一个月重度使用 Kiro 之后，来聊聊它和 Cursor 的对比。
先说结论：Kiro 未来挺有潜力（尤其是它的 Hooks 功能，真的很棒），但现在有不少硬伤：上下文控制做得不好，范围管理不严谨，透明度不足。它经常“读太多”，干预超出任务的东西，还不给我看 token 或上下文消耗情况。我用下来最好的方式，反而是自己贴最小化的代码片段，再配合我写的 rules.md 守则文件——比它自动生成的“引导文件”靠谱多了。值得一提的是，这个月我完全靠 Kiro 从零写完了一个项目，没有借助别的 AI 工具，对此我还挺自豪的。
Hooks：真正的亮点
Kiro 的定制功能看似小，但影响很大。Hooks + 自己控制规则什么时候启用，比 Cursor 的规则机制要好用太多。
我最喜欢的就是 Hooks。一开始我对 Spec Mode（规格模式）最期待，但很快热情就降下来了。反倒是 Hooks 解决了我在 Cursor 里一直的“痒点”：轻量、可复用的记忆功能。我之前在 Cursor 里是用 markdown 任务手动实现类似效果的，而 Hooks 直接把这事搞定了，而且更好用。
为什么省时间？因为 IDE 里的很多 AI 操作都特别重复。有了 Hooks，我就能专注在某个具体任务上（比如写函数实现），不用管风格统一这些琐事。等函数都写好，我开个新对话，挂上风格 Hook，Kiro 就会自动帮我把代码风格更新好。对大规模 API 接口缓存、性能优化批量 rollout 也同样有效。Hooks 还能一点点打磨，直到“完美”。
自动引导文件：鸡肋
Kiro 自己生成的 steering 文件完全没用。看起来像是借鉴了 Cline 的 Memory Bank，但点个按钮让 Kiro 写引导文件，我觉得就是纯浪费 token。Cline 的设计更合理——先让用户自己描述文件，再去写。
其实，拿它当成 Cursor 的规则来用更合适：我自己写文件和规则，再结合 Hooks 的“条件加载”，效果更佳。Cursor 没有这个功能。
当然，缺点是 Kiro 有时候会忽略这些规则（和 Cursor 一样）。我怀疑是它系统提示里塞了太多上下文，互相冲突了。
最大的槽点：太过热心 + Autopilot 有风险
我给它的基本约束是：只在任务范围内，先给方案，再解释理由，最后才改动。模糊任务是我写得不清楚，这没话说。
但有一次，我只让它干一件事：“把 #xy 文件里所有 console.log 都删掉”。它确实删了，可它还顺手“修复”了 TypeScript、Tailwind 和 Svelte 的语法（其实没问题），结果就是画蛇添足。更奇怪的是，单独用 Claude 4 反而不会犯这种“旧语法强迫症”。
上下文 & Token 问题
最烦的一点：Kiro 完全不显示 token 使用情况。我完全不知道上下文快满了没有，导致一上来就经常撞上聊天上下文限制，尤其是 Spec Mode。
更糟糕的是，它老让我“总结对话”，可当时上下文已经超限，根本总结不了。有时候对话很短，它还是不行，因为它在后台偷读了太多无关文件，直接卡死。一些任务因此没法完成。我唯一的解决办法就是去删掉 requirements.md 和 design.md 的内容，挺蠢的。
Cursor 胜出的地方
Cursor 的自动补全真是顶级：快、准、能预测出常见样板代码。
Kiro 的补全慢，而且建议经常离谱。我直接放弃不用它了，结果本来能省的时间都得靠手动操作补回来（比如打十遍 class="bg-black"，或者手动加函数类型签名）。
Spec Mode：控制力差
Cursor 可以选中一段代码，只把那部分交给模型。Kiro 不行，我得复制粘贴进去，而且它有时还会自己偷看整个文件甚至更多。上下文污染严重。
所以我在 Kiro 里用 Ctrl + I 内联编辑的频率反而更高。
缓存问题
Kiro 缓存特别重，有时候甚至改了文件都没法保存。代理在运行时尤其明显，动不动就覆盖掉我的修改，或者我只能等它跑完才能继续写。
Claude Code（CC）和 Kiro 的缓存冲突比 CC 和 Cursor 多得多。Cursor 也有，但要少很多。我觉得是 Kiro 的缓存机制问题。
另一个 bug：在大 JSON 文件里用搜索，有时找不到精确匹配。我测了几次都是这样。如果项目数据量大，这问题很烦。
文档不足
文档确实薄弱，可以理解是新工具，但至少得有个搜索框。我翻过一遍文档，总觉得漏了很多功能或设置。要是有搜索，确认起来方便得多。
我的经验总结
* 手动片段模式：复制/粘贴需要的行，避免让它打开整个文件。
* 自写规则文件：像 Cursor 那样用。
* 严格守则：只做请求的修改，先提计划、再解释、再改动。
* 发现额外问题？只列出来，不要乱改。
* 文件白名单：只允许它动指定文件或行，其它都禁掉。
* 拆小任务：大任务分解成小步骤。
* 跳过自动引导文件：别用那套，容易让 Kiro“越界”。
* 需要 Context meter：实时显示上下文 token 剩余多少，最好还能看到具体调用消耗。
* Token 用量透明化：告诉我消耗多少，方便我控制成本。
* 更细粒度的上下文范围控制：能指定文件行区间，不要乱读整个文件。
* 工作区扫描设置：关掉/按需开/只扫改过的文件，并支持 include/exclude 配置。
* 更好的引导机制：减少内置冲突提示，多把控制权交给用户，让 Kiro 按我的方式工作。
总结：
Kiro 有亮点，Hooks 是大杀器，但上下文、缓存、透明度和补全都拖了后腿。Cursor 在稳定性和补全上还是更胜一筹。
- Kiro 优势：Hooks + 条件规则加载 → 灵活度高，能做 Cursor 做不到的记忆/复用。
- Cursor 优势：上下文控制、补全、缓存、稳定性、文档 → 整体更成熟、好用。
- 整体评价：
- Cursor = 稳定生产力工具，开箱即用。
- Kiro = 有潜力的新秀，但目前更适合“折腾党”，需要各种 guardrails（防护措施）才能发挥价值。
| 功能点 | Kiro | Cursor
| Hooks / 规则 | 有 Hooks，灵活强大 | 没有 Hooks，规则死板
| 上下文控制 | 经常读太多，容易超限 | 可精确传片段，更可控
| 自动补全 | 慢，建议怪 | 快、准，顶级
| 缓存/稳定性 | 缓存冲突多，不稳 | 稳定可靠
| 整体体验 | 有潜力但乱 | 成熟好用