先把正文、评论和版本历史当成三种不同资料。正文适合搜索和迁移，评论与修订要单独整理或导出为讨论记录，并保留作者、时间、位置和结论；用于外发的最终文档不要混入内部讨论。
正文下载成功后，评论区往往还是空的；Markdown 里有最终文字，却看不到谁提出过反对意见；几个月后想查某段内容为什么这样定，只能重新翻飞书。问题不在导出文件坏了，而是正文和协作记录本来就是两层内容。
归档前先回答一个问题：你要保存的是最终正文，还是这次协作留下的判断过程。答案不同，需要保留的内容和验收方式也不同。
先确定归档目的
| 目的 | 应该保留 | 不必强求 |
|---|---|---|
| 公开或交付最终版 | 干净正文、图片、附件、版本号 | 内部讨论和个人提醒 |
| 项目资料交接 | 正文、关键结论、负责人、未决事项 | 所有已解决的闲聊评论 |
| 审计或争议复盘 | 评论原文、作者、时间、修订记录和审批依据 | 与结论无关的临时讨论 |
把三种目的混在一起，通常会导致两个坏结果：最终文档夹带内部评论，或者真正重要的决策被当成普通评论清掉。
正文、评论和版本历史要分开
正文
正文是最后要阅读、搜索和迁移的内容。它应该保持结构稳定，适合转成 Markdown、Word 或 PDF。
评论和批注
评论记录的是讨论过程，可能包含疑问、反对意见、补充资料和 @ 提醒。它们的位置、回复关系和上下文，通常比一串独立文字更重要。
版本历史
版本历史回答“什么时候、由谁、改了什么”。如果文档经过多人协作或正式审批，只有最终正文不足以还原过程。
导出前先做一次真实测试
拿一篇带评论、回复和版本记录的测试文档，分别尝试官方导出、页面打印或浏览器本地导出。检查四个问题：
- 评论是否出现在结果里。
- 评论是否还保留作者、时间和对应段落。
- 多个版本的差异是否能被识别。
- 图片、表格和内部链接是否仍然可用。
不同导出入口保留的内容可能不同，不要只看“文件已下载”，要用真实文档确认协作内容有没有一起带走。
评论记录怎么整理
如果评论需要长期保留，可以把它们整理成一份独立的讨论记录。最小字段包括：
| 字段 | 作用 |
|---|---|
| 文档和版本 | 确认讨论对应哪一份内容 |
| 评论位置 | 指向章节、段落或页面 |
| 评论人和时间 | 保留责任链 |
| 评论原文 | 避免二次总结改变语气和条件 |
| 后续结论 | 记录采纳、驳回或暂缓 |
| 负责人 | 明确谁继续处理 |
已经在飞书里解决的评论，不代表以后也能随时打开。重要项目至少保留一份可离线查看的评论截图、PDF 或讨论记录。
修订记录怎么落下来
版本历史通常不是可以直接复制的一页正文。需要审计时，建议记录：
- 版本号或保存时间
- 修改人和参与者
- 这一版改动的范围
- 修改原因
- 审批或确认结果
如果版本之间差异很大，不要只留下“已完成修改”这五个字。写清是结构调整、数据更新、合规修改还是文字润色，接手的人才知道该核对什么。
发布前要检查的三件事
内部评论有没有被带出去
分享给客户或外部合作方的文件，不应该夹带内部质疑、个人信息、报价讨论或未决风险。
关键结论有没有留下责任人
讨论记录只有观点没有负责人，等同于把问题重新留给下一个人。至少写清谁确认、谁执行、什么时候完成。
归档版本能不能独立打开
断网打开正文，检查图片和附件；再打开评论记录，确认作者、时间和评论位置没有丢。两项都通过，才算正文和协作过程都归档完成。
一套省事的处理顺序
- 先冻结一个明确的文档版本。
- 导出干净正文，命名为最终版或归档版。
- 单独整理需要保留的评论和未决事项。
- 记录版本差异、审批结论和负责人。
- 检查最终版是否混入内部信息，再移动目录做离线验证。
评论和修订不需要全部保存，但影响决策、责任和后续执行的内容不能丢。归档的目标不是复制整个评论区，而是让后来的人能看懂正文为什么是现在这样。