把工作交给 AI 之后,文档是怎样慢慢坏掉的

大语言模型给人的第一印象，往往是很会干活。

它可以帮你改代码，整理文档，调整表格，写配置文件，修改字幕，甚至处理一些你并不熟悉的专业格式。只要你把文件交给它，再告诉它想要什么结果，它似乎就能像一个助理一样替你完成工作。

这种使用方式和过去的问答不太一样：以前我们问模型一个问题，它回答一段话，现在我们把一整件事交给它。

你不只问它这段代码是什么意思，而是让它重构这几个文件；你不只问它这个配置怎么写，而是让它直接把配置改好；你不只是让它解释一个文档，而是让它按要求把文档改成另一个版本。

这就是论文里说的 delegation，也就是委托。

委托的本质是信任。当你把工作交给一个人，你默认他不会悄悄把你的文件弄坏。当你把工作交给 AI，你也会自然地产生类似期待：它应该只改我要求它改的地方，不该乱删，不该乱编，不该把数字弄错，不该把原本正确的东西改坏。

问题就在这里。

arXiv:2604.15597 [cs.CL] 这篇论文想研究的，正是这个问题：当我们把真实文档交给大语言模型反复修改时，它到底能不能可靠地保住文档原本的信息？

答案并不乐观。

他们发现，现在的模型在短任务里看起来很强，但一旦进入长流程委托工作，就会逐渐损坏文档。更麻烦的是，这种损坏经常不是一眼就能看出来的。文档表面上还完整，格式也还像样，模型也会说自己完成了任务，但里面可能已经有一部分内容丢失、错位、被误改，或者被模型自己“合理化”重写了。

为了测试这件事，作者做了一个 benchmark，叫 DELEGATE-52。

这个名字里的 52，指的是它覆盖了 52 个专业领域。它把很多真实知识工作里的文件格式都放了进来。比如 Python 代码、数据库、配置文件、字幕、菜谱、晶体学文件、3D 对象、交通记录等。因为真实世界里的文档并不都是 Markdown 或 Python。很多工作文件是半结构化的、领域专用的、格式古怪的，而且里面有大量细小但重要的信息。

作者没有简单地问模型能不能改这个文件然后人工判断对错。那样太贵，也不容易规模化。而是设计了一个更巧妙的方法：往返编辑接力。

比如有一个账本文件，第一步让模型把账本按支出类别拆成多个文件，第二步再让模型把这些文件按时间顺序合并回原来的账本。理论上，如果模型真的正确完成了这两个操作，那么最后得到的账本，应该和一开始的账本在语义上完全一致。

这有点像来回翻译，把中文翻译成英文，再从英文翻译回中文。如果信息没有损失，最后的中文意思应该和原来一样。这个方法的好处是，它不需要为每个任务人工写标准答案。原始文档本身就是答案。只要最后能不能恢复原始文档，就能衡量模型在这个过程中有没有破坏信息。

作者还把这种往返操作串起来。一次往返是两次交互：先改过去，再改回来。十次往返，就是二十次交互。这就开始接近真实工作里的情况了。现实中你让 AI 改文件，往往不是只改一次，而是今天改一点、明天再改一点；发现问题再让它修一下，然后再让它重构一下。

很多错误就是在这种连续修改里累积出来的。

为了让测试更真实，作者还给模型加入了干扰上下文。模型拿到的不只是目标文件，还会拿到一些相关但不该使用的材料。现实中的 agent、RAG、代码库工作区也经常是这样：上下文里有很多文件，有些相关，有些只是看起来相关，有些甚至会误导模型。

这时，模型不仅要会改，还要知道哪些信息该用，哪些不该用。

评估也不是简单做字符串比较。如果一个菜谱里写着 200g 黄油，模型改成 0.2kg 黄油，这不应该算错。可是如果它改成 800g 黄油，那就是严重错误。普通的比较无法理解这个差别，所以作者为每个领域都写了专门的解析器和相似度函数。账本有账本的比较方法，菜谱有菜谱的比较方法，字幕有字幕的比较方法，代码有代码的比较方法。它们尽量比较语义是否保住，而不是只比较表面文本像不像。这也是这篇论文最费功夫的地方。

结果：模型会把文档越改越坏

作者测试了 19 个大语言模型，包括 OpenAI、Anthropic、Google、Mistral、xAI、Moonshot 等模型。主实验是 20 次委托交互。到最后，即使是前沿模型，平均也会破坏大约四分之一的文档内容。所有模型平均下来，损坏接近一半。

这意味着：如果你把一个真实专业文档交给 AI 连续处理，最后它交还给你的东西，可能已经不是原来的可靠文档了。它可能只是在表面上还像原来的文档。

更值得注意的是，模型的能力很不均匀。在 Python 这类领域，模型表现很好。很多模型能做到几乎不损坏内容。这个结果也符合我们日常感受：模型在代码，尤其是 Python 这种训练数据丰富、结构清晰、容易运行验证的领域，确实比较强。

但到了其他领域，情况就不一样了。比如账本、乐谱、字幕、菜谱、晶体学文件、交通记录、复杂结构化文档，模型就容易出问题。它可能不是完全不会做，而是做着做着就漏掉一项、改错一个数字、混淆一个字段、打乱一段结构。

这就是论文里很重要的一个判断：LLM 的能力不是平滑分布的，而是锯齿状的。

它在某些地方强得惊人，在另一些地方又很不可靠。你不能因为它会写 Python，就相信它也能可靠修改一个专业账本；不能因为它能解释字幕格式，就相信它能长期无损地重排字幕；不能因为它能生成配置文件，就相信它能在复杂项目里持续维护配置不出错。

作者还研究了有工具的 agent 会不会更好。按理说，有工具应该更强。模型可以读文件、写文件、运行代码、调用脚本。它不必每次都靠自己重新生成整个文档。

但实验结果有点反直觉：在他们测试的设置里，有工具的 agent 反而表现更差。

原因是现在的模型使用工具还不够稳定。工具调用会引入大量上下文开销，模型每次任务会多次读写文件，输入 token 变多、链路变长，错误机会也变多。而且这些任务很多不是简单脚本处理就能完成的，它们需要理解领域语义。模型没有真正把代码执行工具用成可靠验证器，更多只是把它当作读写文件的手段。这对现在流行的 agentic coding 很有警示意义：让 AI 有工具不等于让 AI 可靠。工具只是放大器。模型会用，工具就能减少错误；模型不会用，工具反而会增加复杂性。

论文还发现，文档越大，越容易坏。这也不难理解。文件越长，模型越容易漏东西。更重要的是，文档大小的影响会随着交互次数放大。不是说一个大文件只是在第一次修改时更危险，而是每多改几轮，早期的小错误会继续被后面的任务继承、扩散、放大。如果你有一个 500 行的小配置文件，模型可能还可以处理。如果你有一个几万 token 的复杂文档，让模型连续改二十轮，风险就完全不同。

交互次数本身也是风险。作者把部分实验扩展到 100 次交互。结果显示，退化没有停止。文档没有坏到某个程度后稳定下来，而是继续变坏。即使最强模型，长流程之后也会明显退化。这说明问题不只是“偶尔犯错”，每一次委托操作都有一个小概率引入损坏。只要流程足够长，这些小概率就会累积成必然问题。

论文里还有一个很关键的观察：错误并不是每次都均匀发生。很多时候，模型前几轮表现正常，分数几乎不掉。然后某一次突然发生严重损坏。作者把这种情况称为 critical failure，也就是关键失败。这也很像现实使用 AI 的体验。让它改十次，前九次看起来都可以。第十次它突然把一个重要函数删了，或者把字段名改错了，或者把某个边界条件丢了。问题是，它不会大声告诉你“我刚才破坏了一个关键部分”。它还会正常输出，还会说任务完成。

这种失败尤其危险。因为它不是“模型明显不会”。如果模型明显不会，你会警惕。真正危险的是它大多数时候看起来会，于是你放松检查，然后在某一步悄悄出错。

真正有启发意义的是，作者区分出了两种错误：删除和腐败。删除比较容易理解，就是内容没了。弱模型经常会这样，改着改着漏掉一段，或者干脆省略某些部分。腐败更隐蔽。内容还在，但意义变了。表格还在，数字错了；字段还在，含义错了；结构还在，引用关系断了；字幕还在，时间轴错了；配置还在，默认值变了；代码还能编译，但业务逻辑已经偏了。

强模型不一定大量删除内容，但会产生这种更像“文档腐败”的错误。

对人来说，这类错误更难发现。因为你看到的是一个完整、漂亮、格式正常的结果。你很容易误以为它没问题。

论文最后讨论了这个发现对 AI 使用者和 AI 系统设计者的意义。对普通用户来说，结论很简单：不要轻易把长流程文档维护完全交给 AI。尤其是那些你自己不容易检查的文档。你越不懂，越容易觉得 AI 做得好；但也正因为你不懂，你越难发现它哪里弄坏了。

对工程师来说，结论更具体：如果你要让 AI agent 修改代码、配置、数据库 schema、文档、字幕、账本、规范文件，就不能只靠模型本身。你需要验证机制。比如测试、类型检查、schema 校验、parser 校验、diff 审查、快照回滚、格式化检查、领域规则检查、最小化编辑范围。

换句话说，可靠的 AI 工作流应该尽量让模型少做整篇重写，多做局部可验证的修改。它不应该每次都把整个文件重新吐出来。它应该能明确说明改了哪里、为什么改、影响范围是什么。系统也应该能检查它有没有动不该动的地方。

这篇论文不是想说 AI 没用，恰恰相反，作者承认模型进步很快，而且在 Python 这样的领域已经接近可委托状态。问题在于，我们现在很容易把一个领域里的成功经验，错误推广到所有领域。

• AI 会写 Python，不代表它会安全维护账本。

• AI 会总结文档，不代表它能无损编辑文档。

• AI 会生成字幕，不代表它能长期维护字幕时间轴。

• AI 会输出看起来正确的配置，不代表它没有破坏隐藏约束。

所以，这篇论文的核心是指出了一种更具体的风险：在委托式工作里，AI 的错误会变成文档本身的一部分，并且会随着后续修改继续传播。一旦错误被写进文件，后面的模型调用会把这个错误当作新的事实基础。它不会知道这是上一轮引入的损坏。它会继续在这个损坏的基础上加工。久而久之，文档就像被慢慢污染了一样，外表还完整，内部已经偏离原始含义。

这也是论文标题里 “corrupt your documents” 的意思。模型以一种看似合理、看似顺滑的方式，在反复编辑中让文档逐渐失真。

我们正在从问 AI 问题走向让 AI 做事，评价标准正在变成它能不能保住原始信息，能不能经得起长流程反复操作。这篇论文告诉我们，AI Agent 的瓶颈不只是推理能力，也不只是工具调用能力，而是长期维护工作产物的保真能力。对于真正的知识工作来说，这一点可能比能不能答对一个问题更重要。