Grok Bot 的额度怎么花：我从 12 条建议里留下的工作方法

我的结论先放前面：想让 Grok Bot 的额度花得明白，先管任务边界、上下文和运行频率，再考虑模型怎么分工。换个执行入口，不代表工作免费；新建一个 bot，也不代表能省下某个固定比例。

最近读到 maestro（@maestrooth）的文章 《12 Ways to Reduce Your Grok Bot Token Bill (Copy & Paste Settings)》。他自述订了每月 200 美元的 Ultra，三天用了 99% 的周额度，84% 的 tokens 花在重读聊天上。这些都是作者的个案，我没有独立验证，也不是我的用量数据。

下面保留原文十二个问题的顺序，用我自己的理解归纳，再放进我的工作方式里。文中的模板是我改写的任务约定，不是产品设置。原文涉及菜单、自动充值和计费机制的说法，我没有独立核查，不据此提供操作路径，也不把任何控制写成官方保证。

先把我的使用前提说清楚

我的 Ultra 额度与 Cursor 共用，所以把任务转去 Cursor，不能当成绕开同一额度池的办法。我的安排是：bot 只负责协调，真实工作在 Mac Studio 上执行，工作不用 Cursor 模型，也不用 CloudAgent。

模型选择上，我首选 Ollama Cloud / DeepSeek Flash 4.1，其次是 GPT/Codex，再到 Claude。但首选顺序还得服从实际可用的执行路径。这次写稿用的是现有 personal Codex 登录：现有 ds-claude --ollama 只从 Documents 读取本地 key，不接受 1Password 引用，因此这次不走它，也不为它读取 key，更不碰 work 凭据。

这套分工的意义是让协调和执行各自承担明确的工作。执行模型仍有自己的成本；机器放在桌上，调用的云模型也不会因此免费。我不能把协调端少消耗了多少，直接说成总账单少了多少。

我也不想为缩短上下文删掉关键依据。交接如果漏了路径、约束或已经确认的决定，新执行者就得重新摸索。整理上下文时，要一起考虑后续能否顺利接手，不能只看交接文字变短了多少。

1. 一项任务一段上下文，用短交接换班

长对话把需求、试错和过期决定越积越厚，后续工作可能反复读取这些上下文。我已经多次采用的办法是：让旧 bot 写短交接，交给新 bot 接手，旧 bot 留档，不删除。

新 bot 确实丢掉了旧对话上下文，这正是换班的结果，不是出错。所以交接要留下必要事实，不能只说“继续刚才的事”。规则和必要材料仍会占新上下文，也需要重新读取；少带历史，不等于零成本。同一个 bot 是否能另开独立新对话，我没有核实，这里不教具体操作。

我会用下面这个短交接模板：

任务：最终要交付什么。
进度：已完成什么，验证结果是什么。
待办：下一步做什么，按顺序列出。
路径：工作目录、输入材料、输出文件。
决策：已确认的取舍及原因。
边界：只允许做什么，哪些动作待批准。
停止：同一步失败两次，停止并汇报。

至于原文的 84%，只能按作者报告的口径理解。cache-token 占比不等于额度扣费占比，不能拿它推算“换班就能省 84%”，也不能据此估算我的节省幅度。

2. 把例行任务的间隔拉开

routine，也就是自动运行的例行任务，值得先算次数：每十五分钟一次，一天是 96 次；每小时一次是 24 次；每天三次就是 3 次。这个算术成立，但调用次数和费用未必同比变化。

我会先问：信息真的每十五分钟就值得处理一次吗？如果只需要早、中、晚看结果，先按这个节奏设计。频率应该跟实际需要的新鲜度走，不能因为能自动运行，就默认一直高频运行。

3. 能由事件触发，就把触发范围写窄

原文建议只盯特定频道或短语。我理解它的重点是减少无关检查：明确什么输入值得启动任务，命中后读多少、做什么、何时结束。

不过，事件触发是否受当前工具支持，需要另外确认。这里讨论的是任务设计，不承诺某个产品一定有对应开关。即使支持，也要避免一条模糊关键词把所有消息都卷进来。

4. 没产出的例行任务，先暂停

如果一个 routine 经常跑完却没有有用结果，先暂停，保留它的目标和规则，复盘为什么没有产出。以后需要恢复时，还有依据。

这比边放着跑边猜更容易看清问题。是否彻底移除，等确认不再需要时再决定；删除必须有明确批准，不能让 bot 为了“清理”自行处理。

5. 让例行任务有自己的 bot

固定检查最好只带它需要的说明和材料，别混进日常聊天里的长篇讨论。否则，做一个小检查，也可能背着一大段与它无关的历史。

这和第一条相通，但处理的是不同时间尺度：第一条管任务换班，这一条管长期重复工作的上下文。我会把检查对象、输出格式和停止条件写清楚，同时接受独立 bot 仍要读取自身规则的成本。

6. 先做最小安全测试

原文提醒，测试也可能真的执行操作。我的理解是，“试一下”三个字不能代替权限边界。

先用少量输入验证判断和输出；如果只是想检查流程，就明确要求只读、生成预览或草稿。任何发送、发布、删除、生产变更，都需要明确批准。不能让测试顺手变成真实操作，再拿结果证明流程可行。

7. 不需要的工具，就别给任务使用

只改一份本地文稿的任务，没有必要使用搜索、消息发送或生产系统工具。工具范围应该跟交付物对应，减少无关探索，也让任务的行为更容易检查。

我会先在 brief 里声明允许的工具和访问范围；若执行环境支持限制，再按需要收窄。这里不假设 Grok 一定提供某个关闭工具的设置，也不把少给工具等同于确定少扣额度。

8. 昂贵动作之前，设置检查点

原文举了几个适合先批准的边界：读超过五个网页、启动 subagent、失败两次后继续重跑，以及工作超过十五分钟。这些可以作为拟定任务预算的参考，不是我核实过的产品阈值。

我会把适合本任务的边界写进 brief。尤其是同一步失败两次，就停止并汇报：尝试了什么、卡在哪里、下一步需要什么。继续花时间之前，先让人知道任务已经偏离预期。

9. 移交编码任务之前，先认清额度池

作者提到转交 Cursor cloud agent，但这个建议只可能对他所述的旧 Cursor 独立额度情形有意义。他也明确说，X Subscription 共用周池时，这样做不省该池额度。

这正好提醒我：移交只是改变谁执行，不能凭入口名称判断成本。我的工作交给 Mac Studio 上的执行端，不用 Cursor 模型或 CloudAgent；是否值得这样分工，要同时看协调端和执行端的消耗、结果与返工，不能只看其中一边。

10. 给额外消费划线，但别把上限当硬停保证

先决定愿意承担多少额外消费，比额度快用完时临时放开更清楚。如果当前服务有相应控制，需要确认它实际限制什么、什么时候生效。

作者说，上限不保证让在途任务立刻硬停。我没有独立核查这个机制，因此不会把它写成承诺，也不提供未经验证的菜单路径。预算边界还应写进任务约定，不能只依赖一个想象中的开关。

11. 大任务前看用量，每周看最重的五项

开始大任务前，先看当前能拿到的用量记录，再决定范围和执行方式。周复盘则先挑消耗最高的五项，看它们交付了什么、有没有重复读取、频率是否过密、失败后是否还在重跑。

记录要按实际可见的口径解释。token 数、缓存占比、额度消耗和金额不能随意互换；如果看不到细分数据，就承认看不到。我现在没有足够数据给自己的流程报一个节省百分比。

12. 开始前，把交付物和停止条件写清楚

“帮我研究一下”很容易不断扩张。至少先说清楚交什么、读哪里、做到哪一步结束，减少模型猜需求，也减少我事后补需求造成的返工。

下面是我会复制后填写的 brief，同样只是任务模板：

目标：要解决的具体问题。
交付：文件路径、格式、长度、审核人。
输入：允许读取的材料与范围。
执行：在哪台机器执行，采用什么模型。
边界：允许修改哪里，允许使用哪些工具。
验收：什么结果算完成，需要检查什么。
预算：时间和访问次数上限；扩大范围先汇报。
停止：同一步失败两次，停止并汇报。
批准：发送、发布、删除、生产变更前须获明确批准。
结束：汇报结果、未完成项和不确定性。

对我来说，这十二条最有用的地方，是把自动运行的工作变成有边界、可检查的任务。旧 bot 留档，新 bot 拿短交接继续；协调端交代清楚，执行端按约定完成。先把每次运行为什么发生、要交付什么、何时停止说明白，再用真实记录判断成本有没有改善。