# 评审、重构、验证：Claude Code 把工程纪律做成了三个内置技能 ## 概述 聊开发者效率类 Skills，多数榜单还在数社区市场里那些花哨的货架。但这一轮横向评测拆下来，最值得逐行读的东西其实不在任何市场里，而是 Claude Code 近期版本直接内置的三个工程命令：`/code-review`（审查）、`/simplify`（重构清理）、`/verify`（运行验证）。它们分别接管 AI 写码循环里最高频的三件事——查 bug、改结构、证行为——而且三个的 description 文本互相引用、分工边界写在明面上，本身就是一份可以直接抄的提示词工程范本。外围再配一组 Anthropic 官方精选（curated）集合里的 GitHub 工作流技能：`gh-fix-ci`、`gh-address-comments`，以及官方示例库 anthropics/skills 中 example-skills 目录下的 `webapp-testing`。本文先逐行拆内置三件套，再看外围集群怎么补位。 ## 一、先说清楚：为什么 description 就是 SKILL.md 的命根子 Claude Code 的技能触发机制决定了：SKILL.md 里 frontmatter 的 `description` 字段会被注入系统提示，模型根据它判断当前对话该不该路由进这个技能。换句话说，**description 既是说明书，也是 API 合同，还是触发条件**。一个技能设计得好不好，八成看这几行字怎么写。 内置三件套的 description 都短得惊人——每个就两三句话——但信息密度极高。下面逐行拆。 ## 二、/code-review：把「审查范围」和「取舍旋钮」写进一行字 它的 description 大意是（保留原文关键结构）： > Review the current diff for correctness bugs and reuse/simplification/efficiency cleanups at any effort level (low/medium: fewer, high-confidence findings; high→best for 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 findings are collected. 这一段至少藏了四层设计： **第一层：范围锁定在 `current diff`。** 不是「审查这个仓库」，不是「审查这个项目」，而是当前改动。这是信噪比意识：AI 全库扫一遍，产出的一半是噪音；只审 diff，每条发现都对应你刚写的东西。同时天然省 token——审查对象的大小和你的改动成正比，而不是和仓库成正比。 **第二层：两类产出并轨。** correctness bugs（正确性缺陷）和 reuse/simplification/efficiency cleanups（复用、简化、效率类清理建议）放在同一次扫描里。查错和提质本来是两次工作，这里合并成一遍遍历，成本减半。 **第三层：effort 旋钮把权衡写明。** low/medium 档明确标注「发现更少、但置信度高」，high 档标注「覆盖更广、可能包含不确定的发现」。绝大多数工具只会给你一个开关，不会告诉你开到最大会有什么副作用；这里把查全率/查准率的取舍直接写进了用户文档。想快速过一遍小改动用 low，提交前的最终把关用 high——用户不需要读任何额外文档就能做对选择。 **第四层：输出侧双通道，默认不动手。** `--comment` 把发现以 inline 评论的形式贴到 PR 上；`--fix` 才会把修复应用到工作区。注意默认行为是**只报告、不修改**——审查者先看清单，再决定要不要让 AI 动手。而且 `--fix` 的描述里还有个容易被忽略的时序细节：「after the findings are collected」——先收集完全部发现，再统一应用修复。这避免了边审边改导致后面审查的对象已经被前面改过的经典混乱。 ## 三、/simplify：一行负面清单，写透单一职责 它的 description 更短： > Review the changed code for reuse, simplification, efficiency, and altitude cleanups, then apply the fixes. Quality bar — it does NOT hunt for bugs; use /code-review for that. 值得逐词看的两处： **「it does NOT hunt for bugs; use /code-review for that」。** 一个技能的 description 里专门写一句「我不干什么」，并且明确把那件事移交给另一个技能。这是把单一职责原则从代码层面提到了技能编排层面：simplify 只管结构清理，查 bug 的事有专门入口。负面清单在技能设计里极其实用——模型路由靠语义匹配，如果不写清边界，「帮我看看这段代码」这种模糊请求就可能被错误吸进来做错事。 **四个清理轴里，altitude 这个词选得妙。** reuse（复用既有实现，别重复造轮子）、simplification（砍复杂度）、efficiency（性能）都好理解，altitude 指的是**抽象层级**——代码常犯的错不是写错了，而是站错了高度：该调高层接口的地方扎进了底层细节，或者反过来，为一次性逻辑造了过度抽象。一个词把这类「说不清但一眼假」的问题归了类。 **和 code-review 的重叠是故意的。** 细看会发现 code-review 的产出清单里也有 reuse/simplification/efficiency cleanups——两处描述刻意重叠，但行为不同：code-review **报**，simplify **改**。同一次审查发现的问题，可以先看报告再一键执行，这组分工是成对设计的。 ## 四、/verify：只信运行时，五个触发短语全写进描述 > Verify 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 a feature works, or look at what the app looks like before committing. **方法论一句话说死：running the app and observing behavior。** 静态审查（code-review）再仔细，也只能证明「代码看起来对」；verify 的存在就是为了补上这一段认识论鸿沟——把应用真的跑起来，观察实际行为。AI 写码最大的风险从来不是写不出，而是「看起来对了」。 **五个触发短语的枚举是教科书级的路由设计。** verify a PR、confirm a fix works、test a change manually、check a feature works、look at what the app looks like before committing——用户嘴上会说出的五种不同说法，全部预先写进了 description。技能作者常犯的错是只写一句书面化的功能描述，结果用户换个说法就触发不了。这里示范了正确姿势：**把用户口语的同义词全部塞进去**，路由命中率完全取决于你对用户语料的想象力。 ## 五、评测对比表 评分基于可直接观察的接口设计、触发设计与定位（三件套为内置分发，社区活跃度一档按「随主版本分发、迭代随官方」计），不虚构使用统计。 | 技能 | 功能完整度 (25%) | 设计质量 (25%) | 实战效果 (20%) | 上手难度 (15%) | 分发与迭代 (15%) | 综合 | |------|------|------|------|------|------|------| | /code-review | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★ | **4.9** | | /simplify | ★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★ | **4.5** | | /verify | ★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★ | **4.5** | - **/code-review**：功能、设计、上手三项拉满。effort 分档加双输出通道，覆盖了从随手一看提交前把关的全谱系；扣分点仅在长上下文大 diff 时的表现仍取决于模型本身。 - **/simplify**：设计质量满分——那句负面清单是本文见过最干净的责任边界声明。功能上只做清理不做查错，是有意的窄，不是缺陷。 - **/verify**：触发设计最用心（五个短语枚举），但「跑起应用观察」依赖项目本身可运行，在无法本地启动的环境里会退化。 ## 六、外围集群：GitHub 工作流的补位者 内置三件套管的是「本地写码循环」，官方精选集合里还有一组技能把同一套纪律延伸到 GitHub 侧。本节按收录情况与命名定位介绍，不做逐行拆解： - **gh-fix-ci**：CI 红了之后的第一急救包。定位非常聚焦——不吃「帮你写 CI」的大活，专吃「这次构建为什么挂了、怎么修」的卡点场景。与 code-review 形成07互补：一个在提交前拦问题，一个在提交后救火。 - **gh-address-comments**：批量处理 PR 评审意见。人工 reviewer 留下的一串评论，逐条回复修改是最磨损人的机械劳动，这个技能把「读意见—改代码—回帖」串成一趟。 - **webapp-testing**：官方 anthropics/skills 仓库 example-skills 目录下的示例技能，走浏览器自动化路线做 Web 应用测试，可视为 /verify 在前端场景的重型版本。 - **security-review**：与 code-review 平行的独立命令。安全审查单独成令是合理的——它的检查清单（注入、越权、敏感信息泄漏）与正确性审查几乎不相交，塞在一起只会互相稀释。 ## 七、安装与使用 **内置三件套**：随 Claude Code 近期版本自带，无需安装，升级后直接用： ```bash # 会话内直接调用 /code-review # 默认：审当前 diff，只报告 /code-review high # 最终把关档：覆盖更广，接受不确定性 /code-review --comment # 发现以 inline 评论贴到 PR /code-review --fix # 收集完发现后统一应用修复 /simplify # 对当前改动做结构清理并直接改 /verify # 跑起应用验证行为 ``` **精选集合技能**（gh-fix-ci、gh-address-comments 等）：经 `/plugin` 的官方 marketplace 安装，或把技能目录整体拷贝进 `~/.claude/skills/` 即被发现；webapp-testing 在官方仓库 anthropics/skills 的 example-skills 目录下，同样拷入即用。 ## 八、三件套在工作流里的位置 ```mermaid flowchart TD W["改完一段代码"] --> CR["/code-review
审查当前 diff"] CR --> Q1{"有正确性问题？"} Q1 -->|"有"| F["修掉问题"] F --> CR Q1 -->|"没有"| S["/simplify
结构清理并应用"] S --> V["/verify
跑应用看行为"] V --> Q2{"行为符合预期？"} Q2 -->|"否"| F Q2 -->|"是"| C["提交或开 PR"] C --> AC["gh-address-comments
跟进评审意见"] AC --> W ``` 注意循环里 /code-review 出现两次以上入边——审查是这个环的重心，另外两件都是围绕它的后续动作。 ## 九、分维度排行榜 - **最值得立刻用起来**：/code-review。零配置，且 effort 分档让它同时适配「顺手看一眼」和「提交前严审」两种场景。 - **接口设计最佳**：/simplify。一句「does NOT hunt for bugs; use /code-review for that」同时完成了自我限界和流量转发，是本文最值得抄的一句话。 - **最容易被低估**：/verify。它没有花哨参数，但「只信运行时」是三件套里唯一能真正终结「看起来对了」争论的一环。 - **最值得与三件套配套加装**：gh-fix-ci。CI 挂掉是最痛的卡点，也是内置三件套唯一没覆盖的时段。 ## 十、结语：高频动作正在被 harness 收编 把这一轮拆解放回 Skills 生态看，趋势已经相当清楚：**高频、普适的工程动作（审查、重构、验证）正在被官方从技能市场收编为内置能力**，社区技能的生存空间被挤向两类——更长的尾（gh-fix-ci 这种特定卡点场景）和更重的活（webapp-testing 这种带浏览器依赖的重型流程）。对想写技能赚钱的开发者，这轮的启示很直接：别再做大路货的「代码审查助手」，去打磨内置三件套管不到的环节。而对所有技能作者，三件套的 description 就是现成的作业——范围写窄、取舍写明、边界写成互相引用的移交指针。 ## 参考来源 1. [anthropics/skills](https://github.com/anthropics/skills) — 官方技能仓库，example-skills 目录（含 webapp-testing）与精选集合的上游 2. Claude Code 内置技能说明 — `/code-review`、`/simplify`、`/verify` 的 description 原文，任一近期版本会话内可通过内置技能列表查看，本文引文均出于此 3. Anthropic 官方精选技能集合 — gh-fix-ci、gh-address-comments 等的收录来源，本地安装后位于 `~/.claude/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 等场景全覆盖。