如何对 AI 生成的代码负责
问题
团队大量使用 AI 编程助手后，如何在提升效率的同时控制正确性、安全、隐私、许可证和维护风险？当 AI 生成代码导致线上问题时，责任应该如何界定？
我的原则是：AI 可以生成建议，但不能转移工程责任。提交代码的人和批准变更的团队仍对结果负责。
治理不应只靠禁止，而应按风险分级：
- 低风险样板代码可以正常 Review 和测试；
- 核心业务、认证、支付、加密、基础设施等高风险代码需要领域负责人和安全审查；
- 密钥、个人数据、未公开源码不能输入未经批准的外部模型；
- 所有 AI 代码都经过同样的编译、测试、Lint、SAST、依赖和许可证检查；
- 引入的新依赖、API 和配置必须回到官方来源验证；
- 保留必要的工具、模型和人工审查记录，但不上传敏感 Prompt；
- 评估效率时同时看返工、缺陷、安全和认知负荷，不能只看生成速度。
一、责任原则
AI 生成内容不具备责任主体，组织仍需明确：
| 角色 | 责任 |
|---|---|
| 提交者 | 理解代码、验证行为、说明风险和测试 |
| Reviewer | 检查设计、边界、安全与可维护性 |
| 模块负责人 | 对领域约束、依赖和长期维护负责 |
| 安全/合规 | 定义数据、模型和高风险代码政策 |
| 平台团队 | 提供批准工具、审计、扫描和默认防线 |
| 管理者 | 不用不合理产能目标诱导绕过质量流程 |
“这是 AI 写的”不能成为事故免责理由；同样，也不应把所有问题归咎于某个开发者，而忽略缺少测试、Review 和工具防线的系统原因。
二、风险地图
1. 输入风险
- 把生产日志、用户信息、访问 Token 或私钥发给外部模型；
- 上传公司未公开算法、合同代码或客户数据；
- Agent 自动读取仓库中的恶意指令、Issue 或依赖文档；
- 使用个人账号和未批准插件，绕过企业数据策略。
2. 输出风险
- 使用不存在、过时或行为错误的 API；
- 生成表面通过测试但边界错误的代码；
- 引入名称相似的恶意依赖或不必要依赖；
- 复制来源和许可证不清晰的实现；
- 生成难以维护的大段重复代码；
- 把安全校验只放在前端，或者使用自制加密算法。
三、按变更风险分级
| 等级 | 示例 | 最低要求 |
|---|---|---|
| L1 低风险 | 测试样板、文档、局部重命名 | 常规 Review、CI |
| L2 中风险 | 普通业务逻辑、组件、数据转换 | 单元/集成测试、依赖扫描 |
| L3 高风险 | 认证、权限、支付、迁移、并发 | 领域负责人 Review、安全检查、回滚方案 |
| L4 严格限制 | 密钥系统、核心加密、生产自动操作 | 批准工具、双人审查、隔离验证或禁止生成 |
风险由代码所在边界和潜在损失决定，不由生成代码的行数决定。
四、输入数据治理
团队需要明确“可以输入什么”：
- 使用企业批准的模型、账号、数据保留和训练策略；
- IDE 在发送上下文前做 Secret 和个人信息检测；
- 默认排除
.env、密钥、生产数据、证书和敏感目录； - 用脱敏 Schema、伪造样本和最小代码片段替代真实数据；
- Agent 工具按最小权限授权，读取和执行分开审批；
- 对外部仓库、网页和 Issue 内容按不可信输入处理。
“请不要泄露密钥”不能替代访问控制。模型根本不应获得无关密钥和生产权限，敏感操作需要工具侧校验、确认和审计。
五、输出验证流水线
开发者提交前清单
- 能否用自己的话解释代码、状态和失败路径；
- API、版本和配置是否从官方文档确认；
- 是否新增依赖，包名、维护者、完整性和许可证是否可信；
- 是否覆盖空值、并发、重试、权限和资源清理；
- 是否复制了已有能力，或者破坏模块边界；
- 测试是否验证行为，而不是照着实现复述；
- 是否准备监控、灰度和回滚。
为什么测试也需要审查
如果代码和测试由同一个 Prompt 同时生成，它们可能共享同一个错误假设。关键逻辑应增加独立的规格、属性测试、对照实现或人工设计的反例。
六、依赖与供应链
AI 很容易推荐不必要、过时或名称错误的包。新增依赖至少检查：
- 包是否存在于官方 Registry，仓库和发布者是否匹配；
- 下载并不是唯一可信信号，需查看维护、签名和漏洞；
- Lockfile 是否只出现预期变化；
- 是否能用平台 API 或现有依赖完成；
- 许可证是否满足项目分发方式；
- 生成 SBOM，并持续监控后续漏洞。
安装命令不应由高权限 Agent 无确认执行；依赖安装和脚本执行要显示目标与影响。
七、Review 方式需要变化
AI 提升了代码产生速度，也可能把瓶颈转移到理解和 Review：
- PR 控制体积，按可独立验证的意图拆分；
- 描述中写清需求、约束、AI 使用范围和人工验证；
- Reviewer 从逐行挑错转向契约、边界、状态和失败模式；
- 高风险变更要求演示测试、迁移和回滚；
- 大段生成代码先做设计评审，避免在实现后讨论方向。
不要强制保留完整 Prompt 和敏感上下文；需要审计时记录工具、模型类别、生成范围和验证证据即可。
八、Agent 自动修改代码的权限模型
推荐把能力分层：
| 能力 | 默认策略 |
|---|---|
| 读取仓库 | 允许，但排除 Secret 和敏感路径 |
| 修改工作区 | 限定分支或沙箱，可审查 Diff |
| 运行测试 | 允许受限命令和资源 |
| 安装依赖 | 需要确认和来源检查 |
| 访问网络 | 域名和用途受控 |
| 写生产配置 | 禁止默认直达，必须审批 |
| 部署/删除/迁移 | 人工确认、最小权限、可回滚 |
工具调用参数必须经过独立校验，不能因为模型说“这是安全的”就跳过权限检查。
九、如何衡量 AI 编程的真实收益
结果指标：
- 从需求就绪到生产的前置时间；
- 开发者完成常见任务的成功率；
- 新人上手时间和文档可发现性；
- 重复工作量和等待时间。
护栏指标：
- AI 相关变更的返工、回滚和缺陷；
- 安全、许可证和依赖风险；
- PR 体积、Review 等待和 Reviewer 负担；
- 开发者是否真正理解代码；
- 工具成本、数据暴露和供应商锁定。
只统计接受了多少补全或生成了多少代码，会鼓励数量而非价值。
十、事故处理
AI 代码引发事故时仍按正常流程：止血、恢复、证据保全、根因分析和无责复盘。根因可能同时包括：
- 生成内容错误；
- 提交者未验证；
- Review 缺少领域知识；
- 测试和扫描未覆盖；
- 权限过大或工具默认不安全；
- 进度压力导致绕过流程。
改进重点应是增加系统防线，而不是简单写一条“禁止使用 AI”。
常见面试问题
Q1: AI 生成代码的 Bug 应该由谁负责？
答案：提交和批准变更的人及其团队仍负责结果。组织也要为工具选择、权限、测试和审查机制负责，不能把系统缺陷全部归咎于个人。
Q2: 是否应该禁止在核心代码中使用 AI？
答案：应按风险控制而非一刀切。高风险模块可以限制生成、要求批准模型和双人审查；即使禁止生成，也不代表可以减少正常的测试与安全流程。
Q3: 如何防止 AI 推荐恶意依赖？
答案：安装前验证官方 Registry、仓库和发布者，检查名称、维护、漏洞和许可证；限制 Agent 安装权限，审查 Lockfile，并使用 SCA 和 SBOM 持续治理。
Q4: AI 生成的测试可靠吗？
答案：可以提高覆盖，但可能和实现共享同一错误假设。关键逻辑需要独立规格、人工反例、属性测试或对照实现，不能用“测试通过”代替需求验证。
Q5: 记录所有 Prompt 是否最利于审计？
答案：不一定，Prompt 可能包含源码和敏感信息。应遵循数据最小化，记录工具、模型、变更范围、审批和验证证据；只有确有合规需求时才保留脱敏 Prompt。
Q6: 如何判断 AI 是否真的提升了效率？
答案：比较端到端前置时间、任务成功率和开发者体验，同时观察返工、缺陷、Review 负担和成本。局部编码变快但整体等待或返工增加，不算效能提升。