给 Claude Code 装技能这件事，卡人的从来不是写提示词，而是喂文档。某个框架的官方文档三百多页，你得先翻一遍、抽成 reference 文件、再手写一份 SKILL.md 告诉它「什么时候读哪个文件」。这套活干完，一整天没了。
1.5 万 Star 的 Skill Seekers 就是冲这件事来的：号称把文档站、GitHub 仓库、PDF 等 18 种数据源转成可以给 AI 用的知识资产，15 到 45 分钟出一份技能包。我把它拉进沙盒从源码跑了一遍，抓取和打包确实能用，但它的「代码智能」部分——设计模式识别——基本是在猜。
它做什么：三层流水线
把它拆开看只有三步。第一步是发现层，拿到一个 URL 后会依次尝试 sitemap.xml、站点自带的 llms.txt 索引，最后才上无头浏览器渲染，这套顺序决定了它比普通爬虫快。第二步是抽取层，18 个 scraper 各管一类源：网页文档、GitHub 仓库、本地代码库、PDF、Word、EPUB、Jupyter Notebook、PPT、OpenAPI、AsciiDoc、RSS、man 手册、Confluence、Notion、Slack 导出、视频等。第三步是组织层，把抓下来的内容按主题分类，交给 AI 增强写成 SKILL.md，再做多源冲突检测，最后打包成目标平台格式。
对外宣传的数字不少，我逐项在代码里核了一遍：
| 官方声明 | 核对结果 |
|---|---|
| 18 种数据源 | 属实（source_detector.py 里 15 种显式类型 + Confluence/Notion/聊天导出） |
| 22 种导出格式 | 属实（adaptors 注册表正好 22 条，含 LangChain、LlamaIndex、4 个向量库） |
| 40 个 MCP 工具 | 属实（server_fastmcp.py 里正好 40 个注册装饰器） |
| 19 个 agent 安装目标 | 属实（AGENT_PATHS 19 条） |
| 68 个增强工作流预设 | 属实（workflows 目录 68 个 yaml） |
| 3,900+ 测试 | 属实偏保守（189 个测试文件里 4,235 个 test 函数、8 万行） |
数字没注水，但文档与代码脱节的地方不少：同一个 MCP 服务器文件的 docstring 还写着「提供 34 个工具」，实际是 40 个；install-agent --help 只列出 8 个可选值，代码里支持 19 个，剩下 11 个只能靠翻 README；README 说 CLI 有 19 个命令，实际是 20 个。
实测：抓取能用，代码分析不能信
抓取、打包、冲突检测：能直接用
测试环境是手机上的 Alpine aarch64 沙盒（Python 3.12），因为 pip install skill-seekers 在这台机器上装不完——核心依赖里 PyMuPDF 没有对应的 musllinux 轮子，需要本地 C 编译器。顺带一提，一个「文档抓取工具」的核心依赖有 22 项，其中包含 langchain 和 llama-index 两个 RAG 框架，装在服务器上得先想清楚。
从源码跑抓取则相当顺。拿 Ruff 的文档站试，它命中 llms.txt 索引，14 个页面约一分半抓完，产出三个文件：SKILL.md 4.3KB、references/ruff.md 135KB、index.md 91 字节。自带的质量评分给了 72.75 分（B-），其中文档覆盖率一项只有 15 分。
问题出在这份 SKILL.md 的内容上。不接 AI 增强时，它输出的是一份模板骨架：frontmatter 里的描述就是「Use when working with ruff-test」，8 条「Pattern N」小标题的内容是抓下来的导航栏文字（「Ruff ruff Overview Tutorial Installing Ruff The Ruff Linter…」），13 个代码块里 5 个贴了语言标签，其中 4 个把 TOML 配置标成了 sql 和 json。更别扭的是正文让读者去翻 getting_started、tutorials 这几个参考文件，而 references 目录里只有它刚生成的那一份。
那默认流程会走 AI 增强吗？会。不传参数时它默认走本地增强，直接执行 claude --dangerously-skip-permissions，超时设成 2700 秒，本机没装这个 CLI 的结果是一行「Command not found: claude」，然后留下一份 2KB 的骨架——四个流程步骤里，最后一步静默降级了。
设计模式识别：一个漏检、三个误报
真正让我意外的是设计模式识别。这是它宣传的差异化能力：10 个 GoF 模式检测器、跨 9 种语言、分 surface/deep/full 三档深度。我造了个 6 文件的小项目试，结果是这样：
| 我造的场景 | 它的判定 |
|---|---|
AppConfig：__new__ + _instance 缓存的标准单例 |
三档深度全部漏检 |
class Singleton: pass（只有类名，没有任何实现） |
判为 Singleton，0.7 分 |
| Policy：保险单记录类，与策略模式无关 | 判为 Strategy，0.7 分，证据只有「类名像 Strategy」 |
DbSingleton：带 @classmethod 的单例 |
额外被判为 Decorator |
漏检的那个最冤枉：代码里明确写着「Python 的 __new__ 覆盖本身就是受控初始化」，给了 0.3 分，而命中阈值是 0.5——这个检测器永远认不出 __new__ 写法的单例。误报的那个更值得说：Policy 被认成策略模式，是因为关键词表里塞了「policy」。而 @classmethod 被判装饰器模式，是把语言级的装饰器语法和 GoF 的装饰器模式混为一谈了。
这不是个别现象。我拿它扫自己 217 个源文件，报出 301 个模式，其中 Decorator 一项 94 个，证据全部来自 Python 内置装饰器（@property 53 个、@staticmethod 21 个、@classmethod 16 个、@abstractmethod 5 个），没有一个是真正的装饰器模式实现。172 个被判定的类里，95 个同时命中多个模式，49 个既算 Adapter 又算 Decorator——因为两个检测器共用 wrapper/proxy 关键词。
还有个更隐蔽的机制问题。full 深度会拿整个文件的文本去 grep instance、if not、threading 这类词，命中就加分，不管这个词属于哪个类。我做了个隔离测试：一个文件里放只有类名的 Singleton 和一个带 instance 方法的无关类，前者立刻从 0.6 涨到 0.7，证据栏写着「检测到实例缓存」——它缓存了个寂寞。
对比之下，它另一个卖点做得很扎实。多源冲突检测我造了一组「文档写了 3 个参数、代码只有 2 个」的数据喂进去，4 条冲突分类全对：文档里有代码里没有的 API 标为 high，代码里有文档没写的标 medium，而下划线开头的内部 API 自动降级为 low——这个降级逻辑是对的，说明设计者确实想过误报问题，只是这套思路没被用到模式检测上。
其他几个实测细节：打包成 Claude 技能包正常，39.7KB 的 zip 里 SKILL.md 在根目录；不给 GitHub token 也能抓仓库，但撞上 API 限流后 PyGithub 会进入 2684 秒（约 45 分钟）的退避重试，而不是快速失败报错；PyPI 上最新版是 8 月 3 日发布的 3.9.1，而仓库 development 分支已经到 3.10.0.dev0，pip install 拿到的是落后六周的版本。仓库本身还有个卫生问题：docs/UML 目录 2049 个文件占 27.3MB，近三分之一的仓库体积是架构图。
该不该用
同类里还有三个选择：手写 SKILL.md 最准但最慢；拿 llms.txt 自己写二十行脚本最轻，只适合现代文档站；官方 skill-creator 管结构规范但不管抓取。Skill Seekers 的位置在中间——它把「抓 + 分 + 打」这一整条链路做完了，22 种导出格式里那 8 个 RAG 目标是别人不做的。
它适合：手上有大量内部文档、老项目代码、PDF 手册要批量变成知识资产的人；一次抓取、要同时导出成 Claude 技能 + 向量库数据的人。
不适合：只想给某一个框架做一份高质量 SKILL.md 的人（这种情况手写反而更快）；没有模型 API key、也没装本地编码 agent 的人——因为默认的增强流程会直接失败。
我的判断是：把它当抓取和打包工具用，把它的代码分析当参考信号而不是事实。冲突检测值得一试，模式识别的输出建议直接忽略。
相关阅读：
关注 AI商业快讯，每天一篇 AI 热点深度解读。
—
实测数据截至 2026-09-14，基于 development 分支（3.10.0.dev0）源码在 Alpine aarch64 沙盒运行。项目地址：yusufkaraaslan/Skill_Seekers，MIT 许可。本文不含任何商业合作。
