从“氛围编程”到“意图工程”：AI Coding Agent时代的规范驱动开发深度实践
从“氛围编程”到“意图工程”：AI Coding Agent时代的规范驱动开发深度实践
1. 困境：为什么AI编程越“聪明”，代码库越“混乱”？
过去两年，AI编程助手的能力经历了指数级跃升。从Tab键的智能补全，到能理解上下文的Agentic Coding，再到可以一口气生成数百行代码的端到端实现，开发效率似乎迎来了“第二春”。
然而，随着AI生成代码在项目中的占比越来越高（在部分企业的试点中已达60% ），一个新的、更棘手的问题浮出水面：代码库正在以惊人的速度熵增。
这种现象被行业形象地称为 “Vibe Coding” （氛围编程）。就像让一位技艺高超但不了解规则的实习生自由发挥，AI能快速产出语法正确的代码，但产出的代码风格迥异、逻辑重复、架构割裂。当你让AI第二次实现类似功能时，它可能生成一套完全不同风格的代码 。这带来了三个核心痛点：
- 代码延续性差：AI缺乏项目特定的“记忆”，每次生成都是“零基础”发挥，缺乏架构一致性。
- 团队协同失效：不同开发者撰写的Prompt质量参差不齐，导致AI生成的代码风格五花八门，维护成本急剧上升 。
- 意图与实现脱节：AI模型擅长模式补全，却不擅长“读心术”。它无法从“添加一个红包模块”这种模糊指令中，理解业务边界、合规约束和领域模型 。
这个困境揭示了一个根本性问题：我们试图用非结构化的“自然语言提示词”（Prompt），去约束一个概率模型的“代码生成”。 这无异于用细沙筑堤，看似能挡住水流，实则一击即溃。
2. 破局之道：SDD（规范驱动开发）的范式转移
为了解决上述困境，业界将目光重新投向软件工程的古老智慧，并结合AI的能力，催生了规范驱动开发（Specification-Driven Development，SDD） 。
SDD的核心理念并非新鲜事，它吸收了测试驱动开发（TDD） 和行为驱动开发（BDD） 的精髓，但在AI时代，其内涵发生了根本性变革。
传统开发 vs. 规范驱动开发
| 维度 | 传统开发（Code-Centric） | 规范驱动开发（Spec-Driven） |
|---|---|---|
| 事实来源 | 代码是唯一的真相，文档往往滞后 | 规范是核心事实来源，代码是规范的衍生品 |
| AI的角色 | 模糊搜索工具，根据提示词猜测意图 | 规范的执行器，根据明确契约生成代码 |
| 变更流程 | 改代码、改文档（或忘记改文档） | 修改规范，AI与工具链系统性重新生成受影响的工件 |
| 主要产出 | 可执行代码 | 可执行的活文档（规范、计划、任务清单） |
GitHub在其官方博客中定义：SDD是先定义代码应如何行为的契约，这个契约成为AI Agent生成、测试和验证代码的事实来源，从而减少猜测、降低意外、提高代码质量 。这是一种从“写代码”到“设计意图”的范式转移，开发者从“代码打字员”转变为“意图架构师”和“AI教练” 。
3. 核心工作流：Specify → Plan → Tasks → Implement
SDD并非一个空洞的口号，而是一套可落地的、严格的四阶段工作流。这套流程通过将开发过程分解为四个明确的阶段，确保AI始终在正确轨道上运行 。
阶段1：Specify（规格定义）
- 目标：清晰定义软件做什么（What）和为什么（Why），而非如何做。
- 产出：
spec.md。包含用户故事、验收标准（如EARS语法）、功能/非功能需求、边界条件等 。 - 关键：这份规范必须是精确、完整且明确的，足以让AI生成工作系统，消除意图与实现间的鸿沟 。
阶段2：Plan（技术方案）
- 目标：决定**如何构建（How）**软件。
- 产出：
plan.md。包含架构概览、技术栈选型、数据模型设计、API契约、以及宪法（Constitution）合规性检查 。 - 关键：将“做什么”翻译成技术约束，为AI划定实施边界。例如，如果团队宪法规定“所有API必须使用RESTful约定”，计划中就必须体现这一点 。
阶段3：Tasks（任务拆解）
- 目标：将技术方案分解为具体、可执行的开发任务。
- 产出：
tasks.md。按阶段（如基础、核心功能、UI、安全）组织，每个任务都应是独立的、可测试的、有明确验收标准的工作单元 。 - 关键：任务拆解越细致，AI的执行精度越高。例如，“实现一个
AddFeed方法，验证URL格式，解析RSS/Atom，存储到SQLite，返回Feed ID” 。
阶段4：Implement（实现）
- 目标：AI Agent根据前三份产物，逐个任务地编写代码。
- 关键：开发者在此阶段主要进行代码审查（Code Review），验证AI生成的代码是否符合规范与计划，而不是亲自下场编码。若发现问题，应回溯修改规范，而非直接修改代码，从而保持规范与实现的一致性 。
4. AI Coding Agent实施SDD的工程实践
了解了理论，更关键的是如何在真实项目中让AI Coding Agent遵循这套流程。以下是基于企业级实践的工程技术方案。
4.1 建立“宪法（Constitution）”：团队的AI最高准则
在让AI编写代码前，必须先让它学习团队的“法律”。这个“宪法”文件记录了项目的架构模式、代码风格、安全合规要求等核心原则 。
代码示例：宪法片段（CLAUDE.md / constitution.md）
# 项目宪法 v1.0
## 技术标准
- 所有API必须遵循RESTful约定并使用标准错误响应格式。
- 前端组件必须基于公司级UI组件库（如Ant Design）开发。
- 数据库变更必须使用迁移脚本，并遵循命名规范：YYYY-MM-DD-description。
## 安全与合规
- 所有用户数据必须使用AWS KMS进行静态加密。
- 日志和错误信息中严禁包含敏感数据（如手机号、身份证号）。
## 编码规范
- Java：使用大驼峰命名类，小驼峰命名方法。集合判空统一使用`CollectionUtils.isEmpty()`。
- 所有代码更改必须通过至少两名团队成员的Pull Request审查 。
有了宪法，当AI Agent在规划或实施时，就会自动引用这些约束，确保生成的代码风格一致、安全合规 。
4.2 多AI Agent协同：各司其职的“开发团队”
复杂的现代软件工程无法由单一AI模型完成。一个成熟的SDD实践会构建一个多AI Agent协同系统，让不同模型扮演不同角色，通过MCP（模型上下文协议）等工具进行无缝协作 。
| AI Agent角色 | 主要职责 | 技术选型示例 |
|---|---|---|
| 协调者（Orchestrator） | 理解需求、拆解任务、决定调用时机、整合最终结果 | Claude（擅长全局规划与决策） |
| 高级工程师（Sr. Engineer） | 代码设计、实现、调试、重构 | Codex（代码生成能力强） |
| 大上下文分析师（Analyst） | 阅读大型代码库、分析长日志、异常堆栈 | Gemini（上下文窗口极大） |
实现机制：协调者Agent（如Claude）通过全局规则被强制要求：“对于任何非琐碎的任务，你必须思考‘Codex能否在这里提供代码帮助？Gemini能否进行大上下文分析？’” 。基于此，协调者会动态调用其他Agent，形成一个由AI驱动的、自我组织的虚拟开发团队。
4.3 实践案例：为一个电商系统添加“红包模块”
让我们以一个真实的企业级场景——为电商导购系统添加“NN红包模块”——来串联整个流程 。
1. 编写规范（Specify）
开发者在spec.md中定义业务意图：
- 用户故事：作为用户，我希望在首页看到我可用的红包列表，并按门槛从低到高排序。
- 验收标准：
- 仅当用户有可用红包时，模块才展示。
- 红包数据需从
FpProvider服务获取。 - 若获取失败，模块静默降级，不阻塞页面渲染。
2. 制定计划（Plan）
协调者AI（如Claude）根据规范和宪法（constitution.md），生成plan.md：
- 架构：遵循项目既定的“数据服务（DataService）-> 模块构建器（ModuleBuilder）”模式。
- 技术栈：使用Spring Boot，数据服务实现
DataService<List<FundQueryDTO>>接口，模块构建器继承BaseModuleBuilder<NnRedPacketVO>。 - 流程：数据服务查询数据 -> 构建器组装VO -> 前端渲染。
3. 拆解任务（Tasks）
AI将计划拆解为具体任务清单tasks.md：
- 任务1：创建
NnRedPacketDataService，实现execute方法，调用FpProvider查询红包。 - 任务2：创建
NnRedPacketVO，包含redPacketList和totalAmount字段。 - 任务3：创建
NnRedPacketModuleBuilder，在doBuild方法中获取数据并构建VO。 - 任务4：编写单元测试。
4. AI协同实现（Implement）
- 协调者（Claude） 将任务1分派给高级工程师Agent（Codex）。
- Codex读取
spec.md、plan.md和宪法，生成符合项目规范的NnRedPacketDataService代码，包括必要的注解、日志和异常处理。 - 若在实现中遇到对现有
FpProvider接口的疑问，Codex可请求分析师Agent（Gemini）分析该Provider在项目其他模块中的调用方式，确保用法一致。 - 任务完成后，由人类开发者进行Pull Request审查，验证代码是否严格实现了
spec.md中的验收标准。
通过这套机制，AI不再是脱缰的野马，而是在清晰轨道上高速运行的列车。开发者从编写代码的细节中解放出来，专注于定义意图、审核产出和把控架构。
5. 挑战与展望：SDD并非银弹
尽管SDD展现出巨大潜力，但其落地仍面临现实挑战：
- 历史代码（棕地）集成：如何为百万行级的存量代码逆向生成规范和宪法，是当前主要难点。业界策略是新功能100%采用SDD，存量代码按修改频率渐进式改造 。
- 工具链成熟度：目前的SDD工具（如GitHub Spec Kit, OpenSpec, BMAD）仍在快速演进，尚未形成统一的行业标准 。
- 思维转变成本：开发团队需要从“写代码”的舒适区，转向“设计意图”和“审查规范”的新模式，这需要时间和培训投入 。
未来展望：随着Coding Agent从“执行指令的实习生”进化为“主动规划的技术合伙人”，SDD将成为连接人类战略意图与机器执行能力的通用语言 。它不仅是提升效率的工具，更是构建可控、可审计、高可信AI软件工程体系的基石。在这场变革中，开发者角色的转变——从实现者到设计者与验证者——将定义下一代软件工程的形态。