<!-- title: 内建四件横评：描述里互相让路 -->

# 内建四件横评：描述里互相让路

## 概述

开发者效率赛道是本栏目翻地最勤的一块：代码审查、测试、调试、重构四个动词都各自横评过一轮，市场件的新面孔越挖越薄。这一轮换个挖法——不看货架，看**出厂**。随 Claude Code CLI 一起装机的内建件里，藏着一条完整的质检流水线：`code-review`（找错）、`simplify`（收拾）、`verify`（对行为）、`run`（开机器），外加 `loop` 与 `fewer-permission-prompts` 两个岗哨。六个件的描述原文全部取自 2026-09-15 本机会话注册表逐条比对，市场对照数据沿用本栏目 5 月存档抓取记录（已注明时点）。核心发现一句话：这组内建件最值钱的设计不在单个件里，而在**描述与描述之间互相让路**——每件的触发词都精确地把自己的边界、邻居的边界一起写清楚，像一份出厂时就签好的分工协议。

## 评测对比表

| 件名 | 职责 | 功能完整度 | 设计质量 | 实战效果 | 上手难度 | 维护活跃* | 综合 |
|:---|:---|:---:|:---:|:---:|:---:|:---:|:---:|
| code-review | 找 bug + 质量清理清单 | ★★★★★ | ★★★★★ | ★★★★☆ | ★★★★★ | ★★★☆☆ | **4.6** |
| simplify | 只收拾不找错 | ★★★★☆ | ★★★★★ | ★★★★☆ | ★★★★★ | ★★★☆☆ | **4.5** |
| verify | 跑起来观察行为 | ★★★★☆ | ★★★★☆ | ★★★★★ | ★★★★☆ | ★★★☆☆ | **4.4** |
| run | 把项目跑起来 | ★★★★☆ | ★★★★☆ | ★★★★☆ | ★★★★★ | ★★★☆☆ | **4.3** |
| loop | 定时值守 | ★★★☆☆ | ★★★★☆ | ★★★☆☆ | ★★★★☆ | ★★★☆☆ | **3.8** |
| fewer-permission-prompts | 扫记录发权限白名单 | ★★★☆☆ | ★★★★☆ | ★★★☆☆ | ★★★★☆ | ★★★☆☆ | **3.7** |

> \* 口径说明：内建件随 CLI 主程序分发，无独立仓库与 Star 数可观测，「维护活跃」按保守中性档三星计，不假造数据。综合分按功能 25%、设计 25%、实战 20%、上手 15%、维护 15% 加权，与全系列口径一致。

## 主四件：一条出厂自带的质检流水线

### code-review：挡位拧在描述里

描述原文：*"Review the current diff for correctness bugs and reuse/simplification/efficiency cleanups at any effort level (low/medium: fewer, high-confidence findings; high→broad: more, lower-confidence findings). Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree after you review."*

拆到行，这句描述里藏了四个设计决策。**第一，以 diff 为界。** 只审「当前改动」，不扫全库——这一刀把它和全库审计类市场件（如 5 月存档里 4.1K Star 的 Trail of Bits 安全套件）划清了赛道：内建件管日常，审计件管年检。**第二，挡位即召回率旋钮。** low/medium 档给「少而高置信」的发现，high 档给「多而低置信」——把「宁缺毋滥还是宁可错杀」这个永远吵不完的问题，直接做成参数交给用户。这是全家族里最聪明的一行：审查工具最大的差评从来不是「找不到 bug」，而是「报了一堆噪音」，它把噪音量明码标价。**第三，两个动作出口。** `--comment` 把发现贴成 PR 行内评论，`--fix` 直接把修复落到工作区。读和写分开卖，用户按场景点单。**第四，人保留终审。** 注意那半句 "after you review"——连 `--fix` 这种动手模式，描述里也要塞进「你先过目再改」的次序，这是整套内建件一以贯之的克制。

短板也在这：只认 diff 意味着存量代码的烂账它一概不管，老仓库第一件事仍得请外部的全库扫描件。

### simplify：一句门规，两个件不打架

描述原文：*"Review the changed code for reuse, simplification, efficiency, and altitude cleanups, then apply the fixes. Quality gate, not bug hunter. Use /code-review for that."*

这是六件里**设计密度最高**的三行字。四个清理维度依次排开：reuse（该抽公共函数的抽出来）、simplification（绕弯的拉直）、efficiency（明显的浪费砍掉），以及最值得单讲的 **altitude**——「高度」清理，即代码的抽象层级对不对：该在业务层说的话别沉到工具层，该一行调库的别手搓三十行。这个维度几乎从不出现在社区件的清理清单里，却是代码评审里最高频的争执。**然后是那句门规：** "Quality gate, not bug hunter. Use /code-review for that."——质量门卫，不是猎 bug 的。一句话把「我不干什么」写在脑门上，再把顾客推出门时顺手报了邻居的门牌。对照全系列看过的上百份市场件 SKILL.md，触发词抢地盘的见过一堆（同一套触发词三四个件都来应答），**主动给邻居导流的，这是唯一一份写成白纸黑字的**。还有一处易漏的细节：动词是 "then apply the fixes"——它不是只出报告，是直接动手改。同门两个件，code-review 默认只读、可选 `--fix`；simplify 默认动手。一柔一刚，用户用挡位和动词选择控制风险敞口。实战定位：提交前的最后一道收拾，专治「功能对了但代码没法看」。

### 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 feature works, or to observe behavior."*

方法论只有一句：**跑起来，观察行为**——不是读代码找证据，是执行系统拿证据。这一句把它和静态审查件彻底分开：code-review 读出来的叫「疑似」，verify 跑出来的才叫「确认」。触发侧一口气列了五个短语：verify a PR、confirm a fix works、test a change manually、check a feature works、observe behavior——同义词铺到第五个，就是在给语义匹配撒网：用户嘴上说「帮我看看修好没」「手动测一下」「验收这个功能」，任何一个说法都能命中。这种「一条方法论 + 一网同义触发词」的写法，和市场件里常见的「堆功能清单」是两个流派：前者赌的是**高频场景足够窄**，窄到可以用五种说法反复占住。实测定位里它是四件中体感最强的一件——「改完→跑通→眼见为实」这个闭环一旦常态化，「我以为修好了」这类事故会肉眼可见地变少。

### run：先问项目自己的意见

描述原文：*"Launch and drive this project's app to see a change working. Use when asked to run, start, or screenshot the app to see a change working, or to confirm it works manually. First looks for a project skill that already covers launching the app; otherwise falls back to built-in patterns per project type (CLI, server, TUI, Electron, browser-driven)."*

verify 负责「对行为」，run 负责「开机器」，两者是上下游。run 的描述里有一条完整的**寻路算法**：第一步先找项目里已有的启动技能（project skill），没有才走内建兜底；兜底按五种项目形态分发——CLI、server、TUI、Electron、browser-driven。这个「先查项目自述、再按形态猜」的次序非常尊重现实：启动一个项目的知识本来就长在项目自己身上（README、Makefile、package.json scripts），通用件不该抢答。触发词里混进了 "screenshot" 很妙——很多人验证 UI 改动的第一诉求不是「跑起来」而是「截图给我看」，一个词把视觉验收也圈了进来。短板：五种形态之外的怪项目（嵌入式交叉编译、需要真实硬件的）它兜不住，得靠项目自带技能接管——好在描述里已经把这条路让出来了。

## 两个岗哨：值守与减摩擦

**loop**：*"Run a prompt or slash command on a recurring schedule... Use for autonomously iterating in a loop, or for periodic re-checks. Do NOT use for background tasks that finish on their own."* 又是一件把「不适用」写进描述的：定时重复的活归它，自己会结束的后台任务不归它——正反两条触发边界一起划，防的是最常见的误用（拿它当后台任务跑，结果任务早完了它还在空转）。配合 verify 就是「每五分钟回归一次」的土法值守。

**fewer-permission-prompts**：*"Scan your transcripts for common read-only Bash and MCP tool calls, then add a prioritized allowlist to project .claude/settings.json to reduce permission prompts."* 这件把「摩擦治理」做成了件：数据源是你自己的历史会话记录，找出高频只读操作，按优先级生成白名单写进项目配置。先分析后放行，放行的还只是只读操作——权限问题上官方同样收着劲。

## 工作流图

```mermaid
flowchart TD
    A["改完一段代码"] --> B["code-review 找错"]
    B -->|有bug| C["回炉修改"]
    C --> B
    B -->|干净| D["simplify 收拾"]
    D --> E["run 开机器"]
    E --> F["verify 对行为"]
    F -->|不符| C
    F -->|相符| G["loop 定时值守"]
    G --> H["扫记录发白名单"]
```

## 对照市场件：轻装版与重装版

同一批动词，市场上有重装版，数据沿用本栏目 5 月存档抓取记录（时点 2026-05，现为当时值）：superpowers 套件把 systematic-debugging、test-driven-development、verification-before-completion 等 12+ 个子技能做成完整工程纪律流水线（存档记 8K+ Star）；gh-fix-ci 专修 CI 红灯（5 月工作流轮已评）；Trail of Bits 安全套件管全库深度审计（4.1K Star）。对账结论：**内建件赢在随身与零配置，市场件赢在深度与边界外**。日常 diff 级别的找错、收拾、验证，出厂四件已经覆盖八成；剩下两成——全库审计、CI 事故、系统性调试方法论——仍是市场件的地盘。这也是本栏目 5 月存档里「Skills 2.0 渐进式加载」判断的延续：官方自己下场后，先做薄做全，把「厚」留给生态。

## 安装/使用命令

内建件无需安装，CLI 会话内直接调用：

```bash
# 找错：低噪音档审查当前 diff
/code-review low
# 找错：广撒网档，并把发现贴成 PR 行内评论
/code-review high --comment
# 提交前收拾代码（会直接动手改）
/simplify
# 把项目跑起来
/run
# 验证行为：确认修复真的生效
/verify
# 定时值守：每5分钟回归一次
/loop 5m /verify
```

市场对照件（安装命令来自 5 月存档原文，克隆前请自行确认仓库现况）：

```bash
# superpowers 工程纪律全家桶（5月存档：8K+ Star）
git clone https://github.com/obra/superpowers ~/.claude/skills/superpowers
# Trail of Bits 安全审计套件（5月存档：4.1K Star）
git clone https://github.com/trailofbits/skills .claude/skills/trailofbits
```

## 推荐排行榜

**按场景找件**

| 场景 | 首选 | 理由 |
|:---|:---|:---|
| 提交前找 bug | code-review | diff 为界，挡位控噪音 |
| 代码能跑但没法看 | simplify | 四维清理，直接动手 |
| 「你确认修好了？」 | verify | 跑起来拿证据 |
| 新 clone 一个项目要起服务 | run | 先问项目自述再兜底 |
| 长任务盯梢 | loop | 正反边界写得最清楚 |
| 权限弹窗烦不胜烦 | fewer-permission-prompts | 用你自己的记录治你自己的烦 |

**上手难度**（从易到难）：六件全部零配置，差异在使用纪律——simplify 最需要谨慎（默认动手改码），verify 最需要环境（起不来的项目用不了），其余四件随叫随到。

## 关键发现

1. **描述即路由器。** 六个内建件的描述里，每一份都同时写清「我管什么」和「邻居管什么」，simplify 甚至直接报出邻居的门牌。触发词从此不是抢地盘的战场，而是出厂就分好的户籍。
2. **动词分工精确到风险敞口。** 只读（code-review 默认）、动手（simplify）、执行观察（verify/run）、定时（loop），四个风险等级一一对应四个动词，用户选件就是在选风险。
3. **「不适用条款」是内建件的标配。** simplify 的 not bug hunter、loop 的 do NOT use for tasks that finish on their own——把负向边界写进描述，是这批件区别于多数市场件的最外显特征。
4. **摩擦本身被做成了件。** 权限弹窗、重复操作这类「使用体验税」，官方的解法不是改交互，而是做一件扫记录、发白名单的件——工具的问题用工具收尾。

## 参考来源

1. [anthropics/claude-plugins-official](https://github.com/anthropics/claude-plugins-official) — 官方插件与技能仓库（本栏目 5 月存档抓取记录，时点 Star 19.5K+）
2. [trailofbits/skills](https://github.com/trailofbits/skills) — Trail of Bits 安全审计技能套件（5 月存档记录，4.1K+ Star）
3. [obra/superpowers](https://github.com/obra/superpowers) — 工程纪律全家桶，含 systematic-debugging、verification-before-completion 等子技能（5 月存档记录，8K+ Star）
4. [skills.sh](https://skills.sh) — Skills 生态市场与热门榜单（5 月存档记录收录）
5. 内建件描述原文 — 2026-09-15 本机 Claude Code 会话注册表逐条比对；市场件对照数据出自本栏目 2026-05-16 存档抓取文件（output/skills-ecosystem-*.md）

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