编辑器背后

为什么 这么擅长编辑文档？

语言模型可以写出不错的句子，但将其连同格式放回原处则是另一项工作。我们解释了为什么让AI编辑文档一直以来都如此困难，以及我们构建了什么来解决这个问题。

阅读时间 9 分钟2026年10月3日

概述

让聊天机器人修改Word文件中的某个条款，其实是让它同时完成两项工作：修改文字，以及重写保存这些文字的文件格式。语言模型擅长第一项工作，但在第二项工作上并不可靠。

将第二项工作从模型手中接过来。本文解释了为什么这很重要、它在长文档上是如何运作的，以及它与聊天网站和计算机使用智能体相比有何不同。

  1. 01语言模型将文档读取为标记（markup），而不是页面。
  2. 02一个错误的字符就可能导致文件无法读取，而冗长的输出往往更容易产生错误的字符。
  3. 03 将内容与格式分离：模型负责修改文字，我们的代码负责编写文件。
  4. 04长文档会像现代编程智能体那样进行分批、拆分并赋予上下文。
  5. 05聊天网站可以使用Python编辑文件，但更改可能会无声无息地丢失。
  6. 06计算机使用智能体像人类一样进行编辑，但成本要高出许多倍。

01

大语言模型只能看到文本，看不到格式

在 Word 中打开一份合同，你会看到一个页面：带有公司风格的标题、加粗的金额、带有下划线的截止日期。Word 程序会创建这些格式，以便我们可以进行可视化编辑。Word 文件（.docx）的底层是一个复杂的 XML 系统，其中我们看到的每个字都被痛苦地加上了被称为标记的隐藏文字注释。12

你看到的内容

模型所看到的内容

<w:p>  <w:pPr><w:pStyle w:val="Heading2"/></w:pPr>  <w:r><w:t>4. 租金</w:t></w:r></w:p><w:p>  <w:pPr><w:jc w:val="both"/></w:pPr>  <w:r><w:t>承租人应于</w:t></w:r>  <w:r><w:rPr><w:i/><w:u w:val="single"/></w:rPr><w:t>每月第一天</w:t></w:r>  <w:r><w:t>支付</w:t></w:r>  <w:r><w:rPr><w:b/><w:color w:val="1F4E79"/></w:rPr><w:t>US$2,400</w:t></w:r>  <w:r><w:t>。</w:t></w:r></w:p>
图 1同一条款出现了两次。这些文字占用了 26 个字符；其周围的 XML 占用了 373 个字符。word/document.xml 片段。

大语言模型无法获得Microsoft Word、LibreOffice或Pages的辅助，只能依靠其对标记语言本身的理解。为了正确编辑，大语言模型需要理解原始标记的效果，并使用正确的标记编写新句子。

02

大语言模型的输出具有天生的不稳定性

模型可能已经有了实质性的改进，但即使是最新模型也依然会犯错。在微软研究院 2026 年对 52 个专业领域的 19 个模型进行的一项研究中，诸如 Gemini 3.1 Pro、Claude 4.6 Opus 和 GPT 5.4 等前沿模型在漫长的编辑工作流结束时，平均损坏了 25% 的文档内容。4

在 Word 文件中，一个小错误就足以使文件无法使用。这里模型漏掉了一个斜杠：

<w:p>  <w:pPr><w:jc w:val="both"/></w:pPr>  <w:r><w:t>承租人应于</w:t></w:r>  <w:r><w:rPr><w:i/><w:u w:val="single"/></w:rPr><w:t>每月第一天</w:t></w:r>  <w:r><w:t>支付</w:t></w:r>  <w:r><w:rPr><w:b>1<w:color w:val="1F4E79"/></w:rPr><w:t>US$2,400</w:t></w:r>  <w:r><w:t>。</w:t></w:r></w:p>
图 2少了一个斜杠会导致加粗标签保持开启状态。XML 不再格式良好，Word 将无法正常打开该文件。3

XML 对错误的标记容忍度为零。文件要么格式良好，要么就完全损坏。Word 有时可以恢复损坏的文件，但恢复后的副本可能会丢失文本或格式。

输出越长，错误越多

风险随长度增加而增长。LongProc 是一个针对长结构化输出的 2025 年基准测试，它发现开源权重模型在输出达到 2,000 个 Token 时开始出现不稳定，而 GPT-4o 在达到 8,000 个 Token 时性能显著下降。5 另一项研究发现，随着输入量增长，即使模型能够检索到每一个相关的事实，其性能也会下降 13.9% 到 85%。6 一个 10 页的 Word 文档大约有 10,000 个 Token，试图一次性编辑全部 10 页而不出错，几乎是不可能完成的任务。

<w:p>  <w:pPr><w:pStyle w:val="ClauseText"/></w:pPr>  <w:r><w:rPr><w:b/><w:sz w:val="24"/></w:rPr><w:t>5.1</w:t></w:r>  <w:r><w:rPr><w:sz w:val="24"/></w:rPr><w:t xml:space="preserve"> Harlow &1 Pike LLP 就本租约项下产生的一切事宜代表房东行事。</w:t></w:r></w:p><w:p>  <w:pPr><w:pStyle w:val="ClauseText"/></w:pPr>  <w:r><w:rPr><w:b/><w:sz w:val="24/>2</w:rPr><w:t>5.2</w:t></w:r>  <w:r><w:rPr><w:sz w:val="24"/></w:rPr><w:t xml:space="preserve"> 承租人应使租赁房屋保持良好和实质上的修缮及状况。</w:t></w:r></w:p><w:p>  <w:pPr><w:pStyle w:val="ClauseText"/></w:pPr>  <w:r><w:rPr><w:b/><w:sz w:val="24"/></w:rPr><w:t>5.3</w:t></w:r>  <w:r><w:rPr><w:sz w:val="24"/></w:rPr><w:t xml:space="preserve"> 任何通知均须以书面形式发出，并送达附表 2 中指定的地址。</w:t></w:p>3<w:p>  <w:pPr><w:pStyle w:val="ClauseText"/></w:pPr>  <w:r><w:rPr><w:b/><w:sz w:val="24"/></w:rPr><w:t>5.4</w:t></w:r>  <w:r><w:rPr><w:sz w:val="24"/></w:rPr><w:t xml:space="preserve"> 若租金逾期超过 21 4
  1. 1文本中包含一个单独的“与”号（&）。XML 要求将其转义为实体。
  2. 2缺少右引号。其后的所有内容都被读取为值的一部分。
  3. 3在段落结束前从未闭合的文本段（run）。
  4. 4输出会直接停止。长文本生成可能会达到长度限制或在标签内部超时。
图 3模型输出的四个片段，四种失败情形。任何一种都足以让文件无法读取。

03

如何解决此问题

我们编写了将格式与内容分离的自定义程序。模型会收到需要更改的文字以及页面的渲染图像，从而获得来自 Word 程序的辅助。然后，我们的代码会将编辑后的文字放回原有的文本段中，并保持文件的其余部分不变。

你的文件

<w:p>  <w:pPr><w:jc w:val="both"/></w:pPr>  <w:r><w:t>承租人应于</w:t></w:r>  <w:r><w:rPr><w:i/><w:u w:val="single"/></w:rPr><w:t>每月第一天</w:t></w:r>  <w:r><w:t>支付</w:t></w:r>  <w:r><w:rPr><w:b/><w:color w:val="1F4E79"/></w:rPr><w:t>US$2,400</w:t></w:r>  <w:r><w:t>。</w:t></w:r></w:p>

将内容与格式分离

提取的内容

承租人应于每月第一天支付US$2,400。

呈现的页面

两者都发送给模型

语言模型编辑文字。从不触碰 XML。

该模型会返回编辑后的内容

模型输出

承租人应于每月第一天每个月第五天支付US$2,400US$2,600。

将文字写回原始文本段

你的文件，已编辑

<w:p>  <w:pPr><w:jc w:val="both"/></w:pPr>  <w:r><w:t>承租人应于</w:t></w:r>  <w:r><w:rPr><w:i/><w:u w:val="single"/></w:rPr><w:t>每个月第五天</w:t></w:r>  <w:r><w:t>支付</w:t></w:r>  <w:r><w:rPr><w:b/><w:color w:val="1F4E79"/></w:rPr><w:t>US$2,600</w:t></w:r>  <w:r><w:t>。</w:t></w:r></w:p>

✓ 有效的 .docx。加粗、颜色和下划线完全保持原样。

图 4编辑流程（简化版）。高亮显示的文本是文件中唯一发生更改的部分。

这同时解决了两个问题。模型现在可以看到它以前看不到的格式，并且不再编写最容易出错的标记。

你在通用聊天机器人中找不到这一层。提取、渲染和重新组装程序是由自己的工程师构建和维护的。

04

解决长上下文问题

有些修改篇幅很长：跨越好几页的段落，或者在数百个地方一致应用的某项更改。对于这些情况，我们向软件工程进行了取经。2026 年 3 月，Anthropic 在一个公开的 npm 包中意外发布了其 AI 编码智能体 Claude Code 的源代码。7

那个泄露的代码编辑器教给我们一个显而易见的道理：要编辑较长的内容，就得将其拆解。我们将文档拆分为多页一组（这种技术称为分批处理），并将长段落拆分为句子，这样每次编辑的规模都足够小，从而确保准确无误。

将文档拆分会产生一个新问题：上下文。如何使用第 2 页上的定义来编辑第 60 页上的段落？在这里，两年来在 AI 代码编辑器（Cursor、GitHub Copilot、OpenAI Codex）中积累的经验派上了用场。他们的答案是上下文工程，它将相关信息收集到一个聚焦的集合中，并将其提供给拥有干净上下文窗口的子代理。8 我们对文档采用相同的方法。我们像仔细的读者一样将逻辑相关的信息分组，然后将其与编辑目标一起发送给负责实际修改的子编辑。

1批量处理文档

第 1–40 页第 41–80 页第 81–120 页第 121–160 页第 161–200 页第 201–240 页第 241–280 页第 281–300 页

2拆分长段落

第18.3条 · 第60页
句子 1句子 2句子 3句子 4句子 5

3收集上下文，然后并行编辑

定义术语第 2–12 页

各方与角色第 1 页

先前的修正案第 34 页

子编辑 1第 1–40 页 + 集合

子编辑 2第 41–80 页 + 集合

子编辑 3第 81–120 页 + 集合

图 5一份 300 页的文档被拆解。每个子编辑获得文档的一小部分以及该部分所依赖的上下文。

示例：遮蔽判决书

律师要求将判决书中的每个证人姓名遮蔽，并列出其引用的案件清单供初级律师研究。

  1. 搜索。 通过常规模式匹配查找每一个个人姓名和每一个判例引文。目前还不需要模型。
  2. 分类。 每个姓名及其前后的句子都会发送给一个模型，由其判定：证人、律师还是法官。这些答案共同构成了证人集合。
  3. 收集。 同样的方法构建了一个被引用案例的集合。
  4. 执行。 由于我们确切知道每个证人姓名出现在哪里，我们会在原始文件中只对这些位置进行遮蔽。

高等法院

王座分庭

Harrow v Kestrel Logistics Ltd

修改前：Mrs Justice Holloway

判决书

Mrs Justice Holloway：本索赔源于被告仓库装卸区于 2024 年 3 月 14 日发生的坍塌。原告由 Ms Priya Raman 代表，被告由 Mr Thomas Whitby 代表。我听取了为期四天的口头证词。

主要目击证人Mr Daniel Okafor是夜班叉车工。Mr Okafor在法庭上作证说，该装卸区的警示灯已经损坏数周，且他曾对此进行过两次汇报。第二位证人Ms Margaret Ellison是一名在2月份检查过该装卸区的承包商，她证实其报告建议立即进行维修。我认为这两位证人都谨慎且可信。

占有人对合法进入其场所者负有注意义务，这一点已是既定原则，我以 Donoghue v Stevenson [1932] AC 562 中的邻居原则作为出发点。在新型情形下施加义务是否公平、公正、合理，由 Caparo Industries plc v Dickman [1990] 2 AC 605 规范，但本案情形并非新型。Mr Whitby 辩称，所主张的损失过于遥远。该辩称须对照 Hadley v Baxendale (1854) 9 Exch 341 加以检验。

在综合权衡了 Mr Okafor 和 Ms Ellison 的证词以及相关文件后，我确信被告在知晓缺陷的情况下未能采取行动。原告胜诉，责任成立。损害赔偿额将在后续听证会上评估。感谢 Ms Raman 和 Mr Whitby 清晰且切中要害的陈述。

图 6切换视图以查看结果。判决内容和姓名纯属虚构；所引用的三个案例均为真实案件。

05

chatgpt.com、claude.ai和其他聊天网站能做到这一点吗？

有时，是的。这些网站通常包含一个 Python 解释器，允许模型打开 Word 或 PowerPoint 文件并使用代码编辑其 XML。

但代码仍然是由一个不稳定的模型编写的，并且没有什么机制来对照原文检查结果。在我们内部测试中，我们经常收到包含意外删除和修改的文档。在一个极端案例中，一份20页的文档返回时变成了10页，且没有任何警告。

带Python的聊天网站

20 页
10 页

完成！我已根据你的要求更新了文档。

未提及缺失的 10 页。

更新日志

  • 第 4 页 · 第 2.1 条

    三十（30）天 六十（60）天

    还原
  • 第 9 页 · 第 6.3 条

    供应商 承包商

    还原
  • 第 17 页 · 附表 1

    US$2,400 US$2,600

    还原

生成新文档

图 7左侧：我们内部测试中的静默截断。右侧：OneTurn 上的所有 AI 更改均已列出且可还原。

对于任何严肃的工作而言，悄无声息的遗漏或修改都是致命的。在 上，我们的 AI 智能体所做的每一次更改都会被记录下来。你可以审阅每一处更改、撤销其中任何一处，并生成新的文档。

06

像 OpenClaw 或 Manus 这样的计算机使用智能体（computer-use agent）能做到这一点吗？

这些智能体像人一样控制计算机。它们在 Microsoft Word 或 PowerPoint 中打开文档，然后进行滚动、点击和键入。11 因为它们使用与人类相同的程序，所以它们能像人类一样进行编辑，而且其结果往往令人印象深刻。

代价是成本和速度。智能体通过在滚动时截取屏幕截图来阅读文档，每一个小步骤都需要调用模型来决定下一步做什么。单张全高清截图本身就要消耗大约 1,500 到 2,700 个 Token。10 在 OSWorld 基准测试中，即使是表现最好的智能体，其执行步骤也比必要的多出 2.7 到 4.3 倍，并且后期的步骤比早期步骤耗时多达 3 倍。9

计算机使用智能体

  1. 截屏
  2. 模型决定下一步操作
  3. 滚动、点击或输入
  4. 对每个步骤重复此操作

  1. 仅阅读一次文本
  2. 批量编辑
  3. 写入文件
20页的合同，30处修改计算机使用智能体
模型调用≈ 180≈ 12
每次调用的 Token 数≈ 10,000≈ 4,000
总 Token 数≈ 1,800,000≈ 48,000
差异约为 37 倍，或在 OSWorld 上测得加上额外步骤后约为 100–160 倍
图 8假设：约 11,000 个单词；60 张用于阅读文档的截图；每次修改进行 4 次操作；每次调用包含一张截图以及近期历史记录。OneTurn 会阅读一次文本并批量发送修改内容。

据我们估计，对于相同的修改，计算机使用智能体（computer-use agent）消耗的 LLM Token 数量可能比 多达 100 倍，且完成所需的时间要长得多。

来源

  1. WordprocessingML 文档的结构微软 Learn · Open XML SDK 文档
  2. ECMA-376：Office Open XML 文件格式Ecma 国际 · 标准
  3. 验证字处理文档微软 Learn · Open XML SDK 文档
  4. 当你委派任务时，大语言模型会损坏你的文档Laban、Schnabel 和 Neville · 微软研究院 · 2026
  5. LongProc：长文本语言模型在长程序生成任务上的基准测试Ye 等人 · COLM 2025
  6. 即使检索完美，仅靠上下文长度也会损害大语言模型的性能Du 等人 · EMNLP 2025 年研究结果
  7. Anthropic 通过 npm Source Map 文件意外泄露 Claude Code 源代码InfoQ · 2026年4月7日
  8. 面向 AI 智能体的有效上下文工程Anthropic 工程团队 · 2025年9月29日
  9. OSWorld-Human：计算机使用智能体效率基准测试Abhyankar、Qi 和 Zhang · MLSys 2026
  10. 视觉：分辨率与 Token 成本Claude Platform 文档
  11. 在 OpenClaw 热潮中，Meta 的 Manus 推出桌面应用，将其 AI 智能体引入个人设备CNBC · 2026年3月18日

各图均为专为本文制作的插图。XML 是真实的 WordprocessingML；文件名称、人员和判决均属虚构。

在一个绝不能出错的文档上试试吧。

免费试用 →