Kiro 提出规格驱动开发，用 Markdown 规格说明书指挥 AI 编程，告别“氛围感编码”，实现需求可追踪、代码可演进的智能协作开发新范式。
六十年前，程序员还在用机器码一行行敲代码，而今天，AI已经能听懂你说“我要做个塔诺斯汉诺塔游戏”，然后自动给你写出来。
但问题来了——AI写出来的代码，真的符合你心里想要的样子吗？如果你中途改主意了，它还记得你最初的需求吗？
这，就是今天我们要聊的核心：规格驱动开发，也就是用“说明书”来指挥AI写代码，而不是靠“感觉vibe”和“临时提示”。
这篇文章的作者是亚马逊的资深工程师，长期深耕系统架构和自动化推理领域。他在亚马逊内部推动过很多高可靠性的系统设计，也深度参与过基于形式化方法（比如 TLA+）的系统验证工作。他不是那种只写代码的程序员，而是真正思考“软件开发本质”的系统构建者。
他最近推出了一款叫 Kiro 的开发工具，目标只有一个：让 AI 编程从“氛围感编码”走向“可追踪、可协作、可演进”的工程实践。
那什么是“氛围感编码”？就是你现在用 Copilot 或其他 AI 工具时的状态——你一句一句地提示：“加个按钮”、“让它自动解谜”、“别重置游戏”……看起来很爽，但一旦项目变大，需求变多，你就很容易迷失在无数个提示词里，连自己最初想要什么都说不清了。更糟的是，这些“口头约定”根本不会被记录下来，AI 下次生成代码时可能就忘了。
而 Kiro 提出的解决方案，简单又深刻：把需求写成一份“规格说明书”，用 Markdown 文件记录下来，比如 requirements.md。这份文件不是摆设，而是 AI 的“行动纲领”。你改需求？直接改这个文件。AI 会根据最新版本自动调整代码，而且所有变更都有迹可循、版本可控。这就像从“口头传话”升级到“签合同”——靠谱多了！
举个例子。Kiro 让 AI 做一个“汉诺塔”小游戏。第一次生成后，点击“自动解谜”按钮，结果游戏居然重置了，而不是从当前状态继续解。如果是传统 AI 编程，你可能会再发一条提示：“别重置，接着解！”但这条提示很可能被淹没在后续对话中。而在 Kiro 的体系里，你只需在 requirements.md 里加两行字：
> 用户点击“自动解谜”时，应从当前盘子状态开始求解，不得重置游戏。
> 自动解谜过程应可视化，逐步移动盘子，而非瞬间完成。
就这么两行，AI 就会重新规划任务、修改代码，并且以后无论你怎么改其他功能，这两条核心需求都不会丢。这就是规格驱动的力量——把模糊的“感觉”变成清晰的“契约”。
你可能会问：这不就是写文档吗？有什么新鲜的？
关键在于，这份文档是活的。它不是写完就扔进抽屉的废纸，而是和代码、任务、测试紧密联动的“系统中枢”。Kiro 的 IDE 会读取这份规格，自动生成开发任务，分配给 AI 代理执行，甚至在代码变更后自动验证是否仍符合规格。这就像给 AI 装了一个“导航仪”，让它知道要去哪、为什么去、不能偏离哪些原则。
其实，这种思想在大型科技公司早有实践。比如亚马逊著名的“逆向工作法”（Working Backwards）：在写一行代码前，先写一篇“新闻稿”或“FAQ”，描述产品上线后用户会怎么夸它。这本质上就是一种规格——从用户价值出发，定义系统该做什么。Kiro 把这种企业级工程思维，下沉到了每个开发者日常的编码流程中，而且用最简单的 Markdown 实现，人人都能用。
更深层的意义在于：我们终于可以把注意力从“怎么写”转移到“写什么”。
过去六十年，编程语言虽然越来越高级，但核心范式没变——你还是得告诉计算机“一步一步怎么做”。而 SQL 是个例外：你只要说“我要哪些数据”，数据库自己决定怎么查。Kiro 想做的，就是把 SQL 这种“声明式”思想扩展到整个软件开发。你描述“系统应该具备什么行为”，AI 负责实现细节。这不仅是效率提升，更是认知升级。
说到这儿，你可能觉得这太理想化。但 Kiro 强调：AI 不是万能的，但“AI + 工具”组成的系统是。
单独一个大语言模型（LLM），可能连“字符串里有几个 r”都要算半天，还容易出错。但如果你让它生成一段 Python 代码：input_string.lower().count('r')，再让 Python 解释器执行，瞬间搞定，又快又准。这就是“系统思维”——LLM 负责理解人类语言、提取意图；传统工具负责高效、精确地执行计算。
亚马逊内部已经在用这种思路做“自动推理检查”：LLM 从文档中提取业务规则，再用 SMT 求解器（一种形式化验证工具）验证 AI 生成的回答是否逻辑自洽。LLM 擅长处理模糊的自然语言，SMT 擅长做严密的逻辑推导，两者结合，就能构建出既灵活又可靠的智能系统。
这其实回应了一个经典问题：Rich Sutton 在《苦涩的教训》中说，AI 领域最大的教训是——通用方法 + 大量计算，永远胜过人为注入的“聪明设计”。
Kiro 并不反对这一点。他不是要把人类的思维模式硬编码进系统，而是把人类积累的“计算工具”（比如数据库、求解器、编译器）开放给 AI 使用。这不是“教 AI 怎么想”，而是“给 AI 更好的工具去探索”。
换句话说，未来的 AI 开发者，不再是“提示词工程师”，而是“系统架构师”。你要设计的是一个由 LLM、代码解释器、数据库、验证器等组件构成的协作网络。在这个网络里，LLM 是“创意引擎”，其他工具是“执行臂膀”。而规格说明书，就是协调整个网络的“宪法”。
回到开头那个问题：软件开发的未来是什么？
Kiro 的答案很清晰：从“如何做”走向“做什么”，从“临时提示”走向“持久规格”，从“单打独斗的 AI”走向“协同作战的系统”。这不仅是工具的进化，更是开发范式的革命。就像 1950 年代从汇编语言走向高级语言一样，我们正在经历一次抽象层级的跃迁。
而这次跃迁的关键，不是让 AI 更聪明，而是让我们更聪明地使用 AI。
写规格，不是增加负担，而是减少混乱。记录需求，不是形式主义，而是建立信任。当你把“想要什么”清晰地写下来，AI 才能真正成为你的伙伴，而不是一个需要不断纠正的实习生。
所以，别再沉迷于“一句话生成网站”的快感了。真正的生产力，来自于可积累、可复用、可演进的知识结构。
Kiro 的工具，正是为了帮我们搭建这样的结构。它不炫技，不浮夸，却直指软件开发的本质：我们不是在写代码，而是在定义行为；不是在堆砌功能，而是在实现价值。
什么是spec driven规范驱动开发 ？
“Spec-driven” 是 “specification-driven” 的缩写，中文通常翻译为 “规格驱动” 或 “规范驱动”。它是一种软件开发方法论，核心思想是：
先明确“系统应该做什么”，再考虑“如何实现它”。
换句话说，开发不是从写代码开始，而是从写一份清晰、结构化的 规格说明书（specification）开始。这份规格描述了软件的功能需求、行为规则、用户交互、边界条件等，但不涉及具体实现细节（比如用什么语言、什么算法、什么框架）。
Spec-driven + AI 的模式是：
- 你把完整需求写进 requirements.md；
- AI 读这份“说明书”，生成代码、任务计划、测试；
- 你修改规格，AI 自动同步更新实现；
- 所有变更都有版本记录，不会丢失。
简单例子：
你想做一个登录功能。
- 传统开发方式：直接开始写代码——建表、写 API、加密码加密、处理错误……边做边想细节。
- Spec-driven 方式：先写一份规格，把完整需求写进 requirements.md；比如：
- 用户输入邮箱和密码后点击“登录”。
- 若邮箱不存在，提示“账户未注册”。
- 若密码错误，提示“密码不正确”，并限制5次失败后锁定10分钟。
- 登录成功后跳转到首页，并设置会话 Cookie。