AI 编程智能体提交 PR 前怎么验收？测试、权限与回滚指南

直接答案：AI 智能体的 PR 不能靠‘看起来合理’合并

把 AI 编程智能体提交的 PR 当成一个需要独立验收的外部贡献：先核对任务合同和变更边界，再从干净环境复现构建与测试，检查安全、数据、依赖和运维影响，最后由受保护分支、代码所有者与可执行回滚共同决定是否合并。智能体生成了代码、测试和说明，只能证明它提交了材料，不能证明结果正确，更不能让它批准自己的改动。

为什么保留 124989 而不再新建一个 PR 清单页面

站内已有这个明确意图的排期 URL，用户任务始终是审查 AI 编程智能体产生的拉取请求。旧稿只有约一千二百个字符，证据、失败分支、独立资产和当前视觉都不满足新 A 标准，因此本轮不把旧批准当通行证，而是保留 URL 与主题，冻结旧排期后整体重建。这样既避免同意图内耗，也让旧短稿不会在没有实页 QA 的情况下自动公开。

先写一页变更合同

合并前应能用一页说明回答：要解决什么问题、允许改哪些目录、明确禁止什么、成功标准是什么、运行哪些命令、哪些数据或权限不可触碰、谁负责验收、怎样回滚。任务合同必须在智能体开始工作前存在；事后根据补丁倒推目标，会把越界改动包装成必要工作。合同应使用仓库可以验证的路径、命令和阈值，不写‘确保高质量’这类无法判定的口号。

把 PR 描述当索引，不当证据

PR 描述应列出任务、改动文件、用户可见变化、测试、风险、未完成项和回滚入口，但审查者必须从差异和实际运行结果核对这些声明。智能体可能遗漏自动生成文件、锁文件、配置、迁移或删除，也可能把失败测试概括为已通过。每条‘已验证’声明至少连接到具体命令、提交 SHA、运行环境和回执；无法复现时改写成待验证，而不是保留肯定语气。

第一道门：确认审查的是最新提交

状态检查与人工批准必须对应 PR 最新 head SHA 或平台实际要求的测试合并提交。智能体收到评论后继续推送，旧测试和旧批准就可能不再覆盖当前差异。回执保存仓库、分支、base SHA、head SHA、merge SHA（如适用）与生成时间。GitHub 官方说明必需检查需要针对正确提交通过；审查界面显示绿色不等于你本地拿到的补丁与该绿色结果相同。

第二道门：逐文件核对范围

先看文件清单，再看补丁。把每个文件标记为直接实现、测试、文档、生成物、依赖、配置、迁移或无法解释。发现顺手重构、格式化全库、删除保护逻辑、修改工作流、扩大网络权限或新增遥测，应拆分或停止。范围门不是限制合理修复，而是要求每项变化都有任务关联和独立理由，使回滚能够只撤销本次行为，而不把无关改动绑在一起。

第三道门：在干净环境复现

不要只相信智能体工作区的最后输出。用固定提交、受控依赖源和无共享缓存的干净环境执行安装、格式化、类型检查、构建、单元、集成与任务特定测试。记录操作系统、运行时、包管理器、锁文件、环境变量名称和命令退出码。缺少私有服务时用明确的模拟器或暂缓合并，不能把‘本机没有条件’写成通过。干净复现能暴露未提交文件、隐藏缓存和本地全局依赖。

第四道门：测试必须覆盖错误路径

智能体生成的测试可能只重复实现逻辑，或只验证它知道会成功的路径。每个功能变化至少检查正常、边界、无权限、无数据、重复请求、并发、超时、下游失败与恢复。修复缺陷时先写能在旧版本稳定失败、在新版本通过的回归测试。若测试无法观察真实用户结果，只能算组件证据；不要用大量快照或行覆盖率掩盖关键业务不变量没有被验证。

第五道门：检查安全敏感差异

认证、授权、租户隔离、密钥、支付、上传、反序列化、命令执行、模板渲染、网络请求和日志属于高风险区域。逐条追踪输入从入口到副作用的路径，验证服务端授权而不是只看前端隐藏，测试另一个租户或角色不能读取目标资源。新增脚本和工作流还要检查令牌权限、外部 Action 固定版本、输出转义与不可信输入；安全扫描是补充，不能替代数据流审查。

第六道门：准备可执行回滚

回滚不是写一句‘可以 revert’。代码回滚要确认提交可逆、兼容窗口与配置默认值；数据库变更要明确前向修复、双写、读旧写新或不可逆边界；缓存、队列、搜索索引和对象存储可能需要额外恢复。上线前在测试环境演练触发、执行和验证步骤，写明负责人、停止阈值和预计时间。若旧版本不能读取新数据，简单回退二进制可能造成更大事故。

GitHub 状态检查的绿色边界

GitHub 的 check run 与 commit status 都可参与合并门禁，但绿色只说明配置的检查报告了允许结论。官方文档指出 skipped 与 neutral 在某些依赖或门禁路径上也可被视为成功，且拥有写权限的主体可能设置状态。因此要核对检查来源、运行条件、最新提交和日志，防止路径过滤让关键工作流根本没有运行。关键检查应限制到预期 GitHub App，并保存工作流版本。

分支规则集要保护最后一米

为主分支要求 PR、必需检查、代码所有者批准、旧批准在新推送后失效、会话解析和受控合并队列。限制可以绕过规则的人和应用，并定期审计旁路记录。规则只对平台上的合并路径有效，不能防止凭据持有者直接修改生产数据库或部署配置，所以发布权限仍应与仓库权限分离。智能体账户不应拥有跳过审核、修改规则或批准自身 PR 的能力。

合并队列需要单独触发验证

当仓库启用 merge queue，GitHub Actions 工作流若只监听 pull_request，进入队列后的临时合并提交可能没有对应检查。官方故障排查文档要求相关工作流包含 merge_group 事件。验收时模拟一次真正入队，确认必需检查在队列提交上重新运行，且没有用旧 head SHA 的成功结果放行。高并发团队还要观察队列超时、取消、基线前移和冲突时的重新验证。

不要在特权上下文运行不可信 PR 代码

GitHub 官方安全文档明确警告：在 pull_request_target 或其他带秘密、写令牌的上下文中检出并执行外部 PR 代码，会形成供应链风险。即使工作流文件来自默认分支，随后执行 PR 内的 Makefile、脚本、依赖安装或测试也可能泄露秘密。外部分支应在隔离、临时、无秘密或最小只读令牌环境运行；需要评论或贴标签的特权工作流只消费经过验证的结果，不执行其内容。

依赖变化需要独立审查

新增或升级依赖时核对官方来源、维护状态、许可证、完整性、传递依赖、安装脚本、运行权限和体积。锁文件大幅变化不能只看顶层 package.json；使用包管理器解释为什么解析结果变化。对容器镜像和 Actions 固定不可变摘要或受控版本，并计划更新机制。依赖扫描发现无已知漏洞不等于安全，也不能证明包名没有拼写劫持或安装脚本不会访问网络。

数据库迁移先看兼容顺序

把 schema 变化按扩展、迁移、切读写、收缩分阶段处理。新增可空字段通常比直接重命名或删除安全；大表索引、默认值、回填和锁需要在代表性数据上评估。测试旧应用与新 schema、新应用与旧数据的兼容组合，并记录失败时如何暂停或前向修复。智能体生成的 down migration 可能丢数据，不能因为存在 rollback 文件就声称迁移可逆。

API 变化要验收契约与调用方

比较路径、方法、认证、参数、默认值、错误码、分页、幂等、速率限制和响应 schema。保留旧客户端样本与错误路径，确认字段新增不会破坏严格解析，字段删除或语义变化有版本策略。内部 API 也要搜索所有调用方、异步消费者和文档示例。仅通过服务端单元测试不能证明移动端、任务队列或第三方集成仍然兼容。

前端变化不能只看截图

截图能证明某个视口出现了某个画面，不能证明键盘、屏幕阅读器、错误状态、国际化和交互都正确。核对语义 HTML、焦点顺序、可见标签、颜色对比、缩放、390px 宽度、慢网、加载和空状态。用户可见行为应有稳定的端到端或组件测试，但选择器不要只依赖易变样式。涉及上传、支付或删除时，确认重复点击、返回和刷新不会产生重复副作用。

后台任务要验证重试与幂等

队列消费者、定时任务和 webhook 可能在至少一次投递下重复执行。测试相同事件、乱序、延迟、部分失败和毒消息，记录幂等键、最大重试、退避、死信与人工恢复。智能体常把异常捕获后返回成功，导致消息丢失；也可能无限重试放大下游事故。通过条件是业务终态正确且可追踪，不是日志里没有未捕获异常。

并发变化要寻找竞争窗口

对读改写、库存、配额、锁、缓存失效和状态机，单线程测试不足。写出允许状态转换和不变量，用并发夹具制造重复、交错、超时和进程重启。确认事务范围、唯一约束、乐观锁或分布式锁的失败处理。不要接受‘概率很低’作为结论；如果无法稳定复现，就加入观测和停止条件，在灰度中限制影响面。

日志与遥测不能泄露更多数据

新增可观测性时列出字段、来源、保留期、访问者和脱敏规则。密钥、令牌、Cookie、完整提示、上传内容、个人身份与支付信息不能进入普通日志。错误对象和第三方 SDK 可能自动包含请求体，需用测试数据检查实际输出。采样和追踪 ID 应支持事故定位，但不能把用户内容复制到新的供应商。遥测能证明请求发生，不等于证明用户、成功或业务价值。

许可证与生成来源也要留痕

智能体可能复制训练或检索上下文中的代码片段，项目仍需运行许可证和相似性检查，核对新增文件头、第三方资源与模型输出条款。发现与外部实现高度相似时，追到原始仓库和许可证，必要时重写或取得许可。不能仅凭智能体说‘这是原创’放行；也不要把无法解释的归属自动写成本站或公司所有。

配置与基础设施变化扩大审查半径

Terraform、Kubernetes、权限策略、网络、DNS、密钥和 CI 工作流的少量文本可能产生大范围副作用。查看计划输出、资源替换、权限差异和环境选择，禁止在审查阶段使用生产写权限。对删除、公开访问、跨账户信任、通配符权限和持久卷变更设置人工批准。计划无变化只能证明工具当前计算结果，不证明云端漂移、配额或运行时行为不存在风险。

性能结论必须有可复现实验

如果 PR 声称更快或更省，记录基线与变更版本、硬件、数据、并发、预热、样本量和统计口径；同时观察 P50、P95、资源、错误率与正确性。减少耗时但丢请求、关闭验证或扩大缓存陈旧都不是优化。微基准不能外推整条用户路径。没有运行测试时，把文字改成设计预期，并为上线设置测量和回退阈值，禁止把智能体估算当实测数字。

测试由同一个模型生成时要加独立反例

生成者容易在实现和测试中共享同一误解。让人工或独立规则从需求与不变量出发补充反例，必要时用另一工具做静态审查，但最终仍由可执行结果与负责人判断。重点挑战权限、边界、旧数据、失败恢复和隐藏依赖，而不是要求第二个模型泛泛评价代码风格。AI 对 AI 的一致意见不是正确性证明，它们可能同时忽略同一上下文。

大 PR 先拆任务，再谈审查效率

当差异跨越多个意图、组件和风险域时，审查者无法建立清晰因果。按行为切成可独立构建、测试和回滚的小 PR，先合并机械准备，再合并功能，最后清理旧路径。不要为了减少 PR 数把数据库、API、前端、遥测和基础设施塞在一起。若必须原子变更，提供分层阅读顺序、生成文件说明和逐阶段启用开关。

审查顺序从风险开始

先读任务合同和文件列表，再定位认证、数据、迁移、依赖、工作流与删除等高风险差异；然后检查核心行为和测试，最后看命名与样式。这样可在重大阻断出现时尽早停止，避免先花时间润色低风险代码。对每个关键不变量写下可验证问题，例如‘A 租户能否访问 B 资源’，并用代码路径和测试回答，避免被流畅的 PR 摘要带偏。

人工批准必须承担明确责任

指定产品行为、代码所有权、安全、数据或运维责任人，而不是让任何一个批准覆盖所有领域。审批记录说明看了哪些证据、接受什么残余风险和何时复查。合并按钮由有权承担后果的人操作，智能体和自动审查只能提出建议。紧急旁路要有时间限制、事故编号、事后补测与权限复核，不能演变为日常通道。

功能开关不是免测按钮

开关可限制暴露和快速关闭，但错误代码仍可能在初始化、迁移、构建或后台路径执行。验证关闭状态、开启状态、配置服务不可用、缓存旧值和不同租户组合。定义安全默认值、所有者、清理日期与指标。回滚时确认关开关是否足以停止副作用；已经写入的数据、发送的消息或外部调用不会因为界面关闭自动撤销。

发布前建立观察与停止条件

为新功能选择真实但最小的健康信号：错误、延迟、资源、业务终态、权限拒绝、队列积压和人工投诉。设置基线、阈值、观察窗、样本下限与责任人。部署成功和 HTTP 200 只说明技术路径可达，不证明功能正确。指标缺失、遥测断流或版本无法区分时应停止扩大；不能把没有告警解释为没有问题。

灰度要按稳定实体分桶

按租户、账户或稳定哈希放量，避免同一用户在新旧逻辑间来回跳。先内部和低风险租户，再扩大比例；每阶段重新核对质量、安全、成本和支持反馈。涉及状态写入时，确认新旧版本能共同读取并处理在途任务。灰度样本太小只能发现灾难性问题，不能证明长期正确，因此需要足够观察期和完整回滚能力。

回滚后还要处理残留状态

关闭路由或 revert 提交后，检查数据库、缓存、消息、对象、搜索索引、外部供应商和客户端版本。重复副作用要用幂等与对账修复，失败迁移可能需要前向脚本。保留失败提交、运行日志、样本和决策，避免修复时丢失证据。只有业务终态恢复、监控稳定和责任人确认后，才能结束事故；回滚动作执行成功不是事故已经解决。

如何验收智能体修改测试本身

测试删除、断言变宽、跳过条件、固定随机种子变化和快照批量更新都可能让红灯变绿。比较测试意图而非只看行数，要求每个变更说明旧行为为什么不再正确。对 bug 修复保留故障复现，检查修改前失败、修改后通过。若生产代码和测试同时由智能体修改，让独立样本或人工断言验证业务不变量，防止两边共同迁就错误。

如何验收文档和示例

文档中的命令、路径、参数与界面应在当前版本实际执行；示例使用无敏感数据的最小输入，并说明预期输出和失败分支。检查链接、版本边界、平台差异和权限前提。代码片段能编译不等于适合生产，涉及密钥、删除、付费或外部发布时必须给出安全边界。文档若承诺尚未上线的功能，应明确为计划而不是现状。

如何验收生成文件

构建产物、客户端、schema、锁文件和代码生成结果应由固定工具版本从源文件重新产生，并确认工作树无额外变化。不要手工修生成物掩盖源定义错误，也不要忽略巨大差异。记录生成命令和工具哈希；若生成结果包含时间戳或机器路径，应先消除非确定性。可重复生成是供应链证据之一，但不证明生成逻辑或业务定义正确。

如何验收删除与清理

删除代码前搜索运行时加载、动态配置、反射、任务调度、文档和外部调用，确认迁移窗口和回退版本不再依赖它。删除表、字段、事件或 API 前先观察实际使用并通知所有者。所谓‘无引用’可能只是静态搜索找不到动态入口。清理 PR 最好与行为变更分开，在生产已切换且观察期结束后执行，避免一旦失败无法快速恢复。

如何验收错误处理

检查异常是否被正确分类、传播、记录和转换，不能用 catch-all 吞掉故障或把失败返回成功。错误信息不得泄露秘密，但要包含可关联的请求 ID。重试只用于瞬时且安全重放的操作，设最大次数、退避和总时限。用户看到的恢复建议要真实可执行；自动降级改变质量、费用或数据路径时必须可观测，并在 PR 中写明边界。

如何验收缓存变化

定义键、范围、TTL、失效、版本和敏感数据边界。测试不同租户、权限、语言与配置不会共享错误条目，写后读和删除会触发必要失效。缓存命中提高不等于业务更快，若返回旧权限或旧价格就是严重错误。回滚时新旧键格式要兼容，无法兼容则计划双读或清理；大规模清缓存还要评估瞬时负载。

如何验收时间与时区

定时任务、过期、计费和报告应明确使用的时区、夏令时、闰日和边界。测试时钟回拨、跨日、月底、重复执行和延迟事件，不要依赖开发机本地时间。数据库存储与展示层转换分离，日志带时区。智能体常生成看似直观的日期运算，却遗漏业务日历或包版本差异；使用固定时钟和代表性样本验证。

如何验收多语言与编码

用简体中文、英文、混合实体、全角符号、emoji、组合字符和长文本测试输入输出。确认排序、截断、正则、数据库长度、URL 编码和导出不会损坏内容。前端字符数与后端字节数要区分。不要因为 ASCII 测试通过就声称国际化完成；也不要让自动格式化改坏合法引用、代码或品牌专名。生产日志出现乱码时先修编码链路，不用替换字符掩盖损坏。

如何验收隐私与数据保留

列出新增采集、处理、发送、存储和删除的字段，核对合法目的、最小化、地区、供应商、保留和访问控制。测试删除请求、导出、权限撤销与备份边界。即使功能由 AI 生成，责任仍属于部署者。代码里没有明文个人信息不等于无隐私影响，标识符、日志、向量和模型提示都可能可关联。任何新外部端点都需安全和合同复核。

可机读验收合同怎样使用

随文 JSON 示例记录任务、仓库、base/head SHA、允许路径、禁止路径、测试命令、风险标签、必需检查、人工批准、发布和回滚。离线校验器只验证结构、SHA 格式、路径边界和决定值，不访问 GitHub、不运行测试，也不判断代码正确。团队应把真实 CI 回执和审批链接填入后再归档；模板通过只能证明字段齐全，不能冒充合并授权。

十二类一票否决条件

出现任务意图不清、无法解释的越界文件、秘密或个人数据泄露、跨租户访问、未授权生产写入、不可逆迁移无方案、必需检查未针对最新提交、关键测试被跳过、来源不明依赖、高危扫描未处置、回滚不可执行或批准者存在利益冲突时停止合并。阻断项应写清复现与修复要求，不用模糊的‘再看看’把责任推给下一位审查者。

什么时候可以接受剩余风险

不是所有警告都必须归零，但接受必须显式：描述风险、影响面、发生条件、现有控制、观察指标、负责人、期限和补救任务。低风险格式问题可后续处理，高风险权限、数据和迁移问题通常不能用时间压力豁免。风险接受记录关联具体提交，后续推送需重新评估。没有人愿意署名负责的风险，不应被系统默认接受。

最终合并判定

只有任务合同完成、范围可解释、当前提交的必需检查通过、人工审查覆盖对应风险、部署与回滚可执行、证据已归档时，才把 decision 设为 approved。任何关键材料缺失则保持 pending 或 rejected。合并后按计划观察并在异常时回滚；认证不是永久标签，依赖、平台、数据和业务变化都可能要求复核。本文给出流程，不替代你的仓库规则、安全评审和上线责任。

用差异预算控制失焦

在任务合同中给出预计文件、模块和改动规模，超过预算时不自动失败，但必须解释并重新批准。预算的作用是暴露需求蔓延和智能体顺手重构，不是鼓励为了行数隐藏必要测试。生成代码、快照和锁文件可单独统计；真正需要关注的是新增行为和风险半径。若一个小缺陷最终触及认证、数据库、基础设施和十多个模块，先停下来重做设计或拆分，而不是继续让智能体补更多说明。

从用户故事反推可观察结果

把‘实现某功能’改写为用户或系统能观察的输入、动作、结果与错误。例如权限修复不能只说增加校验，而要写明未授权身份得到什么状态、授权身份仍能完成什么、日志留下哪些字段、资源状态是否改变。测试和人工验收都映射到这些结果，避免仅检查内部函数被调用。可观察结果还应覆盖旧客户端、慢网络和中断恢复，使审查者能够判断变更是否真正满足需求。

用不变量审查比逐行猜测更可靠

先列出任何实现都必须保持的规则：跨租户不可读、余额不能为负、一次事件只产生一个副作用、删除后不得继续对外可见、未批准代码不能部署。然后沿数据流、状态机和异常路径验证这些规则。逐行阅读仍重要，但没有不变量时容易被局部正确迷惑。把关键不变量做成测试或运行时断言，并为断言失败设置明确报警；不要让智能体自行删除它认为‘多余’的保护。

对审查意见执行闭环

每条阻断意见应包含位置、风险、复现或证据要求和通过条件。智能体修复后，不只看回复文字，重新检查差异、运行受影响命令并确认没有把问题转移到别处。相互依赖的意见按主题汇总，避免连续小补丁制造新的冲突。所有阻断关闭后仍要重新查看总体文件列表和提交 SHA，因为最后一次修复可能新增未审查内容。评论数量归零不代表风险归零，只有证据闭环才算完成。

审查工作流文件本身

GitHub Actions 或其他 CI 文件决定哪些证据会出现，应像生产代码一样审查。核对事件、分支、路径、权限、秘密、第三方 Action、脚本插值、缓存、产物和环境保护。注意条件表达式导致关键 job 被 skipped 却仍让聚合检查成功，也注意并发取消让旧运行覆盖新状态。修改门禁的 PR 不应仅靠被修改后的门禁自证，需要独立管理员或预先存在的策略验证，并限制智能体修改规则的权限。

验证测试数据和夹具没有作弊

智能体可能为了通过测试修改夹具、默认账户、时间、随机种子或期望文件。比较测试数据变更是否符合真实业务，确保没有把危险输入删掉、把预期错误改成成功或降低阈值。对生成快照抽查关键字段，不批准成百上千个无法阅读的更新。需要迁移测试数据时保留旧样本和版本说明，让回归仍能覆盖历史状态，而不是只适配新实现的理想输入。

处理外部服务与不可重复依赖

第三方 API、时钟、网络、模型和云资源会让测试波动。核心业务使用固定响应夹具验证确定性逻辑，再用少量受控集成检查当前契约；两者要明确区分。集成失败不能被自动重跑到绿色后忽略，应记录首次失败和重试原因。涉及付费或不可逆调用时使用沙箱、最小配额与幂等键。无法在审查期访问外部服务时，保留阻断或缩小发布范围，不以模拟结果冒充真实端到端通过。

定义 flaky 测试的处置

偶发失败说明证据不稳定，不能靠重复运行直到绿色。记录失败频率、种子、环境和最近变化，先判断是产品竞争条件、资源瓶颈还是测试缺陷。关键门禁中的 flaky 测试应修复或用等价稳定检查替换；暂时隔离必须有负责人、到期和独立风险控制。智能体若自动增加重试、延长等待或删除断言，可能只是掩盖问题。合并决定应看到所有尝试，不只看最后一次成功。

审查异常情况下的资源释放

文件、锁、事务、连接、临时目录、子进程和云资源在成功与失败路径都要释放。制造超时、取消、进程终止和部分初始化，检查 finally、上下文管理和补偿动作。泄漏在小测试里可能不可见，上线后会积累成容量事故。不要因为运行一次没有报错就认为资源安全；用循环、并发和故障注入观察句柄、连接池、磁盘与队列。回滚还应清理新版本遗留的临时状态。

审查权限最小化而非只看功能成功

新功能能完成动作，只说明权限足够，不说明权限没有过大。列出运行身份、令牌范围、云角色、数据库权限和文件访问，把读写资源限制到任务需要。测试不允许的动作确实失败，并确认失败不会回退到更高权限身份。临时管理员凭据只用于人工受控迁移，不放入智能体环境、CI 变量或日志。权限变更要能撤销并有使用审计，避免一次 PR 永久扩大攻击面。

审查网络出口和下载

新增 HTTP 请求、包下载、遥测、Webhook 或模型调用会改变数据边界。核对域名、协议、证书验证、重定向、代理、超时、响应大小和内容类型，限制可访问地址，防止服务端请求伪造与内网探测。下载内容在解析或执行前验证来源、摘要和格式，并隔离处理。测试恶意重定向、超大响应、压缩炸弹和慢连接。没有网络变更说明但依赖安装脚本访问外部域名，也应纳入审查。

审查命令与路径拼接

智能体容易用字符串拼接 shell、文件路径或 SQL。优先使用参数化 API 和字面路径，测试空格、引号、Unicode、父目录、绝对路径和特殊设备名。工作目录必须明确，删除、移动和覆盖前解析并验证目标仍在允许根目录。用户输入、分支名、文件名和 PR 标题都可能进入命令，不能因来源是开发者就视为可信。日志展示命令时避免同时泄露令牌和敏感参数。

审查序列化和反序列化

对 JSON、YAML、pickle、对象存储和消息协议，明确 schema、版本、大小、未知字段和默认值。不要对不可信输入使用可执行反序列化，也不要静默接受类型漂移。测试旧数据、新字段、缺字段、重复键、深层嵌套和畸形内容。写入前验证语义与权限，读取失败要进入可恢复路径。智能体生成的宽松解析可能短期兼容，却把错误推到更危险的下游；严格程度应由业务契约决定。

审查加密与秘密处理

禁止让智能体自行设计加密算法或把编码当加密。使用经过维护的库和组织批准的密钥管理，记录算法、密钥用途、轮换、随机数和失败处理。秘密不写入代码、示例、测试快照、构建产物、浏览器包或错误日志；扫描历史和生成文件。认证比较避免时序泄漏，令牌设置最小范围与短期有效。若 PR 暴露了真实秘密，删除文本不足以补救，应立即吊销、轮换并调查使用记录。

审查可访问性和安全提示

涉及批准、删除、支付、授权或数据分享的界面必须让用户理解对象、后果与取消路径。按钮文字、焦点、错误提示和确认不能仅依赖颜色或图标，读屏器可获得相同信息。智能体可能生成视觉漂亮但误导的默认选项，或把危险动作放在常用路径。用键盘、390px、缩放和读屏流程检查，并验证服务端仍强制权限；可访问性提示不能替代真正的安全控制。

建立审查证据的保存期限

CI 日志、检查和外部链接可能过期，GitHub 官方也对检查数据有保留边界。对高风险变更归档任务合同、差异摘要、提交 SHA、关键命令回执、审批、发布版本、指标和回滚演练，避免只保存一个会失效的 URL。证据仓库控制访问并做最小化，不复制完整客户数据。保留期按法规、合同和事故需要设定，到期安全删除；长期保存并不自动提高可信度。

审查版本和发布身份

构建产物必须能追溯到已审查提交，记录源 SHA、构建器、依赖锁、制品摘要和签名。不要在审批后从可变分支重新构建未知内容，也不要让同名标签覆盖旧制品。部署系统核对摘要而非仅核对版本字符串，回滚目标同样需要可验证。若生产版本无法映射到 PR、提交和构建回执，观察指标再漂亮也不能证明运行的是已批准代码，应停止扩大并先恢复可追溯链。

审查配置默认值与环境差异

开发、测试、预发布和生产的开关、权限、区域、数据库、队列与外部服务可能不同。列出变更读取的每个配置、默认值、缺失行为和热更新边界，禁止因测试环境有安全值就假设生产相同。用只读方式核对生产配置 schema，不把秘密复制到 PR。配置服务不可用或返回旧值时要有安全默认和报警；部署回执保存最终生效版本，而不是只保存提交中的配置文件。

审查成本与容量失控

新增模型调用、重试、并发、日志、存储、扫描和第三方 API 都可能改变成本。用代表性任务估算请求数、数据量和失败放大，设置配额、并发、超时和停止线。成本下降不能靠关闭必要验证，成本上升也不能只用模型估算解释。灰度期按成功任务统计资源，并观察队列、连接池、磁盘和供应商限额。达到阈值时应自动降级或暂停，而不是等月底账单才发现。

审查事故与支持准备

上线前让值班和支持人员知道变化、症状、查询方式、临时缓解和升级联系人。运行手册包含版本识别、关键指标、日志入口、停用开关、回滚和用户沟通模板，并在非生产环境走一次。智能体可以起草手册，但负责人要核对命令和权限。若故障只能由原作者在个人环境诊断，说明交付未完成；可维护性和恢复能力与功能实现同样属于 PR 验收。

完成一次反向验收

在准备合并时，假设补丁已经造成事故，反问现有证据能否定位版本、影响用户、错误路径和恢复动作。让未参与生成的人仅凭任务合同、回执与运行手册尝试复现和回滚；若仍必须询问智能体当时‘在想什么’，说明关键事实没有进入可维护资产。反向验收不是悲观演练，而是验证交付能否脱离生成会话长期运转，也能发现描述和实际差异之间的最后缺口。

十二个常见失败与恢复分支

官方证据图与使用边界

当前一手来源

• GitHub Status checks
• GitHub Pull requests
• GitHub rulesets 可用规则
• GitHub 安全使用 pull_request_target
• OpenAI Codex 开发者资料
• NIST Secure Software Development Framework

继续完成相邻任务

• 用Claude Code 权限指南收紧编码工具边界。
• 用AI 编程工具评测方法建立任务集。
• 用模型 API 故障恢复指南设计重试与降级。
• 用企业 Agent 权限与验收指南补充沙箱控制。

时效与数据边界

本文于 2026 年 10 月 1 日核验。GitHub 规则、Actions 事件、安全默认值、Codex 能力和 NIST 资料会变化，实施前应重开对应一手页面。本文没有对特定商业模型做性能评测，也没有运行用户仓库。Bing Webmaster、Search Console、排名、曝光、点击、CTR、访问、用户与转化均未取数；IndexNow、sitemap、爬虫请求与页面可访问性不能替代这些指标。