先确定 Markdown 的用途
仓库 README 需要一条通向成功的简明路径；档案迁移可能优先考虑完整性；供 LLM 工作流使用的笔记可能更看重标题和易读的表格，而不是发布的精修。在转换之前确定目标，这样清理就有了清晰的终点。
- 确定目标读者和发布系统。
- 决定原件还是 Markdown 继续作为事实来源。
- 决定一个大文件是否应拆分为多个聚焦的文档。
- 记录目标环境接受的平台专属语法。
准备源文档
在上传前修正明显的结构问题，比事后推断更快。在 Word 中使用标题和列表样式；在电子表格中，每个工作表只保留一个矩形表格；在演示文稿中，为幻灯片添加有意义的标题，并把关键结论放在可编辑的文本中。
对于 PDF，请确认文本是可选择的。对于 CSV、JSON 和 XML，请校验语法和编码。对于 HTML，请上传已保存的以内容为主的文档，而不是期望服务去抓取或执行远程网页。
在上传前精简敏感输入
临时处理可以降低留存风险，但数据最小化仍然是最好的默认做法。只要结果不需要，就移除凭据、个人信息、私人评论、隐藏工作表、修订痕迹和无关附录。
公共端点只接受上传的文件。它不会抓取用户提供的 URL、启用第三方插件，也不会故意把文件名或内容写入日志和公共缓存。
从结构到细节进行评审
先从文档大纲开始。如果阅读顺序或标题层级有误，打磨个别标点就是白费力气。然后评审列表和表格，接着是链接、图片、代码块和普通空白。
- 大纲：一个 H1、合理的标题递进、无重复的页面装饰。
- 顺序：段落和幻灯片按预期的阅读顺序出现。
- 结构：列表连续，表格列数一致。
- 引用：链接在目标环境中可解析，图片有有用的替代文本。
- 准确性：名称、数字、公式和代码与权威源一致。
了解各格式特有的失败模式
PDF 可能混排分栏或重复页眉；Word 文档可能把含义藏在文本框里；幻灯片高度依赖空间关系；工作簿包含 Markdown 无法重现的计算和交互视图；EPUB 可能使用包内相对链接和尾注结构。
不要把每个源对象都强行塞进 Markdown。复杂的电子表格更适合作为源数据链接出去，配上一张小型的说明表格；架构图可能需要一张持续维护的图片外加文字描述。
在最终渲染器中验证
编辑器预览对清理很有用，但 GitHub、文档框架和知识库可能支持不同的扩展。请在目标环境中预览或构建文档、运行链接和风格检查，并在删除原件之前请领域评审者确认含义。
一份轻量级的交接清单Markdown
- [ ] Heading outline reviewed - [ ] Tables and lists render correctly - [ ] Links and image paths resolve - [ ] Sensitive data removed - [ ] Technical facts verified - [ ] Final renderer checked