5个Grok Bot上夜班，醒来只看一份简报

大多数Grok Bot自动化团队，活不过周四。

周一七个bot全在线，账号都登录好，routine几分钟跑一次。到周末，六个再没人看，一个干了没人批准的事，额度也没了。

Dep的解法是反着来：5个bot，每个只干一件事，晚上干活，白天只留一份简报。他在X上把完整设置贴了出来。

先补背景。Grok Bot是马斯克旗下xAI的自动化agent产品，不是聊天窗口。Debbie O'Brien在推文里解释过：每个bot都有自己的一台云电脑，带浏览器、邮箱和桌面。你把笔记本合上，它继续干。Grok Bot官方账号举过一个例子：用bot处理support队列，一次事件10分钟清掉204张ticket，一位工程师审批。马斯克说Grok Bot是他见过增长最快的产品。

但bot在你睡觉时干活，意味着它犯错时你也睡着了。Dep的三道防线：不可逆操作一律变成草稿；一个专门的审查bot检查其他bot的输出；真正的代码工作由Anthropic的Claude Opus 5.5跑在分支上，绝不碰主分支。

五个人，一个岗位

Reviewer：检查其他bot的输出，返回通过/失败加原因，绝不悄悄修复。
Scout：盯领域里发生了什么新变化，最多10条，每条带链接，没打开过的不许报告。
Coder：每晚通过Claude Code跑一个任务，留分支和摘要，绝不碰main。
Metrics：拉真实数字，一张表加变化，没重新打开过的数字不报告。
Lead：写晨间简报并路由白天任务，07:30一屏，绝不自己干专家的活。

构建顺序：先建reviewer、scout、lead。coder和metrics等这三个活过一周再说。

七条规则，粘贴到每个bot前面

会发送、支付、发布、删除或改动账号的操作，一律变草稿。你永远不自己执行。
报告任何数字或说法前，重新打开来源并附上链接。没有链接，没有声明。
只用你的工作需要的登录。碰到登录墙，停下，留给我。别让我把密码贴进聊天。
夜间运行不等我批准。需要批准就写草稿、记日志、继续走。
同一步失败两次，停下，写清楚什么失败了、试过什么。
每次运行往自己的日志文件加一行：日期、时间、做了什么、什么变了、跳过了什么。
上次运行之后没有变化，写“no change”，然后停。

Dep特意说明了几条关键规则的用途。第1条看的是“能不能撤销”：小动作可能是永久的，大动作可以是草稿。第4条：凌晨3点没有你的“是”，夜间任务必须能自己收尾。第6条：Grok Bot只保留每个routine最近20次运行记录，自己的日志是早上9点的证据。第7条：没有这条，研究型bot第四天就把你淹了。

Prompt

每个bot对应一段，复制后改掉时间和来源就能用。

Reviewer，先建：

你是我的reviewer。你唯一的工作是在结果到我手上之前检查其他bot的输出。
07:00，读取scout、coder、metrics的最新输出。
逐条检查：
- 打开来源链接。内容是否和条目声称的一致？
- 数字是否和来源有出入？
- 是不是昨天的重复？
- 对coder：是否在自己的night分支上？摘要是否与diff一致？
输出：一张表，条目 / 通过或失败 / 一句话原因。
永远不要自己修改或重写任何条目。你对其他bot是否正确没有利害关系。
如果全部通过，一句话说清。

Scout：

你是我的scout。02:00，检查以下来源自上次运行以来有没有新内容：
[你的来源：X账号、changelog、repo、newsletter]
我的领域：[一句话描述你做什么、为谁做]
只有新东西且这个领域的人这周会采取行动的条目才保留。
输出：最多10条。一行发生了什么，一行为什么和我有关，附一个你打开过的链接。
没有符合条件的？写“no change”，停止。记到scout-log.md。

Metrics：

你是我的metrics bot。06:00，打开[你的dashboard]并拉取[具体指标]。
每项和上周同一天对比。
输出：指标 / 昨天 / 上周 / 变化，再用至多3行说明什么动了，标注为猜测。
来源打不开，写n/a。绝不估算。记到metrics-log.md。

Lead，你白天唯一对话的bot：

你是我的lead，我唯一直接对话的bot。团队：scout、coder、metrics、reviewer。
07:30，reviewer之后，写我的简报：
1. 今天需要我做的决定（最多3个），附草稿
2. 数字里什么动了（仅reviewer通过的）
3. 领域里有什么新的（仅reviewer通过的）
4. 昨晚什么失败了，为什么
一屏。没有链接的条目不许出现。
白天，把任务路由给对应bot。交目标、上下文和理由，不只是文件。没有bot负责的事，告诉我。

最后一行是大多数团队漏水的地方。第二个bot拿到文件但没拿到推理过程，于是回答了一个略有出入的问题。

Coder的prompt在代码部分单独说。

时间表，慢是刻意的

01:00 coder，02:00 scout，06:00 metrics，07:00 reviewer，07:30 lead。

Dep的建议很直接：选任务能承受的最慢节奏。Gipp在另一篇文章里算过一笔账：一个bot用5分钟时钟，一个月醒8640次，按Grok 4.6 API价格大约$400；改成每小时唤醒，只要$33。同一个bot、同一个模型、同一条prompt，只是把频率调慢。

所以先用最慢的节奏跑。只有真实失误证明“它太慢了”，才提速。能用触发器，就别用时钟。

代码任务用Opus 5.5

10月更新后，Grok Bot会自己为任务选后端模型，Opus 5.5是选项之一。没有picker，你没法强制指定。Elon Musk在X上确认过，Grok Bot会用“最可能给出好结果”的后端模型，包括Claude Opus 5.5、MidJourney、Suno。如果某个任务必须用Opus 5.5，走终端。

Coder bot在终端里跑Claude Code，用你自己的Claude订阅登录。重构、测试、依赖检查、小修复，都在这条路上处理。注意：所有bot共享同一台云电脑，那个登录谁都能用。

所以需要更严的护栏。settings.json里：允许可逆的操作，读、编辑、测试、lint、commit；push或加新依赖前要问；deny list写死灾难操作，递归删除、force-push、hard reset、.env、裸网络请求。deny压过allow，没有一条宽泛规则能凿穿这堵墙。

仓库里再放一份CLAUDE.md。Andrej Karpathy那份在GitHub拿了82,000 stars、7,800 forks，Dep之前专门拆过，这是他的标准配置。

你是我的coder。01:00，打开[path]仓库里的TASKS.md，在plan mode启动claude code。
今晚的任务是TASKS.md最上面那条。
先让它写PLAN.md。计划碰到deny list，停止并记日志。
否则在分支night/[date]上干，永远别碰main，永远别push。
完成后，或同一步失败两次，写MEMORY.md：改了什么、还剩什么、哪些需要我拍板。
把摘要加进log交给reviewer。

有网友po过Claude Code在5分钟里诊断并修好了一个慢到离谱的Wi-Fi路由器。夜班把同样的能力放到了定时器上，外加护栏和审查。

Review bot：唯一没有利益关系的角色

每个bot都可能自信地犯错。Scout推了个说法略有出入的帖子，Metrics抄了昨天的数字，Coder写了和diff对不上的摘要。自己查自己，每次都通过。

Reviewer只是没有“希望其他bot是对的”的利益关系。它打开每个链接、重新核每个数字、把coder的summary和branch做diff。不通过的项目不会进你的简报，只以失败加原因的形式出现，让你知道该修什么。

每周让lead问每个bot对整套设置的理解，清掉过期认知。记忆会把好习惯带向明天，也会把周二错的理解带到周五。

坑，按出现顺序排

第一天别开太多bot。三个活下来的，比七个养不活的强。
时钟别太快。5分钟一次烧的是“无事发生”的那些次数。
别让bot在凌晨3点等你批。它只会等一宿。规则4。
所有bot共享云电脑、文件和登录，只连接工作需要的账号。
你控制不了Grok Bot何时用Opus 5.5。终端是保证。
外部模型处理任务时会读取bot能读到的数据。有些活儿到这一步就是dealbreaker。
Coder范围蔓延。一晚一个任务。没法在喝杯咖啡的时间里review完的分支，太大了。

什么时候不需要这套？只问问题然后读答案，普通聊天就够。任务没法用一段话交代给新员工，先把描述改好。手上只有一个重复任务，这套东西有三个四个才回本。

最后，有网友kuch给了个相反的方案：他的bot晚上23:00就下班。凌晨3点发现的东西等不到天亮，他宁可醒来读新鲜的，也不想面对5个bot的积压。Dep回了一句：“don't forget bout that.”

Dep的结尾：画好围栏一次，早上review只需要一屏。

p.s. 先建reviewer。它就是每个人跳过、但每天早上第一个要查的bot。