发布说明审核与网站、Slack、PDF 多渠道交付

先确定一个可追溯的发布范围

这个工作流面向需要把单次软件发布交给文档审核人和公告负责人的维护者。输入应是权威变更记录与明确的版本号，而不是未经筛选的提交消息。提取版本章节后，核对日期、分类及已批准变更证据。提取结果为空可能是输入格式未被识别，不能据此认定本次没有变更。尤其不要把“尚未发布”章节里的全部内容顺手放进正式公告。

用同一份 Markdown 主稿控制内容

主稿应说明改了什么、谁需要采取行动，以及已经批准的迁移或回退指引。版本号语法合法并不能证明本次应该升级次版本，兼容性判断应在发布前完成。格式检查用于定位可操作的问题，安全自动修正并不能代替对标题层级、代码示例及遗漏解释的人工审核。确定源稿修订号后再制作副本，避免网站、聊天公告与 PDF 在并行编辑中逐渐分叉。

按阅读场景处理导航与渠道差异

简短发布说明通常不需要目录。长文先定稿标题，再生成目录，随后检查引用。工具生成的锚点遵循 GitHub 风格，仍需在实际网站渲染器中确认能否跳转。链接检查属于静态检查，不能证明软件下载地址可达；必要的外部页面应单独打开验证，包括需要登录的链接。

只生成实际需要的 HTML 和 Slack 版本。宽表格更适合留在完整说明中，聊天公告可以改为短列表，但不能省略迁移提醒和正式发布说明链接。对于不支持的表格、任务列表或依赖图片才能理解的说明，要人工改写并复核，而不是忽略转换警告。格式转换不等于部署网站，也不等于已经发送消息。

验收的是同一次发布，而不只是几个文件

需要审核或存档时再导出 PDF，查看真实页面是否存在表格裁切、代码溢出、分页后上下文丢失。逐份比对版本号、日期、关键操作和链接。如果某个渠道仍是旧草稿，应从主稿重新生成，不要只修改那个输出文件。把批准修订号与产物名称一起留档。更大范围的手册整理使用文档编写工作流，零散格式处理使用 Markdown 工具专题；接口兼容性尚未定论时，先完成 API 版本审查再签署发布说明。