先别急着开五个 Grok Bot，三个活过一周的才算数

Dep 在 X 上给了一套构建 Grok Bot 团队的顺序，核心只有一句：第一天别开五个。

原文链接：https://x.com/0xDepressionn/status/2117287485596135828

Grok Bot 可以理解成用 Grok 搭的自动助手，有人负责评审，有人负责找链接，有人负责汇报。Dep 把顺序拆得很细，先别急着堆数量。

步骤是这些：

1. 写下你每周重复做的工作。
2. 先建评审者。
3. 加一个侦察兵，只报告它真正打开过的链接。
4. 加一个领导，它是唯一和你交流的 Bot。
5. 让这三个跑一周，修掉坏掉的部分。
6. 到这时再加编码和指标。
7. 静音所有晒 30 个 Bot 设置的人。

这个顺序有意思的地方在于，它先解决维护成本。评审者放在最前面，因为 Bot 产出再多，没人把关就会变成堆积。侦察兵只报告打开过的链接，能少掉一批二手链接和没读过的内容。领导只留一个入口，避免几个 Bot 同时说话，最后你也不知道该听谁。

一周测试是过滤器。Harry Tandy 在回复里说，survivors beat volume every time，一周这个筛选才是真测试。Levi 说第 7 步是整个栈里最重要的一步。pronaks 补了一句，第 7 步会干掉他半个信息流。Dep 回：hahaha same。

Levi 还在这条回复里贴了一段视频，配文是第 7 步最重要。视频本身和 Bot 无关，但放在这里很符合这条推文的语气。

也有反向做法。kuch 说他把 Bot 设成 23:00 下班，凌晨 3 点找到的东西可以等到早上，他宁愿读新鲜的，也不想醒来看到 5 个 Bot 的积压。这个思路和 Dep 的顺序不冲突，重点都是先让系统可读、可维护。

多 Bot 设置常见的问题，往往出在维护成本被低估。三个能活过一周的 Bot，比七个活不过的更有用。第 7 步带一点讽刺：信息流里晒 30 个 Bot 的人，通常晒的是数量，不是结果。静音不是反对工具，是先把噪音关小。

如果要试，先写一周重复工作清单，选一个评审者跑起来。别急着把五个 Bot 全开。