先写规格，再写代码：AWS Kiro 与规格驱动开发的上手指南

选型上它站在巨人肩膀上：基于 VS Code 开源内核构建，主题、快捷键与常用扩展大多可以直接迁移，老用户的学习成本被压到很低，官方甚至提供了专门的迁移指南。还有一个值得注意的背景：据 2026 年中的行业报道，AWS 已把代理式开发的资源集中到 Kiro 身上，此前的 Amazon Q Developer IDE 插件进入过渡期——两条产品线最终如何分工，请以 AWS 官方公告为准。

也有人会问：一家卖云计算的公司，为什么要亲自下场做编辑器？逻辑并不复杂——开发者的入口正在从终端迁往 AI 工作台，谁占住了工作台，谁就能影响未来模型调用与算力消费的走向。Kiro 的免费档策略、与 AWS 服务的深度耦合，放在这张大棋盘上看就都顺理成章了。

第三步 · 任务 tasks.md

这套流程的价值不在炫技，而在「可审查」三个字：需求、设计、任务、代码 diff 全部互相链接，做评审的人终于能看到「这行代码为什么存在」。后来 GitHub 开源了同路线的 spec-kit 工具包，说明规格先行正在从一家之言变成行业共识。

顺带把 EARS 讲透：它是 Easy Approach to Requirements Syntax 的缩写，一种用固定句式书写需求的轻量规范。相比散文式的需求描述，它强迫你把触发条件与系统行为一次性写清，而写清楚的每一条都能直接翻译成测试用例。对被含糊需求折磨过的开发者来说，这个格式本身就是生产力。

安全扫描 hook

Hook 的触发器覆盖文件创建、保存、删除与手动执行四类事件，触发后的动作用自然语言描述即可；团队约定则沉淀在 Steering 文件里，让每一次会话都自动带着同一份「项目宪法」。换句话说，Specs 管「这次要做什么」，Hooks 和 Steering 管「以后一直怎么做」。

实际使用中还有个细节值得提醒：Hook 不是越多越好。事件触发意味着每次保存文件都可能唤醒一次模型调用，规则堆得太密既烧额度又打断心流。社区里比较一致的经验是：先挂一到两个收益最明确的（文档同步通常是首选），稳定跑上一两周，再逐步增加新规则。

上表为定性归纳而非跑分结论，三家迭代速度都极快，选型前请以各家官网的最新功能与定价为准。

1. 下载与登录：官网提供 macOS / Windows / Linux 安装包，用 AWS Builder ID 即可登录，不需要预先开通云账户。
2. 平滑迁移：导入 VS Code 的设置、主题与常用扩展，肌肉记忆基本无缝衔接。
3. 先立规矩：新建项目后花二十分钟写好 Steering——技术栈、目录结构、代码规范，此后每次会话自动带上这份上下文。
4. 跑通第一个 Spec：挑一个中等复杂度的真实小功能，完整走一遍「需求 → 审阅 → 设计 → 审阅 → 任务 → 执行」，体会把分歧消灭在文档阶段的感觉。
5. 挂第一个 Hook：把你最烦的重复劳动（比如同步文档）交给事件自动化，一周后回头评估收益再决定要不要铺开。

一句心态建议收尾：Kiro 的收益与「规格纪律」成正比。如果你今天只想快速改两行代码，它会显得笨重；但如果这个项目会长到三个月以上，规格文档带来的可追溯性就会持续升值——这正是它的甜点区。

2025 年预览期采取免费限量制，随后转入包含免费档位的分级订阅。具体档位、价格与额度调整较频繁，请以 kiro.dev 官网为准。

不必须。用 AWS Builder ID 登录即可开始写代码；只有当你要深度集成 AWS 云服务时，才与云账户发生关系。

内置多种主流模型可供切换，并通过 MCP 协议接入外部工具与服务；当前支持的模型清单以官方文档为准。

同属 AWS 开发者工具家族：Q Developer 是嵌在既有 IDE 里的助手插件，Kiro 是独立的代理式 IDE。据行业报道前者已进入过渡期、资源向 Kiro 集中，具体安排以 AWS 官方公告为准。

只想快速改几行代码时，传统补全工具更轻；但若项目会持续三个月以上，规格文档带来的可追溯性会持续升值——这正是 Kiro 的甜点区。