验证层之前：审查与重构五件横评

概述

开发者效率这条链路，前几轮已经拆得很密：审查到调试的七件闭环、验证层的四件专评。但把时间轴再往前拨一格——改动刚写完、还没送进验证工序之前——还剩两道没人单独盘过的工序：审查（找出问题）与重构（清掉坏味道），外加审查的人类半环（接回评审意见）。本期横评就补这个空位，五件对象：

本期最核心的发现来自两个内构件的描述原文：官方把「对错」和「好坏」拆成了两个入口，并在描述层写了互相转诊的协议——这是整个生态里最教科书级的一次职责切分。

需要声明：本会话网页抓取与搜索通道同样未获授权，本期外部数据来自系统预抓取的 GitHub API 快照（2026-09-11），内置件描述原文取自本会话命令清单，装机件不做功能断言，评分为设计分析与可得证据的主观综合。

生态定位图：审查重构层卡在哪

flowchart TD
    W["Claude 写完一段改动"] --> RW
    RW["ripwire：找全该读的代码"] --> CR
    CR["code-review：审对错"] --> CO["发现清单"]
    CO -->|"--fix 修进工作区"| FX["修复后的工作区"]
    CO -->|"--comment 贴行内评论"| PR["PR 评论流"]
    CR --> SM
    SM["simplify：清坏味道"] --> FX
    HU["人类评审意见"] --> GAC["gh-address-comments 回评"]
    GAC --> FX
    GC["gh-cli：GitHub 操作底座"] --> PR
    FX --> V["验证层：上期四件"]
    V --> MG["合并"]

评测对比表

评分说明：内构件随 Claude Code 版本发布，无独立社区维度，按可得性与更新载体折算；两个装机件本机副本未暴露描述，功能与实战分按命名层与同族件类比折算，从严不给高分；ripwire 未实测，实战分按自述保守估计。

主拆一：code-review——把审查拆成三种动词形态

定位：Claude Code 内构件，随宿主发布。它的触发描述原文如下，值得逐句读：

Review the current diff for correctness bugs and reuse/simplification/efficiency cleanups at the given effort level (low/medium: fewer, high-confidence findings; high: broader coverage, may include uncertain findings). Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree after the review.

第一句的名词是使用场景。 审查对象被锚定在「the current diff」而不是整个仓库——全库审查是纸面功能，diff 审查才是日常高频动作。触发描述把使用场景写死在第一个名词短语里，这是技能描述写作的范本操作：模型读到的第一行，决定了它的注意力预算怎么分。

两类产出装在一句话里。 correctness bugs 归一边，斜杠并列的 reuse/simplification/efficiency cleanups 归另一边。官方在定义层面就把「审查」拆成了两个正交任务：找错与改好——这个切分正是下一件 simplify 存在的理由。

最罕见的一句：把查准率与查全率明码标价。 「低/中档：更少但高置信的发现；高档：覆盖更广、可能混入不确定项」。大多数作者不敢在描述里承认「我的高档位会输出不确定的发现」，觉得像自曝其短。实际上这句话干了两件事：对用户是免责声明——高档位输出不是判决书；对模型是校准指令——高档位运行时自动放宽置信门槛并在措辞上标注不确定。把统计学的 precision/recall 取舍翻译成一句用户能懂的人话，这是本期见到的最高水平的提示词工程。

两个 flag 是两种外延。 --comment 是输出通道参数：发现不再是会话里的文字，而是贴到 PR 的行内评论，直接进入人类评审的工作面；--fix 是动作参数，且注意原文的「after the review」——先出清单再修，不是边审边改，审计轨迹优先于效率。

于是这一件 Skill 实际上是三种形态：

一个名字、三个动词，靠参数而不是靠拆件承载——与生态里 -install/-use 双件语法是同一种注意力的两种分法：前者按动作分参数，后者按频次分文件。

主拆二：simplify——一行负面边界，值一次生态升级

定位：同为内构件，与 code-review 是官方钦定的搭档。触发描述原文：

Review the changed code for reuse, simplification, and efficiency, and then apply the fixes. Quality only — it does not hunt for bugs; use /code-review for that.

先看清单：三项全是质量，没有 correctness。 复用、简化、提效——它管的是「好不好」，明确不管「对不对」。

再看默认值：与 code-review 完全相反。 code-review 默认只读，它默认「apply the fixes」直接动手。官方用默认值给两件的危险性分了级：找 bug 的产出是意见，说错了浪费你两分钟；自动重构的产出是代码，改坏了污染你的工作区——所以后者反而配套了更谨慎的触发边界（只碰 changed code，不碰全库）。默认值即安全设计，这是装机即用的内构件才做得起的奢侈：社区件不敢默认动手，因为不知道用户的工作区长什么样。

最后是全文最值的一行：「Quality only — it does not hunt for bugs; use /code-review for that.」 这是负面边界加显式转诊的完整句式：先声明我不管什么，再指名道姓把需求转介给隔壁件。两个内构件在描述层互相引用，等于官方自己维护了一张职责地图。技能生态里最缺的从来不是功能而是边界——「都能做、都不精」的件互相抢触发权，用户措辞稍有偏差就调错件。边界写清楚，撞车才会消失。

为什么拆两件而不是塞一个开关？ 因为找 bug 的怀疑目光和清坏味道的整理目光是两种注意力。塞进同一次运行，审查者会顺手「修好」不该动的结构，重构者会漏掉藏在坏味道里的真 bug。拆开后每件描述都能短到两句，触发更准，产出也更可预期。

副拆：gh-address-comments 与 gh-cli——审查的人类半环和操作底座

gh-address-comments：address comments 直译「处置评论」，在 GitHub 语境里特指 PR 评审意见的回应闭环——逐条读意见、改代码、回帖说明、请求复审。它的生态价值在于：人类评审意见是审查工序里唯一无法自动生成的外部输入，这件 Skill 把这条输入流变成了 agent 的任务清单。它属于装机清单里的 gh- 前缀家族（gh-fix-ci、gh-cli、github-actions-skill）：gh 是 GitHub 官方 CLI 的命令名，前缀即签名，这一族的共同承诺是「直接操作 GitHub 的真实工作面」而非谈论 GitHub。短板要如实说：本机副本未暴露描述文本，触发边界未知；「处理一下 PR 评论」这类自然语言既可能落给它也可能落给通用件，命名层给的信心有限。

gh-cli：工具名即技能名。把 gh 上百个子命令与 flag 的组合经验封装成一件，省得 agent 每次现摸索。设计上是底座件——自己不定义工作流，只提供操作能力，工作流留给上层件（gh-fix-ci 管红灯、gh-address-comments 管回评）去编排。裸命名的代价是没有触发词优势：用户说「看看 PR」时，和它抢触发权的是所有名字里带 GitHub 的件。

编外一件：ripwire——审查的上游是检索

它所在的那份榜单本身也是个信号：前八名里六席是编码代理基础设施（terminal-code、deepseek-harness-desktop、x64dbg-mcp-server、stop-that-shit、moli、ripwire）。近 45 天的新供给正在向「给 agent 用的底层工具」集中，CLI+MCP 的编外件正在成为 SKILL.md 之外的第二条供给线。另外两个参照位次：obra/superpowers（285,175 星）与 affaan-m/ECC（256,298 星）本周仍压在 react 和 linux 之前——开发提效类是整个生态的头部引力区，但两件均已有专期，本期不展开。

一条流水线怎么拼

# 第 1 步：审对错（内构件，零安装）
/code-review              # 默认档：只出发现清单
/code-review --fix        # 审完把发现修进工作区
/code-review --comment    # 把发现贴成 PR 行内评论

# 第 2 步：清坏味道（内构件，只管质量不找 bug）
/simplify

# 第 3 步：接回人类评审意见（装机件，自然语言触发）
# 对 agent 说「把这条 PR 的评审意见逐条处理掉」，
# 触发词以该件 SKILL.md 为准（本机副本未暴露描述）
npx skills find gh        # 市场检索 gh- 前缀家族

# 第 0 步（可选）：检索层编外件，按仓库 README 安装并注册 MCP
git clone https://github.com/redhat-et/ripwire

顺序有讲究：先 code-review 后 simplify——先确认代码是对的，再去把它变漂亮；反过来跑，simplify 的自动重构可能把一个待修 bug 藏进更深的抽象里。

分维度排行榜

自写 Skill 可抄的四个模式

1. 负面边界句式：「X only — it does not Y; use /其他件 for that.」一句话同时完成免责与转诊，是治触发撞车最便宜的药。
2. 默认值分层：只读做默认，动手挂 flag，且写明动作发生在哪个之后（after the review）。
3. 档位与置信度挂钩：告诉用户高档位会有不确定发现——承认局限性反而校准了模型行为。
4. 对象锚定写进第一句：the current diff、the changed code——用名词短语把注意力预算钉在场景上。

诚实条款

参考来源

1. redhat-et/ripwire — 小而美榜第 8 位（1892 星），自述引自系统预抓取 GitHub API 快照（2026-09-11）
2. anthropics/skills — 官方示例件序列参照，内构件设计语系的出处
3. obra/superpowers — 全场热榜头部技能框架（285,175 星），开发提效类引力区背景
4. Nine coding harnesses vs. your laptop（HN 首页，152 分） — 编码宿主概念出圈的同期佐证
5. 本会话环境装机清单与 Claude Code 内置命令清单 — code-review、simplify 触发描述原文来源

[!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 等场景全覆盖。