去年这个时候，谁再给我推荐“又一个 AI 编程编辑器”，我大概率会先翻个白眼——这个品类在过去两年里多到让人麻木，装一圈下来，真正能留在快捷键里的没几个。所以我第一次打开 Kiro 的时候预期很低：无非是聊天窗口换个位置，再加个自动改文件的按钮。一年过去，我的判断变了，但变的原因不是它把补全做得更花哨，而是 Kiro IDE、Kiro CLI、Kiro Crew 这三样东西被拼成了一个能互相接力的闭环：想法在 IDE 里落成文字，文字在 CLI 里跑成流水线，流水线里那些可拆分的脏活则丢给 Crew 去并行啃。这篇就按我一年下来真实的体感，把这三叉戟各自的分工边界、什么时候该上哪一件、串起来怎么编排，以及我踩过的那些坑，一条条摊开讲。如果你是那种已经把 AI 助手用成“高级搜索框”的人，或者团队里正在争论要不要把智能体放进 CI 的人，下面的内容应该能帮你少走几个月弯路。

1. 三叉戟的真实分工：同一套内核，三种“触达代码”的手部动作

很多人第一次看这张产品矩阵，会本能地理解成“三个版本”——就像某些工具分免费版、专业版、企业版那样，IDE 是完整版，CLI 是阉割版，Crew 是加钱版。这个理解是错的，而且错得挺贵——按这个思路选型，你会在错误的场景里用错误的形态，然后得出“AI 编程不过如此”的结论。我用了一年之后最确定的一件事是：这三者的差别不在能力多少，而在交互节奏和触发方式。

1.1 不是能力分层，是交互节奏的分层

Kiro IDE 的核心特征是“人在环内、边看边改”。你在编辑器里，光标在哪、选中了什么、打开了哪几个文件，这些上下文都在，智能体的每一步动作你都能看见、能打断、能回退。它适合的是那些你还没想清楚要什么的任务——需求模糊、边界不清、需要来回试探。这时候快不是第一位的，可观测和可干预才是。

Kiro CLI 的核心特征是“无人在场、一次成型”。它跑在终端里，没有 GUI，没有光标上下文，你给它一段指令，它跑完吐结果。这意味着它天然适合放进脚本、放进流水线、放进远端机器。它的优势不是“更轻”，而是可编排——能被&&串起来，能被定时任务调起来，能在没有图形界面的容器里跑起来。

Kiro Crew 的核心特征是“多个执行体、共享一个工作区”。它解决的不是“单次任务怎么做”，而是“一件能拆成五份的活，怎么让五个执行体不互相踩脚”。这个层次的复杂度是跳变的，因为一旦并行，就产生了协调成本、冲突成本、以及“谁来验收”的问题。

把这三者放在一张表里对比，会清楚很多：

最后一行那个 60/30/10 是我统计了自己近三个月的实际使用时长之后估的，不是官方建议。这个比例很说明问题：最花哨的那个反而用得最少，因为大部分日常工作的复杂度根本没到需要多智能体编排的程度。认清这一点，能省下不少钱和时间。

1.2 让三叉戟成立的地基：资产是共享的

如果三个形态各自维护一套配置、各自记一套规则，那它们就只是三个独立产品捆在一起卖，谈不上“三叉戟”。真正让这套组合产生复利的是：规则文件、规格文档、工具接入配置，这三类是共享的。

我自己的项目里有一个固定目录，长得大概是这个样子：

项目根目录/ .kiro/ steering/ # 长期生效的规则，团队约定写这里 coding-style.md testing-policy.md api-conventions.md specs/ # 单个需求的规格产物 order-export/ requirements.md design.md tasks.md hooks/ # 事件触发的自动化 on-save-format.json

关键在于：我在 IDE 里为“订单导出”这个需求写下的requirements.md，CLI 可以直接读取它去执行任务清单里的某一条；Crew 里负责写测试的那个角色，读的也是同一份design.md。同一条约束只写一次，三个入口都吃得到，这才是三件套合起来比三件单品的总和更值钱的原因。我见过不少团队，规则写在聊天记录里、写在群公告里、写在某个人的脑子里，结果换个入口就全丢了，AI 每次都像新员工第一天上班。

提示：如果你只想先试一件，从 IDE 开始；如果你想先验证价值，先花两个小时把steering目录写扎实。这一步的投入产出比，比换任何模型都高。

2. Kiro IDE：价值不在补全，而在把“想清楚”变成能落盘的产物

我用过太多“输入注释自动生成函数”的工具，那类东西的天花板很明显——它优化的是打字速度，而实际开发里打字占的时间可能不到两成。Kiro IDE 让我留下来的原因，是它把重心压在了另外那八成上：把模糊的口头需求，逼成一份能被人复查、能被机器执行的文档。

2.1 规格先行的真实体感：慢半小时，省一整天

它的核心工作流是“先出规格，再出代码”。你描述一个需求，它不会立刻开始改文件，而是先产出一份需求文档，里面是一串带编号的验收条目；你确认或者修改之后，它再产出设计文档，讲清楚要动哪些模块、新增哪些接口、有什么取舍；最后才拆成一份可勾选的任务清单，一条条执行。

第一次用的人普遍会烦：怎么这么多步骤，直接写代码不行吗。我一开始也是这个反应，直到有一次我跳过规格直接让它改，结果它把我一个对外接口的返回结构给改了，下游三个调用方全炸。那次之后我就老实了。现在我评估一个需求的规格阶段大概花 20 到 40 分钟，看起来是额外开销，但它省掉的是后面反复返工和 review 时扯皮的时间。

一份需求文档我通常要求它长成这样，条目必须可验证，不能是“性能要好”这种废话：

## 需求条目 - R1: 导出任务支持按时间区间筛选，起止时间均为闭区间。 - R2: 单次导出上限 50000 行，超出时返回明确错误码而非静默截断。 - R3: 导出过程中断后可从最后一个成功分片续传。 - R4: 导出文件的列顺序与列表页展示顺序保持一致。 ## 明确不做 - 不支持自定义列（下一期）。 - 不支持导出到外部存储（合规待评估）。

注意“明确不做”这一节，这是我认为整份文档里最值钱的部分。AI 最大的浪费不是做错，是热情地做了你没要的东西。把边界写死，比把要求写全更能收敛结果。

2.2 事件钩子：把“每次都要提醒它”变成“它自己记得”

规格是单次的，规则是长期的。长期规则放在steering目录里，我一般分三类写：编码风格、测试要求、接口约定。写这些的时候有个诀窍——不要写形容词，要写可判定的条件。“代码要清晰”这种话等于没说；“单个函数不超过 60 行，超过就拆”才是能执行的。

再往上一层是钩子。钩子的意思是“当某个事件发生时，自动跑一段智能体动作”。我配置最多的是保存时检查，示意配置大概是这样：

{ "name": "on-save-lint", "trigger": { "type": "fileSave", "glob": "src/**/*.ts" }, "action": { "type": "agent", "prompt": "检查刚保存的文件是否违反 steering/testing-policy.md，只报告不修改" } }

这里有个我踩过的坑：钩子千万别设成自动修改。我早期设过一个保存即自动修复的钩子，结果有一次我在改一个半成品文件，中途保存了一下，它“顺手”把我没写完的逻辑补全成了一个看起来合理但完全错误的分支，而我过了二十分钟才发现。现在我所有钩子都是“只报告不修改”，改不改我自己决定。这个原则我称为钩子只做哨兵，不做手术刀。

2.3 什么时候不该用它

说句公道话，IDE 形态不是万能的。三种情况我会主动切走：一是任务极其确定，比如“把这个目录下所有文件的某段 import 路径批量替换”，用 IDE 一轮轮确认纯属浪费时间，CLI 一条命令解决；二是需要跑很久的活，比如全量回归、批量重构，占着编辑器不如丢后台；三是我自己都没想清楚要什么的时候——这种时候我会先用纯文本把想法写下来，再喂给它，而不是在对话框里边想边问，那样它会被我的犹豫带偏，来回改五轮都收敛不了。

3. Kiro CLI：把 AI 编程从“个人手感”变成“流水线零件”的那把钥匙

CLI 这一支在宣传里往往最不起眼，因为它没有界面可截图。但在我看来，它才是这套组合里唯一能改变团队协作方式的部分。IDE 提升的是个体效率，CLI 提升的是流程效率，这两者的量级差一个数量级。

3.1 无头执行才是它真正的定位

“无头”这个词听着唬人，说白了就是不需要人坐在前面看着。终端里发一条指令，它自己跑完，把结果写进文件或者标准输出。这一点带来的变化是根本性的：它可以被放进任何能执行命令的地方——本地脚本、构建流程、定时任务、容器里的初始化步骤。

举几个我实际在用的场景，命令是示意写法，具体参数以你本地版本为准：

# 场景一：按规格里的任务清单，只执行第 3 条 kiro-cli run --spec .kiro/specs/order-export --task 3 # 场景二：把最近一次改动的 diff 交给它做自审 git diff HEAD~1 | kiro-cli chat --agent reviewer "只报阻塞级问题，不要风格建议" # 场景三：批量给新增文件补测试骨架 kiro-cli run --prompt "为 src/services 下今天新增的文件生成测试骨架，不修改源文件"

第二个场景是我用得最多的。提交前自审这件事，人工做容易疲劳，做久了就糊弄；交给一个只看 diff、只报阻塞级问题的角色，成本低而且稳定。这里的关键是那句“只报阻塞级问题”——如果你不说，它会给你吐三十条风格建议，然后你就再也不看它了。

3.2 参数设计背后的取舍：为什么要卡“只读”和“超时”

CLI 用久了会发现，真正决定它好不好用的是几个不起眼的开关。我总结下来最该关注的三个是：

我吃过一次亏：早期在流水线里跑一个可写模式的任务，没设超时。某次它读错了一个路径，陷入“找不到文件→再找一遍”的循环，把整条流水线卡了四十多分钟，而报警是流水线整体超时才触发的，等我看到的时候，当天的发布窗口已经错过了。从那以后我的规矩是：流水线里的智能体一律只读 + 硬超时 10 分钟，要它改代码，就在本地跑，人看着改。

3.3 让 CLI 好用的两个前置条件

第一个条件是任务必须自带验收标准。CLI 里没人盯着，它跑完你只能看结果。如果任务本身没有可判定的成功条件，那它交回来的东西你就只能靠肉眼扫，等于把省下的时间又还回去了。我的做法是每个 CLI 任务都配一个可执行的检查，比如“跑完必须让这个测试文件通过”“跑完必须让这个脚本输出 PASS”。

第二个条件是上下文要显式给足。IDE 里它知道你在看哪个文件，CLI 里它不知道。你得把路径、把相关文档、把约束条件都写进指令里。我一般的模板是：目标是什么、涉及哪些目录、遵守哪份规则文件、验收标准是什么、不许动哪些东西。写长了确实烦，所以我把它固化成了一个 prompt 模板文件，每次引用。

目标：为核心服务补充边界测试 范围：src/services/export/ 下的全部文件 规则：遵循 .kiro/steering/testing-policy.md 验收：新增测试全部通过，且原有测试无一失败 禁止：修改任何 src/ 下的非测试文件

这五行写下来不到一分钟，但它能把跑偏率压下去一大半。指令里明确“不许做什么”，比列十条“要做什么”更有效。

4. Kiro Crew：多智能体的收益与成本，算清楚再开

如果说前两支是“怎么用 AI”，Crew 这一支讨论的是“怎么组织一堆 AI”。这是三件套里最容易被高估的部分——演示视频里几个智能体你来我往地讨论，看起来特别像那么回事，但真到自己项目里跑，很容易变成一场昂贵的混乱。我用下来的结论是：它确实有不可替代的场景，但那个场景比宣传片里窄得多。

4.1 收益来自“可拆分”，不是来自“并行”

多智能体的本质收益是并行，而并行只在任务真的能拆开的时候才成立。什么叫真能拆开？我总结了三个判据：

• 子任务之间不修改同一批文件，或者能通过目录边界彻底隔开；
• 子任务之间不共享中间状态，不需要 A 的输出才能开始 B；
• 每个子任务都有独立的验收方式，能单独判断对错。

三条同时满足，才值得开多智能体。举个例子，“给一个已有模块补全单元测试、同时补全文档、同时做一次依赖升级评估”，这三件都不改同一批源文件（测试在测试目录、文档在文档目录、评估只读），验收标准各自独立——这就是典型的多智能体场景。

反过来，“重构一个核心类的内部结构”这种任务，看着挺大，但它所有改动都落在一个文件里，拆开就是互相打架。这种事交给一个执行体串行做反而更快。

4.2 角色分工比并行度更重要

Crew 的另一层价值是把角色显式化。我自己常用的是三角色模型：规划者负责把需求拆成有依赖关系的任务图，执行者负责按图施工，审查者负责在验收节点上挑毛病。这三者的 prompt 完全不同，规划者要保守、要问问题；执行者要果断、要不啰嗦；审查者要苛刻、要只报阻塞项。

这里最值钱的是审查者独立于执行者。同一个体写代码再自己审，几乎必然自我宽容；换一个只看需求条目的角色来挑，命中率高得多。我实测下来，审查者能捞出的问题里，大概三成是我自己 review 时会漏的，主要是边界条件和错误路径。

4.3 成本账：为什么我把它的占比压到了 10%

多智能体的成本不只是钱，是三层叠加：

第一层是直接消耗。五个执行体各跑一轮，消耗量大概是单体的三到五倍，如果中间再来几轮审查打回，翻个七八倍很正常。这个数字不难理解，但很多人没算过第二层。

第二层是协调成本。你可以理解为“对齐开销”——每个执行体都要读一遍上下文、理解一遍规则，这部分工作重复了 N 次。任务拆得越碎，重复比例越高。我踩过一个坑：把一个本来两小时能做完的任务拆成了十一个子任务，结果光上下文重复读取就花了快一小时。

第三层是冲突修复成本。两个执行体改了同一个公共文件的不同位置，合并的时候出现逻辑冲突——不是文本冲突，是两个人都加了相似的工具函数，代码能编译但语义重复。这种问题编译器不报、测试不挂，只能靠人看。

这三层加起来，就是我把 Crew 的日常占比压到 10% 的原因。它适合的是一周里那一两次真正大的、能切的活，不是日常。

注意：多智能体最容易失效的地方不是模型不行，是任务边界没切干净。开跑之前花十分钟确认“谁改哪些目录”，比跑完之后花两小时合冲突划算得多。

5. 一天的真实编排：三件套串成一条流水线长什么样

讲了这么多定位，落到实操上，我更想分享一个具体的、可复现的一天。这套流程我在过去几个月里反复跑，已经比较稳定，你可以直接照搬骨架再按自己项目调。

5.1 上午：IDE 里把需求磨成规格

接到一个“导出功能加续传”的需求，我不急着让它写代码。第一步是在 IDE 里把需求条目写出来，一条条确认。这个过程我大概会来回改三轮：第一轮它写得比较笼统，我挑出模糊的地方追问；第二轮补上边界条件，尤其是“超限怎么处理”“中断怎么恢复”；第三轮把“明确不做”补齐。

三轮之后我会做一个动作——把规格读一遍，问自己“如果我是审查者，我能拿这份文档判对错吗”。判不了，就说明还没写清楚，继续磨。这一步偷懒，后面全都要还。

规格定稿之后，让它拆任务清单。任务清单我要求每条都带三样东西：改哪个文件、验收标准是什么、依赖哪一条。这时候我不让它开始执行，因为下一步要做的判断是“这些任务里哪些能并行”。

5.2 下午前半段：CLI 跑确定性任务

从任务清单里挑出那些确定性高的——比如“补全错误码枚举”“生成测试骨架”“更新接口文档”。这些活的特点是有明确输入输出、不需要来回试探，正好是 CLI 的主场。我会把它们写成一个脚本批量跑：

#!/usr/bin/env bash set -u SPEC=".kiro/specs/export-resume" for task in 2 4 7; do echo "==> 执行任务 ${task}" timeout 600 kiro-cli run --spec "$SPEC" --task "$task" \ --read-only false --output json > "logs/task-${task}.json" || { echo "任务 ${task} 失败或超时，停止" exit 1 } done

这段脚本里有三个细节值得说。set -u是防止变量没定义时静默执行；timeout 600是硬超时，防止单点卡死整批；|| exit 1是失败即停，绝不带着失败继续往下跑。第三条尤其重要——批处理最怕的就是带着错误继续，跑完一堆结果你根本分不清哪个是可信的。

跑完之后我不会直接信结果，而是看logs目录里每个任务的输出，重点看两个东西：改了哪些文件、自测有没有过。改动的文件数如果超出预期，说明它越界了，要回退。

5.3 下午后半段：Crew 处理可并行的大块

剩下的那些互相独立、各自都要花一两个小时的活，才交给 Crew。比如这次是“补测试”“补文档”“评估一个依赖升级的影响”三件。开跑之前我会做两件事：

第一件，把目录边界写死。测试只许动tests/，文档只许动docs/，评估任务全程只读。边界写在每个角色的 prompt 第一行。

第二件，设一个审查节点。三个执行体跑完之后，审查者统一过一遍改动集，对着需求条目逐条核对覆盖率。这一步不能省，因为并行跑出来的东西，单独看都合理，合在一起才可能出问题。

5.4 收尾：人工复核只做三件事

一天下来最容易被忽略的是收尾。我的复核清单只有三条，但每条都必须过：

• 需求条目逐条对照，覆盖了没有、有没有多做；
• 改动的文件清单和预期是否一致，有没有意外文件被改；
• 跑一遍全量测试，看有没有“能编译但语义不对”的地方。

第三条是我的血泪教训。有一次两个执行体各自加了一个时间格式化工具函数，名字不同、逻辑几乎一样，测试全过、编译全过，直到两周后有人发现同一份数据在两个页面显示不一致才暴露出来。并行产出的重复实现，是最难被自动化发现的一类缺陷。

6. 一年踩下来的六个坑，以及我现在怎么绕开

前面讲了怎么用，这一节讲讲怎么用砸了。我把它写成排查链路的形式，因为坑的价值不在于“知道有这回事”，而在于下次遇到类似症状时能按图索骥。

6.1 症状：它改得越多，我改得越多

这是最常见的抱怨。表现是：你让它做一个改动，它顺手重构了周围的代码、改了命名、调整了导入顺序，最后 diff 有两百行，其中只有二十行是你要的。你花在审 diff 上的时间，比自己写还长。

排查下来根因通常有两个：一是规则文件里没写“不许做范围外的重构”，二是任务描述太宽。我的修法是双管齐下——在steering里加一条硬规则“只修改与当前任务直接相关的行，不做任何未被要求的重构”，同时在每次指令末尾加一句“禁止修改任务范围外的文件”。

如果只想做局部改动，还有个更狠的办法：先让它只输出方案，不落盘。看方案没问题了，再让它执行。多一轮交互，但省掉一次大面积回退。

6.2 症状：同样的错误反复犯，教了也不记

第二类坑是“记忆断片”。你在对话里纠正过它一次，下一轮它又犯了。这不是它笨，是对话上下文和长期规则是两回事——对话里的纠正只在这一轮有效，换个会话就没了。

正确的做法是把纠正沉淀到文件里。我的习惯是：每次我在对话里纠正它一次，如果这个纠正以后还会用到，我立刻把它写进steering的对应文件。一年下来我的coding-style.md从十几行长到了八十多行，但重复纠正的次数明显下降了。

6.3 症状：任务跑成功了，但结果不能用

这个坑最阴险，因为它不报错。表现是 CLI 任务返回成功，你看日志也是成功，但生成的东西不符合实际约定——比如字段名用了驼峰，而项目里统一是下划线。

根因是验收标准缺位。CLI 判“成功”的标准是“任务执行完毕”，不是“结果符合项目约定”。解决办法是把约定变成可执行的检查：能写成 lint 规则的就写 lint，能写成测试的就写测试，实在写不出来的，就在任务里明确列出“必须遵守的命名对照表”。我现在的原则是凡是能被脚本检查的，绝不靠人眼检查。

6.4 症状：多智能体跑完，代码能编译但行为诡异

前面提过的那种，两个执行体各写了一份功能重复的工具函数。这类问题的排查链路我总结成三步：

1. 先看改动文件清单，看有没有两个执行体碰了同一个文件——如果有，重点查这里；
2. 再看新增的公共函数，按函数名排序扫一遍，找语义相近的——这一步纯人工，但很快；
3. 最后跑一次端到端，重点看跨模块的数据一致性，因为重复实现最容易在跨模块处暴露。

预防手段比排查重要：开跑前把公共目录设成只读，让所有执行体只能新增自己目录下的东西。

6.5 症状：成本突然翻倍

有一周我发现消耗量涨了三倍，但产出没变。翻日志发现是两个原因叠加：一是某个钩子在保存时被反复触发（我在批量改文件，每次保存都触发一次全量检查），二是某个任务的上下文里带了一整个大目录的文件。

第一个的修法是给钩子加节流，或者把触发范围收窄到具体目录。第二个的修法是显式指定要读的文件，别给目录。上下文不是越多越好，无关文件只会稀释注意力。

6.6 症状：一整天的产出，第二天全推翻了

这个坑最伤士气。原因通常是需求在过程中变了，但规格文件没同步更新，智能体还在按旧规格跑，跑得越顺偏得越远。

我现在强制自己做一件事：任何需求变更，先改requirements.md，再改代码。哪怕只是加一个字段，也先落到文档里。这条规矩看起来笨，但它保证了你随时能回答一个问题——“当前代码对应的是哪一版需求”。没有这个锚点，返工是必然的。

6.7 关于选型的几句实话

如果你现在正在评估要不要引入这套东西，我给三条基于实际使用而非宣传话术的判断：

第一，先看你的需求文档质量，再看工具。一个团队如果连需求都写不清楚，上什么智能体工具都会变成“生成一堆看起来对但没法验收的代码”。规格先行这个方法本身不难，难的是愿不愿意花那半小时。

第二，CLI 的落地阻力比 IDE 小，收益比 IDE 大。IDE 是个人工具，推给团队要靠每个人自觉；CLI 是流程工具，一旦进了流水线，所有人自动受益。想快速看到组织级的效果，从 CLI 切入。

第三，多智能体先别急。等你的规格写得足够细、任务拆得足够干净、验收足够自动化之后，再上 Crew，否则你只是在放大混乱。我自己的顺序是先用 IDE 半年把规则和规格习惯养出来，再上 CLI 三个月把流水线跑顺，最后才碰 Crew。

一年下来我最大的体会是，这三件套真正解决的从来不是“AI 会不会写代码”这个问题，而是“一个团队怎么把想清楚的事情，稳定地变成能验收的产物”。IDE 负责想清楚，CLI 负责稳定地跑，Crew 负责把大活切开同时推进，三者中间用同一套规格和规则串起来。工具会继续变，这套组织方式我觉得短期内不会过时。