写代码的那一步，AI 已经很快了；真正拉开差距的，是「改完之后」——找虫、瘦身、验收。本期是开发者效率类横评的第三轮，选了五件在真实装机环境里跑过的 Skill：superpowers 系的三件方法论件（test-driven-development、systematic-debugging、verification-before-completion），官方示例库的 webapp-testing，以及随产品内置的 simplify（连带它的两位同事 code-review 和 verify）。核心发现一句话：开发者效率件的竞争，早已不在功能多少，而在「防跳步」的纪律设计——谁能让模型不抄近路，谁就赢。
| 件 | 功能完整度 25% | 设计质量 25% | 实战效果 20% | 上手难度 15% | 社区活跃 15% |
|---|---|---|---|---|---|
| test-driven-development | ★★★★ | ★★★★★ | ★★★★ | ★★★★ | ★★★★★ |
| systematic-debugging | ★★★★ | ★★★★★ | ★★★★★ | ★★★★ | ★★★★★ |
| verification-before-completion | ★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★★ |
| webapp-testing | ★★★★ | ★★★★ | ★★★ | ★★★ | ★★★★ |
| simplify（内置） | ★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★ |
superpowers 系的这件，管的是「测试」这个环节里最反人性的一步：逼 AI 先写测试，再写实现。它的正文把流程锁成三拍——先写一个会失败的小测试，跑一遍、亲眼看它红；再写实现，且只许写到刚好让测试变绿；最后才轮到重构。三条规矩翻成大白话就是：没有红过的测试不算测试，没有测试护着不许动产码，实现不许「顺手多写」。
亮点在于它针对的正是模型最高频的坏习惯：一口气把测试和实现同时写出来，然后「证明自己正确」。一旦测试和实现出自同一只手、同一个念头，测试就成了摆设——它只会验证你已经相信的东西。这件 Skill 的价值不是教 Claude 什么是 TDD（它早就会），而是把顺序用祈使句钉死，让「先红后绿」变成不可跳的闸口。
短板也在这：纪律是文化成本。如果你的项目本来没有测试习惯，装上它之后 Claude 会先给你补一墙测试，第一周会显得「变慢了」。它适合长期项目，不适合一次性脚本。此外单件不单独分发，得跟 superpowers 整包走，这是上手成本里最重的一项。
调试环节的王者，也是本期实战效果唯一打到五星的一件。它的正文把调试锁成四个阶段，大意是：第一阶段只许调查——读报错原文、稳定复现、查最近改了什么、列出候选假设，不许动代码；第二阶段找参照，在同一个代码库里找一个正常工作的相似例子做对比，看差异在哪；第三阶段做最小实验验证假设，一次只验一个；第四阶段才许修，且只修根因，不许糊症状。
它最狠的一句规矩，大意是：「如果修法看起来显而易见，停下来」——先证明根因，再谈修法。这精确命中了 AI 调试的经典翻车姿势：看到一个报错，条件反射地猜一个原因、改一行、没好、再猜。三轮回合下来，代码改了七处，报错纹丝不动。这件 Skill 用流程把「猜」这个动作挤了出去。
设计上它和 TDD 是一对：调试完根因，回归测试补上；测试意外红了，切进四阶段排查。两件之间有明确的接力关系，这是 superpowers 系最值得抄的写法——Skill 之间不抢活，交接。
短板：四阶段对琐碎小虫是杀鸡用牛刀，改个 typo 也要走全流程会显得啰嗦。它的 description 里给了触发边界（遇到 bug、测试失败、非预期行为时用），实践中建议你在调用时自己把把关。
这件最小，也最特别：它只有一件事——重新定义「完成」。来历很有名：作者 Jesse Vincent 写它，是因为 Claude 总在任务最后一步宣布胜利，而实际没跑过任何验证。于是这件 Skill 把规矩立成：不许说「应该可以」，完成 = 有证据，证据 = 你亲自跑过的命令和它的输出；「没跑过，就不知道」。
亮点在于它揭示了 SKILL.md 写法里最便宜也最有效的一招：模型的能力你改不动，但模型对词的定义你改得动。把「完成」这个词的定义改掉，行为就跟着变了。整件没有一个脚本、没有一行代码，纯文字，却是 superpowers 里被转述最多的一件。
短板是功能面窄——它不帮你验证，只逼你验证。真正的「怎么跑起来看」它不管，得配合下一节提到的 verify 或 webapp-testing。单独装它像请了一位只喊口号的监工，配全套才发力。
同样管验收，anthropics 官方示例库里的 webapp-testing 走的是另一条路：不立规矩，给家伙。它的 SKILL.md 主文很短，教的是一套浏览器测试作业：把本地服务起起来、等端口就绪、用 Playwright 驱动真实浏览器走页面流程、断言结果。细节不在主文里——常见场景（登录、填表、导航、提交）的测试配方放在引用文件里，辅助脚本放在 scripts 目录，用到哪层加载哪层。
这是渐进式披露的教科书写法：主文保持极短，保证触发后不吃掉太多上下文；配方和脚本按需读取。对比 superpowers 的「先锁纪律」，官方示例件的哲学是「给工具和菜谱，信任执行者」。
短板在实战：它依赖 Playwright MCP 或本机浏览器环境，环境一塌（端口占用、无头模式配置、CI 里没有浏览器），Claude 会在工具层反复碰壁，配方再好也使不上。它的定位是「单页应用的功能流验收」，对纯后端、CLI 工具的验收无能为力——那种场景内置的 verify 更对路。
内置件上期拆过触发面的分工（描述里互相让路），这次换看行为面。simplify 的描述是一串名词：reuse、simplification、efficiency、altitude——复用、化简、效率、层级——然后一句「then apply the fixes」：直接动手改，不是开清单。四个名词就是它的全部世界观，尤其 altitude 这刀最有意思：它管「代码写在了错误的抽象层级」——比如在一个工具函数里硬编码业务常量、在路由层里写解析逻辑。这类问题不算 bug、不碰性能，传统 review 很容易放过，却是代码腐化的主航道。
它的边界划得极硬：明确声明不找虫，找虫去找 /code-review。而 code-review 那边的出口设计更见功力，描述原文写得很清楚：「Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree after the review」——发现只报告，落不落地由你选档：--comment 把发现贴成 PR 行内评论，--fix 才落回工作区。档位还有粗细：低档少而准，高档广而杂，连不确定的发现也报上来让你自己筛。
第三位同事 verify 管验收：描述里写明是「跑起来看行为」——起应用、等就绪、用 Playwright 驱动，测试结果不够时用它补人肉验收的洞。三件合起来，正好覆盖改完代码之后的三个动作：找虫（code-review）、瘦身（simplify）、验收（verify），每件一刀，互不越界。
短板：内置件随产品分发，社区层面没有独立仓库可追更新，出了不合预期的地方你只能等下个版本。自由度换省心，值不值看你。
把五件摊开，会发现开发者效率件其实只有两种物种。方法论件（superpowers 系）的赌注是：模型的毛病是跳步，所以 SKILL.md 的主体是流程闸口和禁令句式，全文几乎零脚本。动作件（官方示例、内置）的赌注是：模型缺的是手，所以主体是工具链、配方和脚本，纪律只留最少。两派不冲突——写自己的 Skill 时，先问一句「我的模型到底缺纪律还是缺手」，比堆功能重要得多。
flowchart TD
subgraph L1["方法论件：锁纪律"]
A["test-driven-development"]
B["systematic-debugging"]
C["verification-before-completion"]
end
subgraph L2["动作件：给工具"]
D["webapp-testing"]
E["verify 内置"]
end
subgraph L3["窄刀件：一刀清"]
F["code-review 内置"]
G["simplify 内置"]
end
五件串成一条真实工作流是这样：
flowchart TD
A["改完代码"] --> B{"下一步交给谁"}
B -->|先找虫| C["code-review"]
B -->|先瘦身| D["simplify"]
B -->|心里没底| E["verify 跑起来"]
C -->|发现要修| F["--fix 落回工作区"]
F --> D
C -->|只报告| G["--comment 贴上PR"]
D --> E
E -->|行为不对| H["systematic-debugging"]
E -->|行为符合预期| I["收工"]
H --> A
注意这条流里 verification-before-completion 不在节点上——它不是步骤，是底噪，挂在每次说「完成」的关口。
# superpowers 整包装（含 TDD、systematic-debugging、verification 三件）
# 在 Claude Code 会话里执行：
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
# webapp-testing（从官方示例库拷进个人技能目录）
git clone --depth 1 https://github.com/anthropics/skills
cp -r skills/example-skills/webapp-testing ~/.claude/skills/
# 浏览器驱动（若尚未配置 Playwright MCP）：
claude mcp add playwright -- npx @playwright/mcp@latest
# 内置三件无需安装，直接斜杠调用：
# /code-review（可加 --comment 或 --fix）
# /simplify
# /verify
具体目录名与安装参数以各仓库 README 为准；webapp-testing 的库内路径如与上文不符，以仓库实际层级为准。
防跳步纪律榜：systematic-debugging ＞ test-driven-development ＞ verification-before-completion。三件恰好对应 AI 写码的三大翻车点：瞎猜根因、自证测试、空口宣布完成。
开箱即用榜：simplify 与 verify（零安装）＞ verification-before-completion ＞ TDD ＞ webapp-testing。越靠前的越不需要环境配合。
最值得抄进自写 SKILL.md 的写法榜：systematic-debugging 的阶段锁（每个阶段只许一类动作）、TDD 的绝对禁令句式（没有红就没有绿）、verification 的定义改写法（改一个词的定义胜过十行解释）、webapp-testing 的资源分层（主文短、配方外挂）。四招都是零成本可搬的。
综合首选：如果你只装一件，装 systematic-debugging——调试是 AI 效率损耗最大的环节，也是这件做得最透的环节。如果你只想要零成本，用内置三件套跑熟「审查-瘦身-验收」循环，再考虑补方法论件。
开发者效率件这个货架，上半年还以「多合一全家桶」为主流，如今存活得最好的反而是单职责小件：一件只堵一个跳步点，或者只递一把刀。这符合 Skill 这个形态的物理限制——SKILL.md 是挤进上下文的常驻客，谁占地谁死。写你自己的效率件之前，先看看这五件怎么用四百字正文管住一个模型，比看一百个全家桶有用。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。