发布篇： 最后一公里 发布是文档生命周期里最怕"差不多"的环节——差一点，就差很多 发布就是点一下按钮？ 如果你以为"发布"就是点一下按钮，后台状态从"草稿"变成"已发布"——大概率会撞上三种现实：产品还没上线文档就出去了、插件说发了但商城里找不到、版本号写错了用户升级后一脸懵。
发布之所以是"最后一公里"，不是因为距离短，而是因为这段路上牵涉的依赖最多、协调方最多、出错后修复成本最高。产品团队、测试团队、市场团队、技术支持——每一个环节的信息差，都会在你的文档里变成用户可见的错误。
任何一个环节"差不多"，到用户那里就变成了"差很多"。发布不是终点，是信息从内部走向外部的最后一道闸门——闸门松了，前面的努力全部打折。 六步走，一步都不能省 版本发布时间确认后，确保每个模块负责人建立了迭代任务计划。用 KMS 记录所有迭代任务，@对应模块负责人，确保每个人明确自己的文档交付范围和时间节点。如果某个模块没建任务，不要替他建——替建意味着你替他承担了责任，后续跟进时找不到真正的责任人。
每周跟催，核心看两个维度：进度维度——定期查看任务看板，发现有没有人没走文档流程就直接结束了任务；风险维度——任务扎堆时及时协调资源援助。两个红线： 绝不提前发布 （文档先于产品上线会引发投诉暴增）， 绝不生成历史版本 （下载 HTML 给测试审核，发布时从草稿箱确认）。
发布前一个工作日准备好更新日志草稿。每个官方功能性插件的负责人要自己负责更新内容，你需要时间收集、整合、审校。更新日志草稿至少确认：每个任务的发布版本号、发布日期、APP版本、H5版本。同时确认有没有推迟发布的文档——推迟的功能如果更新日志里已经写了，用户会期待一个不存在的功能。
顺序很关键：先确认官网产品下载页上架了最新版本→提醒各模块发布文档→发布更新日志→最后更新日志索引。为什么要等官网先上架？用户如果从更新日志进入文档，发现下载页还是旧版本，信息是新的、产品是旧的，信任就没了。
更新日志在你自己的平台发布后，还需要提任务给市场组更新官网的更新日志页面。很多团队在这一步就断了——觉得"内部已经发了就行了"，但官网才是用户的第一触点。内部更新日志和官网更新日志不一致，是另一种"差不多"。
最容易被遗忘的一步。文档发布后通知技术支持团队，让他们知道新版本有哪些变化、文档更新了什么。技术支持是用户问题的第一接收人，如果他们不知道最新文档的内容，就无法引导用户去正确的地方找答案——用户的问题还是会回到你这里。
统计→跟进→准备→执行→同步→闭环。不是"写了就发"，而是从信息收集到信息触达用户的完整通路。每一步的顺序都有因果：Step 4 等官网先上架，是因为信息一致性；Step 6 通知技术支持，是因为问题闭环。 三个"绝对不能" 文档先于产品上线，用户看到了新功能说明却找不到这个功能。他的第一反应不是"文档写早了"，而是"产品出bug了"。然后打电话给技术支持，技术支持不知道文档已发，三方信息不一致，投诉升级。 文档发布时机必须在产品之后，一秒都不能早。 产品同事说"插件发布了"，你的第一反应应该是不信。曾经有版本发布日，两个插件实际并未上架——打包失败了，但失败信息没同步到文档团队。 去插件商城亲眼确认上架，亲眼看到才是真的发布。 迭代文档需要先审核后发布，但审核时直接发布会生成历史版本。一旦生成了历史版本，后续修改需要从历史版本里改，而很多作者会忘记——最后发布的内容不是最新版，而是审核时生成的中间版本。 正确做法是下载 HTML 给测试审核，发布时从草稿箱确认。 迭代负责人的统筹清单 这个版本是否上官网？不上官网 = 仅对内发布，文档不需要对外。这一步决定了后续所有动作的辐射范围。 看迭代任务看板，用 KMS 记录所有迭代任务，@对应模块负责人。确保每个任务都有明确的文档交付责任人。 冒烟测试开始时通知组员开始写迭代文档——此时功能已基本可用，文档作者可以实际操作来写。定期查看有没有任务没走文档流程就直接结束的。 确认每个任务的发布版本、日期、APP版本、H5版本。确认有没有推迟发布的文档——推迟的不能写进更新日志。 更新版本适配信息，确认官网安装包下载链接是否最新。一个过期的下载链接，比一篇过期的文档更致命。 与测试沟通，若测试已上传至官网和 CRM 即可通知发布。同时安排升级指南任务——重大版本必须配升级指南。 文档发布后第一时间通知技术支持，让他们知道哪些功能变了、文档更新了什么内容。 迭代负责人的核心价值不是写文档，而是 确保信息不断裂 。从发布类型到技术支持通知，每一步都是在消除信息差。 文档提交：你写的不重要，别人能看懂才重要 文档写完了，提交给审核人时你写了什么备注？这个备注不是给自己看的，是给审核人、给写更新日志的人、给三个月后翻看历史的你看的。提交规范的核心原则： 信息可追溯、状态可追踪、风险可预判 。
文档链接 ：必须有标题+链接，不能只丢一个裸链接。裸链接的问题是——三个月后链接失效了，你连这篇文档叫什么都不知道。 · 关键信息变更（功能参数、接口地址、配置项） · 发现的问题/bug 及处理方式 · 模板/附件/Demo/内置 exe 的更新 · 架构调整、配图更新、措辞调整 · 重命名、标签、分类、相似问法的调整 不要觉得"改动很小不用写"。一个参数名从 pageSize 改成 limit ，看起来很小，但对依赖这个参数的开发者来说是断裂性变更。写了备注，审核人才能判断影响范围。 迭代文档和普通文档的最大区别： 写好了但不能立即发布 。产品还没上线，文档不能先出去。
备注格式 ： "文档暂未发布，待 XX 版本发布后更新。审核时请预览 HTML 文件" 审核方式 ：下载 HTML 文件提交给测试审核，不要直接发布生成历史版本。审核通过后，文档保留在草稿状态，待版本发布时再正式上线。 · 重命名/标签是否需要确认 · 相似问法是否需要补充 · 是否属于重大版本需要推送至用户端 关键动作 ：所有待发布文档统一记录到 发布计划表 。没有这张表，迭代负责人就无法追踪哪些文档在排队等发布、哪些可能被遗忘。发布计划表是迭代的"候机厅"——每个待发布文档都在这里等航班，航班到了一起起飞。 后面每个需要了解这篇文档的人，都要重新沟通确认一遍 文档标题+链接 修改内容分维度罗列 迭代备注含版本信息 待处理事项逐条注明 从"功能清单"到"用户价值" 大多数团队的更新日志，写成了内部工作汇报——列一堆功能名，用户看完不知道对自己有什么用。你在说"我们做了什么"，但用户想知道的是"我能做什么了"。这两者之间差的就是 用户价值翻译 。
1. 新增堆积图 2. 优化通讯录 3. 支持附件上传 4. 新增4款插件 堆积图重磅来袭！ 数据对比一目了然 1. 通讯录升级：支持导出成员列表 2. 仪表盘新增堆积图 3. 审批意见支持上传附件 4. 开放平台新增4款插件 标题控制在8-12字以内，太长目录放不下。吸引力靠动词和场景词，不靠堆砌。"堆积图重磅来袭"比"新增堆积图组件类型"有力得多。 不要主要讲"怎么操作"，主要讲"能用在什么场景"或"用完的效果是什么"。用户不需要在更新日志里学操作步骤——那是文档的职责。更新日志的职责是让他产生"我要试试"的冲动。 每个功能背后都有一个用户问题。堆积图背后是"多组数据对比不方便"；通讯录导出背后是"每次手动复制太低效"。先说问题，再说解决方案，用户才有代入感。 更新日志不是写给老板的周报，是写给用户的邀请函。每一行都在回答一个问题：" 这次更新，对你有什么用？ " 那些"没人提醒你就会忘"的细节 这些细节的共同特点： 没人提醒你就会忘，忘了之后不好修 。
版本推迟发布是常有的事。如果你不知道推迟了，更新日志已经发出，就会出现"日志说有新功能但产品没更新"的尴尬。 产品内嵌的文档链接需要加参数（如版本号、语言、平台标识），确保用户看到的是和自己当前版本匹配的文档。不加参数，用户可能看到旧版文档。 安卓和 iOS 的审核节奏不同，安卓通常在设计器发布第二天可用，iOS 可能需要更长时间。更新日志和文档里需要注明各平台的可用时间差异。 这些细节不是流程里的"加分项"，而是发布质量的"保底项"。流程走完了但细节没确认，等于流程只走了一半。 最容易被忽略的版本适配 如果你的产品有多个产品线、多个版本号同时运行，文档发布时还有一件必须做的事： 确认版本适配信息 。版本适配不是"顺便看看"，而是用户升级决策的直接依据。某次版本发布，版本适配表里漏了一个插件版本号，用户升级后发现插件不兼容，整个工作流中断。升级踩坑的用户比新用户更愤怒——因为他们是从一个可用状态掉进不可用状态的。
立刻可以做的事 ☐ 下次发布前，按六步流程逐项核对，不要跳步 ☐ 确认发布类型：上官网还是仅对内？这决定后续所有动作 ☐ 文档发布时机必须在产品发布之后，一秒都不能早 ☐ 插件发布后，去插件商城亲眼确认上架 ☐ 迭代文档提交时，写清楚修改内容和待处理事项 ☐ 所有待发布文档统一记录到发布计划表 ☐ 更新日志从用户价值出发，轻操作重场景 ☐ 检查版本适配信息，确认移动端各平台可用时间 #文档不头疼 #Carly聊技术写作 #技术传播 #发布流程 #版本管理 #更新日志
夜雨聆风
