祝融说。

风险不是"会不会发生"的问题，而是"什么时候发生"的问题。关键是知道风险在哪里，以及如何应对。

6.1 风险全景

AI 编码的风险不是"一个风险"，而是"一组风险"。不同风险的影响程度和发生概率不同，需要区别对待。以下是一个快速的概览——每个风险的具体内容在后续各节展开。

6.2 质量风险

风险描述

AI 生成的代码在功能上可能正确，但在代码质量上存在隐患——代码风格不一致、错误处理不完善、性能问题、可维护性差。为什么这是"高影响中概率"的风险？因为质量风险不会立刻爆发，但会持续累积——今天一段代码风格不一致，明天一个错误处理不完善，日积月累，代码库就会变成难以维护的"遗产"。

预防措施

1. 建立验收体系（第四章已详述）
2. 制定编码规范，让 AI 遵循统一的风格
3. 使用自动化工具（Lint、格式化、类型检查）

应急预案

问题： 发现已提交的 AI 代码存在质量问题。 应对：

1. 评估影响范围
2. 如果是局部问题，修复后重新提交
3. 如果是系统性问题，回滚后重建
4. 分析原因：是指令不够清晰，还是验收不严格？

6.3 安全风险

风险描述

AI 编码工具可能生成存在安全漏洞的代码。为什么这是"高影响低概率"的风险？因为安全漏洞一旦发生，后果可能是灾难性的——数据泄露、系统被入侵、合规处罚。但发生的概率相对较低，因为 AI 的训练数据中包含了大量"常见的安全实践"（比如参数化查询、输入转义）。不过，AI 也可能"回忆"了训练数据中不安全代码的例子。

常见的 AI 生成安全漏洞包括：

预防措施

1. 安全审查纳入验收流程（验收必须包含安全检查）
2. 建立安全编码规范，在指令中明确安全要求
3. 使用安全扫描工具自动化检测常见漏洞
4. 敏感操作人工审查：涉及支付、用户数据、认证的功能必须人工审查

安全审查清单

安全审查清单（验收阶段使用）：
- [ ] 用户输入是否经过验证或转义？
- [ ] 数据库查询是否使用参数化查询？
- [ ] API 接口是否有权限控制？
- [ ] 是否返回了不应暴露的数据字段？
- [ ] 是否有硬编码的密钥或凭证？
- [ ] 认证逻辑是否完整？
- [ ] 第三方库是否有已知漏洞？

应急预案

问题： 发现 AI 生成的代码存在安全漏洞。 应对：

1. 立即修复漏洞（优先级最高）
2. 检查其他功能是否也存在类似问题
3. 更新验收清单，增加该安全项的检查
4. 如果是系统性安全问题，暂停该项目的 AI 编码，重新培训

6.4 架构风险

风险描述

AI 在实现功能时，可能偏离架构设计。为什么这是"中影响高概率"的风险？因为架构偏移是"日常的"——AI 几乎每次生成代码都可能产生微小的架构偏离（比如放错文件位置、用错命名风格）。单个偏离影响不大，但累积起来会逐步侵蚀代码库的结构。而且架构偏移是隐性的——代码能跑通、功能正确，你很难第一时间发现。

预防措施

1. 蓝图必须包含清晰的架构约定（目录结构、技术栈、命名规范）
2. 验收必须检查架构合规性
3. 定期架构审计

应急预案

问题： 发现代码存在架构偏移。 应对：

1. 评估偏移的严重程度
2. 轻度偏移：记录偏移，在后续迭代中修正
3. 重度偏移（篡改地基、体积失控）：回滚后重建
4. 更新蓝图，明确禁止的操作

6.5 团队风险

团队风险是管理者最容易忽视的——因为它不是"技术问题"，而是"人的问题"。技术问题有明确的解决方案（加验收、加门禁、加工具），但人的问题需要持续的关注和管理。

风险一：技能退化

开发者长期依赖 AI 写代码，可能失去独立编码和调试的能力。

预防措施：

• 要求开发者理解 AI 生成的代码才能验收
• 定期安排"无 AI 日"或"无 AI 功能"
• 鼓励开发者阅读 AI 生成的代码，提出改进意见

监测信号：

• 开发者遇到简单问题时先问 AI 而不是自己思考
• 开发者无法解释 AI 生成的代码
• 代码审查中发现开发者不理解自己提交的代码

风险二：AI 依赖

开发者在决策时过度依赖 AI，失去独立判断能力。

预防措施：

• 明确"AI 给建议，人做决策"的原则
• 架构决策必须由人主导，AI 只提供参考
• 鼓励质疑 AI 的建议

监测信号：

• AI 推荐的技术方案被不加分析地采纳
• 开发者在技术讨论中引用 AI 作为权威
• 缺乏独立思考的迹象

风险三：知识断层

AI 写了核心代码，但团队没有人理解这部分代码。

预防措施：

• 核心代码必须有人理解——验收者就是"负责人"
• 定期进行代码走读，由开发者讲解 AI 生成的代码
• 新成员 onboarding 时，需要独立完成一个小功能（不依赖 AI）

6.6 合规风险

风险描述

合规风险是最容易被忽视的。AI 生成的代码可能包含与开源许可证冲突的代码，AI 可能"回忆"了受版权保护的代码，AI 服务可能处理了敏感数据。这些风险一旦发生，可能带来法律和合规问题。

预防措施

1. 明确 AI 编码工具的数据处理政策——代码是否会被用于训练？
2. 敏感项目不使用 AI 编码——或使用本地部署的 AI 模型
3. 代码审查时注意许可证合规性
4. 不要将敏感数据（密码、密钥、客户信息）输入到 AI 工具中

6.7 成本风险

风险描述

AI 编码工具的 API 调用可能产生显著成本，尤其是大规模使用时。成本风险是"低影响中概率"的——因为成本是可预测、可控制的，不像安全漏洞那样不可控。但如果不加管理，月度 API 费用可能超出预算。

成本控制建议

1. 按需使用：不是所有功能都需要 AI 编码
2. 使用缓存：相同或类似的指令可以复用结果
3. 监控用量：跟踪 API 调用量和成本
4. 本地部署：对于大规模使用，考虑本地部署的 AI 模型

成本估算

成本估算示例（以 Claude Code 为例，基于典型 API 定价）：
- 一个小型功能（1-2 个文件）：约 1000 tokens
- 一个中型功能（3-5 个文件）：约 5000 tokens
- 一个大型功能（5-10 个文件）：约 20000 tokens

月度估算（10 人团队，每人每天 5 次调用）：
- 日均调用：50 次
- 月均调用：1100 次
- 月均 tokens：约 500 万
- 月均成本：根据实际 API 定价计算

6.8 风险管理流程

识别风险 → 评估风险 → 制定预案 → 执行预案 → 复盘改进

1. 识别风险：定期识别新的风险（每季度一次）
2. 评估风险：评估影响程度和发生概率
3. 制定预案：为高影响风险制定预防措施和应急预案
4. 执行预案：在日常工作中执行预防措施
5. 复盘改进：风险发生后复盘，更新风险管理方案

本章小结

AI 编码的六大风险——质量、安全、架构、团队、合规、成本——每个风险的影响程度和发生概率不同，需要区别对待。安全风险和架构风险是最需要关注的：安全风险虽然概率低但后果严重，架构风险虽然影响中等但概率高。团队风险（技能退化、AI 依赖、知识断层）是管理者最容易忽视但影响深远的。建立"识别-评估-预案-执行-复盘"的风险管理流程，让风险可控而不是靠运气。下一章，我们学习如何培训团队。