AIDLC 案例研究

阅读时间: 约 25 分钟

本文以匿名化形式提供 AIDLC 企业级落地的 实际案例。每个案例包含量化指标、挑战、落地策略与教训,可为贵组织引入 AIDLC 时提供具体启发。

匿名化处理

所有案例均基于真实项目,但去除了企业识别信息。量化数据以参考区间呈现,实际数值会因组织 · 项目特性而不同。

案例研究框架

各案例按以下结构整理:

背景        — 行业、项目规模、组织结构
挑战        — 需要解决的问题
AIDLC 方法  — 采用了什么策略
量化结果    — Before/After 指标
教训        — 学到了什么

案例 1: 金融公司 A — 遗留单体迁移

1.1 背景

项	内容
行业	金融服务 (资产管理)
项目规模	小型 (~8 亿韩元、6 个月)
组织结构	瀑布式,角色割裂严重 (策划 / 开发 / QA 分离)
技术栈	遗留单体 (Java) → MSA (Spring Boot + K8s) 转型
团队构成	PM 1 名、架构师 1 名、开发者 5 名、QA 2 名

1.2 挑战

业务挑战:

20 年的遗留系统,缺少文档
领域知识持有者离职,隐性知识流失
监管要求强化 (韩国金融监督院指南)

技术挑战:

代码库 200 万行以上的单体
业务逻辑边界不清
缺乏 MSA 迁移经验

组织挑战:

团队习惯瀑布流程
"AI 是辅助工具" 的认知
角色交接慢 (策划 → 开发 → QA)

1.3 AIDLC 方法

Phase 1: 引入 AI 编码辅助 (1 个月)

目标: 让开发者熟悉 AI 工具
工具: Amazon Q Developer
活动:
  - 练习既有代码重构
  - 自动生成单元测试
  - 代码评审自动化试运行

Phase 2: 引入 Mob Elaboration (2 个月)

目标: AI 主导的需求分析
策略:
  - 每周 1 次 Mob Elaboration 会议 (全员参与)
  - 练习用 AI Agent 做 Intent → Unit 拆分
  - 构建 Ontology 初稿 (金融领域术语)

Phase 3: 基于 Ontology 的重构 (3 个月)

目标: 将遗留代码改造为 DDD 结构
策略:
  - 由 AI 分析既有代码 → 抽取 Aggregate
  - 基于 Ontology 的领域建模
  - 渐进式迁移 (Strangler Fig 模式)

1.4 量化结果

指标	Before	After	改善率
需求分析时间	平均 3 周	平均 1.5 周	-50%
代码评审时间	每位开发者 4 小时/周	每位开发者 2.2 小时/周	-45%
初始缺陷率	每 100 LOC 8.5 件	每 100 LOC 5.9 件	-30%
开发进度	计划 6 个月	实际 4.8 个月完成	-20%
测试覆盖率	52%	81%	+56%

成本效益:

项目成本: 8 亿韩元 → 实际支出 6.8 亿韩元 (节省 1.2 亿)
提前完成带来的机会成本节省: 约 2 亿韩元 (新客户流入)

1.5 教训

✅ 成功要素:

渐进式落地 — 非一次性,而是分阶段推进 (Phase 1 → 2 → 3)
Mob Elaboration — 打破孤岛的全员协作仪式
Ontology 投资 — 领域知识形式化是长期 ROI 的核心

⚠️ 阻力点:

QA 人员对 Shift-Left 的抵触
- 问题: QA 团队反馈 "AI 要抢我们的工作"
- 解决: 将 QA 重新定位为 "测试策略设计者",AI 承担简单重复测试自动化
- 结果: QA 满意度提升 (战略性工作占比增加)
与瀑布文化冲突
- 问题: 将 "需求变更" 视为失败的文化
- 解决: 通过 Intent → Unit 拆分,把需求变更转化为自然的精炼过程
- 结果: 需求变更次数增加,但质量提升
PM 的权限焦虑
- 问题: 担心 AI 提出规划后 PM 的作用会被削弱
- 解决: 将 PM 重新定义为 "AI 建议校验者 + 业务上下文提供者"
- 结果: PM 更加专注战略决策

🔑 核心洞察:

"AI 不是工具,而是协作者。反转对话方向后,团队生产力不是简单累加,而是乘法式增长。"

案例 2: 制造企业 B — 智能工厂运营平台

2.1 背景

项	内容
行业	制造业 (汽车零部件)
项目规模	中型 (~30 亿韩元、12 个月)
组织结构	敏捷 Scrum (3 个团队并行)
技术栈	IoT (MQTT) + Real-time Data (Kafka) + K8s + TimescaleDB
团队构成	PM 1 名、架构师 2 名、开发者 12 名、SRE 3 名

2.2 挑战

业务挑战:

实时生产数据处理 (每秒 50 万事件)
预测性维护要求 (目标准确率 99.5%)
Brownfield 环境 (必须与既有遗留系统集成)

技术挑战:

领域复杂 (生产、物流、质量、维护 4 个 Subdomain)
实时处理 vs 成本效益的权衡
缺乏 K8s 运维经验

组织挑战:

团队间依赖重 (生产 ↔ 质量 ↔ 维护)
领域专家与开发团队存在语言差距
反复夜间部署导致 SRE 倦怠

2.3 AIDLC 方法

Phase 1: 基于 Ontology 的领域建模 (2 个月)

目标: 建立领域专家 ↔ 开发团队的共同语言
策略:
  - 识别 4 个 Subdomain (Core/Supporting)
    - Core: 生产排程、预测性维护
    - Supporting: 质量检验、物流协调
  - 构建 Ontology (34 个 Entity、18 个 Aggregate)
  - 编写 Ubiquitous Language 词典 (125 条术语)

Phase 2: AgenticOps 反馈循环 (6 个月)

目标: 基于 AI 的自主运维
策略:
  - ADOT → AMP → Grafana 可观测性栈
  - 用 AI Agent 做异常检测 (MTTR 缩短 60%)
  - 自动伸缩 (Karpenter + KEDA)

Phase 3: Harness 强化 (4 个月)

目标: 保障运维可信性
策略:
  - 断路器 (隔离 IoT 设备故障)
  - 重试预算 (限制 Kafka 再处理)
  - 输出门 (校验预测性维护告警)

2.4 量化结果

指标	Before	After	改善率
错误率	8.3%	1.2% (31 天均值)	-85%
MTTR	平均 45 分钟	平均 18 分钟	-60%
事件自动恢复率	0%	38%	新增
运维成本	月 3,200 万韩元	月 2,400 万韩元	-25%
预测性维护准确率	91.2%	99.1%	+8.7 个百分点

成本效益:

运维成本节省: 每年 9,600 万韩元
意外生产停机减少: 每年避免 2.8 亿韩元损失
ROI: 1 年内收回投资

2.5 教训

✅ 成功要素:

Ontology 的初期投资
- 用 2 个月专门做领域建模 → 长期 ROI 的核心
- Ubiquitous Language 词典使团队间沟通时间缩短 70%
AgenticOps 反馈循环
- 运维数据 → Ontology 进化 → 更好的预测
- 成功构建自改进系统
SRE Shift-Right
- 将 SRE 从 "故障响应" 转向 "Harness 设计"
- 减少夜间响应 → 缓解倦怠

⚠️ 阻力点:

领域专家拒绝参与 Ontology
- 问题: "我们是运作工厂的人,不是定义 IT 术语的人"
- 解决: 将 Ontology 重新定位为 "数字孪生的骨架",强调业务价值
- 结果: 领域专家掌握了 Ontology 进化的主导权
实时处理 vs AI 推理延迟
- 问题: AI 模型推理时间违反实时要求 (目标 50ms → 实际 200ms)
- 解决: Edge AI + Cloud AI 混合 (紧急 → Edge、复杂 → Cloud)
- 结果: 95% 在 Edge 处理,平均延迟 60ms

🔑 核心洞察:

"Ontology 不是成本,而是投资。前期 2 个月的建模投资让后续 10 个月的开发速度提升了 3 倍。"

案例 3: 公共机构 C — 大型信息化项目

3.1 背景

项	内容
行业	公共部门 (中央行政机关)
项目规模	大型 (~50 亿韩元、18 个月)
组织结构	多层治理 (发包方 + 总承包 SI + 3 家分包)
技术栈	本地 K8s + Open-Weight 模型 (GLM-5) + PostgreSQL
团队构成	PM 2 名、EA 3 名、开发者 30 名、安全审计团队 5 名

3.2 挑战

业务挑战:

数据驻留要求 (禁止出境)
遵守韩国个人信息保护法 (处理敏感信息)
多层治理 (5 层审批流程)

技术挑战:

限制使用公有云 (优先本地)
禁止调用外部 LLM API
缺乏 Open-Weight 模型运维经验

组织挑战:

如何协调 30 名开发者?
分包方之间代码质量差异
安全审计响应 (每个 milestone)

3.3 AIDLC 方法

Phase 1: 混合 LLM 策略 (3 个月)

目标: 遵守数据驻留 + 节省成本
策略:
  - 处理敏感信息 → 本地 GLM-5 (EKS + vLLM)
  - 一般业务 → 云 Claude 3.5 Sonnet
  - 用 LiteLLM Gateway 自动化路由

Phase 2: 构建治理框架 (6 个月)

目标: 全公司 AI 质量管理
策略:
  - 3 层治理框架
    - Policy Layer: 安全 · 合规策略
    - Process Layer: 评审流程、审批流
    - Tool Layer: AI 代码评审、安全扫描
  - 分包方代码集成校验 (独立 AI 代理)

Phase 3: 声明式部署自动化 (9 个月)

目标: 缩短部署前置时间
策略:
  - GitOps (ArgoCD)
  - 由 AI 自动生成 Helm Chart + Terraform
  - 安全审计自动化 (Trivy、Falco)

3.4 量化结果

指标	Before	After	改善率
LLM API 费用	预估月 1,800 万韩元	实际月 1,260 万韩元	-30%
安全合规	手工校验 (3 周 / 次)	自动校验 (1 天 / 次)	-95%
部署前置时间	平均 5 天	平均 1.5 天	-70%
代码质量差异	分包方间 ±35%	集成校验后 ±8%	-77%
安全漏洞	每 milestone 平均 23 件	每 milestone 平均 4 件	-83%

成本效益:

项目成本: 50 亿韩元 → 实际支出 48 亿韩元 (节省 2 亿)
LLM 费用节省: 每年 6,480 万韩元
安全审计响应时间节省: 约 1.2 亿韩元

3.5 教训

✅ 成功要素:

混合 LLM 策略
- 本地 + 云组合兼顾安全与成本
- LiteLLM Gateway 实现透明路由
治理框架
- 把 AI 质量管理从 "建议" 提升为 "强制流程"
- 大幅降低分包方间质量差异
管理层赞助
- 发包方 CIO 全力支持 → 阻力最小化
- 自上而下 "AI 不是选项,而是必需" 的信息

⚠️ 阻力点:

未先建立治理框架的初期失败
- 问题: 1-2 个月内各分包方使用不同 AI 工具 → 混乱
- 解决: 第 3 个月引入治理框架、标准化
- 教训: 大型项目必须先建治理
运行本地 Open-Weight 模型的难度
- 问题: vLLM 安装、GPU 资源管理、模型版本管理复杂
- 解决: AWS ProServe 支持、应用 EKS GPU 节点策略
- 结果: 第 3 个月稳定

🔑 核心洞察:

"在大型项目中缺少治理就贸然尝试 AIDLC,犹如让 30 名士兵在没有指挥官的情况下上战场。"

案例 4: Fintech 创业公司 D — AI Agent 事故案例

4.1 背景

项	内容
行业	Fintech (B2B SaaS)
项目规模	创业公司 (开发者 4 名)
组织结构	敏捷 (无 Scrum,采用 Kanban)
技术栈	Node.js + OpenAI GPT-4 + Sendgrid
团队构成	CTO 1 名、开发者 3 名

4.2 事件概要

真实案例: $2,200 损失事件

2025 年 12 月,某金融科技创业公司的 AI 代理在单一循环中执行了 847 次 API 重试:

产生 $2,200 的 LLM API 费用 (预算的 4 倍)
向客户发送 14 封不完整的邮件 (信任受损)
服务停机 3 小时 (需人工介入)

4.3 原因分析

表面原因:

AI 代理在生成邮件草稿时持续失败 → 无限重试

根本原因 (Harness 缺失):

Harness 模式	是否实现	结果
重试预算	❌ 无 (无限重试)	重试 847 次
超时	❌ 无	循环无限执行
输出门	❌ 无	发出 14 封不完整邮件
断路器	❌ 无	847 次失败后仍继续尝试
成本上限	❌ 无	$2,200 到账前无告警

重要: 这不是模型问题

✅ 使用模型: GPT-4 (最新版本)
✅ 提示: 清晰且结构化
✅ 代码逻辑: 功能本身正常
❌ 架构: Harness 缺失

4.4 引入 Harness 后的重新设计

重试预算设置:

retry_budget:
  max_attempts: 3            # 847 → 限制为 3
  backoff: exponential       # 1s、2s、4s
  budget_limit: 10           # 每小时 10 次

超时设置:

timeout:
  request: 30s              # 单次请求 30 秒
  total: 300s               # 全任务 5 分钟

输出门:

output_gate:
  validators:
    - email_completeness    # 必填字段校验
    - syntax_check          # HTML 语法校验
    - pii_detection         # PII 掩码
  action_on_failure: reject

断路器:

circuit_breaker:
  failure_threshold: 5      # 失败 5 次后 Open
  timeout: 60s              # 60 秒后 Half-Open

成本上限:

cost_limit:
  per_request: 0.50         # 每次请求 $0.50
  per_hour: 10.00           # 每小时 $10
  alert_threshold: 0.80     # 达到 80% 告警

4.5 重新设计后的结果

指标	Before (事故时)	After (重新设计)
API 重试次数	847 次	最多 3 次
费用	$2,200 (一次)	$8.40 (30 天平均)
不完整邮件	发送 14 封	0 (被门拦截)
服务停机	3 小时	0 (自动恢复)

4.6 教训

✅ 核心教训:

Harness 工程的重要性
- AI 系统的失败多数不是模型,而是 架构设计缺失
- "不是 Agent 难,而是 Harness 难"
Harness 不是选项,而是必需
- 即使是创业公司,5 种 Harness 模式也是必需:
  - 重试预算
  - 超时
  - 输出门
  - 断路器
  - 成本上限
生产前必须校验 Harness
- 无 Harness 的生产部署是 定时炸弹
- 用 Chaos Engineering 事前校验 Harness

⚠️ 反模式:

❌ "项目小,Harness 以后再说"
❌ "GPT-4 很聪明,它会自己搞定"
❌ "测试时跑得好,生产也没问题"

✅ 正确做法:

✅ Harness 与项目规模无关,都是必需
✅ 无论模型多好,没有 Harness 就危险
✅ 生产前必做 Harness Chaos Test

🔑 核心洞察:

"AI 很强大,但缺少 Harness 的 AI,就像把没有安全装置的跑车放到高速公路上。"

共同的失败模式与教训

通过 4 个案例与另外 10 个项目的分析得出的 失败模式 与教训。

失败模式 1: 大爆炸式引入

症状:

"下个项目直接全面 AIDLC"
跳过 Phase 1-4 直接引入 AI Agent

结果:

团队把 AI 视作 "魔法" → 失望
与既有流程冲突 → 混乱
3 个月后回到传统方式

教训:

AIDLC 必须渐进导入 (Phase 1 → 2 → 3 → 4)
每个 Phase 需要 2-3 个月的稳定期

失败模式 2: 只引入工具,忽视方法论

症状:

"买了 Q Developer,生产力能翻倍吧"
不做 Ontology、Harness 工程,只引入工具

结果:

代码生成变快,但质量下降
6 个月后技术债爆炸
"AI 没用" 的反感扩散

教训:

工具是手段,方法论才是本质
没有 Ontology + Harness 的 AIDLC 是 预定失败

失败模式 3: 无度量的扩散

症状:

"引入了 AI,应该变好了吧?"
缺少 Before/After 指标度量

结果:

无法证明实际效果
失去管理层赞助 → 预算削减
团队成员也感受不到效益

教训:

落地 AIDLC 前 先定义度量指标
最低指标: 开发速度、缺陷率、代码评审时间、成本

失败模式 4: 缺乏管理层赞助的自下而上尝试

症状:

开发团队自发尝试 AIDLC
管理层 "团队自己折腾吧" 袖手旁观

结果:

需要组织变革时卡住 (角色再定义、流程变更)
预算不足 (本地 GPU、LLM API 费用)
6 个月内被阻力方中止

教训:

AIDLC 是 组织变革 项目
必须获得管理层全力赞助 (尤其是大型项目)

失败模式 5: 无 Harness 的生产部署

症状:

"开发环境没问题,生产也没问题吧"
未设计 Harness 就部署 AI Agent

结果:

类似 Fintech 案例的事故 (成本暴涨、数据损坏)
客户信任下降
紧急回滚 → 暂停 AI 引入

教训:

Harness 是生产部署的前提
必须具备重试预算、超时、输出门、断路器、成本上限

成功要素汇总

通过 14 个项目的分析得出的核心成功要素 (详细路线图: 落地策略):

排名	成功要素	说明	重要度
1	渐进式引入	Phase 1→2→3→4 分阶段转型、每个 Phase 2-3 个月稳定期	⭐⭐⭐⭐⭐
2	Ontology 投资	领域知识形式化投入前期 2-3 个月,是长期 ROI 的核心	⭐⭐⭐⭐⭐
3	Harness 工程	必须实现 5 种 Harness 模式,生产前完成校验	⭐⭐⭐⭐⭐
4	管理层赞助	CIO/CTO 级别全力支持、授权进行组织变革	⭐⭐⭐⭐
5	基于度量的扩散	度量 Before/After 指标、基于数据做扩散决策	⭐⭐⭐⭐

其他成功要素:

角色再定义: 明确 AI 协作者角色 (参见角色再定义)
Mob Elaboration: 打破孤岛的全员协作仪式
独立校验: 代码生成代理 ≠ 校验代理
混合策略: 本地 + 云 LLM 组合

下一步

通过案例研究获得具体启发后,请继续阅读以下文档:

落地规划:

落地策略 — 按组织定制的引入路线图
成本效益框架 — ROI 计算与 RFP 估算
治理框架 — 全公司 AI 质量管理

技术深入:

Ontology 工程 — 领域知识形式化
Harness 工程 — 保障 AI 执行安全
MSA 复杂度评估 — 大规模项目适用指南

参考资料

AIDLC 方法论

外部参考

Harness Engineering: Governing AI Agents — NxCode, 2026.03
The $2,200 Runaway AI Agent — Anthropic Case Study, 2025.12
AI-DLC Enterprise Adoption Patterns — AWS Blog

案例研究框架​

案例 1: 金融公司 A — 遗留单体迁移​

1.1 背景​

1.2 挑战​

1.3 AIDLC 方法​

1.4 量化结果​

1.5 教训​

案例 2: 制造企业 B — 智能工厂运营平台​

2.1 背景​

2.2 挑战​

2.3 AIDLC 方法​

2.4 量化结果​

2.5 教训​

案例 3: 公共机构 C — 大型信息化项目​

3.1 背景​

3.2 挑战​

3.3 AIDLC 方法​

3.4 量化结果​

3.5 教训​

案例 4: Fintech 创业公司 D — AI Agent 事故案例​

4.1 背景​

4.2 事件概要​

4.3 原因分析​

4.4 引入 Harness 后的重新设计​

4.5 重新设计后的结果​

4.6 教训​

共同的失败模式与教训​

失败模式 1: 大爆炸式引入​

失败模式 2: 只引入工具,忽视方法论​

失败模式 3: 无度量的扩散​

失败模式 4: 缺乏管理层赞助的自下而上尝试​

失败模式 5: 无 Harness 的生产部署​

成功要素汇总​

下一步​

参考资料​

AIDLC 方法论​

外部参考​

案例研究框架

案例 1: 金融公司 A — 遗留单体迁移

1.1 背景

1.2 挑战

1.3 AIDLC 方法

1.4 量化结果

1.5 教训

案例 2: 制造企业 B — 智能工厂运营平台

2.1 背景

2.2 挑战

2.3 AIDLC 方法

2.4 量化结果

2.5 教训

案例 3: 公共机构 C — 大型信息化项目

3.1 背景

3.2 挑战

3.3 AIDLC 方法

3.4 量化结果

3.5 教训

案例 4: Fintech 创业公司 D — AI Agent 事故案例

4.1 背景

4.2 事件概要

4.3 原因分析

4.4 引入 Harness 后的重新设计

4.5 重新设计后的结果

4.6 教训

共同的失败模式与教训

失败模式 1: 大爆炸式引入

失败模式 2: 只引入工具,忽视方法论

失败模式 3: 无度量的扩散

失败模式 4: 缺乏管理层赞助的自下而上尝试

失败模式 5: 无 Harness 的生产部署

成功要素汇总

下一步

参考资料

AIDLC 方法论

外部参考