# 普通人用Codex的第一个完整工作流
**作者**: Oldeng
**日期**: 2026-05-24T07:35:28.000Z
**来源**: [https://x.com/dengdry/status/2058451803235107233](https://x.com/dengdry/status/2058451803235107233)
---
你第一次打开 Codex，项目目录就在眼前。
你想让它帮你改个页面，但手悬在输入框上半天，不知道该怎么开口。
你怕它乱改文件。
怕它跑一堆你看不懂的命令。
更怕它最后说“完成了”，其实项目已经被改坏了。
问题不是你不会写 prompt。
是你还没学会让 Codex 按工作流干活。
这篇只讲一件事：
普通人第一次用 Codex，怎么从看项目、定计划、改文件、跑验证，到最后看 diff，完整跑完一个小任务。
你把这一轮跑通，比收藏一百条神奇 prompt 都有用。
很多人看完 Codex 指令教程，还是不会用。
不是因为他不知道 /init、/model、/review 是什么。
而是他不知道这些指令怎么串起来，变成一次完整工作流。
Codex 不是许愿池。
它更像一个坐在你项目目录里的 AI 同事。
你如果只丢一句：
“帮我改一下这个项目。”
然后就开始慌。
它读了哪些文件？
它准备怎么改？
它有没有动到不该动的地方？
它说改好了，是真的改好了，还是只是嘴上说说？
它很可能会做，但你很难控制它做得对不对。
## 太长不看版
如果你已经装好 Codex，第一次进项目，可以直接照这个流程走：
1. 打开项目目录
2. 让 Codex 先看目录结构
3. 让它说明项目怎么启动
4. 让它先给修改计划，不要马上动手
5. 确认范围后再让它改
6. 让它跑测试或启动命令
7. 用 /diff 看它到底改了什么
8. 用 /review 让它自己检查一遍
9. 你再人工看一眼关键页面或关键文件
一句话：
不要把 Codex 当成许愿池，要把它当成一个需要交代任务、检查结果的 AI 同事。
今天你只需要练一个动作：
让 Codex 完整改完一个很小的地方，而不是让它一次性接管整个项目。
## 一、新手为什么会卡住
很多人第一次用 Codex，会有一种很奇怪的感觉：
它好像很强。
但我不敢让它动。
原因很简单。
你不知道它在干什么。
比如你想改一个网页按钮颜色，直接说：
“把按钮改成蓝色。”
这句话对人来说很清楚。
但对 Codex 来说，它至少要先搞明白：
项目是什么框架？
按钮在哪个文件？
样式写在 CSS、Tailwind、组件库，还是内联 class 里？
这个按钮有没有复用？
改了会不会影响别的页面？
它如果不先读项目，直接改，就很容易改错地方。
新手用 Codex 最重要的意识是：
不要急着让它写代码，先让它认识现场。
你不是在聊天框里让 AI 凭空生成一段代码。
你是在你的电脑里，把一个真实项目交给它处理。
真实项目有目录、有依赖、有启动方式、有测试、有历史代码风格。
这些东西不看清楚，后面就会乱。
今天你可以先做一个小动作：
打开任意一个项目，先别让 Codex 改代码，只问它：
“这个项目是什么？主要文件在哪？启动命令可能是什么？”
## 二、第一步：先让它看目录
进项目以后，第一句话不要说“帮我改”。
先说：
请先看一下这个项目的目录结构，告诉我：
1. 这是什么类型的项目
2. 主要代码可能在哪些目录
3. 启动和测试命令可能是什么
4. 你建议先读哪些文件
先不要修改任何文件。
最后那句很重要：
先不要修改任何文件。
这不是不信任它。
这是让它先进入观察状态。
你第一次带一个新人进项目，也不会上来就让他改核心代码。
你会先让他看目录，看 README，看 package.json，看现有代码怎么写。
Codex 也是一样。
它很擅长读文件，但你要先让它读。
常见错误是，上来就把需求讲得很大：
“帮我优化一下整个项目。”
这句话听起来正常，其实范围太虚。
更好的做法是先让它画地图。
今天的小动作：
只让 Codex 读项目，不让它改项目。
这一轮跑完，你至少知道项目的入口在哪里。
## 三、第二步：让它说明项目怎么启动
很多新手不敢用 Codex，还有一个原因：
项目自己都跑不起来。
所以第二步不是改功能，而是确认项目怎么启动。
你可以直接问：
请你判断这个项目应该怎么安装依赖、怎么启动开发环境、怎么运行测试。
如果有 README、package.json、pyproject.toml、requirements.txt、Makefile 之类的文件，请优先参考这些文件。
先给我结论，不要执行命令。
它一般会告诉你类似：
npm install、npm run dev、npm test。
或者：
pnpm install、pnpm dev、pnpm test。
这一步的意义不是让你背命令。
而是让你知道：
这个项目的基本生命体征是什么。
能不能启动。
怎么验证。
后面 Codex 改完代码，不能只说“我改好了”。
它必须能跑验证。
常见错误是，项目还没跑起来，就开始让 Codex 加功能。
这就像车还没点火，你已经在讨论怎么漂移。
今天的小动作：
让 Codex 找出这个项目的三个命令：
安装依赖命令、启动开发环境命令、测试或构建命令。
哪怕你暂时不执行，也先把验证路径找出来。
## 四、第三步：让它先写计划
到了这里，很多人又会急着说：
“好，那你改吧。”
别急。
先让它写计划。
比如你的需求是：
“我想把首页改成一个更适合个人作品集的页面。”
不要直接让它动手。
你可以这样说：
我想把首页改成个人作品集风格。
请你先给一个修改计划，包括：
1. 你准备改哪些文件
2. 每个文件准备改什么
3. 哪些地方可能有风险
4. 改完以后你准备怎么验证
先不要修改文件，等我确认。
这一步非常关键。
因为它会把“脑子里的行动”摊开给你看。
你不一定能看懂每一行代码，但你至少能看懂它准备动哪些地方。
如果它说要改 20 个文件，你就要警惕。
如果只是改一个首页，却要动登录、接口、数据库，那就明显不对。
新手控制 Codex，靠的不是自己马上变成高级程序员。
而是先学会看范围。
小需求，小范围。
这句话记住。
常见错误是，你脑子里只有一个模糊目标，却让 Codex 直接开始改。
比如：
“帮我把网站做得高级一点。”
这不是需求。
这是感觉。
Codex 可以帮你把感觉拆成任务，但你要先让它拆。
今天的小动作：
让它先回答一句话：
“为了完成这个需求，你准备改哪些文件？”
如果它答不上来，或者答得太散，就别急着批准。
## 五、第四步：只批准一个小任务
第一次用 Codex，千万不要一口气让它做大改版。
不要说：
“帮我把整个项目重构一下。”
也不要说：
“帮我做一个完整 SaaS。”
新手第一天，最适合做这种任务：
把首页标题和按钮文案改掉。
给导航栏增加一个入口。
修一个明显的样式问题。
把 README 里的启动说明补全。
你可以这样批准：
可以。先只改首页相关文件。
不要改登录、接口、数据库、配置文件。
改完以后告诉我你改了哪些文件，并运行你认为必要的验证命令。
这几句话看起来啰嗦，但对新手很有用。
因为你在给边界。
Codex 不怕任务小。
它怕任务模糊。
任务越小，越容易成功。
成功一次，你就敢继续用。
常见错误是，新手第一次就想让 Codex 证明自己很强。
结果任务太大，改动太散，你更不敢用了。
第一次练习，反而应该让它做一件小到不能再小的事。
比如只改标题。
只改一个按钮。
只补一段 README。
今天的小动作：
找一个项目，让 Codex 只改一个页面里的一个文案。
你要练的不是“让它写多少代码”。
你要练的是“让它按边界交付”。
## 六、第五步：让它跑验证
很多人用 AI 写代码，最大的问题是：
看到它说“完成了”，就信了。
不要这样。
Codex 改完以后，你要让它验证。
比如：
请运行项目现有的测试或类型检查。
如果没有测试，请至少运行一次构建命令。
如果命令失败，请先解释失败原因，再判断是不是你刚才的改动导致的。
常见命令可能是：
npm test、npm run build、npm run lint、pnpm test、pnpm build。
你不用一开始懂这些命令的全部含义。
先记住：
测试、构建、lint，都是在帮你检查项目有没有明显问题。
如果跑不过，不一定是 Codex 改坏了。
有些项目本来就有旧错误。
但你至少要让它说清楚：
是旧问题，还是新问题。
错误在哪个文件。
它准备怎么处理。
这一步会让 Codex 从“写代码的人”变成“交付结果的人”。
差别很大。
常见错误是，只看 Codex 的文字总结，不看命令结果。
它说“已完成”，只是一个声明。
测试、构建、lint 跑过，才更接近交付。
今天的小动作：
每次 Codex 改完，你都追问一句：
“你用什么方式验证这个改动是有效的？”
如果它没有验证，就让它补。
## 七、第六步：一定要看 /diff
这是新手最该养成的习惯。
Codex 改完以后，不要只看它的总结。
要看 diff。
在 Codex 里可以用：
/diff
diff 的意思很简单：
它会告诉你，哪些地方被删了，哪些地方被加了。
你看不懂全部代码也没关系。
先看三个东西：
第一，它有没有只改你允许的文件。
第二，它有没有删掉看起来很重要的东西。
第三，它有没有加一堆你没要求的复杂逻辑。
比如你只是让它改按钮颜色，它却新增了 5 个组件、改了路由、动了配置文件。
那就不对。
这时候你可以直接说：
这个改动范围太大了。
请撤回复杂改动，只保留按钮样式相关的最小修改。
不要怕指出问题。
Codex 很适合反复修。
你越会看 diff，它越不容易带你乱跑。
常见错误是，看到它总结“只改了样式”，你就放心了。
别只看总结。
看 diff。
总结是它说自己做了什么。
diff 是它真的做了什么。
今天的小动作：
每次改完，固定输入：
/diff
哪怕你看不懂全部代码，也先看文件数量。
一个小需求改了十几个文件，基本就该停下来问一句：
“为什么这个需求需要这么大的改动范围？”
## 八、第七步：用 /review 让它自己挑毛病
改完、跑完验证、看完 diff 之后，还可以再让它自查一遍。
用：
/review
或者直接说：
请你以代码审查的角度检查刚才的改动。
重点看：
1. 有没有潜在 bug
2. 有没有不必要的复杂度
3. 有没有影响其他页面
4. 有没有遗漏验证
5. 有没有更小的实现方式
这个动作很有用。
因为 Codex 写代码时是一种状态，审代码时是另一种状态。
你让它自己回头看一遍，经常能发现一些前面没注意到的问题。
当然，不要迷信它。
但这一步至少能多加一道保险。
新手不需要一开始就懂所有代码。
你先学会让 AI 自己检查 AI。
常见错误是，把 Codex 当成一次性输出机器。
它写完，你就结束。
但真正好用的方式是让它切换身份：
先当执行者。
再当审查者。
今天的小动作：
改完以后，不要马上关窗口。
让它再回答：
“如果你是代码审查者，你会挑这次改动哪三个问题？”
这一步经常能抓出一些小毛病。
## 九、一个可以直接复制的完整模板
如果你懒得每次想怎么说，可以直接复制下面这段。
第一次进项目时用：
```
请先熟悉这个项目。
你需要做四件事：
1. 看目录结构，判断这是一个什么类型的项目。
2. 找到主要代码目录、启动命令、测试或构建命令。
3. 总结这个项目的技术栈和关键文件。
4. 告诉我你建议下一步读哪些文件。
现在只允许读取和分析，不要修改任何文件。
```
准备改需求时用：
```
我想做这个修改：
【在这里写你的需求】
请你先给修改计划，不要直接改文件。
计划里必须包括：
1. 准备修改哪些文件
2. 每个文件准备改什么
3. 是否有风险
4. 改完后怎么验证
5. 有没有更小的实现方式
等我确认后再动手。
```
批准修改时用：
```
可以按这个计划执行。
要求：
1. 只改和这个需求直接相关的文件。
2. 不要顺手重构无关代码。
3. 不要改配置、依赖、数据库，除非你先说明原因并等待确认。
4. 改完后运行必要的测试、构建或检查命令。
5. 最后总结修改文件、验证结果和剩余风险。
```
改完检查时用：
```
请回顾刚才的改动。
重点检查：
1. 是否满足原始需求
2. 是否改动范围过大
3. 是否引入潜在 bug
4. 是否有测试或构建失败
5. 是否还有需要我人工确认的地方
```
这几段够新手用很久。
别一上来追求什么神级 prompt。
先把这个流程跑熟。
今天的小动作：
把上面四段保存到你的 Obsidian、备忘录或者项目 README 里。
以后每次开新项目，先复制第一段。
每次准备改需求，复制第二段。
每次批准执行，复制第三段。
每次改完检查，复制第四段。
别靠临场发挥。
新手最需要的不是灵感，是固定动作。
## 十、第一次练什么最好
如果你完全没经验，我建议第一次不要练复杂项目。
就练一个小网页。
比如：
把首页标题改得更清楚。
把按钮文案从 Submit 改成 Start now。
给页面增加一个 FAQ 区块。
把 README 补成新手能看懂的启动教程。
这些任务看起来小，但刚好能练完整闭环：
读项目。
定计划。
改文件。
跑验证。
看 diff。
做 review。
这才是 Codex 新手最该练的肌肉。
你不用第一天就让它写一个 App。
你先让它稳定改一个按钮。
然后改一个页面。
再改一个功能。
最后再让它接更复杂的任务。
工具不是靠收藏教程学会的。
是靠一轮一轮交付小任务学会的。
今天最推荐的练习是：
请把 README 补成一个新手能看懂的启动教程。
这个任务风险低，但很完整。
Codex 要读项目。
要找启动命令。
要改文件。
要总结验证方式。
你还能通过 diff 很清楚地看到它改了什么。
第一次练这个，比第一次让它改业务代码更稳。
## 最后
很多人对 Codex 的期待太极端。
要么觉得它会自动把项目全写完。
要么一看到它改错，就觉得 AI 编程不靠谱。
这两个想法都不太对。
Codex 真正好用的地方，不是你一句话许愿，它替你变出一个完美项目。
而是你把任务拆清楚，把边界讲清楚，把验证跑起来，它就能替你完成很多原来很麻烦的代码工作。
新手最该学的不是“怎么让 Codex 一次性写完所有东西”。
而是：
怎么让 Codex 一次只干一件小事，并且把这件小事干完整。
从今天开始，你可以先练一个最小任务。
不要打开 Codex 就问：
“帮我改一下这个项目。”
换成这个：
“请先熟悉这个项目，告诉我它是什么、怎么启动、主要文件在哪。先不要修改任何文件。”
然后让它给计划。
再让它改一个很小的地方。
再让它跑验证。
最后你看 diff。
这一轮跑通了，你才真正开始会用 Codex。
不是会聊天。
是会让它干活。
如果你已经用 Codex 改过项目，可以在评论区留一句：
“我最不敢让 Codex 做的是：____”
我后面可以继续按真实卡点写一套 Codex 新手练习路线。
## 相关链接
- [Oldeng](https://x.com/dengdry)
- [@dengdry](https://x.com/dengdry)
- [32K](https://x.com/dengdry/status/2058451803235107233/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [3:35 PM · May 24, 2026](https://x.com/dengdry/status/2058451803235107233)
- [32.1K Views](https://x.com/dengdry/status/2058451803235107233/analytics)
- [View quotes](https://x.com/dengdry/status/2058451803235107233/quotes)
---
*导出时间: 2026/5/25 12:15:01*