Kiro CLI 实战：从安装到真正用起来

终端里的 AI 工具这两年不少，但很多产品的问题也很一致：演示看起来很顺手，真正放进开发工作流之后，要么上下文太浅，要么只能当聊天壳子，要么一接入团队规范就开始失真。Kiro CLI 值得写，不是因为它“又一个 AI Coding 工具”，而是它在 CLI 里把几个真正影响长期可用性的能力拼起来了：会话持久化、Steering、Hooks、MCP，还有可以继续接入编辑器的 ACP。

这篇文章不做发布稿复述，直接从开发者视角讲怎么上手、怎么配置，以及它适合谁、不适合谁。

一、Kiro CLI 到底适合什么场景

先给结论：如果你大部分时间待在终端里，想把 AI 从“偶尔问一句”变成“参与日常开发流程”，Kiro CLI 值得试。尤其适合三类人：

经常在服务器、容器、远程开发环境里工作的人
希望把团队规范固化给 AI，而不是每次重讲一遍的人
已经在折腾 MCP、自动化脚本、工作流编排的人

它不太适合“只想要一个轻量聊天窗口”的用户。因为 Kiro CLI 的优势不在第一次对话，而在你愿不愿意花一点时间把项目规则、工具权限和自动化事件接进去。懒得配置，它也能用；但那样你很难感受到它和普通终端 AI 的真正差异。

二、先安装，再确认基础命令

macOS 可以直接安装：

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

安装完成后，进入你的项目目录，直接启动：

cd my-project
kiro-cli

如果你只是想快速问一句，也可以直接把问题作为参数传进去：

kiro-cli chat "解释一下这个仓库的目录结构"

这里有一个很实用的小点：Kiro CLI 会自动保存会话。也就是说，你不需要把它当一次性命令行工具用，可以在项目目录里持续积累上下文。常用命令包括：

# 恢复最近一次会话
kiro-cli chat --resume

# 列出当前目录下的会话
kiro-cli chat --list-sessions

# 交互式选择会话恢复
kiro-cli chat --resume-picker

这件事看起来不起眼，但它会直接改变使用习惯。很多 CLI AI 工具的问题不是回答不够聪明，而是每次都从零开始。Kiro CLI 至少在会话延续这件事上，思路是对的。

三、真正实用的第一步：给项目加 Steering

如果你只记住 Kiro CLI 的一个能力，我建议记 Steering。它本质上就是把“你希望 AI 长期遵守的项目规则”写成 Markdown，放进 .kiro/steering/ 目录里，让 Kiro 在每次交互里持续参考。

先建目录：

mkdir -p .kiro/steering

然后最少放三类文件：

product.md：这个项目做什么，服务谁
tech.md：技术栈、约束、依赖选择
structure.md：目录结构、命名规则、导入约定

举个很接地气的 tech.md 例子：

# Tech Stack
- Runtime: Node.js 20
- Framework: Next.js App Router
- UI: shadcn/ui
- Styling: Tailwind CSS
- Database: PostgreSQL + Prisma
- Testing: Vitest

# Constraints
- 不引入新的状态管理库，除非现有方案无法满足需求
- API 层优先复用现有 service 目录
- 新增页面默认补基础 loading / error 状态

这样做的价值非常直接：你不用每次都重新提示“我们不用 Redux”“我们统一走 Prisma”“组件按这个目录放”。对个人开发者来说，这相当于给自己做了一层长期记忆；对小团队来说，它比口头约定可靠得多。

四、实战场景：让 Kiro CLI 帮你落一个真实需求

假设你正在维护一个 Next.js SaaS 项目，现在要加一个“账单历史页”，需求不复杂，但涉及列表查询、空状态、分页和基础测试。传统做法是你开 IDE、翻目录、找模式、复制改。Kiro CLI 的更合理用法是先让它理解项目，再让它做结构化推进。

kiro-cli

进会话后，可以直接这样说：

基于当前仓库实现一个 billing history 页面。
要求：
1. 复用现有 Prisma 与 service 层模式
2. 页面放在 app/dashboard/billing/history
3. 必须有空状态和错误状态
4. 补最基础的 Vitest 测试
5. 先给出改动计划，再逐步执行

这个用法的关键不在 prompt 多花哨，而在两点：一是 Steering 已经提前约束了它的行为；二是你要求它先出计划，再执行。这样能明显降低 AI 直接乱改文件的概率。

我的建议是，把 Kiro CLI 当成“能在终端里读项目、提方案、执行部分修改、再持续接着聊”的 agent，而不是一个 shell 版搜索框。它更适合中等复杂度任务，不适合你把整个系统设计都丢给它一把梭。

五、第二个提效点：用 Hooks 把重复动作自动化

Kiro CLI 的 Hooks 可以在 agent 生命周期或工具执行前后触发自定义命令。这个能力对工程流很有意义，因为很多“本来应该自动做”的动作，终于不用每次手动提醒 AI 了。

最常见的用法有这些：

写代码后自动跑格式化或 lint
工具调用前做安全检查
执行完成后记录日志
在关键任务前自动收集上下文

这类能力的价值非常“工程”，不性感，但很实用。AI 一旦进入真实项目，最大的问题不是不会生成代码，而是不稳定。Hooks 的意义，就是把部分稳定性从“模型理解”转成“流程约束”。

六、什么时候该接 MCP，什么时候别折腾

Kiro CLI 支持接 MCP，这意味着它可以把外部工具和数据源纳入自己的能力边界。对于已经有内部文档、数据库查询、部署脚本、第三方服务操作需求的团队，这很有想象空间。

但我不建议个人开发者一上来就沉迷 MCP。原因很简单：MCP 很容易把问题从“AI 好不好用”升级成“整个工具链怎么维护”。如果你连项目规则都还没写清楚，会话都还没形成固定习惯，先别急着加一堆外部 server。对大多数人来说，更好的路径是：

先把会话习惯用起来
再把 Steering 补完整
然后只为高频痛点接 1 到 2 个 MCP server

顺序错了，你得到的通常不是更强的 AI，而是更难维护的 AI。

七、几个值得顺手用上的命令

# 把自然语言翻译成 shell 命令
kiro-cli translate "find all large log files and sort by size"

# 诊断安装和配置问题
kiro-cli doctor

# 查看模型列表
kiro-cli chat --list-models

# 非交互模式下跑一次请求
kiro-cli chat --no-interactive --trust-all-tools "总结当前目录项目结构"

其中 translate 很适合那些你“知道大概想干嘛，但懒得现写 shell”的场景；doctor 则很适合刚装完工具之后先做一轮体检。

八、我的判断：Kiro CLI 值得投入，但别把它当魔法

我对 Kiro CLI 的判断是：值得开发者，尤其是终端重度用户，认真花一两个项目去试。它真正有价值的不是“能聊天”，而是它在 CLI 里开始把长期上下文、项目规则、自动化钩子和外部能力整合成一个更像工作流的东西。

但它也不是没有代价。你需要投入配置时间，需要想清楚规则怎么写，需要控制工具权限，需要接受 AI 仍然会犯错。也就是说，它不是一个“装好就满血提效”的玩具，而是一个值得经营的生产力层。

对个人开发者，我的建议很明确：

现在就可以试，但先从一个真实项目开始
先把 Steering 写好，再追求复杂自动化
不要一开始就沉迷 MCP 全家桶

对小团队也是一样：先把规范沉淀下来，再让 Kiro CLI 进入流程。否则 AI 只会把你们原本模糊的习惯，放大成更模糊的输出。

说到底，Kiro CLI 值得关注的地方，不是它会不会替你写代码，而是它有没有机会变成你项目里的一个稳定协作者。至少从目前的产品方向看，它是往这个正确方向走的。