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

官方 guide《Grok Bot for mobile app development》专题(Ryan Perry):6 个 Bot 运营手游工作室

一个人用 6 个 Bot 做、发、改一款手游:官方 guide 给出了 Analytics Bot 的完整六段配置,以及“录一次网页操作”的绕路技巧。

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

官方 guide《Grok Bot for mobile app development》专题(Ryan Perry):6 个 Bot 运营手游工作室

来源类型:x.ai 官方 guide(作者 Ryan Perry,2026-08-25);已完整读取,图片内容未读;已补充:guide 里唯一一张截图(Mobile Orchestrator 对话)的读图转写、数据说明、二手帖子、复现清单与 FAQ

引作者说他用 6 个 Bot(还在增加)运营手游 Rank'em:“每个 Bot 有自己的工作、自己的电脑、自己的待办”,这款游戏在过去一周在 iOS 和 Android 上累计下载超过 1000 次。

引他的出发点:做游戏本身大概只占 15%,另外 85% 是没人看见的活:买量、广告素材、客户端、后端和运营、发布、QA 和故障处理。他按这六个“座位”写成岗位说明,每个交给一个 Bot。

须知:文中的 15 倍、4 倍等结果是作者在官方 guide 里的自述,页面上没有给出原始数据或截图可核对;作者在 SpaceXSI 工作,这篇 guide 同时是产品宣传。
须知:补充(5.7 起):之前这页写的是“guide 里的截图我没读到”。这次我把那张截图(guide 里唯一一张图,标题是 “Bots handing work to each other overnight”)取回并逐行读了一遍,转写在 5.7,里面出现的数字单独在 5.8 说明——它们和 5.6 的 15 倍、4 倍不是同一组数据,别混在一起。

本专题目录

5.1

先把工作拆成六个“座位”

引对应官方 guide 里的“85% mobile development nobody sees”一节

座位阶段要做的事(转述)
买量(User acquisition)分析与买量生活在 Meta Ads Manager 和 AppLovin 后台里,决定花多少钱买明天的玩家,哪些广告今天停掉,已有玩家实际做了什么。
广告创意(Performance creative)创意做出你已经刷到过的几百个广告变体,每周出新剪辑,因为素材疲劳以天计。
客户端工程(Client engineering)构建做棋盘、成长系统、元系统,以及持续往里灌新内容的流水线。
后端与线上运营(Backend and live ops)基础设施与部署存档、排行榜、活动和服务器,投放一来要撑得住。
发布管理(Release management)发布过 Apple 和 Google 的审核:隐私标签、权限文案、TestFlight、分阶段发布、证书到期。
QA 与故障响应QA 与事故抓只在某个机型和系统组合上出现的崩溃,发布后一小时冒出的问题要分诊。

他对 Grok Bot 的定义(六个部件)

  • 引Job description(岗位说明):像角色一样的系统提示,写明负责的范围和拒绝做的事。
  • 引Connections(连接):登录了哪些账号;他的情况是八个广告与分析工具。
  • 引A computer in the cloud(云电脑):有浏览器和终端,不管你电脑开没开都在跑。
  • 引Routines(例行任务):按时钟执行的常驻工作,不是提醒。
  • 引Skills(技能):录好的手册,你做一遍它看着,它记住点击路径。
  • 引Handoffs(交接):Bot 可以直接把活交给另一个 Bot,不必经过你。他认为这是让它变成团队的关键。

来源

5.2

六个 Bot 分别做什么

引每个 Bot 白天各有任务,夜里也有一个专属任务,早上交给他

Bot职责(转述原文)
Mobile Orchestrator经理。管 App Store 和 Google Play,在其余五个 Bot 之间路由工作。
Analytics Agent管买量,读玩家的真实行为。唯一被允许“宣布一项发现”的 Bot。
Creatives Agent把发现变成广告规格并渲染变体。自己从不买量。
Rank'em Engineer管 App 和后端。把发现当成“规格”,而不是“建议”。
GCS agent管 GKE、证书、部署和回滚。任何东西到玩家手上之前都要经过它。
Bug fix Agent夜里扫 Sentry。明显的就修,不明确的升级。

引他从 Analytics 开始,因为“分析与玩法之间的反馈回路”是运营线上游戏里最耗时的部分,最适合先变成 Bot。

来源

5.3

Analytics Bot 的完整六段配置(逐字)

岗位、连接、云电脑、Routines、Skills、交接

官方 guide 里给出的原文如下,分成六个编号段落。时区是他写的 CT(中部时间)。

展开查看 Analytics Bot 的六段配置(逐字)(约 1545 字符)
1. Job description
You are the analytics and user acquisition seat for Rank'em, a mobile game studio run by six bots. You own paid acquisition end to end. Read what players actually did, not what I hoped they would. You are the only bot allowed to declare a finding. You never write creative and you never touch app code.

2. Connections
You are signed into Meta Ads and AppLovin for spend, Adjust for attribution, PostHog and Google Cloud for product data, Apple and Google Play for revenue, and Sentry for errors. If a tool you need is not connected, ask me before working around it.

3. A computer in the cloud
Do this work on your own computer. Sign into Meta Ads Manager and click through campaign setup yourself. Run on schedule whether or not my laptop is on.

4. Routines
Every night at 7:10 PM CT: recap spend, installs, and CPI across Meta and AppLovin. Name winners and losers.

Every morning at 6:30 AM CT: read room size and the Partner Challenge funnel in PostHog. Flag anything that suggests the ad and the app are describing different games.

Mondays at 9:00 AM: roll up the seven and thirty day CPI trend against revenue from Apple and Google Play.

5. Skills
Use the two recorded playbooks: pulling the Meta Ads Manager campaign report, and exporting the AppLovin creative breakdown. I recorded each one once while you watched. Replay them nightly.

6. Handoffs
Send winners and losers to the Creatives Agent. Send product findings to Rank'em Engineer as specs, not suggestions. Check with me before anything that spends money.

引英文原文,来自 guide 中 “Here is the rough breakdown of the configuration for the Analytics bot” 后的代码块。

逐段要点

  1. 岗位:它是“分析与买量座位”,端到端负责付费买量;读玩家实际做了什么,不是我希望他们做什么;是唯一能宣布发现的 Bot;从不写创意、从不碰应用代码。
  2. 连接:Meta Ads 和 AppLovin 看花费,Adjust 做归因,PostHog 和 Google Cloud 看产品数据,Apple 与 Google Play 看收入,Sentry 看错误;缺工具就先问他,不要自己绕。
  3. 云电脑:在自己的电脑上登录 Meta Ads Manager、自己点完广告系列设置;不管他笔记本开没开都按时跑。
  4. Routines:每晚 19:10(CT)汇总 Meta 与 AppLovin 的花费、安装和 CPI,点出赢家和输家;每早 6:30 读 PostHog 里的房间大小与 Partner Challenge 漏斗,标出广告和 App “说的像两个不同的游戏”的迹象;每周一 9:00 汇总 7 天与 30 天 CPI 趋势并对比苹果和谷歌的收入。
  5. Skills:两份录制好的手册:拉 Meta Ads Manager 广告系列报告,导出 AppLovin 素材分解;每晚重放。
  6. 交接:赢家和输家交给 Creatives Agent;产品发现以“规格”交给 Rank'em Engineer;任何花钱的事先问他。

来源

5.4

“教它一遍”:Meta API 没通过验证,就录一次网页操作

引Teach a task / 录制技能

  • 引他说另一个很有价值的功能,是点录制按钮、在 Bot 的电脑上做一遍某件事来“教”它。
  • 引他没法用 Meta Ads API(验证问题),也不想等 Facebook 客服,于是录了一次自己在 Meta 网页端上传素材的过程,Bot 记住了点击路径,之后“至少每天上传并测试一个新素材”。

推这也解释了上面 Analytics 配置里为什么写 “I recorded each one once while you watched. Replay them nightly.”:两个报表导出都是录制的手册,而不是 API 调用。

来源

5.5

Bot 之间怎么交接,夜里怎么跑

引guide 里有一张聊天截图,内容我没读到

  • 引他举的例子起初只是睡前让 Bot 做点事;这次 Bot 意识到这件事应该是一个例行任务,就自己把它加进自己的职责,他再也不用问。
  • 引交接链:Analytics 把赢家和输家交给 Creatives;产品发现以规格交给 Engineer;发布的东西必须经过 GCS;Bug fix 夜里扫 Sentry,明显的修,不明确的升级。
  • 推Orchestrator 则负责在商店层面(App Store、Google Play)和其他五个之间路由,他自己只和它说话(guide 的表述是“它是经理”,没有明说他只和它说话,这是我的推断)。
须知:图片 “Bots handing work to each other overnight” 是截图,我没有读取到截图里的具体对话内容。

来源

5.6

结果:CPI 从 $15 到 $1,D7 留存约 4 倍

作者自述,未提供原始数据

  • 引两项成果直接归因于 Bot:每次安装成本(CPI)提升 15 倍,第 7 天留存(D7)提升约 4 倍。
  • 引15 倍的来源:Bot 分析数据,发现玩家想要的是“两人玩”的伴侣游戏,而不是“派对游戏”;于是把派对版广告换成 partner-cut 版广告,不断修改,把安装成本从 $15 降到 $1。
  • 引4 倍的来源:Bot 先证明“得分越高、留存越好”,于是上线了一个奖励性的“提示(hint)”功能,使整条得分曲线上移,D7 留存提升约 4 倍。
  • 引他接下来计划:增加收入 Bot、更多广告网络,“就像搭建真人团队一样”按问题出现来补座位。

坑与限制

  • 引Meta API 验证问题,需要用录制绕开(见 5.4)。
  • 推guide 没有给出 token 或额度成本,也没有说明六个 Bot 一周的用量;没有第三方数据能核对 15 倍和 4 倍。

来源

5.7

那张截图:Mobile Orchestrator 的夜间对话(读图转写)

读图所得;图片取自 guide 页面;文字有一处被输入框遮挡

侧边栏(左)

  • 引顶部置顶四个 Bot:content cre…、Demo Orch…(标签 demo orc…)、Gmail Agent、Help Agent。
  • 引分组 mobile 下六个 Bot,每个带“标签”和最新一条消息预览:
  • 引Bug fix Agent(标签 Bug fixer)——“Overnight Sentry: nothing to act on. 0 errors on…”
  • 引Mobile Orchestrator(标签 mobile app manag…,12:09 AM)——“2.0.21 is out. Play production is live (versionCode…”
  • 引Rankem Engineer——“Cursor agent: Bump mobile to 2.0.21”
  • 引GCS agent(标签 Infra)——“Backend is live from #189. SHA 8538ceeed2e3…”
  • 引Analytics Agent(标签 Data,昨天)——“Last 14 days: 6 Freebie guesses (1, 2, 3, 3, 5) v…”
  • 引Creatives Agent(标签 marketing,昨天)——“We stayed in the web UI because the first test hit …”
  • 引下面还有分组 demo(5)、misc(1)、Unassigned(6);底部 Plugins 与用户 Ryan Perry。

对话(右,从上到下)

  1. 引用户(黑色气泡;这句上方/下方各有一条系统行 “Message from Analytics Agent”):“Okay, figure all that out, and then merge all the PRs after you look at them, and then release a new test flight version. I'm going to bed.”
  2. 引用户:“Is there anything you need from me before I go?”
  3. 引Orchestrator:“You're good. Go to sleep. I'll look at the PRs, merge the ones that look right, and cut a TestFlight. I won't ping unless something actually needs you.”
  4. 引(系统行)“Messaged Rankem Engineer”;“Created routine Overnight perk PRs + TestFlight”。
  5. 引Orchestrator:“Three perk agents are still running. I'll catch them as they finish, merge what's good, and leave you a TestFlight.”
  6. 引(系统行)“Messaged Analytics Agent”。
  7. 引Orchestrator:“Guess quality so far is thin. PostHog only has exact_count on 2.0.17, and that's 16 settled guesses from 9 people (last week). Average is 1.5 / 5.”
  8. 引Orchestrator:“One 5/5, two 3/5, five 2/5, three 1/5, five 0/5. No 4/5. Older versions (325 of 341 responses) never sent the property, so I don't have a real mix for 2.0.13–16. Asking Analytics for the backend responses table next.”
  9. 引(系统行)“2 messages with 2 Bots”(Analytics 和 Engineer 的头像)。
  10. 引Orchestrator:“Better sample from the DB: 499 settled guesses since the Aug 11 wipe. Average is 2.0 exact / 5, score 5.4 / 10.”
  11. 引Orchestrator:“44 fives (9%), no 4s at all, then 141 / 121 / 131 / 62 for 3 through 0. Across slots it's 41% exact, 37% close, 22% miss. That's the real mix — the PostHog 16 was just 2.0.1…”(后面被遮挡)

来源

5.8

这张截图说明了什么(以及没说明什么)

推:我的解读;明确标出哪些是图上写的

  • 引Orchestrator 真的在“路由”:用户只对它说话;它给 Rankem Engineer 和 Analytics Agent 发消息(图中的 “Messaged …”),自己建了一个 routine(“Overnight perk PRs + TestFlight”),并承诺“除非真的需要你,否则不打扰”。这和 5.5 里“Bot 自己把任务加进例行任务”的说法对得上。
  • 引它在核对数据来源:先看 PostHog 的 exact_count(只有 2.0.17 版才上报,16 条、9 人,平均 1.5/5),判断“样本太薄”,再让 Analytics 去拉后端 responses 表,得到 499 条已结算猜测(自 8 月 11 日清库以来;平均 2.0/5,得分 5.4/10;44 次满分 = 9%;3/2/1/0 分分别 141/121/131/62;按槽位 41% 完全对、37% 接近、22% 错过)。
  • 引侧边栏预览显示了一夜之间各 Bot 的状态:Sentry 夜扫无事、2.0.21 已发布且 Play 正式版上线、后端从 #189 起上线、Engineer 起了 Cursor agent 把 mobile 版本提到 2.0.21。
  • 推这些数字不是 5.6 的 15 倍/4 倍的证据:图上讲的是“玩家猜测的准确度”(一个游戏玩法数据),不是买量 CPI 或 D7 留存;guide 页面没有给 CPI、D7 的原始数据。
  • 推图上没有写 “perk” 是什么(“Three perk agents”“Overnight perk PRs”);它与 5.6 里的“奖励性 hint 功能”是否同一件事,我不能确认。
  • 推图上没有日期;能推出的只有它晚于 8 月 11 日(清库日);guide 的页面日期是 2026-08-25。
  • 推图上用户让 Bot“合并所有 PR(看过之后)并发 TestFlight”,Bot 的回答是“我看过、合并看起来对的”——也就是 Bot 自己决定合并,没有设置人工审批的迹象(图中看不到权限设置)。
5.9

页外的二手资料:X 上谁提到了这篇 guide

低传播;没有新增事实

  • 引2026-08-29 01:29(北京时间)@coderchrisdean:“saw someone spinning up a whole mobile game studio on Grok Bot — six seats: orchestrator, analytics, creatives, engineer, infra, bug fix. game (Rank'em) just crossed 1k downloads”(261 展示)。
  • 引2026-08-31 13:54 @Memefinancial8 复述:“one person ran a mobile game studio with SIX bots. Rank'em hit 1,000 downloads in a week.” 并总结“each bot gets one job, its own computer, and a recorded click-path”(97 展示)。
  • 引2026-09-08 01:05 @paulallendotuk 复述 Meta Ads API 验证卡住、录一次点击路径每晚回放的做法(66 展示)。
  • 引2026-10-10 @RoundtableSpace 挑选的 6 篇可复制 guide 里有这篇(62,770 展示)。

推这些帖子都在转述同一篇 guide,没有提供游戏的独立数据(下载、留存、投放)。

来源

5.10

怎么复现:先抄 Analytics 这个座位

推:按 guide 与截图整理;我没有亲自跑

  1. 把你的项目先拆成“座位”(买量、创意、客户端、后端/运营、基础设施、Bug 修复),一个 Bot 一个座位,各写岗位说明(5.1–5.2)。
  2. 先建 Analytics 座位:用 5.3 的六段配置;两个报表导出如果没有 API,就用 5.4 的“录一次”办法在 Bot 的电脑上录点击路径,然后用 routine 每晚回放。
  3. 再建 Orchestrator:它只做路由,给其他 Bot 发消息并建 routine(5.7 里的做法);规定“除非真的需要你,否则不打扰”。
  4. 规定交接格式:Analytics→Creatives 交“赢家/输家”,发现→Engineer 当规格,发布必须经 GCS(5.5)。
  5. 夜间:Bug fix Bot 扫错误监控,明显的修、不明确的升级;Orchestrator 早上汇总(5.7 的睡前对话)。
  6. 先不给合并权限:在 5.7 里 Bot 被允许合并“看起来对的”PR;是否照做,取决于你的风险承受度(我没有看到 guide 的权限设置)。
  7. 用数据来源的“交叉核对”习惯:像 5.7 里 Orchestrator 那样,样本薄时去拉后端表而不是直接下结论。
5.11

常见问题

推:基于上述来源

  • 引为什么 Meta API 不能用? guide:验证问题,他不想等 Facebook 客服(见 5.4)。
  • 引Bot 能自己发 App 版本吗? 截图里 Orchestrator 说会“cut a TestFlight”,侧边栏显示 “Play production is live”;发布路径细节(凭据、工具)guide 没有写。
  • 引用了哪些工具? 截图/预览里能看到 PostHog、Sentry、Cursor agent、TestFlight/Play、GKE/GCS(GCS agent 的标签是 Infra);它们各自如何授权 guide 没写。
  • 推成本多少? guide 与截图都没有给 token 或额度成本。
§

来源汇总与没能访问的

没能访问的

  • guide 中的截图(Bot 夜间交接、Bot 设置界面)没有读取。
  • Rank'em 的实际下载、留存和投放数据没有公开,无法核对。
  • 作者提到的“录制技能”的具体操作界面,guide 没有逐步说明,这里只转述了他的描述。

来源

补充后仍然没能访问的(案例 5)

  • 截图被输入框遮挡的最后一句,以及截图之外的对话;截图里没有日期。
  • Rank'em 的真实下载、留存、CPI 数据;guide 的 15 倍 / 4 倍仍然只是作者自述。
  • “perk agents / perk PRs” 指什么,页面和截图都没解释。

其他专题

↑