要用 AI 构建软件发布检查清单，先冻结确切的发布版本，为每道门禁收集证据，再请模型把这些证据整理成一张可审核的表格。AI 可以暴露缺失的负责人或前后不一的措辞，但只有承担责任的发布负责人才能批准豁免（waiver）或作出最终的 go/no-go 决定。

这个流程比通用的负责任使用 AI 的指南范围更窄。它产出的是针对单次发布的运营控制，而不是可复用的 SOP、发布说明、拉取请求摘要或迁移设计。

关键要点

把清单绑定到一个 release ID、源代码修订版、制品、环境和时间窗口。

让每道门禁都能用可长期保存的证据回答，而不是凭信心或记忆。

明确记录负责人、状态、豁免、停止条件和回滚触发条件。

不让 AI 接触生产凭据，也不让它声称某项测试已通过。

发布前演练清单，发布后保存填写完成的记录。

什么样的发布检查清单才可审计？

有用的发布检查清单是针对某一具体变更的决策记录。它写明要发布什么、哪些条件必须成立、由谁核实、证据存放在哪里，以及条件不满足时怎么办。NIST 的安全软件开发框架（SSDF）建议把安全实践融入每一次开发生命周期的实施之中，而不是把安全当作孤立的最后一步。［1］

Google 的发布工程指南同样把发布视为可重复、受控的过程，强调自动化、自助服务和可审计性。其上线指南则强调在扩大暴露之前做好规划、可靠性评审、容量、监控和回滚。［2］［3］这些原则指向的是一份记录证据和决定的清单，而不是一堆含糊的提醒。

每道决策门禁占一行：

字段	它确立什么
门禁 ID	便于讨论和审计的稳定引用
发布身份	release ID、源代码修订版、制品标识和目标环境
要求	二元的或边界明确的条件
证据	测试报告、签名的构建记录、查询、仪表盘、批准或命令输出
证据负责人	负责生成证据的人或系统
决定负责人	有权把门禁标为通过或豁免的人
状态	未运行、通过、失败、受阻或已豁免
豁免	理由、范围、到期日、批准人和补偿控制
时间戳	证据和决定在何时有效
失败动作	停止、调查、缩小暴露范围或回滚

当真正的条件是“修订版 abc123 所需的测试任务已成功完成”时，不要写成“测试已完成”。后一种写法人人理解不同；前一种可对照制品核查。

步骤 1：冻结发布身份和范围

从一个不可变更的发布头开始。记录 release ID、代码仓库和源代码修订版、构建或镜像标识、目标环境、包含的服务、配置包、数据库变更、功能开关、计划的时间窗口，以及承担责任的发布负责人。任何身份信息一旦变化，就创建新的清单版本，或明确宣布受影响的证据失效。

把纳入的工作与邻近的工作分开。一个分支中可能有实验、文档、生成的文件，或计划在之后部署的变更。清单应写明被推进的确切制品，而不是假定某个分支标签就能唯一确定其内容。

这里也要把本任务与代码迁移计划区分开。迁移计划解释依赖、兼容性、先后顺序和架构；发布检查清单则回答：已批准的计划及其证据，是否已为这一次具体的推进做好准备。

步骤 2：先建证据目录，再向 AI 提问

只收集获批且必要的材料。典型的输入包括 CI 任务链接、测试摘要、依赖和漏洞报告、制品证明、变更工单、数据库迁移演练、运行手册、告警定义、容量测试结果、功能开关计划、支持说明和回滚说明。

不要把密钥、生产令牌、客户记录、私钥、未脱敏的日志或专有源代码粘贴到 AI 工具中。用稳定的标签替换敏感值，并保留指向权威内部系统的链接。如果模型需要理解某个失败，只提供最少量的脱敏摘录，并说明删去了什么。

把每项输入归入以下四种证据状态之一：

已核实： 由指定系统针对已冻结的发布身份生成。
待定： 预期会有，但尚未生成。
不适用： 已排除，并记录了理由和批准人。
有冲突： 两个来源不一致，需要调查。

AI 不得把待定或有冲突的证据升级为已核实。NIST 的生成式 AI 配置文件强调了虚构内容、信息完整性、隐私和人工监督方面的风险；一份行文流畅的清单，并不能证明其中各行都属实。［4］

步骤 3：按要防止的失败设计发布门禁

按门禁所要防止的失败来分组，而不是按负责的团队分组。这样跨团队的依赖才能一目了然。

构建与身份门禁

确认制品来自已冻结的源代码修订版、必需的构建任务已完成、依赖按预期锁定、可提供来源证明，并且推进到预发布环境的制品与计划发布到生产环境的是同一个对象。如果组织会对制品签名，就记录验证结果和验证人，而不是签名所用的私密材料。

功能与兼容门禁

链接必需的单元、集成、端到端、回归和平台测试结果。写明受支持的版本和重要的向后兼容性检查。有针对性的测试可以作为有用的证据，但不能把它当作某个无关的完整测试套件门禁已经关闭。

安全与隐私门禁

记录已完成的审查要求、漏洞处置、权限变更、密钥处理、数据迁移的影响、隐私审查和尚未解决的例外。扫描器的结果本身并不代表风险已获批准；应由获授权的安全或隐私负责人记录决定。

运维就绪门禁

确认仪表盘、日志、告警、服务水平指标、值班负责人、容量、速率限制、依赖健康状况、支持升级路径，以及能否区分新旧两个版本。写明发布期间将使用的查询或仪表盘视图。

部署与恢复门禁

明确部署前检查、变更顺序、canary 规模、观察窗口、扩大范围的标准、停止条件、回滚触发条件、回滚命令或运行手册、回滚后的数据兼容性，以及有权采取行动的人。如果没有人测试过回滚路径，或没有识别出不可逆的数据变更，“可以回滚”这句话就不够。

步骤 4：用 AI 构建软件发布检查清单时只给不推断任务

请 AI 整理提供的证据，而不是判断是否就绪。一个有用的提示如下：

根据提供的发布头和证据目录生成一张发布门禁表。
逐字保留 release ID、修订版、制品 ID、负责人、来源链接和状态。
不得推断任何测试、审查、批准、部署或回滚已经成功。
缺少证据标为 [PENDING]，有冲突标为 [CONFLICT]。
为每道门禁提出二元要求、所需证据、决定负责人、
失败动作和需向负责人确认的问题。不得批准豁免或发布。

要求模型给出各版草稿之间的变更记录。如果模型合并了两行，要求它说明合并了哪些证据引用。如果它新增了一道门禁，在相应负责人接受之前，该行只算建议。

AI 也可以把草稿与一份稳定的 SOP 清单比较，但这两种产物必须保持区分。SOP 解释反复使用的方法；发布记录则把这一方法绑定到一个制品和一个决策时间窗口。

步骤 5：固定状态、例外和权限规则

使用封闭的状态集合。“基本完成”之类的自由状态标签会掩盖不同程度的风险。一套实用的状态是 NOT_RUN、PASS、FAIL、BLOCKED、NOT_APPLICABLE 和 WAIVED，并由组织规定谁可以设置每一个值。

豁免应包含未满足的要求、理由、受影响的范围、风险负责人、补偿控制、到期日、复核触发条件和批准人。绝不能因为无人反对就生成豁免。如果发布经理无法确定获授权的批准人，该行就保持受阻状态。

把证据负责与决定负责分开。CI 系统可能生成测试结果；工程负责人可能解释某个已知失败；风险负责人可能接受有边界的例外；发布负责人作出最终发布决定。把这四种角色合并到一个含糊的“负责人”字段中，会削弱问责。

步骤 6：把 canary、监控和回滚写成测试

把每一项运维陈述都变成可观察的条件。例如：

Canary：让获批的用户群体接触新制品 20 分钟。
健康：错误率、延迟、饱和度和业务护栏指标都保持在指定阈值之内。
停止：任何严重告警触发，或任一护栏指标突破阈值时，停止扩大范围。
回滚：调用经过测试的运行手册，确认已恢复到前一版本，并核实数据兼容性。
升级：证据缺失、含糊或延迟时，呼叫指定的角色。

以上数字只是结构示例；请使用为该服务批准的阈值。AI 不得编造可接受的错误率、canary 规模或观察窗口。这些数值来自服务目标、以往证据和承担责任的运维人员。

需要对外沟通发布内容时，把经核实的变更边界交给单独的发布说明工作流。面向用户的说明描述的是影响，不能代替运维就绪的证据。

步骤 7：做冷演练和独立挑战

在发布窗口之前，请一位没有参与起草清单的人，在非生产或获批的演练环境中执行清单。他们应当能找到每一个制品、重现每一项检查、识别决定负责人，并在不依赖私下背景的情况下解释失败动作。

至少挑战以下失败情形：

某个测试链接属于较旧的修订版；
预发布环境中的制品标识与发布头不一致；
某位必需的负责人无法到场；
某个仪表盘没有新版本的数据；
迁移可以正向执行，但回滚不兼容；
某项豁免已过期或缺少批准人；
某个依赖在审核时健康，却在发布过程中出故障；
canary 看起来健康，但一条流量很小的关键路径仍未测试。

记录更正，而不是悄悄替换历史。如果拉取请求摘要缺少背景，就通过 PR 描述流程改进它，再从发布记录中链接到经过审核的产物。

步骤 8：执行、签字并保存记录

发布期间，只依据权威证据更新各行。记录实际的时间戳、执行人、制品、观察结果和决定。如果发布内容发生变化，就让过时的行失效，而不是把绿色标记沿用下去。

最终的 go/no-go 部分应显示未解决的失败、生效中的豁免、回滚准备情况、当前的依赖状态，以及发布负责人的决定。部署完成后，记录实际运行的版本、监控结果、事故、回滚结果（如有使用），以及后续工作的链接。

把填写完成的清单连同其证据引用和变更历史一起归档。模板可以复用，但绝不能照搬上一次发布的“已通过”状态。这份记录的价值在于，另一位审核人能还原当时已知的信息和决定者。

哪些检查最容易发现问题？

总结

把清单绑定到一个不可变更的发布身份。
先收集证据，再请 AI 整理记录的结构。
把门禁表述为可观察的通过/失败条件，并写明有权决定的人。
不让 AI 声称测试已通过、批准豁免或作出 go/no-go 决定。
演练 canary、监控、停止和回滚路径。
保存填写完成的记录，用于审计和改进。

常见问题

发布检查清单与 SOP 相同吗？

不同。SOP 描述反复进行的流程，而发布检查清单记录的是某一个确切制品在特定时间是否满足其门禁。清单可以引用 SOP，但必须把状态和证据绑定到发布身份上。

AI 能判断软件是否可以发布吗？

不能。AI 可以整理提供的证据、找出缺失字段并提出问题。它无法核实外部任务是否正确运行，无法理解未披露的运维背景，不能接受风险，也不能作出承担责任的 go/no-go 决定。

清单需要多少道门禁？

使用能覆盖重大发布风险和强制控制的最小集合。当证据、负责人、状态或失败动作不同时，就拆分为不同的行；只有当这些属性确实相同时才合并。

缺少证据时怎么办？

把门禁标为待定或受阻，写明证据负责人，并规定截止时间和失败动作。不要用旧报告、口头保证或 AI 生成的文字代替证据。

每个失败都必须停止发布吗？

应由组织政策规定哪些门禁具有阻断作用，以及谁有豁免权。未满足的强制门禁始终保持阻断，除非存在获授权并有记录的例外；AI 不得判定某个失败无关紧要。

数据库迁移怎样写入清单？

引用获批的迁移计划、演练证据、兼容窗口、备份或恢复路径、正向和回滚命令、负责人以及停止条件。不可逆的操作要明确写出。

什么样的发布回滚计划可信？

它写明前一个制品、触发条件、权限、经过测试的步骤、数据兼容性假设、预期恢复时间和验证步骤。只链接一份未经测试的通用运行手册并不够。

发布后怎样维护清单？

保存填写完成的记录，记下事故和意料之外的手动步骤，并另行更新可复用的模板。绝不要为了让这次发布看起来更干净而改写历史状态。

来源

NIST, Secure Software Development Framework (SSDF) Version 1.1 — https://csrc.nist.gov/pubs/sp/800/218/final
Google, Site Reliability Engineering: Release Engineering — https://sre.google/sre-book/release-engineering/
Google, Site Reliability Engineering: Reliable Product Launches at Scale — https://sre.google/sre-book/reliable-product-launches/
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 4 日。

用 AI 构建软件发布检查清单，让每道门禁都有可查证据