企业发布说明：一个账户到底会变成什么样子
阅读约 1 分钟
一款公开的 SaaS 产品会把同样的发布说明发给所有人，因为所有人都在同一个版本上。而一个固定在 某个版本上、拥有专属实例、或者只使用了产品里带功能开关子集的企业客户，会打破这个假设：描述 她那边发生了什么变化的发布说明，跟你公开博客上的那份并不一样，可即便如此还是把公开版发给她， 要么会用她还没有的变化把她弄糊涂，要么更糟糕的是，会告诉她一个另一位企业客户的客户经理明确 要求你替他们那边再暂缓一个月的功能。发布说明最佳实践 讲的是通用的写作技艺；这篇文章讲的是怎样为那个只有当你的客户不再全都用着同一个构建版本时， 才会浮现出来的校准问题，写出真正合格的企业发布说明。
为什么企业客户不能干脆去读公开的体验日志
因为它描述的是一个她可能还没有运行的版本，一些她可能还没有权限使用的功能，以及一份跟她自 己的节奏对不上的时间表。一个固定在季度发布周期上的客户，读到一个上周才发布到公开层级的功 能，光凭公开的体验日志根本没办法知道，这个功能会在下周还是下个季度才到她手上。公开体验日 志回答的是”产品里发生了什么变化”；企业客户真正想问的是”我正在运行的这个版本里发生了什么变 化，我什么时候能拿到剩下的部分”，而这个问题，公开体验日志从来就不是为了回答它而写的。
一份私有发布说明需要什么，是公开版本不需要的
一个客户能真正拿来核对的版本或环境标识符，以及一份关于哪些内容还没到达她那里的明确声明。 “这个版本包含了我们公开 4.3 版本里的批量导出改进，但不包含将在你下一次计划中的更新里到达 的新权限模型”，这句话能准确告诉一位企业管理员，她的实例相对于整个产品到底处在什么位置。公 开发布说明永远不需要这种框架，因为可以拿来做相对比较的实例只有一个；而私有版本没有它就毫 无意义。
| 公开发布说明 | 私有（企业）发布说明 |
|---|---|
| 一个版本，一个受众 | 多个版本，被细分的受众 |
| 假设读者拥有每一个被描述的功能 | 必须声明读者拥有和不拥有什么 |
| 跟公开发布同步 | 跟客户自己的更新窗口同步 |
| 可以立即完全公开 | 可能需要保留其他客户还没有的项目 |
干脆推迟把公开发布说明发给企业客户，而不是另外单独写一份，这样做有时候可以接受吗
只有在她那时候的版本真的跟公开版本一致的情况下才可以，而一旦你有超过几个节奏不一致的企业 账户，这种情况其实比听起来要罕见得多。推迟发送公开说明，对一个落后一个版本、马上就要跟上 来的客户来说，可以当作一种权宜之计；但一旦两个企业客户各自处在不同的版本上，这套做法就会 崩溃，因为这时候已经不存在一份可以推迟的”说明”了，只剩下一张记录每个人拥有什么的矩阵。到 了这个地步，按账户校准说明，哪怕只是对同一批底层条目做过滤后的视图，也就不再是可选项了。
发给一个还没有这个功能的企业账户的
公开说明：
"New: Bulk export now supports custom column ordering."
（令人困惑：管理员去试了，发现根本没有。）
为同一个账户校准过的企业说明：
"Available in your next update (scheduled for 2026-10-15):
bulk export with custom column ordering. Not yet available
on your current version (3.8)."客户组织内部真正读这份说明的是谁，这会改变写法吗
通常是一位 IT 管理员或者客户成功联系人，而不是终端用户，而这会改变什么才算有用。终端用户 想知道自己屏幕上有什么看起来不一样了；企业管理员想知道权限、数据处理、SSO 配置，或者任何 会影响她如何为自己的用户管理部署的东西发生了什么变化，因为要回答内部问题的人正是她。一份 读起来像消费者体验日志的私有发布说明，满是崭新闪亮的按钮，却完全没有运营层面的细节，只会 逼着管理员自己去挖掘她真正需要的信息。
这跟一份已经列出同一个功能的公开路线图或公开体验日志之间是怎样相互作用的
要小心处理，因为一个同时读两者的客户会注意到任何不一致。如果你的公开体验日志已经宣布了一 个某个特定企业账户还没有的功能，她的私有发布说明就必须承认这个差距，而不是假装那条公开条 目根本不存在；一个看过公开公告、又收到一份对此只字不提的私有说明的管理员，要么会以为你把 她忘了，要么会以为出了什么故障。公开路线图讲的是如何让一份路线 图对已发布内容与计划中内容保持诚实；这份诚实在发布说明里的企业版本，就是直接说清楚公开的 内容和属于她的内容之间的差距。
只有一两个企业客户的小公司，需要这么多结构吗
不需要完全细分的系统，但那份核心纪律，清楚说明客户处在哪个版本、她拥有什么、不拥有什么， 在任何规模下都很重要，只要你哪怕有一个客户不在你最新的构建版本上。这能防止的那种失败模 式，一个搞不清楚某条公开公告是否适用于自己的管理员，无论你有两个企业账户还是两百个，都会 让你付出一张支持工单和一次信任受损的代价。
FAQ
私有发布说明是否应该提及别的客户已经拥有、但这个客户还没有的功能? 只有在跟她自己的时间表相关的时候才可以，而且要表述成”将在你下一次更新中到达”，而不是跟其 他客户做比较。点名说出某个特定的其他客户拥有什么，越过了一条不该由你来公开的界线；而点名 说出什么将专门为这个客户到来，正是她需要的信息。
同一批底层体验日志条目，能不能同时支撑公开和私有两种发布说明? 可以，而且这通常是更容易维护的做法：给条目打上标签，标明它们适用于哪些版本或哪些层级，然 后在发布时按受众过滤，而不是去写两份完全独立、注定会渐渐脱节的文档。
如果一个企业客户明确要求出现在公开发布说明上，而不是走私有信息流，该怎么办? 尊重这个要求，但要确认她明白公开说明是以公开版本为前提的，而且如果她的版本跟描述有出入， 就自己用书面形式标注出这个差距。这份书面确认，正是日后万一她根据一份实际上并不适用于她那 个构建版本的公开说明采取了行动时，能保护你的东西。
企业客户应该提前多久被告知，她将在下一次发布中获得访问权限的功能? 一旦日期确定下来就应该立刻通知，而不是等到发布的那一刻，因为企业管理员往往需要围绕即将到 来的功能，规划她自己内部的沟通或培训，而当天才发出的通知不会给她留下任何这样做的余地。
本文的技术内容未经独立审核。如有错误，请告诉我们，我们会更正。