Appearance
Kiro CLI 的 thinking 工具会在复杂问题中展示推理步骤，帮助你看到 agent 如何拆解任务、比较方案并形成建议。本文用中文开发者熟悉的缓存、架构和排错场景，说明何时开启、何时关闭，以及如何把 thinking 放进日常工作流。
Kiro CLI thinking：看见复杂决策的推理过程
在日常开发里，AI 给出“建议使用 Redis”“建议先做单体应用”并不难，难的是你要判断这个建议是不是适合当前项目。Kiro CLI 的 thinking 工具解决的正是这个问题：它不是只给结论，而是在复杂任务中把推理过程展开，让你能看到 agent 怎样识别约束、比较方案、排除错误路径并形成最终建议。
这对中文开发者尤其有价值。很多团队已经开始用 CLI agent 处理代码审查、排障和架构讨论，但如果只看最终回答，很容易把 AI 当黑盒。thinking 能让你保留“决策在人”的控制感：AI 负责拆解和分析，人负责判断假设是否成立。
开启和关闭 thinking
通过 settings 命令开启：
bash
kiro-cli settings chat.enableThinking true如果你更习惯在会话里操作，也可以使用实验功能入口：
text
/experiment
# 在列表中选择 Thinking需要关闭时执行：
bash
kiro-cli settings chat.enableThinking false查看当前状态：
bash
kiro-cli settings chat.enableThinking建议把 thinking 当成“复杂任务模式”，而不是永久开启。简单问答、固定命令生成、已经明确的实现任务，通常不需要额外推理展示。
thinking 会在什么时候出现
Kiro 不会对所有问题都展示 thinking。它通常会在下列场景中自动触发：
- 需要多步逻辑推导的复杂问题；
- 需要比较不同技术方案的取舍；
- 需要规划带依赖关系的多阶段实现；
- 需要系统排查的疑难 bug；
- 需要考虑团队规模、部署成本、维护风险的架构决策。
换句话说，如果问题本身存在明显的不确定性，thinking 就能帮你看到 Kiro 是怎么处理这些不确定性的。
示例：为 API 缓存选型
不开启 thinking 时，你可能只会看到结论：
text
> What's the best way to implement caching for our API?
I recommend using Redis for caching your API responses...开启 thinking 后，Kiro 会先展开分析路径：
text
> What's the best way to implement caching for our API?
Thinking...
Let me think through the caching requirements:
1. First, I need to consider the type of data being cached
- API responses suggest read-heavy workload
- Need to handle cache invalidation
2. Evaluating caching solutions:
- In-memory: fast but limited by RAM
- Redis: distributed, persistent, feature-rich
- Memcached: simple and fast, but fewer features
3. Considering your use case:
- API responses benefit from distributed cache
- Need TTL support for automatic expiration
- May need cache invalidation on updates
Based on this analysis, I recommend using Redis...这类输出的重点不是“Redis 一定正确”，而是你可以检查它有没有漏掉关键前提。例如你的服务只有单实例、缓存数据非常小、部署 Redis 成本过高，那么你就可以要求 Kiro 重新基于这些约束分析。
常见使用场景
1. 架构决策
例如你在问：新项目应该用 microservices 还是 monolith？thinking 可以帮助 Kiro 显式比较团队规模、部署复杂度、扩展需求和后续演进成本。
对于小团队或需求仍在变化的项目，Kiro 可能会倾向先用 monolith，因为它更容易调试、部署简单、迭代成本低；而对于多个团队并行开发、模块边界清晰、独立扩缩容诉求强的系统，microservices 才更有意义。
2. 算法和实现方案选择
当你问排序算法、缓存策略、任务队列、数据库索引设计时，thinking 能让 Kiro 先列出数据规模、内存限制、稳定性要求、读写比例等判断条件，再给出建议。
这比直接要“最佳方案”更可靠，因为技术方案通常没有脱离上下文的最佳答案。
3. 复杂性能问题排查
例如“我的应用很慢，但不知道为什么”。thinking 会把可能原因拆成数据库查询、网络请求、内存分配、CPU 密集计算等方向，再建议优先定位的顺序。
这种场景下，你可以要求 Kiro 先给“诊断顺序”，再一步步执行，而不是一上来就修改代码。
使用收益
对学习有帮助
thinking 能让你看到问题是如何被拆开的。你不仅得到答案，还能学习 agent 的分析模板，比如先识别约束，再列候选方案，再比较 trade-off，最后形成建议。
对调试有帮助
当 Kiro 给出一个修复建议时，你可以从 thinking 中检查它是否基于正确假设。如果假设不对，结论也不可靠。越早发现这一点，越能避免无效修改。
对复杂任务有帮助
多步骤实现经常会牵涉文件依赖、测试顺序和风险控制。thinking 可以让你看到任务分解是否完整，从而在动手前修正计划。
最佳实践
适合开启的情况
- 学习新概念，希望理解建议背后的逻辑；
- 做架构、选型、性能优化等高影响决策；
- 调试复杂问题，需要系统排查路径；
- 做 code review，希望知道 Kiro 为什么指出某个风险。
适合关闭的情况
- 只是生成一个简单命令或配置片段；
- 你已经知道实现方案，只需要 Kiro 执行；
- 当前任务强调速度，而不是解释过程；
- 会话输出已经过长，影响阅读效率。
推荐工作流
- 在复杂问题开始前开启 thinking。
- 先让 Kiro 给出分析路径，不急着改代码。
- 检查它列出的假设是否符合你的项目。
- 确认方向后关闭 thinking，让 Kiro 专注执行。
- 到 review 或复盘阶段再开启 thinking 验证方案。
排障
开启后没有看到 thinking
先确认配置是否生效：
bash
kiro-cli settings chat.enableThinking如果状态正确但仍未出现，通常是因为问题太简单，没有触发复杂推理。可以换成包含约束和取舍的问题，例如“在三人团队、两个月上线、后续可能拆分的前提下，应该如何设计后端架构？”
thinking 输出太多怎么办
可以临时关闭：
bash
kiro-cli settings chat.enableThinking false也可以在 prompt 中明确要求“只保留关键推理步骤”“结论不超过三点”。对于执行型任务，建议关闭 thinking 后再继续。
相关页面
常见问题
thinking 会泄露隐藏的系统提示词吗？
不会。thinking 展示的是 Kiro 面向当前任务的推理过程，用于帮助你理解分析路径，不等于暴露底层系统提示词或模型内部状态。
我应该一直开启 thinking 吗？
不建议。它会让回答更长，也会增加等待时间。适合在复杂决策、排障和 review 中开启，进入明确执行阶段后可以关闭。
thinking 能替代人工架构判断吗？
不能。它的价值是把分析过程摊开，让你更容易审查假设和 trade-off。最终是否采纳，仍应由了解业务、团队和系统约束的人来决定。