AI改稿先别交,问题出在Word修订链:开源Adeu把新文本写成可接受、可拒绝的原生修订

AI 情报库 · AI项目

聊天框交付的是新文本，Word 审阅需要的是可接受、可拒绝、能追到作者的原生修订。

关注这个号，每天只挑一件 AI 里真正值得理解的事。

你把一份合同、制度或投标文件交给 AI，它很快给出“建议把纽约州改成特拉华州”之类的修改。Adeu 是一个开源 DOCX redline 工具：它接收原始 Word 和结构化修改，把新文字写回成可接受、可拒绝、能追到作者的原生修订。文字看起来没问题，真正返工却从这时开始：原来的批注、编号和加粗有没有被弄丢？同一句话出现两次时，程序会不会改错位置？

这就是“AI 改完了”和“文件可以交”之间的缺口。聊天框交付的是新文本，Word 审阅需要的是可接受、可拒绝、能追到作者的原生修订。

它还提供 Python、TypeScript、CLI 等入口。对普通办公读者，先记住它的位置就够了：Adeu 不替你判断内容该不该改，而是负责把已经决定的修改，尽量安全地投回原文档。

真正可交的 Word 自动化，至少要同时通过三道检查：修订能审、原结构能复核、目标有歧义时不落盘。少一道，省下的复制时间都可能变成后面的人工找错。

直接改写Word：State of Delaware对了，修订链却没了

最简单的自动化，是打开 DOCX，找到某个段落，把段落文字换掉，再保存一份新文件。它很适合生成模板或干净的新文档，却不自动等于审阅交付。

Word 的修订不是红色字体，也不是在新词旁边加删除线。DOCX 本质上是一个压缩包，正文位于 OpenXML 文件中。原生修订会把删除内容放进 w:del 节点，把新增内容放进 w:ins 节点，还记录作者。Word 打开后，审阅者才能逐项接受或拒绝。

如果程序只是把段落的最终文字改成 State of Delaware，眼睛看见的结果可能正确，但审阅链已经断了：没有谁删了 New York，也没有谁插入 Delaware。遇到受控文件、多人协作或客户往返，这个差别不是美观问题，而是责任和复核成本。

本次最小对照就出现了这种情况。直接用 python-docx 给整个目标段落重新赋值，最终文本确实变对了；Word 16.0 也能正常打开。然而 Word 里修订数是 0，原有批注数从 1 变成 0，目标段原有的粗体和斜体也消失了。

这不等于 python-docx 做不了精细编辑。开发者可以逐个 run 操作，甚至直接编写 OOXML；只是批注锚点、跨 run 匹配、修订作者和歧义门禁，都要自己继续补。对“只要最终文本”的任务，这条路很省；对“必须让别人审”的任务，工程账会迅速变厚。

Adeu把结构化修改投回Word审阅链

可以把这条工作流拆成三层。第一层是 AI 或人提出修改，例如“把管辖法律从纽约州改为特拉华州”；第二层把建议变成明确的结构化操作，包括目标原文、新文本和匹配方式；第三层才是 DOCX 写回，生成原生修订并保存文件。

Adeu 位于第二层和第三层之间。输入是一份 DOCX 与一组修改，动作是定位目标、验证是否唯一、生成删除和插入，输出是一份带修订的 DOCX。它不会替业务负责人决定条款，也不会因为能写 redline，就自动获得批准文件的权限。

这个边界很重要。团队如果让模型直接“重写整份文件”，程序很难分清哪些变化是有意修改，哪些只是模型换了措辞或排版。结构化 edit 把一次任务收窄成“在唯一位置把 A 改为 B”，审计面小得多，也更容易在失败时停住。

这背后是组织工作方式的变化：文档 AI 正从“生成一份新稿”转向“修改一份正在流转的受控文件”，因为下一位参与者还要接着审、批、退回和留档。放到工具链分工里，模型层提出内容，DOCX 工具层写回结构，Word 交付层承接审阅，组织治理层决定谁能批准。核心矛盾不是能不能自动改字，而是自动化速度与可追责、可停止之间的张力。

未来文档 AI 的竞争会从“谁生成得更快”转向“谁能更稳地进入既有工作流”。同类工具若没有唯一定位、原生审阅对象和失败关闭，即使一次结果漂亮，也很难进入高频团队流程。比起一次把字改对，我更关心下一位审阅者是否还能沿着原文件继续工作。

Adeu 还能把 DOCX 投影成 Markdown/CriticMarkup，方便程序读取原始修订视图和接受后的 clean view。前者回答“删了什么、加了什么、谁改的”，后者回答“如果全部接受，读者最后看到什么”。两种视图都要看，只看 clean view 会漏掉修订作者和批注是否仍在。

为了让结果可复核，输入不是一份只有一句话的空白文档，而是放进几种常见结构：一个一级标题、两个项目符号列表、一个带批注的斜体句、一个跨文字 run 的唯一短语 State of New York，以及出现两次的 Renewal notice is required.。另有一段未触及的粗体文字作为控制项。

唯一目标的结构化修改很短：

[
  {
    "type": "modify",
    "target_text": "State of New York",
    "new_text": "State of Delaware",
    "match_mode": "strict"
  }
]

同一个输入分别交给 Adeu 的 Python 与 TypeScript 引擎，修订作者设成不同名字，便于在 Word 里反查。随后用四个角度复核：引擎返回值、raw/clean extract、解包后的 OOXML，以及 Microsoft Word 16.0 只读打开结果。

这不是“所有 Word 格式都通过”的证明。它只回答一个更小、也更实用的问题：在包含标题、列表、批注、强调样式和重复锚点的样本里，核心交付承诺能不能成立。

Adeu双引擎写回：Word出现1删1增和两条修订

Python 输出包含 1 个删除节点和 1 个插入节点，作者是 Codex Python Lab；TypeScript 输出也是 1 删 1 增，作者是 Codex Node Lab。两个文件在 Word 16.0 中都显示 2 条修订，并且无需修复即可打开。

raw view 清楚显示 New York 被删除、Delaware 被插入；clean view 的句子则变成 State of Delaware。这两个结果合在一起，才证明“审阅轨迹”和“接受后的正文”都对上了。

对照文件只有最终文本，没有删除、插入和作者。两边肉眼都能看到 Delaware，但交给下一位审阅者时完全不是一回事：Adeu 输出允许他接受或拒绝这一处修改；静默改写只能让他重新找原版对照。

这也是判断“AI 办公自动化是否省时间”的第一笔账。生成建议只省了思考与起草时间；如果建议无法进入现有审阅界面，团队还要付复制、对照、解释和责任确认的成本。真正的效率不是少点一次鼠标，而是下一位参与者能沿着原流程继续工作。

Adeu Python保留3个关键部件哈希，Node改写numbering与settings

Word 实机检查中，两份 Adeu 输出都保留一级标题、两个项目符号列表和 Original Reviewer 的原有批注。目标段的粗体、斜体仍在，未触及控制段的强调也能在 extract 中读到。直接段落改写虽然保住了标题和列表段落样式，却让 Word 看不见原批注，并丢掉目标段的 run 级强调。

但“可见结果一致”不能写成“两个引擎生成同一个文件”。Python 输出的 styles.xml、numbering.xml、settings.xml 与输入文件哈希一致；TypeScript 输出的 styles.xml 仍一致，numbering.xml 和 settings.xml 的包部件哈希却发生了变化。Word 打开后列表和批注仍正常，说明这份样本的语义检查通过，却不能证明包级字节保真。

TypeScript 引擎还有一个更直接的审计提醒：仓库 checkout、标签和 package.json 都是 v1.27.0，它的 process_batch 返回结果却自报 version: 1.18.2。这个字段来自源码里的硬编码值。本次功能结果没有因此失败，但如果团队把它直接写入合规日志，就会得到错误版本。

所以，自动化记录至少要同时保存工具 tag、commit、包版本和输出哈希，不要只相信单个运行时字段；对重要格式，还要保留 Word 实机打开与自己的 fixture。两套引擎能得到相同 clean text，不代表它们在包内部做了相同的事。

Adeu strict遇到两句相同时为什么拒绝落盘

文档里故意放了两句完全相同的 Renewal notice is required.。把这句话作为 strict 目标、要求改为 optional 时，Python CLI 退出码为 1，TypeScript 脚本同样返回 BatchValidationError。两个预定输出文件都没有创建。

错误不是一句模糊的“匹配失败”。它列出两处命中的上下文，并给出三条可选路径：增加更多前后文，让目标变成唯一；确认两处都该改后明确使用 all；确认第一处就是目标后明确使用 first。

这里最值得迁移的不是某个参数名，而是一条自动化纪律：找不到不写，找到多处也不写。只有调用者补足意图，系统才继续。

很多 AI 写文档事故并不是模型不会改，而是“看起来差不多”的目标太多。付款期限、公司名称、责任上限可能在正文、附件和定义表中重复出现。程序如果默认选第一处，速度越快，错得越隐蔽。strict 把歧义变成显式返工，反而降低了后面人工搜错的成本。

用Adeu副本跑extract与apply：先验一处再碰整份合同

Adeu 的 Python 工具链要求 Python 3.12 或更高版本，Node 核心库要求 Node 22 或更高版本。对初学者，更稳的起点是一份专门的副本，不是正在流转的正式文件。

先准备一个最小 DOCX：放入一个标题、一段加粗文字、一条批注、一组列表，再放一个唯一短语和一个重复短语。然后只跑三条路径：extract 原文、apply 一处 strict 修改、extract 输出的 raw 与 clean view。最后用 Word 打开，核对 revisions、comments、列表与目标外文本。

CLI 的核心形状如下：

adeu extract input.docx --page all -o input.md
adeu apply input.docx changes.json --author "Review Bot" -o redlined.docx --json
adeu extract redlined.docx --clean-view --page all -o accepted.md

成功信号不是“命令退出 0”这一条，而是四件事同时成立：raw view 有删除与插入，clean view 只有目标新文本，Word 中修订作者正确，目标外结构没有出现意外变化。重复锚点测试则应该退出非 0，并确认输出文件不存在。

如果 Word 弹出修复提示、clean view 改动了目标外文本、批注或关键编号消失，或者重复目标仍然写出了文件，就该停在样本阶段。先补 fixture 或缩小自动化范围，不要用“人工最后再看一遍”掩盖不可重复的写入行为。

v1.27.0 关联的 QA 回归文件也在本机实际运行过：Python 这一组是 41 项通过，TypeScript 是 9 项通过。它们能增加对版本实现的信心，但不能替代你的文档样本。项目标签里仍保留一份 QA 问题清单，涉及 live Word 延迟、标题识别、定稿路径差异、表格行等；没有逐项关闭映射的地方，都不应自动写成“新版已经全部解决”。

Word手工修订、Compare和python-docx什么时候更省

如果只有一两份文件、每处修改都必须由人判断，直接在 Word 开启修订通常最省。它没有环境安装成本，审阅体验也最成熟。Adeu 的价值不在替代这种单次人工工作，而在几十份文件需要重复写回同一种结构化修改时。

如果已经有原版和完整修改版，Word Compare 是自然选择。它能事后生成差异，不要求生成端理解 redline。代价是修改版一旦同时改变排版、分段或样式，差异面可能扩大；这次没有做 Word Compare 的量化对照，不能预设它一定更吵或更差。

如果任务是创建新文件、填模板，或者交付根本不需要逐项审阅，直接 python-docx 往往更轻。只有当原生修订、批注、跨 run 格式、唯一锚点和失败落盘都变成硬要求时，专门的 redline 引擎才开始显出价值。

采用成本也不只是一条安装命令。团队要维护依赖与版本记录，为自己的文档结构建立回归样本，决定谁能批准结构化修改，并在升级后重跑 Word 实机检查。Node 自报版本不准、包部件哈希变化这类小问题，正说明“能运行”与“能审计”之间仍有一段工程路。

Adeu原生修订不是批准：数据与复杂DOCX边界

Adeu 的本地核心可以在机器上处理 DOCX，但如果前面的修改建议来自外部 LLM，文档文字是否离开本机，仍由你选择的模型服务和调用方式决定。“本地写回”不能替代数据分级、脱敏和供应商合规判断。

生成 redline 之后，接受或拒绝修订、移除批注、清理作者与隐藏元数据，又是下一阶段。项目提供 accept-all 和 sanitize 路径，但这次实验没有验证定稿清理，也没有覆盖脚注、尾注、域代码、内容控件、复杂多级编号、交叉引用和表格编辑。关键文档只要依赖其中一项，就应该先补样本，再谈批量接入。

因此，适合采用 Adeu 的不是“任何想让 AI 改 Word 的人”，而是已经能产出明确结构化修改、仍要求人在 Word 里审阅、并愿意维护文档 fixture 的团队。不适合的，是希望把整份敏感文档丢给模型后直接得到批准终稿，或者把一次小样通过当成全格式保证的流程。

下次再看到“AI 已经能自动改 Word”，真正该追问的不只是它能不能把 A 换成 B，而是当目标不唯一、结构比样本复杂、审阅人需要追责时，系统会留下可核验的修订，还是选择继续写下去？