基础设置：先把环境搞对
模型选择是第一步。日常任务用 GPT-5.3-Codex 的 medium 或 high 就够了，xhigh 推理模式留给真正复杂的问题——成本更高、速度更慢，没必要浪费。
一个容易被忽略的点：Codex 不只是写代码的工具。它处理常规查询的能力其实相当不错，能用网页搜索，响应也快。如果你已经在 Codex 应用里干活，没必要来回切换到 ChatGPT。
进入 Codex 应用后，花点时间把内置 Skills 配好——Figma MCP、Notion、PDF/表格编辑器这些都有现成的。其中 Skill Installer 是最值得第一个装的，它能从 openai/skills 或其他仓库安装经过筛选的技能包。
几个关键设置：
- Worktree：用 worktree 做并行任务，避免多线程之间互相冲突
- Actions：把常用命令（启动开发服务器、跑测试、lint）做成 Action，省掉重复输入
- 本地模式：第一条消息用 "Local" 开头，让 Codex 在你本机运行并读取仓库
- 自动化任务：与其用 Manus 之类的工具做定时调度，不如直接用 Codex 的 Automations。但记住——先手动跑一遍验证范围和输出，再设置自动调度
- 项目管理：Codex 支持按创建日期、时间线等方式排序项目，比 ChatGPT 应用的项目管理体验好一个量级
提示词策略：少即是多
Codex 的提示词哲学和 Claude Code 不太一样。Claude Code 倾向于拆解成小步骤逐步推进，Codex 则更适合简短精炼的指令。
核心提示词结构：目标 → 范围 + 上下文 + 行为/步骤 + 验证方式 + 约束条件
具体技巧：
- 大任务先要方案：复杂工作先让它出计划，确认后再分步执行
- 语音规划：可以用 Codex 应用内的"听写"功能来做项目规划，比打字快
- 明确完成标准：说清楚要改哪些文件、预期行为是什么、要通过哪些测试
- 调用 Skill 的格式：重复性任务直接用
Use $my-lint-skill这样的格式调用 - 划定边界：在提示词里明确权限范围，比如"不要动这个项目以外的文件"
- 锁定输出格式：告诉它只返回什么，比如"只输出统一 diff"或"只要代码不要解释"
- 避免"前言"请求：Codex 设计上会跳过这类内容，要求前言反而可能导致提前结束
Token 用量优化：这才是真正的效率差距
大部分人用 Codex 的成本偏高，根源在于 token 浪费。三条硬规则：
- 不要重复指令——这是 token 的最大杀手，所以结构化的提示词模板才重要
- 不要发送整个文件——只提供正在修改的函数、相关接口和依赖的类型定义
- 设硬上限——
"最多5个要点"、"用不超过120 tokens解释"、"只输出代码"
这三条做到位，token 消耗能降一半以上。
上下文管理：知道什么时候该重置
Codex 和所有 LLM 工具一样，上下文越长质量越差。三个信号告诉你该重置了：
- 模型开始偏离主题
- 回复质量明显下降
- 任务方向发生了转变
遇到这些情况，果断重置项目上下文。让 Codex 继续在无关的历史上下文里打转，只会越来越差。
一个值得注意的工作流：模型堆叠。先用 Claude Code 做初步开发，再切到 Codex 继续。不同模型的优势互补，输出质量会比单用一个好。
工作流与最佳实践
把思考和构建分开，这是高手和新手的分水岭：
- 第一步：确定方法
- 第二步：评估风险
- 第三步：设计方案
- 第四步：写代码
复杂项目至少花 15-20 分钟做规划。规划永远比直接动手重要。
对抗性测试：上线前用"试着搞坏它"这样的提示词做压力测试，比你自己检查有效得多。
结构先行：复杂任务先让模型列大纲再执行，不要上来就写。
Git 和个性化配置
- Git 提交纪律：永远先看 diff，只暂存你需要的 hunk，不要的及时 revert。Codex 的审查面板支持按文件和按 hunk 粒度的暂存/回退
- Settings → Git：可以添加多条自定义 Git 指令
- Settings → Personalization：自定义个人指令、语气和风格，别放着不用
- 自定义斜杠命令：直接告诉 Codex
"我要创建一个叫 /x 的斜杠命令，它的作用是……从现在起记住它" - Run 功能：右上角的 "Run" 按钮可以配置依赖安装和应用启动方式
说句直接的判断：Codex 目前最大的竞争力不在模型本身，而在它把编码、项目管理、自动化、技能系统整合进了一个应用。对独立开发者来说，工具链越短，摩擦越小，出活越快。但这个赛道 Claude Code、Cursor 都在猛追，真正的壁垒还没形成——现在的策略是哪个顺手用哪个，不要把工作流绑死在任何一家上。