Marico's space
最近折腾了 AI-DLC（AI-Driven Development Life Cycle），踩了几个坑，这篇把问题说清楚。
先说结论：AI-DLC 是 AWS 出的一个基于规则的引导系统——不是工具，不是库——作用是把 AI 结对编程从"看心情 prompt"变成结构化的三阶段生命周期（Inception → Construction → Operations）。它跑在任何支持规则文件的 AI 编码助手上：Kiro、Amazon Q、Cursor、Claude Code、Copilot 都能用。规则文件内容全平台一样，只是存放路径不同。状态存在普通的工作区文件里，所以中途换 IDE 不会丢进度。
.kiro/steering/、.cursor/rules/、CLAUDE.md 等）。aidlc-docs/aidlc-state.md）实现。周一在 Cursor 打开，周三切到 Claude Code——AI 读同样的状态文件，从上次断点继续。我们都遇到过。你打开 AI 编码助手——Claude Code、Cursor、Copilot 随便哪个——输入"帮我写个用户 API"。AI 立马开始写代码，选了 REST（你本来想要 GraphQL），用了 Express（团队用的是 Fastify），新建了一个认证服务（你已经有了），还无视了公司的错误码规范。
根本问题不在 AI 的编码能力，而在没人让 AI 先问问题。
AI-DLC 的做法是在写代码之前插入一个结构化的提问和规划阶段。区别就像：一个是 junior 上来就敲键盘，另一个是 senior 架构师会说"等等，先让我搞清楚需求、看看现有系统、提出方案再动手"。
讲机制之前，先说设计原则：
| 原则 | 实际含义 |
|---|---|
| 自适应执行 | 只执行有价值的阶段；bug fix 不需要写用户故事 |
| 人肉把关 | AI 提方案，人拍板——每个阶段都有明确的审批门槛 |
| 方法论优先 | 跟 agent/IDE/model 无关；只要规则文件能加载就能跑 |
| 可复现 | 规则足够明确，不同 AI 模型产出相似结果 |
| 不重复造轮子 | 单一信息源；生成产物而不是维护副本 |
AI-DLC 把开发分成三个阶段，每个阶段回答不同问题：
Inception——确定 WHAT 和 WHY。这里澄清需求、理解现有代码、规划工作。包含六个阶段：工作区检测、逆向工程、需求分析、用户故事、工作流规划、应用设计。简单 bug fix 绝大部分会跳过；新平台开发则全量执行。
Construction——解决 HOW。这是 per-unit loop，每个系统模块独立设计、编码、测试。包含：功能设计、NFR 需求、NFR 设计、基础设施设计、代码生成（plan + execute）、构建与测试。
Operations——解决 DEPLOY 和 RUN。目前是占位符，后续会有部署、监控、故障响应、运维等阶段。
框架用三个深度等级来调整文档详略，匹配问题复杂度：
| 深度 | 触发条件 | 例子 |
|---|---|---|
| Minimal | 需求清晰简单 | 根因明确的 bug fix |
| Standard | 一般复杂度，有模糊地带 | 范围明确的功能开发 |
| Comprehensive | 高风险、多方干系人 | 系统迁移、新平台 |
关键点：阶段选择是二元的（执行或跳过），但已执行阶段的内部详略是可变的。所有必选产物都会生成，只是内容深度不同。
当你让 AI 往一个 50 个文件的现有代码库"加个支付功能"，AI 需要先理解当前架构才能做出合理的增量。没有逆向工程，AI 可能重复造服务、忽略既有模式、破坏既有约定。
触发条件：只有"棕地"项目（有现有代码）才会执行。绿地（空目录）项目完全跳过。
产出内容——假设你有一个现有电商后端：
aidlc-docs/inception/reverse-engineering/
├── business-overview.md ← "系统处理订单、库存和物流"
├── architecture.md ← 系统图：API网关 → 函数计算 → 表格存储
├── code-structure.md ← 文件清单："src/handlers/order.ts 处理 POST /orders"
├── api-documentation.md ← "GET /products 返回商品列表，POST /orders 创建订单"
├── component-inventory.md ← "3个函数，2张表，1个OSS bucket"
├── technology-stack.md ← "Java 17、Alibaba Cloud SDK、JUnit 5"
├── dependencies.md ← "order-service 通过 MNS 依赖 inventory-service"
└── code-quality-assessment.md ← "80%覆盖率，SpotBugs已配置，无技术债"
为什么重要：后续所有阶段（需求、设计、代码生成）都会加载这些产物。后面 AI 生成代码时，知道该改哪个文件 vs 创建新文件、该遵循哪个模式、哪些服务已存在、依赖图是什么样的。
过期检测：如果隔了几个月恢复项目，代码库已有大量变更，Workspace Detection 会把产物时间戳跟最新代码修改时间对比。产物过期就触发重新生成。
这是 AI-DLC 里比较微妙的一组关系，一开始让我困惑。它们名字听起来像，但职责完全不同。
应用设计 = "有哪些构建块？"识别高层组件、明确职责、描述交互。可以理解为在架构白板上画框框。
一个"任务管理 SaaS"项目，应用设计产出：
## 识别的组件：
- TaskService：任务CRUD、分配逻辑
- NotificationService：邮件/推送通知
- AuthService：用户认证鉴权
- AnalyticsService：用量统计和报表 ## 组件接口：
- TaskService.createTask(userId, taskData) → Task
- TaskService.assignTask(taskId, assigneeId) → void
- NotificationService.send(userId, template, data) → void ## 依赖关系：
- TaskService → NotificationService（分配时触发通知）
- TaskService → AuthService（校验权限）
- AnalyticsService → TaskService（读取事件）
单元生成 = "怎么拆成可并行的工作包？"接收应用设计输出，按工作单元分组——能独立开发的逻辑范围。
关系是单向的：应用设计关注架构（存在什么、怎么连接），单元生成关注开发策略（先做什么、什么可以并行）。简单项目可能需要应用设计但跳过单元生成（单个单元），复杂项目两者都需要。
工作单元是一组相关的故事/功能的逻辑分组，能作为整体设计、编码、测试。它不是微服务、不是单个文件、不是冲刺。它是能交给一个开发者（或一个 AI 会话）的最小系统块，让他"把这个完整做出来"。
跟架构类型的映射：
| 架构 | 单元 = |
|---|---|
| 微服务 | 一个可独立部署的服务 |
| 单体 | 边界清晰的一个逻辑模块 |
| 全栈功能 | 一个能力的前端 + 后端 + 数据库 |
每个单元都走自己完整的设计-构建循环：
Unit 1 → 功能设计 → NFR → 代码生成 → ✅ 完成
Unit 2 → 功能设计 → NFR → 代码生成 → ✅ 完成
Unit 3 → 功能设计 → NFR → 代码生成 → ✅ 完成
...
所有单元完成 → 构建与测试（跨单元集成）
NFR（Non-Functional Requirements）= 系统的质量属性和约束，不是功能本身，而是"做得多好"。
| 类别 | 功能性（是什么） | 非功能性（多好） |
|---|---|---|
| 性能 | "用户可以搜索商品" | "搜索在 p99 下返回 < 200ms" |
| 安全 | "用户可以登录" | "密码用 bcrypt 哈希，会话24小时过期" |
| 扩展性 | "系统处理订单" | "峰值可处理 1 万并发订单" |
| 可用性 | "服务可访问" | "99.9% SLA，自动故障切换" |
| 可靠性 | "数据被存储" | "零数据丢失，RPO < 1 分钟" |
AI-DLC 每个单元有两个 NFR 阶段：
NFR 需求评估 NFR 设计
（需要什么质量属性？） （技术层面怎么实现？） "需要 < 200ms 响应时间" → "使用 Redis 缓存层 + CDN"
"需要 99.9% 可用性" → "多可用区部署 + 健康检查"
"需要等保三级合规" → "传输加密、敏感字段脱敏"
NFR 需求评估问：扩展性预期是什么？性能基准多少？安全合规标准？技术栈偏好？
NFR 设计把答案转化为具体的架构模式、技术选型及理由、基础设施需求。
大多数 linting 和合规工具只会产生警告，开发者直接无视。AI-DLC 扩展不一样——它们是阻塞性约束。代码违规就停流程。
每个扩展恰好两个文件：
extensions/your-category/your-extension/
├── your-extension.md ← 完整规则（用户选择启用才加载）
└── your-extension.opt-in.md ← 轻量问题（始终加载）
opt-in 文件（轻量，始终加载）：
## Opt-In Prompt
是否启用等保三级合规规则？
A) 是 — 强制执行数据安全处理规则
B) 否 — 跳过合规检查
规则文件（完整，用户启用才加载）：
## Rule 等保-01：数据分类分级
**规则**：所有数据模型必须将字段标记为敏感/非敏感...
**验证**：不存在缺少敏感字段标记的模型... ## Rule 等保-02：最小权限访问
**规则**：API 端点必须对敏感字段实现基于角色的访问控制...
**验证**：不存在缺少角色校验就返回敏感数据的端点...
代码生成阶段： AI 生成了一个没有加密的表格存储表 ↓ 扩展 SECURITY-01 检查："传输加密已启用？" → 否 ↓ ⛔ 阻塞性发现 — 阶段无法完成 ↓ 用户只看到"请求修改"选项（没有"继续"） ↓ AI 必须修复违规才能继续流程
| 类别 | 扩展示例 |
|---|---|
| 安全 | 等保三级控制、PCI DSS 要求、零信任网络规则 |
| 合规 | 个保法数据处理、等保 PHI 规则、密评控制 |
| 编码规范 | 内部 SDK 使用、命名规范、API 版本策略 |
| 架构 | 微服务边界、事件驱动模式、无共享规则 |
| 测试 | 最低覆盖率阈值、变异测试、混沌工程 |
| 运维 | 运维手册要求、可观测性标准、SLO 定义 |
关键设计决策：没有 opt-in 文件的扩展始终强制执行（用户没得选）。N/A 规则只记录不阻塞。阶段完成时汇总扩展合规情况。
这是让我盯着代码库看了一段时间才想通的东西。AI-DLC 用双层文件系统，两层职责完全不同：
第一层——规则文件（AI 怎么工作）：这是静态的，流程执行期间不变。通过平台原生规则机制加载：
| 平台 | 规则文件位置 |
|---|---|
| Kiro IDE | .kiro/steering/aws-aidlc-rules/core-workflow.md |
| Amazon Q | .amazonq/rules/aws-aidlc-rules/core-workflow.md |
| Cursor | .cursor/rules/ai-dlc-workflow.mdc |
| Claude Code | CLAUDE.md |
| Copilot | .github/copilot-instructions.md |
第二层——工作流产物（执行过程中生成的状态）：这是动态的，随流程推进创建/更新。放在 aidlc-docs/，这是全平台通用的位置：
aidlc-docs/
├── aidlc-state.md ← "流程进行到哪了？"
├── audit.md ← "发生了什么？完整历史"
├── inception/
│ ├── plans/ ← 执行计划、阶段计划
│ ├── reverse-engineering/ ← 架构、组件、API
│ ├── requirements/ ← 需求、验证问题
│ ├── user-stories/ ← 故事、角色
│ └── application-design/ ← 组件、服务、单元
├── construction/
│ ├── plans/ ← 各单元代码生成计划
│ ├── {unit-name}/ ← 按单元的设计文档
│ │ ├── functional-design/
│ │ ├── nfr-requirements/
│ │ ├── nfr-design/
│ │ ├── infrastructure-design/
│ │ └── code/ ← 仅 Markdown 摘要，不存实际代码
│ └── build-and-test/
└── operations/ ← 后续占位
类比：规则文件 = 菜谱（怎么做菜的指令），aidlc-docs/ = 厨房（实际做菜的地方、成品存放处）。菜谱告诉你"检查烤箱温度"——烤箱和菜谱是分开的。
AI 编码助手不记对话历史。每次新会话从零开始。AI-DLC 的解法：用工作区文件作为持久化记忆，跨会话存活。
aidlc-docs/aidlc-state.md" ## 当前状态
- **当前阶段**：CONSTRUCTION - 代码生成
- **下一阶段**：单元 2 代码生成
- **最后完成**：单元 1 代码生成（2024-03-15）
aidlc-docs/）方案精妙之处：
平台特定规则位置 ──▶ 指令（内容相同） ──▶ 通用工作区文件 .kiro/steering/ ─┐
.amazonq/rules/ ─┤ aidlc-docs/
.cursor/rules/ ─┼─▶ core-workflow.md ──▶ ├── aidlc-state.md
CLAUDE.md ─┤ （规则一样！） ├── audit.md
copilot-instr.md ─┘ └── inception/...
规则文件内容完全相同，只有路径不同。你完全可以在项目中途换 IDE：Day 1 用 Cursor → 生成 aidlc-docs/。Day 5 切到 Claude Code → 读取同样的 aidlc-docs/，从状态继续。
部分平台提供比 AI-DLC 文件方案更强的会话保持：
| 平台 | 额外功能 | 对 AI-DLC 的增益 |
|---|---|---|
| Claude Code |
--continue / --resume 参数 |
可恢复精确对话 + 文件状态 |
| Claude Code | 自动记忆系统 | 跨项目学习用户偏好 |
| Kiro IDE | 条件引导（文件匹配模式） | 可加载阶段特定规则 |
| Cursor |
alwaysApply vs 条件规则 |
常驻确保流程不被遗忘 |
重要限制：AI 上下文窗口是有限的。即使恢复会话，如果项目有 20+ 产物，AI 必须选择性加载相关内容。AI-DLC 用"按阶段智能加载上下文"处理这个问题：早期阶段只加载工作区分析；设计阶段加载需求 + 故事 + 架构；代码阶段加载全部产物 + 现有代码。
每个阶段都遵循：生成 → 展示 → 等待 → 记录
AI 生成产物 │ ▼
展示完成消息，包含： 📋 需要审核（产物链接） 🚀 下一步： 🔧 请求修改 ✅ 批准并继续 │ ▼
⛔ 门控：必须明确批准才能继续 │ ▼
记录用户完整原始响应到 audit.md（ISO 8601 时间戳）
这产生了完整的审计追踪。对于受监管行业，你能追溯为什么做了某个架构决策、谁批准的、当时有哪些上下文。
AI-DLC 明确防止常见的 AI 问题："假设而不是提问"：
旧 AI 行为： AI-DLC 强制行为：
───────────────── ────────────────────────────
用户："写个用户 API" 用户："写个用户 API"
AI：*立刻开始写代码* AI：*生成8个澄清问题* （假设 REST、假设 Java、 - REST 还是 GraphQL？ 假设 MySQL、假设不需要缓存...) - 认证方式？ - 预期请求量？ - 数据保留要求？ ... AI：*等待回复* AI：*分析回复中的模糊点* AI：*追问模糊回答* AI：*确认上下文后开始*
AI 必须检测的用户回答红旗：
audit.mdaidlc-state.md 让任何平台都能跨会话恢复aidlc-docs/、规则在平台指定位置AI-DLC 最有用的情况：
个人练手项目或快速原型可能用不上。自适应深度系统能缓解这个问题，但提问阶段本身有固定开销。扩展系统让它对企业特别有价值——你可以把整套内部开发规范写成阻塞规则。
不是。AI-DLC 是一组规则文件（Markdown 文档），放到项目规则目录即可。没有 CLI、没有 npm 包、没有二进制。你现有的 AI 编码助手读取规则、遵循方法论。Kiro、Amazon Q、Cursor、Claude Code、Copilot 以及其他支持指令/规则文件的 agent 都能用。
可以——Claude Code 是支持的平台之一。你可以直接把 AI-DLC 规则放进 CLAUDE.md，或者通过 include 路径引用。Claude Code 的 --continue 参数在 AI-DLC 文件状态系统之上提供额外的会话连续性。自动记忆功能也会跨项目学习你的偏好。
框架是自适应的——对于真正简单的任务，AI 会提议最小路径。但强制跳过复杂任务意味着丢掉逆向工程上下文、需求澄清和架构规划。常见失败模式是 AI 因为没扫描代码库而重复造服务或破坏既有模式。
两个关键区别：范围和执行力度。Linting 规则在文件级别检查语法和风格。AI-DLC 扩展在架构级别运作——"所有 API 必须版本化"、"每个数据模型需要敏感字段分类"、"有状态服务最少 3 副本"。而且是阻塞的：流程物理上无法继续直到违规解决。没有"忽略此警告"的退路。
每个扩展有 opt-in.md 文件（轻量，始终加载——问用户是/否问题）和完整规则文件（完整，用户启用才加载）。这让 system prompt 保持精简，同时允许任意复杂的规则集。没有 opt-in 文件的扩展始终强制——用户没得选。
可以——这是明确支持的使用方式。aidlc-docs/ 里的工作流状态是平台无关的。开发者 A 用 Cursor，开发者 B 用 Claude Code，开发者 C 用 Amazon Q。他们都读写同一个 aidlc-docs/aidlc-state.md 和产物文件。唯一跟 IDE 相关的文件是规则存放位置，而且那些文件内容完全一致。