让 GPT-5.6 做主控，让 Grok Build 执行：Pi 双模型编程提示词

工作流是怎样的#

完整流程分为四步：

1. Pi 主会话使用 GPT-5.6 阅读需求和相关代码；
2. GPT-5.6 确认约束、影响范围、实现方案和验收标准；
3. GPT-5.6 调用 pi-toolset 的 general agent， 通过 grok-acp runtime 交给 Grok Build 执行；
4. Grok 返回后，GPT-5.6 检查 git diff、测试结果和剩余风险，必要时让同一个 Grok 会话继续修正。

可以把它理解为：

1
需求
2
  ↓
3
GPT-5.6：分析、决策、制定 implementation brief
4
  ↓
5
Grok Build：修改代码、运行测试、报告结果
6
  ↓
7
GPT-5.6：审查 diff、判断是否通过、决定是否返工

其中，implementation brief 不是泛泛而谈的建议，而是一份可以直接执行的任务单，至少应包含：

• 要解决的真实问题；
• 允许修改的范围；
• 推荐实现方式；
• 必须保持的兼容行为；
• 测试和验收标准；
• 不应顺手进行的额外重构。

为什么不能只用 /work-with-grok#

pi-toolset 已经提供了快捷命令：

1
/work-with-grok <任务>

它会要求 Pi 调用 general agent，并覆盖本次调用参数：

1
runtime: grok-acp
2
model: grok-4.5
3
thinking: high

这个命令适合“我已经知道要做什么，直接让 Grok 执行”的任务。但它的内置模板会把后面的原始任务直接交给 Grok，GPT-5.6 通常只负责发起调用，不会先完成一轮详细规划。

因此，两种用法并不相同：

如果目标是复现“GPT-5.6 决策，Grok Build 执行”，关键不是在 /work-with-grok 后面堆更多要求，而是明确告诉 Pi 主模型： 先自己完成决策，再调用 Grok。

使用前确认#

提示词本身不能切换 Pi 当前使用的主模型。开始前需要先在 Pi 中确认：

1
provider: ga-aihub-gpt-5-6-sol
2
model: gpt-5.6-sol
3
thinking: high

然后确认 pi-toolset 已加载，并能看到 general agent：

1
/agent list

Grok Build 执行端还需要本机安装并认证 Grok CLI，且 grok-4.5 在 CLI 中可用：

1
grok models

当前版本中，论坛旧截图里的 subagent/worker 已经迁移为 agent/general。照抄旧名称可能无法得到相同效果。

可直接复制的完整提示词#

把最后的“当前任务”替换成自己的需求即可：

1
你是本任务的主控和决策者。
2

3
先由你自己使用当前主模型 GPT-5.6 完成以下工作：
4
1. 阅读需求和相关代码，确认真实现状、约束和影响范围。
5
2. 决定实现方案，明确需要修改的文件、行为边界和验证方法。
6
3. 将方案整理成一份可直接执行的 implementation brief。
7
4. 规划阶段不要修改文件，也不要把规划工作交给 Grok。
8

9
方案确定后，调用 balaenis/pi-toolset 的 agent 工具，
10
将 implementation brief 交给 general agent 执行，并显式设置：
11
- runtime: grok-acp
12
- model: grok-4.5
13
- thinking: high
14

15
要求 Grok：
16
- 以 GPT-5.6 制定的方案为准；
17
- 可以检查代码验证方案中的假设，但不要擅自扩大范围；
18
- 完成所有代码修改；
19
- 运行相关测试和静态检查；
20
- 报告修改文件、验证命令和剩余风险。
21

22
Grok 返回后，由你继续担任主控：
23
1. 检查 git diff 和 Grok 的测试结果。
24
2. 判断实现是否符合原始需求和你的方案。
25
3. 如有问题，优先继续同一个 Grok ACP run/session，让 Grok 修正。
26
4. 未通过验证前不要宣称完成。
27
5. 最终由你向我总结方案、实际改动、验证结果和残余风险。
28

29
当前任务：
30
【把你的具体需求写在这里】

这段提示词把决策权留在 GPT-5.6 手里，同时避免两个模型同时修改同一个工作区。Grok 开始执行时，GPT-5.6 的方案应该已经足够具体。

一个实际示例#

假设需要修复登录状态丢失，可以这样写：

1
你是本任务的主控和决策者。先由 GPT-5.6 阅读代码、分析登录超时问题并制定 implementation brief，规划阶段不要修改文件。
2

3
方案确定后，调用 general agent 执行，参数必须是：
4
runtime: grok-acp、model: grok-4.5、thinking: high。
5
Grok 负责修改代码和运行测试。完成后你检查 git diff 和测试结果；
6
如有问题，继续同一个 Grok session 修正。
7

8
当前任务：修复用户登录后偶发跳回登录页的问题，保持现有认证架构，不引入新的状态管理库。修复必须包含回归测试，并保持现有公开 API 兼容。

GPT-5.6 最终发起的工具调用大致会是：

1
{
2
  "agent": "general",
3
  "runtime": "grok-acp",
4
  "model": "grok-4.5",
5
  "thinking": "high",
6
  "task": "这里是 GPT-5.6 整理好的具体实施方案和验收标准"
7
}

重点不在 JSON 长什么样，而在于 task 中传给 Grok 的内容应当是 GPT-5.6 已经整理好的方案，而不是未经分析的原始一句话需求。

日常使用的精简版#

完整模板适合高风险或范围较大的任务。普通开发任务可以使用下面这个版本：

1
先由你作为 GPT-5.6 主控阅读需求和相关代码，独立确定实现方案、修改范围和验收标准。规划阶段不要修改文件。
2

3
然后调用 balaenis/pi-toolset 的 general agent 执行你的方案，设置：
4
runtime: grok-acp、model: grok-4.5、thinking: high。
5
要求 Grok 完成代码修改并运行测试，不扩大任务范围。
6

7
Grok 返回后，由你检查 git diff 和测试结果。发现问题时继续同一个 Grok run 修正；验证通过后再向我汇报。
8

9
任务：【填写任务】

如果任务本身已经非常明确，不需要 GPT-5.6 先规划，再使用快捷命令即可：

1
/work-with-grok 按现有项目规范实现这个明确任务，并运行相关测试

让分工真正生效的几个细节#

1
/agent runs
2
/agent status <run-id>

Grok Build runtime 和模型来源不是一回事#

这里的 grok-acp 表示：Pi 通过官方 Grok CLI 的 ACP 协议启动执行环境。它负责会话、工具调用、命令执行和修改文件。

模型请求使用哪种额度，则取决于 Grok CLI 中 grok-4.5 的实际配置：

• 使用官方登录时，通常消耗 Grok Build 对应额度；
• 配置自定义 API Provider 时，执行环境仍是 Grok Build CLI，但模型费用由该 API Provider 承担。

因此，“使用 Grok Build 执行”和“使用官方 Grok 额度”不能混为一件事。

总结#

这套工作流的关键不是同时调用两个强模型，而是让它们承担不同责任：

• GPT-5.6：理解目标、分析代码、权衡方案、定义验收标准、审查结果；
• Grok Build：依据方案修改文件、运行命令、完成测试、提交执行结果；
• 用户：保留生产操作、费用、数据库和重要架构决策的最终审批权。

最值得保留的一句提示词是：

先由你作为 GPT-5.6 主控完成决策，再把已经收敛的实施方案交给 general agent，通过 grok-acp 执行；Grok 返回后，由你检查真实 diff 和测试结果，未通过验收前不要宣称完成。

当规划、执行和验收各自有明确负责人时，多模型协作才不只是“多问一个模型”，而是一条真正可控、可检查、可继续修正的工程工作流。