四款 AI 规范驱动工具的真实安装步骤计数

# 8 次点击还是 54 次：四款规范驱动工具在你写下第一行代码之前真正需要付出的代价

大家好，今天我开始撰写一系列文章，帮助你挑选适合 AI 编码代理的工作流程，弄清楚这些工具到底有多实用，以及在使用之前你真正需要做哪些准备工作。不是宣传视频里说的那种"一分钟内完全掌控 AI 上下文"。

第一篇比较四款工具：从零开始到第一个提示、真正开始写代码，需要经过多少步骤。后续几篇将进一步深入，探讨此后还需要多少步骤，以及那些提示里究竟包含什么内容。

今天我们要测试的工具如下：

OpenSpec
github.com/Fission-AI/OpenSpec (https://github.com/Fission-AI/OpenSpec)

GitHub Spec Kit
github.com/github/spec-kit

BMAD Method
github.com/bmad-code-org/BMAD-METHOD

Kiro（IDE）
kiro.dev


# 规则说明

在给出数字之前，先定义三个概念，方便你自行核对，而不是盲目相信我的计数。

**一个操作**是指我亲手完成的一件事：一次点击、一次需要思考的按键、一条输入的命令、一个选择的答案。等待生成不算操作。

**第一个提示**是指我能实际发送给代理的第一条工作流命令。对于某些工具，该命令携带我的想法；对于另一些工具则不然，我会在相应章节中说明。

**隐藏操作**是指工具没有告诉你、但不做就无法运行的步骤。这些会在每个章节末尾单独计数。

还有一条我始终遵守的规则：当工具提供选项时，我选择标注为"推荐"的那个。如果没有任何标注，我选列表中的第一个。

我使用的模型是 Claude Code，配合 Opus 5 高努力模式，Kiro 除外——Kiro 运行自己的代理并自行选择模型。

所有操作均手动计数，不使用任何自动化工具或 AI，这样我才能真正体验一个普通用户的感受——那种下定决心"好，我要掌控自己的 AI 日常，来试试 OpenSpec"的用户。

# 

# OpenSpec

README 是怎么说的

> Node 20.19+，两条命令，就这样。

## 
实际发生了什么

安装耗时 6 秒，80 个包，无报错，无询问。根据我的亲身体验，安装说明非常简洁，不需要任何复杂操作。

`openspec init` 打开了一个欢迎界面，并立刻告知我它会收集匿名使用统计数据，以及如何关闭该功能。如果真的是匿名的，我完全接受。但我知道对你们中的一些人来说这是个问题，所以让我们继续看看后面的情况。其实这取决于结果，如果效果足够好，我想我们可以对此视而不见。

接下来是一个包含 40 个工具的选择列表。Claude Code 排在第五位。我很喜欢这种极简风格和小巧的控件。总共有 40 个选项，甚至包括我们稍后要测试的 Kiro。选择 Claude Code 作为主工具。

设置完成。到目前为止共四个操作。

## 

## 它在我的项目里放了什么

`.claude` 文件夹包含 6 个技能和 6 个命令，`openspec` 文件夹包含 changes、specs 和 config.yaml。所以我在"openspec"里面得到了".claude"和"openspec"，哈哈。

我很喜欢这一点：不需要 git 仓库，不需要现有项目，不需要账号，不需要 API 密钥。

## 

## 然后我给它提供了想法

/opsx:propose "A single-page web app for planning a week: seven day columns, add a task to a day, mark it done, everything stored in the browser."

它在一个表单中提出了三个问题：技术栈、周模型和任务操作。每个问题都有一个标记为"推荐"的选项，所以本文将全程选择"推荐"。我知道你们大多数人也会这样做，然后继续看《蜘蛛侠》（哈哈，开个玩笑，继续聊）。

说实话，我希望任何地方都不要出现技术栈问题。我认为如果用户没有主动询问，就不应该被问到这个问题，但这只是我的个人看法。

3分钟09秒后，我得到了 proposal.md、包含7个需求和18个场景的 spec.md、design.md，以及包含17个复选框的 tasks.md。还有一行告诉我接下来该运行什么命令：/opsx:apply。

##

## 意料之外的事

它把自己的假设列成了一个清单，这样我就能看到它在哪些地方替我做了决定，而不是提问。

它在我开始构建之前就主动标出了自己方案中的薄弱环节：没有自动化测试，并解释了原因。

奇怪的是，推荐选项中并未包含"编辑任务"功能，这是个小细节，但你们都知道这个功能有多重要。

OpenSpec：第一次提示触发了8个动作，同一次运行就生成了完整的计划和任务清单。0个隐藏步骤。

# Spec Kit

README 说了什么

> 需要 uv，未指定最低版本。我用的是 0.12.10。

这个工具的描述与 OpenSpec 非常相似，我觉得从描述上看不出什么革命性的东西，但 Spec Kit 说可以引入自己的工作流，我想这一点我们会在以后的文章中再谈。

好了，废话不多说，开始安装吧。这个看起来已经有点繁琐了：

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z

specify init my-project --integration copilot 
cd my-project

README 里接着说：将 vX.Y.Z 替换为最新的 release 标签，保留开头的 v。所以他们给你的命令其实是跑不通的；你得自己去 releases 页面找最新的标签，然后手动粘贴进去。新标签每周发布一到两次，所以要么是他们发版太快来不及更新 README，要么就是纯粹懒得更新🤔。

跑一趟 releases 页面，是本文唯一的隐藏操作：README 并没有把它算作一个步骤，但如果不做这一步，命令根本跑不起来。

紧接着他们给出了第二条安装命令，直接从 PyPI 安装：`uv tool install specify-cli`，不需要手动粘贴标签。我测量的是第一条命令，因为那是他们主推的。

说实话，我有一定的 CLI 使用经验，切换版本之类的都做过，但我一直不喜欢自己去找这些东西，对我来说这确实很困扰。

命令默认写的是 copilot，那我们来找找 Claude Code 对应的选项。找到了，把 copilot 替换成 claude 就行。要查看支持的工具，要么运行 `specify integration list`，要么去文档里的 integrations 页面看。

##

实际发生了什么

安装本身大约花了4秒。15个包，一个可执行文件：specify。没有报错，没有提示。

`specify init` 接受了 `--integration claude` 参数，没有追问 agent 的问题，但它自己问了另一个问题：脚本类型，sh / ps / py，默认选中 sh。它要求选择某种脚本，我还是一头雾水。我个人会选 Python，因为看起来最熟悉，但我们要遵循推荐选项，所以直接按回车就好。

项目准备就绪。初始化速度非常快，我得到了一份命令和技能列表。它还警告我，agent 文件夹可能存储凭据，建议将 `.claude/` 加入 `.gitignore`，这是一个很大的优势。

但问题在于：这已经是四个操作了，我还没有描述我要构建什么。而用 OpenSpec 的话，想法在第一个工作流命令就输入进去了……

##

**它放进我项目里的内容**

`.claude/skills` 中有 10 个技能，还有 `.specify`，包含 integrations、memory、scripts、templates、workflows，以及 init-options.json 和 integration.json。

不需要 git 仓库，目前不需要，不需要已有项目，不需要账号，不需要 API key。

##

## **关于 agent 会读取周围一切内容的说明**

该死，我运行完 `/speckit-constitution` 正准备看看结果，Claude Code 却跑到上一级目录，读取了我用来记录每次运行情况的 `log.md`。这不是 Spec Kit 的锅，agent 就是会读取项目周围的内容。

于是我把笔记移走了，删除文件夹，从零重新运行 init。再次运行 `/speckit-constitution`，它还是知道得太多：它看到了相邻的 bmad、kiro 和 openspec 文件夹，直接告诉我这是一个四工具对比测试。我的笔记已经删了，光是文件夹结构就够它推断出来。

所以现在每个工具都放在各自独立的文件夹里，周围没有任何兄弟目录。删掉，从零初始化，这点我很喜欢。

第三次终于干净了：空文件夹，中性名称，没有相邻目录。这才是我要计入统计的那次运行。

##

**第一个命令和你的想法无关**

这正是 Spec Kit 和 OpenSpec 的分叉点。用 OpenSpec 时，我在第一个命令就输入了想法。而这里第一个命令是 `/speckit-constitution`，它完全不接受想法输入。文件夹是空的，所以 agent 从文件夹名称猜测项目内容，并向我提了三个问题来补全信息。

我注意到，constitution 的问题里没有任何一个带"推荐"标记，而 OpenSpec 每道题都会标出一个，所以我一直选第一个选项。这次我实际上得把每道题都读一遍，不能再一路按回车看《蜘蛛侠》了 ;(

第三个问题我完全不知道它在问什么，就选了模板默认值，而这还只是第一个命令的运行阶段，哈哈哈哈。

最终输出了 `constitution.md`，版本 1.0.0，五条原则。它自己加了第五条，并明确说明这条是它的推断。我感觉这个工具比上一个更严肃，在处理方式上会让你更深入地钻研自己的具体任务。接下来看看剩下 3 个命令会带来什么。

##

**然后，终于到了输入想法的时候**

`/speckit-specify "A single-page web app for planning a week: seven day columns, add a task to a day, mark it done, everything stored in the browser."`

3 个用户故事，16 个功能需求，8 个边缘情况，8 个成功标准，外加一份需求检查清单。检查清单 16 项通过了 14 项，两项未通过均指向同一个悬而未决的问题，它没有自行猜测，而是停下来询问我。

这让我想起 2025 年我曾写过的一个工作流，其中系统提示会持续自我审查，确保没有遗漏任何内容，并且所有决策都经过讨论。有意思的是，它问了一个和 OpenSpec 几乎相同的问题，关于"周"的定义：当前周与上一周，还是不带日期的纯粹一周。它推荐选项 A，于是我选了 A，继续往下走。

在我回答之后，检查清单变成了16/16，新增了两个需求，并重写了一个边缘情况。我注意到它思考了很多可以跳过的决策，看起来是把一个简单任务复杂化了。

##

计划阶段

`/speckit-plan` 生成了 plan.md 脚手架，并询问了技术栈。给出三个选项，TypeScript + Vite 标注为"推荐"。

哦对，到了选技术栈的环节。我知道现在不是比较的好时机，但 OpenSpec 将这个任务识别为简单任务并推荐了纯 HTML/CSS/JS，而 Spec Kit 显然是为更重型的任务设计的，这就是我们看到这种倾向的原因。

第二个问题是关于测试的。哈，测试来了，我喜欢这个工具，它有一套非常严格的工作流，在我看来能把一切掌控在手中。

最终生成了7个文件：plan.md、research.md、data-model.md、三份契约文件和 quickstart.md。规范检查通过5/5，其中一个推迟项被如实记录并给出解释，而不是悄悄隐藏。东西越来越多，我已经感觉自己好像写了10个功能了，哈哈。

有一点需要指出：它报告了"Branch: 001-weekly-task-board"，但文件夹里没有 git 仓库，也没有创建任何分支。`git status` 显示：不是一个 git 仓库。这个名称只是 spec 文件夹的名称而已。

##

任务阶段

`/speckit-tasks` 生成了 tasks.md，包含6个阶段共40个任务。每一个任务都是测试先于实现，因为我在规范中选定的原则是不可妥协的。它还标注了可并行的机会、文件冲突点，以及在第22个任务处的 MVP 截止点。

一个单页周计划器，生成了40个任务。我猜它在处理复杂任务时效果很棒，但它没有检查任务复杂度的验证器，所以每次我想添加某个功能——比如在不同日期间移动任务——都会得到一堆任务和漫长的等待时间。不知道这么多任务会消耗多少 token，不过这不是今天要聊的话题。

Spec Kit 总结：4次操作到第一个提示词，14次操作完成完整计划和任务。1次隐藏操作，就是查找发布标签。

# BMAD Method

README 怎么说的

> 需要 uv、Node.js、npm、Git，以及一个支持 skills 的 AI 编程工具。未给出最低版本要求。

README 看起来很酷，感觉像是发现了某个独立开发者的小众项目，而且开篇就看到了"流程自适应工作量"这句话——这正是 Spec Kit 所缺乏的。

三种安装方式：npx skills add、Claude Code 插件、Codex 插件。从一开始就覆盖了主要市场。我选 CLI 方式，因为它排在第一位，而且不依赖于你使用哪个 agent。

##

进入想法阶段前的八个操作

这是接下来发生的事情的精简版，下面是详细版。

命令要求先安装 skills 包，所以需要一次确认。然后它克隆仓库，找到29个 skills 并打开一个选择器。README 说要选择你需要的，并包含 bmad，但没有说明其余28个中哪些重要。

看到一堆 skills 可以选择。这个安装界面在终端里内置了"搜索"功能，我是第一次见到这个，实在太棒了。不管怎样，我直接选了"全选"。

下一个界面：79个 agents。哇，这次覆盖了79个工具，我简直无法想象支持所有这些工具花了多少时间。其中20个是"通用"类型，会自动安装，但原因不清楚。Claude Code 并不在其中，它在"附加"列表里，需要手动选择。

然后是安装范围：Project（项目）或 Global（全局）。选择"Project"，因为它是第一个选项，也是我们的测试用例。它说"与你的项目一起提交"，所以我以为某个时刻需要一个 git 仓库。剧透：始终不需要。

然后是安装方式：Symlink（符号链接）或 Copy to all agents（复制到所有代理）。它仍然在问关于安装的问题，我完全不知道 symlink 是什么，也不知道"复制到所有代理"在这里是什么意思。当然我可以去查文档或者问 AI，但我希望仅凭安装过程本身就能稍微理解一点。选择 Symlink，这是推荐选项。

进行到第八个操作，我还一个字都没说关于自己要做什么。

##

**安全性表格**

然后出现了其他工具都没有的东西：一张安全风险表，涵盖全部 29 个技能，来自三个扫描器——Gen、Socket 和 Snyk，各自给出自己的判定。一个技能被 Gen 评定为高风险，另一个被 Snyk 评定为高风险，还有几个是中等风险。

嗯，他们为什么要给我看这些红色的"高风险"标记！下面有一个详情链接，我点进去，没有找到对 Gen 或 Snyk 所谓高风险含义的解释。算了，先继续完成吧，我都走到这一步了哈哈。

我确认，又收到一个新提案：安装一个用来查找技能的技能，哈哈哈，好吧冲了。值得注意的是，这个安装到的是你的主目录，而不是项目目录。

然后是 bmad setup，什么都不问，静默创建了一个包含配置和脚本的 `_bmad` 文件夹。根据文档，这是完成安装的最后一条命令，现在该输入想法了。我希望现在终于轮到技术栈的问题了哈哈。

##

**想法，在第十个操作**

bmad-build：一个用于规划一周的单页 Web 应用：七列对应七天，可以向某一天添加任务，可以标记完成，所有内容存储在浏览器中。

而它问的第一件事是是否使用子代理。

我完全没预料到这个问题，我以为这类决定是在工作流内部解决的。而且问这个的甚至不是 BMAD，而是 Claude Code：它自己的规则是除非我明确说明，否则不生成子代理，而 BMAD 工作流恰恰是围绕子代理构建的。所以我收到的第一个问题不是关于我的应用，而是两个工具在工作方式上产生了分歧。好吧，选择推荐选项。

之后它起草了一份规格说明，并在一个表单中一次性提了三个问题。

交付方式：拆分文件并使用 `node --test`，推荐选项。终于到了技术栈问题，有趣的是它提议用 Node 来写测试，这是个新东西。

任务操作：添加加删除，推荐选项。一如既往，删除是它眼中最重要的功能，但三个工具都这么选，说明对任务的理解是到位的。

周模型：通用的周一至周日，推荐选项。三个工具都问了同样的问题。

##

**产出的结果**

一个文件：`spec-week-planner.md`，约 1550 个 token。不是一套文档，而是一份规格说明。

它在一个冻结意图块中记录了我的三个决定，锁定了一条它自行调查发现的约束（`file://` 会阻止 ES 模块导入，因此逻辑文件必须同时兼容浏览器和 Node 测试运行器），并构建了一个包含九行的输入/输出矩阵，涵盖存储损坏、隐私模式和 XSS 形式的任务文本。

不错，规格说明出来了。我立刻想对这句话表示敬意："理想情况下在另一个会话中使用其他技能，以避免上下文膨胀"。这个工具主动维护上下文，对我个人来说这是个很大的优势，尤其是当任务不是一个简单的周计划应用的时候。

然后它提供了三种继续方式：批准并实施、批准并停止，或先让子智能体审核规格说明。我选择了批准并停止，想看看实施之前是否会出现任务列表。

结果没有。规格说明被标记为"待开发"，意图块被冻结，就这样结束了。我本以为会像之前的工具那样得到更多文件或任务，但它只是告诉我它重新从磁盘读取了规格说明，并更改了其状态。

BMAD Method：到第一个提示需要10步操作，到审批通过的规格说明需要15步。完全没有任务列表，工作流程从规格说明直接跳到实施阶段。隐藏操作：0。

# Kiro（IDE）

官网介绍

> 三个入口：Kiro Crew、一个IDE和一个CLI。我们选择IDE，那是产品主推的界面。

与其他工具不同，这是一款付费产品，作为普通用户，我会在下载之前先查看定价。免费计划提供50个积分，可访问开源权重模型以及Claude Sonnet 4.5，但有使用限制。

这是唯一一个需要认真考虑自己在做什么、使用哪些功能的工具，因为任何探索都有浪费金钱的风险。

打开他们的网站，看到紫色设计——很多人称之为AI烂俗风格，但我能看出这里花了大量心思，动画效果和各个版块看起来都很扎实。

## 
启动运行

下载IDE，选择Apple Silicon，243 MB的dmg文件。拖入应用程序文件夹。启动。

它立刻要求我登录。这是四款工具中第一个需要账号的。

浏览器里有四个选项：Google、GitHub、AWS Builder ID、你的组织。跟大家一样选Google，不打算在选方式上浪费时间。

然后是引导流程。导入VS Code配置，我跳过了，因为把我的扩展混进去既不公平，况且也不是所有人都用VS Code。然后是主题：深色或浅色，默认选中深色，这已经给你一种出门前盛装打扮的感觉。用浅色主题的朋友，请告诉我们你们的存在哈哈哈。

然后是Shell设置，有意思的地方来了：macOS请求管理员权限。Kiro会自己发起提示，所以我甚至不需要在这个工具里手动提示，哈哈。说正经的，这是四款工具中第一个申请管理员权限的，而且不是为了工作流程，只是为了把一条命令添加到PATH里。

输入密码后，编辑器终于打开了，立刻弹出一个关于迁移之前会话的模态窗口——而这是全新安装，我根本没有任何旧会话。在它后面，还有三个关于我从未用过的功能的介绍屏。我完全不知道那些是什么，而且在这个阶段也不太可能有人去看文档，所以我直接关掉。

## 

十五步操作才到第一个提示

它显示了一个"打开项目"的按钮，我有些困惑，没有像VS Code那样直接新建项目的按钮。于是我找到并打开了我们的week-planner文件夹 -> 信任对话框，当然选择信任。

编辑器打开，右侧显示四个工作流：Spec（规格说明）、Plan（计划）、Bug Fix（修复Bug）、Quick Spec（快速规格说明）。全部标注为可选，意味着我完全可以直接在聊天框里输入，跳过所有这些。这个工具给了你相当大的自由度，但作为刚下载这个应用的用户，我更希望有更具引导性的一步步操作。你大概也不知道该选哪个，就会直接把任务输入聊天框。Spec排在第一位，于是我点击它。

没有任何反应。它只是被高亮显示了。我想我还是直接开始打字吧。

一款用于规划一周的单页 Web 应用：七个日期栏，可向每天添加任务、标记完成，所有内容存储在浏览器中。

它还会询问这是新功能还是 Bug 修复。在一个空文件夹里，什么都不存在。当然选"Build a Feature（构建功能）"。

然后是：需求还是技术设计。类似 BMAD 对工作流本身的提问，我选了推荐选项。

##

然后是审批确认。

运行 mkdir 的授权请求：允许、始终允许、拒绝、始终拒绝。我们所有人在任何编程 Agent 里都见过这种提示，我通常会点"始终允许"，省得它每次都来问我。最近我甚至启用了 dangerously-skip-permissions。但我们选了高亮选项，点了"允许"。

然后又点了一次允许。再一次。

早知道就点"始终允许"了，这种感觉真让我抓狂——像极了半年前我第一次试用 Claude Code 时，以为根本没办法一次性授权的那种崩溃。

运行过程中我四处看了看这个应用。它是另一款 VS Code 风格的编辑器，和 Cursor 一样，有源代码管理、扩展、调试功能，但多了一个像 AI 扩展的"Ghost"区域：技能、钩子、规格。

跑完的时候，我已经点了 32 次允许。其中有些是让它读一个它自己刚写完的文件，连续点了两次。

如果你觉得审批确认不算操作，减掉这些，Kiro 实际落在 22 步。

##

最终产出

某个时刻，requirements.md 出现了，包含六条需求。其中有一个"清空当天"操作，这个设计很聪明，省得我一条一条删 20 个任务。

然后出现了三个选项：生成技术设计、生成任务列表、分析需求。我们急需提示词，于是我点了"生成任务列表"。

结果它开始生成 design.md。等等，我明明点的是"生成任务列表"，它为什么去生成设计文档？大概这是流程的一部分，但我看不出我点的那个按钮和它实际做的事之间有什么联系。

不过最终它确实到达了终点。三份文档全部生成：requirements.md、design.md、tasks.md。零依赖的 SPA，基于 localStorage 的纯函数状态层，用 fast-check 验证的 6 个正确性属性，以及 7 个实现里程碑。

它从未问过我关于技术栈、周格式或测试的问题。所有决策都是它自己拍板的，而且从我沿途看到的部分决策来看，这个工具会自己考虑用户体验。

仅规划阶段就消耗了编辑器底部计数器显示的 50 个免费积分中的 6.94 个。消息本身报告估计花费 3.35 积分，其余都花在了周边的各种操作上。耗时：41 分 50 秒。

Kiro：15 步到达第一个提示词，54 步完成含任务的完整规划。其中 32 步是授权点击。无隐藏操作。

#
结论

##它们的共识

四款工具中有三款问了关于"周"的同一个问题：固定的周一至周日栏，还是带导航的真实日期？三款都推荐了最简单的方案，不显示日期。Kiro 从未发问，径自选择了当前周的真实日期。它还额外添加了一个"清空当天"操作，其他任何工具都没有提供这个功能。

四款工具都自行加入了删除功能，却没有一款提出编辑任务的功能。如果你把同样的需求句子交给一个人，编辑功能大概是他最先想到要问的。

它们都不需要 git 仓库、现有项目或 API 密钥。只有 Kiro 需要账号，也只有 Kiro 申请了管理员权限。

三者都在我没有提及技术栈的情况下问起了相关问题，而且每次推荐的答案都不一样：一个 HTML 文件、TypeScript 配合 Vite、用 node --test 拆分文件。Kiro 没有询问，自己做了选择。

## 分歧所在

同一句话产生了四种截然不同的工作量。OpenSpec 写了 17 个任务，Spec Kit 写了 40 个，Kiro 写了 7 个里程碑，而 BMAD 根本没有生成任务列表。

其中两个工具在交付成果前会自行检查输出。OpenSpec 列出了它所做的假设，并标注了计划中缺少测试的问题。Spec Kit 对照清单核查了自己的规范，并在两个无法回答的条目处停下来。

其中一个工具统计了自身的局限：Kiro 仅在规划阶段就花费了 6.94 个积分和 41 分钟。OpenSpec 完成同等工作只用了 3 分钟。

还有一个数字不符合规律：Spec Kit 在 4 步操作内到达第一个提示，是四者中最少的，但那个提示并不接收你的想法，而是询问项目原则。想法要在五步操作之后才能输入。

# 我的看法

**OpenSpec**

我真正会留下来用的那一个。两条命令、四步操作，规划就已经完成了。安装说明简单，不需要任何复杂操作，工具选择极简，而且它主动告知了遥测信息，而非将其隐藏。

打动我的是它的主动行为：它写下了自己所做的假设，让我看清它在哪些地方替我做了决定，并在我开始构建之前就标出了计划中的薄弱环节。我唯一的抱怨是编辑任务没有出现在推荐选项中，说实话，我也宁愿它根本不问技术栈的问题。

如果你是独自开发一个小型 Web 应用，从这里开始。

**Spec Kit**

四者中最严格、也最繁重的一个。他们推介的安装命令根本无法直接运行，你得自己去找一个发布标签，而第一条命令根本不涉及你的想法，而是询问项目原则——那些我完全不知道如何回答的问题。

但一旦进入正轨，它有一套严格的工作流程，能把一切都掌控在手。它会检查自己的规范，遇到无法回答的问题会主动停下来，还提醒我注意 agent 文件夹中的凭据问题——其他工具都没有这么做。

但是，为一个单页周计划工具生成 40 个任务。它处理复杂任务时表现出色，但没有验证器来检查任务的复杂度，所以每一个小功能都会产生一堆任务和漫长的等待。

如果你在参与一个有团队、有规范要求的真实项目，就选这个。对于周末应用来说，它太重了。

**BMAD Method**

README 读起来像是发现了某位独立开发者的小众之作，"流程规模随工作自适应"这句话正是 Spec Kit 所欠缺的。

安装需要八步操作，我才能说出关于应用的只言片语，其中一半是关于符号链接和安装范围的问题，我无法自信地回答。那张带有红色"高风险"标签却毫无解释的安全风险表格，也没让情况变好。

但输出内容颇为周到，而且它是唯一一个告诉我把繁重工作放在独立会话中运行以避免上下文膨胀的工具。它会照顾好你的上下文，对我来说这是一大优势，尤其是当任务不只是一个简单的周计划工具时。

然后它停在规范阶段，直接跳到实现，完全没有任务列表。

**Kiro**

唯一需要付费的工具，唯一要求注册账号的工具，也是唯一申请管理员权限的工具。网站看起来投入了大量心血，编辑器是另一个类似 Cursor 的 VS Code 克隆，带有专门用于 AI 的幽灵区域。

54 个操作，其中 32 次点击"允许"。有一次它请求读取一个它刚刚自己写入的文件，连续两次。我点了高亮按钮而不是"始终允许"，为此后悔了整整四十分钟。

它也从未问过我关于技术栈、周格式或测试的问题。所有决定都由它自己做出，而且某些决定表明这个工具会自主考虑用户体验——比如添加了一个"清空当天"操作，其他工具都没有提供这个功能。

41 分钟，消耗了 50 个免费积分中的 7 个，仅仅是为了规划。这才是真正会让我望而却步的地方。

##

## 这意味着什么

宣传视频说你能在一分钟内完全掌控你的 AI 上下文。这四款工具中最便宜的耗费 8 个操作，最贵的耗费 54 个。没有一款能在一分钟内完成。

而且操作数量本身并不能告诉你哪款更好。Spec Kit 是四款中最快到达第一个提示词的，却让我花了最长的时间。Kiro 没有向我询问任何关于应用的问题，却仍然生成了一份扎实的规格说明。这四个数字衡量的是摩擦，而不是质量。

> 感谢阅读。希望对你有所帮助，我很想听听你的想法，尤其是如果你得出了不同的数据。

你参与其中的程度比你想象的要深。你告诉我接下来想看什么，我就去测量什么。

目前我在思考的是：那些提示词里究竟有什么，以及第一步之后还有多少步骤。