给 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 许可。本文不含任何商业合作。