Cursor 手机接着改 Bug，这份交接提示词收好

假设你让 Cursor 修一个 Bug，测试还没跑完，人得出门了。刚下楼，它问了一句「这个兼容逻辑还要保留吗？」

问题不大，但任务就停在这里。你知道答案，电脑却不在手边。

Cursor 10 月 6 日的官方更新日志给这类场景补了一个入口，iOS 应用可以查看、回复电脑上的本地智能体。对经常让 Agent 改代码的人，这个变化挺实在，少一次为了回一句话折返工位。

好家伙，手机终于能接上那句「继续」了。不过我更想带走的，是一份离桌之前把任务交代清楚的模板。否则只是把守着电脑，换成守着手机。

这篇基于官方材料整理，没有做手机配对和断线恢复实测。配图中的设置界面来自 Cursor，后面那段中文提示词是我按交接场景整理的建议，不是官方模板。

先把功能开起来。按这次更新日志的路径，手机安装 Cursor iOS 应用、登录账号，在出现的电脑列表里选中目标机器，再回桌面端批准配对。随后选择已有本地智能体，查看进度或补充消息。企业账号需要管理员开放相应设置。

电脑要继续开机、联网。想让它在离桌后保持唤醒，可在桌面端 Remote Control 设置里开启 Keep this computer awake；官方还要求接电并保持笔记本屏幕打开。把电脑合上塞进包里，不能当作这个流程的一部分。

这里有个容易走岔的地方。另一份官方移动端文档仍描述在 Agents Window 开启功能、输入 /remote-control 的交接路径，还写了云端循环和本地工具的分工。这与本次更新日志的自动列出电脑、批准配对说明不完全一致。

坦率讲，现有公开材料不足以替所有客户端版本判定具体入口。你看到的界面若不同，先核对客户端更新与账号设置，按自己界面对应的官方说明操作。本文按 10 月 6 日更新日志介绍配对，不把两套流程拼成一个必须逐项执行的教程，也不据此断言对话数据完全留在本地。

真正开始试用时，我会挑一个很小的任务。比如已有复现步骤的表单校验 Bug，只涉及一个页面和几条相关测试。暂时用不上大迁移，更用不上「顺便把架构重构一下」。

为什么挑小任务？因为第一次要确认的是交接通不通。电脑上的任务能否在手机找到，手机补充一句要求后，桌面会话是否收到，后续产物是不是仍落在预期分支。把这几件事看清楚，你才知道下一次离桌能放手到哪里。

试验时，人先留在电脑边。手机发一条范围很窄的补充，例如「复用现有错误提示组件，暂不新增依赖」。回到桌面核对它收到的内容，再看修改是否符合要求。这是建议的试跑方法，我没有替你跑过，也没有测得一个所谓成功率。

很多朋友可能会把第一条手机消息写成「继续，弄好了告诉我」。我能理解，手机打字麻烦。

可「弄好了」至少有两种读法。你想的是修完这个 Bug，Agent 可能理解成把碰到的问题都顺手修掉。范围一旦变大，你接下来在小屏幕上看到的，就是一串原本不准备审的文件。

所以我更愿意在离桌前，趁键盘还在手上，把下面这段交代给当前会话。方括号内容换成你的项目实际信息，测试命令用仓库已有的，不照抄一个不存在的 npm test。

继续处理当前 Bug［问题或工单］，使用当前任务分支［分支名］。
修改范围限于［模块或目录］。保留［必须兼容的行为］。
先复现问题，再做最小修复，运行［仓库中已有的相关测试命令］。
不要自动部署、合并主分支、升级依赖或修改真实业务数据。
如果现有测试失败，区分修改前就失败的项目与本次引入的问题。
需要产品取舍、权限提升或范围外改动时，停在该步骤并说明原因。
请把需要我回答的问题收成一条消息，给出备选项和各自影响。
结束时汇报修改文件、实际运行的命令、结果，以及没完成的部分。
保留日志和代码差异，等我回到电脑后检查。

这段话最有用的地方，是把需要人回答的问题收拢了。

同样是兼容性问题，「旧版客户端继续支持，还是删除兼容分支？」比「下一步怎么做？」好回得多。再加一句两种选择分别影响什么，你在手机上就有足够的信息做一个小决定，而不是隔空猜代码。

也别把提示词当权限系统。这些是任务要求，Agent 仍可能理解错，或者已有工具权限比你以为的更宽。涉及真实数据、部署或其他外部改动，仍应由项目已有权限配置限制；一段文字不会替你收回终端里的凭据。

接下来，你得决定什么适合在手机上回。

如果它问「错误提示复用现有组件，还是加一个新的」，而你早就知道产品约束，一句话就够。要是它问「是否删除这个旧接口」，手机上给出的上下文又不完整，我会让它保留现状、列出调用位置，等回桌面再看。

这里没有通用的文件数量阈值。三行权限判断，可能比一百行样式调整更值得仔细审。可以问自己一句，**不打开完整差异，我能不能说明这次选择会影响谁？**说不清，就把它留到电脑前。

我是真的觉得，移动端最适合接短决策。目标明确、影响范围清楚、没有新的外部操作，才值得当场回复。复杂代码审查硬搬到手机上，省下的那点等待时间，很容易花在后面的返工里。

再说一个没那么好看的场景，手机上突然没动静了。

先别连发三次「继续」。你现在不知道的是任务停了、连接断了，还是进度没显示出来。先检查最后一条可见状态和时间，确认电脑是否仍在线；回到原会话核对日志，再决定是否恢复或重开。

公开材料没有替我们保证所有断网情形下的恢复行为。所以第一次试跑就该记住任务分支和会话，避免一着急又开一份同题任务。两个 Agent 同时处理同一处改动，事后比较谁做了什么，比等一会儿更费神。

电脑留在桌上，还要考虑现实条件。电源有没有插稳，网络会不会切换，机器放的位置是否合适，离桌期间有没有别人会操作同一个工作区。这些听起来很普通，但决定了你离开之后到底有没有一个稳定的执行环境。

功能开通后，也不用把每个碎片时间都填满。不是哥们，遛个弯还要盯三十条测试输出，那叫换了个地方值班。

比较舒服的安排，是离桌前约定好暂停条件，只在它确实需要一个选择时回消息。能独立跑完的工作让它跑，手机拿不准的改动让它等。你要减少的是无意义的等待，不是取消自己离线的时间。

回到电脑后，看它的结束汇报，再打开真实差异。确认修改留在约定分支、没有顺手升级依赖，检查测试命令和输出是否对得上；如果它只写「测试通过」，就要求补上实际运行的记录。

这一步和远程控制是否好用是两回事。消息成功送到了，只能证明交接通道通了；Bug 有没有修好，仍要靠复现步骤、代码和测试结果判断。手机上的绿色状态不能替你完成代码审查。

能够把一个本来卡着的小任务接着往前推，已经有点子牛逼了。我的建议是从一条真实的小 Bug 开始，把配对、补充要求、回桌面核对完整走一遍，再决定要不要纳入日常。

这类编程工具的新入口，后面我也会沿着「怎么接手、怎么暂停、怎么验收」继续看。你最想在手机上接住的，是 Agent 的需求追问，还是测试失败后那一下选择？