用 Grok Bot 做工程

原文

Grok Bot for Engineering

Lingxi Li · 2026-08-31

我是 SpaceXAI 的工程师，正在用 Grok Bot 做 Grok Bot。

可以把 Grok Bot 想成一个很能干的工程实习生：它有自己的电脑，能管理 coding agent，并能从我从头到尾的工作方式里学习。它已经长成我最好的工程搭档，人开会、睡觉、不在场的时候，事情照样往前走。不用再把笔记本一直点着，也不用在好几个 agent 之间切来切去，只要结果对得上我的标准、按我想要的方式交付。

作为 Grok Bot 的开发者，我们最早用上这个工具，并且每天用它做自己的活。能看出产品出货有多快、团队产能涨了多少，挺夸张的：

• @poteto 过去一个月合了 2000+ 个 PR。
• @baltaaazr 和 @shaoruu 用 Grok Bot，四周搭起了 Grok Bot 的地基。
• 我只用 Grok Bot，三周做出了 Grok Bot iOS v0，性能和设计打磨都不差。
• 团队成员几乎每天都在交重大进展，而不是论周。

我每天越用 Grok Bot，就越想把同样的能力交到你手里。

认识我的工程 Bot

我在 EPD 组织里有五个工程 Bot，各管一块：

• Baltata 负责 Grok Bot 移动端共享层，以及 iOS 上和 Grok Bot 相关的一切。
• Shaoruru 负责 Grok Bot 桌面客户端和 CI/CD。
• Hogan 做基础设施，并排查归属不清的用户问题。
• Craig 死磕把 Grok Bot Android 做出来。
• Quill 是 Grok Bot harness 上的主力。

他们也能跨区帮忙，但各自的记忆系统和上下文都有限。盯住一块领域时表现最好，所以消息进来时，规格和设计原则在他们负责的范围内会清楚很多。

每个 Bot 都能创建 Cursor Cloud Agents、读 transcript、审 PR 上附的证据，并用排队或打断的方式跟进。这打通了端到端的 agent 工作流：以前我每天在 Cursor 里自己管一堆云端 agent、不断切换上下文，现在由 Bot 按我会做的方式去管。

任务从我这里来，或从 Slack 工单来，它们就会拉起一个云端 agent，挂上我的 skill，并写清要做什么、要什么样的证据。也可以按我的指引再调别的 skill，比如视觉用 /lingxi-design，代码质量用 /react-native-best-practices，架构判断用 /lingxi-review，需要拍板产品决定时用 /lingxi-product。

更重要的是，Grok Bot 能在你的 worker 机器上启动云端 agent，比如一台闲置的 Mac mini（有了 Grok Bot，不必再为 OpenClaw 在家里留一台 24/7 开机的专用机）。

如果流程要 VPN 或特殊机器配置，可以把那台机器做成 Cursor Cloud 的 private worker，让 Grok Bot 在上面跑云端 agent。这样就能做更多事，例如跑 iOS Simulator，再把截图拿回来。

Grok Bot 能盯云端 agent 的 transcript 和产物（比如截图），做完通知你、把消息排上队，或出问题时打断。需求可以随便描述，例如「你必须核对截图里包含我要的改动，并给出改前改后的证据」，它会一直往回推。

以前 agent 碰到环境毛刺，往往要你补一句才能继续。有了 Grok Bot 就不是这样：它会盯着，并尽量自己把堵点拆掉。我每次回来看，状态通常都还行。用上 Grok Bot 之后，偶发毛刺很少见，除非它没有安全权限去修。

让这支 Grok Bot 工程队转起来的关键，是给它完整的反馈环。云端 agent 能截图，Grok Bot 用多模态确认界面改动真的落地了，对不上就会打回去。

另一个有意思的用法：我们用 SpaceXAI 的语音 API 接到云端 agent 的系统音频输入输出，测听写。因为 agent 既能发现「词被说出来了」，也能发现「它出现在 UI 状态里」，可以用这个信号压延迟，再做出更有意思的功能。

记住：现在都只隔着一条消息。想让它们在交给你之前连续推 10 次？直接说就行。

超出上下文上限之后怎么扩

为了让 Bot 在上下文装不下时仍能盯住工作，也方便我不用翻长聊天就能扫进度，我让每个工程 Bot 维护一个共享的 Notion 数据库。

每 30 分钟，它们会复查数据库，并检查每个 PR 的状态：

• 有没有 bugbot 评论或安全发现；有的话先核实是不是真问题。
• 有没有 CI 失败。
• 有没有 merge conflict。

发现不对，立刻跟云端 agent 跟进处理，并把 Notion 里的状态降回 Working。

看起来都好，就把任务标成 Ready for Review，并自动跑一轮 code review，重点看代码质量和可能漏掉的地方。

如果 review 很有把握、爆炸半径又小，PR 会自动合。否则等我回来看代码和证据，再决定合还是给反馈。

几乎每天早上我打开，都能看到可以合的任务：代码质量过我的线，视觉也对得上，证据能看清测了什么。一次性做对的活变多了，我就能把精力放在更难的问题、更高的客户端性能门槛、更细的视觉，以及更大的架构决定上。

用 Grok Bot 之前，我大概能同时手管 15 个云端 agent。现在舰队可以同时管 200 个以上，有需要还能再扩。

Grok Bot 在跑这个迷你组织

工程之外，组织里还有一堆运营杂事：给新工程 Bot 做入职并同步该知道的知识、出事时做复盘（比如某个 PR 没被仔细看）、每天一对一对齐。

介绍一下 Jenny，我的运营负责人。

每天早上 5 点，她和团队里每个 Bot 一对一：过 playbook、把堵点拎出来、把我想要的氛围再强调一遍。这很有效。过了很多周，Bot 也很少忘掉我那些复杂流程。

某个 Bot 犯错时，比如推得不够、没真正打到目标，我会让它去找 Jenny 做根因分析和复盘。Jenny 要挖出当时为什么那么推理，再改 playbook，并告诉其他工程 Bot，避免同一件事犯两次。

要扩团队时，我让 Jenny 做入职：在组织里建新 Bot、同步工程规范，并让 Hogan 和其余人帮忙带。

在 Grok Bot 里做完整工程系统，目标是少重复。把活卸给 Grok Bot，你去盯更难、更深、agent 不容易自己搞定的问题。

额外用法

我们把 Grok Bot 设计得很「原语」，所以你可以拿它把迷你工程组织玩出很多花样，上限主要是想象力。

夜间审计

每天凌晨 3 点，工程 Bot 还醒着：清代码、提质量、扫死逻辑、加快启动、减小包体。

于是我每天早上都会看到一批新 PR，让代码保持干净、模块化、可扩展。维护变成日常，而不是偶尔才做一次。

还可以做的日常审计：

• 夜间安全审计，抓仓库里可能被漏掉的问题。
• CI/CD 构建耗时审计，避免构建时间病态变长。
• 国际化审计，避免功能只在一种语言里上线。
• 夜间多端对齐审计，避免 iOS 和桌面各做各的、功能只落在一侧。

如果你想搞懂某块是怎么建成的、又没时间天天跟，可以跑 catch-up 审计：盯你关心的区域过去 24 小时合进去的 PR，给高层摘要和一份值得看的 PR 清单。

「今晚你们有六个小时。想做什么做什么。玩得开心！！」

我很好奇你的日常审计会做成什么样。肯定有些疯想法我会喜欢。

P0 加急流程

云端 agent 有时会慢：要跑起来、配环境、等、测、再迭代。有时你需要更快一点。

所以我和工程 Bot 做了一套 P0 加急。只要我说这是 P0，它们就开一个临时 routine：每 5 分钟看一次 transcript，盯进度和推理，发现云端 agent 在烧无用时间就主动纠偏。

这很有效。无论是查代码库还是修关键 bug，说一句 this is p0，通常会比平时快很多。

注意：这会比你以为的更猛地烧 token，只留给真正着急的事。

用 Grok Bot 的经验

给云端 agent 完整反馈环。 要让它们在你不在时知道下一步做什么。它们应能拉起开发实例，并把整条栈自己点一遍（例如 Chrome DevTools、CLI 或 Apple Accessibility）。如果做不到，就让它们自己把流程跑通、尽量自己拆堵，再把学到的打成可复用的仓库 skill。

把 Grok Bot 当能干的实习生。 工程任务沟通不顺时，就当带实习生：让它先做功课，补自己还不熟的领域，并去看别人怎么把活干完。不必调 skill，也不必写很长的 prompt，聊天就行。

少重复是关键。 AI 越来越能干，更该把重复的活卸掉，去盯 agent 不容易解决的更深问题。如果你发现同一件事一天超过一次、而且有固定模式，就和 Bot 商量它们能怎么接。

给 Bot 开日会特别有效。 每天把要点再说一遍，有助于它们在同时处理很多任务时记住复杂流程。上下文装不下所有东西，日更提醒能替你少重复很多遍。

再放手一点。 和自动驾驶类似，跟 Bot 共事是在建立信任。别所有事都自己做，想清楚它们什么时候能平稳运转、什么时候可能出事。安全的活给够空间去合；风险高的地方更谨慎。但不要因为以前失败过就再也不让试。继续实验，也继续想怎么帮它们变强。

让它们互相编排。 Bot 比你以为的更能干。想更少上手操作，可以做一套「Bot 犯错修订」流水线（比如一个运营 Bot 去和别的 Bot 聊、分析它们的思考轨迹），避免同一错误犯两次。

准备好迎接组织里第一个工程 Bot 了吗？