最近这段时间，我一直在拿 Codex CLI 当主力折腾。
刚开始其实没抱太大期待。 这类 AI 编程工具现在已经不少了，刚上手的时候，看起来也都差不多：能读代码、能改代码、能聊天、能跑命令。
但我用了一阵子之后，感觉慢慢变了。
它最打动我的地方，不是“默认就有多强”，而是：
这东西挺值得调，而且越调越顺手。
我后来越来越觉得，Codex 有点像编辑器、终端、IDE 这类工具。 默认状态下当然也能用，但真正好不好用，往往取决于你有没有把它调成适合自己的样子。
所以这篇我不想按“产品介绍”的方式来写， 我更想聊聊我自己的实际使用过程：
- 我为什么开始认真配 Codex
- 我是按什么思路一点点把它调顺手的
- 哪些配置我觉得是真的有用
- 我现在最常用的几个工作流是什么
如果你也在用 Codex，或者刚装上但还没找到感觉，可能会有点参考价值。
我为什么会从“随便试试”，变成“认真配置”
一开始我也是默认安装、默认使用， 想着先看看它到底能干成什么样。
结果用着用着，我发现有几类问题特别影响体验，而且还挺高频。
比如：
- 我明明只是想让它分析一下，它直接开始改代码
- 我让它在原文件上修，它转头给我新建了一个文件
- 我在 Windows 上用，它却老按 Linux 命令那套来想
- 有些它其实没确认的事，会直接猜，而且语气还挺笃定
这些问题单看都不算致命， 但如果你每天都在用，它们会非常消耗耐心。
后来我慢慢意识到一件事：
AI 工具不好用，很多时候不是因为它不够聪明，而是因为你没先把规矩立清楚。
也就是说，问题不全在模型本身， 而在于协作方式没有被定义好。
从那之后，我就开始认真折腾配置了。 思路也很简单：
先立规则，再做模板，最后把高频动作封装成工作流。
这基本就是我后面所有配置的出发点。
我的整体思路：先立规矩，再做工作流
我现在回头看，真正让我觉得 Codex “开始像个搭子” 的，不是某一个功能突然特别强，而是我把它分成了三层来处理：
第一层：全局规则
先把最基础的行为边界定下来。 比如说话语言、做事方式、环境习惯、哪些事能做、哪些事不能乱做。
这一层我主要放在 AGENTS.md 里。
第二层：高频 Prompt
把一些会反复出现、但又比较明确的任务，做成短小的模板。 这样以后不用每次重新组织语言。
这一层我放在 prompts/ 里。
第三层：可复用 Skill
把那些带步骤、有流程、能复用的事情，直接封装成工作流。 这样就不只是“问它一句”，而是让它按一套固定方式协作。
这一层我放在 skills/ 里。
这个分层对我来说很重要。 因为如果一上来就堆很多 Prompt、很多招式，最后往往会越来越乱。 先把基础规则立住，后面的东西才会越配越顺。
我的配置基本都放在 .codex/ 下面
Codex 的配置目录挺集中，基本都在这里：
- macOS / Linux：
~/.codex/ - Windows：
C:\Users\你的用户名\.codex\
我现在大概是这么组织的：
.codex/
├── AGENTS.md
├── AGENTS.override.md
├── prompts/
│ ├── check-fix.md
│ └── ...
├── skills/
│ ├── plan/
│ │ └── SKILL.md
│ ├── play/
│ │ └── SKILL.md
│ ├── mindmap/
│ │ └── SKILL.md
│ └── prompt/
│ └── SKILL.md
└── sessions/
如果只说“最值得花时间写”的文件，
那一定是 AGENTS.md。
因为在我这套用法里，它不是普通配置文件， 更像是一份 AI 协作守则。
先说最核心的：我怎么写 AGENTS.md
我现在特别认同一句话：
别总想着临场纠正，能提前写进规则里的，就提前写进去。
因为很多要求如果你每天都要重复说一遍，那本身就是一种浪费。
所以我会把一些高频要求直接固化进全局规则里。 大体上我会分成四类：语言、行为底线、环境约束、风格习惯。
第一类：先把语言规则钉死
这个真的特别基础，但很有必要。
我自己是习惯看中文解释的， 但命令、日志、报错、代码标识符这些内容，我又希望它保留原始语言。 所以我直接写死成这样：
- Always reply in Chinese.
- 除非用户明确要求英文，否则所有回复使用简体中文。
- 代码标识符、命令、日志、报错信息保持原始语言；其余解释用中文。
这条看起来简单， 但长期体验提升很明显。
因为它解决的是那种“每次都不难提醒，但每天提醒真的很烦”的问题。
第二类：把基础行为底线立住
这一块是我后面最看重的部分。 因为很多协作上的不适感，其实都来自这里。
我大概会放这些规则：
- 维持质量与一致性，彻底执行自动检查
- 事实确认，不将猜测当作事实
- 优先编辑现有文件，而不是新建文件
- 先确认任务性质，如果只是计划或文档，不要擅自动代码
这几句不长，但它们几乎都对应了我之前踩过的坑。
不要把猜测当事实
这是我最在意的一条。 AI 最危险的时候，不是它说“我不确定”， 而是它不确定但还说得跟真的一样。
优先改现有文件，而不是新建文件
这个完全是被折磨出来的。 很多改动明明应该落在原来的上下文里，它偏偏喜欢另起一个文件。 短期看像是“交付得快”，长期看就是制造噪音。
计划类任务不要直接动代码
有时候我只是想让它帮我理一下思路， 结果它默认我是在下达执行命令，直接就开始改。 所以后来我干脆把边界写清楚。
这类规则最大的意义，就是让它先学会“别乱动”。
第三类：我在 Windows 上用，所以把环境规则也写进去了
这一块是典型的“你不写，它就容易按默认环境想当然”。
Codex 有时候会天然带着 Linux 命令思维， 但我平时主要在 Windows 上工作。 所以我后来直接把一些工具映射写清楚了：
| 操作 | 使用工具 | 禁止 |
| -------- | -------- | ------------- |
| 读文件 | Read | cat/head/tail |
| 搜文件 | Glob | find/ls |
| 搜内容 | Grep | grep/rg |
| 编辑 | Edit | sed/awk |
| 创建 | Write | echo > |
| 系统命令 | Bash | PowerShell |
你可以把它理解成一句话：
别按错环境习惯。
这东西不写的时候，问题不是每次都爆炸， 而是偶尔来一次就很烦。 写了之后，至少能把很多莫名其妙的翻车挡在前面。
第四类：我还给它加了一点“风格设定”
这个不是必须的， 但我自己用下来，确实会影响手感。
我不太喜欢那种过于标准、过于圆滑的 AI 语气。 很多时候它看起来很礼貌、很完整，但就是没有判断力，也没有那种“真在跟你一起把问题想清楚”的感觉。
所以我给它加了一点更像技术搭子的风格，大概是这种方向：
- 技术要求高
- 不会无脑附和
- 看见问题会直接指出来
- 说话可以自然一点，别太客服腔
我甚至给它加了点“东北老哥”味儿。 不是为了整活，主要是我想让它更像一个有经验、有判断的同事，而不是一个永远只会顺着说的工具。
当然，这块纯看个人习惯。 有人喜欢严肃，有人喜欢极简，我只是分享我自己的偏好。
把基础规则立住之后，我才开始做 Prompt 和 Skill
我后来发现，真正提升效率的，不只是“它更听话了”， 而是我把很多重复出现的动作做成了模板。
因为开发里有很多事情，你不是不会做， 而是每次重新组织一遍思路很费劲。
所以我会这么分：
- Prompt：解决明确、单点、高频的问题
- Skill：封装带步骤、可复用的工作流
这个区分挺重要。 我一开始是什么都往 Prompt 里塞，后面才发现复杂流程还是 Skill 更合适。
我最常用的 Prompt：修完 bug 之后，再看一眼有没有带出副作用
这个 Prompt 叫：
/check-fix
它的出发点很简单， 因为我之前真的遇到过很多次这种情况：
一个 bug 当下修好了，但后面发现把别的地方也带崩了。
不是代码不会写， 而是影响范围没看全。
所以我后来专门做了一个检查模板，让它在修完之后帮我做一轮结构化复盘。 重点看这些东西：
- 改过的函数有哪些调用方
- 参数签名有没有变
- 返回值结构是不是还兼容
- 数据结构变化会不会影响旧逻辑
- 上下游调用链有没有连锁反应
这个 Prompt 我现在基本已经形成习惯了。 只要是稍微涉及核心逻辑的改动，我大概率都会顺手跑一下。
它不一定能把所有问题一次全找出来， 但它很适合做“第二眼检查”。 很多本来容易被我忽略的方向，至少它会提醒我去看。
Skill 里，我最依赖的是 $plan
如果只选一个我现在最常用的 Skill， 那大概率就是它。
因为我现在非常确定一件事：
复杂任务最怕的，不是难，而是边想边改。
当下看起来很快， 但特别容易返工，而且很容易改着改着就失去全局感。
所以我给自己做了一个规划模式：
$plan 实现用户认证功能
它接到之后，不是直接开始写代码， 而是先去做这几件事：
- 看现有项目结构
- 理解需求
- 分析影响范围
- 拆任务步骤
- 生成一份本地计划文档
这里我定了一条特别重要的规则：
计划阶段只读不写。
也就是说，在 $plan 阶段，它不能直接改源代码。
它只能分析、整理、产出计划。
等我确认计划没问题了，再执行：
$do-plan
这个工作流对我最大的帮助，不是“显得流程化”， 而是真的能降低返工率。
因为很多时候浪费时间的不是执行， 而是你在错误方向上执行了很久。
第二个很实用的 Skill，是 $play
这个主要是给 Playwright 自动化准备的。
比如我会直接这样用：
$play http://localhost:3000/admin
然后它会去：
- 打开页面
- 检查页面状态
- 如果需要登录，就继续处理登录流程
- 中间如果有异常，直接停下来告诉我
这个功能我很喜欢的一点是，它接管了不少高频但机械的动作。
尤其本地联调的时候， 你会不断地：
- 打开页面
- 重新进页面
- 处理登录
- 验证页面有没有按预期工作
这些事本身不难， 但一天做很多次就真的挺烦。
所以我现在能交给它的，就尽量交给它。
再往后，是我很喜欢的 $mindmap
这个 Skill 比较像“整理思路加速器”。
比如我在做技术调研， 脑子里已经有一个主题了，但还没有成型的结构， 我就会直接扔一句：
$mindmap React 状态管理方案对比
然后它会先组织出结构化内容， 再用 markmap 生成思维导图， 最后直接打开预览。
它的价值不在于“技术上有多复杂”， 而在于它把我从“从零开始整理”的阻力里拉了出来。
以前很多时候不是我不会整理， 而是我懒得从空白页面开始搭结构。 现在变成“先说，再整理”，整个过程就顺很多。
最后一个我会留着长期用的 Skill，是 $prompt
这个更偏“提示词优化器”。
有些 Prompt 不是完全没用， 而是很不稳定：今天能跑，明天跑偏；这个任务有效，换个任务就出问题。
所以我给自己做了个 $prompt，专门拿来分析这些内容：
- 这段 Prompt 的目标够不够清晰
- 结构有没有问题
- 约束是不是太松
- 哪些地方容易让模型误解
- 怎么改会更稳
- 改完之后怎么做对比测试
它不属于我那种“每天必用”的工具， 但只要我开始认真打磨一个 Prompt，它就很有价值。
因为 Prompt 最烦的从来不是“写不出来”， 而是“总感觉差一点，但又不知道差在哪”。
这些配置最后给我带来的，不只是“更快”，而是整个协作方式变了
如果一定要总结，我觉得变化主要在两个层面。
第一层：很多重复性脑力消耗被接管了
比如：
- 改完 bug，不再完全靠自己硬扫影响范围
- 碰到复杂任务，不再直接冲进去改
- 本地页面验证，不想再手动一遍遍点
- 做技术调研时，不再总卡在“脑子里有，但懒得整理”
这些都不是大事， 但它们往往最消耗注意力。
第二层：我和 AI 的关系变了
以前更像什么？
更像我在旁边一直盯着它：
- 提醒它说中文
- 提醒它别乱猜
- 提醒它别乱建文件
- 提醒它先分析再动手
- 提醒它检查影响范围
现在更像什么？
更像我先把规则和流程搭好， 然后让它按这套方式来协作。
这两种状态差别挺大的。 前者是实时遥控，后者更像是在培养一个固定搭子。
最后说点真实感受
我现在对 Codex 的看法其实挺简单的：
它不是那种装上就立刻封神的工具，但很适合愿意打磨自己工作流的人。
如果你只是默认安装、默认用法，那它当然也能干活。 但如果你愿意多往前走一步：
- 写好全局规则
- 把高频任务做成 Prompt
- 把复杂动作做成 Skill
- 让它适应你的环境、习惯和边界
那它带来的顺手感会越来越明显。
至少对我来说，它现在已经不是一个“偶尔拿来玩玩”的东西了， 而是真的进了我的日常工作流。
这也是我为什么想专门把这套东西整理出来。 不一定是标准答案，但至少是我自己一路踩坑、一路调整之后，磨出来的一版“顺手配置”。
如果你也喜欢把工具链慢慢打磨到顺手， 那 Codex 这套东西其实挺值得玩。
附件
文里提到的配置文件我都一起打包了，放在下面，感兴趣可以直接点开看：
- AGENTS.md：全局规则
- AGENTS.override.md：覆盖配置
- check-fix.md：修完之后检查有没有带出副作用
- plan/SKILL.md：任务规划模式
- play/SKILL.md：Playwright 自动化
- mindmap/SKILL.md：思维导图生成
- prompt/SKILL.md：提示词优化
不过还是那句话：
这套配置只是我自己磨出来的“顺手版”，不是标准答案。
拿去直接用当然可以， 但最好还是按你自己的习惯改一遍。 因为 AI 工具真正好用的时候，一定不是它像别人，而是它开始像你。
