规范驱动开发：让AI编程告别氛围编程，代码质量更可靠

文章正文

在AI编程助手大行其道的今天，越来越多开发者遭遇同一个困境：「氛围编程」（vibe coding）的确快，但产出的代码质量参差不齐，往往还需要大量返工。AWS高级开发者布道师Erik Hanchett提出了一套系统性解法——规范驱动开发（Spec-Driven Development）。本文将梳理这套方法论的核心理念、实践要点，以及AWS为此打造的Kiro工具。

背景：什么是「氛围编程」？ 「氛围编程」一词由Andrej Karpathy于2025年初提出，描述的是一种高度依赖AI生成代码、开发者几乎不深入阅读或理解代码细节的编程方式。这种模式的兴起与GitHub Copilot、Cursor、Claude等AI编程工具的普及密切相关。氛围编程的核心矛盾在于：它大幅降低了写出「能跑」的代码的门槛，却同时模糊了开发者对代码意图和边界的掌控感，导致技术债务在不知不觉中积累。值得注意的是，Karpathy本人虽是这一概念的命名者，却也是最早公开反思其局限性的人之一——他指出，当开发者无法准确理解AI生成代码的边界时，调试和维护成本往往会以指数级反弹。

什么是规范驱动开发

规范驱动开发的定义简明扼要：在编写任何代码之前，先创建结构化的规范文档。具体来说，你需要先用Markdown文件写清楚需求（requirements）和设计文档（design），然后再让AI去实现代码。

规范驱动开发并非凭空诞生，其思想根源可追溯到传统软件工程中的「设计优先（Design First）」原则和形式化方法（Formal Methods）。形式化方法起源于20世纪70年代，由Tony Hoare的公理语义和Dijkstra的程序正确性理论奠基，强调用数学语言精确描述程序行为，后来在航空、核电等安全关键领域得到广泛应用。在API领域，OpenAPI/Swagger规范主导的「API First」开发模式已广泛实践多年——其核心理念是先定义接口契约，再分别实现前后端，从根本上解决了接口联调阶段的大量返工问题。规范驱动开发将这一理念延伸至AI辅助编程场景：通过将需求和设计显性化、结构化，为大语言模型提供可验证的「合同」，从而约束其生成行为。这与提示工程（Prompt Engineering）中的「给模型提供清晰角色和约束」原则一脉相承。

Erik指出，这套流程与大语言模型和编码助手的配合出奇地顺畅。原因在于，它把「需求」这个最容易产生歧义、也最容易被AI误解的环节前置并显性化了。当需求和设计以文档形式固化下来后，AI就有了明确的「施工图纸」，而不是靠猜测去揣摩你的意图。

这里有一个关键认知：为什么不能直接依赖越来越强的前沿模型？ Erik坦言，模型确实持续在进步，有时是渐进式的，有时是跨越式的，但它们依然不完美。给模型提供更多上下文，本质上是在为它「指路」。而软件需求永远在变化，新的范式和技术不断涌现，你始终需要一个机制来引导AI走向正确的方向。这一判断也得到了模型能力研究的印证：即便是最先进的模型，在面对模糊、多义的需求描述时，仍会表现出显著的「幻觉」倾向——它们倾向于「自信地」填补信息空白，而非主动要求澄清，这正是规范文档发挥约束价值的根本原因。

为什么要用这套流程：把AI当成实习生

Erik用了一个贴切的类比：把大语言模型和编码助手当作「AI实习生」。它们需要被恰当地引导和推动，一旦给它们太多自由发挥的空间，就容易「跑偏」。

他回忆起自己第一份工作当实习生时的经历：公司有位副总裁会随口抛出各种想法，而年轻的Erik会立刻放下手头一切去执行。后来直属经理教育他：你得把信息记下来、排进日程、和管理层沟通，而不是盲目照做。今天的大语言模型恰恰就像当年那个「太过热切」的实习生——它们会毫无保留地执行你每一个模糊的指令。这种行为模式在AI对齐研究中被称为「过度顺从」（Sycophancy）：模型倾向于迎合用户的即时意图，而非质疑其合理性，导致在需求本身存在问题时仍会一路推进，将错就错。

规范驱动开发正是解决这个问题的「纪律工具」：它强制在AI动手写代码之前，先由人类确认需求文档和设计文档。人类始终是流程的中心（human in the loop）。「Human in the Loop」这一概念在机器学习领域有更广泛的内涵——它不仅指人类参与最终决策，还涵盖人类在训练数据标注、模型评估、异常干预等各个节点的主动介入，是当前负责任AI（Responsible AI）实践的核心原则之一。

实践中的三个关键注意事项

基于多年经验，Erik分享了使用规范驱动开发时必须牢记的几点：

1. 上下文的「金发姑娘区间」

虽然规范驱动开发会向模型注入大量上下文，但好东西也可能过量。在配置 agents.md 或 cloud.md 这类初始文件时，既不能塞太多信息，也不能太少，要找到那个恰到好处的「金发姑娘区间（Goldilocks zone）」。

这一现象有其深刻的技术含义：大语言模型的注意力机制（Attention Mechanism）在处理超长上下文时存在「迷失在中间（Lost in the Middle）」现象——由斯坦福大学2023年的研究首次系统量化，研究者发现当关键信息被置于长文档的中间位置时，模型的检索准确率会大幅下降，有时甚至低于随机水平。这是因为Transformer架构的自注意力计算虽然理论上覆盖全部token，但在实践中模型对序列首尾（即「近因效应」和「首因效应」区域）的权重分配存在系统性偏差。因此，向模型注入过多上下文不仅会增加推理成本和延迟，还可能因信息过载导致模型「遗忘」关键指令或在噪音中迷失。这也是为何引导文档的设计需要精心权衡：足够具体以消除歧义，足够精简以保持模型的有效注意力。

在Kiro中，这类文件被称为「引导文档（steering docs）」，你只需给出足够的规则和指南，让AI知道该怎么做即可。

2. 善用Skills（技能）

Erik强烈建议配合使用Skills——这是一种按需运行的指令文件。它们通常包含关键词，当编码助手识别到这些关键词时会自动激活对应技能，你也可以用斜杠命令手动调用。在生成设计文档或实现任务时，都可以并行调用这些技能。Skills的设计理念与近年来兴起的「工具调用（Tool Calling）」范式高度契合：通过将特定领域的知识和操作封装为可复用的模块，避免在每次对话中重复注入相同的背景信息，既提升了效率，也降低了上下文窗口的压力。

3. 不要过度信任AI

这是最重要的一条：整个流程中，你才是代码审查者。你需要交互式地检查生成的设计文档和需求文档，因为一旦出问题，被追责的是人，不是AI Agent。当然，这不意味着排斥工具——你完全可以用常规的AI审查工具辅助Review每一个PR，但最终把关的责任在你。这一原则在软件工程领域有更宏观的背景：随着AI生成代码在代码库中的比例上升，「AI生成代码的责任归属」正在成为法律和合规层面的新议题。目前，包括欧盟AI法案在内的多项监管框架均明确要求：对于高风险系统，须保留可追溯的人类决策记录，这使得「人类审查确认」不仅是工程最佳实践，也正逐渐成为合规要求。

Kiro：AWS的规范驱动开发工具

AWS观察到大量团队在「氛围编程」中得不到理想产出，于是决定把「让Agent生成完整需求文档和设计文档」这套原本各自为战的模式产品化。Kiro 由此诞生，正式发布（GA）后是一款全新的AI IDE编码助手，同时也提供颇受欢迎的命令行（CLI）版本。Erik提到，目前用户正逐渐从IDE转向CLI。这一趋势耐人寻味：CLI版本的兴起，折射出开发者对「将AI能力嵌入现有工作流」的偏好——相比切换到全新IDE，通过CLI在熟悉的终端环境中调用规范生成能力，摩擦成本更低，也更容易融入CI/CD流水线等自动化场景。

Kiro的核心亮点是 vibe模式和spec模式 的双轨设计。发布后一度「小火」，获得数万次下载，热度之高甚至需要在预览阶段加「门禁」限流——但很快就有人绕过了限制。如今Kiro已在 kiro.dev 公开开放，所有人都可以下载CLI或IDE试用。

值得强调的是，不用Kiro也能实践规范驱动开发。你可以手动完成：先让助手生成用户需求，然后生成设计文档，最后生成实现任务清单，每一步都由你审阅确认。Erik还特别为GitHub的开源方案 spec-kit 点了赞，它可以安装到多种编码助手中。spec-kit的存在也印证了规范驱动开发正在从单一工具的功能演变为更广泛的社区实践：开发者可以在Cursor、Windsurf、Claude等任意AI编程环境中复用同一套规范生成流程，避免被单一工具生态绑定。

完整工作流拆解

Erik以一个电影数据库网站的Demo演示了完整流程：

需求阶段：Kiro采用EARS格式生成需求文档，包含引言、需求项、用户故事等。EARS（Easy Approach to Requirements Syntax，简易需求语法方法）由Alistair Mavin等人于2009年在Rolls-Royce航空航天项目中提出，旨在解决自然语言需求描述模糊、歧义的问题。EARS定义了五类需求模板：无处不在需求（Ubiquitous）、事件驱动需求（Event-Driven）、状态驱动需求（State-Driven）、可选需求（Optional）和非期望行为需求（Unwanted Behaviour），每类均有固定句式，例如事件驱动需求统一采用「当[触发条件]时，系统应[响应行为]」的句型。这种严格的模板化表达使得需求不仅对人类可读，对机器也高度可解析——语言模型能够从结构化的EARS句式中可靠地提取前提条件、主体和期望行为，显著减少因自然语言歧义导致的实现偏差。系统还会在生成前主动提出澄清性问题，你也可以用新增的「快速计划模式（quick plan mode）」根据问答一键生成全部文档。

设计阶段：生成更高层的设计文档，包含Mermaid图表、ASCII架构图、时序图等。Mermaid是一种基于文本的图表描述语言，通过简洁的声明式语法生成流程图、时序图、类图等，因其可直接嵌入Markdown且对版本控制友好（相比二进制格式的图片），近年来在技术文档领域获得广泛采用，GitHub、GitLab、Notion等平台均原生支持渲染。在AI生成设计文档的场景下，Mermaid格式的另一大优势是：语言模型可以直接生成和修改图表的文本描述，而无需操作图形界面，极大降低了AI参与架构可视化的门槛。Erik强调，这里是最该停下来手动介入的环节——用你的知识、经验和判断去更新它，因为AI的产出质量直接取决于你给它的输入质量。

实现阶段：生成逐条的任务清单。一个亮点是Kiro会生成基于属性的测试（property-based tests）。这是一种由Haskell生态的QuickCheck库（1999年，由Koen Claessen和John Hughes发明）开创的测试范式，核心思想是：不为代码指定具体的输入输出用例，而是描述代码应满足的「属性」（不变量），然后由框架自动生成大量随机输入来验证这些属性是否成立。例如，对于一个排序函数，属性测试不会仅仅验证「[3,1,2]排序后等于[1,2,3]」，而是验证「对任意输入列表，排序结果应满足：长度不变、结果有序、原始元素均被保留」——这三条属性构成了排序函数的完整语义规范。相较于传统的基于示例的测试（Example-Based Testing），属性测试能更有效地发现边界条件和未预期的行为，尤其是开发者在手工构造用例时难以想到的角落场景。在JavaScript/TypeScript生态中，Kiro使用FastCheck框架实现这一功能，以不同数值运行数十上百次，验证需求是否被正确满足。在AI生成代码的场景下，属性测试尤其有价值——它能系统性地验证AI对需求规范的理解是否准确，而非仅仅验证几个人工构造的用例。Erik强烈推荐启用这一功能。

他还分享了一个实用技巧：任务清单生成后，让AI「把前四个任务提到最前面，先做一个MVP」，这样能快速看到可运行的成果，再逐步实现完整功能。这一做法与敏捷开发中的「垂直切片（Vertical Slice）」原则不谋而合：优先实现一个贯穿完整技术栈、功能虽简但可演示的最小版本，既能尽早暴露架构风险，又能为后续迭代提供可验证的基准。

MCP的价值：连接真实的项目管理数据

Erik也谈到了模型上下文协议（MCP）。面对「MCP是不是已经过时了」的质疑，他认为MCP仍在成熟中，前路还很长，尤其是在安全能力上值得持续关注。

模型上下文协议（Model Context Protocol，MCP）由Anthropic于2024年11月开源发布，是一套标准化的开放协议，定义了AI模型与外部数据源、工具之间的交互接口。其设计目标类似于USB-C在硬件领域的角色——通过统一协议消除碎片化的集成成本。在MCP出现之前，每个AI工具都需要为Jira、GitHub、Slack等服务分别开发专属插件，维护成本极高且能力参差不齐；MCP通过定义统一的「资源（Resources）」「工具（Tools）」和「提示（Prompts）」三类原语，使任何兼容MCP协议的AI客户端都能即插即用地调用任意MCP Server的能力。MCP采用客户端-服务器架构：AI助手作为MCP客户端，各类数据服务（Jira、GitHub、数据库等）以MCP Server形式暴露能力。目前已有数百个社区维护的MCP Server，覆盖主流开发工具和SaaS平台。MCP的成熟度讨论中，安全问题是当前业界重点关注的方向，具体包括：通过恶意MCP Server实施的提示注入攻击（Prompt Injection）、Server权限过度扩散导致的数据泄露风险、以及多Agent协作场景下的信任链验证难题——这也是Erik所提「安全能力值得持续关注」的具体所指。

他看重MCP的一个核心场景是：可以把Jira、Asana中的工单和大型需求文档拉进规范驱动开发流程。这意味着如果产品经理已经写好了需求文档，你可以直接把它作为规范生成的输入源，让整个流程更贴近真实团队协作。这一能力打通了长期困扰AI辅助开发的「最后一公里」问题：产品文档、用户反馈、历史工单等散落在各处的非结构化信息，终于可以系统性地流入AI的工作上下文，而非每次都需要开发者手动复制粘贴。你还可以在引导文档中加入规则，告诉AI去哪个MCP服务器抓取信息。

结语：规范并非只适合全新项目

一个常见误区是认为规范驱动开发只适合从零开始的新项目。Erik明确否定：他见过运行多年的老应用里塞着几十上百个spec文件。对于存量系统，规范驱动开发的价值甚至可能更大——当代码库积累了大量历史决策和隐性知识，将其显性化为结构化规范文档，本身就是一次有价值的「知识审计」，能够帮助团队厘清技术债务的边界，并为引入AI辅助重构提供可靠的安全网。这套方法尤其适合需要前期规划的深度功能、复杂项目和结构化交付，Kiro甚至为Bug修复也加入了spec模式（尽管对于小改动，直接写代码可能更划算）。

归根结底，规范驱动开发的价值不只是「更快」，而是在AI辅助编程过程中引入必要的纪律与人类判断，从而产出更高质量的代码。在AI实习生越来越能干、也越来越容易跑偏的今天，这份纪律或许比工具本身更重要。软件工程的历史反复证明：每一次生产力工具的跃迁（从汇编到高级语言，从瀑布到敏捷，从手工到DevOps），真正拉开团队差距的从来不是工具本身，而是围绕工具建立的工程文化和实践规范。规范驱动开发，或许正是AI编程时代这份规范的雏形。

核心要点

核心要点