Grok Bot 移动开发指南：六个 Bot 怎样运营 Rank’em 游戏工作室
从获客数据到广告素材、游戏机制、部署与错误巡检，理解长期运行的团队交接。
在当前的辅助编程工具帮助下，用自然语言写出一个类似 Wordle 或消除类游戏的可用原型已经不再困难。但在开发者 Ryan Perry 看来，依照其在移动游戏领域的从业经验，写出游戏主程序往往只占总工作量的 15% 左右。
真正消耗大量精力、甚至决定产品生死的是那被忽视的 85%：在 Meta Ads 和 AppLovin 等买量平台中持续监测单次安装成本（CPI）、每几天就要更新一批以防老化的广告素材切片、跟进 PostHog 与埋点数据核实真实玩家行为、维护存档、排行榜、活动与服务器、处理苹果与谷歌应用商店繁琐的提审资质与证书轮转，以及半夜排查特定系统版本上的偶发崩溃。
曾就职于 Sensor Tower 与 Lion Studios（AppLovin 旗下）的移动游戏开发者 Ryan Perry，在运营其手机游戏 Rank'em 时，通过 6 个常驻的 Grok Bot 搭建起一套分布式虚拟工作室。作者发布相关经验时，该游戏在过去一周内跨 iOS 与 Android 双平台的下载量刚超过 1,000 次。这套系统并不是在对话框里临时提问，而是让每个 Agent 拥有独立的云端环境、定时工作流以及彼此直接交接工作的能力。
Grok Bot 的六大基石：常驻智能体与临时对话框的本质区别
在常见的工作流中，大语言模型往往是一个「用完即走」的聊天窗口：你必须主动打开网页、把上下文复制进去、等待结果，再把结果手动粘贴到下一个系统。Grok Bot 在设计上更接近一个具备固定职责的长期协作者，其运行体系建立在六个核心支柱上：
- 岗位描述（Job Description / 职责边界）： 不同于宽泛的「你是一个资深专家」设定，每个 Bot 的系统提示词像一份严密的岗位说明书。它不仅界定当前席位全权负责什么，更关键的是明确写出它「严禁插手什么」。职责收窄是多智能体协同不陷入混乱的前提。
- 系统授权（Connections / 接入的账号）： Bot 直接绑定其工作所需的应用账户（如 Jira、GitHub、Meta Ads Manager、PostHog、Sentry 等）；缺少工具需先向人类确认。但缺少权限仅限制其操作范围，并不意味着模型不会产生幻觉去编造数据。
- 云端独立电脑（A Computer in the Cloud）： 每个 Bot 分配有一台带有独立浏览器与终端的云端虚拟主机，无论使用者的电脑是否开机都能运行。这是作者自述的运行配置，并不等同于系统层面的完全权限隔离保证。
- 例行惯例（Routines / 定时任务）： 这是常驻工作的核心触发器。它不是手机上的闹钟提醒，而是挂载在 Bot 自身日程表上的定时作业（如每日特定时刻自动复盘买量指标、抓取错误日志），无需人工登录后台点击触发。
- 示教录制技能（Skills / 动作回放）： 面对没有开放 API、接口申请受阻或界面权限极度繁琐的第三方平台，使用者可以直接在 Bot 的云端电脑上点击「录制」，亲自在网页界面操作一遍。Bot 会记录完整的点击流路径与输入节点，将其固化为一项可反复重放的技能。
- 自主交接机制（Handoffs / 跨席位流转）： 这是让独立 Agent 凝聚为工作组的核心机制。Bot 在完成阶段性产出后，可以直接将结论与制品传递给下一个对应席位的 Bot，而不需要人工充当中继路由。
原文还将移动游戏工作拆成六类传统岗位：买量分析、效果创意、客户端工程、后端与线上运营、发布管理、QA 与事故处理。其中，发布管理包括隐私标签、权限文案、TestFlight、分阶段发布与证书；QA 要留意只在特定设备与系统组合出现的崩溃，以及发版后的错误峰值。这些职责解释了作者所说的“游戏之外的工作量”。
六个虚拟席位的分工矩阵与权限红线
工作室设置了 6 个明确的 Agent 席位，以岗位说明书形式界定职责：
- Mobile Orchestrator（工作室总管）：
- 职责定位： 担任管理者，掌管 App Store 与 Google Play，并在其他 5 个 Bot 之间分发与协调工作。
- Analytics Agent（数据分析与买量监控）：
- 职责定位： 端到端掌管付费买量，审视玩家在游戏内的实际行为；全团队唯一被允许对业务现状定论（Declare a finding）的席位。按其系统提示词不撰写广告创意、不改动应用代码。
- Creatives Agent（广告素材生产）：
- 职责定位： 将数据发现转化为广告规格并渲染变体切片，但自身从不采买媒介。
- Rank'em Engineer（客户端与后端研发）：
- 职责定位： 掌管客户端与服务端代码，将数据分析得出的结论视为硬性技术规格（Spec）而非随意参考的建议进行开发。
- GCS Agent（集群运维与部署）：
- 职责定位： 掌管 GKE 集群、证书、部署与回滚，所有内容必须经过它才能触达玩家。
- Bug fix Agent（夜巡修复）：
- 职责定位： 彻夜扫描 Sentry 错误日志，负责修复显而易见的明确缺陷，遇到非显而易见的问题则向上升级。
岗位与业务案例按作者实践整理，收益为作者自报；具体合并、发布与花费授权由自己的团队配置。
六席位 Bot 协同矩阵与业务流转演示
直观拆解 6 个常驻 Agent 的权限边界、云端环境与交接逻辑，查看数据如何驱动素材换代与玩法更新。
拆解核心提示词：如何配置一个有边界的数据分析席位
在整个体系中，数据分析与业务开发之间的反馈链路最耗费人力，因此 Analytics Agent 是最先被固化下来的席位。以下为按照该工作流逻辑梳理的中文配置参考，工具字段提供替换位置，原文的 7:10 PM CT、6:30 AM CT 与周一 9:00 AM 则保留为作者示例时间：
# [按本篇工作流改写的配置示例：数据与买量分析席位]
## 1. 岗位描述（Job description）
你负责 [项目名称] 的数据分析与买量获客席位。你端到端掌管付费买量与用户行为分析。
你的核心任务是审视玩家在游戏中「实际做了什么」，而不是主观假设「期望他们做什么」。
【核心约束】你是团队中唯一允许对数据结论「正式定论（Declare a finding）」的席位。
你严禁撰写广告创意素材，严禁触碰或修改任何应用端及服务端代码。
## 2. 工具连接（Connections）
你已授权接入以下服务：
- 买量平台：[Meta Ads / AppLovin 等投放控制台]
- 归因与埋点：[Adjust 归因后台 / PostHog 行为分析]
- 基础设施与财务：[云平台数据仓库 / 苹果与谷歌应用商店财务报表]
- 监控告警：[Sentry 错误收集系统]
【规则】如果发现缺少某个分析工具的访问权限，严禁自行猜测数据或绕过检查，必须向人类请求补齐配置。
## 3. 云端工作环境（A computer in the cloud）
使用为你分配的独立云端主机执行任务。你可以通过内置浏览器访问控制台并操作报表导出。
按计划定时执行例行作业，不依赖人类终端是否在线。
## 4. 例行任务（Routines）
- 每晚 7:10 PM CT（美国中部时间，可按需自行换算时区）：自动汇总 Meta Ads 与 AppLovin 的支出、新增安装量与 CPI，列出胜出与落败的广告组。
- 每晨 6:30 AM CT：在 PostHog 中读取房间人数（room size）与 Partner Challenge 漏斗，标记任何显示「广告宣传与游戏实际内容不符」的异常信号。
- 每周一 9:00 AM：拉取 7 天与 30 天的滚动 CPI 趋势，对照 Apple 与 Google Play 的实际收入完成投产比汇总。
## 5. 示教技能（Skills）
回放以下已录制的标准操作路径：
1. 买量后台自定义数据报表提取流程。
2. 广告平台创意维度转化分解导出流程。
严格按照示教时记录的点击路径重放，定期提取并校验数据源。
## 6. 任务交接与权限卡点（Handoffs）
- 将广告维度的胜负分析结论直接移交给 [素材制作席位 Creatives Agent]。
- 将产品机制与漏斗断点结论整理为正式技术规格（Spec），直接移交给 [研发席位 Engineer]，而非作为口头建议。
【核心审批门禁】任何涉及追加预算、调整出价或产生真实资金消耗的操作，必须挂起等待人类明确确认。
关键机制解析：用界面示教录制上传素材
在实际操作中，作者因企业认证问题无法使用 Meta Ads API，如果等待 Facebook 客服支持会耽搁进度。
Grok Bot 的云端示教录制功能为此提供了一种替代途径：
- 开发者直接在分配给 Bot 的云端电脑上点击「Record（录制）」按钮。
- 人类亲自在 Meta Ads 网页端界面操作一次广告素材上传。
- Bot 学习并记住了该点击路径，后续部署新素材时即可在自己的虚拟桌面中自动重放该路径上传素材（作者借此维持每天至少上传测试一套新素材）。该录制是上传素材的操作示范，并非用于完整定向投放测试或任意 API 的通用绕过手段。
夜间自治与人类把关：一次完整的版本迭代
白天人类主要负责高层决策与战略评估，夜间则是 6 个 Bot 集中运转的高峰期。很多在后期演变为日常惯例的任务，最初往往始于人类在睡前发出的一句非结构化指令。系统在理解任务意图后，能够自主将该诉求沉淀为长期的固定定时作业。
上图展示了夜间协同日志的局部切片。截屏记录的是开发者睡前向调度中枢交接任务的实际片段，其中包含两份不同口径的观察样本（16 组实时竞猜与 499 组数据库样本），两者并非已验证评分稳定性的测试样本；截图也未体现完整 CI/CD 流程或 GCS 部署顺序。
团队各席位之间的核心流转关系示意如下：
- 数据转化为需求： Analytics Agent 审视玩家实际行为，将发现整理为硬性工程规格（Spec）而非随意参考的建议，交由 Rank'em Engineer 承接。
- 代码与补丁开发： Rank'em Engineer 落实机制调整；同时 Bug fix Agent 彻夜扫描 Sentry 错误日志，针对明确异常编写修复补丁。
- 夜间交接与构建： 在作者给出的夜间交接示例中，开发者在睡前明确交代让 Bot 自动完成 PR 合并并打包出 TestFlight 版本，Bot 甚至主动将临时要求固化为长期例行作业。
- 发布与环境协同： 最终由 Mobile Orchestrator 负责 App Store 与 Google Play 渠道，配合 GCS Agent 处理服务部署与回滚。
验证成果：两个业务闭环与事实边界
这套机制在 Rank'em 上的实际运转，带来了两个作者报告的业务进展：
- 营销买量维度的成本收敛：
- 原先假设： 游戏在早期投放中主打「聚会派对游戏」概念，面向多人大群组，但获客成本居高不下，单次安装成本（CPI）一度达到 $15。
- Bot 协同闭环： Analytics Agent 发现玩家多为双人搭档而非大型聚会群组，团队随即将聚会题材广告替换为双人搭档切片，将单次安装成本从 $15 降至 $1（降至原来的 1/15，降幅约 93.3%）。
- 游戏核心体验的留存修复：
- 数据发现： Analytics Agent 发现更高的对局得分与更好的留存率存在相关性（作者自述证明了分数与留存相关，而非已验证因果关系）。
- 机制迭代： 该结论作为工程规格交由 Rank'em Engineer 开发并上线了局内 bonus "hint"（加分提示）功能，平移了整体得分曲线，作者自报第 7 天留存率（D7 Retention）约为此前的 4 倍。
实践中的事实边界
在参考该案例时，需注意其自报成果的具体条件：
- 资金审批门禁： 作者在提示词中明确要求「任何涉及花钱的操作必须先向人类确认」，并未将预算与资金权限完全放开给 Bot 自治。
- 自报指标与相关性： 安装成本从 $15 降至 $1 以及 D7 留存约为此前的 4 倍均为作者自述经验，其中加分功能改善留存建立在分数与留存的相关性观察上，这段自报没有提供足以判断某个功能独立因果作用的信息。
作者的下一步是扩充收入分析 Bot 和广告网络，并继续研究游戏内收入。已有成果主要是安装成本与留存，原文尚未给出收入提升、利润或整套 Bot 成本核算，不能据此算出完整的投资回报率。
Grok Bot 移动开发：从数据发现到素材与版本迭代
Ryan Perry 运营 Rank’em 时，把买量、素材、工程、部署与排错交给六个常驻 Bot。他估计主程序只占约 15% 工作量；其余工作还包括隐私标签、证书、商店提审和设备特定崩溃排查。
六项配置：岗位边界 · 已授权工具 · 独立云端电脑 · 定时例程 · 示教技能 · 跨 Bot 交接。边界靠明确配置，独立电脑不代表完全权限隔离。
Analytics 唯一负责正式数据定论，把结论分别交给 Creatives 做素材、Engineer 作为工程规格（Spec）承接；这描述作者的岗位约定。
Grok Bot for mobile app development · Grok Bot
Six bots, one mobile game studio. How I use Grok Bot to build, ship, and improve Rank’em.
This is how I use Grok Bot to run a mobile game studio with a team of six bots (and growing). Each one has its own job, its own computer, and its own todo list, and together they build, ship, and improve my mobile game Rank'em, which just passed 1000 downloads across iOS and Android over the past week.
The 85% of mobile development nobody sees
I started my career at Sensor Tower and Lion Studios (AppLovin) studying how mobile games get built, and the lesson was always the same: the game itself is maybe 15% of the job. Especially with Claude Code, Codex, or similar tools, anyone can one-shot a serviceable clone of multi-million-dollar games like Candy Crush or Wordle today. But then they're stuck with the other 85%:
| Seat | Phase | The job |
|---|---|---|
| User acquisition | Analytics and UA | Lives in Meta Ads Manager and the AppLovin dashboard. Decides what to spend to buy tomorrow's players, which campaigns die today, and what the people already playing actually did. |
| Performance creative | Creative | Makes the hundreds of ad variants you have already scrolled past, and ships new cuts every week, because creative fatigue is measured in days. |
| Client engineering | Build | Builds the board, the progression, the meta systems, and the pipeline that keeps feeding new content into all of it. |
| Backend and live ops | Infra and deploy | Saves, leaderboards, events, and servers that hold when a campaign lands. The reason your progress survives a new phone. |
| Release management | Release | Gets the build through Apple and Google. Privacy labels, permission copy, TestFlight, staged rollout, and certs that expire at the worst time. |
| QA and incident response | QA and incident | Catches the crash that only happens on one device and OS combination, then triages the spike that shows up an hour after a release. |
What Grok Bot is
Grok Bot launched out of SpaceXSI this month. Each sidebar item is not a chat window, it's a long-lived agent. Think of each one as a DM with a coworker who has:
- Job description (who it is): A system prompt that reads like a role: the lane it owns, and the work it refuses.
- Connections (what it can reach): The accounts it is signed into. Jira, Figma, GSuite, Salesforce, GitHub, or in my case eight ad and analytics tools.
- A computer in the cloud: Its own machine, with a browser and a terminal, running whether or not yours is on.
- Routines (when it acts): Standing work on a clock. Not a reminder you set, and not something you have to open the app to trigger.
- Skills (how it does a task): Recorded playbooks. You do the job once while it watches, and it keeps the click-path.
- Handoffs (who it passes to): The ability to hand work to another bot directly, without routing through you. This is the one that makes it a team.
The last one is the one that matters. A bot that can hand work to another bot is a foundation for a team, and what really differentiates the Grok Bot experience from other knowledge-work products.
Meet my bots
I wrote six seats out as job descriptions, the way a studio would, and handed one to each bot. At the beginning of each day each bot also had a particular task it was in charge of working on overnight, so it was ready for me in the morning.
- Mobile Orchestrator is the manager. It owns App Store and Google Play, and routes work between the other five.
- Analytics Agent owns paid acquisition and reads what players actually did. The only bot allowed to declare a finding.
- Creatives Agent turns findings into ad specs and renders the variants. It never buys the media itself.
- Rank'em Engineer owns the app and the backend. It takes a finding as a spec, not as a suggestion.
- GCS agent handles GKE, certs, deploys, and rollbacks. Nothing reaches players without going through it.
- Bug fix Agent sweeps Sentry overnight. It fixes what is obvious and escalates what is not.
Building a single bot
The feedback loop between analytics and gameplay is the most time-consuming part of running a live game, so it made the best candidate for turning into a bot first. Here is the rough breakdown of the configuration for the Analytics bot:
text
Another incredibly valuable feature of Grok Bot is the ability to "teach it" a skill by hitting the record button and doing something on Grok Bot's computer.
I was unable to use the Meta Ads API because of verification issues, so rather than wait on Facebook support, I recorded myself uploading a creative through the Meta web UI once, and the bot learned and remembered the click-path for future creatives (it was uploading and testing at least one new creative per day).
The bots talk to each other
Here's an example of what now runs more autonomously as routines, but started as me asking my bots to do a little work as I went to bed.
You may notice that I asked it to do something, and on this particular night the bot realized that my request should be a routine and went ahead and added that to its own remit so I never had to ask again.
Bots handing work to each other overnight
What was the ROI?
ROI is really the name of the game, and I plan to talk about this in more detail as I do the same work on revenue generation in the app. But two wins trace directly to the bots, resulting in a 15x improvement in cost per install and a 4x improvement in D7 retention.
The bots analyzed the data, saw that people wanted more of a partner game than a party game, and kept revising the ad until installs cost 15x less.
The same feedback loop produced both wins: the bots read the data, worked together as a team to form and test a hypothesis, and:
- Swapped the party ad for the partner-cut ad after data showed people were playing as couples rather than large groups, taking installs from $15 to $1.
- Shipped a bonus "hint" feature that shifted the whole score curve after proving that higher scores are correlated with better retention, improving D7 retention by about 4x.
What's next
I've been pleasantly surprised by the progress so far, and just like building a team of humans, now that the MVP is ready it's time to scale up.
As I continue to grow the team of bots, some of the empty seats are obvious, like setting up a revenue bot or adding more ad networks, and some will emerge as new problems and responsibilities arise.
If you want to try out the game and follow along as it improves, get Rank'em on iOS or Android and start a Partner Challenge.