Agentic AI 时代
软件工程该怎么做？
一套完整的 AI-DLC 方法论
引 AI 写代码很快，但你的项目真的变快了吗？
2026 年，几乎所有开发者都用上了 AI 编程工具。但一个尴尬的现实是：代码产出快了 10 倍，产品迭代速度可能只快了 10%。
因为大多数人还停留在两个极端：
| AI 辅助模式 | AI 完全自主模式 |
|---|---|
| Copilot / ChatGPT 补全片段 人做所有决策 AI 不理解全局上下文 效率：1.2x–2x 远未达到预期 |
Vibe Coding / 无监督 Agent AI 从头到尾独立完成 输出随机、不可预测 可用率：20-40% 大量返工甚至重做 |
不是让 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 |
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 生成 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 并行） + 每次提交人审 + 知识飞轮 |
多 Agent 并行：怎么让 3 个 Agent 不打架？
答案是契约。就像三个施工队在三个房间各自装修，只要都看同一份施工图纸就不会冲突：
• 前端 Agent（分支 feat/ui）：根据 API Spec 生成 Mock 数据，不需要等后端
• 后端 Agent（分支 feat/api）：根据同一份 API Spec 实现接口，跑契约测试验证格式
• 测试 Agent（分支 feat/test）：根据 Spec 提前写好 E2E 测试，不需要等代码写完
三个 Agent 之间不需要互相"说话"，它们只需要看同一份契约文档。人的关键决策是：模块边界怎么划、契约怎么定义、最后合并时冲突怎么解决。
关键不是 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 — 系统/组织级别 "能做什么 + 做错了怎么兜底"
|
三层的演化路径其实回答了一个问题：我们对 AI 的掌控粒度，从"一句话"放大到了"一整个生产环境"。
• Prompt Engineering 解决"怎么说"——给 AI 一句清晰的指令
• Context Engineering 解决"看到什么"——给 AI 项目级的持久上下文
• Harness Engineering 解决"能做什么 + 做错了怎么兜底"——给 AI 整个组织级的运行环境
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 就完事——它是一整套工程体系：
+ 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-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 可访问的目录和工具 • 边界清晰 → 产出可控 |
关键原则：做"目录"，不做"百科全书"
很多团队在落地时第一个错误就是——把所有规则、架构、API 都塞进一个超大的 AGENTS.md 文件，觉得越详细越好。
结果：
• 文件越来越大，规则越来越多，没人维护、信息过时；
• AI 每次都加载这一大坨，浪费窗口空间；
• 真正需要的规则淹没在过时规则里。
正确做法：让主文件只做"目录"，把具体内容拆到各自的文件里，需要时再加载。
▼ ✅ 正确做法（~60 行主文件，只放指针）
## API → docs/api-contracts/
## Conventions → .cursor/rules/
▼ ❌ 错误做法
大而全的文档 ≠ 好文档。小而准的指针 > 大而全的手册。主文件永远保持简洁；具体内容分散在各自文件里，各自维护，各自更新。
这个原则简单但反直觉。它的本质是：上下文要"按需加载"，而不是"提前塞满"——这跟微服务架构里的 lazy loading 是同一个思想。
6 Constraints：规则代替口头约定
依赖方向强制执行
| Types | → | Config | → | Repo | → | Service | → | Runtime | → | UI |
每层只能依赖左边 — 边界严格，内部自由
为什么这对 AI Agent 特别重要？人类开发者可能凭经验知道"这个不该引用那个"，但 AI Agent 不懂这种隐含规则。如果没有强制约束，Agent 会随便跨层调用，代码很快变成一团乱麻。
中央管控 vs 本地自治
• 中央管控（不能让 Agent 自己决定）：模块间接口格式、依赖方向、数据格式、命名规范
• 本地自治（让 Agent 自由发挥）：模块内部实现、算法选择、优化方式
具体例子：Linter 报错要对 Agent 友好
假设你的架构规则是：Controller 不能直接调用 Repository，必须通过 Service 层中转。
▼ ❌ 传统 Linter 报错（给人看的）
→ Cannot import from 'repositories' layer
人看到能理解，但 AI Agent 只知道"第 42 行有个非法 import"，不知道应该改成什么、中转层在哪、有没有参考案例。结果 AI 可能瞎改——删掉 import、换个路径、或者绕过检查。
▼ ✅ AI-Friendly Linter 报错（给 Agent 看的）
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 去探索各种方案（很多是死胡同）。清晰的约束 = 缩小搜索空间 = 更快收敛到正确答案。
管 AI Agent 和管一个几百人的工程团队是一回事：中央管边界，本地给自由。
7 用 Agent 清理 Agent 的混乱
AI 写的代码比人写的代码腐烂得更快——文档过时、命名漂移、死代码堆积。
为什么？因为人写代码时会本能地维护一致性——命名风格统一、删掉没用的代码、更新文档。但 AI Agent 没有这个本能。它每次生成都可能用不同的命名风格，不会主动删除旧代码，文档和代码容易脱节。
所以必须用 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 写代码（Generator），另一个 Agent 审代码（Evaluator）。不通过就反馈重做。就像写作文的人和改作文的人不能是同一个人——自己检查自己永远会漏。
3. 人的反馈回归系统（Human to Agent → 持续进化）
这是 Mitchell Hashimoto（HashiCorp 联合创始人）的核心理念：
→ 分析：缺什么上下文/规则？
→ 让 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 工作流开源了，开箱即用：
⭐ 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 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% 价值
not just a tool.
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连 🙏
关注我，持续分享 AI 时代的软件工程实战与深度思考