祝融说。

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

6.1 风险全景

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

6.2 质量风险

风险描述

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

预防措施

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

应急预案

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

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

6.3 安全风险

风险描述

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

常见漏洞类型（覆盖率类估计见 OWASP Top 10，此处不给出精确占比）：

• 信息泄露、权限缺失、输入验证不足、硬编码凭证——详见本章安全审查清单与第二册第五章。

预防措施

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 模型

成本估算

成本量级示例（计算示例，非实测数据；实际成本以你所用工具的当前定价为准）：
- 一个小型功能（1-2 个文件）：数千 tokens
- 一个中型功能（3-5 个文件）：数万 tokens
- 一个大型功能（5-10 个文件）：数万到十余万 tokens

月度估算（10 人团队，每人每天 5 次调用）：
- 日均调用：50 次
- 月均调用：约 1100 次
- 月均 tokens：视任务规模而定，量级在数百万
- 月均成本：根据实际 API 定价计算

6.8 风险管理流程

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

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

本章小结

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