不少人第一次在手机上使用 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 正在做什么，并能在关键节点及时介入。
