Codex 桌面版怎么用：从打开项目到审查第一份改动

普通聊天最常见的用法，是贴一段代码、拿到一段建议，再由你自己搬回项目。Codex 的不同不在于“回答更像程序员”，而在于它可以围绕一个真实目录连续工作：先读项目规则和相关文件，再修改、运行命令、查看结果，最后把差异留给你处理。

这条工作链才是桌面版的价值。比如修复一个手机端横向滚动问题，真正费时间的往往不是写两行 CSS，而是找到溢出的元素、确认桌面端不受影响、运行构建、查看改动范围，再处理审查意见。Codex 可以把这些步骤串起来，但接受哪一行代码、是否提交和何时发布，仍然是你的决定。

只打开这次要处理的项目目录，不要直接选择桌面、下载目录或个人主目录。项目边界越清楚，Codex 越不容易读到无关文件，你也越容易判断一次权限请求是否合理。

接着看一眼 git status。这个动作很朴素，却能避免最常见的误会：桌面版 Review 展示的是当前 Git 工作区里的全部变化，包括你自己原来没提交的修改，并不只统计 Codex 本轮写下的内容。已有工作如果重要，先保存、提交，或者至少记清哪些文件本来就脏。

• 问题能否稳定复现；如果可以，记下最短复现步骤。
• 项目实际使用什么测试、构建或预览命令。
• 哪些文件、接口、数据或现有改动绝对不能碰。
• 完成后你准备用页面、测试结果还是代码差异验收。

让 Codex 从空目录生成一个落地页，看起来很惊艳，却几乎测不出它是否理解真实项目。更好的第一次任务，是修一个你已经能看到、结果只有“通过”或“没通过”的小问题。选择 Local，因为你需要用现有浏览器、开发服务器和本机环境马上验收。

下面这段可以直接改成自己的任务。它没有角色扮演，也没有要求“深度思考”；每句话都在减少跑偏空间。

• 目标：修复 375px 宽度下出现的横向滚动。
• 复现：运行现有开发服务器，打开指定页面，把视口调到 375px。
• 先做：找出真正溢出的元素并说明原因，确认后再修改。
• 边界：不要改变桌面布局，不新增依赖，不顺手重构无关组件。
• 完成：运行项目现有构建和相关测试；最后列出改动文件、执行过的命令，以及仍需人工查看的地方。

第一次保持默认权限就够了。正常的小修复通常只需要读写项目目录、运行本地命令；如果它突然要求访问项目外目录、开启网络或执行高风险命令，先看清理由，不要因为想让任务继续就一律允许。官方的默认沙箱本来就是为了把写入范围限制在工作区，并在越界时停下来询问。

一个靠谱的执行过程通常能看到几类证据：它读了项目规则和相关文件，找到了复现路径，修改范围不大，并且实际运行了检查。相反，如果还没定位原因就开始批量改文件、为了一个小问题新增依赖，或者反复宣称“已修复”却拿不出命令输出，就应该立即用后续消息把它拉回来。

• 权限请求与任务有关吗？能否只批准这一次，而不是永久放宽。
• 读取的文件是否围绕问题，还是开始扫描无关目录。
• 新增依赖是否真的必要，现有工具能否完成。
• 测试或构建是确实执行了，还是只在最终总结里写了“应该通过”。

任务结束后先忽略那段流畅的总结，打开 Review，从文件列表开始看。第一问不是“代码优不优雅”，而是“它为什么动了这些文件”。范围不对，后面的实现再漂亮也不值得继续审。

Review 面板可以查看未暂存、已暂存、提交、分支或最近一轮的差异，也可以按文件或代码块暂存、撤回。对具体一行有疑问时，直接留下行内评论，再发送“处理这些评论，保持改动范围不变”，通常比重新描述整个任务更精准。

• 范围：是否只改了任务需要的文件，有没有顺手格式化或重构一大片。
• 行为：删掉的判断、错误处理和兼容逻辑是否仍然需要。
• 证据：测试、类型检查、构建和页面验证分别运行了什么，结果是什么。
• 残留：调试日志、临时文件、无用依赖和被跳过的检查是否还在。

Worktree 不是“更安全的 Local”按钮，而是同一个 Git 仓库的另一份检出目录。它最适合这种场景：你正在 Local 启动开发服务器和改当前功能，同时想让 Codex 在后台尝试另一个独立任务。完成后可以留在 Worktree 创建分支，也可以使用 Handoff 把聊天和代码接回 Local。

第一次用 Worktree 最常见的失败不是 Codex 不会写，而是项目根本跑不起来。新的检出目录可能没有 node_modules，也不会自动拥有被 Git 忽略的 .env 文件。把安装和初始化命令写进本地环境的 setup script；确实需要复制的忽略文件，可以谨慎列进 .worktreeinclude。不要为了省事把整个密钥目录都复制过去。

Cloud 会在 OpenAI 托管的容器中检出你选择的仓库分支或提交，运行 setup script，然后让代理修改和验证代码。它不会看到你电脑上尚未推送的文件，也不会继承一个只能在你本机复现的临时状态。代理阶段的网络访问默认关闭，需要时必须在环境中明确配置。

因此，Cloud 适合输入和验收都能从仓库重建的任务，例如运行完整测试、处理明确的 CI 失败、做范围清楚的跨文件修改。依赖本地数据库、未提交素材、已登录浏览器或只在你电脑上出现的问题，先留在 Local；否则你会花更多时间解释环境，而不是解决问题。

• 适合：仓库已推送，安装命令明确，任务可以通过测试或差异验收。
• 不适合：问题只在本机出现，依赖未提交文件、个人登录状态或特殊硬件。
• 先确认：运行时版本、setup script、必要环境变量和网络白名单都已配置。

很多新手一开始就折腾模型、Skills、MCP 和自动化，结果项目本身连测试命令都没告诉 Codex。更有效的顺序是先做两三个真实任务，记录它重复犯的错误，再把稳定规则写进 AGENTS.md。这个文件会自动进入 Codex 的项目上下文，内容越具体越有用。

不要写“保持高质量”“认真思考”这类无法验收的口号。写清目录、命令、边界和完成定义。只有一套流程已经手动跑通多次，才值得整理成 Skill；只有任务不需要你临场判断，才考虑定时运行。

• 项目从哪个目录运行，哪些目录只是生成物。
• 测试、构建、格式化和本地预览分别使用什么命令。
• 哪些接口、迁移、密钥文件或用户已有改动不能擅自碰。
• 任务结束前必须检查什么，最终汇报需要包含哪些证据。

OpenAI 当前把 Free 定位为体验快速、小型的 Codex 任务，把 Plus 定位为每周进行几次聚焦的编码工作。订阅升级能改变可用额度和部分能力，但不会替你补齐复现步骤、项目规则或验收标准；上下文混乱时，换更高套餐仍然会得到混乱的改动。

先用 Free 完成三个真实任务：一个小修复、一次测试补充、一次只读代码审查。如果工作链已经顺手，但任务经常在完成前被额度打断，再比较 Plus。只是偶尔改一个文件时，Free 已经足够判断 Codex 是否适合你。