个人主页杨利杰YJlio❄️个人专栏《Windows 疑难杂症与工单复盘案例库》 《Sysinternals实战教程》《WINDOWS教程》 《Windows PowerShell 实战》 《IOS插件分析测试》《超简单用Python让Excel飞起来》让复杂的事情更简单让重复的工作自动化别再把 Codex 当 ChatGPT 用Projects、AGENTS.md 和 Skills 应该这样分工一、为什么不能把Codex当普通聊天窗口用二、Projects应该理解成项目工作区不是聊天列表三、写完代码后要用Review检查变更四、Automations适合处理固定频率的重复任务五、复杂任务先让Codex制定计划再让它执行六、AGENTS.md是项目级员工手册七、Personalization适合放全局偏好八、Skills适合封装重复SOP九、推荐使用顺序先分项目再写规则最后封装流程十、总结把Codex当成工作流系统而不是聊天工具一、为什么不能把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制定计划它要改哪些文件新增哪些组件影响哪些接口是否需要测试哪些地方需要确认。计划通过后再进入执行阶段。这个任务执行界面更适合承接“先计划、再执行”的场景。判断一个计划是否合格不是看它写得多长而是看它有没有说明改动范围、执行步骤和验证方式。不明确明确不通过通过提出需求需求是否明确先让 Codex 拆解目标和改动范围让 Codex 制定执行计划人工确认计划调整范围和限制条件执行代码修改Review 检查变更人工验证运行结果计划阶段的价值是把不可控的大任务拆成可检查的小步骤。如果计划都说不清楚直接执行只会增加返工概率。六、AGENTS.md是项目级员工手册AGENTS.md可以理解为给Codex看的项目规则文件。它更适合放在项目根目录用来说明目录结构、编码规范、测试要求、提交规则、命名风格和项目特殊约束。如果每次都手动告诉Codex“这个项目用什么目录结构”“测试文件放在哪里”“不要改某些配置”效率会很低。把这些稳定规则写进AGENTS.md可以减少重复说明也能降低不同任务之间规则不一致的问题。画面字幕里明确提到“需要放在项目根目录下”这正好对应AGENTS.md的放置位置。项目根目录和文件树是判断规则作用范围的关键随便放到子目录里可能只影响局部范围或者被后续任务忽略。建议AGENTS.md至少包含四类内容项目结构说明、编码规范、测试命令、禁止修改范围。例如哪些目录不能动、哪些文件属于生成文件、提交前需要跑什么命令都应该写清楚。七、Personalization适合放全局偏好AGENTS.md解决的是项目级规则Personalization解决的是全局个人偏好。它适合放所有项目都通用的要求例如回答语言、默认解释方式、代码风格偏好、输出结构和固定检查习惯。进入Personalization后可以看到配置区域。这里的内容不应该写某个项目的细节而应该写跨项目稳定生效的规则。这个设置页对应的是全局配置不是某一个项目的配置文件。比如你习惯让Codex先说明改动计划、再执行修改、最后输出验证步骤这类固定流程就适合放在全局偏好里。Personalization不要写得太细。如果把某个项目的目录结构、依赖版本、业务规则写到全局配置里后续切换项目时反而会误导Codex。八、Skills适合封装重复SOPSkills更像可复用的流程模板。它适合处理那些经常重复、步骤相对固定、输出结构比较稳定的任务。比如新建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。点击回到顶部
