功能在我们写出来、并在产品里发布之前，并不存在

行业公开调研与访谈里，有一句口径很硬：功能在我们写到、并随产品发布之前，并不存在。

工程师眼里，合并进主干就存在。产品经理眼里，灰度开关打开就存在。演示现场里，口述能走通就存在。用户眼里却不是这样：找不到稳定说明、不知道怎么打开、不知道边界在哪、客服也说「好像上周上了但帮助中心还没有」——那就等于还没交给他们。代码在、对外说明不在，是半发布；半发布会制造演示惊喜，也制造上线惊吓——演示按口述走通，客户回去按帮助中心搜不到，或搜到旧路径，锅很少记在「文档排期」上，多数会记在「产品不好用」上。

这句话不是否定研发交付，而是换尺子：交付是否完成，要看对外世界能不能核对。没有可核对的页，功能只活在研发群欢呼、演示 PPT 和「你们内部人都知道」里。对外部用户、伙伴实施、客服排班来说，它还不存在。存在，不是「我们内部知道有」，而是「对方能打开一页现行说明，按步骤做完，且失败时知道该查哪条边界」。

换一把尺子之后，争论会少很多。团队不必再吵「文档算不算研发工作量」，而要验收「用户今天能不能打开现行说明」。能打开，功能才算交给了外部世界；打不开，再漂亮的发布会也只是内部庆祝。

前一篇把文档说成与用户之间的承诺；本篇把承诺钉进发布窗口——写出来，还要随产品一起出门。只写在飞书草稿、企微「稍后整理」、个人网盘里的「说明_待发」，同样不算存在：用户打不开、助手采不到、截图转发也没有稳定地址。地址不稳定，就等于没有契约落点；没有落点，下次发版群一刷，上周的口述又会变成「以谁为准」的半小时对齐会。

若完成定义只写「测试通过、可灰度、监控无红」，文档缺席，功能会以半发布状态出门：销售可以讲，实施靠口述，客户搜帮助中心得到 404 或旧路径。行业公开观察里，与产品同步仍是许多人的头号工作流痛点之一；缺的不是再强调「要重视文档」，是把「对外说明与发版说明」写进这次发版的完成线。

不把「写入每个产品团队完成定义」伪装成 Baklib 功能——那是你们的协作约定；工具只负责让约定更容易落地。约定可以很短，短到一张清单：这次发版至少有一条操作日志说清「现在有了什么」——也就是把关键变更记成可回看的记录，而不是只活在群消息里；以及一篇帮助或手册步骤写清「怎么打开、边界在哪」。有人认领、有发布动作、有可分享链接，才算过线。没有链接，只有「群里说过了」，对用户仍是半发布。

半发布还有一种更隐蔽的形态：功能在产品里开了，文档写的是意向版或上周评审稿。用户按文档操作，踩到「界面已改、参数默认值已换」的坑。表面上有文档，实际上违约。所以「写出来」不够，还要与现行行为对齐——这就是可追溯性在发版现场的用法：从变更到对外页，能对上同一窗口；出事时能说清「这一步对应哪次发版」，而不是翻三天企微聊天记录猜。

对靠内容推动试用与自助的团队来说，半发布也伤产品驱动增长：人愿意自己动手开通、自己摸功能，却找不到现行步骤，增长漏斗在「开通之后」先漏一截。你以为在省文档人力，其实在用支持成本和续约摩擦还债。半发布制造的「演示惊喜」，最后几乎都会变成进线量、实施加班和「你们文档太乱」的客户原话。

完成线要钉的，不是「文档团队忙不忙」，而是三个可验收状态：发版说明能打开；关键路径步骤能打开；群通知带的是现行页链接，而不是「详见内部群」。兼职也可以过线，前提是认这份活，而不是默认「文档以后再说」。

常见排期：周二灰度或全量，周五「有空再改帮助」。中间三天，客服按企微群消息答，用户按旧教程点，伙伴按过期错误码联调。下周补上的那页，救不回这三天里散掉的信任——客户已经学会「以群里最新口述为准」，正式站再次变成装饰。装饰站比没有站更糟：它看起来像正式通道，读到的却对不上现网。

发版通知可以快；正式页必须同窗口可点。否则「新功能」只存在于演示稿和研发群。更糟的是：市场先发公众号「重磅上线」，帮助中心入口仍是旧导航，站内搜索先冒出两年前的活动说明。用户以为走进了正式通道，读到的却是过期事实——过期入口比没有入口更伤。销售方案书里已经写了新能力，客户自己点帮助中心却找不到对应步骤，谈判桌上攒下的信任，会在浏览器地址栏里丢掉。

国内现场还有一层更土的摩擦：变更发生在研发企微群，说明写在飞书个人空间，对外 PDF 还躺在项目网盘的「最终版」文件夹。三处各改各的，没有人故意搞砸，只是「改一处就够」被默认成了组织习惯。结果是：产品已上线，帮助中心下周再说；下周再说的时候，又有一轮新变更插进来——永远在追，永远追不上「今天现网」。

可执行的最小闭环不必等大编制：发版说明有固定入口；关键路径有人改步骤；改完发布；群通知带现行页链接。兼职也可以，前提是完成线认这份活。一个人认领两条关键路径，也比十个人都「有空再说」强。问问题的方式也要换：从「这页写完了吗」，问到「用户今天能不能打开现行说明」——后者才是半发布与完整发布的分界。

若你们已经习惯「功能先上、文档后补」，不妨把后补代价写进复盘：那三天进线量、实施加班、客户原话里有多少句「帮助中心找不到」。看见代价，完成线才更容易站住；看不见代价，下周仍会「有空再说」。

Baklib 不把这件事包装成「再催一波文档」。我们更常说：让这次发版该亮的说明，能跟产品同一窗口出门。

产品日志 接住「现在有了什么」；同一发布面也可承载产品反馈入口，把「上线了什么」和「哪里不对」放进同一信息流，减少「反馈去了 A 群、说明还在 B 盘」的分叉。产品操作手册 与 帮助中心 同源改步骤、再发布——手册偏规格与边界，帮助偏此刻怎么做完，门牌可以不同，事实源应一。建设侧可按场景点亮 Feedback、Docs、Help 一类叶子：先让骨干入口有门、找得到，再谈更漂亮的运营页。

不吹自动从代码变更开文档单，也不把组织习惯写成平台开关。能交付的是：真源可协作、版本可对齐、发布可同窗口亮相。草稿老实待在草稿里，别混进对外库；未审核的「差不多对」进了公网，下一周就会变成客服口述与正式站打架的种子。先让用户能打开现行说明，半发布制造的惊喜，才不会默认变成支持成本。

落地顺序通常很克制。先定完成线：这次发版至少有一条现行发版说明、一条关键路径步骤、一条可分享链接。再选住所：日志、手册、帮助中心同源改，而不是各开一套站点各养一份拷贝。最后才谈到达：群通知、站内搜索、助手问答，都应指向已发布页，而不是再养一份「只给机器人看的说明书」。模型会组词，组织仍要定口径——没有同窗口发布，智能只会更快传播半发布。

没写出来、没随产品发布，对用户就不算存在。存在，从可核对的那一页开始；那一页，最好跟这次发版一起亮相。