借助 Loop 串联云端与本地的 AI 开发流程
前言
前段时间薅了个羊毛:SuperGrok Heavy 正价是 $300 一个月,我赶上了优惠,$900 左右买了一年。刚开卖那会儿还附带送 Cursor Ultra,后来这个福利就不送了,好在已经领到的还能继续用。
钱都花了,额度总不能浪费。于是我把日常的需求开发尽量交给 Cursor 的云端 Agent 去做。
用了一段时间,代码确实不太用我写了,但时间都花在了云端和本地之间来回跑上:云端提需求、看计划、等它做完、拉到本地跑模拟器、改两行、推回去、再去 PR 里看 review……我好像从写代码的人,变成了一个传话的人(误。
所以我做了 Loop。一个需求从提出到 PR 合并,往往要在云端和本地之间来回好几趟,这些交接现在都交给它来管。
Loop 是什么
Loop 是一个 macOS 桌面应用,基于 Craft Agents 的开源版本,让 Codex 和 Claude 一起改出来的。Craft 本身已经有不错的桌面界面和对话能力,我在上面加了「任务交付」这一层:
- 云端:接 Cursor 的云端 Agent,列计划、写代码、跟进 PR 都在云端
- 本地:每个任务一个独立的 worktree,带终端,对话接本机的 Codex
- 其他:GitHub 用本机的
gh登录,Jira 工单可以关联到任务上
打开是一个看板,分「待我处理」「处理中」「已结束」三列。平时我只看最左边那列,其他的让云端自己跑:

用 AI 写一个管 AI 干活的工具,也不知道谁在给谁打工。
Loop 里的模型分工
大致是云端写代码、跟进 PR,我在本地验收、做决定。具体分工:
| 环节 | 谁来做 | 在哪 |
|---|---|---|
| 列计划 | Claude Opus 5.5(high) | 云端 |
| 审计划 | 我 | Loop |
| 写代码 | Grok 4.7(xhigh) | 云端 |
| 测试、桌面端和 Web 端验证 | Grok 4.7(xhigh) | 云端 |
| iOS、Android 验证 | 我 | 本地 |
| 修改不符合预期的地方 | Codex(GPT-6 Astra,Extra High) | 本地 |
| 处理 PR review、CI | Grok 4.7(xhigh) | 云端 |
| 产品决策、合并 | 我 | Loop |
模型的大致水平可以参考 Artificial Analysis 的智力榜。
计划用 Opus,是因为后面改哪些文件、怎么验证都由计划决定,这一步我愿意用最强的模型,Opus 5.5 目前在榜上排第一。
写代码用 Grok 4.7。说实话它能力一般,和第一梯队还差一截,但照着写好的计划出个初版够用,额度又是送的。
本地用 Codex,走我自己的 ChatGPT 订阅。云端交回来的代码,交互细节、文案经常和我想的不一样,在本地让 Codex 改,比重新描述一遍发回云端快。
移动端只能我来验。云端 Agent 跑在 Linux 虚拟机里,能开浏览器验桌面端(Electron)和 Web 端,但 iOS 模拟器只能跑在 macOS 上。
一个任务在 Loop 里怎么走
1. 新建任务,审计划
新建任务时写清楚要什么结果、哪些平台要改、哪些不动,有 Jira 就贴上链接。点「开始计划」后,云端 Agent 用 Opus 以计划模式启动,只出计划,不改代码。
计划会完整显示在 Loop 里。我看一下范围和验证方式,没问题就点「批准并执行」,不用去开 Cursor 网页。
2. 云端实现
批准后,同一个 Agent 换成 Grok 4.7,按计划写代码、跑测试、验桌面端和 Web 端。它在做什么,Loop 里能实时看到。
这里用到的是 Cursor 今年 4 月底升级的 Cloud Agents API v1:一个 Agent 可以持续存在,每次发 prompt 是一个新的 run,进度通过 SSE 实时推送。所以一个需求从头到尾只用一个云端 Agent,列计划、写代码、改 review 都是在它上面追加 run。上下文一直保留,我也不用把计划复制来复制去。
3. 本地验收
云端做完后,任务回到「待我处理」。点「开始本地验收」,Loop 会把代码拉到这个任务自己的 worktree,终端也已经切到对应目录,启动项目就能看。
页面上会列出云端验不了、需要我确认的检查清单:

我在 iOS 和 Android 上跑一遍,对照需求看位置、文案和交互对不对。不对的地方,在旁边的对话框里让 Codex 改。
4. 交回云端
验收通过后交回云端。交回时只勾选要提交的文件,再写几句验证说明,比如在哪些设备上验了什么。这段说明会随提交一起回到云端,Agent 之后处理 review 时也看得到。

5. 云端盯 PR
交回之后,云端 Agent 继续跟进 PR:CI 挂了去修,review 评论去处理。同仓的 PR 用 Cursor 原生的 PR 订阅;跨 Fork 的 PR 不支持原生订阅,就由 Loop 读 GitHub 的检查状态,失败了再派给原来的 Agent 去修。
6. 需求问题回到我
有些 review 意见会改变需求范围。比如需求只改移动端,review 里有人说「桌面端也统一一下吧」。遇到这种情况,Loop 会让 Agent 先停下,把它变成一个问题来问我:

如果我选择扩大范围,就更新计划再走一遍。代码有改动,就回到第 3 步重新验收。
7. 合并
CI 通过、review 处理完,最新的提交我也验过了,就在 Loop 里点「合并」。
交接上的几条规矩
这个流程里最容易出错的是交接,所以我给 Loop 定了几条规矩:
状态都在看板上。 同时开三四个需求时,哪个在云端跑、哪个等我审计划、哪个等我验收,看板上都有。以前经常是打开 GitHub 才发现,某个 PR 已经等了我半天。
同一时间只有一边改代码。 任务在云端时云端改,拉到本地后我和 Codex 改,交回去之后又轮到云端。
验收对应具体的提交。 我在本地验完后,云端可能又根据 review 推了新提交,这时候要合并的已经不是我验过的版本。所以云端一推新提交,之前的验收就失效,合并时也只合并我验过的那个提交。
Agent 的报告不算验收。 Agent 说「测试都过了」,我还是要自己看;没跑的检查也不算通过。
下一步:iOS 和 Android
目前我花手动时间最多的还是移动端验证,所以打算给 Agent 也配一台 Mac,要么买台 Mac mini 放家里常开,要么租云端的 Mac 按需用。
两种做法思路一样:Agent 写完代码后自己在 Mac 上把检查清单跑一遍,把截图传回 Loop,我看截图就行,不用每次自己去点。
目前还只是个计划,等搭起来了再单独写一篇。
不过这能覆盖的主要还是 Bug。按钮有没有被挡住可以自动测,改动是不是用户想要的,还得人来看。
写在最后
现在一个需求里,我要做的基本就是审计划、本地验收、做产品决策和合并,其余的交给云端 Agent 和 Codex。
至于那 $900 能不能回本,就看这一年能帮我省下多少时间了。要是再买台 Mac mini,回本的压力就更大了(误。