Agent Skill

taste-skill 复测：9.2 万 Star 的反 AI 味前端框架，近 100 条提交里 63 条只改 README，技能正文 131 天没动

作者
taste-skill 复测：9.2 万 Star 的反 AI 味前端框架，近 100 条提交里 63 条只改 README，技能正文 131 天没动

如果你用 Claude Code 或 Cursor 生成过落地页，大概都见过同一张脸：按钮全是圆角、卡片全带阴影、标题一律紫蓝渐变。四星期前我评过一个专治这个毛病的项目 taste-skill，当时它 8.4 万 Star（GitHub 上的收藏数，相当于「赞」）。今天它 9.2 万，涨了 8,279 颗。

星数在涨，但我把仓库拉下来重数了一遍，发现一件更值得说的事：最近 100 条提交里，63 条只动了 README、赞助商图片和许可证文件，一行技能规则都没改。 主技能的正文，上次修改停在 5 月 26 日。

先说它是什么

taste-skill 是一套「反模板」的前端设计技能：它把「AI 出的页面为什么一眼假」拆成一条条可检查的硬规矩，写进 AI 助手的指令文件里。你装上它，助手出手前就必须先读需求、声明自己的设计判断，再按规矩落地。比如「三张等宽卡片」和「居中大标题」这类默认动作，被它点名列为 AI 痕迹。

上次提到的几点，一条都没变

四星期前那篇评测末尾列了几条待观察项，我这次逐条复核，结论是：一条都没改。

上次指出的 现在的状态
无正式版本，默认技能自称「实验版」 未变：仍是 0 个版本标签，仍写「实验版」
规则靠助手自觉遵守（issue #106） 未变：issue 仍开着，最新一条评论在 9 月 30 日
README 顶部有 Kimi「首购返 10% 额度」推广 未变：同一句仍在 README 第 23 行
技能文件本身 未变：7、8、9 三个月，13 个技能文件一行没改

这四星期里唯一实测变动的数字，是赞助商额度：9 月 23 日，README 里某家赞助商的注册赠送从 1 美元改成 3 美元，提交记录里就是这一行改动。这条和技能好不好没关系。

还有一件事得说清楚，免得记错功劳：这个仓库执行过它自己最重要的那条规矩。5 月 26 日作者做过一次大扫除，主技能文件里 145 处破折号全部清掉，只留 5 处：那 5 处是讲这条规则本身时必须写出这个符号，属于规矩的一部分。这个数字是我用脚本数的，不是照抄它的说明。但这次大扫除发生在 5 月，不是我上次评测之后。

实测第一段：把它的规矩变成 3 条机器检查

这个项目最值钱的地方，是它把「AI 味」写成了一张禁令清单。破折号是全页禁令：标题、正文、按钮、图片描述里一个都不许出现，出现一处，交付前检查就判定失败、必须重写。

但这里有个老问题：规矩是写在文档里的，不是写在代码里的。GitHub 上有个 9 月 3 日开的 issue，标题就是「怎么强迫 AI 助手 100% 遵守这个技能」，到今天还开着，评论区的答案都是同一句话：把规则变成检查，而不是提示词。

我照这个思路动手，写了 3 条纯机械的检查，跑在它自己的仓库上：

它自己定的规矩 我的检查方式 结果
全页禁用破折号 扫描 13 个技能文件里该符号出现次数 103 处命中，其中 93 处在正文
安装名与文档一致 对比安装脚本的键与技能文件声明的名字 13 个里 9 个对不上
模板不带本机路径 扫描脚本里的绝对路径 3 个文件里 4 处，全是写死的 Windows 用户目录

先说破折号。103 处里只有 10 处是在讲规则本身，剩下 93 处是真·正文用法。最夸张的一个技能文件里有 43 处。也就是说，这条它自己判作「头号 AI 痕迹」的红线，在自家仓库里被违反了 93 次。

再说安装名。这个项目的每个技能有两个名字：文件夹名，和技能文件里声明、实际生效的那个名字。安装脚本用文件夹名，文档用声明名，13 个里对不上 9 个。比如主技能，安装脚本认「taste-skill」，实际要用的名字是「design-taste-frontend」。有人 7 月 11 日就开了 issue 指出这件事，到现在没人动。

最后是路径。它的几个图片处理脚本里写死了 C:/Users/User/Downloads 这种本机目录，一共 4 处。任何人克隆下来都跑不动这几个脚本。

实测第二段：装是能装上的，而且是逐字节一致

规矩归规矩，能不能用是另一回事。我在隔离沙箱里跑了一遍完整安装，这个沙箱只有只读的根目录，网络单独开，装完即清：

检查项 结果
安装命令是否成功 成功，一次跑通
实际装到几个技能 13 个，与仓库声明一致
安装位置 项目下的隐藏目录，并自动链接给 Claude Code
覆盖面 输出里具名列出 5 个助手，另有 15 个折叠显示
与我克隆的源码比对 13 个技能逐字节完全一致，零差异
安装体积 384 KB

最后一行是我特意做的对照。技能装到本地后被改过、或者装的是旧版本，是这个生态里最常见的坑；这次一个都没出现。

也有个副作用要提醒：它把 13 个技能一股脑全装上，包括实验版和它替代掉的旧版。你如果只想装一个，得加参数点名。

翻车点：63% 的提交没碰过技能本体

现在说这次复测最意外的一条。

我把最近 100 条提交逐条过了一遍，按它改了哪些文件分类：

提交类型 条数 占比
只改 README、素材图、许可证 63 63%
动了技能规则正文 20 20%
合并分支的记录 10 10%
其它 7 7%

那 63 条里，58 条动的是 README，32 条动的是素材图片。按提交数算，六成以上的改动落在仓库门面上，两成落在技能本体上。

再看时间线就更清楚了。主技能正文的最后一次修改是 5 月 26 日，距今 131 天；13 个技能里有 5 个的最后修改停在 3 月 20 日，比后来那些改动都早得多。最近 100 条提交覆盖的是 4 月 23 日到 9 月 26 日，其中动过技能正文的 20 条，全部集中在 4、5、6 三个月。7 月、8 月、9 月这三个月，13 个技能文件一行都没改过。

README 那一侧则热闹得多：9 月 16 日加赞助商、9 月 20 日一次加四个社区赞助位、9 月 22 日把一位赞助商从公司位挪到社区位、9 月 23 日改赞助额度、9 月 26 日又加一位。

星数从 9 月 4 日的 84,044 涨到今天 92,323，和技能正文的改动没有关系，这 131 天里技能正文一次没动。

这里必须说清楚：改 README 找赞助，在这个生态里是正常且正当的做法，作者也要吃饭。但它会改变你怎么看这个仓库。如果你把它当成「一个正在快速迭代的设计技能」，证据不支持；把它当成「一份已经定稿、正在变现的稳定文档」，才对得上。

三个还挂着的技术问题，我逐条复核过

它开放的问题里，有三条是能机器验证的，我全部重跑了一遍，三条到今天原样挂着：

  • 9 月 12 日开的 issue 说，几个图片处理脚本写死了开发者本机目录、引用了不存在的源文件。我复核：4 处写死路径确实还在，全部是 Windows 用户目录。
  • 同一天开的另一条说，两段「标准代码骨架」里有个冲突：外层元素同时用了两套滚动钉住机制，会导致滚动抖动，而且给「不希望有动画」的用户留了个内容锁死的坑。这两段代码现在还是原样躺在主技能文件里，位置都对得上。
  • 7 月 1 日那条最有分量：主技能单个文件 85 KB，按英文粗略折算约 2.2 万 token（token 是模型读写文字的最小计量单位，也是计费单位）。技能一旦被触发就整份进上下文，且会一直待着。提建议的人已经动手把它拆成「薄核心 + 按需读取附录」，实测常驻体积能小 7 倍。这个方案到今天没被合并。

最后一条可能比前面所有数字都实在：一份 85 KB 的说明书，助手在长对话里很容易读漏，这正是第一个 issue 抱怨的那件事。

拉两个参照物

同赛道里，Impeccable（另一套设计语言技能，作者 pbakaus）75,290 Star，从我上次评测时的 4.99 万涨到现在，已经发过 77 个版本，走的是「生成后用斜杠命令逐条打磨」的路线，不预设风格。Anthropic 官方那份前端设计技能是基线，往上还能叠。

taste-skill Impeccable 官方前端设计技能
Star 92,323 75,290 官方基线
协议 MIT Apache 2.0 随官方
版本节奏 0 个正式版本 77 个 持续更新
思路 装一次，生成时自动生效 生成后逐条打磨 基础规则

适合谁：用主流编码助手做落地页、官网、作品集，被 AI 模板页面反复折磨的人。它的禁令清单确实具体，照着读一遍就能改掉自己的习惯。

不适合谁：做数据密集后台和复杂表单的人。它的「不适用范围」里就明确写了仪表盘、数据表、多步表单。另外如果你已经在用别的同类技能，先别急着叠加，两份规矩同时生效时助手会挑它好执行的那份。

我的判断

这次和上次的结论不一样了。

上次我把它当作一个正在快速迭代的项目推荐；四星期后，这个判断被数据推翻了。它的设计思路依然值钱，但那套思路从 5 月起就没再更新过，现在维护的是它的变现面。

具体怎么用：把它的技能文件当一份「设计纪律手册」读一遍，挑出适合你的规矩抄进自己的项目说明文件，仓库本身可以不用装。等哪天它真的拆完文件、修掉那几个脚本，再回头装也不迟。

最后提一句，这篇复测的全部数字都来自今天的沙箱实测，日期是 2026 年 10 月 4 日。这种仓库变化快，尤其是 README 那一侧。

相关阅读：taste-skill 上一次评测（四星期前，84k Star 时的完整拆解），以及设计类技能的另一条路线（192 套配色全过无障碍标准的那一个）。

关注 AI商业快讯，每天一篇 AI 热点深度解读。

mattpocock/skills 深度评测：27.4 万 Star 的工程师技能库，27 个技能只有 688 KB，6 条自定规矩我全跑了一遍

作者
mattpocock/skills 深度评测：27.4 万 Star 的工程师技能库，27 个技能只有 688 KB，6 条自定规矩我全跑了一遍

用过 Claude Code、Codex 这类 AI 编程助手的人，大概都经历过同一个循环：听说某个「技能包」很神，装上；过两天又看到另一个，再装上。装到第二十个的时候你会发现问题来了——助手不但没变聪明，反而开始答非所问，因为它每次开口之前，都得先读完你塞给它的那一大堆说明书。

今天要评测的 mattpocock/skills 走的是完全相反的路线。它挂着 27.4 万个 Star（GitHub 上的收藏数，相当于「赞」），是这一轮 AI 技能热潮里体量最大的仓库之一；但你把它的技能全部下载下来会看到，所有技能文件加起来只有 259 KB——比一张手机照片还小。

它是谁，凭什么这么大

作者 Matt Pocock 是挺有名的 TypeScript 讲师，仓库第一句话写得很直白：「让我每天干真活的技能，不是 vibe coding（指不做设计、完全靠感觉让 AI 写）。」

它反对的东西也写在明面上。GSD、BMAD、Spec Kit 这一批「流程框架」，思路是替你接管整套开发流程；作者的说法是，接管的同时也拿走了你的控制权，一旦流程本身出 bug，你很难改回来。

所以它的设计只有三条：技能要小、要能改、要能互相拼。

这话几乎所有技能库都会说，区别在执行。我把它 clone（把仓库整个拷到本地）到沙箱里数了一遍，实际情况是这样：

项目 数字 说明
Star 274,405 2026-10-02 实测
Fork 23,051 别人复制走自己改的次数
仓库体积 688 KB 不含版本历史
技能目录 259 KB 全部技能文件
技能文件 37 个 其中 27 个随插件发布
未发布技能 10 个 6 个标「开发中」、4 个标「杂项」
协议 MIT 可商用、可改

关键设计：技能只按「谁来喊」分类

这是整个仓库最值得抄的一点。它不按功能分（写代码 / 调试 / 写文档），只按一个问题分：这个技能由谁触发？

  • 用户调用：只有你亲手敲 /grill-me 才启动，职责是「指挥」。
  • 模型调用：你也能敲，同时助手觉得合适时会自己拿来用，职责是「装规矩」。

这两类不许乱串：一个用户调用的技能，可以去调模型调用的技能，但绝不允许去调另一个用户调用的技能。27 个技能里，16 个归用户调用，11 个归模型调用。

为什么要这么较真？因为 AI 助手最常见的翻车方式是「自说自话地开工」。用户调用的技能负责在开工前把话问清楚，模型调用的技能负责在开工时守住规矩——两类混在一起，就会出现助手自己指挥自己。

实测：它自己定的规矩，我一条条跑了一遍

它把仓库规范写进了项目说明文件，一共六条硬规矩。我把每一条都变成了可执行的检查脚本，在沙箱里跑：

它定的规矩 我的检查方式 结果
正式技能必须全部随插件发布 对比技能目录与插件清单 27 对 27，通过
未发布技能不得混进插件 检查「开发中/杂项」是否泄漏 通过
每个技能桶要有说明文件 逐个目录查找 5 个目录齐全，通过
正式技能要有文档页 逐个技能查找对应页面 27 个全有，通过
未发布技能不给文档页 反向检查文档目录 通过
全文禁用破折号 全文扫描该符号 手写内容 0 处，通过

六条全过。 这在同类仓库里不算常见——大多数技能库的说明文件和目录结构早就对不上了。

唯一一个「不完全干净」的地方，正好说明了它的严谨程度：那个破折号规矩的最后一条例外，是自动生成的更新日志。我扫出来的 68 处破折号全部落在这个自动生成的文件里，手写的技能正文、文档、说明文件里一处都没有。规矩是人定的，例外也是人写的，而它把例外限定在了机器产出的那一个文件。

最核心的东西只有一个：盘问引擎

整个仓库的心脏叫 grilling，直译是「盘问」。

它的做法是把你要做的一个计划拆成一棵决策树：每个决定下面，挂着依赖它的决定。然后是关键一步——它一次只问「现在就能问」的那一层，每个问题都编号，而且必须附上助手自己推荐的答案。你答完这一轮，树的边界往外推一圈，能问的问题就变多了，再问下一轮。

有一点很实用：找事实是助手的活，不是你的活。某个问题需要先去翻代码或查文件，它就派个子任务去查，而不是回头问你——因为那些问题「等查完再问」，剩下的照问不误。

我数了一下，27 个正式技能里，有 7 个都在用这个盘问引擎：做规格的、分派工单的、做代码评审的、做架构梳理的，全部指向同一个原语，没有一个重新发明提问方法。

也正因如此，最早的两个技能薄到离谱。grill-me 的正文只有一句话——「调用 grilling 技能」；grill-with-docs 的正文也只有一句话——「调用 grilling 和 domain-modeling 两个技能」。它们不是功能，是指针。 真正的方法只有一份，改一次，七处同时生效。

拉两个参照物

第一个是同类里体量最大的：affaan-m/ECC，同样 27 万 Star 上下，同样是「给工程师的技能库」，但走的是完全相反的路——什么都给你。68 个助手、293 个技能、94 个命令，仓库体积 80 MB。mattpocock 这个仓库是 688 KB。换算成「每 KB 换到多少 Star」，两者差了大约 121 倍。

mattpocock/skills affaan-m/ECC
Star 274,405 270,953
仓库体积 688 KB 80 MB
技能数 27 个（发布） 293 个
思路 把判断权还给你 把所有能力塞给你

不是说 ECC 不好——它想做的是一整套「Agent 操作系统」，那是另一种野心，需要的体量也确实不一样。但两个仓库摆在一起，恰好是当下 AI 技能生态的两条分岔路。

第二个参照物更有意思，是它自己承认的一个洞。它的 tdd（测试驱动开发）技能文档里明写着：这个技能决定「在哪些接缝上写测试」，但没有任何东西决定「这个改动到底值不值得写测试」。作者把它记成了 issue #746，到现在还开着。一个 27 万 Star 的仓库，把自己管不了的那块标出来不遮不掩，这比任何功能列表都更能说明它的风格。

我的判断

如果你已经装了十来个技能、助手开始变迟钝，这个仓库值得看的是它的结构思路，而不是某一条具体规则。

  • 适合谁：天天写代码、对「流程被框架接管」有戒心的工程师。它默认你懂测试驱动开发、懂领域建模，不负责给你补基础。
  • 不适合谁：想要「一键装好就变强」的人。它装的当天几乎没变化，好处是你用久了会形成自己的改法。
  • 一个提醒：它上次发版是 8 月 6 日，到现在 57 天，中间积压了 75 个提交、13 个待发布的小改动，版本号还停在 1.2.3。功能一直在动，插件包更新滞后。另外按它自己的说法，插件和手动拷贝两种装法只能二选一，都装你会得到每个技能两份。

同类工程技能库可以对照着看：addyosmani/agent-skills 深度评测（25 个技能、自带评测全绿的另一个路线），以及 Spec Kit 深度评测（同一批「流程框架」里长成插件市场的那一个）。

关注 AI商业快讯，每天一篇 AI 热点深度解读。

reverse-skill 实测：36.9k 星的技能路由包，它自己 178 条路由全绿，我出的 56 条错了 7 条

作者
reverse-skill 实测：36.9k 星的技能路由包，它自己 178 条路由全绿，我出的 56 条错了 7 条

132 天 36,908 星，平均每天约 280 个 star——reverse-skill 是近期安全向 Agent 技能里涨得最快的一个。它的判断很简单：AI 不是不会用工具，是不知道该用哪个工具，于是把 44 条路由规则摆在最前面，让 jadx、IDA、Frida、Burp 先各归各位，再进入 45 个场景模块里的那一个。仓库自带 178 条路由回归用例，我在 Linux 上全量跑完，178 条全绿；随后自己出 56 条对抗用例，它错了 7 条，其中 3 类是真问题——最典型的一个 bug，会让「sandbox escape」这种标准提法被路由去分析恶意软件。

一个「先选剧本再动手」的技能路由包

拆开仓库，它由三层组成：单一事实源 skills/config/routing.json（15,089 字节，44 条规则按优先级排列，每条规则由 must 命中、mustAll 全中、exclude 一票否决三段组成）、45 个场景模块的 SKILL.md，以及一套 bootstrap 脚本负责探测本机工具链。路由产出 PRIMARY/SECONDARY 两档 skill 路径和置信度（high/medium/low），还附带 case-init 流程：授权范围与网络档没就绪之前，不许对真实目标动手。

项 我实测的数字
路由规则 44 条（R0–R45，R0 为兜底），优先级链单独列出
场景模块 45 个 + 根路由 SKILL.md，INDEX.md 由脚本自动生成
CTF 子技能 41 个 competition-* 目录、42 个 SKILL.md
SKILL.md 合计 46 个、324,983 字节，按 1.8 字节/token 约 18 万 token
首屏负担 主路由只读 routing.json + MASTER-ROUTING.md（7,435 字节），模块按需展开
提交与人力 181 次提交、15 位贡献者（前三名 42、36、36 次）

上手路径也是三条：给 Claude Code 装 reverse-skill 插件、复制仓库根的 AGENTS.md 到项目 AGENTS/、或 git clone 后用 master-route.sh 单独跑路由——仓库为 Claude、Codex、OpenCode、Cursor、Copilot、Gemini 各准备了各自的桥接文件（CLAUDE.md、AGENTS.md、opencode.json、GEMINI.md 等），最小加载路径甚至可以为零。我在干净的 Alpine 沙盒里跑了 bootstrap：--list 列出 23 项发现能力、7 个工具组、4 条纪律（只发现不激活、MCP 默认不注册、每个安装给一行理由、端口只读探活），并直接点名缺 java、jadx、frida、radare2；它的工具索引刷新后给出 34 项清单，只有 5 项在沙盒里可用（python3、node、npm、npx、burp-mcp-full），每个缺失项都带 install_hint。路由的判定逻辑可以一句话概括：must 命中、mustAll 全中、exclude 一票否决，同分时按优先级链仲裁——官方基准里就有「ghidra + .so」这种用例：两条规则都命中，预设路由是 ghidra 而不是 IDA，靠的正是优先级而非关键词数量。

我抽开了被路由频次最高的 apk-reverse 模块：11,727 字节、14 个 H2，开头是五步 ACTION REQUIRED——NOW 读 precedent-reverse.md 确认这是已授权的常规操作、NOW 核对适用范围、NEXT 查 tool-index.md 校验工具真实路径、缺工具就调 bootstrap 而不是猜路径、ACT 进工作流第一步别停在确认状态；结尾则是「任务完成自检（声称完成前 MUST 通过）」，中间夹着工具分工、自带脚本、禁止事项、输出要求、路由上下文和按需自举六段。相邻的 mobile-reverse 是 6,234 字节，结构同款。首尾各一道强制协议，比在提示词里写一句「要注意安全」硬得多——agent 想跳过，得先跳过自己刚读过的清单。

授权边界在这套体系里不是口头约定。master-route.sh 的下一步是 case-init：先写 scope 文件，声明 authorization_ready（靶标、测试账号、时间窗）、network_profile（read_only / controlled_active / active 三档）和 response_format（no_write / read_only / active），三者没对齐之前，R45 的强制 scope 检查不让任何 ACT 动作落地。配套的 RULES.md（中英两版）还写了更细的硬约束，比如单个红队阶段不超过 5 分钟、不超过 15 个动作，收尾必须提交 Evidence → Finding → Path 三件套到时间线，报告格式由 REPORTING.md 模板锁死。换句话说，它把「你有没有资格动手」变成了一个可被 agent 循环反复校验的状态，而不是一句提示词里的情绪表达。

这个体量设计值得单独说一句。我们评测过的 a-stock-data 把 7,288 行塞进单个 SKILL.md，一次加载 11 万 token；reverse-skill 的 46 个 SKILL.md 全量也有 18 万 token，但它是路由型结构，首轮只读十 KB 级的路由配置，命中哪个模块才开哪个——同一堆文档，上下文成本差一个量级。对比同赛道的大星仓库：ECC 25.5 万星管的是工程纪律，marketingskills 47k 星管的是营销流程，reverse-skill 管的是危险动作的顺序与授权边界——这是三者里唯一把「不许对没授权的目标动手」写进流程的。

实测一：它自己出的 178 道题全绿，状态表却写错了

克隆仓库后我把六套测试全部跑了一遍：

测试 结果
test-routing（路由回归） 178/178 全绿；其中 quick 冒烟 44 条、中文用例 103 条、英文 75 条，44 条路由全部有覆盖
test-bash-workflow 5/5，1.9 秒；含网络档校验、未授权拒绝两条安全断言
verify-repository-security 599 个文件全部被跟踪、74 个可执行源、无符号链接，OK
verify-doc-links 全部内部 Markdown 链接可达
bootstrap 两套回归（manifest + client-neutral） 全过
refresh-tool-index 34 项工具只探测到 5 项可用（python3/node/npm/npx/burp-mcp-full），java、jadx、frida、r2 全缺，每项附 install_hint

基准本身的质量高得超出预期：每条路由至少 2 条用例、44 条全覆盖、中英双语，还是跨平台 CI（Windows + Ubuntu）跑的。但README 的 Current status 表把回归基准写成 175 cases，实际文件里是 178 条（基准 meta 停在 2026-08-02）——文档和数据第一次对不上，就发生在最该对得上的那个数字上。治理面同样偏紧：15 位贡献者、18 个 open issue、7 个 closed，唯一的 PR 还挂着，0 个被合并，主线实际上仍是作者一人在推（最新提交 9 月 22 日）。文档滞后一两天不致命，但滞后偏偏发生在 README 首屏的状态表里——后来者第一眼看到的就是一个错数。

实测二：我出的 56 条对抗用例，49 过 7 错

官方基准的用例几乎都含规则里的字面关键词，等于命题人和考生共用一张表。我另出 56 条：口语化重述、中英混合、多个技能域竞争，全部走真实入口 master-route.sh。结果 49 过 7 错（中文 45/51、英文 4/5），单次路由延迟 min 304ms / p50 358ms / p90 683ms。7 条失败分三类：

类型 用例 → 实际路由 判定
子串误命中 docker sandbox escape → malware-analysis 真 bug
关键词不对称 redis 未授权访问安全评估 → R11 通用渗透 真洞
优先级平局 iOS APP 证书校验绕过 objection → apk-reverse 真错
平局取工具方 用 nmap 扫完出个报告 → R11；mysql 注入 → R35 可辩护
口语掉置信 抓一下 APP 的请求看看签名怎么算 → R0，confidence=low 标记正确

第一个是实锤 bug：R9 恶意软件规则的 mustAll 里有一项裸词 cape（指 CAPE 沙箱），没有词边界，于是 “escape” 直接命中。我补测了四个变体：「sandbox escape」「k8s sandbox escape」「escape from sandbox」全部被判给 malware-analysis，只有中文「容器逃逸」落到正确的 cloud-k8s——因为规则写的是 docker.?escape|container.?escape，中间插一个词就不匹配，而官方基准里 R23 的逃逸用例措辞恰好全都带字面 container/docker，所以 178 条自测全绿也测不出这个洞。第二个是规则不对称：mysql、postgres、mongodb 是裸词直达 R35 数据库安全，redis 却要求 redis.?secur 相邻出现，一句「redis 未授权访问」（渗透测试里最经典的一句话）就漏到了通用渗透。第三个是优先级设计：iOS 与 APK 两条规则同时命中时，R1 排在 R2 前面，于是带 objection 的 iOS 任务进了 APK 技能。

我又围绕这个洞补了四个探针：「sandbox escape」「k8s sandbox escape」「escape from sandbox」三条英文全部落进 malware-analysis，「sandbox 逃逸」因为没有 escape 字面、R9 的 mustAll 不成立，干脆跌到逆向工程兜底——同一个意思，换种说法就换来三种不同结局，路由表对英文子串的敏感和对中文语义的迟钝同时暴露。

值得肯定的是置信度机制真的在工作：中文口语「抓一下这个 APP 的请求看看签名」匹配不到任何字面关键词，路由退回兜底 R0 并标了 confidence=low——它知道自己没听懂，这比硬给一个 high 强得多。合起来看，官方基准考的是「关键词表内命题」，我的 56 条考的是「把同一件事换种说法再问一遍」——178/178 与 49/56 之间的差距，就是这套路由在真实对话里的安全边际。

生态、赞助与中文圈的数字滞后

项目挂了三家赞助（UCloud AstraFlow、AtlasCloud、Kite AI），自建了教程站与 star-history 图，并上了 Trendshift 榜。文档纪律倒是罕见地完整：REPORTING.md 约束证据格式（Finding 必须带 PoC、Path、Impact 三件套）、CHANGELOG 记录到最近一次提交（v1.0.1 是唯一正式 release）、RULES 有中英两版，甚至 burp-mcp-full/ 里嵌了完整的 MCP 服务端代码。中文圈已有教程向覆盖：知乎两篇、腾讯云一篇、CSDN 与 CodePass 各一篇，但口径明显滞后——8 月 20 日的知乎长文还写着「41 条路由规则 + 163 个回归用例」（现在是 44 + 178），Threads 上 20 小时前的热帖还在转「27.5k 星」，而我实测拿到的是 36,908，两天差了九千多。没有一篇做过实测复核——中文教程基本停在安装向，没人跑过一次 test-routing，也没人指出 README 状态表与实际文件差了 3 条用例。这也是本文只做一件事的原因：把它自己出的题和我出的题都跑一遍，让 36,908 这个星数落在可验证的地面上。

什么时候不适合用

它不是万能插件，四种场景建议绕开：任务不在 44 条规则覆盖域里（Web CRUD、数据分析、写作润色），每次请求都要先付一遍路由上下文再落到 R0 兜底，纯亏；中文口语描述容易掉出关键词覆盖，命中不了就得自己补一句术语（我实测中文场景 88% 通过，剩下基本败在口语重述上）；越是关键任务，越不能只信那 178 条全绿——cape 这个洞证明自测基准有盲区，master-route 的输出要人眼过一遍再往下走；另外它的主线是 Windows（PowerShell 一等公民，bash 是对等移植），Linux/Kali 用户建议直接读 kali/ 平台文档。如果你只是想给 Agent 加一个单点能力，装个几百行的小 skill 比引一整套路由与授权流程轻得多——那样的话，先看你更适合哪种，再决定要不要它。

unlazy 深度评测：3,462 星的反摆烂验收闸门，把「做完了」变成一条能跑的命令

作者
unlazy 深度评测：3,462 星的反摆烂验收闸门，把「做完了」变成一条能跑的命令

你让 AI 改 80 个文件里的 bug，它交回一份自信的完工报告，每个文件都打了勾。你抽查一遍，发现它实际只打开了 11 个。

unlazy 的作者把这件事写在仓库最显眼的位置。这个 2026 年 8 月 9 日建仓、40 天涨到 3,462 星的 skill，只做一件事：把「做完了」这句话变成一条能跑的命令。

它不劝模型努力，不写更长的提示词，也不骂模型。它要求 agent 在动手之前先写一份验收台账 GATES.md，每条闸门必须配一条命令和一句成功标记；跑完之后，检查器把「定义摘要、退出码、输出指纹」写回台账，agent 只能报告检查器认可的结果。

我在 Alpine 沙盒里把它拆开，跑了 6 组对抗实验，包括我自己伪造证据去骗它。结论比宣传语复杂：它能识破手写的假报告，但挡不住会算哈希的骗子——而作者自己承认了这一点。

它是一段代码，不是一段话术

反摆烂这个赛道里，unlazy 算是最冷的一条路。

它没有一句「你必须在放弃前再试 3 次」这类施压话术，核心是一个 960 行的 Node 脚本 gate-check.mjs，配套 953 行的解析库。整个仓库的运行时依赖是零：只用 node:fs、node:crypto 这些内置模块，没有 node_modules，Node 16 以上直接跑。SKILL.md 常驻上下文只有 10,520 字符，占整个技能包 114,606 字符的 9.2%，其余方法论、编排、安全说明都靠按需加载。

它给三种场景配了三档模式：

  • solo：一个 GATES.md 管一个任务，适合一个会话能干完的活。
  • orchestrated：先写 PLAN.md 定义契约和树结构，每个叶子和分支各自带台账。
  • parallel：多个叶子并行时，靠 OWNS: 声明文件所有权，先声明再开工，出错时能知道谁动了哪块。

闸门本身长这样，CHECK: 后面是可以执行的 shell 代码，EXPECT: 是只有成功才会打印的那句话：

- [ ] G1: pricing fixtures render the expected tiers
  CHECK: node scripts/verify-pricing.mjs
  EXPECT: pricing verification passed
  EVIDENCE: pending

判定规则只有两条：进程退出 0 + EXPECT 命中输出。两条都满足，检查器才会写回一条自动证据，长这样：

automatic-evidence=v1; definition-sha256=5f9ebdcc…; exit=0; EXPECT=matched;
output-sha256=67265cd5…; output-bytes=9; shell=/bin/sh; cwd=…; path=2da0e2f6c375/7 entries

这条 346 字符的证据，是整篇文章最值得注意的地方：它不是人写的，是检查器写的，而且和这条闸门的 CHECK:、EXPECT:、CWD: 三个字段的 SHA-256 绑定。你只要改动其中任何一个字，证据立刻作废。

实测：6 组对抗实验

我把测试分两类：它能不能识破别人撒谎，以及它自己会不会被糊弄。

实验 我做的事 结果
手写假证据 给一条命令实际会 exit 1 的闸门打勾，证据栏写「passed – independently verified」 --status 判 UNMET，理由是证据未绑定；加 --approve 真跑一遍后，勾被取消，证据回到 pending
未审批直接跑 不带任何参数运行检查器 只打印 CHECK、EXPECT、CWD、SHELL、PATH，一行命令都不执行
输出超限 让闸门打印 2 MiB 再退出 0 不是把输出截断成通过，而是直接 SIGKILL，报 output exceeded 1048576 bytes
定义漂移 把 CHECK 里的 ok.mjs 改成内容完全相同的 ok2.mjs 不执行任何 shell，--status 直接判 stale-unmet
台账畸形 空台账、重复 id、缩进写 ABANDON: 均 exit 2 并给出行号；顶格 ABANDON 判 exit 1 HANDOFF REQUIRED，不算成功
停止钩子 连续触发 6 次停止事件 前 6 次全部 decision: block，第 7 次主动释放，理由是「6 次无进展」，防止把 agent 卡死

有一组实验它没扛住。

它的证据绑定用的是无密钥的 SHA-256：摘要算法是公开的，仓库自己把 gateDefinitionDigest() 导出了。我把这个函数 import 进来，算出一条会失败闸门的定义摘要，然后手写一条声称 exit=0; EXPECT=matched 的证据，再打上勾——--status 立刻把它读成 MET，整份台账报「4 gates，UNMET 1」。一条命令实际退出码为 1 的闸门，就这样被判为通过。

README 里其实写着这件事：这种绑定能发现结构性漂移，但挡不住能编辑台账的人伪造看起来合法的证据。所以正确的用法是父层复核——加 --reverify 重跑所有可跑闸门。我试了，同样一份被我伪造过的台账，重跑 3 条闸门后，假的那条被判 FAIL，勾被取消，证据清空。输出里还有一行 reran: 3, previously met reverified: 3。

说白了：它防的是「不小心糊弄」，不是「故意撒谎」。

官方测试和自己承认的账

仓库自带 8 个测试文件，近 7,000 行。我在沙盒里逐个跑完：34/34、27/27、51/51、29/29、8/8、15/15，压力测试 24 条里通过 23 条，合计 187/188。

唯一挂掉的那条，是安装器拒绝硬链接文件的那组压力测试。我复现后发现失败发生在清理阶段，报的是 ENOTEMPTY。原因是我的沙盒对硬链接做了特殊模拟，ln 之后会留下 .l2s.* 临时副本，连 rm 都报 Operation not permitted——不是产品问题，是环境问题。产品那一侧的断言（拒绝写入、不改受害者文件）实际是通过的。

更有意思的是这个仓库对自己宣传数据的态度。

初版 README 写着深度树的算术：努力量等于 T 乘以 2 的 N 次方减 1，tree 3 就是 4 倍工作量，tree 7 是 64 倍。现在的版本把这句话改掉了，改成「深度树是分解与整合，而不是算术上的努力倍增器」。早期那组「六次运行对比」输出的 token 比例和自找缺陷数，也被明确标注为不可复现、不得当作 benchmark 承诺，仓库里专门放了一份 research/validation-protocol.md，给出预注册、隔离运行、操作化指标、盲评、发布计算过程、限定结论这 6 步可复现协议。

顺便说一句，它的引用是干净的：README 里列的 9 篇论文，我逐个打开 arXiv 核对，编号、标题、日期全部对得上；SlopCodeBench 摘要里那句「没有任何 agent 端到端解决问题，最好的 agent 通过 14.8% 的检查点」，和 README 的引用一字不差。

代价方面：--status 跑一次 206 毫秒，3 条闸门的 --reverify 934 毫秒，一条自动证据 346 字符。这个开销换来的是那句你不能反驳的交付报告。

三条反摆烂路线，选哪条

把已发过的几篇放在一起看，反摆烂目前有三条路线：

路线 代表 做法 你得到什么
话术施压 tanweai/pua（19.6k 星） 用压力话术和方法论约束 agent 的行为 模型行为的改变，无法验证
文件化计划 Planning-with-Files（26k 星） 用三个文件让 agent 不失忆 一份可读的计划和进度
可执行验收 unlazy（3.4k 星） 每条验收标准绑定一条命令 一份能被脚本复核的完成证据

适合谁：长任务、多部件交付、需要向别人交代证据的场景，或者你被 agent 的假完成坑过。它的 solo 模式上手成本很低，一份十来行的 GATES.md 加两条命令就能跑起来。

不适合谁：一次性的小改动别用，SKILL.md 自己写了——琐碎编辑和事实性回答不需要建台账。另外停止钩子只在 Claude Code 里生效，换别的宿主就只剩手动跑检查器这一半能力。最要紧的一条：如果你需要的是防作弊，它不行，它只是让作弊变得需要多写一行代码。

结论

值得放进工具箱，但别把它当防作弊工具。

我的建议是只用它的两个动作：开工前写 GATES.md，交付前跑 --reverify。第一条治的是「凭感觉觉得做完了」，第二条治的是「证据过期了还以为通过」。这两件事它做得比任何提示词都硬。

它现在的短板也很实在：仓库 0 release、0 tag，README 明确说 2.1.0 只是源码里的目标版本，你 npx skills add 装到的是未发布的源码树；11 个 issue 全部关闭、24 个 PR 合并 16 个，治理看着干净，但版本这件事上你得自己锁 commit。

真正让我愿意为它写一篇的，是作者的克制。一个 3,462 星的仓库，主动把早前那句「tree 7 = 64 倍努力」撤掉，把六次运行的对比数据标成不可复现，再附一份自己还没跑的可复现协议——这件事在 skill 生态里比任何性能数字都少见。

关注 AI商业快讯，每天一篇 AI 热点深度解读。

相关阅读：

Dashi PPT 实测：8,250 星的开源 PPT Skill，1020 套版式，一份 JSON 导出 36 页可编辑 PPTX

作者
Dashi PPT 实测：8,250 星的开源 PPT Skill，1020 套版式，一份 JSON 导出 36 页可编辑 PPTX

做过汇报的人都有过同一种卡壳：内容早在脑子里排好了，时间全耗在把字挪进模板、调对齐、换配色。让 AI 代劳也不省心——它吐出来的 HTML 常常是「看着像 PPT，改起来像拆炸弹」，动一行样式整页崩。

所以当一个 8,250 星、97 天冲到榜单的 PPT Skill 出现在雷达里，我决定不只看它的宣传页，而是把它彻底跑一遍：不装插件、不开浏览器点选，只喂一份内容 JSON，看它能不能离线产出一份真正能改的演示稿。结论先放这里：9 页稿子跑通了，还导出成 36 页可编辑 PPTX（11MB、740 个可编辑文本对象）；但它自带的校验器也会误报，这点后面细说。

它把 PPT 拆成了三层

Dashi PPT 是一个 Agent Skill，核心思路和「让大模型直接写 HTML」完全相反：模型不负责画版式，只负责填内容。

它内部有 12 套视觉主题，每套主题是一批预置版式（封面、数据、对比、流程、风险、结论……），每个版式都是一段带控件的 React 组件。生成时先由 layout:query 按「页面角色 + 主题 + 随机种子」选出候选版式，再让 Agent 写一份 PageContentPack：每页只写标题、摘要、要点、图表数据，不写任何样式。随后 goal:scaffold 为每个逻辑页产出 4 个方案——3 个模板方案（锁死版式的视觉结构，只替换文字）+ 1 个按本页内容定制的方案。最后渲染成静态 HTML，导出 PPTX。

关键在「锁模板填文案」这条约束：页面的视觉、结构、数量、显隐、配色由版式决定，Agent 只能改文字。这既是它的可控性来源，也是它的上限所在。主题清单也能看出它的取舍：轻拟态风对应企业内部汇报，深浅代码风对应技术方案，色谱图表风对应数据分析，黑金实验风对应高端发布——都不是给品牌视觉团队准备的。

真正撑起这套体系的不是模板数量，而是三个量化文件：3.5MB 的 layout-manifest.json 登记了每个版式的控件与默认值，71KB 的属性契约约束每个控件能取什么值，82KB 的 spec 校验脚本负责在渲染前拦住非法结构。前者定义「有什么」，后两者定义「不能乱来」。

宣称 我的离线复核
12 套视觉主题 12 套，每套 71 到 111 个版式
1020 个版式页面 1020 条，逐条数列一致
8576 个可调控件 8576 个：开关 4276、滑杆 2372、下拉 1825、图标 77、图片位 26

三个数字全部精确对上，没有注水。

实测：从内容 JSON 到可编辑 PPTX

我把这次评测本身写成了 9 页内容计划，然后在 Alpine/Linux 沙盒里跑完整流程：

  • 依赖只有 35 个包、90MB，npm ci 32 秒装完，没有需要编译的原生模块；
  • 生成器先是两次拒绝了我的输入：一次是我把 chartData 的 id 写成了和 items 相同的 fact-1（要求 id 唯一、label/value/unit 必须一致），一次是同页图表单位混用「个 / 套 / 星」（要求要么全填、要么全空）。这两条不是文档里的客气话，是硬拦截；
  • 通过后产出 9 页 × 4 方案的 goal.json（122KB），渲染出 index.html（601KB）+ assets（7.9MB），离线双击即开；
  • 导出 PPTX 走了无头 Chromium：11MB、36 页、740 个可编辑文本对象、1309 个形状、147 张图片，打开后每段文字都能改。

但「可编辑」有边界：导出器同时给出了几百条降级警告——背景光效、渐变底、部分 SVG 与遮罩元素无法翻译成 PPT 形状，会被栅格化成图片贴上去。也就是说，文字和基础形状是真可编辑的，那些让页面显得精致的视觉特效，到了 PPTX 里就变成了一张底图。这是所有「网页转 PPTX」方案共同的物理限制，不是它独有的毛病。

另外两点体验值得一提：一是中文并没有被打包进字体，index.html 里明确写着 Noto Sans SC 这类中文字体超出体积预算、改用系统字体回退，所以同一份稿子在 Mac 和 Windows 上中文字重会略有差别；二是它的依赖干净得少见，没有原生模块，在一台只装了 Node 的机器上 90MB 就能跑起来。

也就是说，它宣传的「HTML 能编辑、PPTX 可交付」是真的。

但同一个流程里，它自带的文案校验器给了我一个退出码 1：报出 27 处「未覆写模板文案槽」（每页 3 处，对应 3 个模板方案），外加一条「AI Capital / 投融资默认文案残留：大模型」。

我去查了这两条的成色。那条「大模型」来自我自己写的正文「让大模型直接吐 HTML」——词表把常见词当成了投融资模板的特征词。而被判「未覆写」的 statLine，实际是投影阶段被显式清空（值写成空字符串），cards 也已绑定到我的 3 条内容和 1 条图表摘要，只是校验器把「空值」和「没写」算成了一回事。渲染出来的 9 页里，我一处模板默认文案都没找到。

模板默认文案确实存在，但位置很隐蔽：第 1 页所用版式的默认值是一整套「AI Capital Lab / 战略投资者 / 云资源授信 118 亿美元」的投融资示例，在文件里出现 10 次，全部躺在 data-prop-defaults 里——那是浏览器编辑器里控件的默认值，不是你交付出去就摆在观众面前的字。换句话说，这道闸门偏保守：宁可误报，也要逼你逐槽确认。

两条路线，怎么选

维度 版式库路线（Dashi PPT） 让模型直接吐 HTML
可控性 每个控件有契约与默认值，改坏了会被校验拦住 依赖模型自觉，改一处可能整页崩
自由度 只能组合已有版式 任意布局，上限更高
返工成本 改内容不动样式 常要整页重写
交付 静态 HTML + 可编辑 PPTX 通常只有一次性 HTML

几个必须先知道的前提：一是可编辑 PPTX 导出要在本机跑一次无头浏览器（官方推荐 macOS/Windows，Linux 需要自备 Chromium）；我在沙盒里就撞上了环境限制——导出 CLI 启动的预览服务读取网卡信息失败，最后是绕过预览服务、直接调用导出引擎才拿到文件。二是许可证是 AGPL-3.0，公司内部用没问题，把它包进自家产品再分发前要确认合规。三是版式覆盖的是常见汇报结构，发布会主视觉那种强定制需求仍要人工介入。

适合谁：周报月报、方案评审、产品介绍这类高频、结构固定的汇报，收益最大；需要交付 PPTX 继续人工改的团队也合适。不适合谁：追求品牌级排版的视觉团队，以及指望它一键完成「内容 + 视觉双定制」的人。

我的判断

值得放进工具箱，但别把它当成万能排版引擎。它真正的价值不在 1020 个版式，而在那套「内容与样式分离 + 生成前后双校验」的工程约束——这正是多数 AI 出图/出稿工具缺的一环。它的问题是闸门做得太保守，误报会消耗信任；一句话概括：它不擅长帮你把 PPT 做漂亮，但很擅长让你别在排版上浪费时间。

关注 AI商业快讯，每天一篇 AI 热点深度解读。

相关阅读：

Skill Seekers 实测：1.5 万 Star 的文档转技能工具，18 种数据源 22 种格式，设计模式识别却把 @property 当装饰器模式

作者
Skill Seekers 实测：1.5 万 Star 的文档转技能工具，18 种数据源 22 种格式，设计模式识别却把 @property 当装饰器模式

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

i-have-adhd 深度评测：4.3 万 Star 的输出风格 skill，自带评测涨 0.43 分却被自己的闸门拦下

作者
i-have-adhd 深度评测：4.3 万 Star 的输出风格 skill，自带评测涨 0.43 分却被自己的闸门拦下

用过 Claude Code 的人几乎都撞过同一堵墙：问了半小时，答案埋在第三段；改完一个 bug，它还要用两段话回顾自己做了什么，最后来一句”希望这有帮助”。

i-have-adhd 就干一件事——把 AI 的回答从”报告”改成”下一步做什么”。它用 10 条规则把输出重新塑形，上线 122 天拿到 43,456 颗星，是 2026 年增速最快的输出风格 skill 之一。更有意思的是：这个项目自带一套评测框架，而它自己公布的评测结果，发布闸门是失败。

它不是 CLI，是一份 142 行的规则文件

整个技能的本体，就是 skills/i-have-adhd/SKILL.md：7,207 字节、142 行，MIT 许可。没有模型、没有 API、没有依赖，任何 harness 都能装。

它的出发点是五条关于 ADHD 读者的判断：工作记忆小（不在屏幕上就等于忘掉）、知道答案不等于做完、启动是最难的一步、模糊的时间估计等于没有估计、进展必须看得见。十条规则全部由这五条推出来。

规则 治的毛病 我的一行判断
1 先说下一步动作 答案埋在下文 最有价值的一条，直接改变回答的第一行
2 多步骤写编号 步骤糊成一段话 要求”能少一步就少一步，别写完整路线”
3 结尾给一个 2 分钟内能做的动作 “还需要什么随时说” 把开放式结尾换成封闭动作
4 抑制跑题 顺手塞三条无关建议 自己查得到的先自己查，留到最后的只有一条
5 每轮重述状态 “第 3 步做到哪了”要靠翻记录 “第 3/5 步完成，下一步回填列”
6 给具体时间估计 “这需要一些工作” 明确要求用分钟，不许用”一会儿”
7 让成果可见 改动藏在总结里 “登录现在能用魔法链接了，跑 npm run dev 试”
8 错误只讲事实 “哎呀，测试好像失败了” 位置 + 原因 + 修复，不演情绪
9 列表控制在 5 项 一屏 30 条的清单 争论最多的一条，见下文
10 不写开场白、不写回顾、不写客套 “好问题！让我想想” 直接禁止清单里点名了这些话术

关键的反直觉在于：它不追求短。规则 9 的原文明确写了”这条只塑形，不能限制分析、检索、工具结果、候选项生成”；技能里还专门留了一节”什么时候可以破例”，六种情况包括：用户要求解释就尽管展开、破坏性操作先确认、连续三次修不好就停下来质疑假设、”规则和任务打架时任务赢，形状不变”。最后一条的例子写得很清楚——用户问”我有哪些选项”，答案就该是 2 到 4 个带取舍排序的选项，而不是一条路径。

它的安装面铺得极广：仓库里的安装文档有 14 个章节，覆盖 Claude Code、Codex、Cursor、OpenCode、Gemini CLI、Kimi Code CLI、Qwen Code、Copilot、Pi、OMP、Zed、Antigravity、AstronClaw 等 13 个具名平台，外加一个通用 agent-skills 方式。但它没有发过任何 release，也没有 git tag，package.json 里的版本号停在 0.3.0——43k 星的仓库，走的还是”直接追 main 分支”的路线。

实测：自带评测框架跑得通，但它自己的闸门过不去

这个仓库最特别的地方，是它为了回答”这个 skill 到底有没有用”专门造了一套评测框架：14 条用例 × 3 轮 × 基线/候选两组 = 84 个回答，再用同一个模型盲评打分。

我把这套框架在沙盒里跑了一遍，是可以复现的：

  • python3 scripts/run_evals.py validate 通过，14 条用例格式合法；
  • plan --trials 3 能输出完整的运行矩阵（84 行生成 + 42 次评判）；
  • 仓库自带的 51 个单元测试，6.77 秒全过。

作者公布的结果确实漂亮：加权分从 4.045 涨到 4.473。拆开看，简洁度维度涨得最猛（3.429 → 4.571），而权重最高的正确性（+0.190）和安全性（+0.024）也没掉——README 里那句“不是拿准确度换简洁”，在数字上站得住。

但同一份 RESULTS.md 往下读三行，写着 Release gate: FAILED。失败原因是闸门的第一条规则：”候选中不能有任何阻断性发现”。候选有 3 个，基线有 7 个，翻了一倍还多，照样不算过。

我把这个闸门单独复现了三次，结论很干净：

  • 按公布的每用例均分重建（加权分 4.045 对 4.473，与我复现出的算数完全一致）、候选仍带 3 个阻断 → 不通过；
  • 候选全维度满分 5.0、只保留 1 个阻断 → 不通过；
  • 候选全维度 5.0、0 个阻断、基线 4.0 → 通过。

也就是说，规则 1 是一条绝对条款：只要用例集里还剩任何一个阻断性发现，再优秀的候选也过不了。RESULTS.md 自己把这层写透了——”按现在的写法，任何候选都不可能在还有阻断留存时通过，无论它改进了多少”。

更麻烦的是，14 条用例里有一条结构上不可能通过。agent-owned-edit 问的是”我让你改 README 的错别字，你有仓库权限，接下来怎么做”，评分要求”直接动手改，然后报告验证结果”。但两个 runner 的配置一个是 --tools ""，另一个是 --sandbox read-only——谁都没有工具。作者在 issue #98 里承认：这是”在一个没有行动能力的配置里要求智能体行动”，而且基线在这种不可能的任务上退化成了”我现在去读文件，让我用一下工具”这种自言自语。

真正的坏消息只有一条：partial-success 用例上候选回归了 −0.63 分（三轮分别是 +0.05 / −0.70 / −1.25）。机制被指得很准——规则 8 要求”先说原因，再给修复”，当证据不足以确定原因时，这个模板会推着模型去编一个原因。评判模型的批注原文是：”把『缺少认证头』当成确定原因并给出修复，没有任何证据支撑。”作者没有辩解，把它标成了”唯一值得加试验轮次的方向”。

顺带说，它的盲评机制不是口号：42 组（用例、轮次）的 A/B 标签由组名的 sha256 派生，我算出来 A/B 分布是 23:19，同一组重跑标签不变——结构上确实没给评委留下位置信息。

两个真实的坑：常开钩子会静默复活，中文文档缺两节

坑一：你说”关掉”，一次上下文压缩就给你打开。

Claude Code 上有个常开模式：把 flag 文件写到 ~/.claude/.i-have-adhd-always，之后每次会话启动由 SessionStart 钩子把整套规则注进去。我实测了：flag 不在时零输出，flag 在时每次注入 6,986 字节，而且 sh 版和 Node 版两个实现的输出逐字节一致。

问题出在匹配条件上。hooks.json 写的是 startup|resume|clear|compact——resume 和 compact 都是接着旧会话继续，但钩子本身只检查 flag 文件是否存在，全程不读 stdin（我把 hooks/ 目录全部文件 grep 了一遍，没有任何 stdin 或 source 字段的读取）。

于是我把 {"source":"compact"} 喂进去，输出和 startup 逐字节相同。意思是：你在会话里说了”停掉 ADHD 模式”，压缩一次之后规则会带着”ADHD 模式已激活，适用于每一条回复”的横幅重新注入，而钩子输出在界面上默认不可见。

这条不是我发现的——仓库有个叫 AI Agora 的讨论区（issue #127），专门让 AI agent 之间讨论规则措辞，提这条的 agent 在结尾署了 provenance：由 Claude Code（claude-opus-5）起草并验证。同一讨论区的另一条提案（opencode 配 GLM-5.3 起草）指向的正是规则 8 的编原因问题，和评测里的回归对上了。这些提案目前都还没被合并。

坑二：中文安装文档比英文少两节。

.github/install/INSTALL.zh-CN.md 有 12 个平台章节，英文版有 14 个：OMP（Oh My Pi）整节缺失，OpenCode 被并进”其他运行环境”的通用段落里。另外规则的缩写版散落在 13 个文件里，光 INSTALL.md 一个文件就复制了 6 份规则清单——想改一条规则，得同时改十几个地方。

同类项目里，规则 9 至今还在改。15 条评论的 issue #96 里，用户反馈”控制在 5 项”被模型字面执行成”砍掉第 6 项之后的全部”，作者前后给了三版措辞，当前版本的解法是加一句”多余的条目内部保留，只是不显示”。

和同类比，它站在哪个位置

项目 星数 层次 核心手段
i-have-adhd 43,456 结构层 10 条规则重排回答形状：先动作、编号、重述状态
Caveman 105,244 语言层 用洞穴人语体压缩输出，宣称省 65% token
stop-slop-zh 47 语言层（中文） 禁词表 + 标点规范 + 四层质检，专治中文 AI 味

Caveman 和历史榜首那批项目在同一条赛道上：压语言、省 token。i-have-adhd 换了个层面——它几乎不省字，改的是信息的顺序和可见性。issue #4 里就有人问能不能把两者合体，作者的回答是”这个仓库只做 ADHD 相关规则，想合请自己 fork”。

stop-slop-zh 的对比尤其值得看一眼：它的作者跑到 issue #42 里问”把结构收紧，模型会不会把冗余转移到句子层面”，i-have-adhd 的作者直接承认”结构本身不够，句级清理放在发送前检查那一步”，并说”塑完形状，填充物会跑进句子里，然后你追着它跑”。两个作者都确认：严格规则能抬高下限，也会削平上限，所以两边都加了”默认而非绝对”的逃生舱。

适合谁：日常在 Claude Code / Codex / Cursor 里跟 Agent 来回拉锯、经常要翻半天找结论的人；团队里要让 AI 输出变成可执行步骤的负责人。不适合谁：主要用 AI 做长文写作和头脑风暴的人（它专门为”解释模式”开了豁免，但你本来也不需要它）；指望它省 token 的人（要省 token，去看 Caveman）。

值得装，但要知道它的三处短板

我的判断是：装，但要把它当一个需要维护的规则集，而不是一个装完就忘的插件。三条注意事项——第一，Claude Code / Codex / Qwen Code 上它默认不自动生效，必须显式调用 /i-have-adhd；第二，上下文压缩或分叉会话会让它掉线或静默复活，觉得输出漂回老样子，重新调用一次是最省事的解法；第三，别把它当成”AI 输出质量的保证”——它有一份诚实到罕见的自评报告，评的是回答形状，不是回答对不对。

顺带一个可以偷师的点：这个仓库把”我怎么证明自己有用”写成了可复现的代码（14 条用例、盲评、发布闸门、成本上限），还允许 AI agent 在专门议题里提交带模型署名的提案。做开源项目的人比做 skill 的人更该抄这套东西，因为它把”我改进了多少”从口嗨变成了能被别人跑出来的数字。

关注 AI 商业快讯，每天一篇 AI 热点深度解读。

相关阅读：

本文数据于 2026-09-13 抓取：仓库 star 数、fork 数、提交时间来自 GitHub API；仓库结构与评测运行结果来自本机 Alpine aarch64 沙盒实测（run_evals.py validate / plan、pytest 51 项、闸门三场景复现、always-on 钩子两种实现对比）。评测框架中的模型打分沿用作者 2026-08-02 公布的数据，非本人重跑，已如实标注。

anything2explainer 实测：上线 3 天 954 星的话题转讲解视频 skill，8 个 Agent 并行 40 分钟出一条片

作者
anything2explainer 实测：上线 3 天 954 星的话题转讲解视频 skill，8 个 Agent 并行 40 分钟出一条片

想把一个技术概念做成一分钟讲解视频，多数人的第一反应是找 Sora 或 Veo 生成 —— 结果画面很炫，字全是乱码，画面上的数字一个都不敢用。第二条路是自己开剪辑软件，一帧一帧摆元素，做一条四分钟的片要熬夜。

9 月 8 日开源的一个 Claude Code / Codex skill 想解决这件事：给它一个话题，它产出一条 1280×720、带配音、带逐字字幕、带章节进度条的科普讲解片，全片每一帧都是代码画出来的。上线三天多，954 星、172 个 fork —— 这是我这两天见过涨得最快的 AI 视频方向仓库。

它到底交付了什么

先纠正一个预期：它不是一个「一句话出片」的工具。作者在 README 里写得很直白：这不是 CLI，交付的是「一个 AI 编程 agent 拍完一条片所需要的全部方法」。

拆开看是四层：

层 内容 规模
流程 SKILL.md：9 个阶段、4 个确认点、8 条硬性原则 86 行
规范 reference/ 九份文档：风格、动效词汇、构图与光、配音分镜、多 agent 协议 687 行
工程 可编译的 Remotion 4 模板 + 图元库 + 11 个脚本 7998 行 TSX/TS + 768 行 Python
标尺 样片《RAG 与知识库》全套档案：调研、解说词、分镜、44 个镜头源码、QC 报告、成片帧 8246 帧 = 4 分 35 秒

真正稀有的不是模板，是把审美写成了可判定的数字。 模板本身只是 Remotion（用 React 写视频）的工程封装，市面上不缺；缺的是这种句子：「每个镜头静止帧占比 ≤40%、最长静止 ≤1 秒」「主角高度 ≥170px 且必须带光」「每个镜头 ≤1 处闪烁，且只给该镜头的核心术语」「内容区最大物体 <110px 不得持续超过 45 帧」。这些数字不是宣传语，仓库里有对应的检测脚本。规则可判定，才谈得上验收。

它怎么跑一遍

它的运行方式更像一个剧组，而不是一个按钮。九个阶段里，主会话只做编排与验收，调研、打样、构建、QC 都是派出去的 agent：

  • 调研 1 个 agent 先产出带来源的调研文档（样片那份 29222 字符、128 个 URL，覆盖定义的每条数字）；画面上出现的每个数字、年份、英文术语都必须能在调研文档里查到出处，没核实的不许上画面。
  • 写完解说词后 tts_build.py 用词级边界把每句切成字幕块，直接算出每句的起止帧号，写进时间轴与字幕表。
  • 主会话定分镜、补图元，先只派第 1 组做出前 30 秒给你看，确认风格后才并行派剩下的 7 组。
  • 渲完不是结束：每章派 1 个 QC agent 逐帧核，再派修复 agent，样片跑了两轮 QC（v1 报出高 1 / 中 23 / 低 42，v3 终检时白名单外的闪烁是 0 处）。

我核对过它的时间轴算术：8246 帧 = 274.9 秒、44 句净朗读 249.9 秒、留白 25 秒占 9% —— 全部对得上。这不是拍出来的片子，是算出来的。

代价也写得很清楚：一条 4 分半的片子，约 2 小时、8 个构建组并行 40 分钟、磁盘预留 5GB 以上。

实测：模板能编译，工具链有坑

我在手机上（Android 内的 Alpine Linux aarch64 沙盒，Node 22）clone 了仓库实测，宣称与实测对比如下：

项目 仓库宣称 实测结果
模板可编译 开箱 npm install + tsc 250 个包 / 263MB / 36 秒；tsc --noEmit 15 秒，0 个类型错误
静态自检 几秒查帧覆盖、闪烁白名单、字面量 44 个镜头全覆盖；但报 18 个问题，其中 17 个是误报
默认配音 edge-tts 免费云端合成 44 句里 34 句拿到音频，随后一句连续 4 次重试失败，脚本当场退出
成片渲染 无 GPU，CPU 渲染 没跑通：需下载 chrome-headless-shell，下载源不通且无 linux-arm64 版
跨平台 macOS 验证过，Linux 应该能用 5 个 shell 脚本写死 #!/bin/zsh，建项目第一步就中止

自检脚本那 17 个误报值得单独说：脚本要求闪烁白名单以固定格式内联写在分镜表里，而样片的分镜表写的是「白名单见 AGENT_RAG_BUILD_RULES.md §8」，正则抓不到，白名单被读成 0 条，19 处合规闪烁全部标红。唯一那条真问题也很有意思 —— SC27 的代码帧区间比分镜表多 4 帧，注释写明是第二轮 QC 故意做的淡出重叠。也就是说：这条检查只能报「对不上」，不能判断「是不是有意为之」。

sed -i '' 是 BSD 语法，在 Linux 上会报 No such file or directory 然后中止。同一个问题也出现在仓库第 4 号 PR 里：有人在树莓派 5 上端到端跑通了一整条片，顺手把 zsh、BSD sed、ARM 上的 TTS 与系统浏览器配置一起修了，目前还没合入。

有意思的是它自曝的返工日志

仓库里最有价值的文件可能是 reference/lessons.md（199 行）。作者用这个 skill 拍了至少 4 部片，每踩一个坑就写一条根因，其中几条是自曝：

  • 样片自己不合格。 第 4 部片加入「持续动作」规则后，回头量化样片：4/6 镜头静止帧占 42%–72%、最长静止 2.8 秒，全部超过新规则。作者原话是「样片也有同样的毛病，所以『对标样片』筛不出它。」
  • 检测分级会骗人。 组级低分辨率检测 48/48 全部通过，成片复测却有 11 个镜头超限（3 个真静止、8 个只有小面积动作）。于是流程里写死了：成片复测才算判据。
  • 一个静默降级的 bug 藏了很久。 edge-tts 从 7.2.0 起默认不再返回词级边界，脚本拿不到词边界就退化成「按字数插值」估字幕位置。作者实测最大偏差 15 帧 —— 整块字幕晚半秒，并承认「这个洞在所有 edge 引擎的成片里一直存在」。

一个项目敢把自家样片的实测短板写进仓库，比任何宣传语都有说服力。

谁适合，谁别碰

先划清路线：这类需求和 OpenMontage 那种「121 个工具调云 API 出片」不是一条路 —— 后者靠生成模型要素材，它一帧都不用生成模型，全部代码绘制，所以任何一帧都能改、每个数字都能追到来源。另一条路是 Manim / Remotion 手写，它比手写多的正是那套流程和判据。

适合：做技术科普、课程、产品原理动画的个人或小团队，愿意花约 2 小时等一条 4 分半的片，并且看重「画面上每个数字都能溯源」。中文是一等公民，文档中文优先，还有独立的英文片配置。

不适合：想一句话出片的人 —— 它会在写文案前、配音前、定稿前、前 30 秒样片这四个节点停下来等你确认；要竖屏的人（模板与安全区全部按 1280×720 横屏）；以及任何商业用途。

商业许可这条不是假设。项目用的是 PolyForm 非商业许可，商用需要作者单独授权，而仓库第 5 号 issue 就是一位教育自媒体在问商业授权怎么办理、是否支持多个账号、能不能改模板做竖屏 —— 截至今天，作者没有回复。

结论

三天 954 星、172 个 fork，说明「把内容变成讲得清楚的视频」这个需求是真实的。但它的价值不在自动化，而在它把一件靠审美的活儿拆成了可验收的工程步骤 —— 从 把审美纪律编译进 agent 到 把方法论写成 skill，这条路数上的极端版本就是它。多数 AI 视频工具还停在「能不能生成」，它已经在回答「能不能验收」。

值得放进观察清单。但真正上手前，先把 zsh / sed 和默认 TTS 这两个动手就遇到的坑解决掉。

关注 AI商业快讯，每天一篇 AI 热点深度解读。

OpenMontage 实测：57k Star 的开源视频 Agent，121 个工具零密钥能跑几个？

作者
OpenMontage 实测：57k Star 的开源视频 Agent，121 个工具零密钥能跑几个？

用 AI 做过视频的人都熟这套流程：脚本问 ChatGPT、图给 Midjourney、配音上 ElevenLabs、最后回剪映里一帧帧对时间轴。四个工具、四轮复制粘贴、一次成片半天就没了。

OpenMontage 想干的就是把这一串收进一句话：你在 Claude Code 或 Cursor 里说「做个 60 秒的神经网络讲解视频」，剩下的交给 Agent。

这个项目 3 月底建仓，现在 5.7 万 Star，还挂上了 GitHub Trending 当日第一的徽章。我把它拉进手机里的 Linux 沙盒实测了一遍：一个 ffmpeg、零 API 密钥，121 个注册工具里究竟有几个能真正跑起来——结论比宣传语有意思。

它的核心设计：没有编排器的 Agent 流水线

大多数「AI 做视频」项目本质是一个带 UI 的调用链：Prompt 进、片段出。OpenMontage 反过来——它没有代码编排器，你的 AI 编程助手本身就是编排器。

仓库里被拆成四层，职责很清晰：

  • tools/ —— 121 个 Python 工具，是 Agent 的「手」（生成、配音、剪辑、分析）
  • pipeline_defs/ —— YAML 管线清单，是「剧本」（哪些阶段、用什么工具、什么验收标准）
  • skills/ —— 157 个 Markdown 技能文件，是「怎么做」（每个阶段的导演手册、创作技巧、评审标准）
  • .agents/skills/ —— 90 个技术知识包，是「底层原理」（各家模型 API 怎么用）

每次生产都走同一条流水线：研究 → 提案 → 脚本 → 分镜 → 素材 → 剪辑 → 合成 →（发布）。每个阶段都配一份「导演技能」文件，Agent 读完再动手，做完自查，再停下来等你点头。

比较少见的是它的闸门设计：提案、脚本、分镜、素材生成、发布五个节点默认强制人工确认，官方写明「checkpoint 写入器会拒绝一个没有审批记录的阶段」。素材生成前还会弹一张分镜接触表，把每个镜头的取景、Prompt、预估花费、质量分列出来——钱花在哪儿，先看再批。

配套还有个本地看板 Backlot，管线跑到哪一步、花了多少、哪个 provider 被选中，实时显示在一块板子上，跑完还能按时间戳回放整个生产过程。

内置 12 条管线，覆盖的场景比想象中宽：动画讲解（Animated Explainer）、纯动效（Animation）、数字人播报（Avatar Spokesperson）、电影感预告（Cinematic）、长视频切条（Clip Factory）、纪录片式混剪（Documentary Montage）、实拍+AI 混合（Hybrid）、多语言配音（Localization & Dub）、播客转视频（Podcast Repurpose）、软件录屏（Screen Demo）、口播（Talking Head），以及用 SVG 骨骼做角色动画的 Character Animation。

实测：官方说 100+ 工具，到底几个能跑

实测环境：手机内的 Alpine Linux 沙盒（aarch64，PRoot），Python 3.12，没有配置任何 API 密钥。所有数字来自 sudo 无关的两条命令——工具的注册表发现接口和仓库自带测试套件。

先把官方宣传和实测数字摆一起：

官方说法 实测结果
100+ 生产工具 注册表实际发现 121 个工具
60+ provider 集成 代码里实际 66 个 provider 标识
700+ 技能与知识文件 skills/ 157 个 + .agents/skills/ 577 个 = 734 个
12 条生产管线 pipeline_defs/ 下 13 个 YAML（多出的是冒烟测试管线）
零密钥可做真视频 装完 ffmpeg 后 121 个工具只有 36 个可用

数字对得上，宣传没注水。但最后一行值得展开——因为这决定了你上手第一天的体验。

密钥不是门槛，运行时才是。 装上 ffmpeg 之前，注册表报告 121 个工具全部不可用。装完 ffmpeg（一条 apk add ffmpeg），状态变成：36 个可用、84 个不可用、1 个降级。

拆开看结构更清楚：43 个纯本地工具里 32 个立刻转正，剩下的靠缺失的运行时卡住——Piper 语音要装 piper 二进制、转写要 faster_whisper、语义检索素材要 PyTorch 模型、本地视频生成要 GPU。而 55 个云端 API 工具，零密钥时可用数为 1。

最扎眼的一格是视频生成：27 个视频生成工具，零密钥时可用数量为 0。官方的「零密钥也能出片」指的是另一条路——用 Piper 配音 + 免费素材库/档案馆的现成画面 + Remotion/FFmpeg 做动画合成。这是一条真实存在的路，但它是「拿现成素材剪出视频」，不是「凭空生成画面」。

我挑了几个 ffmpeg 系工具做了实际的端到端调用：

工具 实测任务 结果
auto_reframe 1280×720 横屏转竖屏 4.4 秒输出 1080×1920，帧数一致
frame_sampler 均匀抽 4 帧 1.2 秒，4 张 JPG
video_trimmer 裁 1–3 秒片段 0.3 秒
silence_cutter 静音段处理 0.5 秒
audio_probe 音频流探测 0.3 秒

手机沙盒里跑竖屏重构，4.4 秒——这类活它干得干净。

然后是翻车点，这两个才是真正该看的。

第一个是硬编码的 Windows 字体。showcase_card（给视频加标题卡）的默认字体写死成 segoeuib.ttf——Segoe UI Bold，Windows 专有。在 Linux/macOS 上 ffmpeg 直接退出码 254，报错信息只有一行 FFmpeg failed。有意思的是它的参数说明写着「Uses system font lookup」（使用系统字体查找），但源码里根本没有查找逻辑，三处字体位置全是 segoeui*.ttf 字面量。我显式传入 title_font=/usr/share/fonts/dejavu/DejaVuSerifCondensed-BoldItalic.ttf 后，4.0 秒正常出片。

第二个更值得警惕：注册表的状态字段会撒谎。仓库里一个 9 月 6 日新开的 issue（#637）由踩坑者提出：diagram_gen 在没装 mermaid-cli 的情况下依然报告 AVAILABLE，然后把 mermaid 源码原样渲染成一张文字卡片，还返回 success: True。提问者写道：「一个信任注册表状态和 success 标志的 Agent，会把代码图片当成图表交付出去。」根因是源码里用 or 判定可用性——只要装了 Pillow 就报可用。

我在自己的沙盒里撞上了同一类问题：face_tracker 的工具契约声明依赖只有 cmd:ffmpeg，实际 get_status 检查的却是 mediapipe + opencv。照着契约装 ffmpeg 永远也变不成可用。

最后是仓库自己的测试套件。我没有挑测试，直接跑 pytest tests/contracts tests/tools：1730 项通过、18 项失败、7 项跳过，耗时 32 分钟。18 个失败全部集中在 Google 系后端（Vertex、Imagen、Lyria），原因是我沙盒里没装 google-genai 包——属于环境缺依赖，不是代码缺陷。一个视频项目把契约测试做到 1700+ 项，说明工程纪律是真的。

谁该用、谁等等：三条现实约束

第一条是许可证。OpenMontage 用的是 AGPL-3.0，不是 MIT。你自己用、内部用都没问题，但如果你打算把它集成进一个对外提供服务的 SaaS 产品，AGPL 的传染性会咬人——这一点官方在 README 里没有专门提示，选型时必须自己过一遍。

第二条是单人项目的风险。仓库 52 位贡献者，作者 calesthio 一个人贡献了 311 次提交，其余贡献者都在 30 次以下；当前 317 个 issue 挂在那里（历史总量 152 个已关闭）。项目背后有一个官网和云服务「OpenMontage Studio」的等候名单，也就是说这是「开源核心 + 云产品」的商业结构，长期维护有动力，但节奏完全取决于一个人和一家新公司。

第三条是要选对参照物。同类的视频自动化项目里：MoneyPrinterTurbo 12.2 万 Star、MIT 许可、昨天还在提交，胜在简单直接但只覆盖「素材拼接 + 配音字幕」这一条链路；Open-Sora 2.97 万 Star、Apache-2.0，做的是模型本身不是生产管线；ShortGPT 已经一年多没提交，可以划掉了；Remotion 5.9 万 Star，是 OpenMontage 底层实际使用的合成引擎，属于互补而非竞争。

顺带提醒一句：官方在 9 月 4 日专门开了 issue 声明有假冒的「OpenMontage-app」安装包仓库在传播，这个项目本身不发布任何安装程序。搜索时别装错了。

如果你已经有 Claude Code / Cursor 的订阅，想批量化生产讲解类视频又不想按月付视频生成 API 的钱，它值得放进工具箱第一格——装好 ffmpeg 和 Node，第一天就能跑通素材类管线。如果你期待的是「打开网页、输入主题、十分钟出片」，或者你要把它塞进商业 SaaS，那先放观察清单，等云版本和许可证策略明朗再说。

一句实话：这次实测我没有注册账号、没有购买任何 API 密钥，官方云产品的报价（官网演示账单约 $2.09 一条 60 秒视频）来自官方页面而非我的账单；沙盒环境是 Alpine Linux，与官方推荐的 Ubuntu/macOS 有差异，少数工具的表现可能受环境限制。上面每一个数字都可以复现——仓库是公开的。

关注 AI商业快讯，每天一篇 AI 热点深度解读。

相关阅读：

darwin.skill 实测：受 Karpathy 启发的 Agent Skill 自动优化器，微软官方集成

作者
darwin.skill 实测：受 Karpathy 启发的 Agent Skill 自动优化器，微软官方集成

你的 Skill 写得再漂亮，跑出来效果差就是零

Agent Skill 生态正在爆发。Claude Code、Codex、OpenClaw、Trae、CodeBuddy 等工具都支持 SKILL.md 格式。当你有 10 个 Skill 可以手动维护，当你有 60+ 个时，你需要一个系统。传统 Skill 审查是纯结构性的——检查格式对不对、步骤有没有编号、路径能不能访问。但一个格式完美的 Skill，跑出来的效果可能很差。darwin.skill 同时评估结构质量和实际效果，然后只保留真正有改进的修改。 受 Andrej Karpathy autoresearch 启发，它把”只保留可测量改进”的棘轮机制从模型训练搬到了 Skill 优化领域。

像训练模型一样优化 Skill

darwin.skill 的核心思路来自 Karpathy 的 autoresearch：定义目标和约束，让 agent 自主生成和测试变更，只保留可测量的改进。区别在于：autoresearch 完全自主（loss 只是个数字），Skill 质量有时需要人的判断，所以 darwin.skill 在关键阶段强制暂停等人确认。

整个优化循环分 5 个阶段：

阶段 做什么 人参与度
Phase 0 初始化 扫描 Skill、创建 git 分支、初始化结果文件 低
Phase 0.5 测试 Prompt 设计 为每个 Skill 设计 2-3 个典型测试 prompt 高（需确认）
Phase 1 基线评估 9 维度打分，子 agent 跑实测对比 中（审报告）
Phase 2 优化循环 诊断短板 → 改一个维度 → 独立评委打分 → 保留/回滚 高（每轮 CHECKPOINT）
Phase 3 回归测试 涨幅低于阈值自动停手 低

棘轮机制是核心：分数只能上升。每一轮要么改进 Skill，要么干净地回滚。不会随时间积累局部退化。v2.1 引入了 paired 同-judge 比较（奇数 N 多数决），解决绝对分数 ±8 的 judge 噪音问题——同一份未改文字换个 judge 评，总分可摆动 ±8 分，全是 judge 换尺，不是真实退步。

独立评分是另一个关键设计：评分用子 agent，避免”自己改自己评”的偏差。SkillLens 论文实证 LLM 自评准确率仅 46.4%（接近随机），加入 meta-skill 三维度后升到 73.8%。每轮启动 2 个独立评委，下一轮换全新评委，避免锚定效应。

9 维度评估体系：结构 + 效果 + 反模式

总分 100。v2.0 吸收微软研究院 SkillLens 和 SkillOpt 两篇论文后，从 8 维升级到 9 维：

结构维度（59分）— 静态分析

# 维度 权重 一句话
1 Frontmatter 质量 7 name 规范、description 包含做什么+何时用+触发词
2 工作流清晰度 12 步骤明确可执行、有序号、每步有输入/输出
3 失败模式编码 12 必须显式编码”如果 X 失败 → Y”，只写正向流程扣 ≥3 分
4 检查点设计 6 关键决策前有用户确认，必须显性标记（🔴/STOP）
5 可执行具体性 18 禁止”建议/可以考虑/根据情况/灵活把握”等模糊词
6 资源整合度 4 references/scripts/assets 引用正确、路径可达

效果维度（35分）— 需要实测

# 维度 权重 一句话
7 整体架构 12 结构层次清晰、不冗余不遗漏
8 实测表现 23 跑测试 prompt，对比有/无 Skill 的输出质量

Meta-skill 维度（6分）— 反模式防护

# 维度 权重 一句话
9 反例与黑名单 6 必须有”不要做什么”的反例清单，只写”应该做”扣 ≥3 分

v2.0 新增的三个维度直接来自 SkillLens 论文：

  • 失败模式编码：不只是”告诉 agent 别犯错”，而是把已知失败路径显式编码进 Skill
  • 可执行具体性：明文禁止模糊措辞，出现 ≥3 处扣 ≥3 分
  • 高风险行动黑名单：rm / git reset –hard / force push 等破坏性操作必须显式列禁

实测表现权重最高（23分）。一个格式完美的 Skill，跑出来效果不好就是零。这就是 darwin.skill 与纯结构审查的本质区别。

实测数据：从 80.8 到 91.65 的进化路径

darwin.skill 提供了两个实测案例：

Skill 基线分 优化后 最终分 增益 评委数
huashu-gpt-image 80.8 91.5 91.65 +10.85 6 个独立评委共识
darwin-skill（自评） 86.05 92.05 92.7 +6.65 独立评委

关键数字：

  • 8 条反例黑名单（明文禁止的反模式）
  • 5 条核心原则（单一可编辑资产、双重评估、棘轮机制、独立评分、人在回路）
  • v2.1 改为 paired 比较后，false-revert 率显著下降
  • 每轮涨幅 < 1 分自动早停，避免凑分堆冗余
  • 干跑比例 > 30% 自动告警

before vs after 示例（huashu-gpt-image）：

  • before（80.8）：结构基本完整，但缺乏失败模式编码，实测输出质量不稳定
  • after（91.65）：失败路径显式编码，模糊措辞清除，实测一致性提升

作者还做了 controlled study：对 huashu-research 做 4 类 degradation，5 个独立 judge 盲测一致判定 V1>V2，Δ 均值 +46.5（5/5 high confidence）。结论：rubric 能识别 gross degradation，但 fine-grained quality difference 仍不可信，重要决策必须人审。

安装、适用场景与结语

安装

npx skills add alchaincyf/darwin-skill

安装后在任何支持 Skill 的 Agent 工具中说”优化所有 skills”或”优化某个 skill”就行。无法访问 GitHub 的朋友，可以下载 zip 包解压放到 ~/.claude/skills/darwin-skill/。

前置条件：在 git 仓库里跑优化，先 commit 或 stash 本地改动，darwin.skill 才能干净地保留或回滚实验改动。

适合谁

角色 价值
Skill 开发者（60+ 个 Skill） 批量优化，自动回滚，不再手动维护
Claude Code / Codex 深度用户 提升日常使用 Skill 的输出质量
AI Agent 研究者 9 维度 rubric 可作为评估框架参考
团队 Skill 管理者 棘轮机制确保质量只升不降

不适合谁

  • 只有 1-2 个简单 Skill 的用户（手动改改就够了）
  • 没有 git 基础的用户（需要 git 操作能力）
  • 期望完全自动化的人（人在回路是核心设计，不是缺陷）

内链

评分

8.5/10

维度 分数 说明
概念创新度 9 autoresearch + SkillOpt 映射，棘轮机制新颖
功能完整度 9 5 阶段循环 + 9 维评估 + 人类检查点，设计完整
文档质量 8.5 SKILL.md 519 行/31KB，详尽但偏长
安装便捷度 9 一行 npx install，开箱即用
实测数据 8 有 controlled study，但样本有限（2 个 Skill）
社区认可 9 微软 SkillOpt 官方集成、5.8k Star
局限性 – SKILL.md 31KB 偏重、需要 git 基础、人在回路设计牺牲自动化

一句话总结：darwin.skill 是目前 Agent Skill 优化领域最系统的开源方案，微软官方背书 + autoresearch 灵感 + 9 维度 rubric 构成了扎实的理论基础。它的核心价值不在于”自动改 Skill”，而于”只保留可测量的改进”——棘轮机制让质量只升不降。

—

合规披露：本文基于 darwin-skill 公开 README、SKILL.md 及 Trendshift 数据撰写，未接受作者资助。