最近一个月白嫖完了两个Krio 账号，正在用第三个。
Kiro 是亚马逊推出的AI编辑器，而亚马逊是Claude的最大金主。所以Kiro对新用户真的非常慷慨，注册账号就送500积分，Claude Opus 4卯足劲，甩开膀子用，也能很长时间。
Kiro支持谷歌账号和Github账号注册，而且不受地域限制，在中国大陆可以流畅使用。作为一个拥有10个Google账号的男人，我实在拒绝不了这种送上门的福利。
现在的AI编程软件真是比大模型都还多，但是Kiro却是一个很有独特想法的产品，因为它引入了一个新的概念：规范驱动开发(Spec-driven Development)。
好家伙，又是一个新概念，当初MCP我就研究了几天才鼓捣明白。自从研究AI大模型后，我了解的概念和产品名字，比我高中三年学的英文单词都多了！
那什么是规范驱动开发(Spec-driven Development)呢？它和Vibe Coding又有什么区别呢？
我们先来聊聊Vibe Coding的弊端。
之前刷到过一个非常有意思的排行榜，AI编程提示词排行榜，这里贴出来大家乐呵一下，反正我第一次看到，差点喷饭，真的太经典了！
在Vibe Coding开发范式下，"给我生成完整可运行的代码"遥遥领先！
只要是重度使用过AI编程工具的人，上面20个提示词，不说100%，80%都经常输入过，我甚至在对话框喷过GPT-5，神奇的是，严辞批评后，有些Bug竟然神奇修复成功了！
其实这些排行榜上的提示词就是Vibe Coding最大的弊端。氛围编程其实说白了就是凭感觉走，而凭感觉的代价就是失控。一旦逻辑稍微复杂一点，Agent 就容易像脱缰的野马，不仅误解上下文，还需要你像保姆一样步步引导。最麻烦的是，整个开发过程中的决策理由完全是断层的------代码是写出来了，但"为什么这么写"却无从追溯，这简直是团队协作的噩梦，唯一的解决办法就是推倒了重来。
通过Vibe Coding去完成一个小单元或者一个函数，现在变得异常简单，但是让它一开始先完成一个产品功能需求和技术的完整架构，靠我们输入一段不超过100字的提示词，就天真的以为，喝杯咖啡的功夫，一个完整的MVP Demo就跑出来了。
但凡这么说的，基本就是自己没有动手用AI编程软件开发过产品的人。
这就是写代码和软件工程开发最本质的区别，前者有手就行，后者必须有严格的规矩和质量规范控制。
AI 可以帮你写出一段漂亮的代码，但它无法帮你通过一段 100 字的废话读懂整个产品的灵魂。
代码是生成的，但架构是"生长"出来的，后者无法被压缩进一个 Prompt 里。
于是规范驱动开发(Spec-driven Development)出现了。
其实Cursor和Trae等产品已经有了这样的意图，他们都在自己的产品上增加了Rules功能。这个功能就是用来编写限制性的提示词，用来约束编程Agent，防止其跑偏或者重复犯同样的错误。
但是Rules并没有从根本上解决Vibe Coding在完整产品开发中面临的问题：细致到函数功能级别的明确需求。
Rules 是贴在施工单位门口的"规矩"和"警告"，Specs 才是"施工图"。Rules解决的是 How（怎么写），而Specs解决的是 What & Why（做什么、业务逻辑是什么）。
比如：这个函数输入是什么？如果用户未登录，应该抛出异常还是重定向？数据更新后是否需要刷新缓存？
现在我们用一个万年历网页的简单示例来看一下Kiro的Spec 编程方式。
在Krio中打开一个空白项目文件夹，我们会看到如下界面。
Kiro提供了两种编程思路，一种是Vibe，就是边聊边构建代码，这个其它产品都有类似的功能。我们重点看一下Spec模式。
sql
Plan first, then build. Create requirements and design before coding starts.上面这段英文通读易懂，用中文解释就是先规划设计，最后编写代码，设计先行，代码殿后。
我们在下方的聊天框输入这么一段提示词，看看Kiro的Spec模式做了什么？
xml
```xml<rules><role>你是一名Web应用开发专家，最擅长使用NextJs开发全栈应用。</role>
<goal>开发一个万年历应用，选中某一天，就能显示前100年和将来100的这一天有哪些中国传统节日，比如元旦，冬至。</goal>
<keywords>万年历、阳历、阴历、中国传统节日、历史的今天</keywords>
</rules>```我们看一下Kiro做了什么工作。
上面动图的字太小，我把Kiro的总结贴到下面。
javascript
我来帮你创建一个万年历应用的规格说明。让我先基于你的需求生成初始的需求文档。Createdrequirements.md我已经基于你的需求创建了初始的需求文档。文档包含了以下主要需求：日历界面与日期选择 - 用户可以查看日历并选择任意日期，同时显示阳历和阴历信息节日查询功能 - 选中日期后显示前后100年内该日期对应的中国传统节日阴阳历转换 - 准确的农历公历转换，包括闰月处理和JSON序列化/反序列化节日数据集 - 完整的中国传统节日定义，包括固定阳历节日和农历节日性能要求 - 响应时间和加载速度的具体指标响应式设计 - 支持手机、平板和电脑等不同设备需求文档看起来是否符合你的期望？如果没问题，我们可以继续进行设计阶段。你可以提出修改意见，比如：添加更多节日类型调整日期范围增加其他功能需求这里面最重要的是创建了需求文档requirements.md，但是这个不是普通的Markdown文件，实际包含了三个过程：Requirements、Design和Task List。目前Kiro只完成了第一个过程，这个需求文档你可以继续提出修改意见。
我们直接进入第二个Desigh环节，我们看一下Kiro做了什么工作。点击聊天框右上角的 Move to Design phase按钮即可。
这个阶段Kiro做了什么事情？生成了一个新的设计文档Design.md。
sql
设计文档看起来是否符合你的期望？如果没问题，我们可以继续创建实现任务列表。
设计文档包含：
基于Next.js 14的架构设计核心组件和接口定义数据模型（农历日期、节日、节气）10个正确性属性用于验证系统行为错误处理策略使用Vitest + fast-check的测试策略我们来大致看一下Design.md的内容。针对需求文档，Design.md提供了这个的技术整体架构，包括核心组件和接口的标准。
接下来我们进入最后一个过程，生成开发任务的Task List，并询问你要不要开发Faster Mvp产品。
最后这个过程，Kiro交出了一份开发任务清单，总共13个大任务和几十个子任务。我这里放个局部细节图。
大家注意看上图中，我框选出的符号，一个箭头和Start task标记，然后下面是具体的任务项，这个任务要完成什么事情以及怎么测试。
至此，一份完整的Spec文档就完毕了，包含三部分：需求文档、设计文档和任务文档。
这个过程是不是很规范严谨，其实如果细心的话，这个过程是一直可以聊天修改的，也就是说，先不写代码，先把这三个文档跟Kiro聊清楚聊明白。
最后一步，我们直接让Kiro把所有的开发任务全部完成，看看能做成什么产品出来。我们先不让Kiro去做测试任务，先把核心功能开发出来。
你可以输入提示词让Kiro 去干活，也可以直接点击Start task那个闪电图标，一个任务一个任务的去完成。
当前开发在进行哪些任务，在Task.md也能实时看到。
开发的过程是漫长的，我们就不详细说了。不过这个过程中，你是可以悠闲喝咖啡的，因为需要你动脑的事情已经不多了。
除了一开始安装开发环境我需要点几下鼠标进行授权，剩下的时间我都在窗户旁来回踱步晒太阳，等待Kiro完成开发。
终于开发完毕，我们启动这个一下，看看最终的效果。
完美，一步到位，没有任务Bug!!
当然很多细节功能需要优化，比如我想选中阴历生日，再帮我查找；没有对应节日的年份直接过滤等等，细节的优化就比较花费时间了。
至此，我们完成了整个Spec模式的开发探索，整个过程消耗了Kiro 账号40个积分，因为我全程用的Claude Opus 4.5,积分按2.2倍计算。
这篇文章终于要结尾了！做个总结吧。
让我们告别"开盲盒"的代码生成，Kiro 用 Spec 模式证明了：磨刀不误砍柴工，教会 和告诉AI明确的需求和开发规范，比逼它瞎干活要靠谱得多。
Vibe Coding 让我们享受了"脑洞大开"的玩具Demo快感，而 Spec 模式则补全了从"玩具"到"产品"之间最关键的工程拼图。
从跟 AI 互相扯皮改 Bug，到变成喝着咖啡监工它按文档施工，这才是AI编程用户该有的体面生活。
完。