你来找的是一份产品发布清单 —— 分几个阶段、有哪些项,发布前能直接贴进文档的那种。它就在下面,拿走用。但你得清楚拿到的是什么:清单本质是一排勾选框,而勾选框只能记下某件事曾经为真。只要上游某个决策一动 —— 改了价、重切了 spec、GTM 往后挪了一周 —— 依赖它的那几项其实已经错了,可它们还是绿的,因为 Notion 表格或 Google Doc 里没有任何东西把「定价已定」连到「定价页已上线」。Draftlize 给你同一份清单 —— 但让每一项都成为一张连着依赖的卡片,上游一变,相关项就自己标记 stale。
这就是完整的发布计划清单 —— 发布前、发布当天、发布后。放进文档、wiki 或项目看板都能用,照抄即可。下一节讲的是:当每一项不再是勾选框、而成为一张知道自己依赖什么的卡片时,会发生什么变化。
要做的范围已锁定并写下来。下面每一项都默认这版 spec —— 这恰恰是为什么事后重切 spec 会悄悄让半张清单失效。
对结果负责的人已就「做什么、不做什么」达成一致。不是 Slack 上点个赞,而是一条事后能指回来的、被记录下来的决策。
套餐、价格、组合都已敲定。这是整页最上游的决策:定价页、计费、付费墙文案、GTM 叙事,全挂在它身上。
结账全链路跑通,付费墙按你定的套餐拦截,测试里真有一张卡被扣款。它在定价的下游 —— 所以定价一动,它立刻 stale。
定位、发布文案、各渠道(官网、邮件、社交、若有媒体)都已起草并排期。这一切都默认价格和功能集不变。
关键路径已在接近生产的数据上测过,回归清楚,已知问题清单诚实写明哪些是带病上线。
能告诉你这次发布成没成的那些事件,在发布前就已上报并验证,而不是事后补 —— 没埋的点,事后量不出来。
一套测过的撤销部署的办法,加一行写清楚由谁、在什么条件下叫停。最容易省掉的一项,也是凌晨两点最贵的缺口。
按计划的方式上生产 —— 灰度开关、逐步放量,或一次性切换 —— 并确认上线的这个版本,就是你签过字的那个。
上线后立刻在真实生产上跑一遍关键路径:注册、付费、做核心动作。这五分钟专抓那些只在生产里才暴露的配置错误。
翻官网、发邮件、发帖 —— 按计划的顺序,且只在冒烟测试变绿之后。把一个坏版本宣布出去,是唯一收不回来的失误。
头几个小时盯着报错、延迟、注册和支付。有人明确在值守、在看盘,而不是默认一切都绿。
拿你埋好的指标来对这次发布 —— 激活、转化,以及那个你说过「就看它定成败」的指标。和 PRD 当初的预测对一对。
把第一波用户反应、工单、困惑收拢到一个地方,让它能变成决策,而不是消散在 Slack 里。
清单漏了什么、什么悄悄失效却没人发现、下次发布前该改什么。这一项让下一次发布更省力。
把学到的东西变成更新后的决策和 spec —— 让下一次发布从当下的真相起步,而不是从一份停在发布当天的文档起步。
这就是清单。下面讲:勾上一项的那一刻,正是它开始骗你的时候 —— 以及我们拿它怎么办。
勾上「定价已定」,在你勾的那一刻为真,之后再没被复查过。Notion 或 Google Doc 里的清单只把某个状态记录一次;它根本不知道所记的事什么时候不再成立 —— 一排勾选框看不见发布的其余部分在变。
你在发布前三天改了价。这下定价页、计费接通、付费墙文案、GTM 叙事全错了 —— 可它们每一项还是绿的,因为没有任何东西把「定价已定」连到它下游的那四项。本该护住发布的清单,反倒成了藏住故障的那层皮。
一份全勾满的发布清单看着像万事俱备,这恰恰是它危险的地方:你分不清哪些绿项在勾上之后悄悄失效了。整张清单读起来都「完成」,而其中真有一部分是假的 —— 而你会在发布当天、而不是之前,才知道是哪一部分。
在 Draftlize 里,发布清单不是一排勾 —— 每一项都是一张有类型的卡片:它代表的那条决策或 spec、谁负责、处于什么状态、依赖什么。结构化、有 ID 可寻址,能从 PRD 或某个 thread 里直接引用,而不是埋在文档里。
因为每一项的依赖是真实的连线、而非心照不宣,改价会让所有压在旧价上的卡片 —— 定价页、计费、付费墙、GTM —— 自动变 stale,就像构建系统让一个改动文件的下游全部失效。手动靠不住的那片绿,交给底座替你守住诚实。
Claude Code 或 Cursor 通过 MCP,在起草发布文案或 release notes 之前,先读完每一条相关决策和 spec,再把状态写回同一批卡片。清单不再是某人忘记更新的文档,而成为 agent 每一轮都重新读一遍的上下文。
清单能告诉你发布前要做哪些事,却没法告诉你:你已经勾上的某一项,什么时候不再为真。三个阶段照留,让底座替你守住诚实。
产品发布清单，是发布前、发布中、发布后必须成立的所有事项的清单——横跨产品、市场、销售、支持、法务——好让你在 deadline 压力下不漏掉任何关键项。它把混乱的发布周，变成一组有主、可核实的事项。
三个阶段。发布前：最终 QA、文档、定价与计费、市场素材、支持赋能、法务签字。发布中：部署、公告、监控。发布后：收集反馈、盯指标、快速修。每一项都要有主和明确的完成标准，否则它只是一个没人真核过的勾。
发布前（把准备就绪、把一切对齐）、发布中（上线、公告、盯着）、发布后（度量、学习、迭代）。多数发布之痛，来自把清单只当发布前的事、发布日一过就没声了——而决定成败的指标，恰恰是那之后才来的。
一张全勾的清单让人觉得就绪，但你分不清哪些绿项在你勾上之后已经过时。Draftlize 把每一项做成带真实依赖的卡片，于是一改价，凡是建立在旧价上的项都自动标成 stale——绿保持诚实，而不是把虚构藏到发布当天。
把上面这份清单抄走,或者开个项目、让 agent 从你的 spec 和 PRD 里把它填好 —— 然后替你把每一项、以及它依赖的一切,一路保持到发布当天都还是当下的真相。
$5 免费起步