AWS Kiro来了：氛围编程正式进入规律阶段

[[IMG:hero]]

“氛围编程真的太好玩了。是真的好玩。”

自2026年初以来，我几乎每天都在用Cursor和Claude Code——业务工具、副业原型，想法一来就能写代码。对于一个曾经放弃编程的人来说，这简直是一场革命。

但最近一两个月，有一种不安的感觉逐渐出现。“能做出东西，但不确定它能不能持续运行。""凭感觉写的代码，三周后连自己都看不懂。“同样的不安开始出现在业界重量级文章里——仅最近一个月就出现了三篇：Cursor Composer 2的评测文章、IBM的”从构建到运营”阶段宣言，以及AWS Kiro。把它们放在一起看，都像是对同一个问题的不同回答。

我发现了：它们都指向同一个方向。氛围编程全盛期正在向下一个”规律阶段”过渡。今天我要以一名曾经放弃过编程的工程师的视角，拆解这个信号核心——AWS Kiro。

氛围编程：快乐背后渐渐积累的不安

先说一个我自己的失败案例。我想和读者站在同一水平线上，所以实话实说。

三月份，我用Cursor和Claude Code快速搭建了一个内部客户支持仪表盘。Slack通知、从Notion自动导入、过滤界面——三天就成形了。“这简直神了”，我到处向同事展示。一个从客服背景、曾经离开编程的人，做出了这个。当然会觉得热血沸腾。

两周后问题出现了。需求变更来了，我打开自己的代码，完全不知道当时是怎么想的。我问Claude：“这个函数是干什么的？“Claude回答：“这段代码可以有多种解读方式。“写代码的本人和AI一起迷失了。

这不是我一个人的问题。国外有几个数据为证：

• METR（模型评估与威胁研究机构）的RCT实验显示，使用AI工具时的开发任务反而比预期慢（出处：METR官方博客）
• GitClear的调查发现，AI辅助代码的重构率和删除率高于传统代码
• Cisco CodeGuard和Tenzai等多款安全扫描工具报告称，氛围编程生成的代码中检测出10～45%的漏洞

我的亲身感受和这些数据指向同一个方向。“让东西跑起来的快感”和”让它持续运行的质量”之间，还没有桥梁。

我不打算在这里扮演救世主大谈规格驱动开发。我自己也还在摸索。但正是在这个摸索过程中，AWS Kiro出现了——用图解的方式展示了”规格优先是什么意思”。这就是我今天要分享的内容。

AWS Kiro提出的”规格驱动型AI开发”究竟是什么

[[IMG:1]]

AWS Kiro是AWS提供的AI优先集成开发环境（IDE），以Visual Studio Code为基础开发。核心是与AI智能体进行”规格→设计→实现”顺序的交互式对话流程。目前中文详细解说还不多，XenoSpectrum在2026年5月22日发布了一篇先行解析文章。

Kiro的核心在于强制用户在写代码之前通过对话创建三个文件：

1. requirements.md — 要做什么。用EARS记法（简单需求语法方法）编写用户故事和验收标准
2. design.md — 怎么做。包括数据流、API时序、TypeScript接口、ER图、单元测试策略
3. tasks.md — 按什么顺序实现。包含离散任务以及对应需求编号的引用

这个流程的优点很明确：只是强制在正确的时机写东西，写的内容本身和过去”正规开发”一模一样。需求定义、概要设计、任务分解。有经验的人应该早就知道。但这些在氛围编程的速度中被完全遗漏了。Kiro要求先把这三件事写好。

另一个重要概念是Steering Files（引导文件）——将项目特有规则写成Markdown放置在项目中，Kiro会始终参考。比如”使用Tailwind v4”、“API错误必须用错误边界包裹”等前提。已经在用CLAUDE.md或AGENTS.md的人一定能理解，这是同一脉络。Kiro将其作为核心功能内置。

定价分为Free / Pro / Pro+ / Power四档，在Kiro官方定价页面公开（2026年5月时点）。支持免费开始，详情请查阅一手来源。支持OS：Mac/Windows/Linux。模型可从Claude Sonnet等多个选项中选择。

为什么是现在的”规格优先”？三个数字揭示的临界点

[[IMG:2]]

“规格优先很重要”——老实说，软件工程界几十年来一直在说这个。为什么偏偏现在出现了像AWS Kiro这样的专用IDE？我的解读是这样的。

**氛围编程一口气提升了”写代码的速度”，于是写完之后的问题变得更加明显。**以前需求定义就要花两周，所以”边写边改”还有时间。现在三天就能成形，雑乱的需求三天后就直接进入维护地狱。

三个数字并排来看：

• METR RCT的”慢19%“现象：经验丰富的开发者使用AI工具反而出现变慢趋势，原因之一是”没有注意到需求模糊就直接推进”
• GitClear的”删除率上升”：AI辅助编写的代码，写完后被删除或大幅修改的比例明显高于传统代码。过早写代码的征兆
• Cisco CodeGuard/Tenzai的”10～45%漏洞检出”：多款安全扫描工具报告氛围编程代码的安全缺陷比率偏高，主要原因是需求阶段缺少认证、授权、输入验证

三个共同关键词：“需求缺失”。速度提升后，缺失的代价变得更加清晰可见。AWS Kiro以”所以先写规格”来回应——并在IDE层面强制执行。这不是精神论，而是开发流程的结构性变化。

我自己第一次看到这三个数字时的感受是：“糟了，说的就是我。“作为一个曾经放弃过的人，某种程度上感到了解脱——专业工程师面临的问题，终于和我处于同一水平线了。相同的问题，相同的工具，能一起解决了。

解读成熟化三重奏：Cursor 2、IBM、Kiro指向同一方向

最近一个月出现的三个动向，我私下称之为”成熟化三重奏”。

事件	时间	内容	指向同一方向的信号
Cursor Composer 2	2026年4月	强化了智能体驱动的长任务执行。SiliconANGLE评价为”Cursor主角化”，The Register提出代码质量担忧，评判标准变得必要	氛围编程的旗舰IDE开始承担”执行责任”
IBM的”从构建到运营”阶段宣言	2026年5月	声明AI智能体的主战场是”运营”而非”构建”。从单次提示执行转向智能体长期持续运行的质量讨论	持续运行的质量胜过一次跑通
AWS Kiro（再受关注）	2026年5月	规格驱动型AI开发IDE，强制在代码生成之前进行规格、设计、任务分解的对话	”先决定写什么再去写”成为IDE标准

三个方向看似分散，却都是对同一问题的回答：“氛围编程带来速度提升之后，下一个课题是什么？”

• Cursor把”执行责任”交给智能体和IDE
• IBM把”运营责任”从AI智能体设计阶段就内置进去
• AWS Kiro把”规格责任”通过IDE工作流强制落地

明确责任归属——这是共同点。不只是”能跑就行”，而是”谁对什么、到什么程度负责”都要纳入设计。这就是氛围编程之后规律阶段的本质。

这和Nagi关于”按需调用的AI时代已终结”的判断也是一脉相承的话题。AI从”按需调用”变成”常驻运营”，设计的分量自然增加。Kiro的规格优先是这一趋势中的自然进化。

用”Kiro式流程”试验自己的业务工具

[[IMG:3]]

对于还没有正式引入Kiro的人，我来分享一下我这周做的”Kiro式流程”迷你实验。不安装Kiro本体，用Claude Code或Cursor也能试验类似的东西（这是相同三文件结构的模拟实验，不是Kiro实机演示）。

题材：一个”将Slack收到的咨询自动分类并保存到Notion的Bot”。对客服背景的我来说，正是想用来简化自己工作的工具。

第一步：先写requirements.md（约15分钟）

# Slack到Notion咨询分类Bot需求

## 用户故事
- 作为CS成员，我想将#support频道收到的咨询自动保存到Notion的"咨询数据库"
- 保存时希望自动分类"类别（Bug/问题/需求）"

## 验收标准（EARS记法）
- WHEN Slack收到新帖子 THE系统 在Notion创建新行
- WHEN 帖子内容包含"不能用""报错""崩溃" THE系统 将类别判定为"Bug"
- IF Notion API连续失败3次 THE系统 向CS Lead发送DM通知失败详情

第二步：在design.md中设计（约20分钟）

把数据流、错误处理、认证信息存放位置、测试策略整合在一页纸里。在这里边和Claude对话边整理，写代码之前就会冒出三个左右”啊，这个漏掉了”的发现。我的情况是”如何避免同一帖子重复保存”被遗漏了。

第三步：在tasks.md中分解（约10分钟）

• T1: Slack Bolt SDK初始化（验收标准: 1, 2）
• T2: Notion API调用模块（验收标准: 1）
• T3: 类别判定逻辑（验收标准: 2）
• T4: 重试与DM通知（验收标准: 3）
• T5: 单元测试（验收标准: 1, 2, 3）

第四步：写代码

到这里才把任务交给Claude Code：“从T1开始实现”。事先共享了三个文件，生成精度体感上明显提升了。更重要的是，三周后自己回头看时，能明白为什么这样写。

所需时间：需求、设计、任务共45分钟，代码主体2小时。以前的我会直接在代码上花3小时，然后扔掉一半。 45分钟的铺垫省下了2小时。

三个踩坑点与给初学者的注意事项

实话实说，Kiro式流程并非万能。先分享我踩过的三个坑。

踩坑1：过度写规格的地狱

最初写requirements.md太上瘾，洋洋洒洒写了几千字。等到推进到设计、任务阶段时，实现的动力已经消耗殆尽。目标：3～5个用户故事，验收标准10条以内。不要追求完美，以边写边改为前提。

踩坑2：在design.md里填代码的陷阱

很容易在design.md里写很长的代码片段。要忍住。design.md是”方针”，代码是tasks.md之后的事。我划的界限是：接口定义（类型）可以写，实现本体不行。

踩坑3：持续更新三个文件的负担

每次需求变更都要更新三个文件，老实说很累。我的规则是”只反映重大变更”，轻微变更只修改实现侧。但为了防止事后”规格和实现差太多”，每周花5分钟同步一次。

给初学者的一句话：如果觉得”这对我太早了”，就先只写requirements.md，跳过design.md和tasks.md。仅仅坚持一周”写代码前先写用户故事”，交给Claude的提示质量就会明显提升。正如Nagi所说的，不需要会写代码的时代要到来，尽早锻炼写用户故事的能力也是一种提前投资。

总结：“能跑就行”与”规格优先”可以并存，本周试一个项目

说了很多。感谢一直读到这里。

今天的内容压缩为三点：

• AWS Kiro是规格驱动型AI开发IDE。核心是通过对话创建requirements.md / design.md / tasks.md三个文件的流程
• Cursor Composer 2、IBM”运营阶段”宣言、AWS Kiro三者是氛围编程之后规律阶段的同一方向信号
• 不需要安装Kiro也能开始。Claude Code或Cursor的”规格优先”迷你实验本周就能做。就算只是试写requirements.md也有价值

最后说一下我的立场。“能跑就行”的精神，以后也不会放弃。让东西跑起来的快感，正是把我这个曾经放弃过的人拉回编程世界的东西，不会舍弃。

但我学到了，只有”能跑就行”，三周后就会痛哭。不再用粗糙的规格去搭建，然后事后补规格的做法了。代替方案是：“提前15分钟写规格，用氛围来实现，让它能持续运行”。仅此而已。

本周一个作业：把你正打算写的、或者最近写的代码的requirements.md，用15分钟写出来。写完就能看出少了什么。那就是迈向规律阶段的第一步。

我下周还会写更多踩坑的地方分享给大家。让我们一起在泥里打滚，一起变强。

---

出处

• AWS Kiro官网: https://kiro.dev/
• AWS Kiro定价页面: https://kiro.dev/pricing/
• AWS Kiro规格文档: https://kiro.dev/docs/specs/quick-plan
• AWS Kiro引导文档: https://kiro.dev/docs/steering/
• XenoSpectrum”AWS Kiro解析”2026-05-22（URL待确认）
• METR”Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• GitClear”AI Copilot Code Quality 2024”（URL待确认）
• Cisco CodeGuard / Tenzai安全扫描报告（URL待确认）
• IBM”The shift from build to operate for AI agents”官方声明（URL待确认）
• 内部参考：Nagi 「按需调用的AI」时代已终结
• 内部参考：Nagi 不需要会写代码也行的时代