AI会擅自修改文档内容 顶尖模型也存在风险

你是否曾有过这样的体验？深夜将一份文档或说明材料交给AI处理，附上一句“请帮我整理并优化，让它更清晰易懂”。第二天打开一看，确实感觉焕然一新：文字更流畅了，结构更分明了，排版也专业了许多。

然而，问题往往就潜藏在这种“看起来不错”的时刻。真正需要警惕的，并非内容写得糟糕，而是写得“过于正确，以至于难以察觉错误”。

一个典型的例子：合同中原本写明“付款时间为验收后30天”，AI可能会不经意地将其改为“付款时间为交付后30天”。两者看似相近，实则法律含义与商业风险天差地别。

微软研究院上月发表的一篇论文，深入探讨了这一问题。论文标题为《LLMs Corrupt Your Documents When You Delegate》，直白地揭示了核心发现：当你将文档的持续修改任务委托给大语言模型时，它很可能在多轮迭代操作中，逐渐“腐蚀”文档的原始内容与意图。

这里最关键的概念，并非“文档”或“模型”，而是“Delegate”——委托。

什么是委托？并非简单地向AI提问并获得一次性答案。而是指你将一份已存在的材料交给它，要求其在此基础上进行后续修改、补充、整理，沿着既有的逻辑与框架持续推进工作。

这正是现实工作中的常态。老板交给你一份方案，要求修改三轮；客户将合同退回，让你调整条款；同事发来数据表格，请你统一格式并补充说明。

为此，研究者设计了一个全新的测试基准，命名为DELEGATE-52。你可以将其视为一场大规模的压力测试，旨在评估AI在长期、多轮文档修改任务中的稳定性和可靠性。

该测试覆盖了52种不同领域的文档类型，范围从Python代码、SQL数据库文件，到乐谱、会计台账、字幕文件、餐厅菜单、家族谱系等。

测试方法设计巧妙：首先让模型执行一次正向修改操作，例如将一个复杂表格按类别拆分；随后要求其执行反向修改，即将拆分后的内容重新合并回原始结构。

如果模型足够可靠，那么经过“修改-还原”的循环后，文档应与初始版本高度一致。若无法复原，则说明在此过程中某些关键信息已被丢失或悄然改变。

这种来回修改会持续多轮，模拟真实办公场景中常见的“你改一版，我补一版，他调整格式，最后又需回顾前文”的复杂协作流程。

测试结果颇具警示意义：几乎所有参与测试的模型都未能幸免。

在测试的19个模型中，经过20轮交互后，所有模型的平均内容保真度下降约50%。即便是Gemini 3.1 Pro、Claude 4.6 Opus、GPT-5.4等顶尖模型，平均也会损坏约四分之一的内容。

这里所说的“四分之一”，并非指页面篇幅减少，而是指内容的保真度——即你交付给模型的原始意图、结构和细节——在经过多轮修改后，有相当一部分已悄然偏离原貌。

最易导致误判的一点在于：短期测试往往表现良好。

在前两轮交互中，这些顶尖模型的保真度通常能维持在94%到97%，看起来完全可靠。然而，一旦将交互轮次提升至20次，情况便急转直下：Gemini 3.1 Pro降至80.9%，Claude 4.6 Opus降至73.1%，GPT-5.4降至71.5%。

这很像一位新入职的实习生：第一项任务完成得不错，于是你逐渐放心，交付更多工作。直到第十项、第十五项任务时，你才发现前期累积的小错误已连成一片，难以挽回。

AI目前在处理许多文档任务时，正处在这种状态。

更棘手的是，其错误并非每轮均匀地微量出现。

论文发现，大量内容损失源于少数几次重大且突然的失误。平时表现稳定，但在某一轮修改中，模型可能突然将关键字段改错、打断逻辑链条、或删除重要的限定条件。一次这样的失误，就足以导致保真度大幅下滑。

这类错误并非一眼可辨的低级问题，如乱码、整段缺失或排版混乱。而是读起来通顺流畅，看似无误，但其中几处关键的“螺丝”已被悄悄拧松。

此外，模型能力越强，有时问题越难被发现。较弱模型的常见问题是直接删除内容、遗漏段落或丢失字段，易于察觉。

而强模型则更像一位“善于表达”的协作者。它懂得保持文档的外观、结构，甚至维持专业的语气，却可能悄悄替换核心含义。例如将“建议”改为“决定”，将“可能”换成“将会”。句子更完整，语气更肯定，但潜在风险也更加隐蔽。

论文中还有几个细节，值得深入探讨。

代码是例外，文档是重灾区

在测试的52个领域中，编程是唯一大多数模型达到“可用”门槛的领域。原因不难理解：代码结构相对规整，许多错误可通过运行测试、查看结果或语法检查被发现。但文档、会议纪要、合同、说明书则完全不同。它们的许多错误不影响阅读流畅性，却会直接影响语义表达，难以通过自动化工具检测。

工具越多，未必越稳

当前许多用户在使用OpenClaw、Claude Code等智能体前，倾向于安装大量Skill或插件工具，认为这能显著提升AI能力。

论文专门测试了这种场景。结果发现，在一套基础的工具框架下，模型的平均表现反而有所下降。

为何如此？可以这样理解：一个本就容易分心的协作者，手边工具越多，操作步骤越复杂，界面切换越频繁，稳定性未必提升。更何况，模型往往并不像人类那样精准地“只改一句、只调一列、只动一个字段”，它仍倾向于大段重写内容。

这就像你请同事帮忙修改一行文字，他却打开Excel、复制数据、重新排序、再粘贴回来……流程复杂化后，潜在的出错点自然也增多了。

文档越长，风险越高

这一点也符合直觉。一页纸的请假说明，与一份40页的合作协议，完全不在同一难度量级。

论文测试表明，文档长度越大，模型在后续修改轮次中“改坏”内容的概率就越高。而现实工作中最常见的任务，恰恰是处理长文档、长表格、长上下文的场景。

无关材料会添乱

例如，你将主文档交给AI时，顺手将几份参考材料、旧版本、会议记录、相关制度文件一并塞入上下文。人类有时都需花费精力区分哪些该看、哪些无关，模型自然更容易被干扰。

这高度模拟了日常办公场景：桌面同时打开三个版本的合同，邮箱存有两份旧纪要，聊天群还有一张相关截图。你要求AI从这堆混杂信息中继续修改，很难保证它不会将不该整合的内容错误地合并进去。

时间不会自动治愈错误

论文将交互轮次延长至100次，模型的性能仍持续下降，未出现明显的稳定平台。这意味着，当前模型并非“改着改着就学会稳住”，而是“改着改着，仍会继续犯新的错误”。

当然，必须明确指出，这篇论文并非全盘否定AI的实用性。

作者表述相当克制。他们测试的是一个基础版的智能体框架，并非全球最先进、最精细的工程系统。因此，不能将结论简单理解为“只要使用AI智能体就一定不可靠”。

但这篇论文有力地证明了一点：当前的AI，非常适合协助你起草内容、提升效率、迈出第一步。然而，它还远未稳定到可以让你将整条文档工作流完全托付，自己则彻底放手不管的程度。

这也解释了为何许多人用AI写作感觉顺畅，用AI修改却越发心虚。“写作”是从无到有生成内容，而“修改”是在保留原意的基础上优化。后者难度高得多。

那么，如何更安全地使用AI进行文档处理？以下提供五条实用建议。

第一，避免整包托管

不要简单说一句“请帮我全部改完”就交付任务。最好将任务拆解为小段、小节、小模块。例如，先仅让其修改摘要部分，再仅整理表格标题，接着仅润色一段说明。每次改动范围越小，出错时越易被及时发现。

第二，关注改动点，而非只看成稿

如果工具支持差异对比（diff），务必查看改动详情。因为通读一篇修改后的文章，人很容易被“读起来顺畅”的感觉欺骗。而一旦聚焦于“到底修改了哪些句子”，许多隐藏问题便会立即浮现。

第三，对敏感信息进行单独检查

金额、日期、时间节点、付款条件、地名、人名、版本号、试点范围、生效状态、例外条款……这些位置最容易出现重大疏漏，也最值得人工逐项核对。

第四，文档越长，越不能偷懒

十页以上的方案、数十行的表格、带附件的合同、含历史版本的制度文件，对这些长文档切勿轻信“它应该没问题”。文档越长，越应设置人工检查节点。

第五，区分任务类型：结构化任务更可靠

如果一项工作有明确的对错标准、现成的校验方式、清晰的规则约束，例如代码测试、固定格式转换、严格字段检查，那么AI通常更值得信赖。反之，凡是读起来通顺，但对错需依赖人类理解上下文才能判断的内容，潜在风险都更高。

因此，下一次当你准备将一份合同、一份方案丢给AI处理，然后安心离开时，不妨多问自己一句：这份看起来“没问题”的成果，是否真的没有问题？

毕竟，AI再强大，它也不会替你承担最终的责任。