刚开始用 Codex 时，最容易注意到的是它会写代码、改文件、跑命令。用久以后，拉开体验差距的却是另一些事，下面为大家整理一套更好用的工作方法。
1. 对话、项目、记忆与上下文
项目和对话最好从一开始就分开。项目保存的是会反复使用的东西：代码、资料、规则、来源，以及多次任务都需要的背景。对话的寿命则短得多，它只负责一个能说清楚的结果。
比如同一个产品正在做登录修复、界面重构和代码审查，这三件事可以属于同一项目，但不要塞进同一条对话。让它们各自拥有独立的目标、过程和交付记录，后续查找更方便，Codex 也不容易把某次排查中的临时判断带进另一项工作。
源文件夹决定 Codex 在这个项目中可持续参考的代码和资料。可以添加多个文件夹，例如前端仓库、后端仓库与共享文档目录；但应避免无关文件扩大检索范围和上下文噪声。
本地项目还有一个很实际的细节：主目录会影响 Git 操作，以及 AGENTS.md、Skill 和 config.toml 的自动发现。很多看似是模型理解能力的问题，最后发现只是目录选错了。开始任务前注意看一眼工作目录和 Git 状态。
上下文不该全放在聊天里。架构、数据流和关键决策写进项目文档；构建命令、测试要求、禁改目录和完成标准写进 AGENTS.md；个人偏好与反复出现的历史经验交给记忆。这样分层以后，新对话不必从零解释。
Codex 说明适合放每次对话都成立、又不属于某个仓库的偏好。例如可以写：
默认使用中文回复。
修改代码前先说明计划；不覆盖用户已有改动。
完成后列出修改文件、执行过的验证和仍未验证的项目。
涉及删除、外部发送或生产环境操作时，先说明影响范围。
这类说明应保持短而稳定。项目专属的构建命令、目录边界和验收要求，仍应放在项目文档或 AGENTS.md，不要混入个人说明。
AGENTS.md 是告诉 Codex 先看哪些文件，哪些地方不要碰，修改后跑什么检查，最后怎样汇报。等同一种错误重复出现，再增加一条规则。提前写几十条抽象原则，只会挤占上下文。
全局 AGENTS 适合保存跨项目重复执行的操作约定。例如：
通用工作约定
开始前确认当前目录、Git 分支和工作区状态。
改动后运行与改动范围匹配的测试；不要把无关格式化混入提交。
不读取或输出密钥、令牌和本地凭据。
最终汇报包含：修改内容、验证结果、已知限制和下一步建议。
全局规则应只写通用约束；某个仓库特有的命令、部署流程和禁止修改目录，放在仓库内的 AGENTS.md 更清晰。
结束对话时，可以让 Codex 留下一份很短的交接：做了什么、改了哪些文件、跑过什么验证、还剩哪些风险。真正需要长期保留的内容再更新到项目文档。任务已经结束，就开一条新对话；任务仍在延续，就沿用原对话。
2. 计划、目标、Fork 分支与“/”命令
计划模式最适合那些“一旦方向错了，重来很耗时耗力”的任务。跨模块重构、数据库变更、架构迁移和难以复现的故障，先用 /plan 调查现状、补齐未知项，再讨论方案。
一个有用的计划会回答几件具体的事：涉及哪些文件，哪些接口必须保持不变，工作怎么拆成可验证的步骤，失败后如何回退。
/goal 处理的是另一类问题，说明任务最终要走到哪里。需要长时间推进的迁移、重构或实验，可以把最终状态、边界、验证方式和停止条件写进目标，让 Codex 自己循环推进。
但诸如“持续优化这个项目”并不算目标，因为它没有终点。
Fork 经常被误解成代码回退。它只是从当前历史派生一条新的对话路线，硬盘上已经发生的修改不会消失。想比较、恢复或合并代码，仍然要看 Git。即 Fork 处理谈话的分叉，Git 处理代码的分叉。
可以把它类比为 GitHub Fork 的探索，但不同的是：GitHub Fork 会在你的账号下复制一个代码仓库，可独立提交并通过 Pull Request 合并；Codex Fork 则从当前节点复制一条对话历史，用来比较两种排查或实现路线。它不会新建远程仓库、分支或提交，也不会自动隔离本地工作区。需要隔离代码时，仍要创建 Git 分支或 Worktree。
输入 / 后出现的命令面板，值得熟悉，但不必死记。日常使用频率较高的大致是这些：
这些命令组合起来，对应一条完整节奏：先想清楚，设定终点，执行中及时纠偏，路线确实分叉时再 Fork，交付前做 Review。对话拖得太长就 Compact；工作已经结束就收口，不要继续往里堆内容。
熟悉 “/” 命令可以少靠一段模糊的自然语言去猜当前意图，降低遗漏关键步骤的概率，也让对话在复杂任务中更容易回到可验收的轨道。
3. 浏览器、手机端控制与交互
前端任务只跑测试是不够的。布局错位、按钮不可点、登录跳转异常、错误提示消失，这些问题都可能躲过构建和单元测试。内置浏览器的意义就在这里：让 Codex 打开真实页面，按用户路径操作，再把结果和代码改动放在一起检查。
内置浏览器适合需要 Codex 参与验收的页面：它可以在受控的浏览器表面中打开页面、按步骤操作、观察结果并留下截图或测试证据。将网页 URL 默认交给 Chrome 等外部浏览器，则更适合日常阅读、复用个人登录状态、扩展和书签；页面会在你的常用浏览器中打开，但是否能被 Codex 继续操作取决于浏览器连接与授权状态。
浏览器验收最好提前写清楚。以表单为例，至少应该覆盖正常提交、缺少必填项、接口失败和权限不足。每个场景都写明操作与预期结果，Codex 才知道该停在哪里、看什么，以及什么现象算失败。
如果故障只在页面上出现，先复现并截图，修改后再走同一条路径。这样留下的是可重复的验证过程。浏览器控制还涉及另一条边界：允许访问某个网站。网页里的文字不能自动变成新的任务指令，提交信息、修改权限、删除数据等动作仍需单独判断。
手机端远程控制适合把已经定义清楚的工作继续推进。连接后，任务仍运行在电脑或电脑连接的 SSH 环境中；手机用来启动任务、追加要求、审批命令、查看 diff 和测试结果。主机需要保持在线，Windows 上涉及计算机操作时，桌面会话也要可用。
这套方式很适合查看长测试、批准一条明确命令，或者在任务跑偏时及时拉回来。需要处理复杂冲突、评估大段代码或精细检查 UI 时，回到桌面会更稳妥。
4. Hooks、SSH、Git、环境与 Worktrees
这一组功能看起来分散，其实都围绕执行环境。环境决定依赖和工具在哪里；SSH 把工作位置延伸到远程主机；Git 记录代码历史；Worktree 隔离并行修改；Hooks 则在特定节点自动运行检查或动作。
Hooks 适合做确定性工作。例如会话开始时加载项目状态，工具调用前检查危险命令，文件修改后运行扫描，任务结束前确认测试结果。用户级 Hook 可以放在 ~/.codex/hooks.json 或 config.toml，项目级配置放在仓库的 .codex/ 目录。
Hook 可以直接执行命令，也可能把输出加入模型上下文。新增或修改后的非托管 Hook 需要先审查；输出应保持短小，不要包含密钥和隐私数据。
SSH 的原则和普通远程开发一样：在 ~/.ssh/config 中配置明确别名，使用可信密钥和低权限账户，先确认 ssh <alias> 可以正常连接，再把主机加入 Codex。远程主机上要能从登录 Shell 找到 Codex。不要把 App Server 或无认证端口直接暴露到公网；需要跨网络连接时，使用合适的 *** 或安全网络。
Local、SSH 和 Cloud 没有绝对优劣。依赖已经配好的本机工具时用 Local；代码或算力在远端时用 SSH；需要容器化、后台化执行时再考虑 Cloud。无论选哪一种，安装步骤、环境变量、网络权限和验证命令都应明确。
Git 始终是底座。任务开始前确认分支和 git status，结束后看 diff、跑测试，再按逻辑提交。Fork 不会恢复代码，远程控制不会替你保存历史，Worktree 也不负责判断改动是否应该合并。
Worktree 适合多个对话同时修改同一仓库。每个任务使用独立目录和 Git 状态，就不会在同一个工作区里互相覆盖。Codex 管理的 Worktree 一般从所选分支的 HEAD 创建，初始处于分离 HEAD；后续可以在其中创建分支，也可以通过 Handoff 移回 Local。
这里有两个容易踩的坑。
第一，Git 不允许同一分支同时在多个 Worktree 中检出，这是正常保护。
第二，.env、本地证书等被忽略文件不会自动齐全，确实需要时可用 .worktreeinclude 精确声明。
5. Skill、插件、MCP 与子 Agent
这几个名字经常同时出现，但职责并不重叠。Skill 记录一套可复用的做法；插件把 Skill、MCP、Hook 等内容打包分发；MCP 提供外部数据和动作；子 Agent 接手可以独立处理的工作。
Skill 应从已经跑通的流程里长出来。发布检查、日志排查、PR 审查、固定格式的文档生成，这些流程在普通对话里稳定执行几次后，再整理成 Skill。刚想到一个点子就封装，后面往往要一边使用一边拆掉重做。
插件解决分发问题。团队需要统一安装一组 Skill、MCP 和 Hook 时，插件比手工复制配置合适。安装前要看清它能读什么、能写什么、是否会把内容发送到外部服务。
MCP 用在仓库之外：GitHub、工单、设计稿、知识库、数据库或内部服务。服务器处理认证、授权、实时数据和受控操作，Skill 负责告诉 Codex 以什么顺序使用这些工具。只需要本地文件时没必要先搭 MCP；需要外部写入时，则要把读取和修改权限分开考虑。
子 Agent 适合范围明确、结果可独立检查的任务，例如扫描受影响文件、补既定测试、归类日志、并行研究几个方案。整体目标、方案取舍和最终合并仍由主 Agent 负责。委派时至少写清输入范围、禁止事项、输出格式和验证标准。
模型也可以按角色分工：先用推理能力较强的 Sol 完成任务拆解，再把边界清楚的执行项交给速度、成本更合适的 Luna，或已接入并完成验证的 DeepSeek 模型。
可以使用OpenCodex 一类的模型路由工具把子 Agent 请求发送给选定的提供方；但接入前应核对模型能力、隐私边界、价格和失败回退策略。
还有一个常被忽略的成本：子 Agent 会独立使用模型和工具，Token 消耗通常高于单 Agent。只有当并行能减少等待，或把大量探索噪声挡在主线程之外时，委派才划算。
6. 成本、效率与 SOP
Codex 最贵的部分通常是返工。目录选错后读了一遍仓库，目标没说清便开始重构，几个 Agent 重复搜索同一批文件，对话太长导致旧结论不断回来，最后只看总结没看 diff——这些损耗往往比模型单价更大。
因此，优化顺序应该是先缩小任务，再补足相关上下文，写清约束和完成条件，最后才讨论模型与推理强度。范围明确的检索、归类和文档整理可以优先速度；架构、安全、复杂调试和高风险迁移更需要推理质量。
一条够用的任务描述通常包含以下几部分：
当然，这些任务描述也可以通过计划模式来完成。
权限也会影响效率。合适的状态是：工作区内的常规操作可以顺畅执行，越过文件、网络或系统边界时仍然可见。自动审查只是把审批请求交给独立审查 Agent，不会扩大可写目录，也不会自动开放网络。
实际工作可以收敛成一套不复杂的顺序：
确认项目、目录、分支、Git 状态和运行环境。
写清目标、相关上下文、不可触碰的边界和完成条件。
简单任务直接做；复杂任务先 /plan；长任务再设 /goal；并行修改放进 Worktree。
保持小步修改。方向不对就立即纠偏，只把真正独立的部分交给子 Agent。
运行测试、lint、类型检查和构建。涉及界面的改动，用浏览器走一遍真实流程。
查看 diff 和失败日志，区分已经验证、验证失败和没有验证的部分。
提交或创建 PR 后，把长期有效的信息写回项目文档或 AGENTS.md。重复流程稳定以后，再做成 Skill。
更多游戏资讯请关注：电玩帮游戏资讯专区
电玩帮图文攻略 www.vgover.com
