# 四动词官方答卷：效率赛道出厂件横评——审查、重构、验收三份半，调试缺编 ## 概述 ## 一、选题逻辑：市场答卷犁完之后，官方自己的卷子没人翻过 先自证白地是真的。效率赛道至今入档的每一件——四座山、三路线、七件调试、规格层、文档层、浏览器四层手——全部来自市场端或装机端：有仓库、有星数、有货架。而本会话注册表上还躺着另一类东西：`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 所用）显得过苛，改按名字级中间值给分，全行标注※。 ## 三、四动词岗位图：一张缺了一条腿的编制表 ```mermaid 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 的出厂件（基于本会话注册表一手清点※）。这是本期最重要的结构性发现，展开见第八节。 ## 四、主拆一：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。** 不审整个仓库，只审「当前 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 **改**。让位句之外的第二种划界术，见下一节。 ## 五、主拆二：simplify——让位句教科书与「altitude」的品类词 描述原文照录：*"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 + run——判断与驾驶的双件套 **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 的价值恰恰在变局之上恒定：总得有谁决定验收算不算完成。 ## 七、裸名双件、TRIGGER 特化件与邻区边界 **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 发行，**零安装**，斜杠即调： ```bash /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 等场景全覆盖。