LibreOffice Writer 导出修订后的定稿：按作者和日期筛选、接受拒绝与文档核对

多人轮流改一份方案时，最容易出问题的不是“有没有留修订痕迹”，而是负责定稿的人随手点了“全部接受”，回头才发现有些修改根本不是对应角色提交的、甚至超出了约定的评审时间范围。LibreOffice Writer 自带的修订管理功能，可以先按作者和日期缩小待处理范围，再逐条判断接受或拒绝，最后导出一份没有残留修订标记的干净定稿。

先准备一份可回退的评审版

假设产品说明书已经收到了设计和开发两轮修改，文件名是 release-note.odt。先复制一份评审版，例如 release-note-review.odt，在副本上处理修订。这样即使某条修改接受错了，仍能回到原始修订状态，不必向同事重新索要文件。

打开待处理的协作文档后，先扫一遍页面上的删除线、下划线或者侧边栏标记，确认这些是修订生成的，不是普通手动加的字体格式。LibreOffice 生成的修订记录默认会附带提交作者和精确操作时间，这也是后面我们做范围筛选的依据。

从修订管理窗口筛出本轮要处理的内容

在 Writer 顶部菜单选择“编辑 > 追踪修订 > 管理”，就能调出修订管理窗口。列表页会逐条展示所有改动内容，切换到筛选标签页就可以指定过滤的作者、日期和时间范围。比如你只想处理本周设计评审留下的修改意见，就可以把作者限定为对应评审人，再填好开始和结束的日期区间。

筛选完不要光盯着列表的颜色判断范围。官方帮助里明确提过，蓝色的条目本身可能不匹配你设置的筛选条件，只是它下面嵌套的子项里有符合规则的记录；灰色条目是没法直接点击接受或拒绝的。把父项全部展开，点选真正的叶子级改动操作，就能避免把一组关联的层级记录误当成单条改动处理。

作者筛选适合处理责任边界

如果同一份文档里同时有产品、开发、法务多方的修改意见，优先按作者维度筛选处理最稳妥。产品提交的文字调整可以直接纳入定稿，法务留下的修改标记最好先翻回对应上下文再判断是否采纳。筛选只是调整列表的显示范围，工具不会替你判断内容本身合不合理。

日期筛选适合处理一轮评审

日期范围筛选适合清理“昨天到今天新提交”的改动。选边界日期的时候要留意时间范围是不是覆盖了完整的一整天，别因为筛选起点选成了当天下午，漏过了上午提交的改动。当前批次处理完之后记得清除所有筛选条件，再扫一遍列表里有没有剩下其他人的待处理记录。

逐条决定接受、拒绝还是暂时保留

选中某条修订之后，先切回正文看它影响的完整上下文句子，再点接受或者拒绝。接受操作会把修改内容直接写入最终正文，拒绝操作会恢复成修改前的原始内容。这两个操作都不是“把标记藏起来”，而是实打实修改文档内容，所以别以为关掉“显示修订”的开关就等于做完定稿了。

同一个作者提交的连续大段文字改动，确认完上下文之后可以用批量操作省时间；但涉及标题、业务数字、法律措辞或者接口参数这类关键内容，建议还是逐条核对处理。如果需要全程保留讨论痕迹，可以先在原始评审版里做完所有采纳/驳回的判断，另存出来的定稿文件就只留最终的纯正文内容。

保存和导出后做一次反向验收

所有改动处理完之后，先清除所有筛选条件，重新打开修订管理窗口，确认没有遗漏的待处理修订。然后把内容另存为新的定稿文件，不要直接覆盖你手里唯一的那份原始评审存档版。如果交付要求是PDF格式，走“文件 > 导出为 PDF”生成交付件就行；如果对接方之后还要继续编辑文档，就同时保留ODT格式的源文件。

导出完成之后要打开刚生成的PDF，或者重新打开存好的定稿ODT做校验，重点核对三处：标题和版本号是不是正确、表格和分页有没有乱掉、正文里是不是还残留着修订标记或者没处理的评审批注。导出的PDF只是最终交付件，不能替代源文件的留档备份。

常见问题

关闭“显示修订”是不是就等于接受全部修改？

不是。关闭显示修订的开关只是隐藏了页面上的标记，所有修订记录还完整存在文件里。要出定稿的话，必须回到修订管理窗口逐条确认接受或者拒绝所有改动，再保存文件。

筛选后为什么还有蓝色的项目？

蓝色条目大概率是包含匹配子项的父级条目。展开它的层级处理完真正符合筛选条件的子项，全部操作结束之后记得清除筛选条件再做一次全量复查。

接受全部修订前要保留什么？

至少要单独存一份原始评审版和一份处理前的备份副本。标题、金额、日期、版本号这类关键字段，最好由第二个人在最终导出的交付文件里再交叉核对一遍。

交付前的最小清单

• 作者和日期筛选已经全部清除，修订管理窗口确认没有遗漏的待处理记录。
• 关键修改都已经对应到上下文逐条确认过，只有非核心的批量改动用了批量处理操作。
• 定稿ODT源文件和交付PDF都已经单独备份，原始评审版的存档还保留可以随时回退。
• 重新打开交付文件校验，标题、页数、表格和版本号都和预期的定稿内容完全一致。