别再把 Codex 当 ChatGPT 用

一、为什么不能把Codex当普通聊天窗口用

很多人第一次使用Codex，会直接把已有项目拖进去，然后像使用ChatGPT一样连续追加需求：先让它改页面，再让它补接口，再让它加一个支付功能。短时间看起来能跑，但项目越改越乱，后面很难判断某一次变更到底来自哪个任务。

Codex的核心不只是“回答问题”，而是围绕代码项目执行任务。它有项目区、任务上下文、代码变更、审查、自动化和规则文件。如果把所有内容都塞进一个聊天窗口，后续很容易出现上下文混乱、需求覆盖、修改范围失控的问题。

这个项目任务界面里能看到左侧项目列表、中间代码区和底部终端输出，它更像是在一个真实项目里操作，而不是普通聊天窗口。使用Codex时要先确认项目边界，再把每一次需求拆成独立任务。

如果一开始就把Codex当成长聊天窗口使用，后面最容易出的问题不是它不会写代码，而是你找不到它为什么这么改。

二、Projects应该理解成项目工作区，不是聊天列表

左侧的Projects更适合理解为项目工作区，接近电脑上的真实文件夹。它负责承载项目代码、文件结构、上下文范围和任务入口。一个项目里可以有多次任务，但不能把项目本身理解成普通聊天分组。

进入项目后，界面会出现任务、代码、终端和当前上下文。这里的使用方式接近“在一个真实代码仓库里操作”。项目文件夹负责放代码，任务线程负责处理某一次具体需求。

这个界面更适合解释项目工作区的概念：左侧是项目入口，中间是当前任务，底部是终端或运行结果。实际使用时，建议按项目类型拆分工作区，例如codex-demo、playwright-demo、工具脚本项目、博客自动化项目分别管理，避免多个项目互相污染上下文。

更稳妥的做法是：一个项目对应一个明确代码仓库，一个任务只处理一个明确目标。比如“补登录页校验”“修支付按钮样式”“生成测试用例”都应该拆开，而不是塞进同一轮连续聊天里。

三、写完代码后要用Review检查变更

Codex写代码之后，不建议马上合并或直接复制结果。更合理的步骤是让它基于某个基础分支做Review，检查当前改动是否合理、是否影响已有逻辑、是否存在明显风险。

Review适合放在代码提交之前。它不是替代人工审查，而是先把明显问题提前暴露出来，比如文件改动范围太大、函数命名不一致、测试缺失、边界条件没有处理。

画面中的Review区域已经进入修改意见场景，它适合用来回答两个问题：这次改了哪些文件，哪些地方需要人工重点复核。对代码类任务来说，这一步应该放在执行之后、合并之前。

不要把Review当成形式步骤。如果项目涉及支付、登录、权限、数据库迁移、自动化删除文件这类高风险逻辑，必须人工再看一遍关键文件和执行结果。

四、Automations适合处理固定频率的重复任务

有些事情不应该每次手动提醒Codex。比如每天清理一次调试日志、每周整理一次TODO、定时检查某个目录里的代码风格、扫描项目中是否存在临时调试内容。这类任务更适合放进Automations。

Automations页面里有自动化任务入口和New automation按钮。它的定位不是聊天，而是让Codex按固定规则定时执行任务。

自动化入口适合管理长期任务。对个人项目来说，可以设置代码清理、测试提醒、文档更新提醒；对团队项目来说，可以用于固定周期的代码巡检和待办整理。

创建自动化任务时，弹窗里需要写清楚执行内容、频率和目标范围。比如让Codex每天检查代码库，把无用console.log清理掉，并把TODO汇总出来。

这个弹窗更适合讲任务描述、执行频率和权限边界。任务描述越具体，自动化越可控。建议写清楚扫描目录、处理对象、输出方式和是否允许自动提交。比如“只扫描src目录”“只汇总TODO不修改代码”“修改前先生成计划”这些限制都应该提前写明。

不建议一开始就给自动化任务过高权限。如果任务涉及删除文件、批量重构、自动提交代码，最好先让它只生成报告，确认可靠后再放开写入动作。

五、复杂任务先让Codex制定计划，再让它执行

很多Codex使用问题，不是模型能力不够，而是任务一开始就没有拆清楚。比如直接说“帮我加一个支付功能”，这句话对人和模型都太大。它可能涉及页面、接口、状态管理、错误提示、订单状态、测试和文档。

复杂任务开始前，应该先让Codex制定计划：它要改哪些文件，新增哪些组件，影响哪些接口，是否需要测试，哪些地方需要确认。计划通过后再进入执行阶段。

这个任务执行界面更适合承接“先计划、再执行”的场景。判断一个计划是否合格，不是看它写得多长，而是看它有没有说明改动范围、执行步骤和验证方式。

计划阶段的价值，是把不可控的大任务拆成可检查的小步骤。如果计划都说不清楚，直接执行只会增加返工概率。

六、AGENTS.md是项目级员工手册

AGENTS.md可以理解为给Codex看的项目规则文件。它更适合放在项目根目录，用来说明目录结构、编码规范、测试要求、提交规则、命名风格和项目特殊约束。

如果每次都手动告诉Codex“这个项目用什么目录结构”“测试文件放在哪里”“不要改某些配置”，效率会很低。把这些稳定规则写进AGENTS.md，可以减少重复说明，也能降低不同任务之间规则不一致的问题。

画面字幕里明确提到“需要放在项目根目录下”，这正好对应AGENTS.md的放置位置。项目根目录和文件树是判断规则作用范围的关键，随便放到子目录里，可能只影响局部范围，或者被后续任务忽略。

建议AGENTS.md至少包含四类内容：项目结构说明、编码规范、测试命令、禁止修改范围。例如哪些目录不能动、哪些文件属于生成文件、提交前需要跑什么命令，都应该写清楚。

七、Personalization适合放全局偏好

AGENTS.md解决的是项目级规则，Personalization解决的是全局个人偏好。它适合放所有项目都通用的要求，例如回答语言、默认解释方式、代码风格偏好、输出结构和固定检查习惯。

进入Personalization后，可以看到配置区域。这里的内容不应该写某个项目的细节，而应该写跨项目稳定生效的规则。

这个设置页对应的是全局配置，不是某一个项目的配置文件。比如你习惯让Codex先说明改动计划、再执行修改、最后输出验证步骤，这类固定流程就适合放在全局偏好里。

Personalization不要写得太细。如果把某个项目的目录结构、依赖版本、业务规则写到全局配置里，后续切换项目时反而会误导Codex。

八、Skills适合封装重复SOP

Skills更像可复用的流程模板。它适合处理那些经常重复、步骤相对固定、输出结构比较稳定的任务。比如新建React组件、同步生成测试文件、整理Markdown文档、生成CSDN文章结构、清洗Excel数据。

Skills页面强调的是让Codex按你的方式工作，而不是每次重新解释一遍流程。它和AGENTS.md的区别在于：AGENTS.md管项目规则，Skills管可复用操作流程。

这个页面对应Skills入口和工作方式设置，适合解释“把重复操作封装成模板”。如果某个动作你连续说过三次，就可以考虑做成Skill。比如“创建组件时同步创建测试文件”“生成博客时先分析图片语义”“改代码前先列计划后执行”，这些都适合变成流程模板。

Skills的重点不是一次性回答，而是把重复流程固定下来。流程固定之后，后续任务才更容易保持一致，也更容易检查哪里出了问题。

九、推荐使用顺序：先分项目，再写规则，最后封装流程

把Codex用稳，关键是顺序。先把项目工作区分清楚，再写AGENTS.md，再配置Personalization，最后把重复操作做成Skills。如果一开始项目就混乱，后面写再多规则也很难稳定。

收尾画面里的“再写agents.md”更适合放在使用顺序章节，而不是放在Skills执行状态里。它强调的是先把项目和规则整理好，再让Codex按流程工作。

推荐落地顺序可以按下面执行：

第一，按真实项目建立Projects，不要把多个项目塞进同一个工作区。

第二，在项目根目录写AGENTS.md，把目录结构、编码规范、测试命令和禁止修改范围写清楚。

第三，把跨项目偏好放进Personalization，不要把项目专属规则写成全局规则。

第四，把重复执行的流程封装成Skills，再按风险大小决定是否放进Automations。

Codex用得好不好，不只取决于模型能力，也取决于你有没有把项目、规则、流程和自动化分开管理。

十、总结：把Codex当成工作流系统，而不是聊天工具

Codex的使用重点，不是让它在一个聊天窗口里连续回答问题，而是把项目、任务、规则和重复流程拆开。Projects管项目边界，Review管代码检查，Automations管定时任务，AGENTS.md管项目规则，Personalization管全局偏好，Skills管可复用流程。

对于个人开发者来说，这套方法能减少上下文混乱和返工。对于团队来说，它能把零散经验变成规则文件和流程模板。对于技术写作、脚本自动化、桌面运维和数据处理场景，也可以借鉴同样思路：先定义边界，再记录规则，最后再做自动化。

下一次使用Codex时，先不要急着让它动手写代码。先问自己三个问题：这个任务属于哪个项目，项目规则写在哪里，是否已经有可复用的Skill。

点击回到顶部