很多团队已经把大量预算投入到 AI 编程助手、代码生成和自动化平台，但软件交付速度、质量和业务结果并没有同步改善。问题通常不在于模型不够强，而在于组织仍然用 token 数、调用次数和账号开通率衡量 AI 成功，却没有找到软件开发生命周期中真正的瓶颈。
Quotient CEO Lizzie Matusov 提出的 AI 成熟度框架，试图把讨论从“大家用了多少 AI”转向“AI 是否改变了工程系统的结果”。这意味着工程负责人需要同时观察工具、流程、团队行为和业务指标。
五个阶段，五种典型状态
下面的阶段名称是对该类成熟度框架的实践化表达。现实中的组织可能同时处于不同阶段：例如代码生成已经比较成熟，但测试、评审或发布流程仍停留在早期。
1. 试验阶段：工具很多，目标很少
团队开始尝试聊天机器人、代码补全、测试生成和文档自动化。使用者往往是少数热心工程师，工具选择由个人偏好驱动，组织还没有统一的安全边界和成功标准。
这一阶段最容易统计的是账号数和调用量，但这些数字只能说明“工具被打开过”，不能证明交付效率得到改善。正确动作是选择少量高频场景，记录原始基线，例如变更交付时间、代码评审等待时间和生产缺陷率。
2. 局部采用阶段：个人效率提升，团队流动受阻
部分开发者已经明显受益，但 AI 产生的代码仍要经过原有的测试、评审和发布流程。于是个人写代码更快，整个团队却可能在评审队列、集成测试或发布审批处排队。
这正是“局部优化没有带来端到端收益”的典型表现。工程领导者需要从单个开发者的产出，转向观察整个价值流：需求进入后，经过设计、实现、评审、测试，直到生产上线，时间究竟耗在哪里。
3. 标准化阶段：从自发使用转向可治理的能力
组织开始提供统一的模型访问、提示词规范、代码库上下文、安全策略和使用指南。团队也会为常见任务建立可复用流程，例如生成测试时必须运行哪些检查，处理敏感代码时哪些数据不能发送到外部服务。
标准化并不等于强制所有人使用同一个工具，而是让团队拥有清晰的边界和可比较的实践。没有治理的 AI 采用可能带来许可证风险、机密泄露、错误代码扩散和审查成本上升。
4. 工作流集成阶段：AI 开始连接整个 SDLC
AI 不再只是编辑器中的补全按钮，而是被嵌入需求拆解、设计评审、代码实现、测试生成、故障分析和发布后的反馈环节。重点从“模型能不能生成代码”转为“系统能不能减少交接、等待和返工”。
例如，AI 可以根据变更内容生成测试建议，再由 CI 验证；也可以从线上错误日志中整理复现步骤，并把结果反馈给负责的服务团队。每个环节都需要明确人工审批点，因为自动化范围越大，错误传播速度也越快。
5. 结果优化阶段：用业务结果指导 AI 投资
成熟组织不再把 AI 使用量当成终点，而是持续验证它是否带来更短的交付周期、更稳定的发布质量、更少的返工，或者更低的运营成本。
这并不意味着 token 使用量完全没有价值。它可以帮助估算成本和发现异常，但应当放在成本指标的位置，而不是业务价值指标的位置。真正重要的是建立“AI 实践 -> 工程行为 -> 交付结果”的因果链，并定期检查这条链是否成立。
团队为什么会卡住
把活动指标当成结果指标
账号开通率、提示词数量、生成代码行数和 token 消耗都很容易收集，因此常被用作管理汇报指标。但它们无法回答几个关键问题：代码是否更快进入生产？评审是否变快？缺陷是否减少？工程师是否把时间从重复劳动转移到了更高价值的设计和验证工作？
只优化编码环节
如果开发者写代码的时间减少了，但代码评审队列、集成测试环境或发布审批没有变化，端到端交付时间就不会明显下降。AI 成熟度评估必须覆盖完整的软件开发生命周期，而不是只看 IDE 内的行为。
缺少共同的采用方式
同一个团队中，不同工程师可能使用不同模型、不同上下文策略和不同验证方式。短期看似灵活，长期会形成难以维护的质量差异。组织需要定义最低验证标准，同时允许团队在安全边界内进行实验。
没有先建立基线
如果没有采用 AI 前的基线，团队很难判断某个工具是否真的有效。指标还可能被其他因素干扰，例如团队规模变化、架构迁移、需求复杂度上升或发布策略调整。因此，衡量 AI 影响时要记录时间窗口、样本范围和业务背景，而不是只展示一个漂亮的百分比。
可以这样建立结果导向的指标
一个可操作的指标体系可以分成三层：
- 采用指标：活跃用户、覆盖的任务类型、工具成本和使用频率。
- 工程行为指标：变更交付时间、评审等待时间、部署频率、返工比例和测试通过率。
- 业务结果指标：线上缺陷、服务可用性、客户问题解决时间、交付承诺达成率和工程成本。
下面的示例使用一组简化数据，计算 AI 实践前后的工程结果。它不是完整的 DORA 实现，但可以直接运行，也可以改造成从 Git、CI 和工单系统读取数据的脚本。运行前只需要把示例数据替换为团队真实数据。
from statistics import mean
periods = {
"before_ai": {
"lead_time_hours": [42, 36, 51, 45],
"review_wait_hours": [12, 10, 15, 11],
"escaped_defects": [3, 4, 2, 5],
},
"after_ai": {
"lead_time_hours": [34, 31, 39, 30],
"review_wait_hours": [13, 12, 14, 12],
"escaped_defects": [3, 3, 2, 4],
},
}
for name, metrics in periods.items():
print(name)
print(f" average lead time: {mean(metrics['lead_time_hours']):.1f}h")
print(f" average review wait: {mean(metrics['review_wait_hours']):.1f}h")
print(f" average escaped defects: {mean(metrics['escaped_defects']):.1f}")
before = periods["before_ai"]
after = periods["after_ai"]
lead_time_change = (mean(after["lead_time_hours"]) / mean(before["lead_time_hours"]) - 1) * 100
review_change = (mean(after["review_wait_hours"]) / mean(before["review_wait_hours"]) - 1) * 100
defect_change = (mean(after["escaped_defects"]) / mean(before["escaped_defects"]) - 1) * 100
print("\nChange after AI adoption")
print(f" lead time: {lead_time_change:+.1f}%")
print(f" review wait: {review_change:+.1f}%")
print(f" escaped defects: {defect_change:+.1f}%")
这个结果可能显示交付时间下降，但评审等待时间上升。此时结论不应是“AI 无效”，而是“编码环节获得了收益，评审环节成为新的瓶颈”。下一步应该优化评审规则、队列分配或变更大小，而不是继续单纯增加模型调用量。
给工程领导者的落地清单
- 为关键交付指标建立至少一个采用前基线，并记录数据来源和统计周期。
- 把 AI 实验绑定到具体工作流，例如测试生成、缺陷定位或变更摘要。
- 同时观察编码、评审、测试、发布和线上反馈，避免只优化单个环节。
- 设置代码安全、隐私、许可证和人工审批边界。
- 每个季度检查 AI 成本是否对应可验证的工程或业务收益。
- 允许不同团队实验，但要求共享结果、失败案例和可复用的验证方式。
AI 成熟度不是一次采购或一次培训就能完成的项目，而是组织持续发现瓶颈、调整工作流和验证结果的过程。真正成熟的团队不会因为使用了更多 AI 就宣布成功，而会继续追问：哪一个环节被改善了，谁因此节省了时间，业务结果是否真的发生了变化。