最近很多人终于把 Codex 装好了。

账号搞定了，环境也配好了，终端里输入 codex 也能正常启动。

结果用了十几分钟以后，第一反应却是：

就这？

让它写个页面，效果很一般。

让它改个 Bug，改完又冒出新的问题。

让它做个项目，跑几步就开始报错。

看别人演示的时候，Codex 像一个可以独立干活的程序员。

到了自己手里，却感觉和普通聊天机器人没什么区别。

于是很多人开始怀疑：

是不是 Codex 被吹得太厉害了？

其实很多时候，问题不在 Codex。

而在于：

你虽然已经用上了 Agent，却还在用 ChatGPT 的方式使用它。

---

一、别把 Codex 当成一个更强的 ChatGPT

这是我觉得最容易踩的坑。

很多人打开 Codex 以后，第一句话还是：

这段代码怎么改？

或者：

这个报错是什么原因？

甚至：

帮我写一个登录接口。

这种用法当然没有错。

但问题是：

你根本没有发挥 Agent 的优势。

因为这种交互方式，本质上还是：

我问一个问题，你给我一个答案。

这和普通聊天模型没有本质区别。

Codex 真正适合的使用方式应该是：

我给你一个任务，你自己去完成。

比如，不要这样问：

这个登录失败的问题怎么修？

而应该这样说：

先阅读整个项目。

找到用户登录相关的代码和配置。

分析为什么用户登录后偶尔会失效。

定位问题以后直接修改代码。

修改完成后运行相关测试。

如果没有测试，就补充一个最小测试。

最后告诉我：

1. 问题原因
2. 修改了哪些文件
3. 为什么这样修改
4. 测试结果

注意两种 Prompt 的区别。

第一种是在：

问答案。

第二种是在：

交任务。

而 Codex、Claude Code 这一类工具真正强的地方，恰恰就是后者。

---

二、AI Agent 不怕任务复杂，怕的是任务模糊

很多人第一次使用 Codex，喜欢直接来一句：

帮我做一个电商网站。

然后就开始等。

结果 AI 写了一堆文件。

页面有了。

按钮也有了。

但是越往后做越乱。

最后项目变成一个半成品。

于是得出结论：

Codex 不适合做大型项目。

其实这个结论不一定对。

问题在于：

“做一个电商网站”根本不是一个任务。

它是几十个甚至几百个任务的集合。

例如一个最简单的电商项目，也可能包含：

• 用户注册；
• 用户登录；
• 商品列表；
• 商品详情；
• 搜索；
• 购物车；
• 地址管理；
• 下单；
• 支付；
• 订单查询；
• 后台管理。

如果是一个真实开发团队，也不会有产品经理走过来说：

今天把淘宝做出来。

然后程序员就开始干。

正常开发一定会拆任务。

AI 也是一样。

所以更好的方式应该是：

我们准备开发一个简单的电商网站。

先不要写代码。

第一步：

阅读当前项目结构。

然后给我一个最小可用版本的功能拆分。

第一阶段只实现：

1. 商品列表
2. 商品详情
3. 购物车

不要加入支付、登录和后台。

先输出你的开发计划。

等它完成以后，再继续：

按照刚才的计划开始实现第一阶段。

每完成一个功能都要运行项目验证。

不要一次修改过多文件。

你会发现效果稳定很多。

所以我一直觉得：

AI Agent 不怕复杂任务。

它真正怕的是模糊任务。

---

三、很多人甚至没有让 Codex 先读项目

如果你接手一个陌生项目，你会直接开始改代码吗？

正常情况下不会。

你至少会先看：

README.md

然后看目录。

再看：

package.json

或者：

go.mod

或者：

pom.xml

然后搞清楚：

项目是什么技术栈？

从哪里启动？

数据库在哪里配置？

前端在哪里？

接口在哪里？

测试怎么跑？

但是很多人使用 Codex 的时候完全跳过了这一步。

上来就说：

给我增加一个用户管理功能。

这相当于一个程序员第一天入职，你没有给他介绍任何项目情况，就让他直接改核心代码。

效果当然不稳定。

所以我现在拿到一个陌生项目，通常第一句话反而非常简单：

先不要修改任何代码。

阅读整个项目。

重点查看：

README
项目目录
依赖配置
启动入口
数据库配置
测试目录

然后告诉我：

1. 这个项目是做什么的
2. 使用了什么技术栈
3. 核心目录分别负责什么
4. 项目如何启动
5. 当前有哪些明显问题

暂时不要修改文件。

这一段非常重要。

它相当于让 AI 先：

入职。

等它真正理解项目以后，再开始交任务。

---

四、别只让 AI 写代码，要让 AI 验证代码

这是另外一个特别重要的区别。

以前我们使用 ChatGPT：

复制代码。

让 AI 修改。

自己粘贴回去。

然后自己测试。

AI 只负责：

生成代码。

但是到了 Agent 时代，这种方式已经落后了。

因为 Codex 最大的价值之一就是：

它可以自己运行命令。

所以不要只说：

修复这个 Bug。

而应该说：

修复这个 Bug。

修改完成后运行对应测试。

如果测试失败，继续排查。

只有测试通过以后再结束任务。

甚至可以继续增加：

完成后执行：

npm test

npm run build

如果项目支持 lint，再执行 lint。

确认没有新增错误以后再给我结果。

如果是 Go 项目：

go test ./...

如果是 Python：

pytest

这时候整个工作流就发生变化了。

以前：

AI 写代码 → 人测试。

现在：

AI 写代码 → AI 测试 → AI 修复 → 人验收。

这才是 Agent 真正应该工作的方式。

---

五、最好先让它分析，再让它动手

我自己非常推荐一个使用习惯：

不要一上来就让 Codex 改代码。

特别是比较复杂的问题。

比如你发现：

用户偶尔登录失败。

千万不要马上说：

帮我修复登录 Bug。

可以先让它：

先不要修改代码。

分析用户登录的完整调用链。

包括：

前端请求
后端接口
Token 生成
Token 校验
Redis
数据库

找到最可能导致登录偶发失效的位置。

把你的判断和依据告诉我。

这个阶段相当于：

诊断。

如果分析没问题，再执行：

按照刚才的分析开始修改。

尽量保持最小改动。

完成以后运行测试验证。

这样做有一个非常大的好处：

你可以在 AI 真正修改代码以前，先判断它有没有理解对问题。

否则很多时候 AI 一上来就改。

改了 10 个文件。

最后发现：

方向从第一步就错了。

---

六、不要一句话同时塞十几个要求

还有一种特别常见的 Prompt：

帮我做一个后台管理系统，
使用 Vue3，
界面好看一点，
支持用户管理，
支持权限管理，
支持暗黑模式，
增加图表，
还要移动端适配，
登录页设计高级一点，
最好再接一个 AI，
代码规范一点。

这种 Prompt 看起来要求非常详细。

其实非常糟糕。

因为你把：

需求分析。

架构设计。

UI 设计。

前端开发。

权限系统。

响应式适配。

AI 功能。

全部塞在了一个任务里。

AI 很容易顾此失彼。

更好的方式是分阶段：

第一阶段：

只搭建项目基础结构。

要求：

Vue3
TypeScript
Pinia
Vue Router

先完成：

登录页
后台基础布局
左侧菜单
顶部导航

暂时不要开发业务功能。

然后：

第二阶段：

增加用户管理。

包括：

用户列表
新增用户
编辑用户
删除用户
分页
搜索

接着：

第三阶段：

实现 RBAC 权限。

先阅读现有代码。

不要重构无关功能。

这样 AI 会稳定很多。

不要把 Prompt 写成愿望清单。

把它写成：

可以执行的任务单。

---

七、你应该告诉 AI 什么不能动

这一点也非常有用。

很多 AI 修改项目时喜欢：

“顺手优化”。

你明明只是让它修改登录 Bug。

它可能顺手：

重构目录。

升级依赖。

改数据库。

换 UI。

甚至重写某个模块。

于是一个 Bug 修复任务，最后变成项目大装修。

所以我经常会增加一句：

只修改解决当前问题必须修改的文件。

不要重构无关代码。

不要升级依赖。

不要改变现有接口格式。

不要修改数据库结构。

这一句话非常值钱。

因为真实开发里面：

能少改，就不要多改。

这其实也是程序员很重要的一种工程思维。

---

八、真正厉害的人，开始学会“验收 AI”

AI Coding 时代还有一个很明显的变化。

以前程序员最核心的能力是：

写代码。

以后可能越来越变成：

定义任务 + 判断结果。

例如 AI 告诉你：

登录问题已经修复。

你不能看到这句话就结束。

你要继续问：

你是如何验证问题已经修复的？

或者：

列出修改的所有文件。

解释每一处修改的目的。

甚至：

检查刚才的修改是否可能引入新的安全问题。

最后再：

重新运行全部相关测试。

AI 会越来越擅长“干活”。

但最终是否接受这个结果，依然需要人判断。

所以以后非常重要的一种能力可能叫：

AI 验收能力。

---

九、为什么同一个 Codex，有人用起来像外挂，有人却觉得一般？

很多人喜欢研究：

哪个模型最强？

哪个模型写代码排名第一？

哪个模型 Benchmark 高？

这些当然重要。

但是实际使用里面，你会发现：

两个使用同一个模型的人，效果可能差得非常大。

原因就在于：

一个人在说：

帮我改一下。

另一个人在说：

先分析项目。

确认问题。

提出方案。

最小化修改。

执行测试。

失败继续修复。

最后总结结果。

两个人用的是：

同一个模型。

但是得到的是：

完全不同的结果。

所以 AI Coding 发展到今天，我越来越觉得：

模型能力当然重要。

但工作流同样重要。

真正影响最终效果的可能是：

模型 × 上下文 × 任务拆分 × 工具权限 × 验证流程。

而不是单纯：

模型排行榜第一名。

---

十、从“会提问”升级到“会交任务”

ChatGPT 刚出现的时候，大家都在讨论一个词：

Prompt Engineering。

很多教程教大家：

怎么问问题。

怎么写提示词。

怎么让 AI 回答得更好。

但是进入 Agent 时代以后，我觉得思维需要再升级一次。

未来更重要的可能不是：

Prompt Engineering。

而是：

Task Engineering。

也就是：

你能不能把一个模糊的目标，拆成 AI 可以执行、验证、交付的任务。

例如以前我们问：

如何优化这个项目？

以后可能会变成：

阅读整个项目。

找出当前最影响性能的三个问题。

按照收益最高、改动最小的原则排序。

先修复第一项。

完成后执行性能测试。

对比修改前后的数据。

确认有改善以后再继续下一项。

这已经不是在：

问 AI。

而是在：

管理 AI。

---

最后

很多人现在觉得 Codex 不好用。

并不一定是工具的问题。

而是我们的使用习惯还停留在聊天机器人时代。

以前：

你问，AI 答。

现在：

你描述目标，AI 执行。

以前：

AI 写代码，人负责剩下所有事情。

现在：

AI 阅读项目、修改代码、执行测试、排查问题，人负责验收。

这才是 AI Coding 真正发生变化的地方。

所以如果你已经装好了 Codex，却一直觉得没有别人演示得那么强，不妨试着改变一个习惯：

少问一句“这个怎么做？”

多说一句：

“这个任务交给你，做完以后自己验证。”

你可能会发现：

同一个 Codex，

突然就完全不一样了。