Appearance
Codex 是什么：先做一次只读项目体检
很多人第一次听说 Codex，脑子里蹦出来的画面是"一个会写代码的 ChatGPT"。也不能说错，但这个印象会让你踩两个坑：一是它不了解你项目的时候会瞎猜，二是它真的能干很多事情，多到你没准备的时候会吓一跳。
所以这篇文章不跟你讲大道理，直接带你做一件事：用 Codex 给自己的项目做一次体检，只看不改。跑完这一趟，你自然就知道 Codex 到底是个什么东西了。
先说一下：如果你不写代码，日常工作是做 PPT、写文档、搞电商、做研究这些，那 Git 仓库体检不是你的起点。建议先去 普通人完整学习路线，那边用 ChatGPT Work 就能上手，不需要终端和命令行。本页往下是开发者路线。
说白了，Codex 是个什么东西
你问 ChatGPT 一个问题，它给你一个答案，对话结束。
Codex 不一样。你给它一个目标，它会自己循环：看看当前情况 → 决定下一步干什么 → 调工具执行 → 看结果对不对 → 继续修正。一直循环，直到把事干完。
所以它不只是"会聊天的 AI"，而是一个能进到你项目里干活的代理。比如：
- 把你的仓库翻一遍，画出真实的代码调用链
- 跑测试，看到报错，自己定位到出问题的地方
- 改好几个文件，然后给你看
git diff - 打开本地页面，检查界面是不是真的能用
- 读你的文档、表格、截图，生成新的交付文件
- 通过 MCP 或插件去访问你授权的第三方工具
关键是，你不只是看它输出的"答案"。你真正要盯的是三样东西：它干了什么、你能怎么验证、到底改了什么。
Codex 的四种打开方式
Codex 有四个入口，很多新人在这里就懵了。简单说一下每个适合干嘛：
| 入口 | 最适合干什么 | 你怎么验收 |
|---|---|---|
| ChatGPT 桌面应用里的 Codex | 复杂任务、长任务、需要预览文件、浏览器验证、Git 审查 | 看任务进度、文件预览、diff、终端结果 |
| Codex CLI（命令行） | 终端党、服务器上干活、脚本、CI/CD、精确复现 | 看命令输出、工作树、退出码、JSONL |
| IDE 扩展 | 围绕当前文件或选中的代码快速修改 | 看编辑器上下文、局部 diff、诊断信息 |
| Codex Cloud | 隔离环境里并行跑任务、远程实现、提 PR | 看云环境配置、任务 diff、云端验证 |
不管用哪个入口，本质都一样：让代理在一个你能控制的环境里把活干了，然后你来检查证据。
实操：给你的项目做一次只读体检
废话不多说，直接动手。找一个你熟悉的 Git 仓库。
先记录一下现在的状态：
bash
cd /path/to/your-project
git status --short --branch然后在 Codex App 里打开这个目录，或者从仓库根目录运行：
bash
codex --sandbox read-only把下面这段话发过去：
text
只做只读的项目体检，不要改任何文件，也不要装依赖。
请基于仓库里的真实文件回答：
1. 这个项目解决什么问题，主要入口在哪里；
2. 启动、测试、构建命令分别是什么，证据来自哪些文件；
3. 一次典型请求或用户操作会经过哪些模块；
4. 当前最需要我人工确认的三个风险是什么；
5. 列出你实际读过的关键文件路径。
信息不够就直接说缺什么，不要根据常见框架来猜。你看到的输出应该长这样
靠谱的结果应该引用你项目里的真实路径，比如 package.json、pom.xml、go.mod、入口文件或者部署配置。如果它只说"这个项目看起来像一个常见的前后端项目"——那等于什么都没说。
别急着收工，再追问一句：
text
把"启动命令"的判断逐条对应到配置文件里的具体字段，并说明哪些命令你还没有实际跑过。这一步很关键，能帮你分清楚三样东西：
- 事实：配置文件里白纸黑字写着的
- 分析：Codex 根据代码结构推断的
- 猜测：还没跑过、没法确认的
收工后核对工作树
任务跑完之后再执行一次：
bash
git status --short输出应该跟你开始前一模一样。如果多了新文件或者有修改，先用 git diff 和 git status --short 搞清楚来源，不要上来就 git clean 或 git restore 清掉。看看 Codex 到底动了什么，这本身就是最好的学习。
什么任务适合丢给 Codex
不是什么活都适合让 AI 干的。满足以下条件的，是最佳候选：
- 输入明确：有仓库、有报错日志、有截图、有数据文件、有需求文档，总之一句话——有东西可以"给"它
- 结果可以检查：测试有没有过、页面有没有变化、文件有没有生成、diff 对不对，总之你能自己验证
- 范围可以圈定：别说"帮我优化一下项目"，要说"改这个文件里的这个函数"
- 搞砸了能回退：Git 能回滚、文件能恢复、数据库有备份
- 结论能被验证：它说的每句话你都能回到代码、命令或来源里去核对
反过来，下面这些绝对不要直接交给它全自动跑：
- 需求本身还在扯皮、没定论
- 涉及到生产数据库、没法恢复的
- 涉及付款、发布、对外操作
- 需要替你做法律或商业承诺的
- 光说"帮我优化一下"，没有任何具体验收条件
新手最容易掉的三个坑
坑一：模型很强，就不用给上下文了？
Codex 确实能自己翻仓库，但它不知道你们团队口口相传的那些业务约束。关键的限制条件——写进任务里、写进 AGENTS.md 里，比让它事后猜靠谱一万倍。
坑二：代码都写出来了，问题就解决了？
代码只是候选方案。它写出来的代码跑不跑得通、测不测得过、部署上去有没有问题——测试结果、运行日志、浏览器行为、数据检查，这些才是真正的证据。
坑三：权限给满，成功率就高？
权限只决定"能不能做"，不决定"该不该做"。新手上来就用只读或者 workspace-write，确实需要的时候再逐步放权。说个真事：我第一次用的时候没经验，给了完全权限，结果它把我好几天的代码给 rebase 了——找都找不回来。从那以后我每次都先跑 git status 再开权限。
下一步
不确定用哪个入口？先看 选择 App、CLI、IDE 还是云任务。
已经选好入口了？直接进 安装、登录与环境检查。