当 AI 编程智能体可以自主读取需求、修改代码、运行测试并提交合并请求时，团队面对的已不只是“代码是谁写的”，而是“谁授权、谁复核、谁批准、谁承担上线风险”。🤖 如果仍沿用传统的个人提交追责方式，要么把责任简单推给工具使用者，要么迫使评审者逐行检查全部代码，最终既不公平，也会让效率优势被高昂的复核成本抵消。
一、先明确：智能体不能成为最终责任主体
AI 智能体可以成为代码生成者、修改执行者和流程参与者，但不应被视为能够承担组织责任的主体。缺陷发生后，团队不能以“这是 AI 写的”为结论，而应沿着授权链、控制链和决策链追溯：谁定义任务边界，谁配置权限，谁提供上下文，谁批准合并，谁决定发布。
因此，合并请求中应同时记录机器贡献与人工责任。例如标注智能体名称及版本、任务发起人、提示或需求来源、修改范围、自动测试结果、人工复核人和最终批准人。这样做不是为了制造更多表单，而是为了避免事故发生后只能依赖聊天记录和个人回忆还原过程。🧾
二、缺陷追责应按照原因分层
第一类是任务定义责任。如果需求本身存在歧义、验收标准缺失，或者发起人要求智能体修改其无权判断的业务规则，那么主要问题在任务设计，而不能只归因于生成代码的模型。
第二类是智能体治理责任。如果平台给予智能体过大的仓库权限、允许其绕过分支保护、可以直接接触生产凭据，或者没有保留操作日志，那么责任重点应落在工具管理者、仓库管理员及相关治理机制上。OWASP 的 AI Agent 安全建议强调最小权限、敏感操作授权和审计记录，可作为权限设计参考。[1]
第三类是人工复核责任。评审者应对制度明确要求其检查的内容负责，例如核心逻辑、安全边界、数据迁移和兼容性，而不是对所有潜在缺陷承担无限责任。若合并规则只要求普通评审，却在事故后要求评审者承担安全专家级责任，说明制度本身存在错配。
第四类是流程与发布责任。自动测试未覆盖、流水线告警被忽略、灰度策略缺失、回滚机制失效，都可能放大一个普通代码缺陷。此时应开展根因分析，把“缺陷如何产生”和“缺陷为何进入生产环境”分开处理，避免把系统性问题归咎于某一个人。
三、根据变更风险确定复核强度
人工复核成本不宜按代码行数简单计算。智能体可能用十几行代码改变权限判断，也可能批量生成数百行低风险测试。更合理的做法是根据影响范围、可逆性、敏感程度和验证难度给合并请求分级。⚖️
- 低风险：文档、注释、格式调整、明确的测试补充，可采用自动检查加抽样复核。
- 中风险：一般业务逻辑、内部接口和依赖升级，应由模块负责人检查关键路径及测试有效性。
- 高风险：身份认证、权限控制、支付、隐私数据、数据库结构、基础设施和发布配置，应要求领域负责人或安全人员复核。
- 极高风险：不可逆数据操作、生产环境权限变更、跨系统批量执行，应限制智能体自主提交能力，并设置双人批准或人工执行。
仓库可以通过 CODEOWNERS 自动请求相关代码负责人评审，并结合受保护分支要求负责人批准后才能合并，具体能力可参考 GitHub 官方文档。但必须注意，指定代码所有者只是建立责任路由，不能替代测试、安全扫描和发布控制。
四、把人工成本算清楚，而不是一味增加审批
复核成本至少包括四部分：理解任务和上下文的时间、检查差异和关键逻辑的时间、补充或重跑验证的时间，以及发现问题后的沟通和返工时间。团队可以在合并请求中记录预计风险等级、实际评审时长、退回原因和生产缺陷结果，用持续积累的内部数据调整策略，而不必套用无法验证的行业平均值。📊
更值得观察的指标不是“AI 生成了多少代码”，而是每个有效合并请求需要多少人工分钟、首次评审通过率、缺陷逃逸情况以及返工次数。如果智能体显著提高提交数量，却让评审队列持续变长，说明瓶颈只是从编码环节转移到了审核环节。
降低复核成本也不能依靠减少检查项目，而应提高证据质量。智能体提交合并请求时，可强制附带变更摘要、受影响模块、风险说明、测试清单、关键设计选择和回滚方法。评审者应验证这些内容是否真实，而不是重新从零推断所有修改意图。NIST 的安全软件开发框架主张把安全实践整合进软件开发生命周期，并通过统一实践减少漏洞、控制影响和防止问题复发，可作为流程建设依据。[2]
五、建立可执行的责任矩阵
- 任务发起人：对目标、输入材料、验收标准和智能体使用范围负责。
- 仓库或平台管理员：对账号权限、分支规则、日志留存和工具接入安全负责。
- 代码复核人：对分配给自己的检查项及批准决定负责。
- 发布负责人：对发布窗口、灰度验证、监控和回滚准备负责。
- 团队负责人：对风险分级是否合理、人员能力是否匹配以及流程是否可执行负责。
追责的目标不应是找到一个为所有损失买单的人，而应是识别哪一道控制失效，并让同类缺陷更难再次发生。🔍
总结
AI 编程智能体自主提交合并请求之后，责任边界应从“作者负责制”升级为“授权、生成、复核、合并和发布”的全链路责任制。人工复核成本则应依据风险等级、验证难度和影响范围配置，而不是对所有机器生成代码进行同等强度的逐行审查。只有保留完整证据、明确角色边界、实行分级审批，并持续用内部缺陷与评审数据校准规则，团队才能在提升开发效率的同时，避免责任模糊和审核成本失控。
