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