本页解决什么问题
Codex 能不能长期顺手,不只取决于模型能力,也取决于你有没有把自己的工作方式说清楚、固定下来并定期修正。 本页专门处理八类个人化问题:- 我希望 Codex 用什么语气、什么语言、什么粒度回答。
- 我希望它以什么格式输出计划、diff、测试结果和风险。
- 哪些偏好应该写进个人默认规则,哪些只能写进当前提示。
- 怎样准备上下文,让它少猜、少重复读取、少把无关信息带进来。
- 怎样用斜杠命令、终端别名和编辑器动作减少重复操作。
- 怎样记录复盘,让成功做法可以复用,失败教训不会污染未来任务。
- 怎样按任务风险和复杂度分层,而不是所有事情都用同一套流程。
- 怎样建立一套速度、安全、质量和隐私之间能长期维持的工作节奏。
命令、菜单名称、配置键和模型行为会随版本变化。使用前先运行codex --help、会话内的/help,并以当前版本的官方文档为准。本文中的配置和命令是工作方法示例,不保证适用于每个版本。
先建立三层边界
在开始写个人配置前,先把信息分为三层。分层比“记得越多越好”更重要。
个人默认规则不应覆盖项目硬规则。比如你偏好使用
npm,但项目明确规定使用 pnpm,项目规则优先;你喜欢输出完整解释,但当前任务要求只返回 JSON,就应服从当前任务的明确格式。
可以用下面的判断题决定一条信息放在哪里:
- 以后所有项目都希望如此吗? 是,考虑个人默认规则。
- 只有这个仓库必须如此吗? 是,写入项目
AGENTS.md。 - 只对这一次任务成立吗? 是,写进本次提示。
- 只是今天的临时状态吗? 是,写进状态记录,不要长期记忆。
- 包含秘密、客户资料或私人屏幕内容吗? 不要写入任何记忆、规则或日志。
个人偏好不等于权限授权
“我希望你自动执行测试”是一种工作偏好;“你可以删除目录、访问生产数据库”是权限决定。前者可以沉淀,后者必须在具体操作前逐项确认。 同样,“我喜欢简短回答”不能解释为“省略风险”;“我喜欢自动修复”不能解释为“未经确认就提交或发布”。个性化只改变协作方式,不改变安全边界、审批要求和事实验证标准。设计自己的默认画像
开始时不要写一份长篇自我介绍。先写一张短小的“工作画像”,只保留会反复影响产出的信息。 推荐记录以下字段:一份适合个人使用的规则示例
以下内容可以作为用户级规则的起点。路径和具体文件名以你的 Codex 版本为准:输出格式:先定义交付物
个人化最容易见效的地方是输出格式。你不必要求 Codex 每次都写长报告,但应该明确你想从每一轮得到什么。日常修改的默认格式
适合小型代码修改、文案修正和单函数调整:计划阶段的默认格式
适合需求不清楚、跨文件或影响面较大的任务:代码审查阶段的默认格式
审查时不要让总结掩盖问题。可以固定成按严重程度排序:交接和恢复阶段的默认格式
默认提示词:从固定句变成决策规则
默认提示词适合放稳定的协作规则,不适合替代每次任务的目标。可以使用“默认行为 + 例外条件”的结构。一个完整任务提示模板
从模糊请求改写
模糊请求:上下文习惯:准、少、可恢复
上下文管理的目标不是把所有资料都提供给 Codex,而是提供当前决策必需的资料。每个任务先做上下文清单
开始前快速回答五个问题:- 当前任务的唯一目标是什么?
- 哪些文件直接决定行为?
- 哪条测试或命令可以证明结果?
- 哪些内容是背景但不应影响实现?
- 哪些资料包含敏感信息,不能带入会话?
@ 引用;把完整的错误堆栈、请求形状和最小复现保留下来;不要把整个仓库、完整日志或数据库导出一次性贴进上下文。
一个任务一个会话
同一问题的连续排查适合保留在一个会话里,因为它保留了决策和失败尝试。任务切换到不相关目标时,应新开会话;不要把“一个项目一天一个会话”当成固定规则。 可以按下面的信号决定是否换会话:fork 通常只复制会话上下文,不代表磁盘文件自动隔离。要并行修改同一仓库,使用 Git 分支或 worktree;共享目录中的两个写入会话可能互相覆盖。
何时压缩上下文
当 Codex 开始重复读取文件、遗忘已确认的约束、或工具输出大量截断时,先生成状态摘要,再使用本版本支持的/compact。
压缩前可发送:
快捷方式:减少重复,不隐藏动作
快捷方式的价值是降低输入成本,但每个快捷方式都应该让动作更透明、更容易撤销。常用会话命令
不同版本的命令可能不同,先用/help 确认。常见的工作意图如下:
/plan 之后仍要审核范围;/review 之后仍要确认测试;/resume 之后仍要检查实际工作区。
终端别名示例
可以把只读检查做成别名,减少每次输入,同时保留显式输出:编辑器快捷动作
在 IDE 中,选中最相关的代码再发起请求,通常比让 Codex 扫描整个项目更稳定。可以建立自己的动作习惯:- 先打开实现文件和直接相关测试。
- 选中错误附近的最小代码范围。
- 把终端中的完整错误贴入会话,并删去敏感值。
- 使用固定的“目标 / 范围 / 验收”模板。
- 修改后回到 diff 视图,而不是只看 Codex 的总结。
复盘记录:把经验变成证据
复盘不是写感想,而是记录下一次可以改变行为的事实。每个有返工、误改、测试失败或隐私风险的任务,都值得留下一条短记录。 推荐格式:将复盘升级为规则
一条经验只有在满足以下条件时,才适合升级为长期规则:- 在多个任务中重复出现。
- 行为要求稳定,而不是临时例外。
- 能写成短句,并能通过文件或命令检查。
- 不包含敏感信息,不依赖某个短期分支或端口。
AGENTS.md 或项目规则,但修改前要检查是否会与团队规则冲突。一次失败不能自动证明某个规则永远正确,先观察多次任务,再决定是否固化。
个人记忆与 AGENTS.md 的边界
Memories 适合稳定、低敏感、可复用的上下文,例如常用技术栈和反复出现的工作习惯;必须每次生效的规则应写进 AGENTS.md。记忆通常是后台异步生成,不保证即时出现,也不能代替版本控制中的规则文件。
可以采用“使用旧记忆但暂不生成新记忆”的策略,具体配置以当前版本为准:
/memories 关闭当前会话的记忆使用或生成。关闭生成不会删除已有记忆;删除文件也不会自动关闭功能,两者要分别验证。
任务分层:用合适的流程处理合适的事
所有任务都走完整计划会浪费时间,所有任务都直接执行会增加风险。可以使用四级分层。L0:机械任务
适合的请求:L1:局部实现和修复
适合的请求:L2:跨模块任务
先让 Codex 读代码并回答:影响哪些接口、有哪些调用方、测试在哪里、回滚点是什么。计划确认后,一次只推进一个可验证步骤。 推荐拆法:- 盘点当前行为和调用关系。
- 补充或固定失败测试。
- 修改核心实现。
- 更新直接调用方和类型定义。
- 运行局部测试,再运行更大范围检查。
- 审查 diff、兼容性和文档影响。
/plan 就让一次会话无限扩大。计划的作用是暴露决策,不是替代分阶段交付。
L3:高风险任务
高风险任务的第一步不是“执行”,而是建立证据链和回滚方案:可持续工作流:从开始到结束
下面是一套可以每天重复使用的闭环。1. 开始前检查点
2. 选择任务层级
问自己:这次改动是否跨模块?是否改变公开接口?是否接触外部系统或敏感数据?是否有明确测试?根据答案选择 L0-L3,不要只按“代码行数”判断难度。3. 准备最小上下文
点名实现文件、测试、配置契约和完整错误。过滤无关日志、生成物、凭据和客户数据。对无法确认的内容标记为假设,不要把猜测写成事实。4. 写提示并定义完成
使用目标、上下文、范围、约束、验收五个槽位。验收优先写成命令、测试、退出码、接口响应或可观察界面行为。5. 探索或计划
L0、L1 可以直接读相关文件并实施;L2、L3 先只读分析和计划。确认计划时重点看:是否越界、是否改变兼容性、是否有回滚点、测试是否足够。6. 小步实施
每个步骤只解决一个连贯问题。修改后立刻看 diff;不要积累十几个未经检查的编辑再统一验收。7. 自验证和人工抽检
让 Codex 跑最小相关测试、lint、类型检查或构建,并要求它 review 自己的 diff。你仍需人工抽检边界条件、权限变化、文件范围和测试是否真的覆盖目标。8. 收尾和记录
结束时输出:修改了什么、为什么改、运行了什么、结果如何、哪些未验证、如何回滚。对有教训的任务写一条复盘,不要把秘密和原始个人数据带入记录。速度、质量和可持续性
速度不是单次响应最快,而是从目标到可信交付所需的总时间最短。减少返工通常比盲目降低推理强度更有效。 可以遵循以下顺序:- 先减少歧义,避免错误方向。
- 再减少无关上下文,避免重复读取。
- 再按任务难度选择模型和推理强度。
- 对边界清楚的独立任务并行,但用 worktree 隔离文件。
- 最后才考虑版本支持的快速模式,并确认额外用量成本。
隐私注意:个性化越强,暴露面可能越大
个性化系统会积累更多上下文,因此隐私边界必须主动管理。 绝对不要写入个人规则、Memories、任务状态或公开日志的内容包括:- API key、密码、访问令牌、SSH 私钥和 Cookie。
.env、完整数据库连接串和可直接访问的内部 URL。- 客户姓名、联系方式、订单号、工单原文和未公开业务数据。
- 会议、私信、密码管理器和内部仪表盘的屏幕内容。
- 未公开漏洞、生产凭据、权限批准和安全事件细节。
常见失效方式
偏好文件越来越长。 只保留会反复改变结果的规则;把一次性任务移回提示或状态记录。 个人规则和项目规则冲突。 以项目硬规则和当前明确约束为准,并删除过时的个人偏好。 默认输出过于简短。 要求简洁时仍保留命令、退出码、关键证据和未验证项。 把 Memories 当成硬规则。 必须每次生效的内容写入AGENTS.md,并在关键任务中再次写出验收标准。
快捷方式掩盖风险。 别名可以简化只读检查,但不要把删除、提交、推送和部署包装成无需确认的一键动作。
会话混杂多个任务。 当前任务完成后新开会话;上下文过长时先写状态摘要再压缩。
只记录成功,不记录失败。 失败的尝试和触发条件通常比成功结果更能减少下一次返工。
把一次复盘直接变成永久禁令。 先观察是否重复发生,再写成可验证、低副作用的规则。
最终验收清单
每次调整个人工作方式后,检查:- 默认规则是否短小、明确,并与项目规则分离。
- 输出格式是否保留了证据、风险和未验证项。
- 任务提示是否写出目标、上下文、范围、约束和验收。
- 当前会话是否只承载一个连贯任务。
/plan、/compact、/resume、/fork和/review是否按实际版本验证过。- 快捷方式是否只减少重复输入,而没有隐藏高风险动作。
- 复盘记录是否只包含可验证事实和脱敏内容。
- Memories 中是否只有稳定、低敏感、可复用的信息。
- 关键任务是否通过 diff、测试、构建或真实用户路径验收。
- 当前工作区、分支、修改文件和任务摘要是否一致。
小结
一套好用的个人化方式,不是让 Codex“记住你的一切”,而是把正确的信息放在正确的位置:个人默认规则保存稳定偏好,项目AGENTS.md 保存团队约束,当前提示描述一次性目标,任务记录保存可恢复状态,Memories 只补充低敏感的长期上下文。
把输出格式固定下来,把上下文控制在相关范围,把快捷方式限制在透明动作,把复盘变成短而具体的规则,再按 L0 到 L3 分配流程和权限。这样得到的不是一组漂亮的提示词,而是一套能持续使用、能被检查、出错后能回退的协作系统。
参考资料:参考/codex/13-prompting.md、参考/codex/31-speed.md、参考/codex/36-best-practices.md、参考/codex/19-memory.md。动态命令和配置以本机 --help、会话内 /help 及官方文档为准。