# Agentic AI 时代，软件工程该怎么做？

> AIDLC（AI Development Life Cycle）：当 AI 深度参与软件开发，传统 SDLC 需要怎样的重构？从需求、设计到测试部署的全流程实践。

- 作者: zhuermu
- 发布: 2026-05-27
- 网页版: https://zhuermu.com/blog/aidlc-ai-coding/

---

一套完整的 AI-DLC 方法论

AI-DLC · Spec-Driven · Harness Engineering · 写给每一个想让 AI 真正帮上忙的开发者

## 引 AI 写代码很快，但你的项目真的变快了吗？

2026 年，几乎所有开发者都用上了 AI 编程工具。但一个尴尬的现实是：**代码产出快了 10 倍，产品迭代速度可能只快了 10%。**

因为大多数人还停留在两个极端：

| AI 辅助模式 | AI 完全自主模式 |
| --- | --- |
| Copilot / ChatGPT 补全片段 人做所有决策 AI 不理解全局上下文 **效率：1.2x–2x** 远未达到预期 | Vibe Coding / 无监督 Agent AI 从头到尾独立完成 输出随机、不可预测 **可用率：20-40%** 大量返工甚至重做 |

**✦ AI-DLC 的核心洞察**

不是让 AI 做得更多或更少，而是在正确的环节用正确的方式协作
Spec 约束 + 知识库 + 人工审查 = 可控的高效率
**效率提升：5x–10x，且输出可控、可验证**

• • •

## 1 从 SDLC 到 AI-DLC：三阶段

传统软件开发生命周期（SDLC）大家都熟：需求 → 设计 → 开发 → 测试 → 部署 → 运维。每一步都是人在驱动。

AI-DLC 把这个流程重新设计成**三个阶段**：

| 1 **Inception 构思** 人主导 • 需求结构化为 Spec • 建立知识库 • 拆分工作单元 • 定义验收标准 | → | 2 **Construction 构建** AI 主导 • 按 Spec 逐任务编码 • 生成测试用例 • 生成 IaC • 人审关键逻辑 | → | 3 **Operations 运维** 人+AI 协同 • IaC 部署生产 • AI 驱动事件响应 • 知识库持续更新 • 经验回流 Inception |
| --- | --- | --- | --- | --- |

**核心特征：**每个阶段为下一阶段构建更丰富的上下文。知识不断累积，AI 越用越聪明——这就是飞轮效应。

### Inception 阶段的核心动作：Spec Q&A 循环

**不是人一次性写完需求，而是人给出模糊意图，AI 反复提问澄清，直到双方对齐。**

### 实操示例：需求澄清怎么做

你只需要给 AI 一段简短的产品描述 + 一个"需求澄清提示词"，AI 就会像一个专业产品经理一样反复追问你。

▼ 需求澄清提示词（一次写好，反复复用）

# 角色

你是一位专业的产品经理，负责创建定义明确的用户故事——它们将成为开发系统的契约。

# 工作方式

1. 在

requirements_plan.md

写下你的步骤，每步加复选框

2. 任何需要我澄清的步骤，用

[Question]

标签提问

3. 创建

[Answer]

标签 + 多个推荐选项 + 一个空选项让我填其他

4. 如果我的回答不清楚，在原问题加

Updated

追加追问

5. 通过多轮迭代，直到你完全理解我的意图

6. 同时提出非功能性需求的问题（性能/规模/部署等）

7.

不要自行做关键决策

，完成计划后请求我审批

8. 我批准后再逐步执行，输出中文需求文档

9. 每完成一步，把对应复选框标记为已完成

# 任务

根据下面的产品描述，在 Spec 中创建 Requirements。

▼ 你给 AI 的产品描述

产品描述：构建一个名为"积分商城"的内部员工福利电商网站。

MVP 验证员工积分兑换系统的商业模式。

核心功能：

- 员工：浏览和兑换产品、查看积分余额和兑换历史

- 管理员：配置产品信息、管理员工积分（发放和扣除）

▼ AI 自动生成 requirements_plan.md，带着问题来找你

## 需求澄清

[Question 1]

积分来源

员工的积分从哪里来？

 A. 管理员手动发放（MVP 最简）

 B. 与 HR 系统对接，按绩效自动发放

 C. 两者都要

 D. 其他：___

[Answer]:

A

[Question 2]

商品库存

商品是否需要库存管理？

 A. 不需要，无限量兑换

 B. 需要，库存为 0 时不可兑换

 C. 其他：___

[Answer]:

B

[Question 3]

非功能性需求

预期用户量级？

 A. < 100 人（单机部署即可）

 B. 100-1000 人（需考虑并发）

 C. > 1000 人（需分布式架构）

 D. 其他：___

[Answer]:

___

**关键设计：**AI 不自行做决策，而是给你选项让你拍板。每个问题都有多个选项 + 一个空选项让你填写其他想法。通过多轮迭代，直到 AI 完全理解你的意图。

### 实操示例：设计澄清怎么做

需求对齐后，进入设计阶段。同样的模式——AI 生成 design_plan.md，带着架构决策问题来找你。

▼ 设计澄清提示词

# 任务

进入设计阶段，请你提设计层面的问题，并在

design_plan.md

写下步骤，每步加复选框。

# 工作方式

1. 任何需要我澄清的步骤，用

[Question]

标签提问

2. 创建

[Answer]

标签 + 多个推荐选项 + 一个空选项让我填其他

3. 如果我的回答不清楚，在原问题加

Updated

追加追问

4. 通过多轮迭代，直到你完全理解我的意图

5.

不要自行做关键决策

，完成计划后请求我审批

6. 我批准后再逐步执行

7. 每完成一步，把对应复选框标记为已完成

▼ AI 生成的 design_plan.md

# 积分商城设计计划

## 阶段 0：范围与关键决策对齐

[Question 1]

技术栈选择

前端框架选择？

 A. React + TypeScript（生态最成熟）

 B. Vue 3 + TypeScript（团队更熟悉）

 C. Next.js（需要 SSR/SEO）

 D. 其他：___

[Answer]:

A

[Question 2]

部署方式

 A. 容器化部署（ECS/EKS）

 B. Serverless（Lambda + API Gateway）

 C. 传统 EC2

 D. 其他：___

[Answer]:

B

[Question 3]

数据库选择

 A. PostgreSQL（关系型，适合事务）

 B. DynamoDB（Serverless 原生，免运维）

 C. 其他：___

[Answer]:

B

**所有决策对齐后，AI 才开始正式输出设计文档。**这就是 AI-DLC 里"人主导"的含义——不是人写文档，而是人做决策，AI 做执行。

**✦ 这个模式的本质**

AI 是**提问者和执行者**，人是**决策者和审批者**。需求不是一次写完的，而是通过 Q&A 循环反复澄清的。

• • •

## 2 AI-DLC 核心五步

整个 Construction 阶段的执行循环：

| START | → | 1 **AI** 创建计划 | → | 2 **人类** 验证计划 | ✓通过→ | 4 **AI** 执行计划 | → | 5 **人类** 验证结果 | → | END |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| | ✗不通过 ↓ | | | | | | | | | |
| | 3 **AI** 修改计划 ↑ 修改后回到 ② | | | | | | | | | |

●

AI 主导步骤

●

人类决策步骤

- -

反馈循环（迭代直至通过）

关键设计：

• **步骤 2 和 5 是人类决策点**——AI 不能自己决定计划是否合理、结果是否正确

• **步骤 3 是反馈循环**——不通过就迭代，直到人满意为止

• **AI 负责执行（1/3/4），人负责决策（2/5）**

• • •

## 3 Spec-Driven 开发：AI-DLC 的骨架

Spec-Driven 不只是"写代码前写文档"。它贯穿需求分析、模块划分、接口设计、任务拆解、AI 编码、验收测试**全流程**——Spec 是 AI-DLC 的骨架。

### 一个具体例子：Spec 质量如何决定 AI 产出

假设你要做一个"用户注册"功能。

▼ ❌ 传统做法（给 AI 一句话）

"帮我做一个用户注册功能"

AI 会随便写——可能用邮箱注册、可能用手机号、密码规则不确定、注册后跳转哪里也不知道。**产出可用率 30%。**

▼ ✅ Spec-Driven 做法（给 AI 一份结构化 Spec）

功能：

用户注册

接口：

POST /api/auth/register

请求体：

{ email: string, password: string, name: string }

密码规则：

≥8 位，含大小写 + 数字

成功响应：

201 { userId, token }

失败响应：

409 邮箱已存在 / 422 参数校验失败

验收标准：

- Given 有效邮箱和密码 → When 注册 → Then 返回 201 + token

 - Given 已存在的邮箱 → When 注册 → Then 返回 409

 - Given 密码不足 8 位 → When 注册 → Then 返回 422

AI 读到这份 Spec，**产出可用率 95%+**。写 Spec = 写 20% 的代码，获得 5x 效率。

### 真实案例：AWS Bedrock 团队

| **6** 人工程团队 原计划 30 人 | **76** 天完成交付 原预估 12-18 个月 | Spec 先行 + 群建模式（多 Agent 并行） + 每次提交人审 + 知识飞轮 |
| --- | --- | --- |

**启示：**AI-DLC 不是减少人——而是改变人的角色：从"写代码的人"变成"管理 AI 写代码的人"。

### 多 Agent 并行：怎么让 3 个 Agent 不打架？

答案是**契约**。就像三个施工队在三个房间各自装修，只要都看同一份施工图纸就不会冲突：

• **前端 Agent**（分支 feat/ui）：根据 API Spec 生成 Mock 数据，不需要等后端

• **后端 Agent**（分支 feat/api）：根据同一份 API Spec 实现接口，跑契约测试验证格式

• **测试 Agent**（分支 feat/test）：根据 Spec 提前写好 E2E 测试，不需要等代码写完

三个 Agent 之间不需要互相"说话"，它们只需要看同一份契约文档。人的关键决策是：模块边界怎么划、契约怎么定义、最后合并时冲突怎么解决。

**OpenAI 内部实践：**他们的 Frontier Product Exploration 团队用 Codex 在 5 个月内生成了超过 100 万行代码，处理了数千个 PR，每天消耗约 10 亿 Token——零人工手写代码。

关键不是 Agent 多厉害，而是 Spec + 契约 + Harness 让这个规模成为可能。

• • •

## 4 Harness Engineering：给 AI 装上导轨

讲完了 Spec-Driven 怎么让 AI 知道**"该做什么"**，下一个问题来了：**怎么保证 AI 不会跑偏？**

想象一下，你给 AI Agent 写了一份完美的 Spec，它在 5 分钟内生成了 2000 行代码。但你打开一看——它擅自删了一个你以为不该改的文件、调用了一个测试环境不该用的真实 API、还在 main 分支直接 push 了。

这不是 AI 不够聪明的问题，是**没人给它划边界**的问题。这就是 2026 年最重要的新工程学科——**Harness Engineering**。

### 什么是 Harness？

Harness 直译是"安全带 / 缰绳"。但在 AI-DLC 里，它**不是限制 AI**，而是**给 AI 装上导轨**——让它能跑得更快但不翻车。

**✦ 一句话定义**

"Agent 能看到什么 + 能做什么 + 做错了怎么办"

### 从 Prompt → Context → Harness 的进化

很多人会问：那 Harness 跟之前流行的 Prompt Engineering、Context Engineering 是什么关系？

答案是：**三者是嵌套关系，每一层包含前一层**——

| **Harness Engineering** — 系统/组织级别 "能做什么 + 做错了怎么兜底" **Context Engineering** — 项目/Session 级别 "Agent 能看到什么" **Prompt Engineering** "怎么跟 Agent 说话" — 单轮对话级别 |
| --- |

三层的演化路径其实回答了一个问题：**我们对 AI 的掌控粒度，从"一句话"放大到了"一整个生产环境"。**

• **Prompt Engineering** 解决"怎么说"——给 AI 一句清晰的指令

• **Context Engineering** 解决"看到什么"——给 AI 项目级的持久上下文

• **Harness Engineering** 解决"能做什么 + 做错了怎么兜底"——给 AI 整个组织级的运行环境

**类比：**Prompt 像跟司机说目的地，Context 像给司机一张地图，**Harness 是给整辆车装上方向盘、刹车、安全带、车道线和监控系统**。

### Harness 的六大支柱

具体到工程实践，Harness 由六个支柱组成。前四个管 AI 的"运行时行为"，后两个管"维护期质量"——你会发现这些不是新概念，但是**第一次被组织成一个完整的工程体系**：

| 支柱 | 解决什么 | 举例 |
| --- | --- | --- |
| **Powers / Permissions** | Agent 能做什么 | 文件/命令/网络权限白名单 |
| **Context Engineering** | Agent 能看到什么 | Steering 文件、MCP 工具、项目规范 |
| **Constraints** | Agent 必须遵守什么 | 依赖方向、命名规范、架构边界 |
| **Feedback Loops** | 做错了怎么办 | 死循环检测、Generator-Evaluator 分离 |
| **Cleanup / 熵管理** | 代码腐烂怎么办 | 文档园丁 Agent、死代码清理 |
| **Testing Harness** | 怎么验证产出 | 契约测试、E2E、预览环境 |

下面我们挑其中几个最关键的支柱展开讲——**Context（上下文管理）、Constraints（约束）、Cleanup（熵管理）、Feedback Loops（反馈循环）**。这四个支柱构成了 AI-DLC 实战中最核心的工程实践。

### 先说两个不展开但很重要的支柱

在深入展开 4 个核心支柱之前，先快速过一下另外两个支柱——**Powers/Permissions** 和 **Testing Harness**，它们更偏向 DevOps/运维侧的常规实践，但同样不可或缺。

▼ Powers / Permissions（能力与权限）

解决：Agent 能做什么、不能做什么。具体分四个维度：

| **文件权限** | 只能读写 src/，不能碰 .env、deploy-prod.sh |
| --- | --- |
| **命令权限** | 可以跑 npm test，不能跑 rm -rf、git push --force |
| **工具权限** | 可以调用数据库查询 MCP，不能调用删除接口 |
| **网络权限** | 可以访问内部 API，不能发外部 HTTP 请求 |

**类比：**给实习生一把只能开特定房间的门禁卡。让他能干活，但不能误删生产数据库。

▼ Testing Harness（测试约束）

解决：怎么验证 Agent 的产出是对的。具体包括：

• **契约测试**：前后端 Agent 各自开发，用 OpenAPI Spec 做接口契约验证

• **AI 生成测试 + 人审场景**：AI 写测试用例，人确认覆盖了正确的场景

• **预览环境**：每个 PR 自动部署到临时环境，人可以点击验证

• **覆盖率门槛**：低于 80% 不允许合并

**类比：**工厂流水线末端的质检站——产品出厂前必须过这一关。

### 为什么叫 "Engineering"？

很多人会问：这不就是写几条规则吗？为什么要起个"Engineering"这么大的名字？

因为这**不是写一个 prompt 就完事**——它是一整套工程体系：

Harness

=

Steering 文件

+

Rules / Constraints

+

MCP 工具配置

+

Hooks（pre-commit / post-task）

+

权限边界

+

反馈中间件

+

监控告警

就像 **DevOps 不是一个工具而是一套实践**，Harness Engineering 也是**围绕 AI Agent 的一整套运行时治理实践**——它需要工程化的设计、版本化的管理、可观测的监控、可演化的迭代。

下面我们就深入展开这个体系里最核心的四块——从**上下文管理**开始。

• • •

## 5 Context Engineering：上下文是 AI 的工作记忆

先讲六大支柱里最被低估、但实战中最影响产出质量的一个——**上下文管理**。

你有没有这种经历？跟 AI 聊到第十几轮，它突然开始**忘记你前面说过的话**——重复生成已经写过的代码、违反你早就定好的命名规范、或者把刚说"不要改"的文件又改了一遍。

这不是 AI 在偷懒，是它的**"工作记忆"满了**。

### 上下文窗口的物理限制

每个大模型都有一个有限的**上下文窗口**（比如 Claude 是 200K Token，GPT-5 是 256K）。这个窗口同时装着这些东西：

| **系统 Prompt** | AI 的角色定义、行为准则 |
| --- | --- |
| **+ 项目规范** | AGENTS.md / Steering 文件加载的内容 |
| **+ 当前任务代码** | 用 @ 引用的相关代码文件 |
| **+ 对话历史** | 前面所有轮次的问答内容 |
| **+ AI 输出** | 本次生成的代码 / 回复 |
| **= 剩余空间** | 越小越危险 |

窗口塞满了会怎样？AI 会**从最早的内容开始遗忘**——而最早的内容往往是你最重要的项目规范。结果就是：**产出质量下降、重复代码、矛盾逻辑、违反规范**。

**AI Ready 检查清单：**每次给 AI 任务前自问：
□ 项目规范在不在？ □ 相关代码引用了吗？ □ 窗口还有余量吗？

### 不同任务，需要的上下文完全不同

既然窗口有限，**"塞什么进窗口"**就是关键决策。AI-DLC 给了一个非常实用的**"上下文选择框架"**——按你当前所处的阶段和任务类型，选最该塞的内容。

| 阶段 / 任务 | 必要上下文 | 有益上下文 |
| --- | --- | --- |
| **Inception 设计文档** | 项目目的、范围、需求、约束 | 架构、技术栈、成功指标、图表 |
| **Construction 为已有代码加功能** | 代码结构、需求、编码规范、集成点 | 测试要求、文档标准、类似示例 |
| **Operations 调试** | Bug 描述、复现步骤、错误日志、受影响代码 | 近期变更、监控数据、调试记录 |
| **Operations 部署排障** | 错误信息、部署方式、环境状态 | IAM 权限、CloudWatch 日志 |

**这张表是上下文管理的"作弊小抄"**——拿到任务先问自己：现在是什么阶段？再对照表格喂上下文。比直接把整个 repo 扔给 AI 高效 10 倍。

### 静态上下文 vs 动态上下文

在喂上下文之前，还要先理解一个关键区分：

| 📚 静态上下文 | 📊 动态上下文 |
| --- | --- |
| repo 文档、架构规范、API 合约、ADR **原则：所有决策必须进 repo**——讨论达成的共识必须同步到文档 | 日志、指标、测试结果、浏览器截图 **能力：Agent 自己跑应用验证**——通过 DevTools 截图看 DOM、运行 curl 看响应 |

这个区分很关键：**静态上下文需要你提前准备好（写文档、写规范）；动态上下文 Agent 可以自己获取（跑命令、查日志）**。你不需要把所有日志提前贴给 Agent，给它一个能调用 CloudWatch 的 MCP 工具即可。

### 三大策略：提供、压缩、隔离

理解了上下文窗口的限制和按阶段的选择框架，下一步是**具体怎么管理**。AI-DLC 总结了三大策略：

1. **提供上下文**：让 AI 有"足够的知识"——但不是全塞进窗口，而是按需获取（MCP 工具、文件指针）

2. **压缩上下文**：在有限窗口内"最大化信息密度"——摘要旧对话、只留任务相关内容

3. **隔离上下文**：防止"跨任务污染"——每个功能用独立 Session，每个 Agent 用独立分支

| 提供上下文 | 压缩上下文 | 隔离上下文 |
| --- | --- | --- |
| • **长期记忆 Steering**：Agent 把经验写回文件，下次自动加载 • **Powers / Skills**：打包 MCP + Steering + Hooks，一键赋能 • **MCP 按需获取**：外部数据按需调用，不全塞窗口 • **持久化到文件**：阶段成果写入文件，释放窗口 | • **摘要压缩**：用 /summarize 压缩对话历史 • **选择与修剪**：仅保留与任务直接相关的内容，删除冗长调试记录 • **工具拆分**：只给当前任务需要的 MCP 工具——*每多一个工具 = AI 多一个"岔路口"* | • **任务隔离**：每个功能一个独立 Session，避免跨功能污染 • **分支隔离**：每个 Agent 在独立 Git 分支工作 • **范围控制**：限制 Agent 可访问的目录和工具 • 边界清晰 → 产出可控 |

**关键洞察：**你不需要手动提供每一条上下文。利用 Agent 的内置知识 + MCP 工具，**与它协作共建上下文**——它能问你的就让它问，它能跑命令查的就让它跑。

### 关键原则：做"目录"，不做"百科全书"

很多团队在落地时第一个错误就是——**把所有规则、架构、API 都塞进一个超大的 AGENTS.md 文件**，觉得越详细越好。

结果：

• 文件越来越大，规则越来越多，**没人维护、信息过时**；

• AI 每次都加载这一大坨，**浪费窗口空间**；

• 真正需要的规则**淹没在过时规则里**。

正确做法：让主文件只做**"目录"**，把具体内容拆到各自的文件里，需要时再加载。

▼ ✅ 正确做法（~60 行主文件，只放指针）

## Architecture →

docs/arch.md

## API →

docs/api-contracts/

## Conventions →

.cursor/rules/

▼ ❌ 错误做法

把所有规则、架构、API 文档全塞进一个 5000 行的 AGENTS.md

"A monolithic manual turns into a graveyard of stale rules" — OpenAI

**大而全的文档 ≠ 好文档。小而准的指针 > 大而全的手册。**主文件永远保持简洁；具体内容分散在各自文件里，各自维护，各自更新。

这个原则简单但反直觉。它的本质是：**上下文要"按需加载"，而不是"提前塞满"**——这跟微服务架构里的 lazy loading 是同一个思想。

• • •

## 6 Constraints：规则代替口头约定

### 依赖方向强制执行

| **Types** | → | **Config** | → | **Repo** | → | **Service** | → | **Runtime** | → | **UI** |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |

每层只能依赖左边 — 边界严格，内部自由

为什么这对 AI Agent 特别重要？人类开发者可能凭经验知道"这个不该引用那个"，但 AI Agent 不懂这种隐含规则。如果没有强制约束，Agent 会随便跨层调用，代码很快变成一团乱麻。

### 中央管控 vs 本地自治

• **中央管控**（不能让 Agent 自己决定）：模块间接口格式、依赖方向、数据格式、命名规范

• **本地自治**（让 Agent 自由发挥）：模块内部实现、算法选择、优化方式

### 具体例子：Linter 报错要对 Agent 友好

假设你的架构规则是：Controller 不能直接调用 Repository，必须通过 Service 层中转。

▼ ❌ 传统 Linter 报错（给人看的）

ERROR:

Illegal import at src/controllers/userController.ts:42

 → Cannot import from 'repositories' layer

人看到能理解，但 AI Agent 只知道"第 42 行有个非法 import"，不知道应该改成什么、中转层在哪、有没有参考案例。结果 AI 可能瞎改——删掉 import、换个路径、或者绕过检查。

▼ ✅ AI-Friendly Linter 报错（给 Agent 看的）

ERROR:

Architecture violation at src/controllers/userController.ts:42

Rule:

Controllers cannot import directly from repositories.

Fix:

Import the corresponding Service instead.

 Example: import { UserService } from '../services/userService'

Reference:

docs/architecture.md#dependency-rules

Agent 读到这条信息，**直接就能自动修复——不需要人介入**。

### 约束反而是加速器

没有约束时，Agent 面对无限可能性，会浪费大量 Token 去探索各种方案（很多是死胡同）。**清晰的约束 = 缩小搜索空间 = 更快收敛到正确答案。**

"This resembles leading a large engineering platform organization: enforce boundaries centrally, allow autonomy locally." — OpenAI Codex

**管 AI Agent 和管一个几百人的工程团队是一回事：中央管边界，本地给自由。**

• • •

## 7 用 Agent 清理 Agent 的混乱

AI 写的代码比人写的代码**腐烂得更快**——文档过时、命名漂移、死代码堆积。

为什么？因为人写代码时会本能地维护一致性——命名风格统一、删掉没用的代码、更新文档。但 AI Agent 没有这个本能。它每次生成都可能用不同的命名风格，不会主动删除旧代码，文档和代码容易脱节。

**OpenAI 的案例：**他们的 Frontier 团队 3 个工程师 5 个月写了 100 万行代码、数千个 PR。按这个速度，人根本来不及做清理工作。

所以必须**用 AI 的速度来对抗 AI 的混乱**——自动化清理跑得跟代码生成一样快。

### 自动化清理频率

| 频率 | 任务 | 实现 |
| --- | --- | --- |
| 每次提交 | 架构约束检查 | Custom Linter + CI |
| 每天 | 文档一致性扫描 | "Doc-gardening" Agent 自动开 PR |
| 每周 | 死代码清理 + 依赖审计 | 定时 Agent 扫描 + 提 PR |
| 每月 | 架构质量评分 | Agent 生成报告 + 人工审查 |

• • •

## 8 反馈循环：Harness 不是笼子，是导轨

三层反馈，缺一不可：

### 1. Agent 自检循环（单 Agent → 自己拦住低级错误）

• **LoopDetectionMiddleware**：检测死循环——改了 A 破了 B → 改 B 又破了 A → 自动停止并报告

• **PreCompletionChecklistMiddleware**：提交前验证——测试通过了吗？Lint 过了吗？文档更新了吗？

### 2. Generator-Evaluator 分离（Agent to Agent → 互相审查）

"Agent 自评总是过于乐观" — Anthropic Engineering

一个 Agent 写代码（Generator），另一个 Agent 审代码（Evaluator）。不通过就反馈重做。**就像写作文的人和改作文的人不能是同一个人——自己检查自己永远会漏。**

### 3. 人的反馈回归系统（Human to Agent → 持续进化）

这是 Mitchell Hashimoto（HashiCorp 联合创始人）的核心理念：

人发现 Agent 犯错

→

分析：缺什么上下文/规则？

→

让 Agent 自己写修复规则到 Steering 文件

→

下次遇到同样场景不再犯

**✦ 错误不是终点**

是 Steering 文件的新条目。每一次犯错都让系统变得更聪明——这就是飞轮效应。

没有反馈循环的 Harness 是牢笼，不是导轨。三层反馈缺一不可。

• • •

## 9 角色重定义：每个人的工作方式都在变

| 角色 | Before | After |
| --- | --- | --- |
| **产品经理** | 写 PRD → 传达给开发 | 写 Spec → AI 直接执行 |
| **开发者** | 逐行编码实现功能 | 监督 AI + Code Review |
| **架构师** | 画架构图 → 口头传达 | 规范写入知识库 → AI 遵循 |
| **QA** | 手动写测试、手动回归 | 定义策略 → AI 自动生成+执行 |
| **DevOps** | 手动配置 CI/CD | AI 生成 IaC → 人审批关键变更 |

**✦ 共同规律**

角色从"执行者"转变为"监督者 + 策略制定者"。

AI 做 80% 执行，人做 20% 决策——但决策创造 80% 价值。

• • •

## 10 想动手实践？AWS 官方 AI-DLC 工作流

看完方法论想立刻试试？AWS Labs 已经把整套 AI-DLC 工作流**开源**了，开箱即用：

🔗 **github.com/awslabs/aidlc-workflows**

⭐ 2.5k stars · MIT-0 License · AWS Labs 官方维护

### 这是什么

一套**"喂给 AI Coding 工具"的 Steering 规则集**——把 Inception → Construction → Operations 三阶段的所有提示词、决策点、产出规范打包好。下载放进项目，在对话框里说一句"**Using AI-DLC, ...**"，AI 就会自动按 AI-DLC 流程跟你工作。

### 支持哪些 AI Coding 工具

| 工具 | 配置文件位置 |
| --- | --- |
| Kiro / Kiro CLI | .kiro/steering/ |
| Amazon Q Developer | .amazonq/rules/ |
| Cursor IDE | .cursor/rules/ |
| Cline | .clinerules/ |
| Claude Code | CLAUDE.md / .claude/ |
| GitHub Copilot | .github/copilot-instructions.md |
| OpenAI Codex | AGENTS.md |

### 三步上手

1. **下载**：从 GitHub Releases 下 `ai-dlc-rules-v0.1.x.zip`

2. **解压**到你的 AI Coding 工具对应规则目录（见上表）

3. **触发**：在 AI Chat 里说出魔法句

▶

新项目：**"Using AI-DLC, build a ...（你的产品描述）"**

▶

老项目：**"Using AIDLC, analyze the project"**

AI 会自动进入 Inception 阶段，开始用 [Question]/[Answer] 多选题问你需求，全程**人审、人批、人决策**，所有产出物落到 `aidlc-docs/` 目录。

### 六大特性

| **Adaptive Intelligence** | 只跑对你这个需求有价值的阶段 |
| --- | --- |
| **Context-Aware** | 分析现有代码库和复杂度自动调整 |
| **Risk-Based** | 复杂改动深度处理，简单改动快速通过 |
| **Question-Driven** | 结构化多选问题写到文件里，不是聊天 |
| **Always in Control** | 每个阶段都需要人审批才能继续 |
| **Extensible** | 可叠加自定义规则（安全/合规/组织规范） |

**✦ 核心理念**

AI-DLC 是**方法论**，不是工具——它能跑在任何 IDE、任何 Agent、任何模型上。这套开源规则只是把方法论"打包成 AI 能直接读懂的格式"。

• • •

## ✦ 核心要点回顾

1. **范式转变**：软件开发从人驱动 → AI 原生，AI 是核心协作者

2. **AI-DLC 方法论**：AI 创建计划 → 人类验证 → AI 修改 → AI 执行 → 人类验证结果

3. **Spec-Driven**：Spec 质量决定 AI 产出质量。写 Spec = 写 20% 的代码，获得 5x 效率

4. **知识库飞轮**：静态上下文 + 动态 Steering + MCP 工具 = AI 越用越聪明

5. **质量保障**：TDD + Cleanup Agent + Human Review = 比传统方式更高的代码质量

6. **人不可替代**：AI 做 80% 执行，人做 20% 决策——但决策创造 80% 价值

**Let AI be your core collaborator,
not just a tool.**

如果这篇文章对你有帮助，欢迎**点赞、在看、转发**三连 🙏

关注我，持续分享 AI 时代的软件工程实战与深度思考