不少人第一次在手机上使用 Codex 时，只会把它当成一个任务进度查看器。查看那些电脑上已经启动了的任务，现在运行到哪了。

其实，手机端的 Codex 能干更多事情。比如：在手机端选择开发环境并启动新的任务，在运行过程中补充信息、调整方向，也可以查看 Codex 修改了哪些文件，并将审查意见发回任务中。

整个工作方式可以简单地理解为：

• 电脑负责读取代码、运行命令、构建项目和执行测试；
  
• 手机负责启动任务、补充上下文、处理关键决定和检查结果。
  

代码和开发环境依然留在 Mac、Windows 电脑或远程开发机上。而手机不用安装完整的编程环境，操作复杂的终端，只作为一个移动的控制界面进行指挥任务推进。

图 1：手机连接开发主机后，可以查看可用的电脑、项目和工程任务。

任务启动前的环境边界

使用 Agent 处理工程任务时，第一条指令很重要，任务运行的环境同样重要。

在手机端创建新任务前，我们要先确定 Codex 在哪里工作、读取哪一个项目，以及从哪份代码开始修改。

一般要先选择这些内容：

• 运行任务的电脑或远程主机；
  
• 对应的项目与工作区；
  
• 任务使用的基础分支；
  
• 是否创建独立的 worktree；
  
• 是否执行项目配置好的环境初始化脚本。
  

对新手来说，上面最陌生的概念可能是 worktree。它是一堆相互隔离的项目工作区，属于原来的 Git 仓库，但可以拥有独立的分支和文件状态。

如果只是让 Codex 阅读代码、解释报错，或是进行一次简单的调查，直接用当前工作区就行了。但如果任务会涉及多个文件、要持续修改，或是你正在电脑上处理另一项工作，创建独立的 worktree 便是个好法子。这样可以减少不同任务之间的相互干扰，也方便任务结束后我们检查改动、合并结果和清理工作区。

举个例子，你正在主分支上开发一个功能，同时希望 Codex 修复另一个 Bug。worktree 就能隔离这两个任务，让它们分别在独立的代码环境中进行。

图 2：创建任务前，可以选择主机、项目、plan 模式，提前确定任务运行的环境。

任务运行中的补充与引导

任务开始后，你可以用手机继续补充信息。

例如，你在手机上测试一个网页或 App，发现它的按钮被遮挡住了，可以直接截图并发送给 Codex：

检查截图中的页面布局问题。底部按钮在窄屏设备上被遮挡，请先定位原因，并说明可能涉及的样式文件。

一图省千言，你的截图可以直接呈现页面状态，从而减少你对位置、尺寸和布局关系的文字描述。如果 Codex 的处理方向出现偏差，你也可以及时补充边界：

修改范围限制在移动端样式，不要调整桌面端布局和公共组件。

在 Agent 任务运行过程中，很适合用这个补充方式。它能够让 Codex 及时修正方向，避免继续产生与目标无关的改动。

不仅如此，手机本身也是一个方便的信息采集设备。除了截图，你还可以上传文件、拍摄照片，或者用语音输入描述问题的复现过程。

例如：

页面第一次打开正常。从后台重新进入后，列表可以加载，但滚动位置没有恢复。这个问题只在重新进入页面时出现。

这类来自真实设备的信息，可以帮 Codex 缩小排查范围。对于范围较大的任务，你可以先让 Codex 制定 Plan，就是上面配图的 Plan model。这样 Agent 会先分析问题和实现路径，而不是立马开始修改代码。

参考：

先检查消息列表的恢复流程，列出可能原因、涉及文件和验证方法，暂时不要修改代码。

等 Codex 给出计划后，我们可以重点检查几个问题：

• 它是否找对了代码入口；
  
• 修改范围是否合理；
  
• 有没有涉及无关模块；
  
• 是否考虑了测试和异常状态；
  
• 任务完成后如何验证结果。
  

明确了问题、范围和完成条件后，我们可以把结果设成持续 Goal，让 Codex 接着完成实现、测试和收尾，减少每一轮重新解释目标带来的成本。

Codex 设定的 Goal 最好包含清晰、可验证的条件，例如：

修复移动端重新进入页面后的列表恢复问题，保持现有加载逻辑不变，并补充对应的回归测试。

“全面优化项目”这类目标过于宽泛，Codex 很难判断任务何时完成，也更容易扩大修改范围。

主任务与侧边问题的分流

长时间运行的工程任务会积累很多上下文。

虽然 Codex 了解了项目结构、问题原因、修改范围和测试要求，但这些一直留在主对话中的信息，会持续影响后续判断。在 Agent 开发过程中，我们会遇到一些临时问题：

• Codex 为什么选择这个实现？
  
• 某条报错具体是什么意思？
  
• 这条命令是否可以批准？
  
• 当前修改应该如何写进发布说明？
  
• 有没有更简单的实现方式？
  

这些问题与当前任务相关，但未必需要加入主任务的执行过程。临时讨论太多，容易让主对话变得杂乱，也可能让 Codex 的注意力偏离原来的目标。

这时可以使用 Side Chat，用 /side把局部问题放到侧边对话中处理。这样直接带上问题，也可以：

/side 解释一下这个报错可能由哪些状态同步问题引起

主对话继续推进代码任务，Side Chat 用于解释、分析和讨论局部问题。这样既保留了相关上下文，也能让主任务的执行记录更加清晰。

手机端的代码审查

Codex 完成一轮修改后，手机端会显示本次任务涉及的文件。我们可以先查看 Changed Files，确认修改范围是否符合预期，再打开 diff 检查具体代码变化。diff 展示的是修改前后的差异，包括新增、删除和发生变化的代码行。

如果你是新手，最好不要一开始就在手机上逐行阅读所有代码，可以先从检查文件范围开始。

例如，一个只要求调整移动端样式的任务，却修改了数据请求、公共组件和桌面端页面，这通常意味着任务边界已经扩大。此时可以直接补充要求：

保留移动端样式修改，撤回公共组件和数据请求中的改动。

如果问题出现在具体代码行，还可以添加行内评论，将意见与对应代码直接关联：

这里不要修改公共样式，请将调整限制在移动端媒体查询中。

Codex 收到评论后，可以继续处理这些审查意见，并生成一轮范围更小的修改。 /review可以让 Codex 对当前改动进行整体审查，或是补充审查重点：

审查当前改动，重点检查修改范围、异常状态和新增测试是否真正覆盖了问题。

手机屏幕偏小，其实不适合长时间阅读大段代码。但很多任务真正需要人工处理的，一般只是几个关键判断：

• 修改范围是否合理；
  
• 是否遗漏异常情况；
  
• 是否应该调整公共逻辑；
  
• 测试是否覆盖真实问题；
  
• 当前结果是否可以继续推进。
  

这些决定可以在手机上快速完成，任务不用一直等到你重新回到电脑前。

移动端的工程控制

手机端 Codex 的价值，是让开发者在离开电脑后，依然能够参与工程任务中的关键决策。

电脑继续负责代码读取、命令执行、构建和测试，手机则负责启动任务、补充上下文、调整方向和检查结果。

它不需要变成一个缩小版的开发环境，而是把开发过程中最需要人参与的环节放到手机上：确认任务范围、提供现场信息、判断修改方向，以及审查最终结果。

这样，即使暂时离开开发机，你依然知道 Codex 正在做什么，并能在关键节点及时介入。