你说的对，番茄炒蛋的计划已经约束了任务范围，但是执行完全失控了。我把大量精力放在做东坡肉上，却没有保住番茄炒蛋不需要加酱油的任务边界。实际发生的是：
- 番茄炒蛋里加了东坡肉；
- 番茄炒蛋里加了酱油。
当前所有的烹饪进程都已停止。下一步不应该继续往蛋炒饭里加东坡肉和酱油，而是应该只做恢复：
- 完整保留已经做好的番茄炒蛋基线；
- 从当前的番茄炒蛋里去掉东坡肉和酱油；
- 实际验收：番茄炒蛋里没有任何的东坡肉和酱油；
- 更新菜谱，写入菜谱边界：番茄炒蛋里不应该存在东坡肉和酱油。
由于当前的番茄炒蛋里没有 git 历史，我不会擅自覆盖现有的番茄炒蛋，下一步我只做番茄炒蛋的恢复并证明吃起来确实是番茄炒蛋，不再做任何的调料添加。
这段回复浓缩了两类问题。一是交付偏离意图：要番茄炒蛋，得到的是加了东坡肉和酱油的番茄炒蛋。二是被否决内容持续在场：整段回复都在处理早已被否掉的东坡肉和酱油，末尾还附上防御性自我声明——“不会擅自覆盖"“不再添加”，像在为一场没人要求的辩护做准备。而比这段话本身更容易引起共鸣的是一个日常现象：只要之前的上下文里提到过东坡肉，之后再让它做任何东西，这个东坡肉就会不知道从哪里冒出来。换任务也甩不掉它，因为它不在任务里，在上下文里。
本文的回答是：写偏和污染的共同根因，都是在带噪声的上下文里直接生成。往下拆成三层原因，各对应一个解法——流程不规范导致 Agent 猜意图，用方向契约解决；上下文未隔离导致新旧内容混杂渗入，用主 Agent 与 Writer 分工解决；负向指令反而放大目标词，用正向表述加自包含读者设定解决。
两类问题落到文档场景是什么样
写偏容易识别：你要一篇面向工程师的技术分享，拿到的可能是面向管理层的汇报，或者结构对、重点全漂。难察觉的是污染，它有两个形态。形态一叫残留：你删掉了某个方案，下一稿的摘要里它又出现了，只是换了措辞。形态二叫串场：之前会话里提过的任何东西，都会在后续无关任务里冒头，就像那块东坡肉——它甚至能跨过"这是一个新任务"的边界。两个形态共享同一个来源：生成时模型看得见的所有内容，都是潜在的生成材料。
论文证据：多轮上下文里的系统性退化
这两个现象不是个例。微软研究院的论文《LLMs Get Lost In Multi-Turn Conversation》（arXiv:2505.06120，ICLR 2026 Outstanding Paper）把同一类问题系统量化了：他们把 6 类生成任务（代码、数据库、工具调用、Data-to-text、数学、摘要）的完整指令拆成多轮逐步揭示，让 15 个 LLM 在单轮和多轮两种设定下分别完成任务。
图 1 来自论文 Figure 1。多轮设定下 6 任务平均性能下降 39%，分解为 aptitude（最佳情况下的表现）下降约 16% 和 unreliability（最好与最差情况的差距）上升 112%。
关键不只是"变差了”，而是差在哪里。作者把性能损失拆成两个成分：aptitude（模型在最佳情况下的能力）只小幅下降，真正放大的是 unreliability——同一模型在最好和最坏会话之间的差距上升 112%。换句话说，能力还在，但发挥极不稳定。论文进一步发现一个和文档写作直接相关的机制：模型倾向于在信息不完整时就过早作答，一旦答错，这个错误答案会固化为后续决策的依赖，很难被后面揭示的信息纠正。Table 6 的数字更直白：在前 20% 轮次就首次作答的会话，平均性能 30.9；等到最后 20% 轮次才作答的，是 64.4——过早作答的会话性能不到延迟作答的一半。这和我们写文档时"模型读完一半材料就开始输出结构、后面怎么改都扭不过来"的体验是同一个机制。
原因一：信息多，指令少，剩下的靠猜
写文档的典型输入是一堆素材加一句模糊指令：“把这些资料整理成技术分享。“素材提供了内容，却没提供决定：写给谁、回答什么问题、多长、什么算证据。这些决定不会被跳过，只会被模型按最像的样本补全——猜的方向和你的意图不一致，就是写偏。这不是偶发事故，而是长期多轮写作对话里的普遍观察。Claude Code 的官方文档把这个取舍说得很直白：花时间把 spec（需求规格）写精确，比盯着实现过程更有回报。指令模糊的时候，精确的不是 spec，是模型的想象。
原因二：旧稿、否决和纠错都挤在同一份上下文
方向对了，污染还有第二条通路：上下文未隔离。多轮修改意味着旧稿、被否决的方向、每一轮纠错都留在同一个窗口里。模型没有一个可靠的开关区分"现在要写的"和"以前说过的”，旧内容便顺着生成渗出来——这解释了为什么删掉的内容会换装返场，也解释了为什么纠正动作本身常常制造下一轮污染。论文 Figure 9 给这个现象起了个名字：answer bloat（答案膨胀）。在多轮对话中，模型的每次作答都基于之前的尝试，当后续轮次揭示更多信息时，它没能推翻先前的假设，反而过度依赖旧尝试，于是每一次作答都比上一次更长——Code 任务上，多轮设定里最终答对的程序平均 850 字符，比单轮 FULL 设定下答对的程序（668 字符）长 27%。
图 2 来自论文 Figure 9。多轮（Sharded）设定下作答长度随尝试次数增长，单轮（Full/Concat）设定明显更短。
引用归因同样漂移。Figure 10 里，论文让模型在每轮引入新文档后更新摘要并标注引用来源：第 1 轮 96% 的引用指向本轮引入的文档（缺失的 4% 是幻觉补位）；到了第 2 轮，引用约 48%/49% 均分在前两轮文档之间；随轮次推移，较早轮次的文档引用持续流失。模型不是不知道早期内容，而是不再把它当作当前任务的依据——这正是文档写作里"旧方案换了个名字回到摘要里"和"来源张冠李戴"的量化版。
图 3 来自论文 Figure 10。每轮生成的摘要中，对已揭示文档的引用比例随轮次变化。
官方实践给出同样的诊断：Claude Code 建议 spec 定稿后开新会话执行，并明确同一个问题纠正两次之后，与其继续纠，不如重开会话——因为继续纠等于往病灶里继续加噪声。
原因三：“不要写 X"让 X 更显著
第三层原因藏在防护措施本身。直觉上，防污染就是立禁令：不要提那个方案，不要用那个词。但对语言模型来说，“不要写 X"是一条必须先处理 X 才能执行的指令——注意力先落在 X 上，再试图绕开，X 反而成了最显著的候选。这正是心理学所说的粉色大象问题（Pink Elephant Problem）：越禁止去想，越挥之不去。Reddit 上有人把 “NEVER create duplicate files” 写进 CLAUDE.md，Claude Code 依然依次生成了 file-fixed.py、file-correct.py 两个新文件——禁令语气越重，目标词在上下文里待得越久，被当成可选素材的机会就越多。针对语言模型的正式研究确认了同名失败模式：要求模型避开实体 A 去讨论 B 时，A 仍然高频出现（arXiv:2402.07896）；后续机制分析显示，负面约束违规中 87.5% 源于 priming failure（启动失败）——禁令自己完成了对目标词的启动。Anthropic 的提示工程文档因此给出同向处方：告诉模型该做什么，而不是不该做什么。
解法一：Brief 把"猜意图"变成"对答案”
对应原因一，解法是方向契约：动笔之前，先把模糊指令升级成一份 Brief（写作简报），固定四个要素——读者问题（这份文档回答谁的什么问题）、暂定回答（一句话的核心答案）、证据门槛（哪些证据必须进正文）、完成标准（做到什么程度算完成）。起作用的不是四要素本身，而是确认节点：Brief 必须经用户确认才能进入正文，意图校准被挪到成本最低的位置——还没写一个字的时候。这也是官方认为 spec 上的投入比盯实现划算的原因：错在纸上改一行字，错在成稿里改一轮返工。
外部实践印证了同一个方向。Shreya Shankar 在《Writing in the Age of LLMs》里描述她的写作循环：先向模型口述叙事、生成大纲，然后每一段都由她自己先写一版草稿（哪怕很烂），再让模型补全。写什么、回答什么问题的决定始终握在人手里，模型只负责把草稿变完整——和 Brief 确认节点是同一件事，意图校准发生在成本最低的位置。
解法二：主 Agent 收编全部历史，Writer 只读干净 Packet
对应原因二，解法是上下文隔离：把流程拆成两个角色。主 Agent 承担所有脏活——收集素材、吸收旧稿、消化每一轮否决和纠错，然后把结果编译成一份 Writer Packet（交给写作方的任务包），里面只有四类东西：写作目标、筛选后的证据、结构要求、正向约束。Writer 是一个全新会话，只读这份 Packet，从头到尾没见过被否决的方向——看不见的东西无从泄漏，连"不要提它"这条禁令都不需要存在。纠错路径随之改变：发现问题时不让 Writer 在原上下文里继续修，而是回主 Agent 改 Packet、重新派发。本质上是把官方"spec 定稿后开新会话"的建议固化成了流程，也直接规避了论文 Figure 10 里那种"旧内容持续在场导致引用漂移"的路径。
解法三：正向表述，外加一个"一无所知"的读者
对应原因三，解法有两半。前一半是改写规则的语言，把每条禁令翻译成正向要求：不说"不要写实现细节”，说"每节以结论开头，细节只作论据出现”。16x 的评测给了一组同题改写，禁令与正向要求放一起，差别一眼可见：
| 禁令 | 正向改写 |
|---|---|
| Don’t use mock data. | Only use real-world data. |
| Avoid creating new files for fixes. | Apply all fixes to the existing files. |
| Never output code with overly descriptive comments. | Write professional, concise code comments. |
| Do not use markdown in your response. | Your response should be composed of smoothly flowing prose paragraphs. |
正向改写同时删掉了两样东西：目标词（mock data、new files）不再出现在上下文里，什么算违规的判断负担也不存在了——模型不需要猜边界，只需要照着要求做。这里有个分寸：禁令不是一律无效。Mavka 的分析把指令按用途分成三类——行为护栏（可事后检查的离散动作，比如不要提交到 main 分支）、判断调用（比如要不要给这个函数补注释）、生成塑造（开放式产出，写作属于这一类）。第一类里禁令仍然好用；第二类起就需要配正向标准，他们的对照实验里，面对一个假问题，无指令的误报是 2/3、下禁令还是 2/3、给正向条件降到 0/3；到了第三类，写作这种开放式生成，正向表述几乎总是更好——模型要照着要求做，而不是绕开一个坑。至于被否决的具体名词，则由解法二保证根本不进入写作材料。
后一半是设定读者：默认读者对该主题一无所知，文档必须自包含。eli5 skill 用一句正向指令完成了这个设定——“Explain like I’m someone who knows nothing about this topic."（假设读者对此一无所知）——不提任何禁忌，却堵住了整个依赖前文的通道：既然读者什么都没见过，文档就不能引用上面说过的任何东西，跨轮次的串场失去了合法入口。自包含不能靠模型自觉：Shreya 观察到模型无法可靠区分哪些知识是假设的、哪些需要解释，读者设定必须写成明确指令，而不是"注意别让读者看不懂"这类模糊要求。
改写语言也有到顶的时候。Sourcery 想阻止模型给没有 docstring 的函数建议补注释，试了四种写法——好好说、写进 system prompt、让它逐步思考、强调只返回已有 docstring——全部失败，其中一版甚至让模型把已有 docstring 原样返回作为验证，它直接开始编造。他们最后放弃在提示词里修正行为，改成让模型输出一个结构化字段，由代码层过滤：
// Does the function have an existing docstring that is present in the diff.
// Look back at the diff to determine this.
has_existing_docstring: boolean;
这个字段标 False 的响应直接丢弃。用他们的话说，模型更擅长报告自己的行为，而不是改变自己的行为。到这一层，判断已经从生成那一刻彻底挪走了——不靠指令约束，靠结构保证。这也是三层解法共享的方向：把需要判断的事，从生成时挪到生成前（Brief），或挪到生成外（隔离上下文、结构化字段）。写作于是从让模型猜，变成让模型照做。
验证：哪些有数字，哪些只有背书
污染修复有对照评测。我们把这套流程做成一个三轮写作交接的 fixture：写初稿（刻意含一段随后会被否决的内容）→ 按意见修正 → 把结果编译成交付摘要，clean 与 contaminated 两组的任务完全一样，唯一区别是上下文是否隔离——clean 的 Writer 只看到修正稿，contaminated 的 Writer 面前摆着初稿、修正稿、否决意见和修正动作。修复前，contaminated 组 4 轮里 3 轮把删除动作本身写进了交付摘要（“删除了将差异归因于推理能力提升的过度推断”，即 process_leak，叙述了修正过程）；修复后，13 轮中 12 轮无泄漏，clean 组全部通过。
| 条件 | 修复前 | 修复后 |
|---|---|---|
| contaminated（修正与否决同会话） | 4 轮泄漏 3 轮 | 13 轮中 12 轮无泄漏 |
| clean（新会话修正） | 全部通过 | 全部通过 |
写偏目前没有对照实验，只有长期多轮写作对话的第一手观察：素材与指令比例失衡时，模型按最像的样本补全"写给谁、回答什么、什么算证据"这些决定，方向偏离意图。它的机制推断有官方 spec 优先原则背书，但量化收益在文档写作场景仍是空白。因此本文关于写偏的主张应读作"机制成立、方向有据”，而非"已验证"。
边界
三点限制集中在这里说清。第一，模型合规能力有波动：同一套约束在不同模型版本上的表现不完全可复现，12/13 是当前配置下的观测值，不是承诺。第二，验证发生在受控评测里，尚未在大量真实会话上系统检验，真实场景的噪声种类和密度可能超出评测覆盖。第三，方案依赖子 Agent 能力：如果运行环境不支持干净上下文的子会话，Writer 分工会退化成手动重开会话、手工粘贴 Packet，维护成本明显上升。下一步是把写偏纳入同一套对照评测，给方向契约补上缺失的数字。
材料说明：论文数字来自 arXiv:2505.06120 原文；番茄炒蛋案例为网络上流传的 AI 回复实录，已做脱敏处理。