DORA / SPACE：AI SDLC 工程生产力
AI-assisted SDLC 的生产力不能用代码行数、提交数或 agent 使用次数衡量。AI 会同时放大有效交付和无效产出: 它能缩短实现时间, 也能更快制造低质量测试、安全缺陷、架构漂移和评审负载。
DORA / SPACE / AI SDLC Engineering Productivity 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_DORA_SPACE_ENGINEERING_PRODUCTIVITY_SDLC_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| DORA | https://dora.dev/ | 参考软件交付性能、组织能力和度量实践 |
| The SPACE of Developer Productivity | https://queue.acm.org/detail.cfm?id=3454124 | 参考 Satisfaction、Performance、Activity、Communication、Efficiency 的多维生产力框架 |
| NIST Secure Software Development Framework | https://csrc.nist.gov/Projects/ssdf | 把 AI-assisted SDLC 连接到安全软件开发实践 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 把 AI engineering productivity 与 AI 风险治理、度量和持续管理连接 |
核心导读
AI-assisted SDLC 的生产力不能用代码行数、提交数或 agent 使用次数衡量。AI 会同时放大有效交付和无效产出: 它能缩短实现时间, 也能更快制造低质量测试、安全缺陷、架构漂移和评审负载。
DORA 和 SPACE 放在一起, 可以把 AI 工程效率从“个人写得更快”转成“系统在安全、可靠、可恢复、可治理的前提下更快交付价值”。真正的目标不是让 agent 产出更多代码, 而是降低从需求到生产价值的总摩擦和总风险。
系统理解的关键是把 DORA/SPACE 当作度量架构，而不是效率仪表盘。AI 辅助开发改变的是整个交付系统：需求澄清、代码生成、测试、评审、安全扫描、架构边界、发布证据和事故恢复都会受影响；因此评估要连接 flow、quality、reliability、security、developer experience 和业务结果。
治理边界同样重要：AI 使用指标不能变成个人监控或活动竞赛，release gate 也不能只要求“有 AI 生成的测试”。可靠的证据应证明变更为什么安全、哪些检查通过、哪些风险被接受、如何回滚，以及事故后如何更新 guardrail、eval 和工程规范。
问题定义
AI code agent 会放大这些正向能力:
- 解释遗留代码。
- 生成测试和重构候选。
- 加速样板代码、文档和迁移脚本。
- 帮助开发者探索陌生模块。
同时也会放大这些风险:
- 未理解的代码被合并。
- 测试覆盖率增加但测试无效。
- 新依赖、license 和漏洞风险增加。
- 架构边界被局部改动侵蚀。
- reviewer 面对更大 diff 和更多噪声。
- 生产故障更难追溯到 AI 辅助决策。
因此问题不应是:
AI 让开发者多写了多少代码?
而应是:
AI 是否让团队更快、更安全、更可恢复地交付正确变更?
核心原理/方法
DORA 提供交付系统的结果指标:
| DORA 维度 | AI SDLC 问法 |
|---|---|
| Deployment Frequency | AI-assisted changes 是否能更频繁安全发布 |
| Lead Time for Changes | 从需求或缺陷到生产的周期是否缩短 |
| Change Failure Rate | AI 辅助变更是否提高故障、返工或回滚比例 |
| Failed Deployment Recovery Time | AI 相关问题能否快速定位、回滚、修复和补证据 |
SPACE 防止生产力被单一指标劫持:
| SPACE 维度 | AI SDLC 解释 | 示例指标 |
|---|---|---|
| Satisfaction | 开发者是否信任工具, 是否降低挫败感 | tool satisfaction、flow interruptions、survey |
| Performance | 系统和业务结果是否改善 | lead time、defect escape、incident rate、business outcome |
| Activity | 可观察活动, 不能单独作为目标 | PR count、agent sessions、commits |
| Communication | 协作和知识流是否改善 | review cycle、handoff delay、architecture questions |
| Efficiency | 是否减少等待和无效工作 | rework rate、context switching、build/test wait |
AI-specific 指标必须与 DORA/SPACE 配对:
| 指标 | 解释 |
|---|---|
| AI-assisted PR share | 哪些变更受 AI 辅助, 用于分层分析而非排名个人 |
| AI-assisted defect density | AI 辅助变更的缺陷密度和严重度 |
| Review amplification | AI diff 是否增加 reviewer 时间和重复评审 |
| Test usefulness | AI 生成测试是否捕获真实风险 |
| Architecture drift rate | 变更是否偏离 ADR、边界和依赖规则 |
| Secure coding violation rate | secrets、注入、权限、依赖和数据处理违规 |
| Eval gate pass rate | AI 产品变更是否通过 prompt/RAG/model/tool 回归门禁 |
系统/架构模型
AI SDLC 生产力系统可以抽象为:
Work intake
-> discovery and design
-> AI-assisted implementation
-> automated tests and security checks
-> human review and architecture review
-> AI product eval gate
-> release evidence bundle
-> deployment
-> observability and incident loop
-> backlog and guardrail updates
AI 产品的发布对象不只是代码:
Code diff
Prompt diff
Model/provider config
RAG corpus version
Tool schema change
Eval dataset version
Eval result
Risk control change
Monitoring threshold
Rollback plan
这意味着工程生产力平台需要连接:
- 代码仓库和 PR metadata。
- CI/CD、测试、SAST/DAST、依赖扫描。
- Prompt、RAG、model config 和 tool schema 版本。
- Eval harness、release gate 和证据仓。
- Observability trace、incident 和 postmortem。
- 开发者体验和团队负载数据。
关键机制与取舍
| 机制 | 设计重点 | 取舍 |
|---|---|---|
| Repository policy | 哪些 repo、文件和数据允许 agent 访问 | 限制过严降低价值, 过松增加泄露和误改风险 |
| Context boundary | agent 可读哪些代码、issue、文档和日志 | 上下文越大越有用, 也越需要隐私和权限控制 |
| PR labeling | 标识 AI-assisted changes | 有利于度量, 但不能制造个人监控恐惧 |
| Review policy | 高风险文件强制人工和架构评审 | 控制风险, 但会增加队列和等待 |
| Test gate | unit、integration、regression、security、AI eval | 门禁越强越安全, 也可能拖慢低风险变更 |
| Dependency gate | 新依赖审批、license、vulnerability | 减少供应链风险, 但要避免所有依赖都人工审批 |
| Evidence bundle | 记录 diff rationale、test、scan、eval 和审批 | 支持审计和复盘, 但需要自动化生成 |
| Incident loop | AI-assisted defect postmortem | 防止重复错误, 但需要无责文化 |
关键原则:
- 活动指标只能作为诊断信号, 不能作为绩效目标。
- AI adoption 不是成功指标, 只有价值、质量和风险一起改善才是成功。
- 速度提升必须和 change failure、review load、security findings 和 developer satisfaction 同看。
证据与控制
AI SDLC dashboard 应覆盖八类指标:
| 层级 | 指标 |
|---|---|
| Flow | lead time、cycle time、queue time、review time、deployment frequency |
| Quality | defect escape、pre-merge regression caught、test usefulness、architecture drift |
| Reliability | change failure rate、MTTR、rollback time、incident severity |
| Security | secret leakage、dependency risk、SAST/DAST findings、policy violations |
| AI Use | agent-assisted tasks、accepted suggestions、manual rewrite rate、prompt patterns |
| Review Load | reviewer time、AI diff size、comment density、re-review count |
| Developer Experience | satisfaction、cognitive load、context switching、tool trust |
| Business Outcome | feature adoption、risk reduction、cost saving、customer impact |
发布门禁应按风险分层:
| Gate | 问题 |
|---|---|
| Code Quality | 是否通过测试、lint、review 和最小可维护性标准 |
| Security | 是否引入注入、secret、依赖、权限和数据处理风险 |
| Architecture | 是否符合 ADR、边界、依赖方向和平台接口 |
| AI Eval | prompt、RAG、model、agent 行为是否通过回归和安全测试 |
| Observability | 是否有 trace、metric、alert 和事故定位信息 |
| Rollback | prompt/model/index/tool 是否可回滚或降级 |
| Evidence | 是否生成 release bundle, 能解释变更和风险接受 |
金融零售场景映射
核心银行变更
AI 可用于理解遗留代码、生成回归测试、解释接口和迁移脚本。但高风险主机、账务、支付和数据迁移场景必须保留 mandatory human review、回归套件、dual control、迁移校验和 rollback rehearsal。生产力指标要看 lead time 是否缩短, 同时 change failure 和审查返工是否可控。
客服 RAG
一次看似简单的 RAG 变更可能包括 policy corpus、chunking、prompt、reranker、引用展示和拒答逻辑。若只看发布速度, 错误政策会更快进入生产。度量必须把发布频率与 groundedness、policy breach、repeat contact、complaint 和回滚能力绑定。
风控模型 pipeline
AI agent 可提升 notebook 到 production pipeline 的速度, 但必须控制 data leakage、point-in-time correctness、feature lineage、model validation evidence 和 approval workflow。这里的生产力不是模型上线更快, 而是验证证据更完整、回归更稳定、事故恢复更快。
反模式
| 反模式 | 表现 | 修正 |
|---|---|---|
| Lines-of-code productivity | 用代码行数证明 AI 工具价值 | 看 flow、quality、reliability、DX 和业务结果 |
| PR spam | AI 让 PR 更多更大 | 限制 diff size, 改善分批和 review policy |
| Generated test theater | 覆盖率升高但不抓缺陷 | 用 bug replay、mutation、regression 验证测试有效性 |
| Security afterthought | 先提速后补安全 | SSDF、依赖和数据边界前置 |
| Agent without architecture | agent 自动侵蚀边界 | ADR、fitness function、architecture gate |
| Individual ranking | 用 AI 指标排名开发者 | 用团队和系统指标做改进, 避免行为扭曲 |
最终心智模型
AI SDLC 生产力的最终心智模型是:
速度不是目标, 可持续价值流才是目标;
AI 不是替代工程纪律, 而是放大工程系统;
指标不能只看 activity, 必须连接质量、风险、恢复和体验;
越是自动化生成, 越需要自动化证据和运行反馈。
好的 AI 工程生产力体系会让团队更快合并正确变更, 更早发现错误变更, 更容易解释高风险变更, 并在事故发生时更快恢复和学习。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。