出厂自带开发效率四件套横评：code-review、simplify、verify、run

概述

一、为什么拆「出厂件」：生态里的隐形多数

把这三块拼起来，是一个生态级的悖论：市场在为 Skill 争星，而出厂套件根本不参赛。code-review、simplify、verify 这些名字没有仓库、没有 Star、没有上架时间——因为它们随 CLI 分发，装机量就是安装量。每一个天天用「审查一下这次改动」的人都在触发它们，但社区评测文章几乎只写市场新品。本期就把这个盲区补上：这批「出厂件」是官方对「SKILL.md 该怎么写」的第一手示范，比任何教程都权威。

一个侧写：同周小而美榜上 zenbu-labs/terminal-code（⭐1855，"VS Code in the terminal"）证明开发者工具在往终端里搬；新上架榜 kunchenguid/backpass（⭐697，"You don't write AGENTS.md. You train it with gradient descent."）在用市场的方式解决「让 Agent 把活干对」。而出厂套件用最朴素的方式解决同一个问题——精选四五个场景，写透描述，随版本走。

二、评测对比表

权重沿用本栏目基准：功能 25%、设计 25%、实战 20%、上手 15%、社区 15%。维度替换说明：出厂件无社区可观测数据，「社区活跃度」替换为「官方维护确定性」（随 CLI 版本更新的概率，均按官方绑定推断给分）；「实战」为基于描述设计与工作流位置的黑箱估分，未经独立基准测试。

（loop 的低分不是它写得差，而是通用调度器的功能天花板本来就低；fewer-permission-prompts 同理，属于「一次配置终身受益」的环境后勤件。）

三、主拆四件套：审查、重构、验证、运行

1. 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→max: 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.

一句话定位：对当前 diff 做正确性缺陷 + 复用/简化/效率清理的双重审查。

这段描述最值钱的是括号里那半句：「low/medium 档给更少但高置信的发现；high 及以上给更广覆盖、可能含不确定项」。这是把信息检索的精确率/召回率 dial 直接写进了触发描述——使用者还没调用就知道调大档位的代价是引入噪声。社区审查类 Skill（含本栏目拆过的 grill-with-docs 那一路）普遍只有一种输出口径，档位化是出厂件的明显代差。两个动作旗标同样讲究：--comment 把发现贴回 PR 行内、--fix 把结论落到工作区——同一份审查结论，三种消费方式（看、贴、改），流水线位置可前可后。短板：范围锁死在「当前 diff」，全仓库级审计不归它管。

2. simplify——重构件，一句话划清与旗舰的边界

清单原文（逐字）：

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

这是全清单里我认为写得最好的一句。三件事：第一，只管已改动代码，范围与 code-review 重叠，职责不同；第二，自动落地修复（"apply the fixes"），比审查件多走一步；第三——也是精华——"Quality only — it does not hunt for bugs; use /code-review for that."。这句边界让渡同时干了三件事：堵住模型自动把质量任务误路由给它的口子（“帮我看看有没有 bug”不会被它接走）、给兄弟件导流、省掉使用者的心智负担（不用记谁管什么）。

对照市场：本栏目拆过的同赛道社区件里，「拒绝说明」几乎是缺失项——描述只写自己会什么，不写自己不接什么，结果就是同名场景混战（orca-cli 那期的问题在出厂件这里被一句话解决了）。短板： apply-fixes 意味着它会直接改你的工作区，胆小的团队需要先在分支上试用。

3. 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 validate local changes before pushing.

它的哲学全在第一个句子里：通过把应用跑起来、观察行为来验证改动。不是读代码推断「应该没问题」，而是要求真实观测——这正面命中 AI 编码最大的坑：「编译通过、测试全绿、功能不对」。五个触发场景列举得非常诚实：验 PR、确认修复有效、手动测试、检查功能可用、推送前的最后一道闸。最后那个场景（validate local changes before pushing）是给个人开发者的日常钩子——push 之前跑一次，把「我以为是好的」变成「我看见了它是好的」。

短板如实说：它要求项目可运行。纯库项目、无法本地起服务的场景，威力打折；上手分因此给四星而不是五星。实战分是四件套最高（五星）——因为它防的是最贵的错误类型。

4. run——运行件，验证件的下游配套

清单开头（逐字）："Launch and drive this project's app to see a change working. Use when asked to run, start, or screenshot the app…"，后续大意是把应用跑起来以确认改动在真实应用中成立，与其纸面推断不如真实运行一遍。

定位：verify 说「要跑起来看」，run 就是那个「跑起来」的手。它要回答的是 AI 编码的另一类经典难题——这个项目的启动命令是什么、跑在哪个端口、怎么算「起来了」。按描述，它覆盖运行、启动、截图三类动作。它和 verify 的分工是典型的能力/任务分层：run 是能力件（会开车），verify 是任务件（把这趟货送到）。同族还有一个名字在册的 init（按惯例负责任项目初始化，描述未随清单给出，本期不评），三者构成「接手一个陌生项目」的完整动线：init 摸底 → run 跑通 → verify 验行为。

四、外围两件与同族名单

fewer-permission-prompts（加权 3.75）——清单原文（逐字）："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." 翻译成运营语言：翻你自己的历史会话，找出那些反复出现、反复要权限的只读命令，生成一份按优先级排序的白名单写进项目配置。它是四件套之外最被低估的一个——不直接碰代码，但每次省掉的那几秒确认，乘以一天几十次就是实打实的摩擦成本。设计上有一个隐藏亮点：用会话历史做证据源，白名单不是拍脑袋给的，是从你的真实使用里长出来的。

loop（加权 3.45）——"Run a prompt or slash command on a recurring interval"，例如 /loop 5m /foo，默认间隔 10 分钟。定时调度器，功能天花板低，但它是把前面所有件变成值守流程的胶水：比如 /loop 30m /code-review --comment 这样的组合（组合效果未经实测，仅示意描述所开放的可能性）。

同族点名（名字在册、描述未随清单给出，本期不评，留待后续轮次）：review、security-review、gh-fix-ci、gh-address-comments、gh-cli、sentry、keybindings-help、init。其中 security-review 与已拆过的官方安全三件套（security-best-practices / ownership-map / threat-model）显然是两条线；gh-fix-ci 一眼是 CI 修复向——但调试路线本栏目已拆过「云端诊断到内存断点」四个外部选手，不在此重复展开。

五、描述工程四模式：读完就能抄走

这是本期真正的干货。把出厂件的描述并排放，能提炼出四种可复用的写法模式：

mindmap
  root((描述工程四模式))
    边界让渡
      Quality only——不找bug
      use /code-review for that
      堵误路由+导流兄弟件
    档位化输出
      low/medium高置信少量
      high高覆盖含噪声
      写明调档的代价
    触发-跳过对
      TRIGGER when技术信号
      SKIP when排除项
      引用级精确
    例句触发
      from now on when X
      each time X
      用用户原话当钥匙

模式一：边界让渡。 simplify 的 "Quality only — it does not hunt for bugs; use /code-review for that"。抄法：你的 Skill 描述最后加一句「只做 X，不做 Y，Y 请用 Z」。前提是生态里真有那个 Z。

模式二：档位化输出。 code-review 的 low/medium/high 口径。抄法：凡是「找问题」类 Skill，在描述里写明默认档的置信换覆盖率策略，把选择权和使用成本同时交给用户。

模式三：触发-跳过对。 同清单里 claude-api 的描述用了教科书级的 "TRIGGER when: … SKIP: …" 结构——触发条件给的是可 greppable 的技术信号（如 import 了哪个 SDK），跳过条件排除的是易混淆的近似场景。抄法：别写「当用户需要 X 时」，写「当代码里出现 Y 信号时」；再补一条 SKIP 把隔壁场景明确推出去。

模式四：例句触发。 update-config 的描述里直接嵌了用户会说出的话："from now on when X"、"each time X"——用用户原话当触发钥匙，比抽象描述命中率高得多。抄法：想三个用户真实会说出口的句子，原样放进描述。

四模式的共同底层：描述不是广告，是路由表。市场件的描述在努力「说服你安装」，出厂件的描述在精确「告诉模型什么时候接手」——这是两个完全不同的写作目标，而后者才是 SKILL.md 的本质。

六、闭环工作流与使用命令

四件套拼起来恰好覆盖一次改动的完整生命周期：

flowchart LR
    A[开发者改完代码] --> B["/code-review 找正确性缺陷"]
    B -->|有bug| C[修复]
    C --> D["/simplify 只管质量清理并落地"]
    D --> E["/run 把应用跑起来"]
    E --> F["/verify 观察真实行为"]
    F -->|不符合预期| C
    F -->|符合| G[推送 / 开PR]
    G --> H[CI或评审环节]
    L["/loop 定时重跑"] -.节奏胶水.-> F
    P["/fewer-permission-prompts 白名单"] -.环境后勤.-> A

调用命令（无需安装，随 CLI 分发；在会话中输入 / 即可看到自动补全列表核验）：

/code-review              # 默认档位审查当前 diff
/code-review high         # 高覆盖档，接受更多不确定发现
/code-review --comment    # 发现以行内评论贴回 PR
/code-review --fix        # 审查后把结论直接落到工作区
/simplify                 # 质量清理并自动应用修复（不找 bug）
/verify                   # 跑起应用、观察行为来验证改动
/run                      # 启动并驱动本项目的应用
/fewer-permission-prompts # 扫描历史会话生成权限白名单
/loop 5m /foo             # 每 5 分钟重跑（默认 10m）

七、推荐排行榜与结论

按维度排名：

• 设计质量 🥇 code-review（档位化）🥈 claude-api 同款 TRIGGER/SKIP 结构在本清单的映射 🥉 simplify（边界让渡）
• 实战价值 🥇 verify（防最贵的错误）🥈 code-review 🥉 run
• 上手友好 全员满分级——零安装零配置，斜杠即用
• 最被低估 fewer-permission-prompts——不碰代码，省的是每天都在发生的摩擦

三条结论：

1. 出厂件是生态的「参考实现」。 市场新品比创意、比增长曲线，而描述工程的基本功——路由精度、边界声明、代价透明——全在出厂件里。想学写 SKILL.md，先精读这六段描述，比读任何模板都快。
2. 市场与出厂在解同一个题。 backpass 说「AGENTS.md 不是写的，是训出来的」，fewer-permission-prompts 说「白名单是从会话史里长出来的」——殊途同归：静态配置正在让位于从使用证据中生成配置。下一个周期，社区 Skill 的描述大概也会这么写。
3. 黑箱也要验货。 本文全部分析基于官方描述文本，SKILL.md 正文未逐行核对；描述写得漂亮不等于正文兑现——建议读者按第六节命令实测一遍，用 verify 的哲学来验收这篇评测本身：跑起来，看行为。

参考来源

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