<!-- title: 官方三闸横评：描述里互相让路 -->

# 官方三闸横评：描述里互相让路

## 概述

Skills 生态的观察写到这个阶段，市场侧的货架已经足够拥挤——skillsmp.com 收录了超过 2300 个 Skill，mcpservers.org 和 skillsdirectory.com 各自维护着经过筛选的目录，skills.sh 的热门榜每周都在换血。但真正值得逐行拆的，反而是随 Claude Code 本体分发的三件内置效率件：`/code-review`、`/simplify`、`/verify`。本文把三件的官方描述原文逐段拆开，做一次开发效率赛道的横向评测。核心发现只有一句话：**这三件最值钱的设计不在正文里，而在描述（description）里——它们用“让路条款”互相划分地盘，而且其中有一条路让出去之后，没人接住。**

## 一、先看三段原文

拆 Skill 到家，就是把描述当合同读。以下是三件内置效率件的官方描述原文，一字未改。

**第一件，找茬岗 /code-review：**

> 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, may include uncertain findings). Pass --comment to post as inline PR comments, or --fix to apply the findings to the working tree.

三十八个词，写了五件事：范围（current diff，只看改动，不扫全库）、职责（correctness bugs 加三类清理项）、档位（low/medium 少而准，high 广而杂但可能混入不确定项）、交付形态一（`--comment` 贴成 PR 行内评论）、交付形态二（`--fix` 直接改工作区）。

**第二件，收拾岗 /simplify：**

> Review the changed code for reuse, simplification, efficiency, and altitude cleanups, then apply the fixes. Design quality is out of scope for this skill; use /code-review for that.

同样短。前半句认领四类清理——复用、简化、效率、层次（altitude）——并且明确“then apply the fixes”，动手改，不是只报告。后半句是全文最值钱的十一个词：**"Design quality is out of scope for this skill; use /code-review for that."** 设计质量不在本件职责内，去看 /code-review。这是一条标准的让路条款（routing clause）。

**第三件，验收岗 /verify：**

> Verify that a code change actually does what it's supposed to by running the app and observing behavior. Use when asked to verify a PR, confirm a fix works, test a change manually, check that a change works in the real app (not just tests), or to validate local changes before pushing.

前半句给出方法论：跑应用、观察行为，用实证代替推断。后半句一口气罗列了五个触发场景：验证 PR、确认修复生效、手动测试、真机验证（括号里特意补刀“不只是跑测试”）、推送前本地校验。

## 二、评测对比表

评分维度沿用本栏目的固定权重：功能完整度 25%、设计质量 25%、实战效果 20%、上手难度 15%（星级越高越友好）、社区活跃度 15%。三件均为内置，随主程序更新，无独立仓库指标可考，社区活跃度按官方维护强度计。

| Skill | 功能完整度 | 设计质量 | 实战效果 | 上手友好 | 社区活跃 | 加权总分 |
|-------|-----------|---------|---------|---------|---------|---------|
| /code-review | ★★★★★ | ★★★★★ | ★★★★☆ | ★★★★★ | ★★★★☆ | **4.75** |
| /simplify | ★★★★☆ | ★★★★★ | ★★★★☆ | ★★★★★ | ★★★★☆ | **4.63** |
| /verify | ★★★★☆ | ★★★★☆ | ★★★★★ | ★★★★☆ | ★★★★☆ | **4.45** |

三件总分咬得很紧，差距全在设计细节和适用前提上。下面逐件展开。

## 三、逐件拆解

### /code-review：把“不确定性管理”写进触发词的找茬岗

定位是审查当前 diff 里的正确性 bug 和清理项。它最聪明的一处设计，是把召回率与精确率的权衡直接做成了档位参数：low/medium 档“fewer, high-confidence findings”，high 档“broader, may include uncertain findings”。翻译成人话：低档少报但条条可信，高档多报但你得自己筛。这个权衡本来是所有代码审查工具的内部难题，它直接把选择权交还给调用者，并且在描述里就把预期管理好了——你选 high，就别抱怨有噪音。

第二个亮点是动作分级。默认行为是只出报告，`--comment` 才把发现项贴到 PR 行内，`--fix` 才允许它碰你的工作区。三个交付层级，风险逐级上升，越权的动作全部藏在显式旗标后面。这是“AI 动手类工具”该抄的标准答案：默认只读，写入须明示。

短板也有：它管找、顺手提清理项，但描述里没有任何“测试”字样——审查完的代码对不对，它不背书。

### /simplify：独门绝活是"altitude"，死穴是没接住的球

定位是专职收拾工：复用、简化、效率、层次四类清理，而且是“then apply the fixes”——发现问题直接改，不像 code-review 默认只动嘴。对不想逐条确认的使用者，这是一条龙的爽点；代价是它默认就写你的代码，风险偏好低的人要先想清楚。

它真正的灵魂词是 **altitude（层次）**。前两类清理是所有 linter 都懂的常识，层次清理却是纯提示词工程产物：识别“在错误的抽象层级解决问题”的代码——比如在调用方层层补 if，而该改的是被调方的契约。这类坏味道没有任何静态规则能抓，只有语言模型能判断，是这个 Skill 不可替代的部分。

短板恰恰是那条让路条款。它说“设计质量归 /code-review 管”，但回头查 /code-review 的描述，人家认领的是"correctness bugs and reuse/simplification/efficiency cleanups"——正确性 bug 加三类清理项，通篇没有一个词提到设计质量。**球传出去了，没人接。** 使用者若真的拿着设计质量问题去敲 /code-review 的门，按描述字面理解，对方并不欠他一次解答。

### /verify：唯一能抓住“测试全绿但跑不起来”的岗位

定位是验收员，方法论写在描述第一句：running the app and observing behavior。它和前两件有本质区别——code-review 和 simplify 看的是文本，verify 看的是行为。测试全绿、审查零发现，应用照样可能一跑就崩：环境变量没配、端口被占、迁移没跑。这类问题只有把应用真正跑起来才能暴露，而 verify 是三件里唯一为此设岗的。

它的描述写法也值得单独一提：一口气罗列五个真实口语句场景——"verify a PR"“确认修复生效”“手动测一下”“推送前验一遍”——这是触发词工程的场景清单法。Skill 的触发靠描述与用户输入的语义匹配，与其堆形容词，不如把用户真会说的话原样列进去。

短板在前提：它需要一个跑得起来的目标应用。纯库代码、没法本地运行的远端服务，这套方法论就落空了。上手友好度因此扣掉一星。

## 四、三闸分流全景

把三件的职责和交付形态画成一张图，就是 Claude Code 改完代码后的标准分流：

```mermaid
flowchart TD
    A["一次改动完成"] --> B{"下一步想要什么"}
    B -->|找bug和清理项| C["/code-review"]
    B -->|清理并动手改| D["/simplify"]
    B -->|跑起来看行为| E["/verify"]
    C -->|默认| F["只出报告"]
    C -->|--comment| G["PR行内评论"]
    C -->|--fix| H["写入工作区"]
    D --> I["直接应用四类清理"]
    E --> J["运行App观察后给结论"]
```

诊断（找茬）、治疗（收拾）、验收（跑真机）——三个岗位串起来恰好是一条完整的质量流水线。但注意两个空位：**写测试的岗位不在编制内**（官方插件货架上的 webapp-testing 属于另一条产品线，不在内置三闸之列），设计质量则在描述层面处于两件互相指向的缝隙里。

## 五、能直接抄走的五条设计模式

这组内置件的真正价值，是给所有想写自己 Skill 的人提供了可复制的模板。从三段描述里能提炼出五条：

**第一条：负空间写法。** 不只写“我做什么”，还要写“我不做什么、该去找谁”。simplify 的 "out of scope; use /code-review" 是范本。模型选 Skill 时只看描述，一条让路条款等于在入口处就完成了分流，省掉一次错误的全文加载。

**第二条：动作分级。** 默认只读，越权动作全部藏进显式旗标（`--fix`、`--comment`）。让“AI 会不会乱改我代码”这个顾虑变成一个用户自己按的开关。

**第三条：权衡档位化。** 精度与召回的矛盾不要自己拍板，做成 low/medium/high 之类的参数，并把每档的副作用写在描述里，提前管理预期。

**第四条：场景清单触发词。** 像 verify 那样，把用户真实会说的话（“确认修复生效”“推送前验一下”）原样罗列进描述。触发靠语义匹配，口语句子就是最好的关键词。

**第五条：让路要双向确认。** 这是 simplify 用教训示范的一条——你把某项职责指给隔壁，先确认隔壁的描述真的认领了这项职责。单向让路 + 对方没接 = 责任缝隙，用户两头碰壁。

一个可直接套用的描述骨架：

```markdown
---
name: my-reviewer
description: 做 X 和 Y，不做了 Z——Z 请用 /other-skill。
  默认只输出报告；传入 --apply 才允许修改文件。
  档位 fast（少而准）/ deep（广而杂）。
  触发场景：用户说「帮我看看」「上线前检查」时使用。
---
```

## 六、使用命令速查

三件均为 Claude Code 内置，无需安装，升级主程序即得：

```bash
/code-review           # 审当前 diff：bug + 清理项，档位可选 low / medium / high
/code-review --comment # 发现项贴成 PR 行内评论
/code-review --fix     # 把发现项直接改进工作区
/simplify              # 复用/简化/效率/层次四类清理，直接动手改
/verify                # 把应用跑起来，用观察代替猜测，推送前最后一道闸
```

想在此基础上加装社区同类件（TDD 驱动、特定语言审查器等），可到 skillsmp.com（2300+ 条目的可搜索目录）、skills.sh（热门榜）或 mcpservers.org/agent-skills、skillsdirectory.com（含安全扫描评级）按 "code review"“refactoring”"tdd" 等关键词检索，挑带安全评级的源安装。

## 七、排行榜

- **综合榜**：/code-review（4.75）> /simplify（4.63）> /verify（4.45）
- **设计质量榜**：/code-review 与 /simplify 并列第一——前者赢在档位与旗标，后者赢在让路条款；/verify 的场景清单稍逊半筹
- **实战收益榜**：/verify 第一，它是唯一能拦住“静态检查全过、一跑就崩”的岗位；/code-review 第二；/simplify 第三，收益取决于代码库的历史欠账
- **新手友好榜**：/code-review 与 /simplify 并列（零配置、斜杠即用）；/verify 需要一个可运行的应用环境
- **写给 Skill 作者的抄袭榜**：五条模式里优先抄第二条（动作分级）和第五条（双向让路）——一条保安全，一条防缝

三件内置件说明了一件事：Skill 生态竞争到今天，正文写得漂亮不稀缺，**描述之间划得清地盘才稀缺**。单件时代拼的是一段提示词的功力，编队时代拼的是一张让每个岗位都知道自己边界在哪、队友是谁的地图。下次写自己的 Skill，先把邻居的描述读一遍，再动笔。

## 参考来源

1. [anthropics/skills](https://github.com/anthropics/skills) — Anthropic 官方 Skills 仓库，本文所引内置效率件的描述原文随 Claude Code 分发
2. [skillsmp.com](https://skillsmp.com) — 2300+ Skills 的可搜索目录，社区同类审查/测试件的检索入口
3. [Agent Skills Library - mcpservers.org](https://mcpservers.org/agent-skills) — 官方与社区精选的 Skills 目录
4. [skillsdirectory.com](https://www.skillsdirectory.com) — 带安全扫描评级的 Skills 目录
5. [skills.sh](https://skills.sh) — Skills 生态热门榜单

> [!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)
