从这里开始 ——
AI 翻车以后 · 最没用的一句话是 ——
"对不起 · 我下次注意。"
如果没有记录、分类、反例和防复发动作 · 下次它还会用另一种方式回来。
本篇一句话
这一篇写的是 —— 失败只有进入系统 · 才会变成资产。AI 做网站最容易让人误解的一点 · 是它看起来总在进步；但真正让系统变强的 · 不是顺利的一次生成 · 而是每次翻车以后能不能被记录、分类、复盘 · 并变成下次自动少犯错的门禁。
结构图 · 失败如何变成资产
diagram · CH08
01
失败现场
02
错误分类
03
MNK
04
ERRORLOG
05
防复发脚本
这张图说明 —— 失败只有进入"记录 → 分类 → MNK → ERRORLOG → fixture / validator / SOP → 下次任务前自动检查" 这条流水线 · 才会变成资产。否则失败只是情绪消耗 · 下一次它会用另一种姿势回来。
1. AI 的错误为什么那么顺滑
AI 的错误和人的错误不太一样。
人的错误经常很粗糙 —— 报错、卡死、说不出话、白屏。
AI 的错误经常很顺滑 ——
- 用很完整的格式 告诉你"已完成"。
- 用很专业的词 解释为什么这么做。
- 生成看起来像样的 Markdown。
- 把"候选" 写得像"落地"。
- 把"本地验证" 写得像"生产可用"。
- 把"知道" 写得像"做到"。
这类错误最危险。
它不像空白、不像报错。它看起来很像工作。
所以我后来对几类词特别警惕 ——
已完成
已进入程序
已验证
自动继续
无需 oldA 操作这些词不是不能用。但每次用 · 都必须有证据 ——
- 文件在哪里？
- 验证在哪里？
- 截图在哪里？
- 失败项在哪里？
- 下次怎么避免？
没有证据的"完成" · 会遮住问题 · 直到它在更贵的地方再爆出来。
这是顺滑的失败（CH05）和假完成（CH06）在第 7 章的另一种表达 —— 同一种隐性税 · 在不同章的不同位置。
2. 失败不进系统 · 就只是情绪
失败本身不可怕。可怕的是失败没有留下痕迹。
- 如果今天 AI 假完成了一次 · 我只是生气 · 让它重做 —— 明天它还会换一种方式假完成。
- 如果今天一个页面把不该给读者看的工程信息误写到了前台 · 我只是删掉 —— 下次另一个 AI 可能又会犯。
- 如果今天我说"自动继续"、AI 却停了 · 我只是再说一遍 —— 下次换个对话框 · 它还是可能停。
这不是 AI 不聪明。
这是系统没有记住失败。
而"系统记住失败"不会自动发生。它需要老A 自己每一次都做一件无聊的小事 ——
把这一次的失败 · 翻译成一条规则。
如果不翻译 · 失败就只是情绪。情绪会消耗 · 但不会沉淀。沉淀只发生在被翻译之后。
3. 7 类错误 · 第一次给失败建表
我后来给自己积攒的失败列了一张表 —— 7 类错误（E1-E7）。
这张表是给我自己用的 · 但每一类都对应一种真实发生过、被反复抓到的失败模式 ——
| 编号 | 错误类型 | 表面现象 | 应沉淀成什么 |
|---|---|---|---|
| E1 | Task DSL 文件名错位 | 任务 ID 与文件名不符（filename ≠ task_id.json）· 校验器漏过 | 文件名 = task_id 的强约束 + 反例 fixture |
| E2 | 范围检查 白名单缺失 | 好内容 改动提议 因为路径不在白名单被挡 · 或不该被允许的路径被放进 | 路径白名单 预检脚本 + 路径表 |
| E3 | Chinese docs vague-scanner 幻觉 | 报告了中文文件里不存在的英文 vague 词 | 中文治理文档 fixture · 要求 0 unverified hits |
| E4 | 评分算术漂移 | 报告头部的分数 ≠ 减分项相加 | 分数 = 100 - sum(penalties) 算术校验器 |
| E5 | 每日 proof 重复触发 | 同一天的标题在 PROOF_OF_WORK 出现两次 | 幂等检查 · 已存在则跳过或替换 |
| E6 | 提交后 ledger 无限追逐 | 提交 ACTIVE_THREADS 时 · post-commit hook 又产生一行新脏数据 | 接受"一行脏数据"为临时事实 · 下次任务再 flush |
| E7 | baseline JSON 畸形 | 生成的 JSON 含杂散字符 · 不可解析 | 写入前 JSON parse 校验 + 测试 |
这张表的价值不在每一类的名字 · 而在"失败可以被分类"这件事本身。
分类之后 · 失败就从"我又踩坑了"变成"这是第 E2 类的一种新变体"。
情绪从"挫败"变成"被分类完毕 · 进入下一步动作"。
4. 两次属于自己的 改动提议 自咬
7 类里 · E2（范围检查 白名单缺失）我自己咬过自己两次。两次都不涉及第三方 · 都是我的项目咬了我自己。
自咬 1 · 一份本来很干净的内容 改动提议 被自己的白名单挡住
我推一个内容 改动提议 · 准备合并。所有检查全部 PASS。但 范围检查 报错 —— 因为我新增的目录不在 第一层白名单里。
这个目录本身没有问题。问题是 ——
- 我没有先读
check-diff-scope.mjs。 - 我没有事先把目录加进白名单。
- 我把白名单想成"事后阻挡机制"· 其实它是事前必读机制。
教训 ——
路径白名单 是安全边界 · 不是不便。它不接受"先做后申请"。所有想新增的路径 · 必须先在白名单里 · 才能开 改动提议。
自咬 2 · 改动说明 写了不属于本次 task 的内容
另一次 · 一份 改动提议 的 body 里混入了另一个 任务编号 的描述。交叉污染。
改动说明 是任务收据的一部分 —— 任务编号 的纯度 决定了"这份收据能不能被自动归档"。
混入另一个 任务编号 之后 · 整份收据不能自动归档 · 必须人工修复。
教训 ——
每一份 改动说明 只服务于一个 任务编号。交叉污染等于把两份收据都污染掉 · 不是"顺便记一笔" —— 是"两边都废掉"。
这两次都属于 E2。都是我自己的项目咬了我自己。都没有外部受害者 · 但都让我自己丢了 1-2 小时。
把它们写下来 · 是为了下次开 改动提议 时 · 这两条会自动浮现。
5. MNK · 不是总结 · 是下次门禁
MNK（经验卡）不是普通总结。
它不是"今天我们聊了什么"。
它也不是"这件事很有启发"。
它必须回答一个问题 ——
下次遇到类似情况 · 我怎么少犯一次错？
所以一份合格的 MNK 必须有 ——
- 方法（M）—— 这次怎么应对的。
- 注记（N）—— 旁人或下个 AI 接手前 · 需要先知道的事。
- 知识（K）—— 沉淀成可复用的概念、SOP、reference。
外加一个 ERRORLOG 映射 · 把每一类错误对应到防复发动作。
MNK 的工作方式很反直觉 —— 它不是用来回忆的 · 它是用来在下次类似情况启动之前 · 被自动加载的。
如果一份 MNK 从来没有在下次任务启动前被读过 · 它就没在工作。
6. ERRORLOG · 把失败变成机器能读的检查点
ERRORLOG 比 MNK 更直接。
它记录的是 ——
错误编号 · E_
错误类型 · 一句话定义
表面现象 · 我看到的样子
触发条件 · 什么输入或环境导致它发生
后果 · 这次让我损失了什么
防复发动作 · 下次怎么提前拦
fixture / validator / 脚本候选 · 应该被沉淀成什么这份记录的读者不是人 · 是系统。
人读它会觉得很干 —— 没有故事、没有情绪、没有华丽的总结。
但系统读它非常顺 —— 每一行都可以被映射到 validator 的一条规则。
我后来给自己定了一条 ——
每一次重复出现的错误 · 必须有一条 ERRORLOG。
每一条 ERRORLOG · 都应该至少有一个 fixture 或 validator 候选。
没有候选的 ERRORLOG · 不算完成。
这是把失败从"情绪"逐级压缩成"机器能读"的过程。
7. 从情绪到门禁 · 失败研究 SOP
普通人用 AI · 最容易卡在情绪里 ——
- AI 又错了。
- AI 又停了。
- AI 又胡说了。
- AI 又忘了。
这些情绪都真实。但只停在情绪里 · 人会越来越累。
我后来学到的方式是 ——
先承认情绪 · 然后把它翻译成系统问题。
翻译表 ——
"你又停了"
→ closeout 后没有连续执行闭环
→ 防复发 · Auto-Continue Closure Rule
"你又让我点 A"
→ 系统性默认 A 没被正确识别
→ 防复发 · KAGU §3.7 默认 A · 60 秒倒计时
"你又把候选当完成"
→ completion claim 没有证据门禁
→ 防复发 · Completion Claim Gate（文件 + 验证 + 截图）
"你又偏离主线"
→ main task return gate 没执行
→ 防复发 · Main Task Return Gate这一步很关键。只要能翻译成系统问题 · 就能写成规则、SOP、validator 或 MNK。失败就不再只是失败 · 它开始变成系统的训练数据。
这是一种操作系统升级 —— 把情绪反应升级为系统反应。
8. 这一章给一个普通人的失败观
如果你也是普通人 · 开始用 AI 做项目 · 我建议你 ——
- 不要只保存成功案例 —— 成功案例会让你开心 · 失败案例会让你变强。
- 给自己建一张最简单的失败表 —— 5 列：哪里错了 · 偶然还是重复 · 触发条件 · 下次怎么拦 · 能不能写成检查清单。
- 接受"==分类失败=="是脱情绪的开始 —— 一次失败被分类完毕 · 情绪就降到可承受。
- 每一次重复出现的错误 · 写一条 ERRORLOG —— 没有 ERRORLOG · 同类错误一定会回来。
- ==MNK 是给下次的自己看的 · 不是给现在的自己看的== —— 写的时候别管"我现在懂"· 想象"下次的我已经忘了"。
- 接受"==失败的速度=="是项目的真实速度 —— 没有失败的项目不存在；看起来没有失败的项目 · 只是把失败藏起来了。
- ==每一次顺滑的"完成" · 都先问一句"证据呢"== —— 这一问是顺滑的失败的解药。
这一切 · 本质上是一句话 ——
失败只有进入系统 · 才会变成资产。
真正的 AI 使用能力 · 不是让 AI 永远不犯错 · 是让每一次错误 · 降低下一次同类错误发生的概率。
本篇方法卡
方法 08 · AI 失败研究 5 步法
每一次 AI 翻车（或自己翻车）· 走完以下 5 步 ——
1. 承认事实 · 不要先争论态度 · 直接记录"哪一步发生了什么"。
2. 分类 · 属于 7 类（E1-E7）的哪一类？如果都不属于 · 这是第 8 类 · 给它编号。
3. 写触发条件 · 什么输入 / 环境 / 时序导致它发生。
4. 写防复发动作 · 下次任务前 · 系统该自动检查什么。
5. 判断 landing ——
- MNK（给人 · "下次怎么少犯一次"）
- ERRORLOG（给系统 · 触发条件 + 防复发）
- TODO（短期未完成 · 不属于失败模式）
- validator 候选（自动检查脚本）
- SOP（手动流程）
- no action（确认是孤例 · 不沉淀）
没有 landing 的失败研究 · 等于没做。
本篇金句
参考与延伸
核心思想锚 ——
- 李笑来《自学是门手艺》—— 经验必须转成下次能用的技能
- 李笑来《思考的真相》—— 概念和错误定义不清 · 判断就会漂移
- 吴军《信息传》—— 记录失败是在减少未来不确定性
- Atul Gawande《清单革命》—— 高风险场景靠检查点降低重复错误
- Henry Petroski《To Engineer Is Human》—— 工程进步建立在失败档案上
- 老A 本书 CH05《顺滑的失败》—— E2-E7 的源头之一
- 老A 本书 CH06《假完成》—— E1 的另一种姿势
- 老A 本书 CH07《默认 A 的硬边界》—— E2 自咬的反向预防
reader q&a
读者留言
留言会先进入人工审核。请不要写电话、住址、证件号、合同全文或他人隐私；本站回复只做信息整理， 不构成法律、税务、投资、医疗或房地产交易建议。
还没有公开留言。你可以提出一个具体问题，审核后会显示在这里。
为了减少广告、辱骂和隐私泄露，留言需要先登录。公开显示前仍会人工审核。