← Grok Bot 实战案例总览 · 成果库

gippp69 专题:Grok Bot 的 routine 每 5 分钟比每小时贵 12 倍(成本与调度“完整课程”)

一篇 87 万展示的 X 长文:Bot 搭好之后,决定账单和每天早晨体验的是“时钟”。含 5 份可直接复制的提示词和一个周审计脚本。

说明:本专题于 2026-10-17 根据公开资料整理,没有编造内容:提示词、步骤和数字都来自下方列出的来源;整理者的推断用“推”标签标出,没能访问或没法核实的放在最后一节。数字多为作者自述,未经验证。
引逐字引用或忠实转述原文 推整理者推断
12

gippp69 专题:Grok Bot 的 routine 每 5 分钟比每小时贵 12 倍(成本与调度“完整课程”)

来源类型:X 长文(@gippp69,2026-10-11,约 88 万展示);已读全文和全部代码块;作者说明成本为估算

引作者的主论点:一次聊天只花一次钱,一个 routine 每次醒来都花钱,而且大多数时候什么都没发生。把 routine 从每小时改成每 5 分钟,成本是 12 倍;你几乎不会得到 2 倍的价值。

引长文的结构:先给数字,再讲为什么时钟比模型更重要,然后依次是:频率表、不要轮询能通知你的东西、变化检查让高频 routine 变便宜、夜间 3 点的审批问题、自己记运行日志、用脚本找出该删的 routine、五个来自官方日志的坑、防护清单、没测过的部分和最后的打法。

须知:成本是作者的估算,不是账单:他按 Grok 4.6 的 API 价格(每 100 万 token:输入 $2、缓存 $0.50、输出 $6)估算一次完整运行约 $0.046(20K 输入加 1K 输出),并明确说订阅是按计划额度计费、真实指标要看 App 里的用量页。这篇文章的“官方限制”部分他注明引自官方 routine 文档、审批文档和更新日志,截至 2026-10-10。

长文里只有文字、9 个代码块(含一个 Python 脚本);原文里的表格是以代码块形式给出的,下面都逐字收录。

本专题目录

12.1

先看数字:限制、价格和频率表

引来自原文第 1、3 节

作者列的“官方限制与估算”原表(逐字):

routines per bot                     up to 50
fastest schedule                     every 5 minutes
runs per month at 5 min              8,640
50 routines x 5 min                  432,000 runs a month
background approval window           ~10 minutes, then it expires
run history kept per routine         20 runs (= 1h 40m at 5 min)
bots on one account                  share one cloud computer

Grok 4.6 API, per 1M tokens          $2 in · $0.50 cached · $6 out
one full run, my example             20K in + 1K out ≈ $0.046
one 5-min routine, API rates         ≈ $397 a month
same routine with a change check     ≈ $45 a month
same job on an event trigger         $0 for the runs where nothing happened

同一个 routine、同样每次读 20K 写 1K token,不同频率的月成本(作者估算,逐字):

CADENCE         RUNS / MONTH     COST / MONTH
every 5 min     8,640            $397
every 15 min    2,880            $132
every hour      720              $33
4x a day        120              $5.52
once a day      30               $1.38
  • 引“从每小时到每 5 分钟是 12 倍成本。想想多出来的 55 分钟新鲜度,你实际会拿来做什么。”
  • 引他认为通常够用的频率:活跃仓库的 CI 与 PR 状态每 15 分钟;收件箱分诊每小时;竞品页面和文档每天一次;报告和看板回顾按计划一次;审计每晚一次。
  • 引原则:从慢开始,只在“出现真实的漏报”证明它太慢时再提速。

来源

12.2

能通知你的就别去轮询:窄触发

引原文第 4 节

  • 引“最便宜的 routine 运行,是从没发生的那一次。”
  • 引schedule 是每 N 分钟问一次“有新东西吗”;trigger 是等别人来告诉你。Grok Bot 的 routine 可由事件启动:Slack 消息、GitHub 通知、带自己 URL 和 key 的 webhook,以及“这周起”发到 Bot 自己邮箱的邮件。
  • 引一个坑:在团队里,管理员得先把收件箱功能打开,Bot 才能用邮件触发。
  • 引官方文档的警告(作者引用):“Avoid broad listeners such as ‘every new message.’”——对所有消息触发就等于 0 分钟的定时。
  • 引规则:系统能发事件就用窄触发(不是“#eng 里任何消息”,而是“#deploys 里包含 FAILED 的消息”);不能发事件就用带变化检查的定时;GitHub routine 只盯一个 PR 时,会忽略其他 PR 的事件,并在 PR 合并或关闭后自行移除,比仓库级监听更省。

他给的 webhook 触发提示词(逐字,可粘贴)

展开查看 webhook 触发提示词(逐字)(约 374 字符)
Create a routine triggered by a webhook.

When it fires, read only the request body. Expect JSON with
"service", "status" and "url".

If status is not "failed", do nothing and stop.
If it is "failed", open the url, find the first error line, and post
to #incidents: service, the error line, one guess at the cause,
and the link. 4 lines max. Never retry the deploy yourself.

来源

12.3

变化检查:让高频 routine 变便宜

引原文第 5 节;核心是“让大多数运行不是完整运行”

引有时你真的需要 5 分钟,又没有事件可听(比如发布刚上线、一个不是你管的页面在快速变化)。作者的办法不是把完整运行变便宜,而是拆成两步:先做一个很小的检查(读一个哈希、计数或时间戳,约 2K token,用一个词回答),只有检查说“有变化”才做真正的工作。

展开查看“检查 + 工作”两段式提示词模板(逐字)(约 464 字符)
Every 5 minutes:

CHECK
Open [the page / repo / board]. Read only [the status field / last
commit hash / count of open items / "updated" date].
Compare it to the value in routines/state/[name].txt.
If it is the same, append "no_change" to the log and stop.
Do not open anything else. Do not "take a quick look around".

WORK (only if it changed)
Save the new value to routines/state/[name].txt.
Do [the actual job].
Post the result to [destination] in 5 lines max.

引原文里方括号处是你自己要填的内容。作者强调 “Do not take a quick look around” 这行很关键:没有它,Bot 往往会顺便探索,你又回到了付完整运行的钱。

作者对成本的演算(逐字,假设一天约变化 6 次,这是他的假设):

WITHOUT A CHECK      8,640 full runs x $0.046        = $397

WITH A CHECK         8,640 checks    x $0.0043       = $37
                       180 full runs x $0.046        = $8
                     total                           = $45   (-89%)

引结论:同样 5 分钟的反应速度,成本约九分之一(约 $397 → $45,-89%)。

来源

12.4

凌晨 3 点问题:后台审批 10 分钟就过期

引原文第 6 节,引自官方审批文档

  • 引官方审批文档(作者引用):由 routine、触发器或另一个 Bot 的消息发起、你不在场的工作,其审批 “expires after about 10 minutes”,卡片显示 Expired,动作不会执行。
  • 引他的算账:你睡 8 小时,一个需要你同意的 5 分钟 routine 会触发 96 次,96 个审批全部过期,什么都没坏也什么都没做成,醒来看到一列灰色卡片。
  • 引所以每个在你不在时运行的 routine,要提前决定结局:①允许(动作安全、可逆、你已连续批准过五次,就写一条自定义规则;过期卡片本身也会提供 “Always allow this in the future”);②停在草稿(动作不安全,就把草稿留在队列里,早餐时处理)。
  • 引“没有第三个选项让 Bot 等你。看起来有,但它什么都不会做。”

来源

12.5

自己记运行日志,再用脚本每周找出该杀的 routine

引原文第 7、8 节;官方只保留每个 routine 最近 20 条记录

  • 引官方文档(作者引用):每个 routine 只保留最近 20 条运行记录;5 分钟一次的话就只剩最近 1 小时 40 分钟,凌晨 2 点出事、9 点才看,证据已经没了。
  • 引所以每个 routine 结尾都往自己的文件写一行日志;Bot 共享一台云电脑,日志放在工作旁边,任何 Bot 都能读。

加在每个 routine 末尾的日志提示词(逐字)

展开查看日志提示词(逐字)(约 231 字符)
After every run, append one line to routines/log/[name].csv:
time,result,changed,minutes,needed_approval,note

result is one of: ok, no_change, draft_left, failed
note is under 12 words. Create the file with that header if missing.

周审计脚本 audit.py(逐字)

引每周对日志文件夹跑一次,每个 routine 打印一行,标出白花钱的。运行前把脚本里的 RUN_COST 改成你自己的完整运行估算。

展开查看 audit.py(逐字)(约 1302 字符)
import csv, sys
from pathlib import Path

RUN_COST = 0.046      # your full-run estimate in $, see section 1
CHECK_COST = 0.0043   # a no_change run, if the routine has a change check

def verdict(no_change, failed, runs):
    if runs == 0:
        return "dead: never ran, check the schedule"
    if failed > 0.10:
        return "PAUSE: fails too often"
    if no_change > 0.99:
        return "DELETE or make it daily"
    if no_change > 0.95:
        return "slow down or add a change check"
    return "keep"

folder = Path(sys.argv[1] if len(sys.argv) > 1 else "routines/log")
rows = []
for f in sorted(folder.glob("*.csv")):
    runs = list(csv.DictReader(f.open()))
    n = len(runs)
    nc = sum(r["result"] == "no_change" for r in runs)
    fl = sum(r["result"] == "failed" for r in runs)
    dr = sum(r["result"] == "draft_left" for r in runs)
    cost = nc * CHECK_COST + (n - nc) * RUN_COST
    share = nc / n if n else 0
    rows.append((share, f.stem, n, fl / n if n else 0, dr, cost))

print(f"{'routine':24} {'runs':>6} {'no_change':>10} {'failed':>7} {'drafts':>7} {'est $':>8}  verdict")
for share, name, n, failed, drafts, cost in sorted(rows, reverse=True):
    print(f"{name:24} {n:6} {share:10.0%} {failed:7.0%} {drafts:7} {cost:8.2f}  "
          f"{verdict(share, failed, n)}")

引判断逻辑(脚本原文):没有运行记录算 dead;失败率超过 10% 标 PAUSE;no_change 超过 99% 标 DELETE 或改成每天;超过 95% 建议放慢或加变化检查;否则 keep。

让前台 Bot 每周一自动跑审计的提示词(逐字)

展开查看周审计提示词(逐字)(约 195 字符)
Every Monday at 9:00, run: python audit.py routines/log
Post the output to me as-is. Then list any routine marked DELETE or
PAUSE and ask me which ones to remove. Do not delete anything yourself.

引他的话:“清单顶部就是你的钱去的地方。一个 99% 都是 ‘no change’ 的 routine 不是监控,是一笔费用。”

来源

12.6

更新日志教你的五个坑,和一张防护速查表

引原文第 9、10 节

原文说前四个直接来自官方 Grok Bot 更新日志和文档,第 4 条是他自己的设计规则:

  1. 和 Bot 聊天会让 routine 多跑一次。“If you message your Bot while a routine is running, the routine runs again afterward.”(官方,作者引用)
  2. 测试运行是真运行。“A test run performs real work. It can navigate websites, change files, and call connected tools.”(官方,作者引用):在副本上测试,不要在真收件箱上。
  3. 日程从创建时开始计数。每小时、间隔和每天的 routine 按创建时间起算;想要 9:00 的报告,就在 9:00 创建,不是 9:37。
  4. 别指望错过的运行会补上。(作者自己的设计规则)每次运行要补上自上次成功记录以来的所有内容,这样漏一次只是延迟,不是丢数据。
  5. 长时间离开会暂停。Grok Bot 可能在你离开很久后问你是否继续运行 routine,不回复就暂停;度假回来先检查 routine 列表。

防护速查表(逐字)

the system can send an event           -> narrow trigger, not a schedule
schedule faster than hourly            -> needs a change check
routine runs while you sleep           -> Custom Rule to allow, or stops at a draft
trigger on "every new message"         -> rewrite it to match one thing
email trigger in a team                -> admin has to enable the inbox first
history matters                        -> routine writes its own log line
no_change over 99%                     -> delete it or make it daily
testing a new routine                  -> safe copy, it does real work
logins on the shared computer          -> every bot can use them

来源

12.7

最后的打法,以及作者承认没测过的

引原文第 11、12 节

作者的 7 条打法(转述)

  1. 给“时钟”定价,而不是给一次运行定价。
  2. 能通知你的,就别轮询。
  3. 从工作能承受的最慢日程开始。
  4. 要快又没有事件?先做廉价检查,有变化再做完整运行。
  5. 提前决定夜里怎么收场:要么允许规则,要么草稿;永远不要“等我”。
  6. 每个 routine 自己写一行日志,周一用脚本读。
  7. 删掉 99% “无变化”的,或两周没人读的。

他明说没测过的

  • 成本数字只是按 Grok 4.6 API 价格当作尺子,Grok Bot 实际按计划额度计费,xAI 没公布额度多大。
  • 每次运行的 token 数:20K 输入和 1K 输出只是例子,开重页面或长线程会多得多。
  • “每天变化 6 次”只是假设。
  • Bot 是否会老实地“只检查”:这个变化检查提示词依赖 Bot 不去探索,他建议先看几天日志再信。

来源

12.8

引用这篇文章的其他帖子

两条,都只引用了结论

  • 引@heyanjey(10 月 14 日 00:15 北京时间):转述“每 5 分钟的 routine 一个月触发 8640 次,每小时只有 720 次”,建议能用事件触发就用事件触发;高频检查时先核实有没有变化再启动完整流程。
  • 引@fleyta88(10 月 15 日 01:21 北京时间):给了一句可粘贴的提示,让 Grok Bot 每 5 分钟监控 X 提及,过滤噪音、保存已核实的发现、记录执行成本、只在重要变化时通知、未经批准不发布。他的提示词原文:“monitor my X mentions every 5 minutes. filter irrelevant activity, save verified findings, track execution costs, and only notify me when something important changes. never publish without approval.”(他说“7 个 AI agent 在 5 分钟循环里”,帖子没有给出这 7 个 agent 的具体内容,我无法核实,视频我没有看。)
§

来源汇总与没能访问的

没能访问的

  • 长文的封面图和配图没有读取;原文的表格以代码块形式提供,已收录。
  • 文中官方文档和更新日志的引文,我没有逐条回到官方页面核对,只是转述作者的引用。
  • Telegram 频道里的其他内容没有访问。

来源

其他专题

↑