• 时间:
  • 分类:

你有没有遇到过这种情况：用 AI 编程助手写代码，生成出来的东西跟你想的完全不一样？改了 prompt 再生成，换了个方向跑偏？来回好几轮，时间花了不少，代码还是一团乱？

如果有，问题可能不在 AI 身上，而在于你跟 AI 沟通的方式。

问题出在哪

目前主流的 AI 编程方式基本是这样的：

  1. 你在 chat 里用自然语言描述需求
  2. AI 根据 prompt 生成代码
  3. 你发现不对，补一句"不是这样，我要的是..."
  4. AI 重新生成
  5. 循环往复

这种方式对简单任务没问题。但需求稍微复杂一点——比如涉及多个模块、有前后依赖关系、需要考虑错误处理和边界条件——AI 就开始猜了。

它不是在理解你的霂求，而是在猜你的霂求。

每一轮 chat 只能看到局部信息，AI 无法建立全局视角。最终的代码是一堆「局部正确」的片段拼起来的，整体架构谈不上。

另一种思路：Spec 驱动开发

亚马逊云科技出的 Kiro IDE 提出了一个不同的方案：先写 Spec，再写代码。

Spec（规格说明）是一段结构化的需求描述。你不需要用特定格式，自然语言就行，但要把核心需求说清楚。

Kiro 拿到 spec 之后，不是直接写代码，而是先做三件事：

1. 生成 Requirements

把你的描述拆成具体的功能点，每个功能点有明确的验收标准。

比如你说「写一个天气查询功能」，它会拆成：

  • 城市名转坐标（验收：输入"北京"→ 返回 39.9, 116.4）
  • 调用天气 API（验收：返回 JSON 包含温度/湿度/风速字段）
  • 格式化输出（验收：输出格式为"城市 🌤️ 温度/湿度/风速"）
  • 错误处理（验收：城市不存在时返回友好提示）

2. 生成 Design

技术方案。包括：函数签名、数据结构、模块划分、API 设计、依赖关系。

这一步解决的是「怎么实现」的问题，而不是直接写代码。

3. 生成 Tasks

把 design 拆成一系列可执行的编码任务，按依赖关系排序。

然后你点一下，Kiro 按 task 列表逐个实现代码。每个 task 完成后可以 review、修改、或者退回去改 spec。

这跟 chat 模式有什么本质区别

信息密度不同。

chat 模式下，AI 每轮只看到你这一条消息加上历史上下文（而且上下文有长度限制）。spec 模式下，AI 从一开始就看到完整的霂求、设计、任务列表。

可追溯性不同。

chat 模式生成的代码，三个月后你看到一段逻辑，不知道当初为什么这么写。spec 模式下，每段代码都能追溯到对应的 task → design → requirement。

一致性不同。

chat 模式的每次生成是独立的，前后可能矛盾。spec 模式的 task 是顺序执行的，后面的代码基于前面的上下文，整体一致。

实际体验

我用 Kiro 给 OpenClaw（开源 AI 助手框架）写了一个天气查询 Skill。

Spec 是这么写的：

天气查询 Skill。支持中英文城市名，
数据源 Open-Meteo（免费无 Key），
用 Bash + curl + jq 实现，
返回温度/湿度/体感/风速。

Kiro 生成了 7 条 requirements、一份 design 文档、5 个 tasks。我 review 了一遍（大概 3 分钟），确认没问题，点击执行。

15 分钟后，一个完整的、有错误处理的、代码风格统一的天气 Skill 就跑通了。

同样的霂求我用另一个 AI IDE 的 chat 模式试了一下，花了差不多的时间，但中间来回修正了 4 轮。最终代码能跑，但有几个地方风格不一致——因为是分次生成拼起来的。

其他值得关注的功能

Hooks（自动触发器）

你可以设置规则，比如：

  • 每次保存 .ts 文件，自动跑类型检查
  • 每次修改数据库 schema，自动更新类型定义
  • 每次改 API 路由，自动更新文档

跟 git hooks 的区别是，Kiro hooks 跑的是 AI agent，能理解代码语义。

Powers（能力插件）

给 AI 加上下文的插件系统。比如装了 Figma Power，AI 就知道怎么把设计稿转成代码；装了 Terraform Power，AI 就知道怎么写 IaC。

目前有 30+ 个 Powers，包括亚马逊云科技的 Bedrock、Amplify、Aurora、CloudWatch 等服务的官方 Power。

CLI

终端版 Kiro。SSH 到服务器也能用。

curl -fsSL https://cli.kiro.dev/install | bash

局限性

  1. Spec 有学习成本。习惯了 chat 模式的人第一次会觉得「步骤太多」。但这其实是把「写代码前想清楚霂求」的过程显式化了。
  2. 模型固定为 Claude。不能像某些工具那样自选模型。但 Claude 的代码能力本身不差。
  3. Powers 生态还在早期。数量不多，但质量不错。
  4. 国内访问可能需要代理。

适合什么场景

  • 需求复杂、涉及多模块的项目 → 适合
  • 需要长期维护、团队协作的项目 → 适合
  • 跟亚马逊云科技服务深度集成 → 很适合（Powers 全家桶）
  • 快速原型、一次性脚本 → chat 模式可能更方便

不是非此即彼。两种工具装着，按场景选。

🔗 Kiro 官网：https://aws.amazon.com/cn/campaigns/kiro/
🔗 Spec 开发文档：https://aws.amazon.com/cn/campaigns/kiro/
🔗 Powers 市场：https://aws.amazon.com/cn/campaigns/kiro/

标签: none

添加新评论