夜雨聆风
Agentic AI 时代,AI Coding 软件工程该怎么做?一套完整的 AI-DLC 方法论
引 AI 写代码很快，但你的项目真的变快了吗？
2026 年，几乎所有开发者都用上了 AI 编程工具。但一个尴尬的现实是：代码产出快了 10 倍，产品迭代速度可能只快了 10%。
因为大多数人还停留在两个极端：
|
|
|
|---|---|
|
|
|
1 从 SDLC 到 AI-DLC：三阶段
传统软件开发生命周期（SDLC）大家都熟：需求 → 设计 → 开发 → 测试 → 部署 → 运维。每一步都是人在驱动。
AI-DLC 把这个流程重新设计成三个阶段：
| 1
|
|
2
|
|
3
|
Inception 阶段的核心动作：Spec Q&A 循环
不是人一次性写完需求，而是人给出模糊意图，AI 反复提问澄清，直到双方对齐。
实操示例：需求澄清怎么做
你只需要给 AI 一段简短的产品描述 + 一个”需求澄清提示词”，AI 就会像一个专业产品经理一样反复追问你。
▼ 需求澄清提示词（一次写好，反复复用）
▼ 你给 AI 的产品描述
▼ AI 自动生成 requirements_plan.md，带着问题来找你
实操示例：设计澄清怎么做
需求对齐后，进入设计阶段。同样的模式——AI 生成 design_plan.md，带着架构决策问题来找你。
▼ 设计澄清提示词
▼ AI 生成的 design_plan.md
所有决策对齐后，AI 才开始正式输出设计文档。这就是 AI-DLC 里”人主导”的含义——不是人写文档，而是人做决策，AI 做执行。
2 AI-DLC 核心五步
整个 Construction 阶段的执行循环：
| START |
|
1
|
|
2
|
|
4
|
|
5
|
|
END |
|
|
||||||||||
| 3
|
● 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）
AI 读到这份 Spec，产出可用率 95%+。写 Spec = 写 20% 的代码，获得 5x 效率。
真实案例：AWS Bedrock 团队
| 6
|
76
|
Spec 先行 + 群建模式（多 Agent 并行）+ 每次提交人审 + 知识飞轮 |
多 Agent 并行：怎么让 3 个 Agent 不打架？
答案是契约。就像三个施工队在三个房间各自装修，只要都看同一份施工图纸就不会冲突：
• 前端 Agent（分支 feat/ui）：根据 API Spec 生成 Mock 数据，不需要等后端
• 后端 Agent（分支 feat/api）：根据同一份 API Spec 实现接口，跑契约测试验证格式
• 测试 Agent（分支 feat/test）：根据 Spec 提前写好 E2E 测试，不需要等代码写完
三个 Agent 之间不需要互相”说话”，它们只需要看同一份契约文档。人的关键决策是：模块边界怎么划、契约怎么定义、最后合并时冲突怎么解决。
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 装上导轨——让它能跑得更快但不翻车。
从 Prompt → Context → Harness 的进化
很多人会问：那 Harness 跟之前流行的 Prompt Engineering、Context Engineering 是什么关系？
答案是：三者是嵌套关系，每一层包含前一层——
Harness Engineering — 系统/组织级别
|
三层的演化路径其实回答了一个问题：我们对 AI 的掌控粒度，从”一句话”放大到了”一整个生产环境”。
• Prompt Engineering 解决”怎么说”——给 AI 一句清晰的指令
• Context Engineering 解决”看到什么”——给 AI 项目级的持久上下文
• Harness Engineering 解决”能做什么 + 做错了怎么兜底”——给 AI 整个组织级的运行环境
Harness 的六大支柱
具体到工程实践，Harness 由六个支柱组成。前四个管 AI 的”运行时行为”，后两个管”维护期质量”——你会发现这些不是新概念，但是第一次被组织成一个完整的工程体系：
|
|
|
|
|---|---|---|
| Powers / Permissions |
|
|
| Context Engineering |
|
|
| Constraints |
|
|
| Feedback Loops |
|
|
| Cleanup / 熵管理 |
|
|
| Testing Harness |
|
|
下面我们挑其中几个最关键的支柱展开讲——Context（上下文管理）、Constraints（约束）、Cleanup（熵管理）、Feedback Loops（反馈循环）。这四个支柱构成了 AI-DLC 实战中最核心的工程实践。
先说两个不展开但很重要的支柱
在深入展开 4 个核心支柱之前，先快速过一下另外两个支柱——Powers/Permissions 和 Testing Harness，它们更偏向 DevOps/运维侧的常规实践，但同样不可或缺。
▼ Powers / Permissions（能力与权限）
解决：Agent 能做什么、不能做什么。具体分四个维度：
| 文件权限 |
|
| 命令权限 |
|
| 工具权限 |
|
| 网络权限 |
|
▼ Testing Harness（测试约束）
解决：怎么验证 Agent 的产出是对的。具体包括：
• 契约测试：前后端 Agent 各自开发，用 OpenAPI Spec 做接口契约验证
• AI 生成测试 + 人审场景：AI 写测试用例，人确认覆盖了正确的场景
• 预览环境：每个 PR 自动部署到临时环境，人可以点击验证
• 覆盖率门槛：低于 80% 不允许合并
为什么叫 “Engineering”？
很多人会问：这不就是写几条规则吗？为什么要起个”Engineering”这么大的名字？
因为这不是写一个 prompt 就完事——它是一整套工程体系：
就像 DevOps 不是一个工具而是一套实践，Harness Engineering 也是围绕 AI Agent 的一整套运行时治理实践——它需要工程化的设计、版本化的管理、可观测的监控、可演化的迭代。
下面我们就深入展开这个体系里最核心的四块——从上下文管理开始。
5 Context Engineering：上下文是 AI 的工作记忆
先讲六大支柱里最被低估、但实战中最影响产出质量的一个——上下文管理。
你有没有这种经历？跟 AI 聊到第十几轮，它突然开始忘记你前面说过的话——重复生成已经写过的代码、违反你早就定好的命名规范、或者把刚说”不要改”的文件又改了一遍。
这不是 AI 在偷懒，是它的“工作记忆”满了。
上下文窗口的物理限制
每个大模型都有一个有限的上下文窗口（比如 Claude 是 200K Token，GPT-5 是 256K）。这个窗口同时装着这些东西：
| 系统 Prompt |
|
| + 项目规范 |
|
| + 当前任务代码 |
|
| + 对话历史 |
|
| + AI 输出 |
|
| = 剩余空间 |
|
窗口塞满了会怎样？AI 会从最早的内容开始遗忘——而最早的内容往往是你最重要的项目规范。结果就是：产出质量下降、重复代码、矛盾逻辑、违反规范。
不同任务，需要的上下文完全不同
既然窗口有限，“塞什么进窗口”就是关键决策。AI-DLC 给了一个非常实用的“上下文选择框架”——按你当前所处的阶段和任务类型，选最该塞的内容。
|
|
|
|
|---|---|---|
| Inception设计文档 |
|
|
| Construction为已有代码加功能 |
|
|
| Operations调试 |
|
|
| Operations部署排障 |
|
|
这张表是上下文管理的”作弊小抄”——拿到任务先问自己：现在是什么阶段？再对照表格喂上下文。比直接把整个 repo 扔给 AI 高效 10 倍。
静态上下文 vs 动态上下文
在喂上下文之前，还要先理解一个关键区分：
|
|
|
|---|---|
|
|
|
这个区分很关键：静态上下文需要你提前准备好（写文档、写规范）；动态上下文 Agent 可以自己获取（跑命令、查日志）。你不需要把所有日志提前贴给 Agent，给它一个能调用 CloudWatch 的 MCP 工具即可。
三大策略：提供、压缩、隔离
理解了上下文窗口的限制和按阶段的选择框架，下一步是具体怎么管理。AI-DLC 总结了三大策略：
1. 提供上下文：让 AI 有”足够的知识”——但不是全塞进窗口，而是按需获取（MCP 工具、文件指针）
2. 压缩上下文：在有限窗口内”最大化信息密度”——摘要旧对话、只留任务相关内容
3. 隔离上下文：防止”跨任务污染”——每个功能用独立 Session，每个 Agent 用独立分支
|
|
|
|
|---|---|---|
|
|
|
|
关键原则：做”目录”，不做”百科全书”
很多团队在落地时第一个错误就是——把所有规则、架构、API 都塞进一个超大的 AGENTS.md 文件，觉得越详细越好。
结果：
• 文件越来越大，规则越来越多，没人维护、信息过时；
• AI 每次都加载这一大坨，浪费窗口空间；
• 真正需要的规则淹没在过时规则里。
正确做法：让主文件只做“目录”，把具体内容拆到各自的文件里，需要时再加载。
▼ ✅ 正确做法（~60 行主文件，只放指针）
▼ ❌ 错误做法
这个原则简单但反直觉。它的本质是：上下文要”按需加载”，而不是”提前塞满”——这跟微服务架构里的 lazy loading 是同一个思想。
6 Constraints：规则代替口头约定
依赖方向强制执行
| Types |
|
Config |
|
Repo |
|
Service |
|
Runtime |
|
UI |
每层只能依赖左边 — 边界严格，内部自由
为什么这对 AI Agent 特别重要？人类开发者可能凭经验知道”这个不该引用那个”，但 AI Agent 不懂这种隐含规则。如果没有强制约束，Agent 会随便跨层调用，代码很快变成一团乱麻。
中央管控 vs 本地自治
• 中央管控（不能让 Agent 自己决定）：模块间接口格式、依赖方向、数据格式、命名规范
• 本地自治（让 Agent 自由发挥）：模块内部实现、算法选择、优化方式
具体例子：Linter 报错要对 Agent 友好
假设你的架构规则是：Controller 不能直接调用 Repository，必须通过 Service 层中转。
▼ ❌ 传统 Linter 报错（给人看的）
人看到能理解，但 AI Agent 只知道”第 42 行有个非法 import”，不知道应该改成什么、中转层在哪、有没有参考案例。结果 AI 可能瞎改——删掉 import、换个路径、或者绕过检查。
▼ ✅ AI-Friendly Linter 报错（给 Agent 看的）
Agent 读到这条信息，直接就能自动修复——不需要人介入。
约束反而是加速器
没有约束时，Agent 面对无限可能性，会浪费大量 Token 去探索各种方案（很多是死胡同）。清晰的约束 = 缩小搜索空间 = 更快收敛到正确答案。
7 用 Agent 清理 Agent 的混乱
AI 写的代码比人写的代码腐烂得更快——文档过时、命名漂移、死代码堆积。
为什么？因为人写代码时会本能地维护一致性——命名风格统一、删掉没用的代码、更新文档。但 AI Agent 没有这个本能。它每次生成都可能用不同的命名风格，不会主动删除旧代码，文档和代码容易脱节。
自动化清理频率
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
8 反馈循环：Harness 不是笼子，是导轨
三层反馈，缺一不可：
1. Agent 自检循环（单 Agent → 自己拦住低级错误）
• LoopDetectionMiddleware：检测死循环——改了 A 破了 B → 改 B 又破了 A → 自动停止并报告
• PreCompletionChecklistMiddleware：提交前验证——测试通过了吗？Lint 过了吗？文档更新了吗？
2. Generator-Evaluator 分离（Agent to Agent → 互相审查）
一个 Agent 写代码（Generator），另一个 Agent 审代码（Evaluator）。不通过就反馈重做。就像写作文的人和改作文的人不能是同一个人——自己检查自己永远会漏。
3. 人的反馈回归系统（Human to Agent → 持续进化）
这是 Mitchell Hashimoto（HashiCorp 联合创始人）的核心理念：
没有反馈循环的 Harness 是牢笼，不是导轨。三层反馈缺一不可。
9 角色重定义：每个人的工作方式都在变
|
|
|
|
|---|---|---|
| 产品经理 |
|
|
| 开发者 |
|
|
| 架构师 |
|
|
| QA |
|
|
| DevOps |
|
|
10 想动手实践？AWS 官方 AI-DLC 工作流
看完方法论想立刻试试？AWS Labs 已经把整套 AI-DLC 工作流开源了，开箱即用：
这是什么
一套“喂给 AI Coding 工具”的 Steering 规则集——把 Inception → Construction → Operations 三阶段的所有提示词、决策点、产出规范打包好。下载放进项目，在对话框里说一句”Using AI-DLC, …“，AI 就会自动按 AI-DLC 流程跟你工作。
支持哪些 AI Coding 工具
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
三步上手
1. 下载：从 GitHub Releases 下 ai-dlc-rules-v0.1.x.zip
2. 解压到你的 AI Coding 工具对应规则目录（见上表）
3. 触发：在 AI Chat 里说出魔法句
AI 会自动进入 Inception 阶段，开始用 [Question]/[Answer] 多选题问你需求，全程人审、人批、人决策，所有产出物落到 aidlc-docs/ 目录。
六大特性
| Adaptive Intelligence |
|
| Context-Aware |
|
| Risk-Based |
|
| Question-Driven |
|
| Always in Control |
|
| Extensible |
|
✦ 核心要点回顾
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% 价值
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连 🙏
关注我，持续分享 AI 时代的软件工程实战与深度思考