Kiro 的 credits 怎么省？六类实操技巧和一条超额分界线
用 Kiro 的人到月中最常问的一句话是：我这 1000 credits 是怎么没的？
这个问题没有官方答案。我先把话说在前面：Kiro 的文档站里那个计费参考页，2026-08-08 我去看的时候是 404；定价页上写了每档给多少 credits、超额多少钱，唯独没写一次操作扣几个 credit，也没写credits 什么时候刷新。所以任何告诉你”某某操作消耗 X credits、避开它就能省”的说法，都不是从官方那儿来的。
这篇不讲那种编出来的数字。讲的是另一件更靠谱的事：既然消耗的计价规则不透明，那唯一能确定的省钱方向就是减少无效的模型调用次数——让 Agent 少跑冤枉路、少推翻重来、少替你干本来两秒就能干完的活。读完你会拿到六类能直接照做的习惯，一套自己测日均消耗的土办法，以及一条能算出来的分界线：什么时候该继续省，什么时候省已经没意义、该直接升档。
先把前提说清楚：不知道单价，就只能优化次数
先看能确定的部分。Kiro 个人版的档位是公开的：
| 档位 | 月价 | 含 credits | 超额单价 |
|---|---|---|---|
| KIRO FREE | $0 | 50 | 页面未写明 |
| KIRO PRO | $20 | 1,000 | $0.04/credit |
| KIRO PRO+ | $40 | 2,000 | $0.04/credit |
| KIRO PRO MAX | $100 | 5,000 | $0.04/credit |
| KIRO POWER | $200 | 10,000 | $0.04/credit |
团队版价格结构一样，PRO $20、PRO+ $40、PRO MAX $100、POWER $200，都是每用户每月，包含的 credits 数量与个人档相同，超额同样是 $0.04/credit。
算一笔：$20 买 1000 credits，套餐内单价 $0.02/credit；超额单价 $0.04，正好是套餐价的 2 倍。往上每一档也一样：$40 换 2000、$100 换 5000、$200 换 10000，全是 $0.02/credit。也就是说，Kiro 各付费档的套餐内单价完全一致，档位之间的差别只是包量，不存在”买大档更便宜”这回事。这个结论后面第六条要用。
但这五行数字之外的东西，官方都没说：一次对话扣多少、Agent 自己展开的每一步是否单独计费、不同工作模式之间差多少、额度是按月清零还是按其他周期刷新。这些我核不到，就不写。想确认的话以官方定价页当时的措辞为准。
那怎么办？把”省 credits”这件事翻译成一句能落地的话：每一次请求都是成本，能合并的合并、能避免的避免、能少推翻一次就少一次。这条原理不依赖任何未公开的计价细节，也不会因为官方哪天调整规则就失效。
顺带给一个自测的土办法，比猜规则实在得多。找一个你正常工作的周，每天固定时间（比如晚上收工时）记一次剩余额度，记满七天。你会得到六个日差值。把它们排开看：中位数就是你的日均消耗，最高那天回头对一下当天干了什么——通常是某次大重构或者某个反复推翻的需求。这份记录的价值在于，它是你自己的消耗曲线，比任何外部数字都准。有了它，你才知道自己离超额还有多远，以及下面哪条技巧对你最有用。
一、把需求圈死再发，别给它自由发挥的空间
这是六条里效果最大的一条，没有之一。
对比两句话。第一句：「帮我优化一下这个项目。」Agent 收到这句会怎么做？它得先搞清楚”这个项目”是什么，于是扫目录、读配置、挑几个它觉得重要的文件读进去；然后判断”优化”指什么，可能是性能、可能是结构、可能是可读性，它得挑一个方向；挑完开始改，改完自检，自检发现连带影响又去读别的文件。这一路下来，搜索、读取、生成、逐文件修改、回头验证，十几步是常态——而且其中大半步骤是在猜你想要什么。
第二句：「只改 order/service.ts 里的 createOrder，把参数校验提到函数开头，别动支付相关的调用。」这句话把三件事都钉死了：改哪个文件、改哪个函数、什么不许碰。Agent 不需要搜索定位，不需要判断方向，也不需要为”要不要顺手改支付逻辑”纠结。步数一下子收敛到读一个文件、改一处、验证一次。
差别不在模型聪不聪明，在于你留了多少需要它自己展开的空白。每一块空白它都得用一轮或几轮调用去填。
具体怎么做，三个动作就够了：
- 给路径。知道文件在哪就直接写出来，别让它去找。哪怕你只记得大概位置，写”在
src/api/下面”也比不写强。 - 给边界。明确说”别动 X”。这一句能挡掉很多它自作主张的连带修改，也挡掉你事后让它改回去的那一轮。
- 给完成标准。“改完能通过
pnpm test里的订单相关用例”这种可验证的标准，比”改好一点”能少掉两三轮来回确认。
二、把项目约定沉淀成一份长期文件
第二个大头是：Agent 每次开新会话，都得重新摸一遍你的项目。你用什么包管理器、组件放哪个目录、命名是驼峰还是短横线、哪些目录是生成的不许改——这些它上次已经搞清楚过一遍，但这次它不记得，只能再搜一遍、再读几个文件确认一遍。你每开一个新会话，就重复付一次这个”认路”的成本。
解法很直白：在仓库根目录放一份约定文档，比如 PROJECT_NOTES.md，把这些一次性写清楚，然后每次开工第一句让它先读这份文件。
写什么？我的经验是这几类最省事：
- 技术栈和命令：包管理器是哪个、跑测试用什么命令、构建用什么命令。这几行能直接省掉它试错跑命令的次数。
- 目录约定：业务代码在哪、共享组件在哪、哪些目录是自动生成的（写明”不要改”）。
- 代码风格的硬规矩：不是那种”要写得优雅”的空话，而是”所有接口请求走
src/lib/request.ts，不要直接用 fetch”这种能一眼判断违反没违反的规矩。 - 踩过的坑：比如某个依赖必须锁在某个版本、某个文件改了要同步改另一个。这类知识 Agent 靠读代码是读不出来的，只能你告诉它。
还有一点值得提：这份文件放在你自己的仓库里，不属于任何一家工具。哪天你从 Kiro 换到别的 Agent，或者同一个项目在两个工具之间来回切，这份约定原样带走就能用。相比之下，那些存在某个工具账号里的配置，换工具就得重做一遍。花二十分钟写的东西，最好让它能跟着项目走，而不是跟着某个订阅走。
三、大任务拆成段做，跑歪只损失一段
假设你要做一个完整功能：加数据模型、写接口、改前端、补测试。一句话全交出去，Agent 会一口气跑完整条链路。听起来很爽，直到它在第二步理解错了一个字段含义，然后带着这个错误理解把后面三步全做了。
这时候的损失不是”改一个字段”，是从第二步开始的所有工作全部作废，你还得先花时间看懂它错在哪。这一整段的调用消耗，一分不退。
拆成四段做，情况完全不一样。每段结束你看一眼产出，对了就往下走，错了就在那一段重来。最坏情况下你损失的只是一段。
拆的粒度我一般按”能不能一眼验证”来定：这一段做完，我能不能在一两分钟内判断对错？能，粒度就合适；要花二十分钟通读才知道对不对，那就还得再拆。前面那个例子，我会拆成：先只定数据模型，看字段对不对；再写接口，跑一下能不能通；再改前端；最后补测试。四个检查点，每个都是几十秒能看完的东西。
这个做法在别的工具上也成立。像 Cursor 那种快速请求用完自动降到慢速池的机制，跑歪一整条长链路的代价就是接下来半天都在排队；Cursor 快速请求用完了怎么办那篇讲过这套降级逻辑。Kiro 这边代价直接落在钱上——超额是 $0.04/credit 实打实地扣。形式不同，浪费掉的东西是一样的。
四、不满意的时候，先想清楚再重发
这条讲的是一个特别容易上头的场景：结果不对，你顺手回一句”不对，再改改”；还不对，“我是说那个地方”；再不对，“你能不能理解我的意思”。三五轮下去，问题可能确实解决了，但你为此付出的调用次数，比一开始就把话说清楚多好几倍。
而且追问有个隐蔽的副作用：对话越长，它每一轮要带的上下文越多。前面那些无效的来回全都还挂在那儿，你后面每一句话都得驮着它们跑。
我现在的做法是给自己定了个规矩：同一个问题连续追两次还没对，就停下来。停下来干什么？花一分钟想清楚三件事——它到底误解了哪一句、我原来那句话里哪个词有歧义、我要的结果具体长什么样。想完了不要在原对话里接着说，开一个新对话，把重新组织过的完整需求一次发出去。
多数时候，重发一次的效果好过继续追问五次，消耗也更少。这不是什么技巧，是承认一件事：说不清楚的需求，靠多说几遍是说不清楚的，只能重新组织。
五、本地几秒能干完的，别交给它
有一类请求纯属浪费，就是那些你自己动手更快的活：
- 改一个变量名——编辑器的重命名快捷键，全项目安全替换，一秒钟。
- 查某个函数在哪儿被调用了——全局搜索，比让 Agent 去读文件找快得多，而且结果是完整的。
- 格式化代码——保存时自动格式化，本来就不该有人管。
- 看某个报错什么意思——先自己读一遍报错信息。相当一部分报错本身就写清楚了原因和位置。
判断标准很简单：这件事有没有确定的机械解法？有的话，用工具，别用 Agent。重命名、搜索、格式化、跳转定义，这些是编辑器几十年积累下来的能力，确定、瞬时、免费。Agent 的价值在于处理那些没有确定解法、需要判断的问题——比如”这段逻辑为什么在并发下会出错”、“这个模块该怎么拆才合理”。
把这两类活分开，你会发现日常请求量能降下来一块，而且降的全是本来就不该发的那部分。
六、用超额分界线做月度复盘：什么时候省已经没意义
前面五条都在教你怎么省。这条相反，教你什么时候别再省了。
回到那组数字。PRO 是 $20 含 1000 credits，PRO+ 是 $40 含 2000。从 PRO 升到 PRO+，多花 $20，多拿 1000 credits。而如果你不升档，靠超额买：$20 按 $0.04/credit 只能买到 500 credits。
结论很硬：当你每月稳定超额 500 credits 以上时，继续留在 PRO 硬省，就是在用两倍的价钱买同样的东西。
每一档的分界线都可以这么算，公式是「跃迁差价 ÷ $0.04」：
| 当前档 | 升到 | 差价 | 多拿 credits | 超额买同样多要花 | 该升档的分界线 |
|---|---|---|---|---|---|
| PRO $20 | PRO+ $40 | $20 | +1,000 | $40 | 月超额 > 500 |
| PRO+ $40 | PRO MAX $100 | $60 | +3,000 | $120 | 月超额 > 1,500 |
| PRO MAX $100 | POWER $200 | $100 | +5,000 | $200 | 月超额 > 2,500 |
看最后一列。你在 PRO 档，月超额稳定在 800 credits，那就是每月多掏 $32 买 800 个；升到 PRO+ 只要多掏 $20，还多拿 200 个没用完的。这时候再抠请求次数，抠的是一件已经不划算的事。
三点提醒。第一，注意”稳定”两个字——赶项目那一个月冲上去了，接下来两个月回落，那是波动不是趋势，别为一次波动改订阅。看三个月，都在线上再动。第二，超额单价 $0.04 是定价页上写的，档位跃迁的性价比全靠它算出来；未来价格若有调整，用同样的公式重算即可。第三，FREE 档的 50 credits 我不建议拿来做任何测算——它太少，而且刷新周期官方没写，用它推不出月度结论。如果你是学生，先看看有没有免费资格更实在，Kiro 学生免费那篇说了申请口径。
顺便说一句口径上的事。不同工具”用完了”之后的代价形式不一样：有的是加钱续（Kiro 这种超额计费），有的是降速继续用，有的是到点只能等下一个周期。选工具的时候，与其比谁家额度给得多，不如先想清楚你更能接受哪种代价——这个判断比任何数字都稳定。
最后
回头看，六条技巧其实只有一个内核：让 Agent 少猜。需求圈死是让它少猜你想要什么，长期文件是让它少猜项目长什么样，拆段是让它猜错了也不至于连累后面，重发是不让它在一个错误理解上越走越远，本地干活是根本不让它猜。第六条则是给”省”这件事画个止损线——省到某个点之后，升档比抠请求更省钱。
至于那些没有公开的东西——单次操作扣几个 credit、credits 怎么刷新、不同模式差多少——我核不到就不编。你真正需要的也不是这些数字，而是自己那条消耗曲线。花一周记七次余额，你会比任何猜测都清楚自己的钱花在哪儿了。价格与档位以官方定价页当时的说明为准，本文所有数字来自 2026-08-08 的核对。