去年这个时候谁再给我推荐“又一个 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 的核心特征是“多个执行体、共享一个工作区”。它解决的不是“单次任务怎么做”而是“一件能拆成五份的活怎么让五个执行体不互相踩脚”。这个层次的复杂度是跳变的因为一旦并行就产生了协调成本、冲突成本、以及“谁来验收”的问题。把这三者放在一张表里对比会清楚很多维度Kiro IDEKiro CLIKiro Crew触发方式人手动发起逐轮推进脚本/管道/定时触发任务队列分发上下文来源编辑器状态、打开的文件、选中片段显式传入的路径与参数共享工作区 角色定义适合的任务粒度半天以内的中等改动分钟级的确定性任务可拆分的长链路任务人工介入点每一步都可以只在头尾在验收节点失败后的代价低随时回退中需要看日志高可能多路同时跑偏我的日常占比约 60%约 30%约 10%最后一行那个 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.mdCLI 可以直接读取它去执行任务清单里的某一条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 用久了会发现真正决定它好不好用的是几个不起眼的开关。我总结下来最该关注的三个是开关类型典型取值为什么重要写权限只读 / 可写只读模式下它只能提建议这是 CI 环节的安全底线超时上限5 分钟 / 20 分钟防止一个跑偏的任务把流水线卡死超时即失败比挂住好输出格式纯文本 / 结构化结构化输出才能被后续脚本解析纯文本只能人看我吃过一次亏早期在流水线里跑一个可写模式的任务没设超时。某次它读错了一个路径陷入“找不到文件→再找一遍”的循环把整条流水线卡了四十多分钟而报警是流水线整体超时才触发的等我看到的时候当天的发布窗口已经错过了。从那以后我的规矩是流水线里的智能体一律只读 硬超时 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 症状多智能体跑完代码能编译但行为诡异前面提过的那种两个执行体各写了一份功能重复的工具函数。这类问题的排查链路我总结成三步先看改动文件清单看有没有两个执行体碰了同一个文件——如果有重点查这里再看新增的公共函数按函数名排序扫一遍找语义相近的——这一步纯人工但很快最后跑一次端到端重点看跨模块的数据一致性因为重复实现最容易在跨模块处暴露。预防手段比排查重要开跑前把公共目录设成只读让所有执行体只能新增自己目录下的东西。6.5 症状成本突然翻倍有一周我发现消耗量涨了三倍但产出没变。翻日志发现是两个原因叠加一是某个钩子在保存时被反复触发我在批量改文件每次保存都触发一次全量检查二是某个任务的上下文里带了一整个大目录的文件。第一个的修法是给钩子加节流或者把触发范围收窄到具体目录。第二个的修法是显式指定要读的文件别给目录。上下文不是越多越好无关文件只会稀释注意力。6.6 症状一整天的产出第二天全推翻了这个坑最伤士气。原因通常是需求在过程中变了但规格文件没同步更新智能体还在按旧规格跑跑得越顺偏得越远。我现在强制自己做一件事任何需求变更先改requirements.md再改代码。哪怕只是加一个字段也先落到文档里。这条规矩看起来笨但它保证了你随时能回答一个问题——“当前代码对应的是哪一版需求”。没有这个锚点返工是必然的。6.7 关于选型的几句实话如果你现在正在评估要不要引入这套东西我给三条基于实际使用而非宣传话术的判断第一先看你的需求文档质量再看工具。一个团队如果连需求都写不清楚上什么智能体工具都会变成“生成一堆看起来对但没法验收的代码”。规格先行这个方法本身不难难的是愿不愿意花那半小时。第二CLI 的落地阻力比 IDE 小收益比 IDE 大。IDE 是个人工具推给团队要靠每个人自觉CLI 是流程工具一旦进了流水线所有人自动受益。想快速看到组织级的效果从 CLI 切入。第三多智能体先别急。等你的规格写得足够细、任务拆得足够干净、验收足够自动化之后再上 Crew否则你只是在放大混乱。我自己的顺序是先用 IDE 半年把规则和规格习惯养出来再上 CLI 三个月把流水线跑顺最后才碰 Crew。一年下来我最大的体会是这三件套真正解决的从来不是“AI 会不会写代码”这个问题而是“一个团队怎么把想清楚的事情稳定地变成能验收的产物”。IDE 负责想清楚CLI 负责稳定地跑Crew 负责把大活切开同时推进三者中间用同一套规格和规则串起来。工具会继续变这套组织方式我觉得短期内不会过时。