你来找的是一份 发布计划模板（release plan template）——那些小节、那些标题,一份能在下次上线前粘进文档的东西。它就在下面,尽管拿走。但你得清楚拿到的是什么:一份软件发布计划本质是一张快照,它所依据的 scope 一动,它就和现实脱节。砍掉一个功能、某个依赖延期、换了个负责人——表格里没有任何东西把这份计划连回它所假设的那些决策和 spec,于是计划悄悄变成一篇没人再信的虚构文。Draftlize 给你同样的八个小节——但把每一节都变成连着依赖的卡片,只要上游某个决策一动,整份计划就会自己标成 stale。
这就是完整的发布规划模板。文档、wiki、表格里都能用——它是每个上线团队最后都会收敛到的那个形状。原样拿去用。下一节讲的是:当每一节不再是一格静态单元格、而变成一张知道自己依赖什么的卡片时,会发生什么变化。
所有人都拿来引用的那个标签和版本号。「v2.3 —— 计费改版」。一个名字,让 spec、讨论串、站会都指向同一个发布,而不是对它的三种含糊描述。
这次发布要做什么——以及同样关键的、明确不做什么。「不做」清单是最能避免争吵的一栏。范围里的每一项都该能追溯回那个把它放进来的决策。
代码冻结、RC、预发、正式发布。卡住这次发布的那些日期,以及从现在到上线之间的检查点。最先出错的就是这部分——某个里程碑一延,计划其余地方还停在旧日期上。
这次发布所假设已经就绪的上游 spec、决策、服务和团队。在表格里,这是一份你会忘记回头看的清单。它是决定这份计划一周后还成不成立的那一节。
发布如何触达用户——feature flag、金丝雀、按比例放量、一个区域一个区域来。谁先拿到、你盯哪些指标、以及下一步打开前必须先变绿的那道闸。
出事了怎么撤回来。决定「回滚」的触发条件、确切步骤、以及要花多久。这一节没人会去看,直到凌晨两点——而这恰恰就是它必须在那之前先写好的原因。
发布负责人,外加每个面的直接负责人(DRI)。不是为了追责——而是当某个里程碑延期、或回滚触发时,有一个名字可以问,而不是对着一个频道喊。
你凭什么判断这次发布成了:指标、阈值、以及你担心的那些回归没有出现。在上线前就把这条定下来,否则「成功」就会变成「碰巧发生了什么就算什么」。
模板就是这些。下面讲:为什么 scope 一动,计划就和现实脱节——以及我们怎么解决。
你按今天的 scope 和 spec 把计划搭出来。然后一个决策砍掉一个功能、一份 spec 改了样子、一个依赖延了一周。那份把这一切都记下来的文档毫无察觉——表格看不见它上游的决策在移动,于是计划继续描述一个已经不存在的发布。
你列出了这次发布建立在什么之上——上游那份 spec、必须先上的那个服务、你在等的那个团队。然后其中之一一动,对齐这份计划就成了手工考古:凭记忆把每个依赖重新核一遍。没人会做。本该让计划保持诚实的那一节,反而第一个开始撒谎。
计划在签字通过的那一刻最准,之后再也没那么准过。到上线那天,它有相当一部分已经是错的——一个过时的日期、一个被砍掉的范围项、一段为早已被替换的服务写的回滚步骤——而你说不清错的是哪一部分,于是团队悄悄不再信这份计划,改成凭记忆把发布跑完。
在 Draftlize 里,这份模板不是一张空表格——而是带着那几节的结构化卡片:发布与版本、范围、时间线、依赖、灰度、回滚、负责人、成功标准。结构化、可按 ID 寻址、能从一份 spec 或一条讨论串里引用,而不是埋在一个没人打开的标签页里。
因为「范围」和「依赖」是真的链接、不是一串名词,所以一旦某个范围项所依据的决策、或某个里程碑所假设的 spec 发生变化,计划里受影响的部分就会自动标成 stale——就像构建系统会让一个被改动文件下游的一切全部失效一样。模板许下的承诺,由底座来兑现。
Claude Code 或 Cursor 通过 MCP,在起草或更新发布计划之前,会把每一份相关的决策和 spec 都读一遍,再把改动按同样的形状写回去。计划不再是一份批准一次就被遗忘的文档,而成了每一轮都会被读取、并被拿去和现实对账的上下文。
发布计划告诉你打算发什么,却没法告诉你:它所依据的那份 scope,什么时候在它脚下悄悄变了。八个小节照旧保留,让底座替你保持它们最新。
发布计划说明你打算在某个 release 里发什么、什么时候发——版本、scope、时间线、依赖、上线与回滚步骤、负责人，以及怎么算成功。它把一个目标日期变成整个团队可以照着做的一组协同承诺。
路线图是战略视角——按季度看的主题和结果。发布计划是战术视角——下一个 release 具体发什么、怎么发。路线图说你要去哪，发布计划说接下来什么离开工厂，带日期、依赖和一条回滚路径。
上面这八个小节：版本、scope、时间线、依赖、上线、回滚、负责人、成功标准。最常被漏掉的是依赖（什么必须先成立）和回滚（怎么撤回）——而这恰恰是发布出岔子时你最需要的部分。
发布计划在批准那一刻最准，此后一路漂移。Draftlize 把每一节做成连着它所依赖决策和 spec 的卡片，于是某个里程碑假设的 scope 一变，计划里受影响的部分就自己标成 stale——而不是团队悄悄弃用它、凭记忆发版。
把上面这份模板拿去用,或者新建一个项目,让 agent 从你现有的决策和 spec 里把计划搭出来——然后在发布推进的过程中,替你把每一节、以及它所依赖的一切,持续保持最新。
注册送 $5,免费开始