角色分工
整套系统本质上是项目经理 + 程序员的搭档关系，只不过两个角色都由 AI 承担：
- 理解用户需求，拆解成具体任务
- 把任务写成清晰的自然语言指令，粘贴给 Gemini
- 审阅 Gemini 的输出，判断是否符合要求
- 发现问题后，把错误信息反馈给 Gemini 要求修复
- 通过 computer use 工具操控整个 IDE 界面
- 接收指令，写代码、修改文件
- 在终端执行命令，运行测试
- 把结果和变更呈现在 IDE 中等待审阅
- 运行在 Antigravity IDE 里，拥有完整的编码环境
交互流程
一次完整的任务循环是这样走的：
用户需求 → Claude 分析
Claude 把需求拆解成任务，写成中文自然语言的任务描述。
Claude 发送指令
用 computer use 把任务文字粘贴进 Gemini 聊天框，回车发送。
Gemini 工作
读文件、写代码、运行终端命令，在 IDE 里生成 diff（+N -N 行变更）等待审阅。
Claude 审阅变更
截图查看变更内容，决定 Accept all 还是 Reject。
错误反馈循环
如果有报错，Claude 把错误信息发给 Gemini 要求修复，循环直到通过。
关键技术点
1. computer use 是桥梁
Claude 没有直接 API 连接到 Gemini，而是通过截图「看」屏幕，再用鼠标点击、键盘输入来操作 IDE，就像一个人坐在电脑前工作一样。这让它可以驾驭任何图形界面工具，不依赖 API 集成。
2. 任务描述的质量决定结果
给 Gemini 的指令越具体越好：指明文件名、行号范围；说清楚「做什么」而不是「怎么做」；包含验证标准，比如「做完后在终端执行 X 来确认」。
3. 错误驱动的迭代
出现报错时，直接把错误信息原文转发给 Gemini，让它自己定位和修复，而不是人工分析怎么改。大模型对自己或其他模型产生的报错有很强的理解能力。
4. 人工审阅关卡
每次 Gemini 的代码变更，Claude 都要查看 diff 再决定是否接受，保持人在控制链上（human-in-the-loop），防止意外的大范围修改。
核心原则总结
| 原则 | 说明 |
|---|---|
| 明确边界 | 一个负责「想什么」，一个负责「做什么」 |
| 指令原子化 | 每次只交代一个明确目标，避免多目标混淆 |
| 错误即输入 | 把报错直接给执行智能体，不要自己翻译 |
| 审阅不跳过 | Accept 之前必须检查 diff，防止意外改动 |
| 验证内嵌 | 指令里要求对方「做完后验证」，而不是自己再问 |
本质思考
这套模式本质上是把大模型当做有代理能力的 API 来调用。
Claude 负责编排和质量把关，专业领域的执行交给最适合的工具（不一定是同一家的 AI）。两个智能体各司其职，形成一个能自我修错、持续迭代的闭环系统。
「随着 computer use 能力的成熟，这种『AI 调度 AI』的模式会越来越普遍——它的上限不是某一个模型的能力，而是编排者的规划水平。」
写于 2026 年，基于真实项目经验总结。