本期是 Skills 生态拆解第 3 轮，主题是开发者效率类。此前几轮已经拆过 TDD、webapp-testing、调试六件和“改完代码三道关”，本轮全部换新面孔，聚焦一个此前没正面碰过的赛道：代码审查。核心发现是：审查类技能已经长出了三个明显不同的“门派”——内置在 Claude Code 里的即席快刀、以 superpowers 为代表的流程协议派、以及住进 CI 流水线的守门派。三派不是替代关系，而是部署位置不同。本期不报具体的星数与安装量——这类数字过期太快，评测只看设计、流程与社区信号。
一个 diff 从写完到合入，审查可能发生在三个完全不同的位置：
/code-review、/simplify、/verify。三派的分工可以这样看：
flowchart TD
A["改完代码"] --> B["会话内即席审"]
B --> B1["内置 code-review"]
B --> B2["内置 simplify 清理"]
A --> C["流程内协议审"]
C --> C1["superpowers 双联件"]
C --> C2["testing-anti-patterns 补测"]
A --> D["真机验证"]
D --> D1["内置 verify"]
A --> E["流水线门禁"]
E --> E1["security-review Action"]
E1 --> F["合入 main"]
看懂这张图，你就明白为什么“装了哪个审查 Skill”是个伪问题——真正的选型问题是“我的 diff 在哪个位置缺人盯”。
评分维度与权重：功能完整度 25%、设计质量 25%、实战效果 20%、上手难度 15%（分越高越容易）、社区活跃度 15%。
| 选手 | 赛道 | 功能完整度 | 设计质量 | 实战效果 | 上手难度 | 社区活跃 | 综合 |
|---|---|---|---|---|---|---|---|
| superpowers 评审双联件 | 代码审查 | ★★★★★ | ★★★★★ | ★★★★ | ★★★★ | ★★★★★ | 4.7 |
| 内置 /code-review（含 /security-review） | 代码审查 | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★★ | 4.3 |
| claude-code-security-review（Action） | 流水线守门 | ★★★★ | ★★★★ | ★★★★ | ★★★ | ★★★★ | 3.9 |
| 内置 /simplify | 重构清理 | ★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★★ | 4.1 |
| 内置 /verify | 真机验证 | ★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★★ | 4.1 |
| superpowers · testing-anti-patterns | 测试元技能 | ★★★ | ★★★★★ | ★★★★ | ★★★★ | ★★★★ | 4.0 |
| superpowers · using-git-worktrees | 重构安全网 | ★★★★ | ★★★★ | ★★★★ | ★★★★ | ★★★★ | 4.0 |
仓库是 github.com/obra/superpowers，作者 Jesse Vincent（GitHub ID obra），这是社区侧最出名的技能全家桶——本报系此前统计过，光其中 TDD 一件的安装量就到了 72 万次的量级，是 skills.sh 榜单上的常客。但全家桶里最值得玩味的不是 TDD，而是这一对：requesting-code-review（求审） 和 receiving-code-review（受审）。
亮点：市面上绝大多数“code review skill”只解决了一半问题——怎么审。这家的做法是把另一半也写成了技能：怎么被审。求审件负责把变更上下文打包、派出评审；受审件负责接住评审意见、逐条查证、决定改还是不改。两件配套，构成一个完整的评审回合。
短板：它是“协议”不是“工具”，意味着你必须走完它的流程才能吃到红利；如果你只想要提交前 30 秒扫一遍 diff，这套仪式就显得重。另外全家桶安装（数十个技能同时上场）对上下文的占用不小，新手建议单拆这两件用。
综合评分 4.7，本期榜首。第四、五节做逐段拆解。
Claude Code 现在自带一整套评审件：/code-review 对当前 diff 找正确性 bug，力度分 low/medium/high 三档——低力档刻意做得“少而准”，高力档撒大网；--fix 顺手修，--comment 直接发到 PR 上。旁边还有 /security-review 管安全项、/review 管常规走查。这一整套不装不配，随 CLI 更新。
亮点：零安装成本是压倒性的。大多数人第一次给代码做 AI 审查，用到的就是它，而它给的结果已经够用：找的是“会出事的 bug”，不纠缠风格。力度分档是个被低估的设计——默认不烦人，要深挖时再调高。
短板：即席工具的天生边界——审的是“这个 diff”，不是“这个仓库的习惯”；没有评审回合的概念，审完你改不改、改得对不对，它不管。这正是双联件补位的空间。
Anthropic 官方还有一个容易被忽略的形态：github.com/anthropics/claude-code-security-review，一个 GitHub Action。配置好 ANTHROPIC_API_KEY 后，PR 一开自动跑安全审查，发现可疑点直接以 review comment 形式钉在对应代码行上。
亮点：它代表了审查的第三种部署位置——异步、强制、留痕。前两派都依赖“人记得去审”，这一派不依赖：门禁就在 CI 里，绕不过去。对开源项目尤其有价值，外来的 PR 没有作者盯着，机器人是唯一必然到场的评审员。
短板：只管安全这一个剖面，正确性与设计问题不在射程内；配置要动 workflow、管密钥权限，上手成本明显高于会话内命令；每次 PR 审查都烧 API 额度，私有仓库大规模用之前得算笔账。
simplify 的官方描述写得极其克制：只做三类清理——复用（有现成的轮子别重造）、简化（绕弯的逻辑拉直）、效率（明显的性能账），然后动手改。注意它明确不做的事：不找 bug。找 bug 是 /code-review 的地盘。
亮点：这个“不做什么”的边界画得非常好。清理和纠错混在一条命令里，是 AI 改代码最常见的翻车姿势之一——说是清理，顺手“修”出一个行为变更。simplify 把两件事切开，各自归位，这是本期所有选手里最值得抄进自家 SKILL.md 的设计决策。
短板：覆盖面窄是自觉选择的代价。深度重构（拆模块、改架构）不在它的能力范围，那类活儿目前还没有哪件 Skill 能独立兜住。
verify 解决的是另一个环节的信任问题：改完了不等于改好了。它的做法是让你把项目真正跑起来，观察实际行为，确认变更生效——而不是盯着代码“看起来对”就宣布完成。
亮点：它攻的是 AI 写码最常见的自欺点——静态推理代替动态验证。“测试都绿了”和“功能真的工作”之间的鸿沟，靠这一件来填。对没有测试覆盖的存量项目，它是唯一的验货手段。
短板：能跑起应用是前提，前端项目、有环境依赖的服务，跑起来的成本本身就高；它也不产出可复用的回归验证，验完一次，下次变更还得重验。
superpowers 全家桶里还有一类“实践件”，testing-anti-patterns 是其中代表。它不帮你写测试，而是列出一串看起来在测试、其实在自欺的反模式——最典型的一条：测了 mock 的行为而不是真实行为，测试全绿但生产爆炸。同类还有 condition-based-waiting（别用 sleep 等异步，等条件成立）等。
亮点：这是测试赛道里稀缺的“元层”供给。TDD 教你先写测试（本报系已拆过），webapp-testing 教你端到端怎么测（也已拆过），而这件管的是“你的测试本身是不是假的”。设计上是清单式的，短小、可全量读进上下文，性价比极高。
短板：不产出任何自动化动作，纯认知输入；对没有测试文化基础的团队，光读清单未必能落地。
重构类技能里真正成熟的不多，superpowers 的做法值得注意：它不写一个“refactor 技能”，而是给了一个环境件——用 git worktree 把大改动隔离到一个平行工作目录里，主目录不动，改砸了直接弃船。
亮点：把“重构安全”从“小心一点”这种嘱咐，变成一个可执行的环境操作，这是工程直觉好的作者才有的写法。与 TDD、评审双联件配合使用时，体验是连贯的：开平行目录→测试驱动地改→审→合回。
短板：worktree 本身有学习成本，对 git 不熟的人是新增概念；单人小改动用它属于杀鸡用牛刀。
横评看热闹，拆解看门道。双联件值得逐段讲，因为它回答了一个所有 AI 评审工具都绕不开的问题：评审员和被评审者不能是同一个人格。
requesting 和 receiving 分开，对应两种完全不同的失败模式。求审侧的失败是“走过场”——自己人审自己人，一眼假；受审侧的失败是“照单全收”——评审员说什么就改什么，把对的改错。一个技能管不住两个方向的病，所以拆开，各治各的。
flowchart TD
W["主Agent写完代码"] --> R["触发求审件"]
R --> P["打包变更上下文"]
P --> S["派出干净子Agent评审"]
S --> L["逐条核对产出清单"]
L --> G["按严重度分级 只报不改"]
G --> B["主Agent触发受审件"]
B --> V["逐条对照代码查证"]
V -->|"真问题"| F["修复并补证据"]
V -->|"误报不适用"| X["说明理由驳回"]
F --> D["验证件收尾"]
求审件的核心动作是派一个没参与写这段代码的子 Agent 去审。这不只是省上下文——主会话的 Agent 写过这行代码，对它有“作者立场”，会不自觉地为自己辩护。新鲜的子 Agent 没有这层包袱，它只看代码本身。这个设计把人类工程里“让作者之外的同事来审”的制度，翻译成了子 Agent 机制。
评审结果被约束成结构化输出：每条发现带严重度（大致是 Critical / High / Medium / Low 四级）、带文件与行号，并且只报告、不动手——修复权留给主 Agent。职责切干净：评审员的信用来自“说得准”，修改者的信用来自“改得对”，混在一起两边的账都算不清。
受审件给主 Agent 立的规矩大意是：收到每条意见，先去代码里核对是否属实，是真问题才改；不属实、或“技术上对但这里不适用”的，明确驳回并说明理由。这一条防的是 AI 最隐蔽的弱点——权威服从。人类评审意见自带光环，模型倾向于顺着改，哪怕意见本身看走眼了。把“驳回”写成合法甚至受鼓励的动作，是这件技能里最有实战价值的一句。
superpowers 家技能的一贯写法：SKILL.md 的 description 不写“我是什么”，而写“什么场景该用我”——写完一段不小的改动、准备提交之前，这类条件一到，Claude 自动把技能拉起来。用户不需要记命令。这是技能区别于斜杠命令的关键设计：技能找时机，命令等你敲。
双联件不是孤岛：往前接 TDD（先有测试兜底）、接 verification-before-completion（完成前拿证据），往后接验证件收尾。全家桶真正的产品形态其实是一条流水线，双联件是其中“质检”工位。单拆两件也能用，但它的完整价值要在链条里才看得出来。
一句话总结这套设计：它没有发明更聪明的评审员，它发明的是让评审结果被正确对待的程序正义。
superpowers 全家桶（含评审双联件、TDD、调试件等）：
npx skills add obra/superpowers
只想要评审双联件，去仓库 skills/ 目录把 requesting-code-review、receiving-code-review 两个文件夹拷进项目的 .claude/skills/ 即可——技能就是明文 markdown，拷贝即安装，改它也是直接改文件。
内置件：无需安装，Claude Code 里直接敲：
/code-review # 审当前 diff，可加 --fix / --comment
/security-review # 审安全项
/simplify # 只清理不纠错
/verify # 跑起来亲眼验证
流水线守门（claude-code-security-review，按官方仓库 README 接法大意如下）：
# .github/workflows/security.yml
- uses: anthropics/claude-code-security-review@main
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
/code-review —— 零安装，随 CLI 走，今天就能用。/simplify 的“不找 bug”边界声明。/verify + testing-anti-patterns —— 一个验真机，一个验测试本身。这一轮看下来，审查赛道给所有想写 Skill 的人一个启示：工具型技能的天花板是“更快地做某件事”，协议型技能的天花板是“防止某类人犯错”。内置命令选了前者，把单点做到顺手；双联件选了后者，把一套评审文化写成 markdown。而真正缺人的位置，往往是第三种——流水线里那个不需要被提醒的守门员。你自己的仓库缺哪一派，答案在 diff 被合入之前的那 24 小时里。
[!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 等场景全覆盖。