直接上干货。上一篇文章写了 Kiro 的安装、基础配置和日常对话技巧，这篇我们往前再走一步。如果你已经用 Kiro 做了一些事，但总觉得它还能更顺手——比如希望它按你的项目习惯自动执行命令、把重复发生的任务封装成一句指令、或者干脆把 Kiro 的模型能力借给别人用，那这篇就是你要的东西。内容主要围绕几个高频需求展开：Skill 封装、CLI 脚本化、命令确认机制调优、模型接口复用，以及和 Cursor 的选型对比，覆盖的都是社区里问得最多的问题。
我默认你已经装好了 Kiro，并且对 Git、终端、JSON/YAML 配置文件这些基础操作不陌生。下面每个章节都是独立主题，你可以按需跳读，但建议至少把第三章权限配置看完——这一章能直接决定你在日常使用里是“爽快干活”还是“被确认弹窗烦死”。
1. Skill 封装实战：把重复劳动变成一句话
Skill 是 Kiro 很核心的一个扩展机制。说人话就是：把一段固定的工作流程、提示词、脚本工具打包成一个“技能包”，之后你和 Kiro 对话时提到 Skill 的触发词，它就会自动加载对应配置，而不是每次都要你重新把需求描述一遍。这个机制特别适合项目里有固定流程的团队，也适合自己维护多仓库、多语言栈的开发者。
1.1 Skill 到底解决了什么问题
先讲一个我自己的例子。我手上维护着好几个 Node.js 服务，每次改动完代码都要走一遍 lint、test、build、写变更记录、推分支。以前我是手动敲一串命令，或者是把这段流程粘贴给 Kiro 让它执行。但每次粘贴都要重新说明上下文，Kiro 偶尔还会理解偏，把 lint 和 test 的先后顺序搞错。
后来我封装了一个名为node-ci的 Skill，里面写好固定的执行顺序、失败时的处理策略、日志格式、以及“改动描述应该怎么写”的模板。之后我只需要说一句“对刚才的改动执行 node-ci”，Kiro 就会自动加载这个 Skill，按预定步骤跑完整个流程。效果非常直接：省掉了每次重复描述的成本，而且流程不会被 Kiro 临场发挥改乱。
Skill 适合封装的场景包括：代码审查、发布前检查、项目脚手架初始化、日志分析、固定格式的文档生成、按团队规范执行的 commit 流程。判断标准很简单——只要这件事你一周会做两三次，并且每次的描述过程都很类似，就值得封装成 Skill。
1.2 手把手做一个“代码审查” Skill
Kiro 的 Skill 目录结构一般是这样：
~/.kiro/skills/ code-review/ SKILL.md scripts/ review.sh先在~/.kiro/skills/下创建一个code-review目录，新建SKILL.md文件。这个文件是 Skill 的描述与核心配置，Kiro 通过它来决定什么情况下调用该 Skill。
下面是我实际在用的SKILL.md示例，你可以直接参考：
--- name: code-review description: 对当前 git 仓库的未提交改动进行代码审查，输出审查报告 version: 1.0.0 --- 当用户要求"审查代码"、"review"或"检查本次改动"时，使用本技能。 执行步骤： 1. 运行 git diff HEAD 获取所有未提交改动 2. 运行 git diff --cached 获取暂存区改动 3. 按文件逐个审查，重点检查： - 是否存在明显逻辑错误 - 是否遗漏错误处理 - 是否有安全问题（如 SQL 注入、XSS） - 是否符合项目既有代码风格 4. 输出审查报告，格式：问题文件 / 问题位置 / 问题描述 / 修改建议SKILL.md 里的description字段非常重要。Kiro 的调用机制是先用描述信息做语义匹配，描述写得越具体，触发准确率越高。我见过很多人写个“用于代码审查”就完事了，结果 Kiro 经常在你说“帮我看看这个逻辑”时想到这个 Skill，在你说“帮我 review 一下代码”时反而没触发。建议把用户可能说的触发词直接写进 description。
1.3 调用 Skill 的两种方式与调试心得
Skill 封装好之后，调用有两种方式。一种是显式触发，直接在对话里说 Skill 的名字，比如“用 code-review 审查刚才的改动”，Kiro 会优先加载对应 Skill。另一种是语义触发，你正常描述需求，Kiro 根据 description 自动匹配合适的 Skill。
我实测下来，语义触发的准确率大概在八成左右，如果命中率高，说明 description 写得好；如果经常命中不了，优先改 description，而不是强制自己在每次对话里都说 Skill 名。
调试 Skill 时有一个很有用的命令：让 Kiro 输出它当前加载了哪些 Skill。不同版本命令可能不同，但一般会有类似/skills list或kiro skills list的选项。看到自己写的 Skill 出现在列表里，就说明 Kiro 已经识别到了。如果没出现，检查目录层级是否正确——SKILL.md必须放在技能名目录的正下方，不能多套一层文件夹，也不能放错位置。
另外注意一个细节：Skill 里如果引用了外部脚本，脚本路径建议写绝对路径，或者放在 Skill 目录下并用相对 SKILL.md 的位置来引用。Kiro 执行 Skill 时的工作目录不一定是你项目目录，如果脚本依赖相对路径，很容易出现“文件找不到”的错误。我最早封装 Skill 时就被这个问题坑过，脚本里用./scripts/review.sh，结果工作目录不对，怎么调都报错。
2. 命令行进阶：从交互模式到脚本化调用
很多人用 Kiro 都是打开终端、敲kiro、进入交互界面，慢慢聊。这个用法没问题，但如果只在交互模式下用，发挥不了 Kiro 的全部价值。Kiro 本质上有完整的命令行接口，支持非交互式调用，你可以把它接入 shell 脚本、CI 流程、甚至 cron 定时任务里。
2.1 非交互模式的核心参数
Kiro CLI 最常用的几个参数我列一下。
kiro -p "你的提示词"或kiro --print "你的提示词"：直接在终端输出结果，不进入交互模式--output-format json：让结果以 JSON 格式输出，方便后续脚本解析--model：指定要用的模型，适合在脚本里固定使用某款模型--config：指定配置文件路径，适合在不同项目目录下切换不同配置-y或--yes：跳过所有确认提示，直接执行
其中-y参数要谨慎使用。在脚本里加上这个参数意味着 Kiro 不会停下来问你，所有命令都会直接执行。如果是可预期的安全命令，加-y能提升效率；但如果命令可能产生破坏性效果，加上-y就相当于拆了保险栓。后面第三章我会专门讲权限配置，这里先记住一个原则：脚本里默认不加-y，只有确定安全时才加。
2.2 用管道和 shell 脚本做自动化
命令行工具最大的优势是可以和其他命令组合。比如我现在经常这样用：
git diff --name-only | kiro -p "请根据这些改动的文件名，判断本次改动涉及的功能模块，并生成一份 commit message 建议" --output-format json这条命令会把所有改动的文件名传给 Kiro，让它分析改动范围、生成 commit 建议。输出是 JSON 格式，我可以直接在 shell 脚本里用jq解析，然后通过 git 提交。整个过程下来，从分析改动到生成 commit message 完全自动化，不需要打开 Kiro 交互界面。
再分享一个批量操作的案例。我有一次要给五个仓库统一补上.gitignore，如果手动打开每个仓库跟 Kiro 对话，至少十分钟。用脚本就快得多：
for repo in repo-a repo-b repo-c repo-d repo-e; do cd ~/projects/$repo kiro -p "为当前仓库生成一个合适的 .gitignore 文件，基于项目主要语言和常见依赖目录" -y done这段脚本让 Kiro 自动在每个仓库生成 .gitignore，全程无人值守。这里加-y是安全的，因为生成 .gitignore 本质上就是写一个文件，风险很低。
2.3 脚本化调用时的四个注意点
脚本化调用看着简单，实际跑起来有几个细节容易被忽略。
第一个是工作目录。Kiro 的上下文感知和处理逻辑都以当前工作目录为准。在脚本里执行kiro前，一定要先cd到目标目录，否则 Kiro 拿到的“当前项目”是错的。
第二个是 shell 转义问题。提示词里如果包含引号、美元符、反引号这些特殊字符，在 shell 脚本里要小心处理。最简单的方案是把提示词写到变量里，或者用单引号包裹整个提示词，避免被 shell 解析掉。我建议写复杂提示词时先存成变量，再传给 Kiro。
第三个是超时与重试。调用模型接口有延迟，如果脚本是放在 CI 里跑，要给命令设置合理的超时时间。Kiro 自身一般会有超时设置，但外层脚本里也可以包裹一层timeout 120 kiro -p "..."，避免极端情况下任务卡住整个流水线。
第四个是结果校验。Kiro 生成的内容不一定每次都符合预期。脚本化调用时，建议在后续步骤里加一个校验逻辑，比如检查生成的文件是否存在、内容是否为有效 JSON、commit 是否成功，而不要想当然认为“Kiro 执行成功了，一切都好”。我的习惯是每个自动化任务后面都跟一个简单的条件判断，失败就提前退出并留下日志。
3. 告别烦人的“需要确认”：命令权限的精细配置
“Kiro 老是需要确认”是社区里被吐槽最多的点，也是新用户最容易卡住的地方。默认情况下，Kiro 执行任何可能影响系统状态的操作都会询问你，比如写入文件、执行 shell 命令、调用外部工具。这个设计本身是好事——AI 自主执行命令是有风险的，每一步都确认至少让你保持对机器的控制权。但如果每删一个临时文件都要弹一次确认，工作效率确实被拖垮。这里的关键是：不要完全关掉确认，也不要完全保留默认，而是按命令类型配置精细的权限策略。
3.1 为什么默认所有命令都要确认
Kiro 运行在你本地，权限和你当前用户一致。这意味着它能读你的文件、写你的文件、执行你怎么写的命令。当你让它“清理项目里的临时文件”时，它实际上拥有删除文件的能力。默认全确认模式是为了避免 Kiro 误判你的意图，或者执行了你自己都没想到的命令。
这个设计和安全工具里的“最小权限”原则一致。问题是，AI 工具的确认频率如果太高，用户就会习惯性地点“允许”，反而失去确认的意义。所以我一直建议：不追求零确认，而是把确认留给真正高危的操作。
3.2 设置所有命令允许执行的正确姿势
如果你确实想大幅减少确认，Kiro 提供了配置项，可以设置一个全局的“允许执行”策略。不同版本的配置项名可能略有不同，但思路类似——在配置文件的权限块里，把命令执行模式调成allow-all或auto。
下面是一个配置示例，假设 Kiro 的配置文件是~/.kiro/config.json：
{ "permissions": { "default_mode": "allow-all", "dangerous_commands": [ "rm -rf", "git push --force", "sudo" ] } }设置成allow-all后，Kiro 执行命令前不会再弹确认窗。但请务必同时配置dangerous_commands黑名单，把真正危险的命令拦下来。我见过有人直接设置全部放行，结果某次 Kiro 在理解错需求的情况下执行了rm -rf，把整个项目目录清空了。这里要明确：“允许全部”不等于“没有限制”，你应该只允许日常安全的操作自动执行，高危命令强制保留确认。
3.3 更推荐的方案：按前缀与场景精细放行
我个人的首选方案不是allow-all，而是在权限配置里给常见安全命令设置自动放行。现在很多版本的 Kiro 支持基于命令前缀的匹配，比如：
{ "permissions": { "allowed_prefixes": [ "git status", "git diff", "git log", "git add", "npm test", "npm run lint", "yarn lint", "pnpm build", "ls", "cat", "curl -I" ], "blocked_prefixes": [ "rm -rf", "sudo", "chmod 777", "mkfs" ] } }这样配置的好处是：日常开发和代码管理相关的命令，Kiro 可以自动执行，不用反复确认；而真正有破坏力的命令，比如rm -rf、sudo、递归权限修改，仍然会触发确认流程或者直接被拒绝。
细心的读者会发现，allowed_prefixes里我写了git add但没写git push——git push会影响远程仓库，风险比 add 高不少，我会保留它的确认。git push --force这种高危操作，则放在blocked_prefixes里。
3.4 分场景权限控制
除了按命令前缀配置，Kiro 一般还支持按目录或项目场景区分权限。比如你可以在某个敏感项目的配置文件里单独设置：
{ "permissions": { "override": "parent", "blocked_prefixes": ["git push"] } }表示这个项目下git push必须手动确认，其他项目则继承全局配置。这样做的好处是，不同项目风险等级不同，权限策略也可以不同，而不用全局一刀切。
我在实际使用中会把自己的个人项目和公司项目分开配置。个人项目基本都是我熟悉的操作，allow-all加黑名单就够了；公司项目因为涉及多人协作、远程分支、生产环境，我会把git push、npm publish这类命令全部加入强制确认列表。
3.5 调优权限后的两个心得
配置完权限后，我建议先观察一两天再逐步放开。不要一开始就全量放行，而是先用allowed_prefixes模式跑几天，看看哪些命令还需要确认，把它们逐个加到列表里。等确认弹窗明显少了，再评估是否提升到allow-all。
另外建议在.gitignore里加入 Kiro 配置文件，如果你把 Kiro 配置放在项目目录下，别把它提交到 git 仓库。配置里可能包含你的个人偏好、目录路径，甚至某些场景的敏感信息，不应该被公开。我第一次就把配置文件提交到仓库里了，后来发现团队其他人 pull 下来后配置被覆盖，还困惑了好一阵子。
4. 模型接口复用：把 Kiro 的能力接到其他工具里
“Kiro 能不能作为模型接口给别的工具用”这个问题被问过很多次。实际场景是这样的：Kiro 本身不是模型，但它内置了对模型服务的对接与路由能力，可以把它理解成一个“模型网关”。你在 Kiro 里配好了 API 密钥、模型路由、代理规则，这些能力通过它暴露的接口，也可以提供给其他 AI 工具使用，比如 Claude Code。
这一节我会重点讲两个方向：一是怎么在 Claude Code 中配置使用 Kiro 的模型接口，二是配合反向代理和 token 体系，把接口供给 New API 这类网关工具统一管理。
4.1 在 Claude Code 中配置使用 Kiro 的模型接口
Kiro 通常会暴露一个本地或远程的 API 服务，具体端口和路径看你的配置。假设你的 Kiro 服务监听在http://127.0.0.1:8081，那么 Claude Code 可以通过环境变量指定使用这个接口。
Claude Code 的标准做法是设置ANTHROPIC_BASE_URL环境变量，让所有 Anthropic 模型的请求都指向这个地址：
export ANTHROPIC_BASE_URL=http://127.0.0.1:8081 export ANTHROPIC_AUTH_TOKEN=your-kiro-token claude这样启动 Claude Code 后，它会通过 Kiro 暴露的接口来调用模型服务。注意，这里实际上是在用 Kiro 的路由和密钥管理能力来替代 Claude Code 自身的 API 配置，好处是你不需要在 Claude Code 里直接配置原始模型的 API Key，统一在 Kiro 侧做管理。
配置时最关键的是 token 要一致。Kiro 侧如果开启了鉴权，那么外部工具调用时必须带上正确的 token。不同版本 Kiro 的鉴权方式可能不同，有些版本直接在启动参数里指定 token，有些版本从配置文件读取。我建议在配置阶段先用本地无鉴权模式验证连通性，确认没问题后再开启 token 鉴权。
4.2 用反向代理把 Kiro 接口接到 New API 网关
如果你想同时管理多个模型来源、多把密钥，或者给团队里其他人分配不同额度的调用权限，更结构化的做法是引入 New API 这类 API 网关。Kiro 的接口接进来之后，由 New API 统一管理 token、配额、日志和统计。
整体链路是这样的：
Kiro 模型服务 -> 反向代理 -> New API -> 下游工具你在 Kiro 侧暴露模型接口，反向代理（比如 Nginx）负责转发请求到 New API 的对应路由，New API 负责注册模型供应商、生成和管理 token。下游工具只需要接入 New API 的地址和 token，不用关心背后的模型来源到底是谁。
这里用一个 Nginx 反代配置示例说明：
server { listen 8082; location /v1/ { proxy_pass http://127.0.0.1:3000/v1/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这条配置把 8082 端口的/v1/路径转发到本机 3000 端口的 New API 服务。后续你在 New API 里添加供应商时，填入http://127.0.0.1:8082/v1作为模型接口地址即可。之后 New API 会负责生成调用 token、记录日志、统计额度，下游工具直接用 New API 的地址。
这个架构的优势是：模型来源对下游透明，你可以随时在 New API 侧调整供应商和密钥，不用改下游工具的配置。对于个人开发者，一套配置打通多个工具；对于小团队，通过 New API 分配 token 就能实现对不同成员额度控制。
4.3 模型名映射与超时调整两个深坑
接口接入过程中有两个问题几乎是必踩的，提前说清楚能省很多查错时间。
第一个是模型名映射。Kiro 侧暴露的模型名不一定和 Claude Code 或 New API 里预设的模型名一致。比如 Kiro 配置里可能把某个模型取名为my-model-v1，但 New API 里注册的模型名是claude-sonnet。下游在调用时指定模型名，如果两边对不上，请求会返回 404 或 400 错误。
解决办法是在 New API 里做模型名映射，或者在 Kiro 侧把模型名调成下游期望的名称。我的建议是统一用下游工具期望的名称来命名，这样调用的心智负担最低。跨工具调用的场景越多，模型命名越要提前规划，否则每个工具里都要记一份别名映射表。
第二个是超时与流式响应。模型接口通常是流式响应，反向代理和网关默认的读超时如果太短，长回答会被截断。Nginx 默认的proxy_read_timeout是 60 秒，AI 接口在生成超长内容时很容易超。我的配置是：
proxy_read_timeout 600s; proxy_buffering off;把读超时拉到十分钟，同时关闭缓冲区，让流式响应直接透传，避免前端等了半天结果被网关缓冲成一次性响应。实际调优时可以从 300 秒开始测试，如果长时间生成偶发超时，再逐步加长。
4.4 token 管理的安全建议
接入了 New API 后，token 管理就成了安全重点。New API 生成的 token 相当于下游访问你模型的钥匙，一旦泄露，别人可以任意消耗你的模型额度。我记得有一次我把自己测试用的 token 直接写在了一个公开示例的 README 里，第二天发现额度被刷了一大截，后来每次提 token 都是走环境变量或密钥管理工具。
几个最基本的建议：token 不要硬编码在代码或配置文件里，用环境变量或专用密钥存储；控制 token 的额度上限，防止超量消耗；定期轮换 token，特别是意识到可能泄露时立刻作废重发；尽量区分不同用途的 token，比如开发环境一个、生产环境一个，一旦某个泄露，影响范围可控。
5. Kiro 与 Cursor：怎么选，怎么互补
在各大平台被问到最多的问题之一就是“Kiro 和 Cursor 到底哪个好用”。这种问题没有标准答案，因为两个工具的定位本身就不一样。从我日常的使用感受来看，它们不是替代关系，而是互补关系。选哪个、怎么组合，取决于你当前在做什么类型的任务。
5.1 定位差异与适用场景对比
我把两个工具的定位差异总结成一张表，方便你直接对照：
| 维度 | Kiro | Cursor |
|---|---|---|
| 产品形态 | 终端 CLI Agent | 图形化 IDE |
| 核心交互 | 对话 + 命令执行 | 编辑器内联动 + 对话 |
| 擅长任务 | 批处理、自动化、命令行操作 | 多文件编辑、代码补全、交互式调试 |
| 使用门槛 | 需要熟悉终端 | 视觉化，上手更快 |
| 自动化集成 | 容易接入脚本和 CI | 弱一些，更多依赖手动操作 |
如果你的任务以“执行命令”“批量处理多个仓库”“接脚本管线”为主，Kiro 天然适合。它能直接跑命令、解析文件、输出结构化结果，而且脚本化调用方便，能塞进定时任务和 CI 流程。如果你的任务以“在编辑器里写代码、改代码、看报错、调试”为主，Cursor 的体验更好。它的代码补全、多文件上下文关联、语法高亮和重构能力，是终端工具替代不了的。
5.2 实际使用中的场景体验
举一个我自己的典型工作流。新需求下来后，我一般先打开 Cursor，在里面阅读相关代码、理解模块调用关系、写新功能的代码骨架。Cursor 的代码补全和侧边栏对话在理解代码结构、生成符合现有风格的代码上，发挥稳定。
等代码写完之后，我切到终端，用 Kiro 做后续的收尾工作：跑 lint、跑测试、生成 commit message、提交分支、甚至更新变更日志。这些事情如果放在 Cursor 里做，得手动点开终端面板、手动敲命令；但在 Kiro 里，一条提示词就能把整个流程串起来自动跑完。
还有一个典型的场景是跨仓库操作。我经常遇到一个改动涉及多个仓库的情况，Cursor 一次只能打开一个项目窗口，切来切去很麻烦。Kiro 则没有这个限制，在终端里我可以对多个仓库目录循环执行 Kiro 指令，一次性完成统一修改。
5.3 我的组合方案与迁移建议
我现在的固定组合是：Cursor 负责写代码和复杂重构，Kiro 负责命令执行、批量处理和自动化脚本。如果你是从纯 Cursor 用户转过来，可以从一个小任务开始体验 Kiro，比如只用它跑测试和生成 commit message，不要一开始就想着完全替换。
如果你是从 Kiro 转投 Cursor，建议把 Kiro 的 Skill 和脚本保留下来，它们仍然可以作为 CLI 工具嵌入你的新工作流。事实上，很多 Kiro 的核心能力通过命令行方式调用，和 Cursor 并不冲突。
关于迁移成本，我的观察是：一个纯新手如果先在终端里折腾 Kiro，学习曲线会比直接用 Cursor 陡很多，因为 Kiro 的使用前提是熟悉 shell、熟悉命令行操作方式。但如果已经有了终端使用经验，Kiro 的上手成本会低很多，而且在自动化场景的价值是 Cursor 无法替代的。
6. 使用高频问题速查与独家避坑
最后这一章是自己这段时间使用 Kiro 遇到的各种问题汇总。有些问题我自己排查了很久，有些是从社区看到别人踩坑后验证过的，整理成速查表的形式，方便你收藏后随查随用。
6.1 高频问题排查速查表
| 问题表现 | 可能原因 | 解决方案 |
|---|---|---|
| Kiro 响应越来越慢 | 对话上下文过长，历史记录积累太多 | 开启新会话或执行会话清理命令 |
| Skill 没被触发 | description 中没有覆盖用户可能的表达方式 | 在 description 中添加常见触发词 |
| 模型接口报 404 | 模型名在 Kiro 侧和下游工具侧不一致 | 统一模型名做映射 |
| 模型接口报 401 | token 无效或过期 | 重新生成 token 并检查环境变量 |
| 配置文件修改后不生效 | Kiro 仍在读取旧的配置文件缓存 | 重启 Kiro 服务或执行配置重载命令 |
| 中文文件名乱码 | 终端编码不是 UTF-8 | 在 shell 配置中设置 LANG=en_US.UTF-8 或 zh_CN.UTF-8 |
| 命令执行提示权限不足 | 命令被权限策略拦截 | 在 allowed_prefixes 中加入对应命令前缀 |
| 反向代理下流式响应卡顿 | 代理缓冲导致流式响应被截断 | 关闭 proxy_buffering 并加长 read timeout |
我实际遇到最坑的是模型名 404 问题。当时我在 Kiro 配了一个claude-sonnet别名，结果 New API 那边注册的模型名是claude-sonnet-20241022，整整排查了快一个小时，最后才发现是名字对不上。从那之后我给自己定了一条规矩：所有跨工具调用的模型名，一律以底层模型官方名称为准，不在 Kiro 侧自定义别名。
6.2 几个值得养成的操作习惯
先说说配置文件的备份。Kiro 的配置、Skill 定义、权限策略都是写在文件里的。如果你像我一样折腾了很多细节，建议把.kiro目录纳入备份体系，或者用 dotfiles 仓库管理起来。一旦系统重装或换新机器，几分钟就能恢复完整环境，不用从头配置。
再说说 Skill 的版本管理。Skill 是文本文件，天然适合用 Git 管理。我给自己的 Skills 目录单独建了一个 Git 仓库，每次修改 Skill 都提交一次，方便回溯。有一回我改了code-reviewSkill 的提示词，结果生成的审查报告质量明显下降，直接git checkout回退到之前的版本，问题就解决了。如果没有版本管理，这种问题就只能凭记忆还原，非常痛苦。
还有一个习惯是定期检查 Kiro 的日志。如果你觉得 Kiro 某个行为不可解释——比如明明没让它执行某条命令，结果它自作主张做了——大概率能从日志里找到线索。Kiro 会在日志里记录每次模型请求、命令执行过程、权限判断结果。排查问题前先看日志，能省掉大量的猜测时间。
6.3 权限放开后的一次事故复盘
最后分享一个真实的教训。前面提到权限配置可以设成allow-all，我有一次为了赶项目进度，图省事把权限全部放开了，连dangerous_commands都没配置。当时让 Kiro 帮我整理项目里的旧目录，它理解成“把旧目录里的文件清理掉”，直接执行了删除命令，而且因为权限全开，没有任何确认提醒。
整个过程发生得很快：我看到终端里刷过一行rm -rf static/old-assets，等反应过来的时候，旧资源目录已经被清空了。好在项目有 Git 提交记录，文件没有彻底丢失，但恢复也花了不少时间。
从那之后我铁了心使用分层权限配置：日常命令放行、高危命令强制确认、危险前缀直接拒绝。这个优先级顺序建议每个人都记一下：功能可用性优先级最低，数据安全优先级最高。Kiro 执行任何命令前，先想想“这条命令如果执行错了，损失能不能承受”，再来决定是否放行。
我自己用 Kiro 从基础到进阶，最明显的感受是：这个工具的天花板取决于你愿意花多少时间去调教它。Skill 封装、权限策略、CLI 脚本化、接口复用，本质都是在把 Kiro 变成你顺手的样子。初次配置会花掉一些时间，但每多配置一个细节，后面省掉的时间都是成倍的。抽一个下午，把这篇里的内容逐条试一遍，后面你的使用体验会完全不同。
