# 第 26 章 风险控制与效率度量

## 本章目标

- **O1** 能够把“质量指标”拆解为“交付成本”与“采用证据”两个可比较分支（产物：风险与效率指标树）
  - 证据: 风险与效率指标树从“质量指标”分支到“交付成本”和“采用证据”并标明层级
- **O2** 能够构造风险与效率指标树，为每个指标写出基线、趋势和取舍（产物：风险与效率指标树）
  - 证据: 风险与效率指标树为每个叶节点记录基线、当前值、趋势和数据来源
- **O3** 能够用基线、趋势和取舍共同解释质量、成本与采用指标（产物：风险与效率指标树）
  - 证据: 产物为质量、成本和采用指标分别记录基线、趋势、来源及取舍

## 学习路径

- **初学者**: 本章迁移任务是：能够用基线、趋势和取舍共同解释质量、成本与采用指标。先按图中的“指标层级”关系完成风险与效率指标树的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够用基线、趋势和取舍共同解释质量、成本与采用指标。提交风险与效率指标树后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: 风险与效率指标树
- **图解类型**: metric-tree
- **关系语义**: 根指标向下分成两个互补分支，各叶节点分别记录基线、趋势和取舍；分支不是停止或继续门禁。
- **核心概念**: 质量指标 · 交付成本 · 采用证据

![第 26 章风险与效率指标树教学图](/learning/diagrams/zh/chapter-26.svg)

沿层级分支阅读风险与效率指标树，分别比较质量、成本与采用证据，不用单一指标代替整体判断。

图把“质量指标”置于根节点，并向下分支到“交付成本”和“采用证据”。分支表示指标层级与互补视角，不表示先后流程或放行门禁；每个叶节点都要独立记录基线、趋势、数据来源与取舍。

> **公开课程改编版。**正文依据内部教材整理，保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学，不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限；重试次数不自动触发恢复；恢复须先保护工作并确认目标、共享状态和外部数据影响。

## 课程讲解

### 26.1 七大风险全景：质量、安全、架构、团队、合规、成本、模型行为

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

AI 编码的风险不是"一个风险"，而是"一组风险"。不同风险的影响程度和发生概率不同，需要区别对待：

| 风险类别 | 风险描述 | 影响程度 | 发生概率 |
|---------|---------|---------|---------|
| 质量风险 | AI 生成的代码质量不可控 | 高 | 中 |
| 安全风险 | AI 代码引入安全漏洞 | 高 | 中 |
| 架构风险 | 代码偏离架构设计 | 中 | 高 |
| 团队风险 | 团队技能退化或依赖 AI | 中 | 中 |
| 合规风险 | AI 代码涉及版权或合规问题 | 高 | 低 |
| 成本风险 | API 调用成本超出预算 | 低 | 中 |
| 模型行为风险 | 幻觉、提示注入、敏感数据外泄到模型方、token 成本失控 | 高 | 中 |

质量风险（高影响中概率）：AI 代码在功能上可能正确，但存在风格不一致、错误处理不完善、性能问题、可维护性差。质量风险不会立刻爆发但会持续累积。预防：建立验收体系、制定编码规范、使用自动化工具。应急：评估影响范围 → 局部问题修复重提 / 系统性问题回滚重建 → 分析是指令不清晰还是验收不严格。

安全风险（高影响中概率）：AI 代码可能包含安全漏洞。一旦发生，后果可能是灾难性的（数据泄露、系统被入侵、合规处罚）。发生概率定为"中"而非"低"——AI 生成代码的安全漏洞概率不容低估（注入类缺陷、过时依赖、被掩盖的边界条件在 AI 代码中并不罕见），这正是第 24 章部署门要求全面安全审查的力度依据。预防：安全审查纳入验收流程、建立安全编码规范、使用安全扫描工具、敏感操作（支付、用户数据、认证）必须人工审查。应急：立即修复（最高优先级）→ 检查其他功能是否类似 → 更新验收清单 → 系统性安全问题则暂停该项目 AI 编码、重新培训。

架构风险（中影响高概率）：架构偏移是"日常的"——AI 几乎每次生成代码都可能产生微小的架构偏离，单个偏离影响不大，但累积起来会逐步侵蚀代码库结构，而且隐性——代码能跑通、功能正确，很难第一时间发现。预防：蓝图包含清晰架构约定、验收检查架构合规、定期架构审计。应急：评估严重程度 → 轻度偏移记录后迭代修正 / 重度偏移（篡改地基、体积失控）回滚重建 → 更新蓝图明确禁止操作。

团队风险（中影响中概率）：这是管理者最容易忽视的，因为它是"人的问题"而非"技术问题"。三种子风险——技能退化（预防：要求开发者理解 AI 代码才能验收、定期安排"无 AI 日"；监测信号：遇到简单问题先问 AI 而不是自己思考）、AI 依赖（预防：明确"AI 给建议、人做决策"、架构决策必须人主导；监测信号：AI 推荐方案被不加分析地采纳）、知识断层（预防：核心代码必须有人理解、定期代码走读、新成员需独立完成小功能）。技术问题有明确解决方案，人的问题需要持续关注和管理。

合规风险（高影响低概率）：AI 生成的代码可能包含与开源许可证冲突的代码、可能"回忆"受版权保护的代码、AI 服务可能处理敏感数据。预防：明确 AI 工具的数据处理政策、敏感项目使用本地部署模型或不使用 AI、代码审查注意许可证合规、不要将敏感数据（密码、密钥、客户信息）输入 AI 工具。

成本风险（低影响中概率）：AI 工具的 API 调用可能产生显著成本。成本是可预测、可控制的。控制建议：按需使用（不是所有功能都需要 AI 编码）、使用缓存（相同或类似指令复用结果）、监控用量、大规模使用考虑本地部署。

模型行为风险（高影响中概率）：这是 LLM 应用特有的第四类技术风险——幻觉率失控（模型一本正经地编造事实）、提示注入（恶意输入劫持模型行为）、敏感数据外泄到模型方（把客户数据、密钥送进了第三方模型的训练或日志管道）、token 成本失控（上下文膨胀导致单次调用成本数倍于预算）。它与"成本风险"的区别在于：成本风险只是花钱，模型行为风险会直接污染交付结果。预防：用 eval 体系持续监控幻觉率（评估驱动的方法见第 21 章，Golden Set 与 LLM-as-judge 的评卷机制见第 22 章）、对外部输入做注入防护与最小权限设计、敏感数据脱敏或使用本地部署模型（与合规风险的处置原则一致）、为每次调用设置 token 预算并监控用量。应急：幻觉问题回退到上一个通过 eval 的提示词/模型版本 → 疑似注入立即下线受影响入口并审计日志 → 疑似数据外泄按安全事件最高优先级处理。

### 26.2 风险管理流程：识别 → 评估 → 预案 → 执行 → 复盘

<!-- code-example:chapter-26-E1 mode:pseudocode -->
> **示例类型：伪代码。** 伪代码，不可直接执行。它只表达判断顺序，实施时必须补齐真实接口、权限与错误处理。
```text
识别风险 → 评估风险 → 制定预案 → 执行预案 → 复盘改进
```

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

安全风险和架构风险最需要关注：安全风险概率不低且后果严重，架构风险虽然影响中等但概率高。团队风险则是影响深远的。建立"识别-评估-预案-执行-复盘"的风险管理流程，让风险可控而不是靠运气。

### 26.3 核心度量指标：效率、质量、团队、客户侧四维度

度量不是"为了给老板看数据"，而是"为了让自己更了解团队的真实状况"。度量的三个目的——证明价值、发现问题、持续改进——第一个是"对外"，后两个是"对内"。数据帮你发现流程中的瓶颈（比如验收通过率低说明指令质量有问题），也帮你持续改进（趋势分析告诉你方法论是否在发挥作用）。

度量指标不是越多越好。四个维度——效率、质量、团队、客户侧——每个维度选 2-3 个关键指标就足够。太多的指标反而会让你迷失在数据中。

效率指标：

| 指标 | 定义 | 测量方法 |
|------|------|---------|
| 交付周期 | 从需求确认到功能交付的天数 | 记录需求确认日期和功能交付日期 |
| 开发效率 | 单位时间内完成的功能点数量 | 功能点/人天 |
| AI 使用率 | 使用 AI 编码的功能占比 | AI 完成的功能/总功能 |

使用建议：交付周期是衡量 AI 编码效果的最直观指标；开发效率需要与历史数据对比，避免绝对值误导；AI 使用率不是越高越好，关键是"用得对"。

质量指标：

| 指标 | 定义 | 测量方法 |
|------|------|---------|
| 缺陷密度 | 每千行代码的缺陷数 | 缺陷数/代码行数×1000 |
| 验收通过率 | 里程碑首次验收通过的比率 | 首次通过数/总里程碑数 |
| 架构偏移率 | 存在架构偏移的功能占比 | 有偏移的功能数/总功能数 |
| 测试覆盖率 | 代码被测试覆盖的百分比 | 自动化测试报告 |

使用建议：缺陷密度应在项目稳定后（上线 1 个月）测量；验收通过率反映指令质量——通过率低说明指令不够清晰；架构偏移率是衡量 AI 编码规范性的关键指标。

团队指标：

| 指标 | 定义 | 测量方法 |
|------|------|---------|
| 技能掌握度 | 团队对方法论的掌握程度 | 定期评估（成熟度模型 L0–L4） |
| 规范遵守率 | 团队遵循编码规范的程度 | 审计结果 |
| 团队满意度 | 团队成员对 AI 编码的感受 | 匿名调查 |

使用建议：技能掌握度每季度评估一次；规范遵守率每月审计一次；团队满意度在导入期和重大变更后调查。

客户侧指标：

| 指标 | 定义 | 测量方法 |
|------|------|---------|
| Production Adoption | 功能上线后被客户真实采用的比例 | 上线后 30 天内实际使用该功能的目标用户占比 |
| 客户工作流影响 | 功能对客户流程耗时与质量的改善程度 | 客户工作流前后对比（同环节耗时、返工率/错误率） |

使用建议：前三个维度衡量的是"团队跑得快不快、稳不稳"，客户侧指标回答的是"交付的东西客户到底用没用上、工作有没有真的变好"——它是最终裁判。production adoption 长期低迷，说明交付的可能是一个"验收通过但无人使用"的功能；工作流前后对比没有改善，说明优化用错了地方。采用与业务结果的度量方法见第 26.3—26.4 节，固定 cohort 的周度采用示例见第 39.6 节；它与本节上线后 30 天口径不同，不可直接比较。第七部分评估体系检验的是模型输出质量，不能替代采用证据；客户项目各阶段应交付什么、向谁交付，见第九部分（客户项目三阶段）。

这里要区分两类指标各自的适用场景：过程合规指标（交付周期、验收通过率、架构偏移率等）度量的是团队过程是否健康，适用于内部改进——发现流程瓶颈、驱动团队持续优化；客户结果指标（production adoption、客户工作流影响）度量的是交付结果对客户产生的实际价值，适用于对客户交付结果负责的场景——客户验收、续约谈判、价值证明。用过程指标向客户证明价值是常见的错位：验收通过率再高，也不等于客户的工作流真的被改善了。内部复盘看前者，对客户交代看后者，两套指标不可互相替代。

### 26.4 度量方法：基线测量、趋势分析、对比分析

度量不是"跑一次数据、看一个数字"就完了。三种方法帮助你把数据变成洞察：

基线测量——在导入 AI 编码方法论之前，先测量基线数据。没有基线，你就无法判断"提升"还是"下降"。比如导入后交付周期是 4 天——这个数字是好是坏？如果你知道导入前是 5 天，就知道提升了 20%。基线数据示例：平均交付周期 5 天/功能、缺陷密度 15 个/千行、测试覆盖率 40%。

趋势分析——单个数据点没有意义，趋势才有意义。导入第一个月交付周期可能反而比基线更长——这不代表方法论无效，而是团队在学习阶段。第二个月开始，随着团队熟悉流程，指标应该逐步改善（下表为演示量级的示意数据，非实测记录）：

| 月度趋势 | 交付周期（天） | 缺陷密度（/千行） | 架构偏移率（%） |
|---------|--------------|-----------------|---------------|
| 第 1 月 | 4.2 | 12 | 20 |
| 第 2 月 | 3.5 | 10 | 15 |
| 第 3 月 | 2.8 | 8 | 12 |
| 第 4 月 | 2.5 | 7 | 10 |
| 趋势 | ↓下降 | ↓下降 | ↓下降 |

对比分析——有条件的话做对比实验：A 组（使用完整方法论）vs B 组（自由使用 AI、无方法论），控制变量（功能复杂度相近、开发者经验水平相近），对比两组的交付周期、缺陷密度、代码质量。如果 A 组在多个指标上显著优于 B 组，就有足够的数据支撑"方法论有效"这个结论。

### 26.5 四大度量陷阱

陷阱一：只关注效率，不关注质量。"我们的开发效率提升了 3 倍！"——但如果质量同步恶化，长期来看是灾难。设想一个合成场景（数字为演示量级）：某团队用 AI 后交付周期从 5 天缩短到 2 天，但上线后 Bug 率显著上升——效率提升的收益被质量下降的成本抵消了。正确做法：效率和质量同时度量，平衡发展。

陷阱二：对比不公正。"用了 AI 之后，功能交付从 2 周缩短到 2 天！"——但可能新功能的复杂度远低于旧功能。一个 CRUD 接口和一个支付对接功能的复杂度完全不同，放在一起对比没有意义。正确做法：控制变量，同类功能对比。

陷阱三：忽视学习成本。"导入第一周，效率反而下降了！"——这是正常的。团队需要学习新工具、新流程、新习惯，学习曲线意味着短期效率会下降，但长期会上升。正确做法：以月为单位测量，关注趋势而不是绝对值。

陷阱四：指标驱动行为。"我们要求验收通过率达到 95%！"——结果团队为了达标，降低了验收标准：以前"功能、架构、安全三个维度全部检查"才算通过，现在"功能检查通过就算通过"。指标看起来漂亮了，质量却下降了。正确做法：综合多个指标评估，避免单一指标驱动；同时关注"指标是否被操纵"的信号。

### 【模板】团队 AI 编码月度报告

<!-- code-example:chapter-26-E2 mode:reference -->
> **示例类型：参考。** 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。
```markdown
## 团队 AI 编码月度报告
（模板填充示例——以下数字为演示用占位值）

## 本月概览
- 完成功能：12 个
- AI 辅助完成：10 个（83%）
- 平均交付周期：2.5 天（上月 3.2 天）
- 缺陷密度：6/千行（上月 8/千行）

## 质量数据
- 验收通过率：85%（首次通过）
- 架构偏移率：8%
- 测试覆盖率：65%

## 重点项目
| 项目 | 功能数 | 交付周期 | 质量状态 |
|:----|:-----:|:------:|:------:|
| 项目A | 5 | 2 天 | ✅ 健康 |
| 项目B | 3 | 3 天 | ⚠ 关注 |

## 改进建议
1. 验收通过率 85% 偏低，建议加强指令清晰度培训
2. 架构偏移率 8% 在可控范围内，继续保持
3. 测试覆盖率 65% 距离目标 80% 还有差距
```

> 第八部分完成。你已经掌握了建立永久自动防线的完整方法论：三道质量防线（预防/检查/审计）与四个质量门禁、灰度异常处理 SOP 与数据巡检机制、"尽早失败"的文化、测试电网（先测试后重构、覆盖率硬标准、"执行并修复所有失败测试"的致命指令）、防退化契约（Commit Hash 基线、Prompt 防退化条文）、以及风险控制与效率度量（七大风险全景、五步风险管理流程、效率/质量/团队/客户侧四维度指标与四大度量陷阱）。

> 现在，让我们进入第九部分：客户交付——从会话流水线到客户现场。在那里，方法论将进入客户项目的定界、验证与交付三阶段。

## 独立练习

使用虚构或已获授权的脱敏材料，先独立作答，再查看参考。将产物保存为 `chapter-26.md`，写上版本、决定、证据和缺项。

建四行风险表：概率、影响、触发信号、负责人和应对。为AI编码效率选择两个指标，写分母、时间窗和返工成本。

<!-- chapter-artifact-requirement -->
### 本章必交产物：风险与效率指标树

以下证据必须出现在本次独立练习的提交物中；正文原有问题用于提供内容，不能替代这些验收项。

- O1: 风险与效率指标树从“质量指标”分支到“交付成本”和“采用证据”并标明层级
- O2: 风险与效率指标树为每个叶节点记录基线、当前值、趋势和数据来源
- O3: 产物为质量、成本和采用指标分别记录基线、趋势、来源及取舍

<details>
<summary>查看参考反馈（先独立作答）</summary>

## 参考反馈

可记录每个已验收任务总工时及返工率，同时看缺陷和客户采用。代码行数和在线时长不代表价值；把模型成本、审核和修复计入。风险涉及技术、数据、权限和协作，未测得的收益留空，不生成看似精确ROI。

### 自评与下一步

对照本章目标检查：决定是否明确，依据是否能复现，未知项是否如实记录。参考给出一种判断方式，不是唯一答案；若不同结论能提供同等证据，可请同伴复核。缺少证据的部分记未完成，再回到对应步骤补充。

</details>

## 来源与边界

登记来源只支持本章涉及的外部事实；风险与效率指标树、示例数字和练习情境属于课程内部教学设计，必须在实际项目中重新验证。

- [Google SRE：分布式系统监控](https://sre.google/sre-book/monitoring-distributed-systems/) — Google, 2026-09-17. 监控应围绕可行动信号，并区分症状、原因、白盒与黑盒信息。
- [NIST AI 风险管理框架](https://www.nist.gov/itl/ai-risk-management-framework) — National Institute of Standards and Technology, 2026-09-17. AI 风险治理需要跨设计、开发、部署和使用阶段持续识别、测量、管理与记录。