很多人第一次用 Codex 是这么开始的：装好、打开、扔一句「帮我改个 bug」，结果它改了一堆不该改的文件，或者干脆卡在权限询问上。问题通常不在模型，而在上手顺序。这篇按新手真实会走的流程拆一遍：先搞清它是什么形态、第一个任务该多小、上下文和权限怎么给、出问题按什么顺序排查，每一步都给出能照着做的动作。
很多人第一次用 Codex 的流程都差不多：装好、打开、扔一句「帮我改个 bug」，然后它改了一堆你根本没让它动的文件，或者干脆卡在权限询问上不知道点哪个。问题通常不在模型强不强，而在上手顺序不对。先搞清楚你面对的到底是什么形态的工具，再决定第一个任务给多大，最后才是上下文和权限怎么配。
下面按新手真实会走的顺序拆一遍，每一步都给能照着做的动作和判断标准。整篇不写具体数字，涉及价格、能力对比之类的量化信息，都去站内对应页面看当时的情况。
先分清：Codex 不是聊天框，是能动手的那一类
聊天框只把代码贴给你，你自己复制粘贴；Codex 这类工具是直接读你的项目文件、直接改、有时还直接跑命令。这个区别决定了它的出错成本高一档——聊天框答错了你笑笑重问，它改错了是污染你的工作区。所以第一步不是学指令技巧，是先接受「它会动手」这个前提。
- 聊天式工具
- 给你代码片段，改动由你自己落地，出错可控
- 能动手的编码工具
- 直接读写项目文件、执行命令，出错会留痕，需要你事后收拾
- 入口差异
- 命令行、IDE 插件、网页端能碰到的文件范围和权限不一样，先确认自己用的是哪种
- 先确认入口：你现在是在命令行、IDE 插件还是网页端用它，三种能触达的文件范围不一样，决定了它「看得见」什么
- 再确认权限：它能不能自动执行命令、能不能自动提交，新手阶段这两个开关建议都保持每次确认
- 名词看不懂别猜，去站内 AI 术语词典把「上下文」「工具调用」「diff」这几个词过一遍
- 和通用概念文的区别：那类文章讲的是这类工具的共同逻辑，这篇只讲 Codex 怎么迈出第一步
第一个任务要小到不可能失败
新手最常见的翻车方式是第一个任务就选「重构整个模块」或者「修一个我还没搞清原因的老 bug」。范围一大，你自己都判断不了它改得对不对，只能凭感觉接受或拒绝，学习效果为零。正确做法是选一个单文件、目标明确、跑一下就能看到结果的任务。
- 挑任务从单文件里选：给某个函数补注释、改一处文案、给一个参数加校验，三选一都行。判断标准是：你能用一句话说清改哪里、改成什么样。
- 写指令把「改哪里、改成什么样、不要动什么」三句话说全。比如「只改 A 函数，加非空判断，不要动其他函数和 import」。
- 验收做完先看 diff 再点接受。接受前问自己：这处改动如果是我同事提的 PR，我会不会直接合并。答不上来就先不合并，让它解释。
- 留退路第一次用尽量在干净的工作区或单独分支上试，改坏了能整体回滚，不用一条条对着 diff 撤。
这套流程的意义不是把任务做漂亮，是让你在低风险环境下先摸清它的行为习惯——它默认会改哪些文件、会不会顺手加依赖、解释风格是什么样。
上下文和权限：给少了它乱猜，给多了它乱改
这两件事是新手最容易走极端的：要么什么都不说，指望它自己看懂项目；要么一股脑全开权限，图省事。前者让它按猜的写，后者让它按猜的改，风险方向不同但都不可控。
| 情况 | 典型表现 | 怎么处理 |
|---|---|---|
| 上下文给少了 | 它按常见写法猜命名、猜目录结构，结果和项目约定不一致 | 涉及命名、目录、依赖约定时在指令里点明，别指望它读心 |
| 上下文给多了 | 长任务跑到一半开始「忘事」，前面说过的约束后面又不遵守 | 拆成几轮小任务，每轮只带这轮需要的背景 |
| 权限收太松 | 自动执行命令、自动提交，出了问题才发现它动过你没想到的地方 | 新手阶段保持每次确认，等摸清了再考虑放开 |
| 权限收太紧 | 每一步都弹确认，跑到一半你自己烦了开始无脑点同意 | 把不涉及写操作的读取权限先放开，写操作保留确认 |
想知道上下文到底怎么算、token 大概怎么估，别凭感觉拍脑袋，去站内关于上下文长度和 token 估算的对应页面看当时的说明。
出问题按这个顺序查，别一上来就换模型
新手遇到效果不好，第一反应通常是「是不是模型不行，换一个」。换模型应该是排查顺序里的最后一步，因为前面几步的命中率比它高得多。
- 第一步：查它读到了什么很多「答非所问」本质是它根本没看到你指的那个文件。先确认它这轮实际读了哪些文件，再谈别的。
- 第二步：查指令歧义把「优化一下」换成「把这个函数的循环改成提前返回」，把「修下这个 bug」换成「这个函数在输入为空时会报错，加上判断」。多数问题到这一步就解决了。
- 第三步：查工程问题权限被拦、依赖没装、环境变量或路径不对，这类和模型无关，看报错信息就能定位。
- 第四步：才考虑换方案前三步都排除了，再考虑是模型能力不够，或者换个入口（比如从命令行换到 IDE 插件）试试。
新手期自查清单
下面这份清单按任务前、中、后三段分，用的时候不用全勾，但每一段的第一个问题答不上来，就说明这一步还没准备好。
- 任务开始前：范围能不能用一句话说清？涉及的文件能不能数出来？数不出来就是范围太大
- 任务进行中：每一步改动你是不是都看得懂？有没有出现你没让它碰的文件
- 任务结束后：这处改动能不能单独回滚？有没有留下需要你手动补的收尾工作
- 连续两次效果都不好，就停下来改指令，而不是重复同样的问法指望它这次能懂
- 同一个任务换过一次模型还是不行，就先回退到更小的任务范围，别硬扛
还有一个容易忽略的点：什么情况下这套流程不适用。如果你面对的是一段完全陌生、连输入输出都搞不清的老代码，先自己读一遍再让工具介入，比让它替你先理解要稳；工具擅长的是你已经能描述清楚目标的任务，不是替你搞清楚目标。
下一步如果你正在几个入口或几个中转站之间犹豫，别只看宣传，去站内对比页面核对当时的参数和可信度记录，再用一个最小任务实测一遍，比看介绍有用。→常见问题
完全不会写代码，能用 Codex 吗？
能跑起来，但会比较累。它擅长的是在你已有项目里做具体改动，如果你连「改完之后对不对」都判断不了，就很容易接受它的错误改动。建议先用它做读代码、加注释、解释报错这类低风险的事，等能看懂 diff 了再让它动手改。想先补编程底子，站内有专门讲新手怎么边聊边学的页面可以对照着走。
为什么它总是改到我没想到的地方？
多数时候是你给的边界不清。它只按指令理解范围，你没说「只改这个文件」「不要动公共方法」，它就按最合理的改法来。下次指令里明确写出允许改的文件、禁止动的部分，以及改完要满足什么条件，范围一收窄，跑偏的概率会明显下降。
用它写代码，额度是不是很容易就用完了？
取决于任务颗粒度和入口。一次性丢大范围重构，消耗会明显高于拆成几轮的小任务。新手阶段建议先做小任务，顺便观察每次大概花多少。具体某档套餐的额度和折算口径，去站内编程套餐目录里按当前档位核对，别用别人几月前的截图当准。
