<!-- title: 验证层之前：审查与重构五件横评 -->

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

## 概述

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

| 代号 | 身份 | 证据强度 |
|------|------|---------|
| code-review | Claude Code 内构件 | 有触发描述原文，可逐行拆 |
| simplify | Claude Code 内构件 | 有触发描述原文，可逐行拆 |
| gh-address-comments | 社区/装机件 | 仅命名层，本机未暴露描述 |
| gh-cli | 社区/装机件 | 仅命名层，本机未暴露描述 |
| redhat-et/ripwire | 编外件（CLI+MCP） | 仓库自述可引，未经实测 |

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

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

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

```mermaid
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["合并"]
```

## 评测对比表

| 维度（权重） | code-review | simplify | ripwire | gh-address-comments | gh-cli |
|---|---|---|---|---|---|
| 功能完整度（25%） | ★★★★☆ | ★★★★☆ | ★★★★☆ | ★★★☆☆ | ★★★☆☆ |
| 设计质量（25%） | ★★★★★ | ★★★★★ | ★★★★☆ | ★★★★☆ | ★★★☆☆ |
| 实战效果（20%） | ★★★★☆ | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ |
| 上手难度（15%） | ★★★★★ | ★★★★★ | ★★★☆☆ | ★★★★☆ | ★★★★☆ |
| 社区活跃度（15%） | ★★★★☆ | ★★★★☆ | ★★★★☆ | ★★★☆☆ | ★★★☆☆ |
| **加权总分** | **4.40** | **4.20** | **3.65** | **3.40** | **3.15** |

评分说明：内构件随 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 实际上是三种形态：

| 调用形态 | 默认行为 | 产出去向 |
|---|---|---|
| `/code-review` | 只读，出发现清单 | 当前会话 |
| `/code-review --comment` | 只读 + 外发 | PR 行内评论 |
| `/code-review --fix` | 读 + 改 | 工作区直接落盘 |

一个名字、三个动词，靠参数而不是靠拆件承载——与生态里 `-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 之前——开发提效类是整个生态的头部引力区，但两件均已有专期，本期不展开。

## 一条流水线怎么拼

```bash
# 第 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 藏进更深的抽象里。

## 分维度排行榜

| 榜项 | 第一名 | 一句话理由 |
|---|---|---|
| 综合加权 | code-review（4.40） | 三形态、档位明码标价、diff 锚定 |
| 设计质量 | simplify（5 分并列） | 负面边界+显式转诊，生态级接口示范 |
| 上手友好 | 两内构件（并列 5） | 零安装，敲斜杠即用 |
| 增长势头 | ripwire | 45 天 1892 星，编外供给线代表 |
| 老手搭档 | gh-address-comments | 把人类评审流变成任务清单 |

## 自写 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](https://github.com/redhat-et/ripwire) — 小而美榜第 8 位（1892 星），自述引自系统预抓取 GitHub API 快照（2026-09-11）
2. [anthropics/skills](https://github.com/anthropics/skills) — 官方示例件序列参照，内构件设计语系的出处
3. [obra/superpowers](https://github.com/obra/superpowers) — 全场热榜头部技能框架（285,175 星），开发提效类引力区背景
4. [Nine coding harnesses vs. your laptop（HN 首页，152 分）](https://news.ycombinator.com/item?id=49651221) — 编码宿主概念出圈的同期佐证
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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
