AI编程三大框架精讲：规范驱动开发的正确打开方式

为什么AI写代码总是失控？

AI编程这两年真正拉开差距的，不是谁的提示词写得更花哨，而是在敲下第一行代码之前，你有没有做对一件关键的事——建立规范。

很多开发者的日常是这样的：跟AI说"帮我做个登录功能"，以为它能心领神会。但你没说用什么技术栈、跟项目哪个模块对接、哪些现有代码不能动。AI只能猜，猜对了你省心，猜错了你花更多时间返工。

根本问题其实就两个：

1. 你没把需求说清楚 — AI缺乏项目上下文，只能凭训练数据"脑补"
2. AI没有持久记忆 — 对话到第十句它已经忘了第一句立的规矩，开始自行其是

为什么AI天然缺乏项目上下文？这要从大语言模型的工作原理说起。LLM基于Transformer架构，通过注意力机制处理输入的token序列，其"理解"完全依赖于当前上下文窗口内的信息。即便是拥有128K甚至更大上下文窗口的模型，也无法自动感知你项目的目录结构、已有的数据库schema、团队的编码规范或历史决策。它的训练数据涵盖了海量开源代码，但这些是统计模式而非对你特定项目的理解。这就是为什么同样一句"帮我做个登录功能"，AI可能给出JWT方案、Session方案、OAuth方案中的任何一种——它在概率空间中选择最可能的输出，而非最适合你项目的输出。

而"没有持久记忆"这个问题，则源于当前主流LLM的对话机制本质上是无状态的。每次API调用时，模型需要将完整的对话历史作为输入重新处理。随着对话轮次增加，早期信息在注意力权重分配中逐渐被稀释——这就是所谓的"中间遗忘"（Lost in the Middle）现象。研究表明，当上下文超过一定长度后，模型对中间位置信息的召回率显著下降。虽然RAG（检索增强生成）和向量数据库等技术可以部分缓解这个问题，但它们引入了额外的工程复杂度，且检索质量直接影响生成效果。

这两个问题合在一起，指向一个核心结论：你不能再用嘴跟AI聊需求了，你得把规矩写成文档，让文档替你盯着它。 将规范写成结构化文档，本质上是用确定性的文本注入替代不确定的记忆召回。

什么是规范驱动开发（SDD）

这个思路有个正式名字——规范驱动开发（Specification-Driven Development, SDD）。一句话概括：先立规矩，再写代码。

传统开发里，我们也讲需求文档、技术方案。但在AI协作编程时代，这些文档的作用从"人看"变成了"AI执行"。文档不再是走过场的形式主义，而是AI的行为准则和执行边界。

SDD并非凭空出现的新概念，它继承了软件工程数十年的方法论积累。从1970年代Royce提出的瀑布模型强调需求规格说明书，到1990年代的契约式设计（Design by Contract）要求用前置条件和后置条件约束函数行为，再到TDD（测试驱动开发）用测试用例作为可执行规范——"先定义行为边界，再实现功能"的思想一脉相承。SDD的独特之处在于，它将这些规范的消费者从人类开发者扩展到了AI代理。文档的格式、粒度和表达方式需要针对LLM的理解特点进行优化，比如使用结构化的YAML/Markdown模板、明确的肯定/否定约束列表，以及可机器解析的验收标准。

目前帮你落地SDD的主流框架有三个：OpenSpec、Spec Kit、Super Powers。很多人搜到这三个名字就懵了，觉得它们在争同一块地盘。实际上，它们各管一段，完全可以搭配使用。

三大框架各自管什么

蓝图阶段框架：明确边界与约束

第一个框架的核心职责是：在AI动手写代码之前，逼你把蓝图想清楚。

它要求你明确回答：

• 这次要做什么、不做什么
• 技术边界在哪里
• 哪些约束绝对不能越

蓝图通过审核，AI才能开工。这就像建筑师画完施工图纸，工人才能进场。没有图纸就施工，盖出来的东西大概率返工。

从技术实现角度看，蓝图阶段框架通常包含几个关键组件：约束声明文件（定义技术栈、依赖版本、架构模式等硬性约束）、范围边界文件（用"必须做/不能做/可以后续做"的三分法明确需求边界）、以及验证规则（在AI生成代码前自动检查其计划是否违反约束）。这类似于TypeScript的类型系统——你预先声明了"形状"，任何不符合形状的输出都会被拦截。在实践中，这些约束文件通常以.md或.yaml格式存放在项目根目录的特定文件夹中，AI编程工具（如Cursor、Windsurf等）会自动读取这些文件作为系统提示的一部分。

施工流程框架：分步执行与检查确认

第二个框架管的是从立项、设计、开工到交付的全流程。

它的核心机制是：每一步都有检查点，每一步都强制停下来等你确认。你不点头，AI不往下走。

这解决的是AI"一口气写完一大坨代码"的问题。有了流程管控，AI走两步停一下，写错了当场就能抓出来，而不是等它生成500行代码后你再慢慢挑错。

这种"检查点"机制，本质上实现了人机协作中的Human-in-the-Loop（人在回路中）模式。这一概念源自自动化控制理论——在关键决策节点保留人类审批权，既利用了AI的高效执行能力，又避免了错误的级联放大。具体到AI编程场景，检查点通常设置在：架构设计完成后、核心接口定义后、每个独立模块实现后、集成测试前。每个检查点包含三个要素：AI需要交付的产物描述、人类需要验证的标准清单、以及通过/不通过后的分支流程。这种机制将AI从"自主代理"降级为"受监督的执行者"，大幅降低了失控风险。

变更记录框架：增量追踪与问题溯源

第三个框架管的是增量变更的可追溯性。

今天加个功能，明天改个需求，它像Git提交一样把每一次变更记录下来。下次出问题能一路倒查，找到是哪次变更埋的雷。

这在真实项目中极其重要——需求永远在变，关键是变了之后能不能追溯。

值得注意的是，变更记录框架虽然常被类比为Git，但它追踪的维度与Git有本质区别。Git记录的是代码文件的文本差异（diff），而变更记录框架追踪的是需求层面的语义变更——为什么改、改了什么业务逻辑、影响了哪些模块的行为契约。这更接近于数据库领域的"审计日志"（Audit Log）或事件溯源（Event Sourcing）模式。当AI根据新需求修改代码时，它不仅要提交代码变更，还要同步更新规范文档中的相关章节，并在变更日志中记录本次修改的动机、影响范围和回滚方案。这种双轨记录使得问题溯源不再需要逐行阅读代码diff，而是可以从业务语义层面快速定位。

三个框架如何协同工作

这三个框架不是三选一，是各管一段、搭着用的：

阶段	职责	类比
蓝图阶段	明确边界和约束	建筑师
施工阶段	分步执行+检查确认	施工流程
变更阶段	记录每次改动	变更台账

新项目从零开始，三个可以串联使用；给老项目加功能或重构，可能更侧重后两个。关键是根据你手上的项目状态，选择对应阶段的框架介入。

实际落地建议

不同场景的框架选择

• 从零开始的新项目：先用蓝图框架理清边界，再用流程框架分步推进
• 给已有项目加功能：重点用变更记录框架，确保新增不破坏已有逻辑
• 重构老项目：三个都需要，但要格外注意蓝图阶段的"不做什么"清单

规范驱动开发的核心心法

说实话，这三个框架不一定每个都要重度使用。更重要的是理解它们各自管什么、在哪里不冲突。即使你更习惯手动维护文档规范，搞清楚它们的分工，也是你以后选择工具的底气。

比起急着上手某一个框架，建立"规范先行"的思维模式更为关键。 无论你最终用哪个工具，核心逻辑都是一样的：让AI在明确的边界内工作，在关键节点停下来等你确认，把每次变更留痕可查。

总结

回顾全文，三件事应该变得清晰了：

1. AI编程失控的根源是缺乏规范约束，而非提示词技巧不足
2. 三大框架分别管蓝图、流程、变更，各司其职不冲突
3. 根据项目所处阶段选择对应框架，比盲目全套上手更务实

规范驱动开发的本质，是把人对项目的理解"外化"成AI可执行的文档。这不是增加工作量，而是把本来就该想清楚的事情提前想清楚——只不过以前你可以糊弄，现在AI会忠实地把你的糊弄放大一百倍。