# 八十万人在用：效率同门四件拆 ## 概述 开发者效率的四个动词——审查、测试、重构、调试——在本栏目已各自有多轮横评，但有一个缺口直到今天才被对出来：skills.sh 总榜上安装量最高的两件效率 Skill，**improve-codebase-architecture（总榜 #5，82.6 万安装）和 tdd（总榜 #6，79.9 万安装）**，本栏目 150 多篇拆解里从未当过主角。它们与已拆过的 code-review（#77）、diagnosing-bugs（#60）同属一个套件，恰好一个动词一件。本文补上这两件的首拆，复评已拆两件，把四件放回同一条开发流水线里横拆一遍。核心发现：安装量排序重构＞测试＞调试＞审查，恰好与内置工具层的覆盖度成反比——**市场销量榜，本质是开发者自律缺口的排行榜**。 ## 为什么是这四件：一个一直没闭上的缺口 据本栏目 8 月 31 日期（引 skills.sh 2026-08-31 总榜），Matt Pocock 套件在效率赛道占着四个动词位：code-review（总榜 #77，44.5 万安装）、tdd（#6，79.9 万）、improve-codebase-architecture（#5，82.6 万）、diagnosing-bugs（#60，50.3 万），另有词汇层的 codebase-design 在 8 月 30 日期做过初评。这套件当时的定位是「通用方法论的第一层」。 此后本栏目把其中两件拆开了：8 月 30 日诊断了 diagnosing-bugs 的六道闸门和 code-review 的双轴分离；9 月 11 日的两篇 R3 又把内置工具件（code-review、simplify、verify、run）和官方测试件（webapp-testing）各横评了一轮。但 **#5 和 #6 这两个全场安装量最高的头部，反而始终没人开盖**——典型灯下黑：它们太「大路货」，每期都在别人的背景板里，从来没当过主角。 更值得注意的是一个结构性事实：Claude Code 出厂内置的效率件是 code-review、simplify、verify、run 这类**窄动词工具**——审查有内置、运行验证有内置、小范围清理有内置，但**测试纪律（tdd）和结构还债（architecture）没有内置对应物**。对照安装量排序（重构 82.6 万 ＞ 测试 79.9 万 ＞ 调试 50.3 万 ＞ 审查 44.5 万），规律浮出来了：内置层覆盖越薄的动词，市场件卖得越好。人类评审免费替你做了审查，但没人替你坚持先写测试、也没人替你还技术债。 ## 生态定位图：四件套卡在流水线哪几环 ```mermaid flowchart LR W["写下一个功能"] --> T["tdd：先红后绿"] T -->|红灯闸门：先看测试失败| I["最小实现"] I --> CR["code-review：双轴审查"] CR -->|发现缺陷| D["diagnosing-bugs：六道闸门"] D -->|根因修复| W CR -->|对但变脏| A["architecture：结构还债"] A -->|结构改善| W ``` ## 评测对比表 评分说明：满分 5 星加权（功能 25%、设计 25%、实战 20%、上手 15%、活跃 15%）。code-review 与 diagnosing-bugs 有 8 月 30 日的 SKILL.md 级拆解背书；tdd 与 improve-codebase-architecture 的 SKILL.md 本期未能逐行核验，评分基于市场信号与方法论结构推断，实战效果一项置信度最低。 | 维度（权重） | tdd | improve-codebase-architecture | code-review（复评） | diagnosing-bugs（复评） | |---|---|---|---|---| | 功能完整度（25%） | ★★★★ | ★★★ | ★★★★ | ★★★★ | | 设计质量（25%） | ★★★★ | ★★★ | ★★★★★ | ★★★★★ | | 实战效果（20%） | ★★★ | ★★★ | ★★★★ | ★★★★ | | 上手难度（15%） | ★★★★★ | ★★★★ | ★★★★★ | ★★★★ | | 社区活跃度（15%） | ★★★★★ | ★★★★★ | ★★★★ | ★★★★ | | **加权综合** | **4.1** | **3.5** | **4.4** | **4.3** | ## 主拆一：tdd——把纪律写成三道闸门 **定位**。总榜 #6、79.9 万安装——注意这是全品类排名，不是效率赛道内排名。一件没有任何 API、不接任何外部服务的纯方法论件，安装量压过了绝大多数办公和内容生成件，这本身是本期最大的信号。 **为什么 TDD 特别的适合被 Skill 化**。TDD 本来就是闸门形状的：红（先写一个失败的测试）、绿（最小实现让它通过）、重构（行为不变地清理）。每一道闸门都有机器可判定的谓词——「测试确实失败了」「测试确实通过了」「行为确实没变」。Skill 化不需要发明任何新能力，需要的是**拦住 agent 走捷径**：收到「加个功能 X」的指令时，模型的阻力最小路径永远是先写实现、测试后补甚至不补。tdd 这类件的价值全部在于把顺序锁死。 **设计上真正吃重的是红灯闸门**。如果 agent 写的测试一上来就通过，这个测试什么都没证明——你无法区分「功能对了」和「测试空转」。所以方法论层面的关键动作是「先亲眼看它失败」，这与官方 verify 的证据链主张（「跑起来观察行为」而非「声称改完了」）、以及 superpowers 系 diagnosing-bugs 第一阶段的反馈回路主张，三个互不相干的生态各自收敛到了同一句话上：**先观察失败，再谈成功**。这种跨生态趋同，比任何单件的宣传语都更能说明 2026 年效率 Skill 的主航道在哪。 **短板**。实战效果未经实测，只能给保守分；TDD 在无测试基建的遗留项目上有冷启动问题——没有测试框架时，第一道红灯都点不亮；另外据今日 HN 首页「RTK reports token savings, but our cost benchmarks disagree」（142 分）一帖，社区正在为「自报的收益与基准实测对不上」吵架——79.9 万安装是显示偏好，不是效率证明。 ## 主拆二：improve-codebase-architecture——「架构」这个词的验收难题 **定位**。总榜 #5、82.6 万安装，套件内最高，比 tdd 还多近 3 万。一个边界最难画的动词，卖得最好。 **为什么它压过所有同门**。我们的解读（标注为解读而非事实）：审查有免费的人类替代品，调试有内置证据链兜底，而「这个目录我不敢碰」是每个团队都有的沉默之痛——遗留系统的泥球没有人类评审对应物。82.6 万安装里相当比例，大概率是「装了就等于立了个还债的 flag」的许愿型安装。 **设计上的真问题**。「架构」是软件里最不可证伪的名词。tdd 有红绿灯，architecture 没有普适的红绿灯——它的 SKILL.md 必须回答：什么才算「改进了架构」的可接受证据？野外可行的答案包括循环依赖计数、分层违规数、耦合度、模块尺寸分布这类可机检指标；不可行的答案是「看起来更清晰了」。本期未能核验它选了哪条路，这是全文最大的存疑点。参考系摆在这里：官方 simplify 刻意把范围缩到只看「改动的代码」，还用一行负面边界写死「不找 bug，那是 code-review 的事」——9 月 11 日期我们说这行字「值一次生态升级」；而总榜 #5 反其道行之，做的是**全库级承诺**。全库范围恰恰是 stop-that-shit（9 月上旬拆过）要拦截的任务范围膨胀的高发区。一个范围最宽的件，比一个范围锁死的件更需要写死边界，它写没写，决定了它是还债工具还是翻车现场。 **短板**。功能与设计两项只能按中性偏保守给分；与内置 simplify 的分工（全库 vs 改动）没有官方说明，同时启用需要用户自己画界。 ## 副拆：已拆两件复评——套件的「房屋风格」 8 月 30 日的拆解给这两件留了可复核的档案。**code-review** 的招牌是双轴分离：正确性与整洁度分开打分、禁止合并排名，配合置信度分级（宁可少报、不报模糊发现）；**diagnosing-bugs** 的招牌是六道闸门：先脱敏（Redact）、再建反馈回路、然后最小化、可证伪、单变量，最后落到「缝」（seam）与复盘。加上词汇层 codebase-design，这套件的方法论是一致的：**把师傅的纪律翻译成可执行的闸门序列，每道闸门配一个可判定的谓词**。这也反过来支撑了对 tdd 内部结构的最合理推断——同门出品，大概率同一种写法。 ## 同一赌注：生态顶部都在押「方法比工具值钱」 ## 安装与使用命令 ```bash # 市场检索（四件同门，关键词直接命中） npx skills find tdd npx skills find improve-codebase-architecture npx skills find diagnosing-bugs npx skills find code-review # 按市场页给出的仓库地址装入技能目录后自然语言触发，例如： # 「用 TDD 流程加这个功能：先写失败的测试给我看，再最小实现」 # 「对这个模块做一次架构还债，先列出你认定的问题和证据」 ``` 内置件无需安装，斜杠即用：`/code-review`、`/simplify`、`/verify`。同装市场件与内置件时，建议口头约定分工（如：内置管本次 diff、tdd 管流程、architecture 单独开任务），避免双审查员打架。 ## 分维度排行榜 - **综合加权**：code-review（4.4）＞ diagnosing-bugs（4.3）＞ tdd（4.1）＞ improve-codebase-architecture（3.5） - **设计质量**：code-review ＝ diagnosing-bugs ＞ tdd ＞ improve-codebase-architecture - **社区热度**：improve-codebase-architecture（#5）≥ tdd（#6）＞ diagnosing-bugs（#60）＞ code-review（#77） - **现在就装**：tdd——纪律增量最确定，零依赖，红灯闸门的收益不依赖任何技术栈 - **观望等实测**：improve-codebase-architecture——安装量冠军，但验收标准未核验，建议等它用可机检指标自证后再放进重要仓库 ## 给自写 Skill 作者的三条抄作业 1. **把纪律写成闸门，每道闸门配机器可判定的谓词**。「先写测试」是愿望，「测试先失败」是谓词；头部件与平庸件的分界线就在这里。 2. **双轴分离，禁止合并排名**。正确性和整洁分开打分，模糊发现宁可不报——code-review 用这一条把审查从「一堆感想」变成「两列结论」。 3. **范围用否定句写死**。simplify 的「不找 bug」一行值一次生态升级；凡是architecture 这类宽动词，缺了否定句边界就等于没装刹车。 ## 诚实条款 ## 参考来源 > [!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 等场景全覆盖。