核心观点 八天里 AI 犯的错可以归成十一种模式，每一种都有判据和对策，而且几乎每一种都是所有者当场纠正出来的。账本上的数字说明速度从哪来、责任在哪；回到第 02 章的问题：AI 改变了生成的成本，没有改变判断、验证与责任的必要性。
下面每一条都来自 Agent X-Ray 的真实记录——任务卡的审查段、BACKLOG、发布记录，或者所有者纠正后写进记忆的条目。格式统一：现象、为什么危险、判据、对策。
蓝图上是一个盒子；做出来的盒子上多了塔楼、旗子和栏杆。所有者指着蓝图。
1. 自己加戏。 现象：把一条合理的 findings 变成一个没人裁定过的功能（会话命名时机从「第一轮」改成「模型自己判断的某一轮」）；或者顺手加一道不在威胁模型里的防线（链接 scheme 过滤）。危险：范围失控，而且每一处都「有道理」。判据：这个改动在画板、任务卡、威胁模型里有没有？对策：没有就停下问所有者；不在威胁模型里的防线一条 findings 就该删。
2. 审查代替设计。 现象：连续五轮 findings 落在同一块自建机制上，每轮补一块。危险：长出一个没人设计过的解析器。判据：连续两轮 findings 落在同一处，且那一处是任务卡里没有的。对策：停，把边界说成一句话，找不需要理解输入结构的办法，列选项让所有者裁定。
3. 审查没过就构建。 现象：审查还在跑，镜像构建已经后台发起。危险：审查要整改，SHA 变，镜像白打。判据：分支合并了吗？对策：构建、发版、起容器验证都放在合并之后。
4. 按行修，不按模式修。 现象：一条 findings 指向「两条查询不在同一快照」，只改了报的那一处，下一轮同类又来。危险：多跑一轮审查。判据：这条 findings 描述的是一处还是一类？对策：先在同一份 diff 里 grep 同类位置一起改。
5. 把 agent 的总结当验证。 现象：「功能已完成」后面没有命令与结果。危险：配置错误、类型错误、运行时问题留到人工使用时才暴露。判据：有没有实际命令和输出？对策：任务卡「本轮实测」段逐项写；「未验」也要写出来。
6. 生成物与清单漏同步。 现象：新服务漏补进构建白名单，按那个提交构建整站 500；skills 镜像漏同步，审查悄悄退回旧清单；画板计数三处不一致。危险：表现是静默的——404、少查、自相矛盾——不是报错。判据：每个「要改多处」的东西有没有一致性检查？对策：计数核对、冒烟清单第一条、CLAUDE.md 明确写「新增一个要改三处」。
7. 公开前不洗资产。 现象：用区分大小写的 grep 扫公司名，报「干净」，结果目录名是小写的，里面还有品牌位图；提交的作者邮箱、绝对路径、私有统计数字也差点带出去。危险：法律与隐私风险直接写到公开站点上。判据：不区分大小写、扫目录名、扫中文机构名、扫邮箱。对策：清单化，逐项过。
8. 不看 LICENSE 就再分发；「上游原版」不 diff。 现象：三个 skill 在公开仓库里也有，目录内的许可文件却禁止再分发；三个「上游原版」逐文件比对后只有一个一致。危险：再分发违反许可；把本机改动当上游内容发，或抹掉上游署名。判据：目录内的许可文件，不是仓库是否公开；diff 过才算原版。对策：发布前逐个看许可、逐文件比对。
9. 把环境假象当代码问题。 现象：新工作树测试红三条（缺 secrets 文件）；docker 挂载路径被改写（容器起来就退出）；审查任务假死 38 分钟（进程随启动器退出）。危险：头十分钟在错误的方向上排查。判据：这个现象在用户级 CLAUDE.md 或项目记忆里有没有？对策：先查记忆，再查代码；坑记进对应层。
10. 在自动模式做「关掉 → 验证 → 开回来」。 现象：关得掉，开不回来——「在生产打开 agent 工具」被安全分类器拦下，生产留在半开状态一轮。危险：验证动作本身改变了生产状态。判据：这个动作的逆操作能不能在当前模式下执行？对策：先请所有者切模式；遇拒就停下，不换写法重试。
11. 判据用错。 现象：用某个常见命令验镜像里有没有旧运行时，基座自带一个软链，结论是错的；用境内不可达的网页当验收用例；用境内不可达的公网地址当存活探针。危险：验证通过或失败都不说明问题。判据：判据本身有没有被验证过？对策：错了改判据不改结论；正确判据写进冒烟清单。
十一条里，第 1、2、3、8 是所有者当场纠正的，第 4、6、7、9、10、11 是实测撞上的，第 5 是流程从第一天就防着的。它们的共同点是：没有一条是「模型不够聪明」。每一条都是能干的 agent 在没有边界、没有判据、没有记忆的地方，用自己的判断补上了空白。
左页是每天的提交，右页是审查过的记录。两页是同一本账。
进度。
| 项 | 数字 |
|---|---|
| 时间 | 2026-08-28 至 2026-09-04，8 天；第 6 天投产 |
| 提交 | 202 次；按日 18 / 4 / 42 / 40 / 44 / 44 / 10 |
| 轮次 | 进度表 24 行，加 1 轮进行中 |
| 数据库迁移 | 生产 13 个；进行中的一轮带第 14 个 |
| 管理面工具 | 28 → 34 → 42 → 46 |
| 设计画板 | 15 → 12（删 5 加 2）→ 15 → 18 → 20 |
| 生产发版 | 7 次 |
审查。 进度表里记了数的轮次相加：67 轮审查、118 条 findings（有两轮只记了部分数字，未计入）。三轮由所有者裁定跳过，理由与残留风险写在任务卡。零 findings 的轮次存在（R-TABS 首轮）；最多的一轮 18 条（管理面）；最长的一轮 7 轮（读网页，其中 5 轮在一块自建机制上）。
时间去了哪。 按每轮 6 到 17 分钟的基线乘以 67 轮，单是等待审查就在十小时量级。环境坑每次十来分钟，记忆里有六条这样的条目。返工：七轮消毒器删掉约 90 行代码与约 80 行测试；一次回滚。文档回填：每轮任务卡加 ROUNDS.md 进度表加发布记录，每轮都有。
哪些是必要成本：审查等待、文档回填。哪些可以省：第 2 到第 6 轮的消毒器（应该在第 2 轮停）、白打的镜像、环境坑的重复排查（记忆之后不再重复）。
速度从哪来。 不是从跳过步骤来的。每一轮都有审查记录，每一次发版都有留证。速度来自：实现 agent 不需要人逐行读代码，因为验收表、审查记录、发布留证已经把「什么被验证过」写清楚了；所有者的时间集中在裁定上，一张十条的冲突清单几分钟裁完；agent 的第二个会话不需要重学第一个会话踩过的坑。
回到第 02 章的问题：演示成功与工程成功。
变了的是生成的成本。 八天做出一个投产的站点，二十几轮，每轮从任务卡到合并大多在一天之内。这在 AI 之前是不可能的节奏。
没变的是三件事。
判断没变。哪些功能进边界、哪个方案的代价可以认、哪条 findings 不采纳——每一个都是人做的。账本上「所有者裁定」出现的次数比任何一个技术名词都多。
验证没变。agent 说完成不算完成；数字要量出来；判据本身也要被验证。第 17 章那 281 篇全量比对，在 AI 之前也是这么做的，只是现在做得起了。
责任没变。跳过审查要留痕，接受残余风险要写「已认」，线上留了一条测试会话要记 BACKLOG。责任不能交给 agent，因为 agent 没有跨会话的记忆，也不承担后果。
AI native 不是让人做得更少，是让人做的每一件事都不可让渡。
诚实地说，这套系统是在特定条件下长出来的：一个人的项目，一个实现 agent，一个审查 agent，个人站点的量级。换一个条件，有些东西要变：
但骨架不变：边界要可查证，验收要可证伪，写代码的不审自己的代码，裁定要落文档，偏离要留痕。
站点还在迭代。BACKLOG 里有几十条待裁定的事：门禁要不要加类型检查、Skills 页要不要显示「agent 可用」徽标、卡片与轨迹面板要不要互相定位、出网过滤的那个缺口什么时候补。它们都在等一个裁定，然后走同一条流程。
这本教程也是同一条流程的产物：大纲经所有者裁定，每章有案例来源可查证，配图经过同一套转换与命名。它会随着项目继续长——新的轮次会带来新的案例，新的失败模式会加进第 21 章。
用同一张账本格式记录自己下一个项目的第一周：提交、轮次、审查轮数与 findings、发版、跳过的步骤及理由。第一周结束时对照十一种失败模式，标出自己撞上了哪几种，每一种写下当时的判据本该是什么。
苏公网安备32011402012723号