爆肝万字！这应该是全网最全的 Codex 实战教程了

大家好，我是 Sunday。

最近这段时间，我后台被同一个问题问麻了。

Codex 到底怎么用？

CLI、App、VS Code 插件，三个入口摆在那儿，看起来都能用。

plugins、skills、MCP、automations、AGENTS.md、子 agent、权限模式，又一个个往外冒。

你只是想让它帮你改个代码。结果它先给你塞了一整套新概念。

不是哥们，我只是想修个 bug，怎么突然像在学一门新职业。。。

所以我昨天专门花了一下午，把 Codex 这套东西重新捋了一遍，顺手录了一个比较完整的视频。

录完之后我发现，这里面其实有很多地方，只看视频很容易滑过去。

尤其是那些 提示词模板、权限边界、版本管理、上下文管理，还有什么时候该让 Codex 只读，什么时候可以让它动手改代码。

这些东西如果不写下来，真的很容易看完就忘。

所以我干脆把视频对应的文案重新整理成了这篇文章。

不敢说多权威。

但如果你是程序员，或者你正在用 Codex、Claude Code、Cursor 这类东西做项目，我觉得这篇应该能帮你少踩不少坑。

这篇主要会讲这些内容：

• Codex 的三大入口
• 使用 Codex 的注意事项
• 权限模式
• Codex 最佳实践
• 提示词与 token 消耗的关系
• 多模态能力
• 版本管理
• 上下文管理
• 长期记忆
• skills
• plugins
• MCP
• 自动化
• 一个完整案例
• 我常用的 Codex 指令模板
• 彩蛋

那么，咱们开始～～

Codex 的三大入口

回到 Codex 本身。

现在 Codex 大概有三个主要入口：

• Codex CLI
• Codex App
• Codex IDE 插件

咱们一个个来说。

第一个是 Codex CLI 。

也就是命令行版本。

如果你是程序员，可以直接通过 npm 安装：

npm install -g @openai/codex

安装之后，在项目根目录里输入：

codex

就可以启动。

如果你想更新，也可以用：

codex --upgrade

CLI 的优点是轻量、直接、适合终端党。

你在哪个项目目录打开它，它就基于哪个项目开始工作。

当我们让 Codex 第一次接触一个项目时，可以先让它读取这个项目。

一般我的提示词是：

请先阅读当前项目结构，不要修改任何代码。

告诉我：
1. 这个项目是做什么的
2. 使用了哪些技术栈
3. 入口文件在哪里
4. 启动、构建和测试命令是什么
5. 如果我要新增一个功能，应该从哪里开始

这个习惯非常重要。

很多人用 Vibe Coding 翻车，不是模型不行，是自己太着急让它改代码了。

这种不翻车才怪。

第二个入口是 Codex App

这个我觉得更适合新手。

直接从官网就可以下载，macOS 和 Windows 都有安装包。

因为 App 比 CLI 更像一个完整的 AI 编程工作台。

你可以开新对话，搜索历史，管理插件，安装 skills，配置自动化。

官方现在也把 Codex App 定位成多 agent 工作台。

也就是说，它不是只让你和一个 AI 聊天。

而是让你可以同时开多个任务，让不同 agent 在不同项目、不同分支、不同 worktree 里工作。

如果你第一次用 Codex，我更建议从 App 开始。

因为 CLI 很爽，但它对新手不太友好。

目录、权限、命令、上下文、沙盒、git 状态，这些东西混在一起，很容易给人整懵。

App 至少能让你有一个更清楚的工作台视角。

第三个入口是 IDE 插件

比如在 VS Code、Cursor 里直接用 Codex。

这个适合你已经在写代码，想让 Codex 在当前工程里辅助你处理某个文件、某个 bug、某个组件的时候使用。

咱们以 VS Code 为例。

直接在插件市场里搜索 Codex，安装插件即可。

然后打开对应项目，就可以在右上角找到 Codex 的图标。

点击之后，就能直接进入 Codex 的工作台。

同时要注意：

如果你同时安装了 Codex App 和 Codex IDE 插件，它们的数据是可以互通的。

使用 Codex 的注意事项

那第一次用 Codex，应该怎么开始？

我建议你不要一上来就找一个公司核心项目练手。

先找一个 demo 项目。

或者找一个你自己不怕改坏的小项目。

然后确认这个项目已经被 git 管理。

如果还没有，可以先通过以下指令初始化：

git init
git add .
git commit -m "initial commit"

这样做的目的是：保证万一 Codex 把你的代码改错了，你还能还原回去。

同时要注意，当我们使用 Vibe Coding 进行编程时，每次 Codex 修改了代码之后，最好都做一次 git commit，以防万一。

所以，一定要做好版本管理。

另外，第一次启动 Codex，不要让它写代码。

就让它读项目。

给大家一个我常用的提示词：

请先不要修改任何代码。

你现在只需要阅读项目结构，并告诉我：
1. 这个项目是做什么的
2. 使用了哪些技术栈
3. 入口文件在哪里
4. 启动和构建命令是什么
5. 如果我要新增一个页面，应该从哪里开始

这一步做完之后，你再看它的理解准不准。

如果它理解错了，就纠正它。

不要着急让它动手。

你可以继续问：

你刚才对项目的理解里，有哪些地方是不确定的？

请列出来，并说明你还需要查看哪些文件。

这样的方式实测非常好用，分享给大家。

权限模式

接着讲权限模式。

这个东西很多人会忽略，但我觉得它非常关键，所以单独拿出来讲一下。

我们知道，Codex 是可以读取和修改你本地代码和文件的。

这样就会涉及到本地文件安全的问题。

比如，万一 AI 直接把你电脑里很重要的文件删了，那就麻烦了。

所以，为了避免这个问题，Codex 里的权限模式通常可以分成三种。

第一种是 默认权限

默认权限最安全，也可以说最保守。

它可以读文件，可以给你提出修改建议，也可以提出要执行的 shell 命令。

但是，真正修改文件或者执行命令之前，需要你主动批准。

好处是安全。

坏处是你不能离开。

毕竟每一步你都得主动确认。

第二种是 自动审查模式

它比默认权限稍微激进一点。

默认权限是，AI 想改文件、想执行命令，都要先问你。

自动审查的意思是，Codex 会先自己判断这个操作是不是安全。

如果它只是修改当前项目里的普通代码，或者执行一些常见命令，比如安装依赖、跑测试、跑构建，那它可能就会自动通过，不用你每一步都点确认。

这样做的好处是效率更高。

比如你让 Codex 修一个 bug，它可能会先读代码，然后改代码，然后跑测试，再根据报错继续修改。

如果每一步都要你确认，其实就很打断节奏。

但是自动审查也不是完全放开。

如果 Codex 要做一些风险比较高的事情，比如删除文件、访问项目外目录、读取敏感文件、联网下载东西，或者执行一些危险命令，它还是会停下来让你确认。

所以自动审查更适合什么场景？

适合你已经比较熟悉这个项目，也比较信任当前这次任务。

你希望 Codex 能连续多干几步，不要每一步都来问你。

但你又不想完全放开权限。

这个时候，用自动审查就比较合适。

它其实是一个折中的模式：

比默认权限更省心，但比完全访问权限更安全。

第三种是 完全访问权限

这个模式就要谨慎了。

你可以把它理解为：把 Codex 的限制放到最小。

在这个模式下，Codex 可以更自由地读取文件、修改文件、执行命令，甚至访问项目外的目录和网络。

好处是执行效率最高。

比如你让它做一个比较大的任务：迁移项目、批量重构、安装依赖、跑脚本、跨多个目录改代码。

它不需要一直停下来等你确认，可以更像一个真正的开发助手一样，连续把事情往下推进。

但是风险也最大。

因为一旦它理解错了你的意思，或者执行了一个不该执行的命令，就可能真的影响你本地的文件。

所以我不建议大家日常一直开完全访问权限。

尤其是陌生项目、刚 clone 下来的开源项目、公司核心项目，或者里面有 .env、密钥、token、配置文件的项目，都不要随便开。

更稳的做法是：

• 平时用默认权限。
• 高效率的时候，用自动审查。
• 在你非常确定这个项目安全、任务明确，而且你知道 Codex 接下来要做什么的时候，再临时打开完全访问权限。

用完之后，最好再切回默认权限或者自动审查。

所以这三个模式可以简单总结一下：

默认权限，最安全，但是需要你频繁确认。

自动审查，效率更高，适合日常开发里的连续任务。

完全访问权限，能力最强，但风险也最高，只适合临时使用。

Codex 最佳实践

然后咱们来看使用 Codex 进行 Vibe Coding 的最佳实践。

这里一共分成 4 步：

• 第一步，指定范围。
• 第二步，指定状态。
• 第三步，指定验收标准。
• 第四步，随时中断。

咱们一个个来看。

第一步 指定范围

不要让 Codex 在整个项目里瞎逛。

尤其是大项目。

你如果只想改登录页，就把登录页相关文件告诉它。

你如果只想查一个 hook，就把 hook 文件和调用位置告诉它。

在 App 或 IDE 里，可以通过 @ 指定文件。

在 CLI 里，也可以直接把路径写清楚。

比如：

请只阅读 src/pages/login 和 src/hooks/useAuth 相关文件。

帮我判断登录跳转逻辑是否存在时序问题。

这就比一句「帮我看看登录有啥问题」靠谱很多。

第二步 指定状态

也就是你要明确告诉它，现在是只读，还是可以修改。

比如：

先不要修改代码，只输出分析。

或者：

可以修改代码，但修改前先给我计划。

再或者：

请按计划直接修改，完成后运行相关测试。

你看，这三句话对应的工作状态完全不一样。

很多人用 Codex 出问题，就是因为没有说清楚边界。

第三步 指定验收标准

比如：

完成后请确保：
1. npm run lint 可以通过
2. 相关测试可以通过
3. 不引入新依赖
4. 不修改无关文件
5. 最后总结修改内容、验证结果和剩余风险

这就叫验收标准。

你不给验收标准，它就只能按自己的理解收工。

而 AI 的「我觉得完成了」，和工程里的「真的完成了」，经常不是一回事。

第四步 随时中断

如果你发现 Codex 开始往奇怪方向走，不要硬等它做完。

直接中断。

在 AI 执行的过程中，点击暂停按钮，然后告诉它：

暂停刚才的方向。

你现在的理解有问题。
正确目标是 XXX。
请基于当前 diff 重新评估，不要继续扩大修改范围。

这就像带实习生一样。

方向不对的时候，要早纠偏。

提示词与 token 消耗的关系

然后咱们来看提示词与 token 消耗的关系。

很多同学会觉得，跟 Codex 说话是不是越短越好？

说的话越短，token 消耗就越低？

其实不一定。

短指令有时候反而更费 token。

因为你说得太短，Codex 就要自己搜索、自己猜、自己补上下文。

你以为省事了。

实际上它绕了一大圈，token 消耗也就上来了。

举个例子。

比如你说：

优化一下这个页面。

这样说省事吧。

但是 Codex 就会很痛苦。

你要优化的是什么？

是 UI，还是性能，还是代码可维护性？

它只能猜。

而它猜的这个过程，token 消耗可能非常大。

所以，更靠谱的说法是指定具体的优化事项。

比如：

请阅读 src/pages/dashboard 相关文件。

我现在觉得这个页面有三个问题：
1. 首屏信息太散
2. 移动端布局容易挤压
3. 接口失败时没有明显反馈

先不要修改代码。
请先输出你的修改计划，告诉我会改哪些文件，以及为什么这样改。

这个指令就好很多。

要记住：在 Vibe Coding 的场景下，最怕的就是让 AI 自由发挥。

Codex 的多模态能力

Codex 不只是能看文字。

你也可以给它截图、设计图、报错截图、UI 问题截图。

比如你看到页面上某个按钮被挤压了，或者移动端布局错位了。

你可以直接把截图丢进去，复制粘贴或者拖拽过去都可以。

然后说：

这是当前页面的截图。

请结合截图和代码，判断布局问题可能在哪里。
先不要修改代码，只输出原因和修改方案。

这个效果会比纯文字描述好很多。

毕竟一图胜千言。

版本管理

再讲版本管理和回滚。

Codex 改代码之前，先看 git 状态。

Git 是一个代码版本管理工具，可以直接在官网下载。

在每次 Vibe Coding 修改代码之前，通过 Git 做好版本管理，这是我非常建议大家养成的习惯。

你可以 直接通过 Git 指令 或者 可视化工具来做 。

也可以让 Codex 先看：

请先检查当前 git 状态。

告诉我有哪些未提交修改。
不要修改任何文件。

如果工作区已经有你自己写了一半的东西，一定要小心。

因为 Codex 可能会在这些文件上继续改。

不是说不能改。

而是你要知道它改了什么。

每完成一个小任务，就让它总结一次 diff。

比如：

请总结这次修改：
1. 改了哪些文件
2. 每个文件改了什么
3. 为什么这样改
4. 是否还有风险
5. 建议我如何验证

然后你自己看一眼 diff。

不要直接闭眼提交。

上下文管理

接着讲上下文管理。

这个也是 AI Agent 里特别关键的东西。

Codex 每个对话都有上下文。

你前面说过什么，它做过什么，读过什么文件，改过什么东西，都会逐渐堆进去。

一开始这很爽。

因为它记得你刚才干了什么。

但时间长了之后，上下文会越来越重。

回答会变慢，甚至开始混淆旧任务和新任务。

也就是大家平常说的：感觉 AI 变笨了。

这时候你就要有意识地管理上下文。

我的建议是，每个对话只做一类任务。

比如这个线程只修登录 bug。

那个线程只做组件重构。

不要在同一个线程里，一会儿让它写页面，一会儿让它查 CI，一会儿又让它总结会议。

这会把上下文搞得很脏。

什么时候继续旧对话？

当这个任务和前面的上下文强相关。

比如刚才修了一半，测试还没过，那就继续。

什么时候开新对话？

当你要处理一个新问题，或者旧上下文已经太乱。

比如你刚做完登录，现在要做支付。

那就开新线程（开一个新的对话框）。

同时，让它在任务结束的时候，做一次收尾总结。

比如：

请总结这个任务。

包括：
1. 目标是什么
2. 最终改了什么
3. 已验证什么
4. 还有什么风险
5. 后续继续做应该从哪里开始

这个总结以后特别有用。

因为你下次搜索历史，或者重新打开这个线程的时候，不需要从一堆碎片里找线索。

你能直接看到这次任务的工程记录。

这就是 Codex App 里搜索功能的价值。

长期记忆

说到长期记忆，就要讲 AGENTS.md。

如果你用过 Claude Code，可能会知道 CLAUDE.md。

在 Codex 里，对应更常见的是 AGENTS.md。

你可以把它理解成写给 AI Agent 的项目说明书。

Codex 会读取这些文件，把里面的规则当成长期上下文。

它可以有几层。

全局层面

可以放你的个人偏好。

比如你希望它回答中文，改代码前先给计划，测试失败要说明原因。

项目根目录

可以放项目规范

比如技术栈、启动命令、测试命令、代码风格、目录约定。

子目录里

也可以放某个模块的特殊规则

比如这个目录是老代码，不要重构公共接口。

或者这个模块里所有请求都必须走统一封装。

这东西非常有用。

因为你不用每次都重复说一遍。

比如你可以在项目根目录放一个 AGENTS.md，写成这样：

# Project Instructions

- 默认使用中文回答。
- 修改代码前，先说明计划。
- 不要主动引入新依赖，除非明确说明原因。
- 不要重构无关文件。
- 前端组件需要考虑 loading、empty、error 状态。
- 涉及用户输入时，需要考虑校验和错误提示。
- 修改完成后，优先运行 npm run lint 和相关测试。
- 如果测试无法运行，需要说明原因和剩余风险。

以后 Codex 进入这个项目，就会带着这些规则工作。

这就是长期记忆。

把你的工作标准固化下来。

把团队的代码规范、分支规范、测试规范、目录约定都写进去。

这会比每次在群里重复提醒靠谱得多。

skills

然后是 skills。

这个东西有多火，我就不用多说了。

现在几乎所有大模型产品都开始提供 skills 的功能。

并且，我也觉得这是 Codex 里非常值得研究的部分。

很多人会把 skill 和 plugin 混在一起。

其实不是一回事。

skill 更像一套做事方法。

它告诉 Codex，遇到某类任务时，应该按什么流程做，检查什么风险，用什么标准输出。

比如你可以有一个前端 review skill。

里面写清楚，每次 review 前端代码，要重点看组件边界、状态管理、接口错误处理、移动端适配、性能问题、XSS 风险。

以后你让 Codex review，它就不是泛泛地看一下。

而是按这套标准来。

你也可以有一个写作 skill。

把你的文章结构、语气、禁用词、案例组织方式都写进去。

以后你让 Codex 写稿子，它就不需要每次重新适应你的风格。

把这些东西写成 skill，就变成了可以复用的工作流。

Codex 中默认就有一个 Skill Creator。

利用它可以直接创建你自己的 skills。

比如你可以让 Codex 帮你创建一个 skill：

请帮我创建一个前端代码审查 skill。

它需要在 review 时重点检查：
1. 是否破坏现有组件约定
2. 是否引入不必要依赖
3. 是否有响应式状态混乱
4. 是否遗漏 loading、empty、error 状态
5. 是否有移动端适配问题
6. 是否有 XSS 风险
7. 是否补充必要测试

也可以直接让它安装别人的 skills。

比如你可以在 GitHub 上找到一个 skill，然后直接跟 Codex 说：

请帮我安装这个 skill，并检查它的用途和安全风险。
链接是：XXX

它就可以帮你完成安装。

plugins

再讲 plugins。

plugin 和 skill 最大的区别是：

skill 更像方法，plugin 更像工具箱。

插件可以让 Codex 连接更多外部工具和信息源。

比如 GitHub、浏览器、文档、邮件、日历、电脑应用、各种 MCP 服务。

一旦这些接上，Codex 就不只是一个写代码的助手。

它开始进入真实工作流。

比如你可以让它看 GitHub PR 的 review comment：

请查看当前 PR 的 review comment。

总结必须修改的问题。
先不要改代码。

也可以让它读取某个文档，再检查项目里对应模块有没有受影响：

请读取这份需求文档。

找出和当前项目相关的变更点。
然后只输出可能受影响的文件和模块。
不要修改代码。

这就很像一个能在不同工具之间来回跑的 AI 同事。

但我还是要强调一遍。

能力越大，边界越重要。

插件不是装得越多越好。

权限也不是给得越高越好。

尤其是涉及公司仓库、邮件、聊天记录、文档权限的时候，一定要注意数据边界。

MCP

然后是 MCP。

这个词最近也很火。

MCP 你可以先简单理解成一套让 AI 连接外部工具和数据源的协议。

比如数据库、浏览器、知识库、设计工具、内部系统。

以前 AI 想用这些东西，每个工具都要单独适配。

现在通过 MCP，就更像有了一套统一的接口。

Codex 接上 MCP 之后，就能访问更多外部能力。

比如：

• 查询数据库结构
• 读取内部文档
• 操作浏览器
• 检索知识库

当然，不同环境支持什么 MCP，要看你自己的配置和权限。

我这里不建议大家一上来就折腾一堆 MCP。

新手先把最基本的项目读写、权限、上下文、AGENTS.md、git 工作流搞明白。

这些才是根本。

MCP 是扩展。

根本没打好，扩展越多越容易乱。

自动化

再讲自动化。

这个功能我觉得很多人会低估。

自动化就是你给 Codex 一个任务，再给它一个时间规则，让它自己周期性执行。

有点像定时任务。

但它不是普通定时任务。

因为执行任务的是一个 Agent。

比如你可以让它每天早上总结昨天的提交：

每天早上 9 点，检查当前项目过去 24 小时的提交记录。

输出：
1. 主要改动
2. 涉及模块
3. 潜在风险
4. 今天需要我关注的地方

不要修改代码。

你也可以让它每 30 分钟检查一次 PR 状态：

每 30 分钟检查一次当前 PR。

如果有新的 review comment，请总结评论内容，并判断哪些需要修改。

不要自动改代码。
只在发现新问题时提醒我。

还可以让它每天晚上总结今天的 diff：

每天晚上 6 点，总结今天当前项目的 git diff。

告诉我：
1. 改了哪些文件
2. 每个文件大概改了什么
3. 有没有明显风险
4. 明天继续做应该从哪里开始

这类任务特别适合 Codex。

因为它们重复、明确、有固定判断标准。

自动化我也建议从只读任务开始。

先让它汇报，不要让它自动改。

等你确认它的判断稳定，再慢慢扩大权限。

这里可以分两类理解。

一种是 跟当前对话绑定的自动化

比如你正在等部署结果。

你可以让 Codex 10 分钟后回到这个线程继续检查。

这种适合短周期、强上下文任务。

另一种是 独立自动化

比如每天早上检查项目提交。

每周五生成项目周报。

每天晚上总结错误日志。

这种任务每次都是独立巡检，不一定依赖当前对话。

你可以这样判断：

• 如果任务需要接着当前对话继续，就用当前线程自动化。
• 如果任务每次都是固定巡检，就用独立自动化。

这样就比较好理解了。

一个完整案例

接下来，我们用一个具体案例串起来。

假设我要做一个番茄钟应用。

先看看最后的实现效果

一套完整的工程实践，总共可以分成 6 步。

很多人可能会说，这么麻烦？

直接说一句：

帮我写一个番茄钟应用。

不就行了吗？

这样能实现出来吗？

能。

但效果大概率一般。

更靠谱的方式，是把 Codex 编程变成一套完整的工程实践。

第一步，先拆需求

我想做一个番茄钟应用。

请先帮我拆需求，不要写代码。

输出：
1. 核心功能
2. 可选功能
3. 第一版最小可用范围
4. 可能的边界情况
5. 推荐的实现顺序

这一步，你可以用 GPT，也可以用 Codex。

如果你还没想清楚，我更建议先用 GPT。

因为 GPT 更适合讨论和拆解。

第二步，让 Codex 读项目

请阅读当前项目结构。

判断番茄钟功能应该放在哪些目录下。

先不要修改代码。
只输出文件计划，包括要新增哪些文件、修改哪些文件，以及原因。

这一步很关键。

因为同样是番茄钟，在不同项目里写法不一样。

有的项目用 React。

有的用 Vue。

有的用 Next.js。

有的有自己的组件库。

有的有自己的状态管理。

Codex 必须先读项目，才能按项目风格做。

第三步，让它小步实现第一版

按刚才的计划实现第一版。

要求：
1. 完成 25 分钟工作计时和 5 分钟休息计时
2. 支持开始、暂停、重置
3. 支持工作和休息状态展示
4. UI 简洁，不要做复杂动画
5. 不要引入新依赖

完成后运行项目检查是否报错。

注意，我这里没有让它一次性做一堆东西。

没有历史统计。

没有通知提醒。

没有音效。

没有复杂主题。

先做核心功能。

因为 Codex 做大任务，最怕一口吃太多。

第四步，让它检查自己

请 review 这次改动。

重点检查：
1. 计时器是否正确清理
2. 组件卸载后是否可能继续 setState
3. 开始和暂停状态是否混乱
4. 重置逻辑是否正确
5. 移动端布局是否会溢出
6. 有没有不必要的复杂代码

先只输出 review 结果，不要修改。

这一步非常有价值。

让 Codex 写代码是一回事。

让 Codex 站在 reviewer 角度再看一遍，是另一回事。

第五步，再让它修

请根据刚才 review 里确认的问题进行修复。

只修改和这些问题直接相关的代码。
不要做额外重构。
完成后再次总结 diff。

第六步，沉淀经验

请总结这次实现番茄钟功能的过程。

包括：
1. 最终文件结构
2. 核心实现思路
3. 遇到的问题
4. 后续如果要加历史记录和通知提醒，应该从哪里开始
5. 哪些规则可以写进 AGENTS.md

你看，这一整套下来，Codex 的工作质量会稳定很多。

我常用的 Codex 指令模板

这里我再给大家一套我自己比较常用的 Codex 指令模板。

第一个，读项目模板

请先阅读当前项目，不要修改任何代码。

帮我总结：
1. 项目是做什么的
2. 技术栈是什么
3. 目录结构如何组织
4. 启动、构建、测试命令是什么
5. 新增一个页面应该从哪里开始
6. 当前项目有哪些明显维护风险

第二个，修 bug 模板

我遇到了一个 bug：XXX。

请先阅读相关代码，不要修改。

输出：
1. 可能原因
2. 涉及文件
3. 你需要进一步确认的信息
4. 修复计划

第三个，执行修改模板

请按刚才确认的计划修改代码。

要求：
1. 修改范围只限于 XXX
2. 不要引入新依赖
3. 不要重构无关代码
4. 完成后运行相关测试
5. 最后总结修改内容和风险

第四个，review 模板

请 review 当前 git diff。

重点关注：
1. 是否破坏现有功能
2. 是否有边界情况遗漏
3. 是否有错误处理缺失
4. 是否有类型问题
5. 是否有安全风险
6. 是否需要补测试

只输出问题，不要修改代码。

第五个，任务收尾模板

请总结这个任务。

包括：
1. 目标是什么
2. 最终改了什么
3. 已验证什么
4. 还有什么风险
5. 后续继续做应该从哪里开始

这几个模板你不用背。

你只要记住背后的逻辑：

• 先读。
• 再计划。
• 再执行。
• 再验证。
• 再总结。

这就是最朴素，也最稳定的 Codex 工作流。

彩蛋

打开之后长这样：

里面包含了非常多的 Codex 配置。

比如个性化、MCP、浏览器使用等等。

这些配置后面可以慢慢研究。

不过这里有个非常好玩的小功能，就是之前 Claude Code 也弄过的 宠物。

只不过之前 Claude Code 的宠物有点虎头蛇尾。

而 Codex 这个虽然没怎么宣传，但我觉得做得还挺完整。

选择「外观」，拉到最后，有一个 宠物 模块。

里面包含了一大堆宠物，同时也可以自定义宠物。

只需要点击「唤醒宠物」，你的宠物就会出现在电脑桌面上。

有一种之前用电脑管家小篮球的即视感。

如果你感觉 Codex 默认提供的宠物太丑了，现在也有很多 Codex 宠物市场。

比如 https://codex-pets.net/

是不是感觉比官方的好看多了。。。

安装也非常简单。

比如安装我最喜欢的 鸡哥。

直接通过右侧的指令即可完成安装 npx codex-pets add ikun

当然了，这块就是一个彩蛋。

好玩归好玩。

真正决定 Codex 好不好用的，还是前面那些东西。

新对话、搜索、插件、skills、自动化。

这些才是 Codex APP 真正的工作流核心。

总结

今天的内容挺长了，我看了下有 一万六千字 。当然视频也挺长的，剪完之后也有 40 分钟。

最后总结下：

AI 不是神。它是一个非常强的工具。

但越是这种工具，越需要你会用。

新手最容易犯的错误，就是给一个模糊任务，然后期待它一次性做完。

这是非常不靠谱的。

真正靠谱的方式是：

• 先只读。
• 再计划。
• 再小步修改。
• 再测试验证。
• 再总结沉淀。
• 把常用规则写进 AGENTS.md。
• 把重复标准做成 skills。
• 把外部工具通过 plugins 和 MCP 接进来。
• 把重复巡检交给自动化模块。
• 复杂任务再拆给多个 agent 并行做。

然后你自己负责方向、判断和验收。

我觉得这才是 Codex 最有价值的地方。