我们都有过这样的经历。你正在完成一篇至关重要的论文、商业计划书或复杂的报告。内容堪称完美，但格式却一团糟。字号不统一，缩进有点偏差，而且出于某种原因，第三段的黑色色号和其他段落不一样。

接下来的一个小时，你不得不点击各种菜单，拖动标尺，寻找“删除段后间距”的按钮。这既乏味又重复，还打断了你的创作思路。

但是，如果你只需要告诉电脑: “把所有标题改成蓝色加粗，把第三段设为双倍行距”，然后这一切就能瞬间完成，那会怎样？

这就是这篇引人入胜的新论文 “Free your mouse! Command Large Language Models to Generate Code to Format Word Documents” 的前提所在。研究人员提出了一种系统，利用大型语言模型 (LLM) 作为引擎，将你的自然语言指令转化为可执行代码，从而自动格式化 Word 文档。

在本文的深入探讨中，我们将了解他们是如何构建这个系统的、用于测试该系统的独特数据集，以及使其发挥作用的复杂提示策略。

问题所在: 为什么我们不能直接“吩咐”Word？

Microsoft Word 功能强大，但其能力被锁定在图形用户界面 (GUI) 之后。要格式化文档，你必须使用鼠标选择特定文本并点击特定按钮。这是一个“手动”过程。

随着代码生成模型 (如 GitHub Copilot 或 GPT-4) 的兴起，我们已经看到了 AI 如何将自然语言转化为 Python 或 SQL。研究人员提出了一个简单的问题: 我们能否将文档格式化视为一种代码生成任务?

目标不是模拟鼠标点击，而是生成脚本 (具体来说是使用 Office Add-ins API 的 JavaScript) ，以编程方式执行格式化。

图 1: 文档格式化任务及基于代码生成的自动格式化方法示意图。

如上图 1 所示，这个概念非常直观。左侧 (b) 是原始文档和一组自然语言指令 (例如，“将第 2 段加粗”) 。这些指令通过代码生成模型 (C)，模型输出一段脚本。当脚本运行时，你就得到了右侧的“修改后的文档”。

然而，要在现实世界中实现这一点出奇地困难。标准的 LLM 虽然擅长 Python，但在处理 Microsoft Word JavaScript API 这种特定的、小众的语法时往往很吃力。此外，之前也没有合适的方法来评估 AI 是否真的擅长这项任务——直到现在。

奠定基础: DOCFORMEVAL

在解决问题之前，你需要先衡量问题。现有的代码基准测试 (如 HumanEval) 侧重于算法逻辑，而不是文档布局。为了解决这个问题，作者构建了一个全新的评估数据集，名为 DOCFORMEVAL 。

为文档格式化创建数据集并不像抓取网页那么简单。数据需要精确、可执行且多样化。研究人员使用了一种巧妙的自下而上的方法来构建这个数据集。

构建流程

团队并没有直接编写随机指令。他们对格式化过程进行了逆向工程。

图 2: DOCFORMEVAL 构建流程概览。

如图 2 所示，该过程涉及几个步骤:

  1. 原子操作收集 (Atomic Operation Collection) : 他们首先确定“原子”操作——即最小可能的格式化动作，如“将字号设为 12”或“字体加粗”。他们将这些操作映射到实际的 Word API 属性 (键值对) 。
  2. 复杂操作组合 (Complex Operation Combination) : 现实世界的指令很少是简单的。我们通常希望同时做几件事。系统随机组合这些原子操作，创建复杂的格式化“骨干”。
  3. 初始合成 (Initial Synthesis) : 利用模板，他们将这些骨干转化为基本的自然语言指令和相应的真实代码。
  4. GPT-4 多样化处理 (GPT-4 Diversification) : 模板生成的文本听起来很机械 (例如，“将字号设为 12。将颜色设为红色。”) 。为了使数据集逼真，他们使用 GPT-4 Turbo 将这些指令重写为自然、多变的人类语言。
  5. 人工验证 (Manual Verification) : 最后，人工标注员审查数据，以确重写后的指令与代码实际匹配。

数据集里有什么？

其结果是一个包含 1,911 个高质量样本的稳健数据集。这个数据集的挑战性在于其复杂度的多样性。

图 10: DOCFORMEVAL 中的指令复杂度分布。

图 10 展示了复杂度分布。虽然约 27% 的任务是“简单”的 (需要 1-5 行代码) ，但很大一部分属于“中等”或“挑战级”类别，需要复杂的脚本来执行。这确保了模型不仅仅是死记硬背简单的命令，而是在推理复杂的需求。

核心方法: TEXT-TO-FORMAT

有了数据集，我们再来看看解决方案。作者提出了一个名为 TEXT-TO-FORMAT 的框架。

简单地要求 LLM “格式化这个文档”通常会失败。模型可能会产生不存在的 API 调用的幻觉，或者编写出导致语法错误的代码。为了解决这个问题，TEXT-TO-FORMAT 采用了一个四阶段的流水线，旨在引导 LLM 找到正确的解决方案。

图 3: 我们提出的 TEXT-TO-FORMAT 架构。

让我们分解一下图 3 所示的架构。

1. API 知识检索 (RAG)

大型语言模型见过很多代码，但它们可能没有记住 Microsoft Word JavaScript 库的具体文档。

为了解决这个问题，系统使用了检索增强生成 (RAG) 。 研究人员建立了一个包含正确 API 代码片段的知识库。当用户要求某种特定格式 (例如，“高亮文本”) 时，系统充当搜索引擎的角色。它将用户的指令转换为向量，并在知识库中搜索最相关的 API 文档。

\[ C _ { r e t } = R ( I , k , C _ { a p i } ) \]

如上式所述，检索函数 \(R\) 接收指令 \(I\) 并检索前 \(k\) 个相关的 API 片段 (\(C_{ret}\))。这个上下文至关重要，因为它为 LLM 提供了编写正确语法所需的“小抄”。

2. 代码生成

接下来，系统构建提示词。它结合了:

  • 用户的指令。
  • 检索到的 API 知识。
  • (可选) 少样本示例 (以前成功代码的演示) 。

这个丰富的信息被发送给 LLM，由 LLM 生成格式化代码。

3. 执行

这是这项任务与写文章不同的地方。代码必须运行。生成的脚本在一个运行时环境 (模拟 Word 的沙箱) 中执行。

4. 自我修正 (Self-Refinement)

这是系统的“智能”部分。如果生成的代码崩溃 (抛出异常) ，系统不会直接放弃。它会捕获错误消息并将其反馈给 LLM。

提示词本质上是说: “你尝试编写了这段代码，但失败并显示了此错误消息。请修复它。”

这种循环允许模型自我修正，显著提高了可靠性。

实验与结果

那么，它的效果如何？研究人员使用各种 LLM 测试了这个框架，包括开源模型 (如 Qwen2 和 DeepSeek) 和商业巨头 (如 GPT-4 Turbo) 。

他们使用了三个关键指标:

  1. 格式化准确率 (FA): 代码是否运行并且产生了正确的视觉结果？
  2. 执行异常率 (EER): 代码是否崩溃了？
  3. 格式化错误率 (FER): 代码是否运行了但产生了错误的结果？

提示策略的力量

下表总结的结果揭示了简单提示与完整的 TEXT-TO-FORMAT 流水线之间的巨大差距。

表 2 总结了……

注意: 在上表中，“Prompt”指的是直接询问模型。“Doc Prompting”指的是 RAG 方法。

结果的关键要点:

  • 零样本失败: 简单地要求 GPT-4 Turbo 生成代码 (“Prompt”行) 仅产生 34.41% 的准确率。它根本不够了解该 API。
  • RAG 改变了游戏规则: 添加检索到的文档 (“Doc Prompting”) 将 GPT-4 的准确率提高到了 81.26% 。
  • 自我修正锁定胜局: 当你结合 RAG、少样本学习 (展示示例) 和自我修正时，准确率达到了 91.43% 。

这证明即使是最强大的模型，在处理此类专业任务时也需要外部知识和反馈循环。

复杂度的挑战

系统并非完美。随着指令变得越来越复杂，性能会下降。

图 4: 格式化指令中涉及的属性数量对性能的影响。

图 4 显示了不同模型的性能趋势。

  • 蓝线 (准确率) : 注意随着“属性数量” (你希望同时格式化的项目数量) 增加，准确率是如何下降的。
  • 橙线 (异常) : 对于像 Gemini Pro 这样较弱的模型，随着复杂度上升，代码崩溃的频率显著增加。
  • 然而，像 GPT-4 Turbo (右上图) 这样的强模型保持了相对平坦的曲线，这表明即使在同时处理 10 个以上的格式化命令时，它们也更加稳健。

准确率的代价

这是一种权衡。为了获得 91% 的准确率，系统使用了“少样本”提示，这涉及在要求模型生成新代码之前向其提供许多正确代码的示例。这会消耗大量的“Token” (文本处理成本单位) 。

图 6: GPT-4 Turbo 上各种提示策略的 Token 消耗。

图 6 展示了 Token 的使用情况。最左边的柱状图 (“Doc Prompting few-shot”) 最高。虽然这种方法最准确，但运行成本也最高。“输入 Token” (蓝色/浅绿色) 非常高，因为模型每次都必须阅读所有的示例和 API 文档。

结论与未来展望

TEXT-TO-FORMAT 论文展示了办公自动化的一大飞跃。通过将文档格式化视为代码生成问题，研究人员打开了一扇通往未来的大门，在那里我们可以通过对话而不是点击来与软件交互。

主要收获:

  1. 专业数据至关重要: DOCFORMEVAL 的创建填补了一个关键空白，使研究人员能够衡量 AI 与办公软件 API 的交互能力。
  2. 上下文为王: LLM 无法独自完成这项任务。它们需要检索增强生成 (RAG) 来访问特定的 API 文档以编写可工作的代码。
  3. 自我修正行之有效: 允许模型查看自己的错误消息并“重试”，可以大幅降低失败率。

也许最令人兴奋的影响在于隐私 。 实验表明，开源模型 (如 DeepSeek 或 CodeQwen) 如果在本地部署并结合这些技术，可以实现可观的性能。这意味着公司可以在离线状态下运行这些格式化工具，确保机密合同或法律文件永远不会离开其安全服务器。

虽然我们要完全扔掉鼠标还需要一段时间，但这项研究证明，与段落间距和字体不一致作斗争的日子已经屈指可数了。很快，你可能只需要输入“把这个弄成专业的商务信函样子”，剩下的就交给 AI 吧。