回归清单：三十八条怎么砍到二十六条

清单不是越长越安全，是长到没人愿意跑完的那一刻，就已经失效了。

一、改了一句邮件模板，跑了九十一分钟

三月的一个周四下午，他只改了任务到期提醒的邮件模板：在正文里加了一句「截止日期见下方」。按惯例，他把三十八条回归清单从头跑了一遍。

跑到第二十四条时，五十八分钟过去了，他关掉终端，去打了两个小时游戏。那处改动真正需要的，是三条必跑加两条邮件相关的选跑，十二分钟。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

清单的问题不是太长，是只有一种跑法。 三十八条里，十二条坏了就是事故，十二条一年只用几次；把它们放在同一个队列里按顺序跑，结果一定是跑到一半放弃。

他后来把那次发布复盘了一遍：真正与模板相关的只有五条，其余三十三条跑完没有提供任何信息；而因为中途放弃，最后几条季度项已经连续四次被跳过。

清单原本是三个月的产物：每次线上出问题就加一条，只加不减。三十八条里有十九条是某次事故的纪念碑，而那类事故再也没有出现过。

他没删清单，只是把它拆开。拆开之后的第一次发布，他在五十八分钟里跑完二十六条，还剩十分钟检查了回滚包能不能下载。

那天晚上他按影响面重排了一遍：与模板相关的只有五条，其余条目不是不重要，是这次不该跑。清单要回答的是「这次跑什么」，不是「所有时候该跑什么」。

二、三问排序：上次改哪、哪最易坏、哪坏了最贵

他不再按功能模块排列清单，改成每条都过三个问题。三个问题至少答得上一个，才配留在清单里。

第一问：上次改的是哪。 最近三个月动过的模块，回归权重最高；刚改过的代码，缺陷密度是稳定代码的数倍。这一问决定「这次跑什么」。

第二问：哪最易坏。 过去一年线上四十七个缺陷里，三十一个落在关键路径上，占 66.0%；缺陷集中在哪几个页面、哪几个接口，清单就该往那里倾斜。这一问决定「什么该常驻」。

第三问：哪坏了最贵。 按四阶段成本倍数，同一个缺陷在需求阶段修是 1，上线后是 100；再叠加不可逆性，收错钱、丢数据、进不去这三类没有第二次机会。这一问决定「什么必须每次跑」。

排序规则很硬：三问都命中的进必跑，命中两问的进选跑，只命中一问或一问不答的进季度。 没有「感觉重要」这一档；感觉不能复算，也就不能在下个季度被检验。

第一问的数据来自提交记录和上一次发布记录，不靠记忆。他每周五花十分钟把这周改过的目录抄进发布记录，下一次发布直接照那几行挑条目。

第二问看缺陷分布，不看代码量。四十七个缺陷里三十一个落在关键路径，说明清单应该压在关键路径上，而不是按模块平均铺开。

第三问把成本倍数和不可逆性叠在一起。导出按钮的样式错和删除账号的误删，修复成本差上百倍，不该占同样的回归权重。

三、三十八条分成三档

分档之后，清单从一张平表变成三张短表。下表是三档的定义与例子。

必跑十二条是硬上限。 超过十二条，发布前就会开始挑着跑；挑着跑和没有清单是一回事。要加一条进必跑，先踢一条出去。

季度项不能删，只能集中跑。 年度报表算错、备份恢复失败这类问题，用户往往几个月后才发现，甚至永远不发现；它们不进发布队列，但每季度必须有人真的点一遍。

选跑是按变更类型挑的池子，不是「有空就跑」。 改前端就挑表单与列表相关的六条，改后端就挑对应模块的四到八条；挑几条由映射表决定，不由当天心情决定。

季度项最能说明静默失败。 年度报表把退款算成收入，数字看起来合理，用户不会报错，直到报税时对不上；这类问题不拦发布，也就没有外部压力，只能靠日历推动。

必跑十二条是从五条不可逆路径倒推的，不是挑最吓人的。 每条路径至少两条（入口与结果），再加上跨租户隔离与邮件送达，正好十二条；多出来的说明路径定义不清，先回去改路径。

档位会移动。 同一个功能加了开关之后可以从必跑降到选跑，因为坏了能立刻关掉；开关下线，它又得升回去。档位跟着可逆性走，不跟着功能重要性走。

三档之外不设第四档。 「有空再看」的条目等于没有归属，半年后既不会被跑，也不会被删；留不下位置的条目，就当场删掉。

四、变更类型决定跑哪一档

三问回答「它为什么在名单上」，映射表回答「这次改哪、跑哪些」。两者合起来，才是可执行的回归。

复算：
全量 = 38 条 × 2.4 分钟 = 91.2 分钟
发布跑 26 条 = 必跑 12 × 2.5 + 选跑 14 × 2.0 = 30 + 28 = 58 分钟
每次节省 = 91.2 − 58 = 33.2 分钟
一年 12 次发布 = 33.2 × 12 = 398.4 分钟 = 6.64 小时

2.4 分钟是全量平均，不是每条都一样。 必跑项要建数据、走完整链路，平均 2.5 分钟；选跑项多是单页操作，平均 2.0 分钟；季度项含准备与核对，不摊进每次发布，按季度单独排一次。

六点六四小时不是重点，愿意跑才是。 一年省下的时间不到一个工作日；真正的变化是发布前那五十八分钟他肯坐下来跑完，而不是跑到一半关终端。

全量不是取消，是降频。 每季度一次全量、每次大版本一次全量，作用是校准分档是否还准确，而不是日常执行；分档一旦长期不校准，漏掉的路径不会自己冒出来。

映射表要写死，不要靠记忆。 六行五列，贴在发布脚本旁边；改了什么类型的代码，就照那一行执行，跑完在发布记录里写一句「按第几行执行」。

每条都要有失败史。 清单里每条后面记两个字段：上次失败时间、对应缺陷编号；连续四个季度既没失败也没抓到缺陷的，降一档或者删掉。

映射表覆盖不了的情况，按三问现场判。 拿不准就按更贵的那一档跑，多花十分钟比少跑一条便宜；事后把这次判断补进映射表，下一次就不用再想。

他确实被映射表救过一次。 改配置里的开关默认值时，表上写的是跑通知与限额三条；他顺手加跑了结账，发现那个开关把试用期长度也一起改了。

发布记录只写三行：改了什么、按映射表哪一行执行、实际耗时。 三个月后回看，哪些行从来没被用到、哪些行每次都超时，一目了然。

五、行动清单与复算验收

先分档，再删条目；顺序反了，删掉的往往是以后会用到的。从现有清单开始，一个下午能做完。

• 把现在的回归清单逐条抄出来，数清总数，标上每条的平均耗时。
• 对每条过三问，按「三问 / 两问 / 一问」分成三档。
• 把必跑压到十二条以内，超出的按「哪坏了最贵」排序后踢出。
• 给选跑十四条补上所属模块标签，方便按变更类型挑。
• 把季度十二条单独建一张表，写进季度日历，不放进发布流程。
• 写六行变更类型映射表，明确每类改动跑哪几条。
• 用最近一次真实发布复跑一遍，记录实际耗时与漏掉的问题。
• 给每条加上「上次失败时间 / 缺陷编号」两个字段，下季度复查。

验收标准：你能说清这次改动该跑哪几条、为什么是这几条，并且发布前的实际耗时落在六十分钟以内；做不到，清单就还只是一张愿望单。

使用边界与实操验收

条数不是标准。 三十八与二十六是这套产品的数字；换一个产品，必跑可能只有六条，季度可能有二十条，分档逻辑不变。

必跑不能靠自动化替代。 十二条里有几条已经写成端到端，但邮件送达、时区提醒仍要人工看一眼真实收件箱；自动化通过不等于用户收到了。

季度项最容易被跳过。 它不拦发布，也就没有外部压力；把它写进季度日历并设定固定日期，比任何提醒工具都管用。

清单会腐烂。 功能下线、页面改版、接口废弃，清单却还在；每季度删一轮，比每季度加一轮更重要。

本文不构成对任何发布节奏、条目数量或工具链的承诺。 数字全部是教学假设，具体工具的用法以官方文档为准。

关键参考与核验范围

• GitHub Actions 工作流语法 ：用于说明如何把分档后的清单挂到流水线。
• Playwright 入门 ：用于核对必跑条目中端到端部分的执行方式。
• Feature Toggles ：用于说明可回滚的改动为何能降档到选跑。
• 语义化版本 ：用于依赖升级时判断变更范围与回归档位。

以上链接于 2026-10-26 实测可公开访问；未核验版本、价格与配额。核验日期：2026-10-26。

边界句。 本文只讨论一人产品的回归清单分档与变更映射，不讨论自动化测试框架选型、性能回归与安全回归。

系列导航

• 上一篇：三层验证的一个人配比：单元、集成与六条端到端
• 下一篇：发布门禁：六项检查与一个红绿灯
• 回到目录：一个人的质量守门：验证预算、回归清单与发布门禁
• 相关阅读：一个人的消息系统：事务邮件、通知分层与送达率