先写规范，再写代码。AWS Kiro正面迎击"氛围编程的弱点"

氛围编程缺的，是”动手前的那5分钟”

上周之前我写了4篇文章,主题都是氛围编程的安全性。

我深挖了Moltbook 150万API密钥泄露事件。追踪了Cursor CEO关于”脆弱基础”的发言。用Forrester(弗雷斯特)的三原则做了对照验证。也梳理了”从随兴到管控”的转折点。

写着写着我一直在想:问题不只是安全。质量本身就不稳定。

打开Cursor,敲一句”我想做这样一个功能”。能跑的东西就出来了。挺好玩的。

但下周回头看,设计意图看不懂了。测试跑不过。需求变更也应付不来。

“能跑”和”能用”之间有一道大鸿沟。

一组数据揭示了这道鸿沟的本质。Stack Overflow在2024年的调查显示,使用AI编程工具的开发者中,有63%回答调试花费的时间”超出预期”。写得快,但修起来费劲。这就是氛围编程的致命弱点。

AWS推出的Kiro(Kiro)IDE,正面迎击了这个鸿沟。

思路其实很简单:写代码之前,先写规范。仅此一点,质量问题的结构就变了。

作为曾经的”挫败工程师”,我来梳理一下Kiro的规范驱动开发。

AWS Kiro是什么?”结构在先,代码在后”的IDE

Kiro是AWS开发的AI驱动代码编辑器。基于VS Code(Visual Studio Code)打造。

外观和Cursor很像,但设计理念完全不同。

Cursor的武器是速度。一边写,AI一边即时补全。

Claude Code的武器是自主性。能理解整个仓库并提出修改建议。

Kiro的武器是结构。在写下一行代码之前,自动生成3份文档。

第一份是requirements.md(需求),定义”做什么”。包含用户故事和验收标准。

第二份是design.md(设计),决定”怎么做”。包含技术设计、数据库结构、时序图等。

第三份是tasks.md(任务),即实现的步骤说明书。以清单形式逐项推进。

你用自然语言说”我想做这样一个应用”,Kiro生成3个文件。你确认内容后给出OK,再进入实现阶段。

这种方法叫做Spec-Driven Development(规范驱动开发)。

2025年7月推出预览版,同年11月开始GA(正式发布)。

根据官方网站,仅预览版就有超过25万人使用。

价格方面,可以从免费版(每月50积分)起步。Pro版每月20美元,提供1000积分。Pro+版每月40美元,提供2000积分。

免费额度足够试用,门槛很低。

这里有个重点:Kiro不是”AI写代码的工具”,更准确的理解是**“AI写设计的工具”**。代码是设计的产物。这个顺序的差别直接关系到质量。

Kiro还有一个叫”Steering Hook(转向钩子)“的机制。在实现阶段,如果代码有偏离规范的迹象,系统会参考requirements.md并提示纠偏。规范作为”活文档”持续监督整个实现过程。

EARS记法。喷气发动机的安全标准,降临到氛围编程

Kiro的需求定义使用了EARS记法。全称是Easy Approach to Requirements Syntax(简易需求语法)。读作”EARS(耳朵)”。

这个记法诞生的地方很有意思:Rolls-Royce(劳斯莱斯)的喷气发动机部门。

2009年由Alistair Mavin(阿利斯泰尔·马文)等人开发。是描述喷气发动机适航规则的方法。“在这种条件下,发动机会这样运作”——为了无歧义地描述这一点而诞生的语法。

基本形式如下:

# EARS记法的基本形式
# While(前提条件) + When(触发条件) + shall(系统响应)

WHEN a user submits a contact form with valid data
THE SYSTEM SHALL send confirmation email within 5 minutes
AND display success message

共有5种模式:

• Ubiquitous(普遍):始终适用的需求。“记录所有请求日志”
• Event-driven(事件驱动):特定事件发生时。“登录时生成会话”
• State-driven(状态驱动):处于特定状态时。“维护期间拒绝写入”
• Unwanted behavior(非期望行为):错误处理。“认证失败3次锁定账户”
• Optional feature(可选功能):有条件的功能。“高级会员可导出CSV”

根据EARS官方网站,Airbus(空客)、NASA、Bosch(博世)、Intel(英特尔)都在采用。在航空航天、汽车、半导体一线得到了验证。

为什么这对氛围编程有效?用具体例子说明。

没有EARS记法的提示: “做一个登录界面”

用了EARS记法的需求:

WHEN a user attempts to log in
THE SYSTEM SHALL validate email and password format
IF the credentials are incorrect 3 consecutive times
THE SYSTEM SHALL lock the account for 30 minutes
AND send a security notification to the registered email

你能看出”做一个登录界面”这条提示里有什么没定义吗?锁定条件、是否通知、锁定时长、恢复方式,全部没定义。AI不会写提示里没写到的东西。

仅仅用EARS记法的”非期望行为”模式,错误场景就自然被梳理出来了。“失败3次会怎样”不刻意去想就容易漏。但有了”IF the credentials are incorrect…”这个模板,你就能照着填进去思考。

喷气发动机的安全标准,降临到了AI编程的质量管理上。这种”降临”的感觉,是我个人最兴奋的一点。

“数月→3周”。制药AI案例展示了Kiro的实力

光讲理论说服力不够。Kiro实际带来了什么?介绍两个案例。

第一个是制药AI案例,刊登在AWS Industries Blog。

3名开发者用3周时间,构建了一个生产级的药物发现智能体。

处理的数据量极大。PubMed(PubMed)、ChEMBL(ChEMBL)等超过30个生物医学数据库。仅PubMed每年就新增约150万篇论文。

要把这些海量数据横向整合,识别治疗靶点,给出基于证据的推荐。这是按传统做法需要好几个月的项目规模。

3周完成的关键在于requirements.md。“从哪个数据库取什么数据”事先定义清楚了。“证据的可信度评估方法”也明确写出。“推荐的输出格式”也定好了。全部都在实现之前完成。

代码动手之前规范已经定好。所以即便3个人也能不犹豫地推进。

第二个是Rackspace Technology(Rackspace科技)的案例。这个更戏剧:预估52周的工作,3周完成。报告效率提升90%。

我想强调的不只是速度。因为规范先存在,完成品就能与规范对照。“跑起来了但不知道对不对”——这种不安从结构上消失了。

以我之前做客户成功的经验来说:“需求模糊就开干”是项目崩盘的典型套路。即使在AI写代码的时代,这条原则没变。

Kiro × Cursor × Claude Code。理清三种思想

我并不是想说”Kiro最强”。这3款工具解决的问题不同。

Cursor的设计理念是”快”。亚200毫秒的Tab补全让手不停。擅长Bug修复、重构、小规模原型。在速度至上的场景下无可替代。

Claude Code的强项是”自主性”。在终端运行,融入Git工作流。擅长大规模仓库的修改和跨文件变更。

Kiro的信条是”结构在先”。适合新项目的启动。具备从需求到任务的可追溯性。在团队开发和需要审计的场景里发挥威力。

使用场景大致这样划分:

• 快速做原型 → Cursor
• 大改既有代码 → Claude Code
• 新项目要带质量启动 → Kiro

我3个都在用。初期设计用Kiro。日常修改用Cursor。大规模重构交给Claude Code。

比如新开发一个业务工具。先用Kiro生成requirements.md。设计定下后,日常功能添加用Cursor推进。3个月后需要大规模结构调整时,交给Claude Code。

不是”哪个更强”,而是”想解决什么问题”来选。工具选项变多本身就是进步。

试过才懂的”先写规范”的体感

理论和案例之后,讲讲我自己的体验。我用Kiro的免费版试做了一个业务工具的设计。

我想做的是一个Slack反馈自动分类工具。把特定频道的发帖按类别转录到表格里。之前用Cursor做到一半就搁置了。

用Cursor半途而废的原因,是在”分类标准”上卡住。Bug报告和功能请求怎么分?可信度低的分类怎么处理?一开始想,手就停了。

我把Slack反馈分类工具的需求输入给Kiro。

生成的requirements.md让我吃惊。

# requirements.md(Kiro自动生成的需求节选)
# 用EARS记法定义了验收标准

## 用户故事1:反馈自动分类
WHEN a message is posted in the designated Slack channel
THE SYSTEM SHALL classify the message into one of:
  - bug_report
  - feature_request
  - praise
  - question
AND store the classification with confidence score

## 非期望行为
IF the classification confidence is below 0.7
THE SYSTEM SHALL flag the message for manual review
AND notify the admin channel

“可信度低于0.7就交人工审核”。这个需求我之前在Cursor做的时候根本没想到。EARS记法的”非期望行为”模式帮我梳理出了错误场景。

而且design.md也生成了。里面写好了Slack API→分类引擎→Google Sheets API的连接设计。tasks.md里以清单形式列出了12个实现任务。

写代码之前就看到全貌。这种安心感的”质”与Cursor的”先跑起来再说”完全不同。

实际开始实现后,我搞懂了这份安心感的本质——“下一步该做什么”完全不用犹豫,时间为零。只需要按tasks.md从第1条开始往下消化。用Cursor写代码时也始终清楚”我现在在实现requirements.md里的哪一条”。

说实话,生成规范一次要花10〜15秒。习惯了即时补全的人会觉得有点慢。

但请你想想这15秒换来的设计精度。我在Cursor上为”分类标准怎么定”纠结30分钟的问题,在生成requirements.md的15秒里就解决了。

“先把能跑的做出来”是我的哲学,这点没变。变的是加上了”开跑前花5分钟确认规范”这一步。仅仅5分钟,后续就能省下3小时的修改时间。

氛围编程的质量问题,不在”工具”而在”顺序”

整理一下到目前为止的内容。

质量不稳的原因不是工具性能不够,而是缺了定义规范这一步。仅此而已。

Kiro证明了”顺序逆转”的效果。

• 制药AI:数月→3周。用requirements.md先固化需求
• Rackspace:52周→3周。规范驱动带来90%效率提升
• EARS记法:源自喷气发动机安全标准的方法,可用于AI编程的质量管理
• 超过25万人使用:免费版即可起步

三部曲追踪了安全问题。第4篇写了”从随兴到管控”的转折。这次的结论是再往前一步。

管控的真身,就是”先写规范”。

先试一次的具体步骤

试用Kiro不需要从大项目开始。按下面步骤体验即可。

1. 在 kiro.dev 注册免费版
2. 想一个平时用Cursor”想做但一直搁着”的工具
3. 对Kiro输入”我想做〇〇。请先生成requirements.md”
4. 读生成的需求,找一找”这个我没想到”的条目

只要第4步出现一条”这个没想到”,Kiro的价值就被证明了。读规范书的时候发现”原来要决定到这一步啊”——这种体验,就是迈向氛围编程下一阶段的入口。

意识到安全。理解管控的重要性。再养成先写规范的习惯。这3步,会让氛围编程从”玩”变成”武器”。

我想起以前和专业工程师共事的时候。他们最先做的就是需求定义,写代码是最后的事。

那时的我做不了”最先的设计”。我以为是技术力不够。

Kiro是一款让AI来做这个设计的工具。

我在Cursor上感受到”顶级工程师附体”的体验。Claude Code让这个信念加深。Kiro再加上的,是”设计的能力”。

能写、能改、还能设计。氛围编程进入了下一阶段。

如果有人现在对氛围编程感到不安,不要去”换工具”,试试”换顺序”。先写规范——仅此一点,体验就会改变。

请用 kiro.dev 的免费版,先生成一次requirements.md试试。我想把这份体验,传递给同样撞到这堵墙的人。