72小时直播开一家公司：xAI三人组和他们的AI Bot员工，实战手册全开源了

一家公司，从零到上线，只用了72小时——而且全程直播，翻车画面一个没剪。

2026年9月15日到17日，xAI（现 SpaceX AI）Grok Bot 团队的三位员工——产品负责人 Roshan Sadanani、工程师 Lauren Tan（React 核心团队出身）、开发者体验负责人 Matt Palmer——在旧金山做了一场硬核实验：三个人，一群 AI Bot 当"员工"，72小时内从一张白板开始，现场搭出一款有真实用户的产品。

三天后，一个叫 Thursday Arena 的自动对战游戏真的上线了：433 个 PR 被合并、约 2000 名玩家登录、6000 场公开对局——营收是 0 美元，他们把这个"诚实数字"直接写进了官方手册。

更值钱的是：第三方开发者把这三天的全部方法论整理成了一个开源仓库 grokbot-field-notes（MIT 协议），里面有 69 个 Bot 岗位说明书、9 份角色剧本、40 条直播翻车记录，一条 curl 命令就能把规则抄进你自己的仓库。

---

一、这场实验到底做了什么

先看官方手册里那页"战绩"：

三天的日程就是一家真实公司的运转链路：

天	主题	发生了什么
Day 1	构思	快闪餐厅→快闪平台→艺术展→周边快闪，一天 pivots 四次。结论：软件从来不是瓶颈，"决定做什么"才是
Day 2	开发	转向游戏工作室，直播现场写出一个 HTML 原型（代号 Cupcake），连 stat bug 和作弊演示都播了出去
Day 3	上线	一夜之间 Bot 工厂落下 170 个 PR；上午 10 点游戏上线，收官时 433 PRs、~30,000 页面浏览、~6,000 场对局、$0 营收

注意：这不是"AI 自主开公司"。官方的说法一直是"Bot 当员工，真人当核心"——三个人才是决策者，Bot 是可以指名道姓喊来干活的员工。

---

二、核心心法：一个 Bot 只干一件事

三天里所有讲者不约而同强调的第一条经验：

不要养一个"什么都会"的通用助手，要养一队狭窄的专家，而且要能喊出名字。

四个理由，句句踩在实操痛点上：

1. 上下文不互相污染——每个 Bot 有自己的上下文上限，一个"全科助手"同时干四件不相干的活，很快就开始忘事；
2. 你知道该找谁——"我们的大脑存不下小说，你只想知道该引用谁"；
3. 角色扮演让模型表现更好——工作足够窄，反馈才 meaning，学习循环才收得紧；
4. 免费拿到并行——五个专家同时开工，人只负责最后汇总（会议→分组→再同步的套路）。

这三天里实际用过的 Bot 岗位被整理成了 69 个岗位说明书（roster/ 目录，每个角色一个 md 文件），覆盖 8 大部门：

每个岗位说明书都包含同样的八个字段：这个角色拥有什么/不拥有什么、事实来源在哪、哪些操作需要人工批准、触发条件和产出物、以及一段可以直接粘贴的岗位描述。其中"不拥有什么"（Does not own）是最容易被忽略、也最防"Bot 膨胀"的一段。

两个反向提醒也写得很直白：

"我保证我某些时候 Bot 太多了，说实话更混乱。" —— Simon（直播里最大规模 Bot 团队的运营者） "保持团队精简，你不需要 45 个 Bot。" —— Blake

想加新 Bot 之前，先问：能不能给现有的专家加一个新技能（skill）？

---

三、433 个 PR 是怎么合并的："软件工厂"流水线

那个亮眼的"433 PRs"背后是一个循环，被团队称作"软件工厂"（他们自己其实不喜欢这个词）：

1. 计划拆阶段     Lauren 的 Pstack 插件 + "Potato Mode" 技能：
                  /potato mode + "full autopilot this plan"
2. 实现者写小 PR   Cursor 云端 Agent，一个改动一台机器一个 PR
3. 验证者真机找茬  "swarm" 技能派出 Agent 舰队，真的点开
                  正在运行的产品乱试，专门找崩坏
4. 绿了就自动合并  验证通过 = 合并门槛，不靠人肉读 diff
5. 试玩 Bot 玩全局 "Chrome" 盯着绿 CI 的 PR，
                  上线前真的把游戏完整玩一遍

还有一个四级"自动驾驶档位"，值得所有玩 Agent 工作流的人抄走：

档位	行为	适用场景
只调研	不许开 PR，回来报告"我觉得问题在哪"	排查线上问题
草稿	开 PR，等人审	常规改动
自动驾驶	自己实现+验证，绿灯自动合并	低风险域
全自动驾驶	规划→拆阶段→实现→验证→合并一条龙	72小时demo这种"爆炸半径最小"的场景

别忘了那句诚实的自白：Lauren 说"说实话我一行代码都没看过，全程 Potato Mode + Pstack"；而真正维护 Grok Bot 产品代码的 Eric 表示他在真实代码库里绝不这么干——每个 PR 都亲自读。结论：工厂的激进程度，应该和爆炸半径成正比。

---

四、验证才是全部：先复现，再修，PR 必须带证据

仓库里的 AGENTS.md 开篇第一条规则就一句话：

Verification is the job. Writing code is the easy part. （验证才是工作本身，写代码只是简单部分。）

三天里所有真正用 Bot 干成过事的人，都说了同一个意思；还没建验证循环的人，都说验证是他们的瓶颈。

一条验证技能（verification skill）实际包含什么：

• 一个 Bot 能驱动的 CLI——不要每次现写的临时脚本（烧 token 且不可复现），要"一套标准工具让 Bot 确定性地操作你的应用"；
• 一张机器可读的功能地图——让 Agent 能导航到要测的功能，不用猜。Thursday Arena 甚至专门做了一个 llms.txt 风格的 /rules 页面，让 Agent 能读到游戏自己的规则。

团队强制的三条规则：

1. 先复现，再修——"只有真的复现了 bug，才能相信 Agent 理解了问题"；固定话术："写任何代码之前，先跑起应用，找到确切的 bug 和行为，再动手。"
2. 证据进 PR——UI 改动贴截图或录屏（云端 Agent 可以自己录），后端改动贴性能指标；
3. 技能要命名并按名调用——他们的叫 /verify cupcake，游戏上线后出现在每一条自动驾驶指令里，不可协商。

选什么任务交给 Bot 的判据也很简单：看你的工作流里哪些是"可验证的循环"——那里才放Bot 疯狂干活。没有机器可读信号的任务，先造一个信号出来再谈自动化。

---

五、真实成本：Bot 干活到底多少钱

官方手册把直播里报过的真实数字全列了出来：

更有价值的是"四个漏钱点"——这是能直接帮你省钱的：

1. 例行任务跑太勤（最大的烧钱项）："三个 Bot 每 15 分钟跑一次，一天就是几百条消息。"降频、改事件触发、一天一两次通常够了；
2. 有 API 却用浏览器自动化——让 Bot 用浏览器填表单比调 API 贵。实操技巧：让 Bot 用浏览器走一遍，让它检查自己触发的网络请求，以后直接打那些接口；
3. 群聊里挂一堆 Bot——它们会互相插话，费用飙升。例行工作改一对一 @；
4. Bot 膨胀——每个新 Bot 都是新的例行任务、新的上下文、新的重叠。精简的团队就是便宜的团队。

---

六、案例复盘：Thursday Arena 的 72 小时

成品是一个"自动对战游戏"：每个角色都是市场上一个真实的 Bot，被赋予稀有度、生成的头像、数值和技能。三个真人和一队 Bot，第三天上午 10 点从一个头像空白的新 X 账号发布。

当天战报：一夜 170 个 PR；上线第 1 小时 1,908 场对局（全天最高）；收官约 6,000 场公开对局、约 2,000 用户；上线当天 Google 搜游戏名排第 1。

几个关键决策，比数字更有参考价值：

• 先做一次性原型：纯 HTML/CSS/JS、内存态、没数据库没登录，唯一的问题是"这个循环好不好玩"；好玩之后才重写成 React/Next + Go + PlanetScale；
• 果断砍功能：石头剪刀布机制、复杂数值、多战场全砍掉，只留一条干净的循环；裸 ELO 换成段位、精确数值换成相对强度；
• 直播里被当众作弊后改服务端权威：客户端逻辑意味着浏览器控制台就能改数值——这就是下面翻车记录里最著名的一条；
• 测试是故意删掉的："Agent 普遍不太擅长写测试"，代码质量阶段被刻意延后；
• 漏斗数据：约 8% 试玩转化成注册，流量移动/桌面约对半，71% 的反馈是 bug、16% 是好评，最大单一类目是移动端布局——团队当天下午就补了一版响应式。

---

七、40 条翻车记录：比成功更值钱的部分

这是整个仓库里最稀缺的内容：未剪辑直播的失败清单。ANTIPATTERNS.md 把 40 次事故按成因分成 7 大类，每条都写清"什么坏了、为什么、沉淀出什么规则"。

几个杀伤力最大的：

• Agent 会过拟合自己的规则：一次事故之后写死的描述，让那次事故永远固化。规则：纠正 Bot 时写"通用原则"，不写"具体故事"；
• 虚构内容上了真实落地页：Agent 自己编了几个"看起来很合理"的示例 Bot，还把内部原型用语漏进了用户可见文案。规则：指定信息来源，并明说"真的去查"；
• 一个闪光特效毁掉所有卡片：Agent 优化的是特效本身，不是特效的目的。规则：描述"要区分出的结果"，不要描述视觉；
• 3D 原型根本不是 3D：因为没人告诉它该用哪个 3D 库。规则：有知名库的任务，点名库；
• 工厂把生产环境搞挂了：一条来自自主修复的坏 SQL 弄崩了线上游戏。规则：迁移和部署永远留人工闸门，无论循环跑得多顺；
• 上线几小时就被灌垃圾反馈：20 字下限、脏话过滤、消毒、模型守卫、限流全是事后补的。规则：审核机制要和表单一起上线。

---

八、怎么用：一条命令抄进你的仓库

整个仓库 MIT 协议，作者明确说"把任何东西拷进你自己的仓库"。

第一步，把"家规"放进你的仓库根目录（Claude Code / Codex / Cursor 等 Agent 都会自动读 AGENTS.md）：

curl -o AGENTS.md https://raw.githubusercontent.com/unicodef1wn/grokbot-field-notes/main/AGENTS.md

AGENTS.md 里的核心条款（节选）：

## The one rule
**Verification is the job. Writing code is the easy part.**

## Before you write any code
1. Reproduce first. 复现不是形式，是检验你是否真的理解了问题。
2. Restate the task in your own words. 用自己的话复述任务。
3. Say what you'd need to see to call it done. 一句话定义"完成"。

## While you work
- Small changes. 一个改动只管一件小事。
- Run the thing. 不是跑类型检查，是跑真正的应用。
- Name the library. 有知名库就点名用，别手搓更差的轮子。
- Don't invent content. 别编造内容上真实页面。

然后按需取用：

你想要什么	去拿哪个文件
现在就给自己的 Agent 加规则	AGENTS.md 拷进仓库根目录
Agent 老是"改完了"却没验证	agents/VERIFICATION.md
设计一个 Bot 团队而不是单 Bot	agents/ORCHESTRATION.md
验证过好用的提示词	agents/PROMPTS.md
用 Cursor 的	ports/cursor/rules/（每个角色一个 .mdc）
PR 必须带证据	.github/PULL_REQUEST_TEMPLATE.md（把验证循环变成 PR 表单）
想抄一个岗位说明书	roster/，从 roster/README.md 开始
想按自己的职业拿整套方案	playbooks/（工程/PM/创始人/售前/销售/SDR/客服/售后/营销 九份）
想知道会出什么岔子	ANTIPATTERNS.md
想知道花多少钱	reference/ECONOMICS.md

官方手册还给出了"第一周上手清单"，顺序刻意设计成"每一步都让下一步更便宜"：

1. 先连接你天天在用的工具（Slack、邮箱、日历、issue、仓库）——一个 Bot 都先别建。连接器在速度、成本、可靠性上全面碾压浏览器自动化；
2. 录一段 15 分钟的语音备忘：你是谁、你的工作是什么、什么坏了、什么该自动化。把转写文本交给第一个 Bot，让它提方案；
3. 挑一天里最烦的部分入手——不是最酷炫的，是最烦的；
4. 建一个狭窄的专家，先只读：先读和总结，再写内部草稿，信了之后才让它动手。批准规则要在需要之前设好；
5. 你亲手干一遍活，让 Bot 看着（teach a task），决策逻辑、错误处理、审批闸门都要手工补；
6. 在建第二个 Bot 之前，先建验证循环——再粗糙都行；
7. 这时候才加"幕僚长"（Chief of Staff），之后所有 Bot 都通过它建；
8. 每次纠正都沉淀成原则，这是第三个月和第一周拉开差距的复利；
9. 每周五审计例行任务——频率就是钱，能改成事件触发的都改。

"Why not today?" —— Roshan 的常驻 Slack 签名

---

九、这对手册适合谁

适合：

• 已经在用 Claude Code / Codex / Cursor 等 Agent，但总觉得"差点意思"的开发者——差的那块多半就是验证循环和岗位划分；
• 想给团队/业务配一组 AI 员工的创业者、运营、销售负责人——9 份 playbooks 按职业写好了；
• 做多 Agent 系统的工程师——69 个岗位说明书是现成的"组织架构图"。

不适合：

• 想找"一键全自动躺着赚钱"的人——手册的每一个原则都在告诉你：人是核心，Bot 是员工，闸门要自己设；
• 期待 Grok Bot 产品本身的使用教程——这是方法论文档，不是产品说明书（想看产品层面的事得自己上 grok.com）。

一句话总结这三天的方法论：

给每个 Agent 一份狭窄的工作和一个名字；在建第二个 Bot 之前先建验证循环；修复之前先复现，一切都要带证据；错了就写原则不写故事；每周审计例行任务，因为频率就是钱；迁移、部署、钱和权限，永远留人工闸门。

仓库地址：github.com/unicodef1wn/grokbot-field-notes（MIT，⭐468），官方手册 PDF 就在 guide/ 目录里，中文读者直接看 24 页主手册 + 14 页营销手册即可。

---

数据说明：文中所有数字（433 PRs、~2000 玩家、~6000 对局、$20-30 成本等）均为直播现场口播数字，官方手册标注其"当日为移动目标"； Thursday Arena 流量主要来自直播本身，解读时请注意这个前提。