版本上线前用 AI 出 12 项发布清单，半小时落成一张表

一句话结论

把近一年的上线问题丢给 AI，让它归纳成 12 项检查清单，发版前逐条勾。不靠记忆，也不靠那份没人更新的老清单。

这篇解决什么问题

版本上线前的检查，多数团队不是没做，而是每次做的都不一样。谁值班谁凭印象过一遍，改了什么、漏了什么，事后没人说得清。

这篇讲的是把这件事固定下来：用 AI 把踩过的坑变成一张 12 项的清单，跑一次就能拿到能贴进发布单的东西。

适用：至少发过三次版本、能翻出历史问题记录的团队。不适用：还没正式上线过任何版本、环境和分支都没理清的项目。

开始前要准备什么

• 一个能用的大模型对话工具，豆包或 Kimi 都行，免费额度足够跑完这套流程
• 近半年到一年的上线问题记录：报错、回滚、用户反馈，凑 3 到 5 条就够
• 本次发布的基本信息：版本号、灰度还是全量、有没有库表和第三方配置变更
• 一段不被打断的时间，整套走完通常在半小时上下

具体怎么做

第 1 步 · 把踩过的坑原样倒出来

打开豆包或 Kimi，新建一个对话，把下面这段提示词整段粘进去，后面跟你的问题记录。记录不用整理，越原始越好，照着当时事故群里的消息抄，人名和业务名换成化名。

我自己的习惯是：记录长、粘贴好几屏的时候用 Kimi，短的时候用豆包，响应更快。

你是我的发布流程助手。下面是我们近一年线上出过的 5 次问题，已经脱敏，人名和业务名都是化名。请你逐条做两件事：一是判断问题发生在发布的哪个环节（发布前准备、发布执行、发布后观察），二是写出当时如果做了哪一项检查就能拦下它。只做归纳，不要给改进建议，不要评价我们做得怎么样。
问题记录：
1. v2.4.1 上线后订单服务报错，原因是新增的数据库字段没在预发环境执行，回滚花了约 40 分钟。
2. v2.4.3 发版后首页白屏，原因是前端静态资源的 CDN 缓存没刷新，用户先看到了旧页面。
3. v2.5.0 灰度阶段支付回调失败，原因是回调地址只在测试环境配置过，生产环境没核对。
4. v2.5.2 上线第二天定时任务重复执行，原因是新旧实例同时在线，旧实例没下线。
5. v2.6.0 发布后产品反馈埋点数据对不上，原因是埋点开关默认关闭，发布时没人打开。
输出格式：两列表格，列名为「环节」「可拦截的检查项」。

预期产出：一张两列表格，通常能拿到 8 到 12 条检查项。这一步我自己做下来发现，AI 归纳出的检查点往往比复盘文档里写的更贴动作层，因为它不受「谁的责任」这种顾虑影响。

第 2 步 · 锁死 12 项，生成初稿

数量必须写死。不写死，它会给你二十几项，看着周全，上线那天没人勾得完。

基于上一步归纳的检查项，帮我生成一份 12 项的上线发布清单。要求如下：
1. 按「发布前」「发布中」「发布后」三段分组，每段 4 项；
2. 每一项写成一句可勾选的判断句，动宾结构，25 字以内，必须能被一个不在场的同事判断出「做了」还是「没做」；
3. 不出现「注意」「关注」「确认一下」这类模糊词，出现就换成具体动作；
4. 每项后面补两个字段：「判断依据」（看哪里、看到什么算通过）和「建议负责角色」（开发、测试、运维、产品选一个）；
5. 用 Markdown 表格输出，列为：序号、阶段、检查项、判断依据、负责角色。
数量固定 12 项，不要多给，也不要解释你的思路。

预期产出：一张五列的 Markdown 表格，12 项，分三段。表格出来先扫一眼有没有两项在说同一件事，这种情况很常见，先记下来，下一步一起改。

第 3 步 · 让它反过来问你

这一步跳过的人最多，但它决定清单是通用模板还是能用的东西。同一个模型，知道你是全量还是灰度、有没有数据库变更，给的项完全不一样。

现在请你反过来问我。为了判断这份清单够不够用，你需要了解我们这次发布的情况。请列出 5 个必须问清楚的问题，比如发布方式是灰度还是全量、有没有数据库变更、有没有第三方回调配置。每个问题下面说明「为什么这个问题会影响清单」。列完就停下等我回答，不要自己假设答案往下写。

预期产出：5 个左右的具体问题。老实回答，别嫌麻烦，尤其是数据库变更和第三方回调这两块，历史事故十有八九出在这里。

第 4 步 · 把答案填回去，让它改稿

还在同一个对话里，不要新开窗口，它得记得前面那张表。把第 3 步的问题答案按实际情况替换掉我示例里的内容。

我按你的问题补充如下：这次是全量发布，没有灰度；有数据库变更，新增两个字段，其中一个是必填；涉及第三方支付回调，生产环境的回调地址上个月改过。请你做三件事：
1. 把 12 项里对这个场景不适用的划掉，补上同等数量的新项，总数还是 12；
2. 标出其中最容易在赶进度时被跳过的 3 项，并写一句跳过的后果；
3. 检查有没有两项其实在说同一件事，有就合并，合并后补一项新的。
用表格输出，在最后加一列「改动说明」，写清哪项被换掉了、为什么。

预期产出：一版改过的 12 项清单，带「改动说明」列。被换掉的那几项值得多看两眼，通常正好对应你们项目里最容易漏的地方。

第 5 步 · 压成一页，贴进发布单

清单再准，放错地方等于没有。我会把它贴在需求卡或者发布单的评论区，让它在上线前一定出现在大家眼前。

把最终版清单压成一页，方便贴到协作工具里。输出三部分：
一、Markdown 表格，列为：□、检查项、判断依据、负责角色；
二、纯文本版本，每行一个「□ 检查项」，不加序号；
三、一句话说明：这份清单的适用版本号和下次复查时间应该写在哪里。
不要加总结，不要加鼓励的话，不要重复我上面给过的信息。

预期产出：一份带方框的表格，加一份纯文本待办。纯文本那份是给不想开表格的人用的，直接粘进群公告也能看。

实测记录

成本上没什么可算的，两个工具都在免费额度里跑完了。真正花时间的是回答问题那一步，因为要临时去翻配置和发布记录。

最容易错的 3 个地方

1. 不给事故记录，直接要清单。出来的都是套话。先喂 3 条真实问题再让它写。
2. 不限制数量。二十几项看着周全，上线当天勾到第八项就散了。写死 12 项。
3. 写成「注意确认缓存」。没人知道算不算做了。每项要能被外人判断做没做。

可复用的东西

五段提示词其实是串起来的：倒事故、锁数量出初稿、让它反问、带着答案改稿、最后压成表。换项目时只改三处——事故记录、发布方式、版本号，其余原样保留。

我把这套存成了一份文档，每次发版复制一遍，改掉第三段里的场景描述就行。清单别指望一次做到位，跑过三个版本之后它才真正贴合你们的节奏。

上线这件事，怕的从来不是没清单，是清单每年都在换。你现在这份上线检查，是靠什么定下来的？

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接