官方 guide《Grok Bot for Engineering》专题（Lingxi Li）：5 个工程 Bot + 运营 Bot Jenny + 云 agent 舰队

做了哪些 Bot

引它们可以跨领域干活，但各自记忆体系不同、上下文有限，所以“专注在自己负责的领域里表现最好”——领域内的规格和设计原则更锐利。

来源

• 官方 guide：https://x.ai/bot/guides/grok-bot-for-engineering

怎么搭

• 引每个 Bot 都能创建 Cursor 云 agent、读取对话记录、检查 PR 上附带的证据（proof），并通过“排队一条消息”或“打断当前运行”来发后续指令。
• 引收到任务（来自作者或 Slack）后，Bot 会带着作者的 skills 启动云 agent，并写一份详细提示词，说明要做什么、需要什么证据；还会按作者的个人指引智能调用其他 skill，例如 /lingxi-design（视觉）、/react-native-best-practices（代码质量审计）、/lingxi-review（评判架构）、/lingxi-product（需要有主见的产品决定）。
• 引Bot 也能把云 agent 启动在你自己的 worker 机器上（例如闲置的 Mac mini）；需要 VPN 或特殊配置时，把那台机器设为 Cursor Cloud private worker，再让 Grok Bot 往上面跑云 agent，这样还能跑 iOS 模拟器并拿回截图。
• 引Bot 监控云 agent 的对话记录和产物（如截图），完成时通知你、排队发消息，出问题时打断。你可以用大白话提要求，比如“必须验证截图里包含我要的改动，并给出前后对比证据”，它会一直干到达标。

反馈回路

• 引云 agent 能截图，Grok Bot 用多模态确认视觉改动是否落地，不符合就打回。
• 引“听写测试”示例：他们把 SpaceXSI 的语音 API 接到云 agent 的系统音频输入输出上；agent 同时拿到口语和转写文本，借此测试整条产品线的语音转语音功能。
• 引环境不稳定导致 agent 停住时，Bot 会尽可能积极地解封；作者说自从用上 Grok Bot，偶发的不稳定几乎不再到他这里，例外是 Bot 没有安全权限去修的时候。

来源

• 官方 guide：https://x.ai/bot/guides/grok-bot-for-engineering

Routine 与触发

引为了在上下文上限之外保持跟进，每个工程 Bot 管理一个共享的 Notion 数据库（里面是 Bot 们评审的 PR）。每 30 分钟，它们检查每个 PR：

• Bugbot 的评论或安全发现，核实每条是否成立；
• 失败的 CI 运行；
• 合并冲突。

分支逻辑

• 引发现问题：立刻让作者的云 agent 去修，并把该行移回 “Working”。
• 引一切正常：标记为 “Ready for Review”，并自动启动一次代码评审，格外留意代码质量和可能的遗漏。
• 引评审结论把握很高且影响面小：PR 自动合并；否则等作者回来看代码和证据，决定合并或给反馈。

结果

引作者说几乎每天早上都能看到“可合并”的任务；更多工作一次做对；以前他最多手动管 15 个云 agent，现在舰队同时管 200+，需要还能扩。（自述）

来源

• 官方 guide：https://x.ai/bot/guides/grok-bot-for-engineering

做了什么

• 引每天早上 5 点，Jenny 和团队里每个 Bot 一对一：回顾 playbook、暴露阻塞、强化作者想要的“氛围”。作者说这很有效，Bot 几周后也很少忘记复杂的工作流。
• 引Bot 出错（例如没有足够地推回去、没触达真正目标）时，作者让它去找 Jenny 做根因分析和复盘；Jenny 挖出导致问题的推理，更新 playbook，并通知其他工程 Bot，避免重蹈覆辙。
• 引要扩编时让 Jenny 做入职：她在作者的组织里创建新 Bot，分享团队工程规则，并请 Hogan 和其他 Bot 协助带新人。

引作者的目标是“让一个完整工程体系里的重复劳动降到最低”。

来源

• 官方 guide：https://x.ai/bot/guides/grok-bot-for-engineering

夜间审计

• 引每晚 3 点，工程 Bot 起来清理代码库、提升质量、清除死逻辑、加快应用加载、缩小包体积；早上得到一批新的 PR。
• 引文中列出的更多审计思路：安全审计；CI/CD 构建时间审计；国际化审计（功能只在一种语言上线）；对等审计（iOS 与桌面等多端功能只落在一端）；追赶审计（监控过去 24 小时某领域合并的 PR，给出摘要和值得评审的 PR 清单）。
• 引作者最喜欢的一句提示词（原文）：“You have six hours tonight. Build whatever you want. Have fun!”

P0 紧急流程

• 引云 agent 有时慢（要装环境、跑测试、迭代）。作者一说某任务是 P0，Bot 就起一个临时 routine，每 5 分钟检查对话记录，监控进展和推理，在 agent 浪费时间时主动纠偏。
• 引原文提醒：这样烧 token 比你以为的快得多，只在真正紧急时才用。

来源

• 官方 guide：https://x.ai/bot/guides/grok-bot-for-engineering

1. 引给云 agent 完整的反馈回路：它们应能启动开发实例并端到端驱动整个栈（如 Chrome DevTools、CLI 或 Apple Accessibility）；做不到就让它自己跑一遍流程、尽量自己解封，并把所学沉淀成可复用的仓库 skill。
2. 引把 Grok Bot 当作有才华的实习生：沟通不顺时，让它先做功课、研究不熟的领域、参考别的工程师怎么做；不用调用 skill，不用长提示词，聊就行。
3. 引避免重复：一天内做同一件事超过一次且有明确模式，就和 Bot 讨论怎么接手。
4. 引给 Bot 开每日会议：每天重复关键点，帮它们在同时处理多件事时记住复杂工作流（上下文装不下所有东西）。
5. 引更放手：像自动驾驶一样是个建立信任的过程；安全时给足自由，高风险区域更谨慎；但不要因为它们失败过就不让试。
6. 引让它们一起编排：建一个“Bot 犯错复盘流水线”（例如运营 Bot 和各 Bot 对话、分析它们的思考轨迹），同样的错不再犯。

来源

• 官方 guide：https://x.ai/bot/guides/grok-bot-for-engineering

推第 3 张里的任务 “share as template toolbar + home long-press” 和第 7 张的新任务内容一致，说明这个 Notion 表就是第 7 张那类任务的落点（推）。

来源

• 官方 guide 与截图：https://x.ai/bot/guides/grok-bot-for-engineering

• 引与 guide 对得上的地方：Engineer Bot 的“30 分钟巡检、只让你合并”就是 4.3 里的做法；Nightly Audit 的“每个区域一个清理 PR”对应 4.5。
• 引时间差异：guide 里夜间审计是凌晨 3 点；模板的默认值是 4am 并且会问你什么时候跑；直播摘要里也说“通常 4 点，个人配置是 3 点”（见 4.9）。三者并不矛盾：3 点是作者自己的设置，4 点是模板默认。
• 引模板页脚注与其他第三方模板一样：“created by a third-party user, not by SpaceXSI. It may act on your behalf.”

来源

• Engineer Bot 模板：https://x.ai/bot/fY1xWwCLzDDGVe3GwH78j
• Nightly Audit Engineer 模板：https://x.ai/bot/hkGSHcqKjGc5dm3ugNc2U

引摘要作者把直播整理成 13 节（日文）。下面是与本 guide 直接相关的部分，我翻译并压缩；时间码为摘要所标，讲者没有写名字（推：开头“最近两个月用 Grok Bot 开发，一个人用 3 周做出手机版初版”与 guide 作者自述相符）。

00:00–00:12　从开发助手到“管理 agent 的 agent”

• 引讲者把开发助手的演进讲成：自动补全 → 问答/编辑 → 能规划、实现、操作界面、验证的 agent → 云端并行 → agent 管 agent。动机：人手管 15 个云 agent 太累，所以把“写指令、查进度、追加要求、纠偏”交给另一个 agent。
• 引Grok Bot 的相关能力：启动 Cursor Cloud Agent 并取回记录/进度/结果；按完成条件核对并要求补截图或性能对比等证据；在用户的 Mac 等私有 worker 上开工；经 Vercel MCP 发现构建失败和按指定时间部署；每个 Bot 的记忆保留过往改进意见。
• 引用户合上设备后，远程环境继续跑；需要登录或人工确认时，用户可直接操作远程电脑。

00:12–00:24　人不在时的运转，以及按角色分 Bot

• 引Bot 盯着 Slack 里的请求，在你移动或睡觉时做评审/调查；检查有无截图和实质测试；在云 agent 里跑仓库内的技能；只有需要人判断时才通知；人批准后，Bot 办批准手续并通知请求者。
• 引来自 X 等渠道的缺陷反馈：先在当前 main 分支上复现，复现了再修并提 PR（摘要注明：讲者没说报告怎么进来）。
• 引人负责的事：产品方向、设计细节、难的性能问题、下一代架构、认证协助。Bot 容易“什么都答应”，所以“不做什么”也要连同理由告诉它并让它记住。
• 引夜间审计：讲者个人配置是每天凌晨 3 点通读代码（质量、模块划分、多余注释、安全问题），夜间做以减少冲突；满足前置条件（如有明确的运行证据）时自动合并。
• 引CI 失败、部署错误、不稳定测试触发调查与修复；例如 10 分钟解决不了就联系值班人。
• 引按画面开发、开发者体验、基础设施等分 Bot 的理由：不是模型能力不同，而是各自需要的上下文和流程不同（摘要作者的感想里说得更直白：每个 Bot 有 context limit）；总管 Bot 只知道谁负责什么，不把所有细节装进一个上下文。

00:24–00:39　夜间审计 Bot 的接手与 P0 流程

• 引演示：从市场里加一个审计 Bot（改名 Steve），让现有开发 Bot Craig 把 Notion 的管理方式、整理标准、工作阶段发给 Steve；Steve 记住并互相确认；当场开始一次审计。摘要特别注明：这个审计 Bot 的通常执行时间是 4 点，与前面的个人 3 点不同。
• 引调查 Flyloair.com 上“看不到以前订的航班”：Craig 在远程环境操作网站，报告订单列表有入口，但跳转页是临时实现，没有显示过往订单的功能。
• 引为避免“请快点”被理解成省略确认或猜测，让 Jenny 管理 Notion 里的共用手册，其他开发 Bot 不得直接编辑。
• 引P0 流程（订票问题被标为 P0）：Grok Bot 每 5 分钟检查一次云 agent 进度；查有没有偏离目标、无谓等待、过度谨慎；必要时中断/追加指示。由 Craig 告诉 Jenny，Jenny 更新手册并通知所有开发 Bot（演示中看到了更新与通知）。

00:39–00:45　证据与工作状态；三点总结

• 引不再时刻盯过程，而是看成果与证据：所有 PR 都按变更类型要求证据——画面变更要截图，性能优化要性能指标——并让 Jenny 把这条写进手册。
• 引Steve 的夜间审计出了至少 1 个可评审的代码整理 PR，另一项工作继续；摘要注明：合并没有明确完成。
• 引众多 agent 的进度记在 Notion 数据库里，用时再查；讲者说 20 个左右的 agent 也不需要把所有细节放进 Bot 的上下文里。
• 引工作坊三要点：① 像教一个能力强的新人那样讲清组织背景和期望；② 把重复的指示整理成共用流程（手册/确认步骤）；③ 提供能判断成败的反馈（用实操验证成果，据此决定追加还是完成）。

摘要作者自己的三点感想（他的观点，不是讲者的）

• 引记忆管理是关键：分 Bot 是为了“不被无关记忆淹没”；拆成 3 个工程 Bot 是因为 context limit；但长时间运行仍会让上下文变挤、跨会话记忆也传不过去。
• 引他对“CI 变红→Bot 查原因→起云 agent→按合并标准合并→10 分钟没解决才叫值班”印象深刻，并指出这使 LLM 的响应速度与可用性成为运维前提——这点会上没提。
• 引他担心自动维护造成规格漂移；对此会上给出的做法是：把“不做什么”连理由告诉 Bot 并记住、自动工作只限低风险变更、PR 要求与变更对应的证据。

推前半场的“Ship by Thursday”艺术/餐饮快闪项目（飞到 3 天内创业的直播企划，Steve 被改造成统筹 Bot、Tater 做开发、Dr. Eggbot 做 Bot 搭建等）在摘要里占了大半篇幅，与这篇 guide 关系不大，我没有收录细节；它说明同一批 Bot 名字（Steve、Tater）在直播里被复用。

来源

• 直播摘要（@TNaoki_0208）：https://x.com/TNaoki_0208/status/2100473017969385488
• 摘要作者的感想帖：https://x.com/TNaoki_0208/status/2100482769088389493
• Galaxy 日程帖：https://x.com/XFreeze/status/2099392868913746235

• 引必须用 Notion 吗？ guide 和直播里都用 Notion 数据库作为共享的工作状态；官方文档没有规定。换成别的看板，核心是“先有一行再动手”（见 4.7 第 6 张）。
• 引Bot 会不会自己合并？ guide 说只让你合并（Engineer Bot 模板简介：“only asks you to merge”）；直播里夜间审计在满足前置条件（如明确的运行证据）时自动合并是作者的个人设置——两处说法不同，取决于你给的规则。
• 引为什么是 3 个或 5 个工程 Bot？ guide 里是 5 个（见 4.1）；直播里讲者说拆成多个是因为上下文限制而非能力差异。
• 引官方文档对 routine 的限制？ 每个 Bot 最多 50 个 routine、保留最近 20 次运行、间隔至少 5 分钟——所以“P0 每 5 分钟检查”正好是允许的最短间隔（推）。
• 推Craig 和 Steve 是不是 guide 里的 Bot？ guide 截图里有 Craig、Baltata、Shaoruru、Hogan、Quill；直播里出现的 Craig 是“已有开发 Bot”，Steve 是新添加的审计 Bot——Steve 没有在截图里出现。

1. 添加 Cursor 与 GitHub 插件；先加 Lingxi's Engineer Bot 模板（或自己建一个工程 Bot），给它一个 Notion 数据库（列：Owner、Stage、PRs；阶段如 Working / Watching n/3 / Ready for review）。
2. 写进规则：新任务先在表里有一行（Stage=Working）再动手；不接手别人的 PR；PR 正文用统一标记（见 4.7 第 6 张）。
3. 建一个每 30 分钟的 routine 巡检表里每个 PR（CI、评审意见、冲突），连续通过 N 次后标 Ready for review，只让你合并。
4. 加一个 Nightly Audit Engineer：先让它研究整个代码库，每个区域一个清理 PR；设定运行时间（模板默认 4am）；先观察再放开自动合并。
5. 建一个不写代码的运营 Bot（Jenny 的角色）：管 Notion 里的共用手册，其他 Bot 不直接改手册；每天早上和每个 Bot 开一对一，问“在做什么、有没有卡住”。
6. 把“证据要求”写进手册：画面变更要截图，性能优化要指标；CI 失败的升级时限（直播的例子是 10 分钟）。
7. 遇到紧急问题（P0），让 Bot 临时建一个每 5 分钟检查云 agent 的 routine，解决后关掉。
8. “不做什么”也写下来并让 Bot 记住：Bot 默认什么都接受。

来源

• 官方 guide：https://x.ai/bot/guides/grok-bot-for-engineering
• 日程帖：https://x.com/XFreeze/status/2099392868913746235
• 摘要帖：https://x.com/TNaoki_0208/status/2100473017969385488