先自证白地是真的。效率赛道至今入档的每一件——四座山、三路线、七件调试、规格层、文档层、浏览器四层手——全部来自市场端或装机端：有仓库、有星数、有货架。而本会话注册表上还躺着另一类东西：code-review、simplify、verify、run、security-review、review、init、claude-api、update-config、keybindings-help、fewer-permission-prompts、loop——十二个无前缀名字，随 harness 本体发行，没有仓库地址，没有 star 数，不在任何市场目录的货架清单里（一手观测）。它们恰恰就是效率四动词的官方答卷：审查、重构、验收各有人认领，调试无人应答。
市场答卷与官方答卷从未同框。这不是命名学问题（撞名九组已档），不是触发词范文问题（触发词批改课已档），也不是「改 Agent 自己」的配置件问题（出厂件末排审计已档，本期不碰 update-config 一族）——这是能力口径与治理面的问题：官方件把什么当输入（diff？工作区？运行中的应用？）、把什么当输出（报告？改动？评论？判收？）、把自己放在交付流水线的哪个工位。这三问，市场端四座山没有一山按这个格式答过。
权重沿用本栏固定口径：功能 25%、设计 25%、实战 20%、上手 15%（越高越容易）、社区 15%。
| 动词 | 对象 | 功能 | 设计 | 实战 | 上手 | 社区 | 加权 |
|---|---|---|---|---|---|---|---|
| 审查 | code-review | ★★★★★ | ★★★★★ | ★★★★（待实测） | ★★★★½ | ★★★★※ | 4.58 |
| 验收 | verify | ★★★★½ | ★★★★★ | ★★★★（待实测） | ★★★★★ | ★★★★※ | 4.53 |
| 重构 | simplify | ★★★½ | ★★★★★ | ★★★★（待实测） | ★★★★★ | ★★★★※ | 4.28 |
| 邻区 | claude-api | ★★★★ | ★★★★★ | ★★★ | ★★★★ | ★★★★※ | 4.05 |
| 验收 | run | ★★★★ | ★★★★ | ★★★½（待实测） | ★★★★ | ★★★★※ | 3.90 |
| 审查 | security-review※ 裸名 | ★★★ | ★★ | ★★（待实测） | ★★★★ | ★★★★※ | 2.85 |
| 审查 | review※ 裸名 | ★★½ | ★★ | ★★（待实测） | ★★★★ | ★★★★※ | 2.73 |
评分说明：全部评分基于描述文本逐字细读，本期未实际调用任何一件，实战分按场景覆盖给中间值并标注待实测※；社区分按「随 harness 发行、更新通道即发行说明」口径统一给四星——出厂件无独立 star 数与 issue 面可考，市场端社区维度在此层失效※；security-review 与 review 为裸名在册（本会话注册表无描述），出厂 provenance 使「谜团层最差情形口径」（浏览器篇对 chrome-automation 所用）显得过苛，改按名字级中间值给分，全行标注※。
flowchart LR
subgraph V1["审查：一件主审 两件裸名"]
CR["code-review 主审"]
SR["security-review※ 裸名"]
RV["review※ 裸名"]
end
subgraph V2["重构：独苗"]
SIM["simplify"]
end
subgraph V3["验收：双件套"]
VER["verify 判断"]
RUN["run 驾驶"]
end
subgraph V4["调试：缺编"]
NB["空椅子"]
end
SIM -->|让位句指向| CR
读法：四个动词三个有岗，唯独调试的椅子上没人。市场端调试赛道七件横评（已档）说明生态早已补位——从报错到复现这条线上，x64dbg-mcp-server 们甚至下探到了二进制层；但官方至今没有一件名字里带 debug 的出厂件（基于本会话注册表一手清点※）。这是本期最重要的结构性发现，展开见第八节。
描述原文照录："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。 不审整个仓库，只审「当前 diff」——把审查件的成本上限写死在输入定义里。市场端审查件普遍以「仓库 + 规则」自我描述（四座山存档口径），出厂件以「本次改动」自我描述：前者卖全知，后者卖增量。
其二，档位文档是一份微型代价曲线。 「low/medium: fewer, high-confidence findings; high→max: broader coverage, may include uncertain findings」——低档少而准，高档广而杂。这句的罕见之处在于后半句的诚实条款：官方直接承认高档位会产出不确定的发现。召回率与精确率的权衡是所有审查工具的宿命，把它明码写进调用文档而不是藏在默认值里，本栏首见。
其三，写面分级藏在旗标里。 默认行为是只读报告；--comment 把发现发成 PR 内联评论——这是对外发布面，写的是 GitHub；--fix 把修复应用到工作区——这是本地写面，改的是你的未提交代码。注意原文的时序词 「after the review」：审查在先、动手在后，写动作永远是显式追加项。治理不是一层壳，是逐档旋钮（定律展开见第八节）。
其四，与 simplify 的领地重叠用动作切分。 它的清理范围写着 「reuse/simplification/efficiency cleanups」——与 simplify 的四个品类词几乎重合。重叠没有用领域划分（你管 bug 我管质量），而是用动作划分：code-review 报，simplify 改。让位句之外的第二种划界术，见下一节。
描述原文照录："Review the changed code for reuse, simplification, efficiency, and altitude cleanups, then apply the fixes. Quality only — it does not hunt for bugs; use /code-review for that."
让位句的完整形态。 这句存档中被引用过多次（触发词溢出、浏览器篇均转引），本期放在四动词坐标系里看它的完整职能：「Quality only」五个词先把领域砍掉一半，破折号之后 「it does not hunt for bugs」 自陈负面清单，「use /code-review for that」 指路。三段式：砍领域、认边界、给出路。触发词批改课批改过十篇官方描述范文（已档），simplify 的价值不在范文性而在系统性——它不是孤立的好句子，是官方划界体系的一个节点：横向让位给同层件 code-review，纵向与 verify 分工（它改完的代码归 verify 验收）。
「then apply the fixes」——动手件的身份证。 与 code-review 最大的分野在这五个词：simplify 报完就改。四动词编制里它是唯一的「重构即落盘」件——没有 --fix 旗标，因为动手就是它的默认行为。写面等级天生比审查件高一档（分级表见第八节），这解释了为什么它的领域必须先砍一半：写面越大，领域越窄，这是出厂层用描述结构表达的治理直觉。
「altitude」——一个品类词的回声。 四个品类词 reuse / simplification / efficiency / altitude 里，最后一个与市场端重构件 altitude 同名（重构赛道横评已档）。谁借了谁的词、流通方向为何，不可考※；但「官方描述采用与市场件同名的品类词」是注册表上的既成事实——品类词一旦被市场叫响，会反向出现在官方文本里。市场与出厂之间隔着的不是墙，是行话。
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 for bugs, or validate local changes before passing to human review."
设计质量全五星的理由有三。其一，方法论一句话立住：跑起来 + 观察行为——不是读代码推断。这与技能层 webapp-testing 形成鲜明的哲学对偶：webapp-testing 的决策树是「能读代码回答就不开浏览器」（浏览器篇存档口径），技能层省浏览器，出厂件坚持真跑。省成本与看真实，验证这件事的两派在注册表上各自成文。其二，五个触发场景排成一张清单：verify a PR / confirm a fix works / test a change manually / check for bugs / validate local changes——注意第三项，手动测试被点名收编：人肉点一遍的活，划归 verify。其三，也是最重要的一处：清单末尾的 「before passing to human review」——verify 自己说清了工位：人机交接线上、人审之前的那道闸。门原语（回路里的人，已档）讲的是显式批准门，verify 是同一血脉在验收位上的变体：它不批准什么，它决定什么够格送到人面前。
run 描述照录："Launch and drive this project's app to see a change working. Use when asked to run, start, or screenshot the app, or to confirm a change works in the real app (not just tests)."
它是双件套里握方向盘的那只手：启动、驾驶、截屏。设计的眼妙在括号：「(not just tests)」——真实应用优先于测试套件，五个词给「测试」这个概念本身划了界。为什么 verify 与 run 不合成一件？因为判断「要不要跑、跑什么、看什么」与能力「怎么把项目跑起来」是两种资产：前者是场景知识，随项目形态剧变（网页、CLI、服务）；后者是驾驶技术，同样随技术栈剧变——两件都变，所以分立；而 verify 的价值恰恰在变局之上恒定：总得有谁决定验收算不算完成。
security-review 与 review：出厂层的两个裸名。 本会话注册表中二者均无描述可考※。名字级解读：前者押注安全专精——与 code-review 的 「correctness bugs」 分家，正确性缺陷与安全漏洞是两次不同的狩猎；后者裸到只剩一个动词，与三百多个装机裸名同池。裸名三件（含 init※）列观察名单，行为以实测为准——本栏不给黑箱打高分，也不给出厂 provenance 打低分。
claude-api：惟一的大写条款件。 注册表上十二件出厂件中，惟独它带大写 TRIGGER / SKIP 块。TRIGGER 侧照录：「code imports anthropic/@anthropic-ai/sdk; user asks for the Claude API... or asks about prompt caching / cache hit rate in an Anthropic SDK project」；SKIP 侧点名 openai 及其他家 SDK、provider 中立代码与泛用编程/ML。为什么惟独它需要喊？因为它的失败模式与所有其他出厂件相反：其他件怕漏触发（该来不来，损失一次帮助），它怕误触发（在 OpenAI 代码里点火，输出整段错误指导）。失败模式是误触发的件，才值得把触发词写成大写条款——这是触发词批改课框架之外的一条新判据：大写条款的密度 = 误触发代价。
邻区边界。 update-config、keybindings-help、fewer-permission-prompts、loop 四件属于「改 Agent 自己」的配置族（fewer-permission-prompts 会扫转录文件然后写 settings.json 的 allowlist），出厂件末排审计已档，本期只划界不重拆。deep-research 的先问后研条款（「BEFORE invoking, check if the question is specific enough... ask 2-3 clarifying questions」）是门原语在研究位的又一变体，记一处回声。
定律一：划界三向。 出厂描述里的排他条款不是一种，是三个方向：横向让位——simplify 指向 code-review（同层件之间）；纵向方法界——run 的 not just tests、verify 的坚持真跑（对方法与概念划界）；流程工位界——verify 的 before passing to human review、code-review 的 after the review（对交付流水线自报坐标）。市场件卖能力，出厂件报工位：每件都写明自己在流水线哪一站。撞名九组（已档）讲的是名字互斥，本期讲的是岗位互认——让位句产业链的终点是一张组织架构图。
定律二：写面分级。 把十二件的输出动作排成梯子：L0 只读报告（code-review 默认、review※）→ L1 改工作区（simplify、code-review --fix）→ L2 对外发布（code-review --comment，写 GitHub）→ L3 判收闸门（verify，决定什么够格见人）→ L4 改 Agent 自己（配置族，已档邻区）。写面越大、领域越窄（simplify 为证）；写面对外、授权越显式（--comment 为证）。据本栏历期存档观察，市场端描述极少自报写面※——把写面等级写进自己的 SKILL.md，是市场件向出厂层看齐的最低成本升级。
定律三：无星经济。 出厂件没有仓库、没有 star、没有 issue 面——市场时代的三个信用凭证在此层全部失效。评价口径坍缩到只剩能力与设计本身，评测表里社区一栏退化成发行渠道稳定度※。这反过来解释了定律一：没有星数可刷的货色，只能靠让位句和工位坐标挣信用——治理文本就是出厂件的货架陈列。
一把空椅子：/debug 缺编。 审查有主件带双裸名，重构有独苗，验收有双件套，调试零编制（本会话注册表一手清点※）。市场端七件调试（已档）证明需求真实存在——从报错到复现是最高频的开发场景之一。官方留白的可能解释※：调试高度依赖运行时生态（调试器、日志、可复现环境），出厂件难做通用件——但这正是 MCP 路线（x64dbg-mcp-server 存档口径）正在填的位。空椅子给生态：谁把「报错输入 → 复现路径 → 根因假设 → 最小验证」做成规格化流程件，谁就坐上了官方没坐的那把椅子。
出厂件随 harness 发行，零安装，斜杠即调：
/code-review # 默认：读当前 diff，报 bug 与质量发现（只读）
/code-review --fix # 审完把修复应用到工作区
/code-review --comment # 把发现发成 PR 内联评论（对外发布面）
/simplify # 质量线清理并直接改码；不抓 bug，让位给 code-review
/verify # 跑真实应用验收改动，人审前的前置闸
/run # 启动并驾驶本项目应用，看改动真实生效（不只跑测试）
/security-review # 安全专审（裸名件，行为以实测为准※）
档位（low/medium/high）以调用参数形式给出，描述未固定语法，具体形态以 harness 内建帮助为准※。四件均无需配置文件、无需 API key、无需市场安装。
日常效率首选榜：code-review（档位 + 双旗标，写面控制最精细）＞ verify（五场景 + 人审前闸，工位最清晰）＞ simplify（动手件，领域窄但确定性高）＞ run（依赖项目可跑，场景最硬）。 设计教科书榜：simplify（让位句三段式）≈ claude-api（TRIGGER/SKIP 与误触发代价）＞ code-review（档位代价曲线）＞ verify（场景清单 + 流程坐标）。 谜团观察榜：security-review / review / init——出厂 provenance 加裸名无描述，行为待实测※。 给后来者：再造一个泛用 diff 审查件没有增量——code-review 的档位文档和双旗标已经是这个品类的完成时。真正空着的是两把椅子：官方没坐的 /debug，和市场端没人自报的写面等级。
[!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 等场景全覆盖。