技能提升网如果文件夹里开始出现“方案最终版”“方案最终版2”和“方案真的最终版”，这份文档多半已经失去明确的修改线索。有人在聊天里提意见，有人直接覆盖原文，还有人拿旧版本继续改。等到交付前，团队只能把几个文件并排打开，猜哪一处才是最后决定。
这种混乱靠更勤快地改文件解决不了。先把原稿、修改意见和最终确认分开，再让每一处调整留下记录，后面才有机会查清来龙去脉。
先别合并第六个最终版
保留一份明确的基准文档。所有文字修改都以它为起点，其他人提交的版本先比较差异，不直接覆盖。Word可以比较两个版本，也能把多位审阅者的修订合并到新文档中。合并后仍要逐条决定接受或拒绝，不能把自动合并当成最终确认。
| 容易失控的做法 | 更容易核对的做法 |
|---|---|
| 每个人保存一个新文件 | 指定一份基准文档，其他版本只用于比较 |
| 直接改掉原句 | 用修订保留插入和删除 |
| 把意见发在聊天窗口 | 把批注锚定到对应文字 |
| 只交一份看起来干净的文件 | 同时保留审阅稿与干净稿 |
修改意见不要全塞进正文
文字错误可以直接修订；需要作者回答的问题适合用批注；涉及价格、责任范围或交付日期的内容，需要明确由谁决定。三类意见混在一起时，文档里会出现大量括号、颜色和临时说明，接受修订后反而可能把讨论文字留进正式版本。
批注最好指向具体词句。比如“这段再确认一下”很难处理，换成“交付日期与附件二不一致，请确认以哪一处为准”，接手的人能直接找到冲突。批注里写问题和依据，修订里保留实际改动，两者的职责就不会打架。
每位审阅者还应使用稳定的作者名称。DOCX的修订记录包含作者和时间，名称频繁变化会把同一个人拆成多个审阅者，也会增加筛选难度。
屏幕上连续的一句话，文件里可能是好几段
DOCX本质上是由多份XML组成的压缩包。Word会因为样式、拼写检查或旧的修订标记，把一段可见文字拆成多个运行节点。屏幕上明明能看到完整句子，程序直接搜索时却可能找不到。
DOCX Skill针对这种情况提供了编辑思路和辅助脚本。处理已有文档时，可以先合并格式相同的相邻运行节点，再修改document.xml。做红线稿时，插入和删除需要写入正确的修订标记，并记录作者与时间；批注则要建立关联文件，再把开始、结束和引用标记放到对应文字范围。
这些步骤比普通查找替换复杂，但它们决定了Word能否正确显示修订。如果只改了可见文字，没有写好结构，文件可能能打开，却无法告诉审阅者哪些内容发生过变化。
接受修订前先看完整标记
Word里的“无标记”视图只会暂时隐藏修改。把文件切换到这个视图，并不等于修订已经被接受或删除。对外发送前应查看全部标记，逐项接受或拒绝，再检查是否还留有批注。
删除整段文字时还要留意空段落。某些转换工具接受删除后，可能留下空白项目符号或多余间距。遇到这种情况，需要检查段落标记和实际渲染结果，不能只看导出的纯文本。
交付时保留两个版本
审阅稿负责说明改动过程，干净稿用于正式阅读。两个文件来自同一份确认后的内容，但用途不同。审阅稿保留修订和必要批注，方便负责人复查；干净稿接受已确认的修改，并清理批注、临时高亮和内部备注。
生成干净稿以后，不要马上删除审阅稿。先比较标题层级、页数、表格、图片、页眉页脚和目录，确认接受修订没有改变不该变化的内容。如果方案含有签字页、金额表或附件编号，再单独核对这些位置。
DOCX Skill能处理到什么程度
官方说明显示，DOCX Skill适用于创建、读取和编辑DOCX或DOTX文件，也覆盖查找替换、图片、目录、页码、批注与修订。它会根据任务使用docx、Pandoc、LibreOffice、Poppler和目录内脚本。依赖没有安装时，部分步骤无法执行；旧版DOC文件通常也要先转换成DOCX。
完成文件结构检查后，还要把文档转换成PDF并逐页查看。结构验证能发现XML、关系和内容类型问题，页面渲染则用来找表格超宽、分页异常、图片错位和文字溢出。两种检查不能互相替代。
这个Skill由Anthropic维护，许可证标注为Proprietary。源文件可以公开查看，但使用、保存和再分发仍要遵守对应的LICENSE.txt及适用协议。
提交前把注意力放回决定本身
- 每条批注是否已经回复、处理或明确保留。
- 所有文字改动是否都能在审阅稿中找到修订记录。
- 干净稿是否真正接受了修改，而不是只切换到无标记视图。
- 金额、日期、责任范围和附件编号是否由负责人确认。
- 两个版本的页数、表格、图片和目录是否正常。
修订记录的价值不在于留下更多颜色，而在于让负责人知道改动发生在哪里、为什么改以及谁确认了它。审阅稿和干净稿都核对完成后，再把文件交出去。
