发布就绪评审：围绕这次变更组装证据包

先说结论

“全量测试绿了”只能说明既有断言没有发现问题，不能自动回答这次变更会影响谁、该补什么测试、离生产环境还有多远。发布就绪评审应绑定精确 revision，从 diff 推导专属风险，检查跨仓依赖，在隔离且接近生产的环境运行关键路径，最后把 metrics、logs、traces 和 summary 组装成可复核证据包。

两层评审机制

AWS 原文把能力分成两层。Release readiness review 对代码变更、团队标准、访问控制与跨仓依赖做分析，并在 AWS 管理的隔离环境执行轻量用户旅程，确认软件至少能构建、运行和通过基础功能检查。Autonomous release testing 则面向 Web 与 API 应用，在客户提供的类生产环境里生成并执行针对本次变化的测试计划。

这两层都必须从具体变更开始，而不是泛泛重跑一个静态套件：

1. 固定 PR、分支或 commit SHA，列出代码、配置和基础设施变化。
2. 结合明确的组织标准与依赖图，找直接和跨仓消费者；“通用最佳实践”不能替代本地契约。
3. 为风险生成专属测试，覆盖功能、回归和集成，不删除原有确定性测试。
4. 在隔离环境记录环境身份、步骤、指标、日志、trace 和执行摘要。
5. 把 BLOCK、谨慎继续或可发布之类的建议交给人判断；建议不是上线授权。

和 Zero-to-AI 的日常开发怎么接上

本站现有 npm run verify 仍是基础门禁。可以在准备发布时额外建立一页“变更证据包”：精确 commit、用户可见变化、直接消费者、外部依赖、由 diff 新增的一条测试、环境差异和全部工件位置。静态检查、构建、浏览器路径与人工验收分层写，不能用其中一层代替其他层。

小站通常没有完整跨仓知识图谱，但仍可从 package 依赖、站内链接、部署工作流和调用入口做最小检查。找不到消费者不等于没有消费者；证据缺口应进入风险摘要，而不是被改写成“安全”。

一个低成本实验

输入： 一次会改变页面行为或 API 响应的小改动、对应的基线 revision，以及一个不接触真实生产数据的临时环境。

步骤：

1. 从 diff 写出一条现有套件未覆盖的用户风险，并据此增加一个变更专属测试。
2. 记录直接调用者、配置引用和可能受影响的部署步骤；跨仓项不知道就明确标为未知。
3. 在固定环境分别运行基线与候选 revision，保存命令、退出码、关键 metrics、logs、traces 和摘要。
4. 人工复核证据包能否支持“阻塞、谨慎继续或进入下一层验收”，但不在实验中执行发布。

成功证据： 证据包能绑定精确代码与环境，专属测试可在有缺陷版本失败、修复版本通过；每项结论都能回指日志、trace、指标或依赖证据，未知项没有被隐藏。

停止线： 环境与生产关键依赖明显不同、跨仓索引过期、测试需要真实用户数据，或日志与 trace 无法绑定同一 revision；停止给出“可发布”结论，先补证据或转人工验收。

常见误区

• “Agent 生成了更多测试，所以覆盖更完整”：测试必须能在负例失败，数量不是有效性。
• “隔离环境通过就是生产安全”：配置、流量和外部依赖差异仍可能改变结果。
• “Safe to Release 等于批准上线”：工具建议、owner 接受和真实发布是三种状态。

原文与证据边界

AWS DevOps Agent 的发布管理能力在原文发布时处于 preview。跨仓依赖分析、隔离环境评审、专属测试与证据工件均为 AWS 产品说明；本站没有连接真实 Agent Space、运行该服务或核验其风险召回率，也没有证据证明它能替代安全评审、合规检查或发布负责人批准。本文实验验证的是证据包方法，不是 AWS 产品效果。

本文是原创中文实践解读，不是逐句翻译。阅读英文原文。