Kiro：规格驱动开发 AI 完全指南

为什么需要 Kiro：AI 写代码之前，先把需求写对

主流 AI 编程工具的工作链路高度相似：开发者在 IDE 中输入提示词，模型直接输出代码补全、函数实现乃至整个文件。这种「提示词到代码」的直连模式带来一个被普遍忽视的问题——方向正确性无法在编码前校验。模型可以把一个错误的需求翻译成语法规范、结构完整的代码，产出的是一批「高质量的错误实现」；在团队层面，每个成员用各自的提示词驱动 AI，产出风格割裂，没有人能清晰回答「我们要构建什么、成功标准是什么、哪些事我们刻意不做」。需求理解的分歧被隐藏在大量已生成的代码里，返工成本极高。

Kiro 将工作流重排为：需求对话 → 规格文档 → 规格评审 → 基于规格生成代码 → 代码与规格的一致性追踪。开发者先与 Kiro 用自然语言对话澄清需求，Kiro 多轮追问、迭代修订，最终产出一份一页以内的结构化规格；规格以 Markdown 形式保存，像代码一样纳入版本管理。规格通过评审之后才进入代码生成阶段，且每一项功能需求都能追溯到对应的代码实现。代码合入后，Kiro 持续检测规格与代码的偏差（漂移检测），把「文档与实现分叉」这个软件工程老问题显性化。

与同门的 Amazon Q Developer 相比，Kiro 刻意收敛能力边界：不做逐行补全，也不追求「一句话生成整个应用」的炫技，而是把资源集中在需求侧的规格化与评审。这让 Kiro 在需要需求溯源、审计与团队协作的场景中，比直接生成代码的工具可靠得多；短板也同样明显——不适合需要快速出码的随手任务。

安装与环境配置：3 步就绪

Kiro 是 AWS 托管服务，无本地安装步骤。首次使用仅需一个有效 AWS 账号，并确认目标区域支持 Kiro。

1. 准备 AWS 账号：没有账号的在 AWS 官网注册，已有账号直接登录 AWS 管理控制台；登录后在右上角确认当前区域。Kiro 需要在其支持的区域中使用，首次使用建议选择美东 1 区（us-east-1），具体可用区域以控制台显示为准。

2. 进入 Kiro 服务：在 AWS 控制台顶部的服务搜索框中输入「Kiro」并进入对应服务页。首次进入时，控制台会引导完成服务开通与必要的授权配置，全程无需安装任何软件或命令行工具。

3. 配置 IAM 权限（团队场景）：个人体验可直接使用账号权限进入；团队使用建议创建专门的 IAM 用户或角色，按最小权限原则授予 Kiro 操作权限。Kiro 用到的 IAM 策略与配置方法见用户指南中「Identity and Access Management」章节。

验证方法：能在 Kiro 控制台中成功创建项目、开启对话并收到回复，即视为环境就绪。就绪后的日常入口有三个：Kiro 控制台（Web）、VS Code 插件（可选安装）、REST API（供程序化集成，调用方式以官方 API 文档为准）。

快速上手：15 分钟跑通第一个规格

最小可用流程的思路：Kiro 的核心工作流是「描述需求 → 生成规格 → 评审规格 → 生成代码」。用一个最小功能（如待办事项管理）跑通全流程，能快速理解规格驱动开发与「直接写代码」的差异。操作步骤如下：

1. 创建项目：在 Kiro 控制台点击「创建项目」，输入项目名称（如 todo-app），进入项目的规格工作区。

2. 开始需求对话：在项目内发起新对话，用自然语言描述需求，包括目标用户、要解决的问题、期望功能点与约束条件。

3. 响应追问并收敛需求：Kiro 会逐轮追问细节（例如「是否需要多用户权限」「数据需要支持导出吗」），逐条回答，直到需求明确。

4. 生成规格：对话收敛后，点击「生成规格」，Kiro 输出包含目标、非目标、假设、功能需求、非功能需求与开放问题的结构化规格。

5. 运行规格评审：点击「评审」，Kiro 对规格进行评分并列出模糊点、矛盾项与遗漏项；根据反馈在编辑器中修改规格的 Markdown 内容。

6. 再次评审直到通过：规格达标后进入代码生成阶段。

7. 生成代码：点击「生成代码」，Kiro 基于规格生成项目骨架与核心实现，并标注每个需求对应的实现位置。

8. 导出并继续开发：将生成的代码导出到本地仓库，在 IDE 中继续补充业务逻辑——先做代码审查再合入主分支。

结果说明：经过以上流程，你会得到一份带评审记录、可版本化的规格，以及一份与规格逐条对应的代码基线。进阶技巧：Kiro 支持导入 FreeMind（.mm 格式）思维导图作为需求输入，适合把团队脑暴结论直接转化为规格初稿；规格文件为 Markdown，可在 Git 仓库中与代码同库提交、评审、回滚。

核心能力详解：4 大支柱

支柱一·规格创作（Spec Authoring）：Kiro 的核心输入是自然语言对话或思维导图，产物是结构化规格。规格不是自由文档，而是遵循固定模板：目标（Goals）、非目标（Non-goals，明确「不做什么」以控制范围）、假设（Assumptions）、功能需求（Functional Requirements）、非功能需求（Non-functional Requirements）、开放问题（Open Questions）。创作过程是多轮共同创作（co-authoring）：开发者对每个部分做反馈，Kiro 迭代修订，而不是一次吐出终稿。这使需求描述从「一次性提示词」变成「可迭代的协作产物」。

支柱二·规格评审与评分（Spec Review & Evaluation）：写代码之前，开发者可用 Kiro 对规格做一次 AI 评审。Kiro 会检查规格中是否存在模糊措辞、相互矛盾的需求、遗漏的边界情况和无法验证的成功标准，给出评分与逐条修改建议。这把原本靠评审会议人工逐行读文档的环节前置并自动化：主观的「感觉哪里不对」变成可执行的「这里缺少可量化的成功指标」。规格评审是 Kiro 区别于补全类工具的分水岭——它是质量门禁，而不是代码生成的前戏。

支柱三·从规格到代码生成（Code Generation）：规格评审通过后，Kiro 以规格为依据生成代码基线，包括项目结构、数据模型与核心业务实现。生成结果与规格的功能需求一一对应，Kiro 会标注哪些需求已实现、哪些尚未覆盖，避免「代码写完了但需求没做完」的假完成。开发者拿到的是一个与规格对齐的起点，而非最终交付物；业务细节、异常处理与测试仍需人工完成。

支柱四·漂移检测（Spec Drift Detection）：软件上线后，需求与代码都会持续变化。Kiro 持续比对规格中「承诺的行为」与代码中的「实际行为」，当两者不一致时在控制台标记漂移，并引导开发者决策：改代码以符合规格，还是改规格以反映现实。漂移检测让规格从「开工前的一次性文档」变成贯穿生命周期的活契约，解决「文档没人信、代码没人懂」的团队协作难题。

生产部署与监控：从上线到运维

部署方式一：规格纳入版本管理。Kiro 项目中的规格是 Markdown 文件，建议与代码放在同一 Git 仓库，与代码同库评审、同库演进。团队约定「规格评审通过才可以开始写代码」，把 Kiro 的评审意见作为合并请求（MR）的前置检查项；规格文件的目录结构与命名规范由团队在仓库中统一约定，并可纳入 CI 校验（如检查规格文件存在且包含必要章节）。

部署方式二：生成代码的后续流水线。Kiro 生成的代码是基线实现，需导出到开发者的代码仓库后再进入正常的 CI/CD 流程：单元测试、代码审查、构建、部署。Kiro 本身不执行测试与部署，也不直接操作生产环境。需要将 Kiro 能力嵌入内部工作流的团队，可通过 Kiro 的 API 将规格创建、评审触发等操作接入现有系统（例如 issue 创建后自动生成规格草稿）。

可观测性与成本治理。规格质量指标：关注规格评审的平均得分与反馈条数，反馈长期偏多说明需求澄清环节投入不足。漂移告警监控：将漂移检测结果纳入例行周会，漂移数量持续上升通常意味着规格已不被团队信任，需要人工刷新或决定废弃。成本治理：Kiro 按使用量计费，规格生成、评审与代码生成均消耗推理资源，上线前应估算月度调用量并设置预算告警；对重复性规格生成，优先复用已有规格做修改，降低重复推理成本。权限审计：对团队账号启用 CloudTrail 审计，记录 API 调用与规格变更，IAM 按最小权限授权。

<p class="para-label">避坑清单：</p>

<ul class="dash-list"><li>坑 1：把 Kiro 当成代码补全插件来用。Kiro 的价值锚定在规格流程而不是逐行补全上，用「能不能立刻给我代码」来衡量它，会得出「不如 Copilot」的错误结论。</li><li>坑 2：跳过规格评审直接生成代码。评审是 Kiro 的质量门禁，跳过评审等于放弃核心能力，生成结果与直接写提示词没有本质区别，务必消化评审反馈后再进入代码阶段。</li><li>坑 3：规格文件不纳入版本管理。规格与代码分处两地会让漂移检测失去基准，规格必须与代码同库、同行评审、同版本回滚，否则文档会再次沦为摆设。</li><li>坑 4：把生成的代码直接合入生产分支。Kiro 产出的是与规格对齐的基线实现，不是生产级交付物，仍需人工 review、补测试并走 CI/CD 流水线。</li><li>坑 5：忽略非目标（Non-goals）与开放问题。多数需求返工源于「没写清不做什么」与「未决问题被默认跳过」，这两节是规格模板中最容易被敷衍、对质量影响最大的部分。</li></ul>

版本迭代

Kiro 于 2024 年 12 月在 re:Invent 2024 以预览版形式发布，核心能力围绕规格创作、规格评审、代码生成与漂移检测展开；2025 年服务进入正式可用（GA）阶段，并新增 Agent Mode（代理模式），可基于已确认的规格自主执行编码任务。作为 AWS 托管服务，Kiro 没有传统本地版本号，迭代以功能更新形式发布（截至训练数据，可能已有更新版本，请以 AWS What's New 为准）。

AI 应用场景

常见误区

面试题