# superpowers里的四件刹车：开发者效率件横评 ## 概述 本栏开发者效率类横评的第三轮。前两轮把审查闸（pr-lens、内置四件）和调试外围（sentry、pcap、apk-reverse）扫过一遍，这期换一个挖法：不再扫市场找新面孔，而是回到已被拆过骨架的 superpowers 仓库内部，把它家四个开发纪律内件——test-driven-development、systematic-debugging、requesting-code-review、verification-before-completion——单独拎出来评。核心发现一句话：开发者效率赛道里最有效的件，几乎都不是加速器，而是刹车。它们不帮 Claude 多干活，专拦它天性里最想干的那几件事——抢进度直接写实现、没找根因就瞎改、宣布“做完了”却拿不出证据。 ## 评测对比表 | 件 | 功能完整度 | 设计质量 | 实战效果 | 上手难度 | 社区活跃度 | |---|---|---|---|---|---| | test-driven-development | ★★★★ | ★★★★★ | ★★★★ | ★★★★ | ★★★★ | | systematic-debugging | ★★★★ | ★★★★★ | ★★★★★ | ★★★★ | ★★★★ | | requesting-code-review | ★★★★ | ★★★★ | ★★★★ | ★★★★ | ★★★★ | | verification-before-completion | ★★★ | ★★★★ | ★★★★★ | ★★★★★ | ★★★★ | | gh-address-comments（点名件） | ★★★ | ★★★ | — | ★★★★★ | ★★★ | | notebook-fix（点名件） | ★★★ | ★★★ | — | ★★★★★ | ★★ | 说明：本期未采集实时 Star 数据，社区活跃度按母仓生态与装机存在感定性评估；两个点名件仅做了定位分析，实战效果列留空，留待后续实测补分。 ## 一个发现：效率件不含效率 把本栏拆过的开发者效率件排成一列，会发现一个反直觉的规律：卖得最好、被引用最多的，恰恰是那些“让 Claude 少做事”的件。 内置四件里的 code-review 和 simplify，本质是给已经写完的代码踩刹车；官方 webapp-testing 是让 Claude 写完必须自己跑一遍浏览器才许交差；而 superpowers 这个两度被本栏拆过骨架的仓库，干脆把“刹车”做成了产品主线——它的技能目录里，真正教 Claude“怎么写代码”的件很少，管“什么不许做”的件占了大半。 这不是巧合。Agent 写代码的真实瓶颈早就不是产出速度，而是产出质量的天花板：模型天生的冲动是直接写实现，因为那样“看起来进度最快”；是没找到根因就试着自己猜一个修法，因为猜对了可以立刻收工；是在测试没跑的情况下宣布完成，因为“应该没问题”是最省 token 的结束语。效率件的竞争，最后卷的全是谁能把这三条天性按得更死。 superpowers 的四个开发纪律内件，正好各按一条。下面逐个拆。 ## 四件逐个拆 ### test-driven-development：把红绿灯写进流水线 **定位**：测试闸的纪律件。它不教 TDD 理论——它假设你知道，然后在你想跳步的时候把你按回去。 **亮点**：整套设计围绕一条硬规则：没有看到一个测试先跑红，就不许写实现代码。流程被锁死在“写失败测试→跑红→写最简实现→跑绿→重构”的循环里，其中“最简实现”甚至允许作弊——先硬编码一个返回值糊弄过去，等下一个测试逼着你泛化。这个细节很懂行：它沿用的正是 TDD 社区里 Fake It 与三角定位的老惯例，而不是教科书式的完美主义。对 Claude 这种爱一次写一大坨的模型，等于把“进度感”重新定义成了“红灯变绿灯的次数”。 **短板**：对没有测试基建的老项目，循环的第一步“先让测试能跑起来”本身就是大工程，纪律件帮不上忙；纯 UI 和探索性代码里，先写测试的摩擦感会被放大。 ### systematic-debugging：修车的先看伤在哪 **定位**：调试闸的方法论件，本期评分最高的一件。 **亮点**：它的核心是一条对 agent 极其对症的禁令——没有找到根因之前，不许动修复代码。流程被拆成一段排除法流水线：先稳定重现，再收集证据定位根因，然后提出假设、用最小实验验证，证伪了就回到上一步，证实了才动手改。它把“快改快试、改到能跑为止”明确划成反模式，理由写得毫不客气：快修只是把根因盖住，账迟早要还。这套设计妙在它对冲的恰好是模型的弱点——语言模型猜答案的能力太强，强到会跳过“看伤”直接“开药”。 **短板**：纪律件共同的软肋它也有——它拦得住模型，拦不住坐在旁边说“你先试试改这一行”的人类。另外在真实事故里，“稳定重现”这一步经常就是最难的一步，件本身给不了太多帮助。 ### requesting-code-review：审查者必须换脑子 **定位**：审查闸的执行件，和 receiving-code-review 构成一对——一个管怎么挑刺，一个管怎么接刺。 **亮点**：设计上最值得抄的一手是审查者的产生方式：完成一个工作单元后，派一个全新的子代理来审，不带作者那套“我当然是对的”的上下文，只拿 diff 和需求清单逐条过。这等于用机制解决了审查最古老的顽疾——作者盲区。配套的 receiving 件管另一半：收到意见先逐条对着代码核实，对的改，错的要拿出证据反驳，不许无脑全收。两个件合起来，审查从“礼貌性互吹”变成了真有攻防的闭环。 **短板**：子代理再干净也是模型，挑出的多是清单内问题，人类审查者那种“这代码闻起来不对”的直觉它没有。清单写得有多好，决定它上限有多高。 ### verification-before-completion：最不起眼，最救命 **定位**：交付闸的纪律件，四件里最短、最不起眼，但实战效果我给满分。 **亮点**：规则简单到只有一句话——宣布“做完了”之前，必须先拿出证据：测试跑过没有、构建过没过、验收标准逐条核对没有。它直接命中 agent 最被诟病的行为模式：“嘴上完成”。本期把它放在重构与交付的质量位上评，是因为它守的正是最后一道关：前三个件保证了过程干净，它保证结果可验证。上手成本几乎为零，单文件即装，五颗星给得心安理得。 **短板**：它能验证的证据形式有限——测试全绿防不住需求理解错了，“按错误的需求正确地实现”是所有验证件的共同盲区。 ## 两个点名件 装机名单里还有两件开发效率件值得点名，本期只做定位分析。 **gh-address-comments**：名字即说明书——把 PR 上的审稿意见逐条处理成回复和提交。它补的正是上面审查闭环缺的最后一公里：requesting/receiving 管怎么审，它管审完之后怎么收尾。做这件事的件必然要处理三个设计点：意见归类（必须改、可争论、纯口味）、逐条留痕、改完回帖。它出现在装机清单里，说明“审查的下半场”已经有人占位，但还没有形成赛道。 **notebook-fix**：调试赛道里最没人抢的工位。此前调试位被 sentry（线上告警）、apk-reverse（移动取证）、pcap（网络分流）依次占满，唯独数据科学家每天面对的坏 notebook——内核状态错乱、cell 顺序依赖、输出残留——没专人管。注意它的名字用的是 fix 而不是 debug，说明定位是修理件而非方法论件：来了就修，不问人生意义。 ## 对照组：同一个词，两种物种 把这四件和已拆过的官方、内置件放在一起看，会发现一个词义分裂：官方 webapp-testing 把“测试”做成了执行件——写完代码后跑浏览器验证；superpowers 的 TDD 件把“测试”做成了纪律件——写代码之前先立规矩。内置 verify 同理，它是一个命令，verification-before-completion 是一条流程。前者回答“怎么检查”，后者回答“什么时候必须检查”。两套都值得装，但别指望互相替代——执行件管结果，纪律件管习惯。 ## 四件刹车装在哪条流水线上 ```mermaid flowchart TD A[接到开发任务] --> B[TDD件接管] B -->|没有失败测试| C[先写测试] C --> D[跑红] D --> E[写最简实现] E --> F[跑绿] F --> G[清理重构] G --> H[完成件验收] H -->|证据不足| C H -->|证据齐了| I[交付] A --> J[中途报错] J --> K[调试件接管] K -->|先别改码| L[重现并找根因] L --> M[假设加最小实验] M -->|证伪| L M -->|证实| E ``` ## 安装命令 四件都在 superpowers 仓库内，推荐整仓安装后按需取用： ```bash # 方式一：克隆后手动拷贝单个件（最通用） git clone https://github.com/obra/superpowers.git cp -r superpowers/skills/systematic-debugging ~/.claude/skills/ cp -r superpowers/skills/test-driven-development ~/.claude/skills/ cp -r superpowers/skills/requesting-code-review ~/.claude/skills/ cp -r superpowers/skills/verification-before-completion ~/.claude/skills/ # 方式二：按其 README 提供的插件市场方式整包装（以仓库当前说明为准） ``` ## 推荐排行榜 - **最值得立刻装**：systematic-debugging——四件里唯一能当场改变 agent 行为质量的，一句“先找根因再动手”值回票价 - **最被低估**：verification-before-completion——最短最土，但挡住的是最贵的错误 - **最成体系**：四件同装——TDD 件产出的失败测试，正好是调试件找根因后的第一个修复动作，纪律互相咬合 - **最值得蹲守**：notebook-fix——“审查的下半场”和“notebook 修理”两个工位都还没形成赛道，先占位的人还没被看见 - **最值得抄的设计**：requesting-code-review 的“换脑子”审查——用子代理机制消作者盲区，任何做 agent 审查流的人都该看一眼 ## 参考来源 1. [obra/superpowers](https://github.com/obra/superpowers) — 四件纪律内件所在仓库，本期主评对象 2. [anthropics/skills](https://github.com/anthropics/skills) — 官方对照组（webapp-testing 等）所在仓库 3. [mcpservers.org/agent-skills](https://mcpservers.org/agent-skills) — Agent Skills 目录，本栏长期观察源 4. [skills.sh](https://www.skills.sh) — Skills 生态榜单站，装机趋势参考 > [!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 等场景全覆盖。