# 出厂自带开发效率四件套横评：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 版本更新的概率，均按官方绑定推断给分）；「实战」为基于描述设计与工作流位置的黑箱估分，未经独立基准测试。 | Skill | 功能 | 设计 | 实战 | 上手 | 维护 | 加权 | |-------|------|------|------|------|------|------| | code-review | ★★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★★ | **4.80** | | simplify | ★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★★ | **4.55** | | verify | ★★★★ | ★★★★ | ★★★★★ | ★★★★ | ★★★★★ | **4.35** | | run | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★★ | **4.30** | | fewer-permission-prompts | ★★★ | ★★★★ | ★★★★ | ★★★★ | ★★★★ | **3.75** | | loop | ★★★ | ★★★ | ★★★ | ★★★★★ | ★★★★ | **3.45** | （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 修复向——但调试路线本栏目已拆过「云端诊断到内存断点」四个外部选手，不在此重复展开。 ## 五、描述工程四模式：读完就能抄走 这是本期真正的干货。把出厂件的描述并排放，能提炼出四种可复用的写法模式： ```mermaid 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 的本质。 ## 六、闭环工作流与使用命令 四件套拼起来恰好覆盖一次改动的完整生命周期： ```mermaid 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 分发；在会话中输入 `/` 即可看到自动补全列表核验）： ```bash /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 等场景全覆盖。