许多人第一次打开 Codex，脑子里会冒出一个问题：

它到底能不能替我把项目做完？

这个问题不算错，但问早了。

对新手来说，真正的门槛不是“AI 写代码强不强”，而是你能不能看见它在做什么、限制它做什么、判断它做得对不对。

所以，Codex 新手的第一课，不是学会更多命令，也不是追问哪个模型最强，而是先学会一件事： 把 AI 的工作过程管起来。

先别把 Codex 当成程序员替身

许多人一上来就想让 Codex “帮我做一个完整项目”。

这当然很诱人，但对新手并不友善。

更好的起点，是把 Codex 当成一个会读项目、会解释上下文、会提出修改方案、会执行小任务的协作台。它的价值不是神奇地把你带到终点，而是让你每一步都能知道：

它读了什么？

它准备改什么？

它已经改了什么？

它怎么证明自己改对了？

这就是 Codex 和许多低门槛 AI 编程工具的差异。低门槛工具更适合让你快速看到结果；Codex 更适合训练你把模糊想法拆成任务，再把 AI 的执行结果验收回来。

如果你只是想体验“AI 帮我做出一个页面”，它未必是最轻松的第一个工具。

但如果你想长期掌握 AI 编程协作，Codex 很适合当作你的工作方法训练器。

第一步：只让它读项目，不要让它改项目

新手第一小时，提议只做一件事：让 Codex 解释项目。

你可以这样问：

请先阅读这个项目，不要修改任何文件。请告知我：
1. 这个项目是做什么的
2. 入口文件在哪里
3. 主要目录分别负责什么
4. 本地如何运行、测试、构建
5. 如果我要改一个很小的页面文案，最可能改哪里

这个动作的意义，不是让 Codex 炫耀它会读代码，而是帮你建立项目地图。

你至少要知道入口、模块、运行方式和测试方式。否则后面它给你改了十个文件，你只会被动点头。

上下文越强，越需要你先划定边界。

第二步：只让它做一个小改动

不要第一天就说：

“帮我重构整个项目。”

“帮我做一个完整系统。”

“帮我把产品优化一下。”

这些任务都太大，也太模糊。新手最好的第一个任务，是一个小到可以肉眼验收的改动：改按钮文案、修一个明显样式问题、加一个小校验、补一条测试。

任务越小，你越容易学习 Codex 的工作循环。

可以这样问：

请只完成一个小改动：把首页按钮文案从 A 改成 B。
要求：
- 只改必要文件
- 改完后说明改了哪些文件
- 展示 diff 摘要
- 如果项目有测试或构建命令，请运行并告知我结果

这时你要盯住三件事：

它有没有改超范围？

diff 是否符合预期？

验证是否真的跑过？

新手和高手的差别，往往不是谁更会写 prompt，而是谁更会验收结果。

第三步：任务一模糊，就先 /plan

只要任务开始变得模糊，列如“优化页面”“增加登录功能”“整理知识库”“做一个新模块”，就不要直接让 Codex 开改。

先让它计划。

请先进入计划阶段，不要修改文件。
目标：为这个项目增加 X 功能。
请输出：
1. 你需要先阅读哪些文件
2. 你理解的功能边界
3. 可能的实现步骤
4. 风险点
5. 验收标准

好的 AI 协作不是一次性命令，而是一个循环：提出目标、补足上下文、设计检查方式、执行、再回看。

/plan 的作用，就是在执行前先把这个循环搭起来。

新手最容易犯的错，是把“我想要什么”直接丢给 AI，然后期待它自己补完所有隐含条件。

Codex 可以补，但它补出来的东西未必是你想要的东西。

第四步：长任务再用 /goal

当任务已经跨越多个步骤，列如要改代码、跑测试、修错误、再总结经验，就可以思考使用 /goal 。

但 /goal 不应该接一个空泛目标。

不好的目标是：

/goal 帮我优化这个项目

更好的目标是：

/goal 完成登录页表单校验改造。
验收标准：
1. 邮箱格式错误时显示提示
2. 密码少于 8 位时阻止提交
3. 现有测试通过
4. 新增或更新必要测试
5. 最后给我一份修改摘要和后续风险

/goal 的价值，不是“让 Codex 更自动”，而是让它在较长任务里持续记住验收标准。

目标越清楚，自动化越有意义。

目标越模糊，自动化越容易把你带偏。

第五步：把重复流程沉淀下来

当你发现自己反复写同一种要求，列如：

“先读项目，不要改文件。”

“给我风险点和测试命令。”

“先输出计划，等我确认再执行。”

这就说明它不只是一个 prompt，而是一个流程。

这时再思考把它沉淀成技能、模板或自动化。

不要第一天就把所有高级能力打开。高级能力不是装饰品，它们是为稳定流程服务的。

一个适合新手沉淀的流程可能是：

每次接到新项目时：
1. 先读 README、package、入口文件
2. 输出项目地图
3. 找到运行和测试命令
4. 标出高风险目录
5. 不改文件，等待我确认下一步

这类流程比“帮我写代码”更值钱，由于它训练的是协作习惯。

新手最容易踩的 6 个坑

第一，一上来问“哪个 agent 最强”。真正影响结果的，是你能否给出边界、上下文和验收标准。

第二，让 Codex 直接大改。新手应该从小改动开始，先练 diff 和测试。

第三，不看 diff 就接受。只要你没看改了哪些文件，就还没有完成协作。

第四，不跑验证。能跑测试就跑测试，不能跑也要让 Codex 说明它为什么不能跑、残留风险是什么。

第五，把 /goal 当许愿池。目标必须有完成条件，否则 Codex 只能猜。

第六，把别人的索引当教程。索引能提供方向，但只有逐篇读过、验证过、放进自己的流程里，才算真的变成知识。

一个 7 天上手练习

第 1 天：只让 Codex 读一个项目，输出项目地图，不改文件。

第 2 天：让它做一个小文案或样式改动，重点看 diff。

第 3 天：让它找到运行、测试、构建命令，并解释每个命令的作用。

第 4 天：给一个稍微模糊的任务，让它先 /plan ，你只审计划。

第 5 天：让它按计划完成一个小功能，要求跑测试并写修改摘要。

第 6 天：尝试一个 /goal ，但目标必须写清验收标准。

第 7 天：让 Codex 总结这一周反复出现的流程，整理成你自己的使用模板。

5 个可以直接复制的 prompt

项目地图：

请阅读项目，不要修改文件。请输出项目用途、入口文件、主要目录、运行方式、测试方式，以及新手最该先理解的 5 个文件。

小改动：

请只完成这个小改动：{任务}。只改必要文件。完成后说明改动文件、核心 diff、验证命令和结果。

先计划：

这个任务还不够明确，请先不要改文件。请给出实现计划、需要确认的问题、风险点和验收标准。

验收：

请根据刚才的修改做一次验收：检查是否满足目标、是否有超范围改动、是否通过测试、还有哪些残留风险。

沉淀：

请把这次协作中可复用的流程总结成一个下次可直接使用的模板，包含输入、步骤、检查点和完成标准。

最后

Codex 新手不需要先成为程序员，也不需要先掌握一堆命令。

你真正要学的是三件事：让它看清上下文，让它在边界内行动，让它交出可验收的结果。

如果说 vibe coding 的第一步是“把想法做出来”，那么 Codex-first 的第一步是“把 AI 的工作过程管起来”。

这条路一开始可能没有那么爽，但它会让你更快从“会让 AI 生成东西的人”，变成“能带着 AI 完成项目的人”。