ai-dlc

name	ai-dlc
description	AI驱动开发生命周期：四阶段工程化AI开发方法论（构思→执行→运维→反思）。当用户说'AI开发流程'、'开发生命周期'、'工程化AI开发'、'AI-DLC'、'质量门控'、'Hat-based工作流'、'AI项目管理'、'规范化AI开发'时触发。核心特点：四阶段闭环、Hat-based角色切换、质量门控阻断机制、Backpressure反馈、DAG依赖编排。

来源: TheBushidoCollective/ai-dlc — AI-Driven Development Lifecycle

发布时间: 2026-04-29

理念: "AI 编程不是聊天，而是工程。每个阶段都有入口标准、出口标准和质量门控。"

🔄 AI-DLC — AI 驱动开发生命周期

把 AI 辅助开发变成可重复、可审计、可改进的工程流程。

---

🎯 核心概念

AI-DLC（AI-Driven Development Lifecycle）将软件开发的全生命周期映射到 AI 协作场景，形成四阶段闭环：

构思(Elaboration) → 执行(Execution) → 运维(Operation) → 反思(Reflection)
         ↑___________________________________________________________↓

与传统 AI 编程的区别：

	传统 AI 编程	AI-DLC
流程	无，想到哪问到哪	四阶段严格闭环
角色	你和 AI 两个人	Hat-based 多角色切换
质量	事后检查	阶段门控，不通过就阻断
可追溯	聊天记录散落	每个决策都有 Intent + Unit 记录
改进	靠经验	Reflection 阶段系统化复盘

---

🎩 Hat-based 角色工作流

AI-DLC 的核心是 "换帽子" —— 同一个 AI 在不同阶段戴不同的帽子，扮演不同角色：

帽子	角色	职责	阶段
🎩 Planner	规划师	需求分析、范围界定、风险评估	Elaboration
🔨 Builder	构建者	代码实现、单元测试、文档编写	Execution
🔍 Reviewer	审查者	代码审查、安全审计、合规检查	Execution/Operation
🔴 Red Team	红队	故意找茬、攻击假设、发现盲点	贯穿全程
🔵 Blue Team	蓝队	防御验证、修复验证、回归测试	Operation
📝 Scribe	记录员	文档维护、决策日志、知识沉淀	Reflection
🎯 Skeptic	怀疑者	质疑过度设计、推动 MVP	Elaboration

换帽规则：

• 每个阶段开始时明确声明"现在戴 XX 帽子"
• 同一轮对话中不换帽子（避免角色混乱）
• 复杂任务强制引入 Red Team 审查

---

📋 四阶段详解

阶段 1：构思（Elaboration）

目标：搞清楚"做什么"和"为什么做"，产出清晰的开发意图。

入口标准：用户提出需求或问题 出口标准：Intent 文档通过 Red Team 审查

关键产出：Intent 文档

# Intent: {功能名称}

## 问题陈述
用户遇到什么痛点？

## 目标
- 目标 1：...
- 目标 2：...

## 范围
### 包含（In Scope）
- ...

### 不包含（Out of Scope）
- ...

## 约束条件
- 时间：...
- 技术：...
- 资源：...

## 成功标准
- [ ] 标准 1
- [ ] 标准 2

## 风险评估
| 风险 | 概率 | 影响 | 缓解措施 |
|------|------|------|---------|
| ... | 高/中/低 | 高/中/低 | ... |

## Red Team 审查意见
- [ ] 假设是否合理？
- [ ] 范围是否过度？
- [ ] 是否有遗漏的边界情况？

阶段内工作流

Planner 分析需求 → Skeptic 质疑范围 → Red Team 攻击假设
    → 修订 Intent → 用户确认 → 进入下一阶段

---

阶段 2：执行（Execution）

目标：按 Intent 实现功能，通过所有质量门控。

入口标准：Intent 文档已确认 出口标准：所有 Unit 通过 Backpressure Gate

关键产出：Unit 文档

# Unit: {功能单元名称}

## 关联 Intent
- Intent: {链接到父 Intent}

## 实现任务
- [ ] 任务 1：...
- [ ] 任务 2：...

## 技术决策
- 决策 1：选择 XX 而不是 YY，原因...

## 验收标准
- [ ] 功能正确性：...
- [ ] 性能：...
- [ ] 安全：...

## Backpressure Gate
- [ ] 单元测试通过
- [ ] 类型检查通过
- [ ] Linter 通过
- [ ] 安全扫描通过
- [ ] 代码审查通过

阶段内工作流

Planner 拆分为 Units → Builder 逐个实现
    → Reviewer 代码审查 → Red Team 攻击实现
    → Blue Team 验证修复 → Backpressure Gate 检查
    → 通过 → 进入下一阶段
    → 不通过 → 返回 Builder 修复

Backpressure 质量门控

每个 Unit 必须通过以下检查才能进入下一阶段：

门控	检查内容	阻断级别
测试门控	单元测试覆盖率 > 80%，全部通过	🔴 阻断
类型门控	静态类型检查无错误	🔴 阻断
规范门控	Linter/Formatter 无警告	🟡 警告
安全门控	无 SQL 注入/XSS/硬编码密钥	🔴 阻断
审查门控	Reviewer 批准	🔴 阻断

---

阶段 3：运维（Operation）

目标：功能上线并稳定运行，收集真实反馈。

入口标准：所有 Unit 通过 Backpressure Gate 出口标准：运行指标达标，无 P0/P1 故障

关键活动

活动	说明
部署	使用蓝绿/金丝雀发布，降低风险
监控	关键指标：错误率、延迟、吞吐量
告警	P0（立即处理）、P1（2小时内）、P2（24小时内）
日志	结构化日志，可追踪到具体 Intent/Unit
反馈收集	用户行为数据、错误报告、性能数据

运维检查清单

# Operation Checklist

## 部署前
- [ ] 回滚方案已准备
- [ ] 数据库迁移脚本已测试
- [ ] 配置项已核对

## 部署中
- [ ] 金丝雀流量比例：5% → 25% → 50% → 100%
- [ ] 每阶段观察 10 分钟，指标正常才继续

## 部署后
- [ ] 错误率 < 0.1%
- [ ] P95 延迟 < 200ms
- [ ] 无 P0/P1 告警持续 1 小时

---

阶段 4：反思（Reflection）

目标：复盘全过程，沉淀经验，改进流程。

入口标准：功能稳定运行至少 1 个迭代周期 出口标准：Reflection 文档产出，改进项进入 backlog

关键产出：Reflection 文档

# Reflection: {功能名称}

## 执行摘要
- 计划工期：x 天
- 实际工期：y 天
- 偏差原因：...

## 做得好的
1. ...
2. ...

## 做得不好的
1. ...
2. ...

## 意外发现
- ...

## 改进项
| 改进项 | 优先级 | 负责人 | 预计工时 |
|--------|--------|--------|---------|
| ... | P0/P1/P2 | ... | ... |

## 知识沉淀
- 模式：{可复用的设计/代码模式}
- 陷阱：{踩过的坑及避免方法}
- 工具：{好用的工具/脚本}

反思会议议程（AI 版）

1. Scribe 回顾全过程（Intent → Units → Operation）
2. Planner 评估范围控制是否准确
3. Builder 评估技术决策是否恰当
4. Reviewer 评估代码质量趋势
5. Red Team 指出遗漏的风险
6. 全体讨论改进项，按优先级排序
7. Scribe 记录并归档

---

🔗 DAG 依赖编排

复杂项目的多个 Unit 之间存在依赖关系，用 DAG（有向无环图）管理：

Unit A（用户模型）
   ↓
Unit B（认证服务） ←→ Unit C（权限服务）
   ↓                    ↓
Unit D（API 网关） ← Unit E（业务接口）
   ↓
Unit F（前端页面）

执行规则：

• 无依赖的 Unit 可并行开发
• 有依赖的 Unit 必须等前置 Unit 通过 Gate
• 发现循环依赖时，Planner 重新拆分

---

💡 使用示例

示例1：Bug 修复（快速流程）

用户：生产环境登录接口偶尔 500 错误

AI-DLC：
1. Elaboration（Planner）：
   - 收集日志、复现条件、影响范围
   - 输出 Intent："修复登录接口偶发 500 错误"

2. Execution（Builder + Reviewer）：
   - Unit：修复连接池超时问题
   - Backpressure：单元测试 + 类型检查 + 审查

3. Operation（Blue Team）：
   - 金丝雀发布，监控错误率

4. Reflection（Scribe）：
   - 根因：连接池配置不合理
   - 改进：建立连接池配置规范

示例2：新功能开发（完整流程）

用户：加一个用户积分系统

AI-DLC：
1. Elaboration（Planner + Skeptic + Red Team）：
   - Intent：用户积分获取/消费/查询
   - Skeptic：质疑是否需要实时计算
   - Red Team：攻击并发一致性假设
   - 最终 Intent 确认

2. Execution（多 Unit DAG）：
   - Unit 1：积分数据模型（无依赖）
   - Unit 2：积分获取接口（依赖 Unit 1）
   - Unit 3：积分消费接口（依赖 Unit 1）
   - Unit 4：积分查询接口（依赖 Unit 1）
   - Unit 5：前端积分页面（依赖 Unit 4）
   - 每个 Unit 通过 Backpressure Gate

3. Operation：
   - 灰度发布，监控积分一致性

4. Reflection：
   - 并发处理方案有效
   - 改进：积分日志需要更详细的审计

---

🆚 与其他方法论的关系

	AI-DLC	BMAD	OpenSpec-SDD
核心	四阶段生命周期	多角色协作	规范先行
特色	质量门控 + 反思	文档分片 + 上下文工程	六阶段评审
适用	全流程项目管理	中大型产品开发	需求对齐
最佳组合	AI-DLC 管流程 + BMAD 管角色 + SDD 管规范

推荐组合方式：

AI-DLC 四阶段框架
├── Elaboration：调用 OpenSpec-SDD 做规范评审
├── Execution：调用 BMAD 的多角色协作开发
│   ├── Planner → PM
│   ├── Builder → Dev
│   └── Reviewer → QA
├── Operation：调用 systematic-debugging 处理线上问题
└── Reflection：调用 hermes-experience 沉淀经验

---

🚀 快速开始

用户：我想用 AI-DLC 方法开发一个 [功能]

AI：
1. 确认进入 Elaboration 阶段
2. Planner 帽子：分析需求，输出 Intent
3. 用户确认 Intent
4. 进入 Execution 阶段，Builder 拆分 Units
5. 逐个实现，通过 Backpressure Gate
6. 进入 Operation 阶段（如需上线）
7. 进入 Reflection 阶段（运行稳定后）

---

"质量不是测试出来的，是流程保证的。AI-DLC 让质量内建于每个阶段。"