10  小规模怎么做（环境层）

这一章和 章节 16 是全书的分界线。没有它们， 前面几章就是一次博物馆导览 ——“看，我建了这些”。有它们，才是一本工具书。

所以这一章有一条硬约束：不许出现任何需要重基建的建议， 每一条都要能在一周内、用现有工具链落地。

10.1 先分清必需前提和特定选择

前面五章里的东西混着两类：这套方法的必需前提，和我这个团队的 特定选择。分不清这两者，你会以为门槛比实际高十倍。

必需前提只有三条：一条主干加短生命周期分支、一个能在合并前跑的自动检查入口 （任何 CI 都行）、一个 Agent 能读到的常驻文件。就这三条。

下面这些都不是前提：单体仓库不需要；特定的构建系统只有 小节 7.2 那一节需要；自建 CI 机器不需要；远程缓存不需要； 二十几万行的自研工具链不需要；二十几条自动检查规则不需要， 而且一开始不该有。

最后一条不是客气话。小节 15.5 讲过：我的第一条自动检查 比 Agent 规模化晚了整整两个月，因为在那之前根本不知道该拦什么。

10.2 三件一周内能落地的事

按投入产出比排序。

10.2.1 一、把常驻文件重写成「带失败形态的规则」

投入半天，产出立竿见影。

方法是把现有的每一条规则补上两句：不遵守会怎样，以及怎么修。

判据很硬：如果一条规则你写不出它的失败形态，那它可能不该存在。 这个测试比它听起来严格得多 —— 大部分团队的规范文档里有相当一部分条目 写不出具体的失败形态，而它们是品味，不是规则。品味应该在评审里表达， 不该占用常驻文件的位置。

顺带做第二件事：按 小节 8.3.1 那三条判据筛一遍， 而第三条（“它能否被写成结构”）通常会筛掉最多。

举个真实的例子。如果你的规范里写着”不要在业务代码里直接读环境变量”， 那么正确的做法不是把这条写得更醒目，是建一个配置模块， 然后加一条检查禁止业务代码直接读 —— 规则从文档移进了结构， 常驻文件少一行，而约束更强了。

10.2.2 二、给最危险的三条路径写一份清单

投入一天。

选哪三条？按”出错之后能不能重试挽回”来选。 绝大多数团队的答案 是同样的三条：数据迁移、发布与部署、认证与权限。

每条只需要四个字段：哪些文件会触发、必须保持什么（一句自然语言， 写给人和 Agent 读）、动手前读什么（一到两个链接）、完成后跑什么（一条命令）。

不需要任何工具支持 —— 一个 Markdown 文件加一条 CI 检查就够了： 如果本次改动触到了这些路径，把对应的段落打印出来。

先不要写禁止模式。 小节 14.4 已经说明，那是需要拿真实数据 调的，而你现在还没有数据。先打印，让 Agent 和人都能看到，跑一两个月再说。

10.2.3 三、把退出码分成三种

投入半天。这是全书投入最小、收益最被低估的一条。

0 通过、1 内容违规、2 基建故障。

实测数据：取样的 500 次 CI 失败里 119 次是基建故障 —— 接近四分之一， 而构建阶段更是每三次红灯就有一次不是代码的错。

如果这些红灯都被当作”你写错了”丢回给 Agent，它会去改本来正确的代码， 而且会改得很有信心 —— 因为它手里确实握着一个红灯。

具体怎么做：在你的 CI 脚本里，把”工具没装”“依赖拉不下来”“执行器起不来” “超时”这几类失败单独识别出来，返回 2。然后在给 Agent 的提示里说清楚： 看到 2 就不要改代码。 这一条不需要任何新基建， 它只需要你的 CI 脚本多几个 if。

10.3 决定要做多少的是重复判断的频次

不是仓库大小，不是团队人数。判断该不该加一条机制的标准只有一个： 同一个判断你做过几次？

第一次直接改，不要建机制。第二次记一笔 —— 写进常驻文件或说明文档。 第三次才把它变成一条能自动跑的检查。

一个人的项目，写清楚一份常驻文件就够了。一个五人团队， 前两条加上那三条路径清单就够了。别从治理系统开始。

10.4 什么时候不该做

这一节用来对冲全书的推销倾向。四种情况下，不做比做好。

项目生命周期短于六个月。 规则的收益来自复利，它拦下的第一百次 比第一次值钱得多 —— 而你等不到那个时候。

单人且不用 Agent。 你自己就是那个判定，把判定外化的成本 在这个规模下换不回收益。

团队还没就”什么是对的”达成一致。 这时候写规则会把分歧固化成机制， 而机制比争论更难改 —— 一条写进 CI 的规则，反对它的成本远高于 反对一句口头约定。先吵完，再写规则。

规则的误报率会超过 5%。 小节 15.6 讲过：会被绕过的规则比没有规则更糟， 因为它还在消耗信任 —— 而信任一旦被消耗，下一条规则（哪怕它是对的） 也会被同样对待。如果你还没有足够的真实数据来校准规则边界， “还没到时候”是一个正确的答案。

10.5 五人团队的第一个月

把上面的东西排成一个可以照着走的月度计划。

第一周重写常驻文件（带失败形态）加上退出码三分。 第二到四周什么都不加，只观察 —— 记下每一次你在评审里说的话， 重复三次以上的那句就是你的第一条规则；同时记下每一次 CI 红灯， 标注它是代码问题还是基建问题，这个比例会告诉你退出码三分值不值。 第二个月把第一条规则写成检查，先只报数不拦。

这个节奏看起来很慢，但它是我唯一推荐的节奏。理由在 小节 15.5： 在你撞过之前，你不知道该拦什么。 而从别处抄来的规则， 误报率会高到让整套东西失去信任。

10.5.1 一个月之后该看什么

一个月之后，你手里应该有三样东西，而每一样都有验收标准。

一份短的常驻文件，每条带失败形态。 验收方式是随便抽三条， 让另一个人（或另一个 Agent）读完之后说出”不遵守会怎样”—— 说不出的，还没写好。

一份评审语句的记录。 你记了一个月你在评审里说了什么， 现在按语义分组，看哪一句说得最多 —— 那句话就是你的第一条规则， 而且它已经被”挣得”了。

一个红灯的分类。 十次以上的红灯，每一次标注了代码问题还是基建问题。 验收看基建问题的占比：超过 15% 说明退出码三分对你有立竿见影的价值， 低于 5% 可以先不做，但要知道这个比例会随依赖增多而上升。

10.5.2 常见的第一个错误

按经验，小团队在这条路上最常犯的第一个错误是： 建了检查，但没建”这个检查坏了会怎样”的答案。

具体表现是一条 CI 检查跑了三个月一次都没红过， 而没有人怀疑过它是不是还在工作。这正是形状 A 里最危险的那个变体 —— 探针失效但仍在输出。

修法极其便宜：让每条检查打印它的工作量 —— 扫了多少文件、 跑了多少用例、处理了多少条。一行输出，而它把一个静默的失效 变成了一个可见的数。而且要从第一天就打印它， 因为等你想加的时候，你已经没有历史数据可以对照了。

10.6 三个可以立刻做的十分钟练习

不用读完全书，这三个练习各花十分钟，而且各自会产出一个具体的行动项。

10.6.0.1 练习一：数一数你的常驻文件

打开它，数三个数： 总行数、写不出失败形态的条目数、能写进结构的条目数。 第二个数应该是零，第三个数是你的待办清单 —— 而如果总行数超过两百，先做第三项，那通常能砍掉最多。

10.6.0.2 练习二：列出不可逆的动作

在纸上列出 你系统里”做错了重试挽回不了”的动作，提示是涉及外部世界的、涉及删除的、 涉及钱的、涉及身份的。对每一个问：改哪些文件可能导致它？那些文件路径 就是你的第一批路径清单。大部分团队做完这个练习会发现： 不可逆的动作比想象中少，通常三到五个 —— 而它们全都没有被特殊对待。

10.6.0.3 练习三：翻最近十次 CI 红灯

逐个标注是代码问题 还是基建问题。如果基建问题超过两个，退出码三分对你有立竿见影的价值。 如果你标注时发现自己说不清某一次是哪一类 —— 那本身就是一个信号：你的失败信息不够定位。

这三个练习各自对应一个核心主张，而且都不需要相信那个主张才能做： 数常驻文件验证”规则的载体决定它是否生效”，列不可逆动作验证”判定的价值 来自不可逆性”，标注红灯验证”判定必须有第三态”。做完之后你会有自己的数据 来判断这些主张成不成立 —— 而这比读一百页论证有用。

这也是我对读者唯一的要求：不要相信我，去量一下。 如果量出来的结果和我说的不一样，那说明你的系统和我的不一样， 而你的数据比我的数据更适用于你。

10.7 逐条对照：前面五章里哪些能用、哪些不能

把第二部逐章过一遍，标出小团队的适用度。

章节 6（Codebase）里七条内容，五条完全适用而且零成本： 「被挣得」原则、角色由”怎么获取”决定、第四格 Testing/、 演进纪律、按变更原因拆文件。共享层按能力组织要有共享层之后才适用， 而 worktree 隔离基本不适用，除非你真的在并行跑多个 Agent。

「被挣得」原则为什么在小团队更重要？因为小项目更容易为了”以后会用到” 而提前分层，而且代价更大 —— 在一个只有三十个文件的项目里， 一层空目录稀释掉的信息量占比更高。

10.7.1 不要为了「以后好扩展」提前分层

这是小团队最容易犯的一个错，而它的理由在 小节 6.2 已经讲过。 这里补一个小团队特有的：在一个三十个文件的项目里， 一层空目录稀释掉的信息量占比更高。大项目里一层多余的目录是噪声， 小项目里它可能是一半的噪声。

章节 7（架构）里，只有依赖图那一节不适用，其余全都适用。 “一份声明派生多端”值得展开一句：它不等于”你得写一个编译器”， 它的最小形态是一份 JSON Schema 加一个生成脚本， 关键不在工具多好，在于从此只有一个地方可以改。 如果你现在只有一个客户端，这一条暂时不适用 —— 它的收益随”端”的数量增长，两端时开始考虑，三端时必须做。

章节 8（载体）整章完全适用，零基建，而且这是全书对小团队 最有用的一章。唯一需要调整的是规模：五种载体里小团队通常只需要三种 —— 常驻文件、按需查阅的说明、路径清单。skill 和跨会话契约要等到 你真的在跑周期性长任务时才需要。

章节 9（工具链）是最难的一章，但也是收益最陡的一章。 不需要造一整套工具 —— 三个阶段里第一阶段（让 Agent 能看见它改了什么） 通常只需要几百行胶水代码，而它是从”完全瞎”到”能看见”的质变。 具体到不同类型的项目：Web 前端是一个能截图并返回控制台日志的脚本； 后端服务是一条能查最近日志和当前状态的命令；命令行工具是一个能跑起来 并捕获完整输出的封装；移动端最难，但模拟器截图加日志已经能解决大半。

10.8 改写示范：走完一条

把 小节 10.2.1 那半天的工作具体化， 拿一条真实的、几乎每份规范里都有的规则走一遍。

改写前：

修改数据库相关代码时要小心。

这一条有三个问题，而它们各自对应一种失效。 它没有失败形态 —— 读者不知道不小心会怎样， 所以他也不知道该多小心。它没有触发条件 —— “数据库相关代码”是哪些文件？读者得自己判断， 而不同的人（和不同的 Agent）会判断出不同的范围。 它没有可执行的动作 ——“小心”不是一个动作， 一个执行者读完之后不知道该做什么。

改写后：

改动 migrations/ 下的任何文件之前，先读 docs/data-integrity.md。 迁移只能演进 schema：加列、加索引、加表、删一张已经没有写入的表。 绝不整表清空、绝不删分区 —— 这两种删掉的行没有任何回滚能还原， 而这类事故在恢复上通常意味着从备份重建，代价以小时计。 删一张退役的表是可以的，但必须同时写一份能跑通的回滚脚本。 改完之后跑 make check-migrations。

改写后的版本长了五倍，而它多出来的每一部分都有作用： 路径给了触发条件，“只能演进 schema”加上四个例子给了边界， “没有任何回滚能还原”给了失败形态和不可逆性， “删一张退役的表是可以的”给了允许什么（小节 14.13 讲过这一条最容易被漏、也最省事）， 而最后一句给了可执行的验证动作。

这一条改写大概花二十分钟，而一份规范里通常有八到十条值得这样改。 半天的估计就是这么来的。做完之后你会发现一件事： 有一批条目改不动 —— 你写不出它们的失败形态， 也想不出验证动作。那些就是该被移走的品味（小节 10.13）。

10.9 三件事各自的验收标准

小节 10.2 给了三件事和它们的工时，但没给验收标准 —— 而”做完了没有”这个问题，在这一章里应该有答案， 否则它就违反了自己讲的那条纪律。

第一件（重写常驻文件）的验收是：随机抽三条， 让另一个人（或另一个新会话的 Agent）读完之后回答 “不遵守会怎样”和”我该怎么做才算遵守”。两个问题都答得上来才算过。 注意验收的对象是读的人，不是写的人 —— 写的人永远觉得自己写清楚了。

第二件（三条路径清单）的验收更硬：故意提交一次触到那些路径的改动， 看那段文字有没有出现在 Agent 的上下文里。 没有出现，那这份清单等于不存在—— 而这一步的失败率比想象中高，因为”写下来”和”被读到”之间 隔着一整套发现机制（小节 8.4.1）。

第三件（退出码三分）的验收在 小节 11.8.0.1 讲过： 找一次真实的基建故障，看 Agent 那一轮做了什么。 它改了代码，就是没做完。

三条验收有一个共同结构：它们验的都不是”我做了这件事”， 而是”这件事产生了预期的效果”。这个区别在这一章尤其重要， 因为这三件事全都很容易做出一个形式上完成、实际上没生效的版本 —— 一份没人读的文件、一份不会被触发的清单、一个没人消费的退出码。 三种失效都是静默的。

10.10 三种规模的具体配置

给三个规模各一份具体的目标状态，可以直接对照。

10.10.0.1 一个人

常驻文件 40–80 行，每条带失败形态； 路径清单一到两份，只覆盖不可逆的；自动检查一条 —— 测试执行数不为零； 退出码三分值得做，因为你没有第二个人帮你判断红灯真假； 而工具链是投入最值的一项 —— 让 Agent 能看见它改的东西。

一个人的系统里，工具链的优先级高于检查层。因为你自己就是那个判定 （至少在早期），但你不是那双能替 Agent 看界面的眼睛。

10.10.0.2 五到二十人

常驻文件 80–150 行； 路径清单三到五份；自动检查三到八条，其中至少一条是报数模式； 债务台账在存量大到不能一次清完时引入；工具链做到第一、二阶段。

这个规模是我主要想写给的人，也是”载体分类”收益最大的规模 —— 因为人开始多到非正式沟通兜不住边界了（小节 7.10.1）。

10.10.0.3 二十人以上，或大量并行 Agent

全书内容基本都适用， 而且会开始需要那些标着 ⚙️ 的东西 —— 依赖图、只测受影响的、语义规则。 但顺序仍然不变，不要因为规模大就跳过前面的步骤。

10.11 小团队特有的两个优势

这一章到目前为止都在讲”大规模的东西怎么缩小”， 但小团队在这件事上有两个大团队没有的优势，值得说清楚， 因为它们改变了投入的优先级。

第一个优势是你还能改结构。 一个三十个人、 五年历史的仓库里，小节 6.2 那条”被挣得”原则 只能用于新增的部分 —— 存量的结构已经被几百个引用锁死了。 一个五个人、一年历史的仓库里，一次目录重构是半天的事。 这意味着小团队可以直接做 小节 5.7 的第三层， 而大团队只能停在第一层然后靠检查兜。

具体的推论是：小团队在”该加一条规则还是该改一次结构” 这个选择上，应该更倾向于后者。一条规则是永久的维护成本， 一次结构改动是一次性的 —— 而这个权衡在存量大的时候会反过来。

第二个优势是你的失败样本是干净的。 五个人的仓库里，每一次故障你都知道是谁、在什么情况下、 基于什么判断做出来的。这正是 小节 14.4 那种调参所需要的东西 —— 大团队里那份”翻了一遍仓库， 26 个迁移文件里有 69 处是合法的表退役”的工作量， 在小仓库里可能只有五分钟。

规则的边界调得准不准，取决于你能不能穷举语料—— 而小仓库的语料是可以被一个人一天读完的。 所以小团队的规则误报率天然可以做得比大团队低， 条件是真的去读那些语料，而不是照抄一条别处的规则。

这两个优势合起来给出一条建议：小团队不该把这套东西 理解成”大公司做法的缩水版”。它是一个不同的最优解—— 更少的规则、更多的结构、更准的边界。

10.12 三个真实场景的具体建议

抽象的建议不如具体的处境。给三个常见的。

10.12.1 场景一：五个人，一个 Web 应用，刚开始用 Agent

现状通常是：单仓库、npm 或 pnpm、一套 CI、有一份写得不错的 README。

第一周把 README 里那些”约定”抽出来，写成常驻文件，每条补上失败形态 —— 大概率会从二十条压到八条。第二周给 Agent 一个能看到界面的方式， 一个截图脚本加一个控制台日志抓取，这是工具链的第一阶段， 通常一两百行。第一个月做退出码三分，因为你们的 CI 里 大概率已经有一批”依赖装不上”的红灯。

不要做任何规则 —— 观察一个月，看评审里重复说什么。

10.12.2 场景二：二十个人，一个后端服务加几个客户端

现状是多仓库、各自的 CI、已经有一些 lint 规则。

这个规模的核心问题通常是跨仓库的约定没有载体 —— 接口契约、错误码、认证方式，这些约定散在几个仓库的文档里， 而没有任何一份是权威的。

第一件事是把接口契约做成”一份声明派生多端”（小节 7.1）， 不需要写编译器，一份 schema 加一个生成脚本就行。第二件事是给 最危险的三条路径写清单，后端这边通常是迁移、发布、认证。 第三件事是让本地和 CI 跑同一条命令 —— 这个规模上， “本地是好的”已经开始出现了。

10.12.3 场景三：一个人，多个小产品

这个场景和我那个仓库最像，只是规模小几个数量级。

优先级是工具链 > 载体 > 判定。理由在 小节 10.10.0.1： 你自己就是判定（至少在早期），但你不是那双能替 Agent 看界面的眼睛。

载体排第二，是因为一个人最容易犯的错是”我知道就行了”—— 那些没写下来的约定，在你自己下一次开新会话时就已经不在场了。 一个人的系统里，常驻文件不是写给别人的， 是写给三个月后的自己和每一个新会话的。

10.13 已有的规范该怎么改造

大部分团队不是从零开始的 —— 手里已经有一份写了两年的规范文档、 一份 onboarding 文档，或者一份”AI 使用指南”。 这一节讲怎么改造它，因为改造比新建便宜，也比新建准确： 那份文档里的每一条，至少都对应过一次真实的讨论。

做法是逐条过一遍，每条问三个问题，而三个问题的顺序不能换。

第一问：它能被写进结构吗？ 能的话，写进去，然后从文档里删掉。 这一问放在最前面，是因为它砍掉的最多 —— 一份典型的规范里有三到四成的条目属于这一类， 而它们留在文档里的唯一效果是被读到（或者读不到）， 写进结构之后是被强制执行。

第二问：它有失败形态吗？ 写不出”不遵守会怎样”的条目， 是品味不是规则。品味不该被删掉，它该被移位—— 移到评审里、移到一次口头讨论里， 而不是占用一份 Agent 每次都要读的文件的位置。

第三问：它需要每次都在场吗？ 不需要的，移进按需查阅的说明 （小节 8.2）。这一问筛掉的通常是那些 “某个具体技术的用法”条目 —— 它们是对的、有用的， 但它们只在做那件事的时候才需要，而不是每次都需要。

三问过完，一份两百行的规范通常会剩下五六十行。 剩下的那些，每一条的到达概率都提高了—— 这是注意力的算术：内容少了三分之二， 剩下每一条分到的注意力就多了三倍。

10.13.1 改造时最容易犯的一个错

最容易犯的错是在删的时候心软，理由通常是 “这条虽然写不出失败形态，但它确实是对的”。

这个理由本身没错，但它误解了这份文件的作用。 常驻文件不是一份”所有正确的事”的清单， 它是一份必须在每一次落笔前在场的清单 —— 而后者的准入标准比前者高得多。 一条正确但不必须在场的规则， 它占用的位置是从另一条必须在场的规则那里抢来的。

判断标准可以说得更硬：如果这一条被违反了， 而你是在评审里发现的，那损失有多大？损失不大的， 说明它可以留给评审，不需要常驻。 损失很大或者不可逆的，才必须常驻。

10.14 三件不该做的事

按遇到的频率排，各自的失败方式不同。

不要先建”AI 编码规范”。 这是最常见的第一步，也是最常见的浪费。 一份从零想出来的规范，它的每一条都没有被真实失败校准过， 于是它同时过严（限制了本来没问题的做法）和过松（漏掉了你还没撞过的坑）。 更糟的是它的信任成本：团队照着它做，撞了一次它没覆盖的坑， 于是这份规范的权威性开始下降 —— 而它下降之后， 它本来覆盖对的那些条目也一起失效了。正确的第一步是重写你已有的东西， 不是新建一份。

不要为了”以后好扩展”提前分层（小节 10.7.1）。

不要在团队还在吵的时候写规则。 失败方式是规则把一方的观点固化成了机制， 而机制比争论更难改。结果是分歧不但没解决，还被埋进了工具里。 判据很简单：这条规则你们讨论过几次？如果超过两次还没有共识， 那它不该被写成规则。

10.15 要不要专人负责

到什么规模需要有人专职维护这套东西？答案取决于一个量：规则集的维护成本。

小节 13.14 那张表里，持续成本只有三项：误报时被打断、 重构时改范围、判断该不该退休。前两项随规则数量线性增长， 第三项通常没人做。

一个粗略的估计：十条规则以内，摊到每个人身上是可忽略的； 超过二十条，需要有一个明确的 owner —— 不一定专职，但要有名字。

这个 owner 的主要工作不是写新规则，是跑那张健康检查清单 （小节 15.13）：每季度一遍，删掉该删的，切换该切的，修掉误报的。 没有这个角色，规则集会单调增长，然后腐化。

10.16 什么时候值得引入构建图

这是第二部里唯一一个需要重基建的东西，所以值得给一个明确的门槛。

引入统一构建系统的成本是巨大的 —— 迁移一个现有项目通常要几个人月， 而且迁移期间的收益是零。它的收益有三块，但只有第一块是它独有的： 反向依赖查询让你能只测受影响的部分，这一块没有便宜的替代； 构建缓存让增量更快，但各语言都有自己的缓存方案； 密封构建让结果可复现，但容器化能解决大部分。

所以问题简化成一个：你需要”只测受影响的”吗？

这个需求有一个明确的触发条件：当你的全量检查时间， 超过了你能接受的单次迭代延迟时。在这之前，全量跑就够了， 而且全量跑还更简单、更可信 —— 没有”影响面算错了”这个失败模式。

大部分五到二十人的团队，永远不会到达这个触发点。 在到达之前引入构建图，付的是全部成本，拿的是三分之一收益。

10.17 六条判据

这一章的最后，把全书那些”把品味问题变成事实问题”的判据集中列一遍。 它们是全书最可移植的部分，每一条都能在十分钟内用完一遍：

判据	用在哪	出处
这一层被第二个实例挣得了吗	目录、抽象、规则	小节 6.2
这条边界换来了什么可测性	架构	小节 7.5.1
这条规则什么时候需要到达	载体	小节 8.2
这道检查坏了会表现成通过还是失败	判定	小节 18.14
出错之后重试能不能挽回	风险等级	小节 14.2
同一个判断你做过几次	该不该建机制	小节 10.3

六条的共同结构是它们都把一个”应该”的问题换成了一个”是不是”的问题。 这个转换的价值在于事实问题在不同的人之间能得到一致的答案， 而”应该”的问题不能 —— 两个人对”这里该不该分层”可以吵一下午， 但对”有没有第二个实例”只会得到同一个答案。

在几十个并行的 Agent 之间，这一点尤其重要—— 因为它们之间没有任何沟通机制来对齐”应该”（小节 7.10.1）。 一个 Agent 不会去问另一个 Agent”你觉得这里该不该分层”， 它会自己做一个判断然后继续 —— 而如果那个判断依赖品味，几十个 Agent 会给出几十个不同的答案。

10.18 和判定层那一章的分工

我用两章讲”小规模怎么做”：这一章讲环境， 章节 16 讲判定。它们该按什么顺序做？

先环境，后判定 —— 而理由不是环境更重要， 是环境的投入在判定建好之后仍然有效，反过来不成立。 一份写好的常驻文件在你加了十条检查之后还是有用的； 而一条建在混乱结构上的检查，会在你整理结构时全部失效。

但有一个例外值得单独说：退出码三分应该最先做， 哪怕它属于判定层。因为它不是一道检查， 它是所有检查的语义基础—— 越晚做，需要改的地方越多。 这条例外在两章里都出现过，不是重复，是因为它确实横跨两层。

还有一条实际的建议：这两章加起来的工作量不要压缩到一个月里做完。 两章的具体建议加起来大概三周的工时， 而正确的节奏是把它们摊到三到四个月 —— 中间那些”什么都不做只观察”的时间， 产出的是你后面每一条规则的依据（小节 16.17）。

10.19 最容易被读错的一句

“每一条都能在一周内落地”这个约束，最容易被读成 “所以一周之内应该全部落地”。不是。

三件事加起来是两天的工时，而正确的日历时间是两三个月—— 小节 16.19 讲的正是这个。两者的差别不在效率， 在于中间那些”什么都不加只观察”的时间是必需的产出， 不是等待。

这一句之所以容易被读错，是因为工时和日历时间在别的工程任务里 通常是同一个数量级的东西 —— 两天的活，一周内做完是合理的。 这里不是，因为这三件事里有两件的质量取决于你手里有多少数据， 而数据只能靠时间攒。

具体地说：常驻文件的改写质量取决于你对”哪些规则真的重要”的判断， 而那个判断在观察一个月之后会明显不同； 第一条报数规则的选择取决于你在评审里重复说了什么， 而那需要真的记一个月。 只有退出码三分是一件纯工程的事，它可以第一周就做完。

所以这一章的正确读法是：它给的是一个两三个月的计划， 其中动手的部分加起来只有两天。而如果你把它压进一周， 你会得到三件形式上完成、内容上基于猜测的东西 —— 而那正是 小节 15.11 那张表里误报率最高的那一类。

10.20 一条元建议

如果这一章的所有具体建议都不适用于你的处境，那么记住这一条： 不要先建系统，先建测量。

你现在不知道你的瓶颈在哪 —— 是判定慢，还是失败信息差， 还是 Agent 够不着某些东西。这三个的解法完全不同，甚至互相冲突： 加机器、改信息、造工具，三条路的投入方向没有交集， 选错一条不只是浪费，还会让你误以为”这套方法对我们没用”。

所以第一步永远是量三个数（小节 17.7）， 看它们的关系，判断自己在哪个稳态（小节 17.15）。 这一步的成本是几天，而它决定了后面几个月的投入方向。

它还有一个额外的好处：这三个数本身就是这套系统的第一个观测器—— 建完之后，你就有了一个能看到”这套东西还在不在工作”的东西。 这一点在半年后会比现在更值钱，因为半年后你会有十几条规则、 几道检查、几个工具，而没有任何一个会主动告诉你它已经不工作了。