工程师如何用好 Grok bot?

本文由 Grok Bot 工程师创作（原文为英文），本篇文章使用 Grok bot 完成中文翻译

原文： Grok Bot for Engineering

帖子： https://x.com/lingxi/status/2094493172516966781

作者： Lingxi Li (@lingxi)

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

可以把 Grok Bot 想成一个能力很强的工程实习生：自带电脑，能管编码 agent，还会跟你的工作方式学习。它已经成了我最好的工程队友——人不在、睡着了、开会时，它也能把事情往前推。再也不用给笔记本「续命」，再也不用在多个 agent 之间来回切上下文，只剩符合我标准、按我想要的方式交付的结果。

作为打造 Grok Bot 的团队，我们最早用上它，并且每天拿它干自己的活。现在发货有多快、团队生产力抬升有多猛，看着都夸张：

@poteto 过去一个月合了 2000+ 个 PR。

@baltaaazr 和 @shaoruu 用 Grok Bot，四周搭起了 Grok Bot 的地基。

我只用 Grok Bot，三周做出了 Grok Bot iOS v0，性能和设计打磨都不错。

每个成员现在几乎每天都能交付大块工作，而不是隔几周才有一次。

越用 Grok Bot 做东西，我就越想把同款超能力交给你们。

认识我的工程师 Bot

我有五个工程师 Bot，各管一块：

Baltata：负责 Grok Bot 移动端共享层，以及一切跟 Grok Bot on iOS 相关的事。

Shaoruru：负责 Grok Bot Desktop 客户端和 CI/CD。

Hogan：负责基础设施，并排查归属不清的用户问题。

Craig：负责 Grok Bot on Android，正拼命把它做出来。

Quill：负责 Grok Bot harness，绝对是这块的传奇。

他们也能跨区干活，但各自记忆系统不同、上下文有限。最擅长的是盯住一个领域——领域内的规格和设计原则，他们会锐利得多。

每个 Bot 都能创建 Cursor cloud agent、读 transcript、审 PR 上附的证明材料，还能排队发跟进消息或打断运行。这打通了端到端的 agent 工作流，覆盖我以前每天在 Cursor 里干的事——那时我要在自己管的一堆 cloud agent 之间不停切上下文。现在这些 Bot 会按我的方式去管它们。

接到任务后（来自我或 Slack），它们会拉起 cloud agent，带上我的 skills，再写一份详尽 prompt：要做什么、要交什么证明。也会按我的个性化指引智能调用额外 skill，比如视觉用 /lingxi-design，代码质量审计用 /react-native-best-practices，架构判断用 /lingxi-review，需要带观点的产品决策时用 /lingxi-product。

Grok Bot 还能在你自己的 worker 机器上启动 cloud agent，比如闲置的 Mac mini（有了 Grok Bot，家里就不用再为了 OpenClaw 专门挂一台 24/7 的机器）。

如果流程要 VPN 或特殊机器配置，可以把那台机器做成 Cursor Cloud private worker，再让 Grok Bot 在上面跑 cloud agent。这会打开更多可能，比如跑 iOS Simulator，再把截图收回来。

Grok Bot 能盯 cloud agent 的 transcript 和产物（比如截图），跑完通知你，排队发消息，出问题就打断。需求怎么说都行，例如「你必须核实截图里包含我要求的改动，并给出 before vs. after 证明」——Grok Bot 会一直干到目标达成。

让 Grok Bot 工程团队持续运转的关键，是给它完整反馈闭环。Cloud agent 能截图，Grok Bot 用多模态确认视觉改动是否到位；对不上你要的，它会顶回去。

听写测试就是这个闭环的好例子。我们把 SpaceXAI 的语音 API 接到 cloud agent 的系统音频 I/O。Agent 同时能拿到语音和转写，我们就能用这些信号测产品线里的 speech-to-speech，并做更多好玩的功能。

有时 agent 撞上环境抖动，会卡到你补一句跟进 prompt 才动。Grok Bot 替你顶着：盯紧这次运行，能 unblock 就尽量 unblock。我每次回来看，状态基本都还行。用上 Grok Bot 之后，偶发抖动很少再落到我手上；例外是它自己没有修这个问题的安全权限。

记住：现在一切都只差一条消息。想让它们在交还给你之前再冲 10 轮？直接说就行。

突破上下文上限

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

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

Bugbot 评论或安全发现，并核实是否成立

失败的 CI

Merge conflict

发现问题就立刻跟 cloud agent 跟进处理，并把行状态拨回 Notion 里的「Working」。

一切正常则标成「Ready for Review」，并自动开一轮 code review，重点盯代码质量和可能漏掉的点。

若 review 置信度很高、影响面又小，PR 会自动合并。否则等我回来审代码和证明材料，再决定合并还是给反馈。

几乎每个早上我回来，都能看到一批可以合的任务：代码质量达标，视觉合我胃口，证明材料也清楚写了测了什么。更多工作能一次打中，我就能把精力放在更难的问题、更高的客户端性能标准、更多视觉打磨，以及更大的架构决策上。

有 Grok Bot 之前，我手工最多同时管约 15 个 cloud agent。现在这支舰队能同时管 200 多个，需要还能再扩。

Grok Bot 运转这个迷你组织

除了工程，组织里还有一堆运营杂事：给新工程师 Bot 做 onboarding、分享该有的知识、出事时跑复盘（比如某个 PR 没仔细审）、开日会对齐。

这些全是 Jenny 的活——我的运营负责人，也是团队里唯一不写代码的 Bot。

每天早上 5 点，Jenny 会跟团队每个 Bot 做 1:1：过 playbook、摊 blocker、强化我想要的 vibe。我发现这很有效。就算过了好几周，Bot 也很少忘掉我那些复杂流程。

某个 Bot 犯错时——比如没有足够顶回去以碰到真正目标——我会让它去找 Jenny 做根因分析和复盘。Jenny 挖清当时的推理路径，更新 playbook，再向其他工程师 Bot 同步，避免同样错误再犯。

需要扩团队时，我就让 Jenny 拉新人。Jenny 在组织里建新 Bot，共享工程团队规则，并叫上 Hogan 和其他人一起帮 onboarding。

Grok Bot 里一套完整工程系统的目标，是尽量少重复。把任务卸给 Grok Bot，你去啃更难、更深的问题。

Grok Bot 的加分玩法

我们把 Grok Bot 做成模块化，用来搭自己的迷你工程组织空间很大。下面是我最爱的两个。

夜间审计

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

每天早上我会收到一批新 PR，让代码保持干净、少 slop、可扩展。代码维护从「偶尔搞一次」变成了日常。

更多夜间审计点子：

安全审计：抓团队可能漏掉的代码问题

CI/CD 构建时长审计：避免构建时间病态变长

国际化审计：补上只发了单一语言的功能缺口

对等性审计：多端（iOS vs Desktop）开发时，避免功能只落在一端

追赶审计：盯住你关心领域过去 24 小时合入的 PR，交回高层摘要和精选待审 PR 列表

还有我最爱的那句 prompt：「今晚你有六小时。想做什么做什么。玩得开心！」

很好奇你会给自己的夜间审计跑什么。肯定有我想偷的点子。

P0 紧急流程

Cloud agent 有时偏慢：要跑起来、搭环境、等、跑测试、再迭代。有时你就是需要更快一点。

所以我给工程师 Bot 做了 P0 紧急流程。只要我说任务是 P0，它们就启一条临时例行：每五分钟看 transcript，盯进度和推理，一旦 cloud agent 开始烧无用时间，就主动纠偏。

效果很好。需要紧急结果时——无论是代码库调研还是关键 bug——说一句「这是 P0」，往往比平时快很多。

注意：这会比你以为的更快烧 token，只留给真正紧急的场景。

用 Grok Bot 的体会与建议

给 cloud agent 完整反馈闭环： 关键是在没有你时，它们仍有下一步信号。它们应能拉起开发实例并端到端驱动整栈（例如 Chrome DevTools、CLI 或 Apple Accessibility）。如果做不到，就让它们自己把流程跑通，尽量自助 unblock，再把学到的东西收成可复用的仓库 skill。

把 Grok Bot 当有才华的实习生： 工程任务沟通卡住时，就当它是个有才华的实习生。让它先做功课，补还不熟的领域，并参考其他工程师怎么把活干完。不必调 skill，也不必长 prompt，聊天就行。

少重复是关键： AI 越强，越要把重复活派出去，专注 agent 不好啃的更深更难问题。如果你发现某事一天做不止一次、且有清晰模式，就跟 Bot 商量它们能怎么帮。

Bot 的日会特别有效： 每天重复关键点，有助于它们在同时甩多任务时仍记住复杂流程。上下文装不下一切时，每日提醒是个省事的 nudge，帮你少重复。

再放手一点： 跟自动驾驶类似，跟 Bot 协作是建立信任的过程。别什么都自己上，要想清楚它们什么时候跑得顺、什么时候可能添乱。安全时可多给空间让它们发货；高风险处更谨慎。但别因为以前失败就禁止它们再试。继续实验，继续想怎么帮它们成长。

让它们互相编排： Bot 比你想的更能干。想对 Bot 运营更放手，可以搭一条「Bot 犯错复盘管线」（比如一个 ops Bot 跟其他 Bot 聊、分析思考痕迹），避免同样错误再犯。