乐于分享
好东西不私藏
夜雨聆风 > > 办公文件 > Codex App 使用教程:把它当成本地项目的 AI 工作台

Codex App 使用教程:把它当成本地项目的 AI 工作台

当前时间： 2026-08-06 22:50:13 分类：办公文件 评论(0)
Codex App 使用教程:把它当成本地项目的 AI 工作台

上一篇我们把 Codex App 装好了。

但装好只是第一步。

真正容易卡住的地方，是打开 App 之后不知道该怎么下手。

很多人第一次用，会把它当成一个“更懂代码的聊天窗口”。

我一开始也差不多。

后来发现，这样用有点浪费。

Codex App 更像一个本地项目工作台：它能读代码、跑命令、改文件，也能把改动放到 Review 里让你检查。

你给范围，它干活。

但最后拍板的人还是你。

这篇不讲复杂配置，只跑一条最常用的链路：

  1. 打开本地项目
  2. ->创建 thread
  3. ->让Codex先读项目
  4. ->给一个小任务
  5. ->查看Review diff
  6. ->决定是否继续修改或提交

这条链路跑通以后，再研究 MCP、Skills、插件、自动化，会顺很多。

一、先理解 3 个核心概念

在开始操作之前，先记住 3 个词。

不用背定义，知道它们分别管什么事就行。

1. Thread

Thread 可以理解为一次任务对话。

你要分析项目、修 bug、写文档、做重构，都可以开一个 thread。

一个 thread 里，Codex 会围绕当前任务持续工作。不要把几个不相关的需求塞在一起。

更好的方式是：

  1. 一个明确任务=一个 thread

比如：

  1. 阅读这个项目并总结结构

或者：

  1. 修复登录页按钮在移动端溢出的问题

任务越干净，Codex 越不容易跑偏。

2. Local workspace

Local workspace 就是你本机上的项目目录。

比如我这台电脑上的文章项目是：

  1. D:\workspace\python\wechat-official

Codex App 打开这个目录后，就能读取里面的文件。

如果你授权它修改文件，它也可以直接在这个项目里动手。

新手第一次使用时，建议选一个低风险项目。

不要一上来就打开公司的生产仓库。

也不要一上来就让它大范围重构。

先用文档项目、demo 项目、个人工具项目练练手。

3. Review

Review 是我觉得最该认真看的地方。

Codex 修改文件后，不要只看它嘴上说了什么。

一定要去 Review 里看 diff。

你需要确认：

  1. 它改了哪些文件
  2. 每个文件具体改了什么
  3. 有没有改到任务范围外
  4. 有没有引入不必要的变更
  5. 是否需要继续让它调整

OpenAI 官方文档里也强调，Review 用来理解改动、给反馈，并决定哪些更改要保留。

所以我建议养成一个习惯：

让它做事，但最后一定自己看 diff。

二、第一次任务：只读项目，不改文件

第一次打开一个项目时，不要急着让 Codex 写代码。

先让它读。

这一步有点慢，但很值。

你可以在 Codex App 里新建一个 Local thread，然后输入：

  1. 请阅读这个项目，帮我总结：
  3. 1.这个项目是做什么的
  4. 2.主要目录结构
  5. 3.技术栈和关键依赖
  6. 4.常用启动命令和测试命令
  7. 5.如果我要继续维护，应该先看哪些文件
  9. 这次只做分析，不要修改任何文件。

这个 prompt 的重点是最后一句：

  1. 这次只做分析，不要修改任何文件。

这一步主要是判断几件事：

Codex 是否能正确读取项目？

它是否理解了目录结构？

它有没有编造不存在的命令？

如果它的回答里提到了启动命令或测试命令，你可以让它解释依据：

  1. 这些命令分别是从哪些文件里判断出来的？

好的结果应该能指向类似这些文件：

  1. package.json
  2. pyproject.toml
  3. README.md
  4. Makefile

这些都能说清楚，说明 Codex 已经读到了项目的基本轮廓。

三、第二个任务：做一个很小的修改

只读分析没问题后，再做第一个写入任务。

这里不要让它“优化整个项目”。

范围太大，风险也大。

更适合新手的任务是：

  1. 请只修改 README.md：
  3. 把 README 里的项目介绍整理得更清楚一点。
  4. 要求：
  5. -不新增虚构功能
  6. -不修改其他文件
  7. -改完后说明你改了哪些段落
  8. -不要提交 git commit

这个任务不刺激，但很适合第一次写入。

只改 README.md，范围小。

文档改错了也容易回退。

更重要的是，你能顺便观察 Codex 会不会遵守“只改一个文件”的约束。

改完后，先不要急着接受。

去 Review 里看 diff。

你要重点检查三件事：

  1. 是否只改了 README.md
  2. 有没有新增不真实的信息
  3. 语气是否符合你的项目风格

如果不满意，可以直接在 thread 里继续说：

  1. 这版太像营销文案了。
  2. 请收敛一点，保持工程项目 README 的语气。

或者：

  1. 保留原来的目录结构，只优化每段表达，不要重排整篇 README。

Codex App 好用的地方也在这里。

它不是一次性丢任务、等成品。

更常见的节奏是：

  1. 修改
  2. ->Review
  3. ->反馈
  4. ->再修改

四、任务描述怎么写更稳

Codex 能不能干好活，很大程度取决于你怎么下任务。

我建议用这个格式：

  1. 目标：
  2. 范围：
  3. 约束：
  4. 验证：
  5. 交付：

举个例子。

  1. 目标：
  2. 修复文章发布脚本在没有图片时的输出提示。
  4. 范围：
  5. 只允许修改 scripts/prepare_wechat_publish.py。
  7. 约束：
  8. 不要引入新依赖。
  9. 不要改变已有输出文件路径。
  11. 验证：
  12. 运行一篇没有图片的Markdown。
  14. 交付：
  15. 说明你修改了什么，并列出验证命令和结果。

这个格式最大的好处，是减少猜测。

Codex 知道要解决什么问题、能改哪里、不能碰哪里，也知道最后要拿什么来证明任务完成。

如果任务比较复杂，可以先让它出计划：

  1. 先不要修改文件。
  2. 请先阅读相关代码，并给出你的修改计划。
  3. 我确认后你再动手。

陌生项目里，这句话很管用。

先看思路，再让它动手。

五、什么时候用 Local thread，什么时候用 Worktree

日常使用里，可以先粗略这样分。

小任务直接用 Local thread。

比如：

  1. 解释代码
  2. 整理 README
  3. 修一个小 bug
  4. 补一个测试
  5. 调整一处样式

这类任务范围小，通常不用单独开一个隔离工作区。

但如果任务会动很多文件，就更适合用 Worktree。

比如：

  1. 重构登录模块
  2. 迁移一个组件库
  3. 批量调整目录结构
  4. 实现一个完整新功能
  5. 升级关键依赖

Worktree 的意义，是把较大的改动先隔离出去。

你可以把它理解成：让 Codex 在一个单独工作区里试方案，做完之后再决定要不要合回来。

这对探索性任务很有用。

尤其是方案还没想清楚时，别急着在主工作区里大改。

六、Review 面板应该怎么看

Codex 改完之后，Review 不要只扫一眼。

建议按这个顺序看。

我一般这样看。

先看文件列表，确认有没有改到不该改的文件。

再看每个 diff，尤其是删除、重命名、配置文件、锁文件、脚本命令。

如果它说已经验证过，就看它到底跑了什么命令。

最后再决定下一步。

你有三个常见选择：

  1. 继续让Codex修改
  2. 保留这次改动
  3. 丢弃不需要的改动

如果某一处 diff 不对，可以直接指出来：

  1. 保留第一段修改。
  2. 撤回第二段里关于自动发布的描述，因为项目里没有这个功能。

或者：

  1. 这个函数的命名可以，但不要改public API。
  2. 请重新调整，保持外部调用方式不变。

Review 不是为了挑刺。

它更像一次校准：你把自己的判断补给 Codex，后面的修改就会更贴近你的习惯。

七、Settings 里先看哪些地方

新手没必要一开始就把 Settings 翻个遍。

下面几个地方先看一眼就够了。

1. 账号和模型相关设置

确认当前登录的是你自己的账号。

如果你有多个账号，尤其要注意不要混用工作账号和个人账号。

2. Git 设置

确认 Codex App 能识别当前项目的 Git 状态。

如果 Review 面板看不到 diff，先检查项目是不是 Git 仓库。

也可以在终端里跑：

  1. git status

3. Browser 和 Computer Use

这些能力适合需要打开网页、检查页面、操作桌面应用的场景。

但它们不是入门必需项。

刚开始先把本地项目工作流跑通。

等你需要截图、网页登录、页面验证时，再单独配置这些能力。

4. MCP、Skills、Plugins

这些属于增强能力，可以让 Codex 连接更多工具，或者按固定工作流做事。

比如你现在看到的这篇文章，就可以配一个公众号发布相关的 skill：

  1. Markdown源稿
  2. ->公众号排版稿
  3. ->图片清单
  4. ->发布检查项

但这不是第一天必须学会的东西。

先把“读项目、改文件、看 diff”练熟，比堆配置更实在。

八、一个适合每天使用的工作流

我现在更愿意把 Codex App 当成日常项目工作台。

不是出问题了才打开。

有时候刚进入项目，也可以先让它帮你热身。

比如：

  1. 请阅读当前 git diff，总结我这次改动的意图，并指出可能需要补测试的地方。
  2. 不要修改文件。

或者：

  1. 请根据最近的改动，帮我整理一段 commit message。
  2. 不要执行 git commit。

再比如写文章项目：

  1. 请检查 articles 目录下这篇Markdown：
  2. 1.是否适合手机端阅读
  3. 2.段落是否过长
  4. 3.图片占位是否清楚
  5. 4.是否有不适合发布到公众号的敏感信息
  7. 先只给建议，不要修改文件。

这些任务都挺适合 Codex。

它不一定每次都要写代码。

读代码、审 diff、整理文档、生成清单，很多时候更省时间。

九、不要一上来就做这些事

新手用 Codex App，最容易踩的坑不是按钮找不到。

而是任务给得太大。

不建议一上来就说：

  1. 帮我重构整个项目

也不建议说：

  1. 帮我全面优化代码质量

这种任务太空，Codex 很难判断你到底想要什么。

更稳的说法是：

  1. 请先阅读 src/auth 目录，找出重复逻辑。
  2. 先给重构建议，不要修改文件。

或者：

  1. 请只重构 src/auth/session.ts。
  2. 保持外部 API 不变。
  3. 改完后运行相关测试。

范围清楚时，Codex 像助手。

范围模糊时，它只能猜谜。

十、我的入门建议

如果你刚开始用 Codex App，可以按这 5 天练。

第一天，只读项目。

让它总结目录、技术栈、启动命令。

第二天，改文档。

只改 README 或一篇 Markdown。

第三天，修一个小 bug。

范围限制在一个文件或一个函数。

第四天，补测试。

让它先找测试入口，再写最小测试。

第五天，看 Review。

专门练习怎么读 diff、怎么给反馈、怎么决定保留哪些改动。

这 5 天走完，你对它的感觉会变。

它不只是一个问答工具，而是能参与项目流程的工作台。

总结

Codex App 入门，不需要把所有高级功能一次性学完。

先养成一条安全工作流：

  1. 先读
  2. 再小改
  3. 看 diff
  4. 给反馈
  5. 再决定是否保留

坚持这个节奏，Codex App 就不会变成一个让人心里没底的自动改代码工具。

你负责判断方向。

它负责读文件、跑命令、改细节、整理结果。

这样用，才比较踏实。