Grokbot TemplatesGrokbot Templates
全部使用案例

工程

有成文规矩的工程 Bot 团队：幕僚长只合并审过且检查全绿的 PR

你成了合并按钮，也成了在工具之间搬运上下文的人。

分享

当时卡在哪

Aaron Schnieder（@schnieds）的业余项目由一个幕僚长 Bot 加每个产品一个工程 Bot 来做。他写下了规则和调优过程中的教训。与 xAI 无关。

要装什么、建什么

工程 Bot 写计划、把代码交给编码代理、对照 main 审完整 diff，并推动 CI。幕僚长只在审查完成、所有必需检查全绿后合并——这是他用书面规则一次性给出的长期授权；涉及金额计算、鉴权和数据库迁移的改动，每次合并前都会被标出来。修 bug 先写一个在 main 上失败的测试；PR 保持小而单一；审查最多两轮增量，之后缩小范围。重复出现的错误写进仓库的 AGENTS.md。

机器人

  • Chief of staff

    只合并已审查且必需检查全绿的 PR；标出高风险改动。

  • Engineering bot (one per product)

    写计划、分派代码、审 diff、推动 CI。

插件

  • GitHub

    必装

例行任务

  • 第一次先别开。自己看过一轮再说。

提示词

这是技巧，不是可贴的系统提示词。作者没有公开提示词。按「第一次怎么跑」做。

第一次怎么跑

  1. 1阅读 https://x.com/schnieds/status/2108754367037788240（致谢 @schnieds）。
  2. 2每个产品一个工程 Bot，上面再放一个幕僚长。
  3. 3写下操作手册：先写失败的测试、PR 要小、最多两轮审查。
  4. 4把合并规则写一次：已审查、检查全绿、高风险改动标给你。
  5. 5代理重复犯错时，把修正写进 AGENTS.md。

审批围栏

长期合并授权是书面的、范围很窄；高风险改动（金额、鉴权、迁移）合并前仍要他过目。

你该改什么

几乎每个改进都源于他不得不说两遍的话；把它写在代理会读到的地方。

出处

Aaron Schnieder @schnieds · 原帖

与 xAI 无关。提示词不是我们写的。第三方模板条款照旧适用。

去看模板

去看团队蓝图

Pro 设置包

想要完整设置，而不只是思路？

Pro 设置包为热门用例提供岗位描述、提示词、排程与踩坑。

了解 Pro