首页 › skills-review › 八十万人在用:效率同门四件拆

八十万人在用:效率同门四件拆

概述

开发者效率的四个动词——审查、测试、重构、调试——在本栏目已各自有多轮横评,但有一个缺口直到今天才被对出来: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 万),规律浮出来了:内置层覆盖越薄的动词,市场件卖得越好。人类评审免费替你做了审查,但没人替你坚持先写测试、也没人替你还技术债。

生态定位图:四件套卡在流水线哪几环

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 内部结构的最合理推断——同门出品,大概率同一种写法。

同一赌注:生态顶部都在押「方法比工具值钱」

安装与使用命令

# 市场检索(四件同门,关键词直接命中)
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 单独开任务),避免双审查员打架。

分维度排行榜

给自写 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 等场景全覆盖。

51学通信知识星球海报-扫码加入