AI 编码的翻车与根因
这一章回答一个问题：你让 AI 写代码，它为什么会翻车，翻车又能不能治。
AI 翻车大多不是因为它笨。它背后有一个共同的诱因：拿训练时见过的一般写法，去填它不知道的、你这个项目的具体情况。不同的翻车，近因并不相同，所以对策不能靠跟它说”认真点”，而要针对每一种翻车的近因或缺口，改变它能看到什么、强制它交出什么。
1.1 三种最常见的翻车
很多人第一次用 AI 写代码，印象是”对着它随口说说就出代码”。真用进项目就会撞见三种翻车，而且反复撞见：
- 编造接口和字段。它拿通用框架里的 API 去填你这个项目的具体代码，调一个你项目里根本不存在的方法，读一个拼错的配置项。
- 跑偏需求。你说”做个登录”，它做成它印象里那套标准登录，而不是你这个系统实际要的那套。
- 自称已完成。它说”写完了、测过了”，实际代码跑不起来、测试没真跑、逻辑对不上需求。
这三种翻车共享一个诱因，近因却不同。编造接口和字段，是因为它缺项目事实、又没有先去代码里检索；跑偏需求，是因为你给的意图和验收条件不完整，它用常见模式补了空白；自称已完成，是因为它没有真实执行、没有独立检查、也没有一个可验证的”算完”的标准。近因不同，后面的对策也就分成三条，各治一种。
所以这套方法不是要把 AI 用得更随意，恰恰相反，是给 AI 编码套上纪律：先把项目事实、要做什么、做到什么算完立清楚，再让它动手。
1.2 现象、近因与对策
撞见翻车，最常见的反应是在提示词里加一句”请认真、不要偷懒、仔细检查”。这几乎没用。要讲清为什么，得把问题分成三层看，这个分法全书都会用到。
下面这张表就是这套方法的诊断方式：遇到一个现象，先找它背后的事实、任务、流程或模型缺口，再选对策。三者是多对多的，一个现象可能有几个近因，一条对策也可能压住好几个缺口。
| 现象（你观察到的坑） | 近因或缺口（事实、任务、流程、模型） | 可执行的对策（你能写进流程的） |
|---|---|---|
| 编造接口和字段 | 缺项目事实；没有先检索 | 动手前核实；调用前先在代码里确认存在 |
| 跑偏需求 | 意图和验收条件不完整，用常见模式补空白 | 先写清”做什么 + 验收条件”再动手 |
| 自称已完成 | 没有真实执行、独立检查、可验证的完成标准 | 独立于自我报告的验证 + 可追溯记录 |
判据很简单：能直接观察到的是现象；需要进一步追问的，是事实、任务、流程或模型在哪一层出了缺口；能落实成动作的才是对策。只复述现象，就容易写出”请认真点”这种无效话术。
“请认真点”为什么瞄错了？两个原因。一是”认真”不是一个模型能执行的动作，它会生成一句”好的，我会认真检查”，然后该漏的照漏，这种叮嘱没有约束力。二是模型的输出对提示里的措辞和暗示很敏感：你带着假设去问”是不是用了 X”，它容易顺着你说”是”，哪怕事实不是。叮嘱改变不了这两点。
还有一项针对真实 agent 运行轨迹的研究给出一个更反直觉的结论：在这项研究覆盖的任务里，决定一个 agent 可靠不可靠的，主要不是它”一次做对”的能力，而是它发现、诊断和纠正错误的能力；研究还发现，掺入无关信息会降低可靠性，上下文的质量比数量更重要。
这把对策的方向定了下来：流程要能发现和纠正错误，而不是指望一次做对；提供上下文时，优先保留当前任务真正需要的材料。
1.3 上下文的质量与数量
窗口大小也印证了上下文的质量比数量重要。模型的标称窗口越来越大，但标称窗口不等于有效窗口。有专门的长上下文基准测过”非字面匹配的推理”：线索散在长文本各处、要跨段落关联起来才能回答，而不是在一堆文本里找一个原词的那种大海捞针。远不到窗口填满，模型的表现就开始明显下降，连表现较好的模型也不能避免。上下文越长，模型对其中信息的利用越不均匀，中段的内容尤其容易被忽略。
这项基准测的是模型能不能在长文本里找到并使用相关信息，没有比较系统提示、工具定义、steering 和任务历史各自的影响。它不能直接给出统一的会话清理线，也不能证明某一类上下文几乎没有成本。
- 工程上应当优先压缩与当前任务无关的东西：读完就不用的长文档、滚动累积的对话历史、工具的大段返回。它们占用上下文，却不再帮助当前任务。
- 常驻的指令层（steering、技能库、工具定义、系统提示）是否过重，要结合工具的加载方式和当前任务另行评估。
- 具体从多少 token 开始清理，是本地经验，不是基准结论。后面讲会话与上下文管理时，再讲怎么判断何时清理或重开。
1.4 三条地基
把前面三件事翻译成能天天用的规矩，就是这套方法的三条地基。后面每一步流程，都是这三条的展开。它们一一对应三种翻车的成因：
| 地基 | 一句话规则 | 治哪种翻车 |
|---|---|---|
| 动手前核实（Grounding） | 写代码前先把接口事实、需求意图、验收条件核实清楚；要调一个接口/字段前，先在代码里确认它真实存在 | 编造接口和字段；跑偏需求 |
| 改旧前上锁（Safety Net） | 没有安全网，不许改没完全看懂的旧代码。重构先写锁住现有行为的特征测试；修 bug 先写能复现 bug 的失败测试 | 改旧代码时的回归和误伤 |
| 交付前验证（Honest Verify） | 每个交付都要有独立于 AI 自我报告的证据（运行结果、测试、验收记录）；高风险或用户可见的行为必须人工验收 | 自称已完成 |
三条各管一段：核实管起点的事实和意图，上锁管过程里的回归风险，验证管终点的”假完成”。特征测试只能证明旧行为没有改变；新需求是否做对，要在验证阶段对照验收条件判断。
验证强度跟着风险走：低风险、可回退的改动，有运行和测试证据即可；高风险或用户可见的行为要求人工验收。
1.5 翻车诊断卡
AI 的产出让你觉得不对劲时，按三步排查：
- 记录现象：它具体做了什么让你起疑。调了不存在的方法？做出来的东西和你要的不一样？说完成但你没验过？
- 定位缺的那一层：是缺项目事实（该核实），还是改了看不懂的旧代码却没有安全网（该上锁），还是没有独立证据证明完成（该验证）？
- 补对应的地基，别加”请认真点”这类叮嘱。
通过标准：你对现象的每一条判断，都能指向一个具体的项目证据，比如哪个接口不存在、哪条验收条件没写、哪个测试没跑，而不是停留在”感觉它不靠谱”。
本章小结
AI 翻车共享一个诱因，近因却各不相同。动手前核实、改旧前上锁、交付前验证，分别在起点、过程和终点发现并纠正错误。
参考与出处
- 长上下文中信息利用不均匀，标称窗口不等于有效窗口：NoLiMa 基准的论文、官方仓库
- agent 的错误恢复能力比一次做对更能预测可靠性，上下文质量优先于数量：《How Do LLMs Fail In Agentic Scenarios?》
- 提示里的暗示和措辞会让模型的回答出现偏差：《How Does Alignment Tuning Shape Representations of Sycophancy》