> ## Documentation Index > Fetch the complete documentation index at: https://aicoding.cscitech.top/llms.txt > Use this file to discover all available pages before exploring further. # 05-个性化工作方式 > 把个人偏好、提示词、上下文习惯和复盘记录组织成可持续、可验证的 Codex 工作流。 ## 本页解决什么问题 Codex 能不能长期顺手，不只取决于模型能力，也取决于你有没有把自己的工作方式说清楚、固定下来并定期修正。 本页专门处理八类个人化问题： * 我希望 Codex 用什么语气、什么语言、什么粒度回答。 * 我希望它以什么格式输出计划、diff、测试结果和风险。 * 哪些偏好应该写进个人默认规则，哪些只能写进当前提示。 * 怎样准备上下文，让它少猜、少重复读取、少把无关信息带进来。 * 怎样用斜杠命令、终端别名和编辑器动作减少重复操作。 * 怎样记录复盘，让成功做法可以复用，失败教训不会污染未来任务。 * 怎样按任务风险和复杂度分层，而不是所有事情都用同一套流程。 * 怎样建立一套速度、安全、质量和隐私之间能长期维持的工作节奏。 这里的“个性化”不是把所有指令都塞进一个巨大文件，也不是让 Codex 猜你的习惯。好的个性化应该满足四个条件：**明确、稳定、可检查、容易撤销**。 > 命令、菜单名称、配置键和模型行为会随版本变化。使用前先运行 `codex --help`、会话内的 `/help`，并以当前版本的官方文档为准。本文中的配置和命令是工作方法示例，不保证适用于每个版本。 ## 先建立三层边界 在开始写个人配置前，先把信息分为三层。分层比“记得越多越好”更重要。 | 层级 | 适合保存的内容 | 常见位置 | 可靠性 | | ---- | ------------------- | --------------------- | -------- | | 个人默认 | 语言、回答结构、常用工具、个人沟通偏好 | 用户级 `AGENTS.md` 或个人配置 | 每个项目默认适用 | | 项目规则 | 构建、测试、目录约定、团队安全边界 | 仓库中的 `AGENTS.md` | 对该项目持续适用 | | 当前任务 | 本次目标、范围、临时限制、验收条件 | 当前提示或任务状态记录 | 只对当前任务适用 | 个人默认规则不应覆盖项目硬规则。比如你偏好使用 `npm`，但项目明确规定使用 `pnpm`，项目规则优先；你喜欢输出完整解释，但当前任务要求只返回 JSON，就应服从当前任务的明确格式。 可以用下面的判断题决定一条信息放在哪里： 1. **以后所有项目都希望如此吗？** 是，考虑个人默认规则。 2. **只有这个仓库必须如此吗？** 是，写入项目 `AGENTS.md`。 3. **只对这一次任务成立吗？** 是，写进本次提示。 4. **只是今天的临时状态吗？** 是，写进状态记录，不要长期记忆。 5. **包含秘密、客户资料或私人屏幕内容吗？** 不要写入任何记忆、规则或日志。 ### 个人偏好不等于权限授权 “我希望你自动执行测试”是一种工作偏好；“你可以删除目录、访问生产数据库”是权限决定。前者可以沉淀，后者必须在具体操作前逐项确认。 同样，“我喜欢简短回答”不能解释为“省略风险”；“我喜欢自动修复”不能解释为“未经确认就提交或发布”。个性化只改变协作方式，不改变安全边界、审批要求和事实验证标准。 ## 设计自己的默认画像 开始时不要写一份长篇自我介绍。先写一张短小的“工作画像”，只保留会反复影响产出的信息。 推荐记录以下字段： ```text theme={null} 称呼和语言：使用简体中文；代码、命令、路径保持原文。 回答风格：先给结论，再给证据；避免空泛鼓励。 修改习惯：先读相关文件；小范围编辑；不要触碰无关文件。 验证习惯：改逻辑后运行最小相关测试，并说明未验证部分。 Git 习惯：默认不提交、不推送；先展示 git diff。 提问习惯：有歧义时列出假设；涉及高风险动作先停下来确认。 隐私习惯：不读取 .env、私钥、客户数据；日志和链接先脱敏。 ``` 这份画像的重点不是描述你是谁，而是描述“什么样的协作结果对你有用”。例如，“我是一名后端开发”不如“后端任务优先给出接口契约、错误处理和测试命令”更可执行。 ### 一份适合个人使用的规则示例 以下内容可以作为用户级规则的起点。路径和具体文件名以你的 Codex 版本为准： ```md theme={null} # 我的 Codex 工作偏好 ## 交流 - 默认使用简体中文回答；代码、命令和错误原文保持原样。 - 先给结论，再给关键依据；不要重复我的问题。 - 只有在确实影响方案时才提问；不确定时列出假设。 ## 工作方式 - 先读取相关文件、项目规则和已有测试，再提出修改方案。 - 小任务直接处理；跨模块或高风险任务先给计划，不要立即编辑。 - 保持改动最小，不为统一风格顺手重构无关代码。 ## 验证 - 改动后运行最小相关检查，并说明命令、结果和未验证项。 - 如果测试失败，先报告根因和影响范围，再决定是否继续。 - 结束时给出变更文件、验证结果、剩余风险和回滚方式。 ## 安全 - 默认不提交、不推送、不部署、不删除数据。 - 不读取或输出密钥、令牌、私钥、Cookie、客户资料和完整内部链接。 - 网络、安装依赖、生产操作和批量修改必须先说明影响并等待确认。 ``` 这份规则有意保持短小。它不应该包含某个任务的文件名、临时端口、当前分支或某一次报错，因为这些信息很快会失效。 ## 输出格式：先定义交付物 个人化最容易见效的地方是输出格式。你不必要求 Codex 每次都写长报告，但应该明确你想从每一轮得到什么。 ### 日常修改的默认格式 适合小型代码修改、文案修正和单函数调整： ```text theme={null} 请按以下格式回答： 1. 结论：一句话说明是否完成。 2. 改动：列出文件路径和每个文件的目的。 3. 验证：列出实际运行的命令和结果。 4. 风险：只写仍未确认的风险；没有则写“无”。 不要复述完整代码，不要提交或推送。 ``` ### 计划阶段的默认格式 适合需求不清楚、跨文件或影响面较大的任务： ```text theme={null} 先只做分析，不修改文件。请按以下格式输出： 目标：把需求改写成一句可验收的结果。 已知事实：只列出已从文件、测试或命令确认的事实。 待确认：列出会改变方案的歧义。 范围：准备读取和修改哪些文件；明确不碰哪些目录。 方案：按执行顺序列出 3-7 步。 验证：每一步对应的检查或测试。 风险：权限、兼容性、数据和回滚风险。 等我确认后再编辑。 ``` ### 代码审查阶段的默认格式 审查时不要让总结掩盖问题。可以固定成按严重程度排序： ```text theme={null} 请只做 review，不修改文件。按严重程度输出： [高] 文件:行号 问题：描述可复现的行为或回归。 证据：引用最小必要代码或测试结果。 影响：说明谁会受到影响。 建议：给出最小修复方向。 如果没有问题，明确写“未发现确定性问题”，再列出测试缺口和残余风险。 ``` ### 交接和恢复阶段的默认格式 ```text theme={null} 请生成短交接摘要，不修改文件，且只写已验证事实： - 原始目标和非目标 - 当前路径、分支和工作区状态 - 已改文件及意图 - 已运行命令及结果 - 失败尝试及原因 - 下一步唯一建议动作 - 风险、回滚点和未验证假设 不要包含秘密、个人数据或未经证实的推测。 ``` 输出格式的边界也要明确。不要要求“永远简短”，因为调试堆栈、迁移步骤和安全审查需要足够证据；更好的说法是“默认简洁，但保留做出决定所需的证据”。 ## 默认提示词：从固定句变成决策规则 默认提示词适合放稳定的协作规则，不适合替代每次任务的目标。可以使用“默认行为 + 例外条件”的结构。 ```text theme={null} 默认行为： - 先检查项目规则、相关文件和测试。 - 先确认范围，再进行最小修改。 - 完成后运行与改动直接相关的验证。 - 报告证据、风险和未验证项。 例外： - 单文件拼写或明显机械修改可直接完成。 - 影响数据库、权限、外部服务、删除或发布时，先停下确认。 - 需求不清且存在多种架构选择时，先输出计划和问题。 - 当前提示明确要求不同输出格式时，以当前提示为准。 ``` ### 一个完整任务提示模板 ```text theme={null} 目标： [描述最终要观察到的行为，不只写“优化”或“处理一下”。] 上下文： - 相关文件：@[路径] - 复现步骤： - 错误输出： - 相关接口或数据约定： 范围： - 可以修改：[文件、目录或函数] - 不要修改：[目录、配置、接口或依赖] 约束： - 保持向后兼容：[是/否，具体说明] - 不引入新依赖：[是/否] - 不访问：[生产、密钥、外部服务等] 验收： - [测试、构建、命令或可观察行为] - [边界条件] - [diff 范围] 流程： 先读取并复述关键事实；如果任务跨多个模块，先给计划；确认后实施；最后展示 diff 和验证结果。 ``` ### 从模糊请求改写 模糊请求： ```text theme={null} 帮我把搜索做快一点。 ``` 可执行请求： ```text theme={null} 目标：让 search(query) 在 10000 条固定测试数据上的 P95 延迟低于 200ms。 上下文：读取 @src/search.ts 和 @tests/search.perf.ts；保持现有返回结构。 约束：不改变公开函数签名，不新增依赖，不牺牲大小写匹配和分页行为。 验收：补充或更新性能测试，运行指定测试，并比较优化前后的结果。 范围：只修改搜索实现和直接相关测试；先给出可能的瓶颈和计划，不立即改代码。 ``` 前一个请求缺少目标、上下文、约束和验收，Codex 只能替你做决定。后一个请求并不保证方案一定正确，但它让判断可以被审查和验证。 ## 上下文习惯：准、少、可恢复 上下文管理的目标不是把所有资料都提供给 Codex，而是提供当前决策必需的资料。 ### 每个任务先做上下文清单 开始前快速回答五个问题： 1. 当前任务的唯一目标是什么？ 2. 哪些文件直接决定行为？ 3. 哪条测试或命令可以证明结果？ 4. 哪些内容是背景但不应影响实现？ 5. 哪些资料包含敏感信息，不能带入会话？ 把相关文件点名，必要时使用 `@` 引用；把完整的错误堆栈、请求形状和最小复现保留下来；不要把整个仓库、完整日志或数据库导出一次性贴进上下文。 ### 一个任务一个会话 同一问题的连续排查适合保留在一个会话里，因为它保留了决策和失败尝试。任务切换到不相关目标时，应新开会话；不要把“一个项目一天一个会话”当成固定规则。 可以按下面的信号决定是否换会话： | 信号 | 动作 | | ------------------ | ------------------ | | 仍在解决同一个 bug，刚得到新日志 | 继续当前会话 | | 目标已完成，准备做完全不同的功能 | 新开会话 | | 想保留当前分析并比较另一套方案 | 在隔离工作区中 fork | | 早期日志已无用、上下文开始混乱 | 先保存状态，再 `/compact` | | 会话恢复后目录或分支不明 | 立即停止写入，先检查环境 | `fork` 通常只复制会话上下文，不代表磁盘文件自动隔离。要并行修改同一仓库，使用 Git 分支或 worktree；共享目录中的两个写入会话可能互相覆盖。 ### 何时压缩上下文 当 Codex 开始重复读取文件、遗忘已确认的约束、或工具输出大量截断时，先生成状态摘要，再使用本版本支持的 `/compact`。 压缩前可发送： ```text theme={null} 在压缩前整理状态，不修改文件： 目标、非目标、当前分支、已改文件、验证命令、失败原因、已确认约束、下一步动作和禁止事项。 只写可由 git、文件或命令验证的事实。 ``` 压缩后不要盲信摘要。重新检查： ```bash theme={null} git status --short git diff --stat git diff --check ``` 上下文摘要不能替代代码、测试输出和任务状态文件。尤其不要把迁移顺序、权限批准或唯一的回滚信息只留在会话记忆里。 ## 快捷方式：减少重复，不隐藏动作 快捷方式的价值是降低输入成本，但每个快捷方式都应该让动作更透明、更容易撤销。 ### 常用会话命令 不同版本的命令可能不同，先用 `/help` 确认。常见的工作意图如下： ```text theme={null} /plan 先探索并输出计划 /status 查看当前会话状态 /compact 压缩较早上下文 /resume 恢复已有会话 /fork 从当前节点分叉会话 /review 审查改动或基准差异 /memories 控制当前会话使用或生成记忆 ``` 不要把命令名称本身当成工作流。比如 `/plan` 之后仍要审核范围；`/review` 之后仍要确认测试；`/resume` 之后仍要检查实际工作区。 ### 终端别名示例 可以把只读检查做成别名，减少每次输入，同时保留显式输出： ```bash theme={null} alias ccheck='git status --short && git diff --stat && git diff --check' alias cbranch='printf "branch: "; git branch --show-current' alias ctest='git diff --check' ``` 这些别名只做检查，不应隐藏安装、删除、提交、推送和部署动作。不要把包含密码、令牌或生产地址的命令写入 shell 历史或脚本。 ### 编辑器快捷动作 在 IDE 中，选中最相关的代码再发起请求，通常比让 Codex 扫描整个项目更稳定。可以建立自己的动作习惯： * 先打开实现文件和直接相关测试。 * 选中错误附近的最小代码范围。 * 把终端中的完整错误贴入会话，并删去敏感值。 * 使用固定的“目标 / 范围 / 验收”模板。 * 修改后回到 diff 视图，而不是只看 Codex 的总结。 快捷方式不应跳过审批，也不应让“自动接受所有修改”成为默认个人偏好。 ## 复盘记录：把经验变成证据 复盘不是写感想，而是记录下一次可以改变行为的事实。每个有返工、误改、测试失败或隐私风险的任务，都值得留下一条短记录。 推荐格式： ```text theme={null} 日期：2026-09-05 任务：为订单导出增加空结果处理 目标：空结果返回含表头的空 CSV 结果：功能完成，测试通过 返工：第一次修改了不相关的 formatter.py 根因：提示没有写明修改范围 有效做法：点名 export.py 和 tests/test_export.py 下次规则：跨文件任务先列“可改 / 不可改”清单 验证：pytest tests/test_export.py -q；8 passed 隐私检查：未读取 .env，日志已脱敏 ``` ### 将复盘升级为规则 一条经验只有在满足以下条件时，才适合升级为长期规则： * 在多个任务中重复出现。 * 行为要求稳定，而不是临时例外。 * 能写成短句，并能通过文件或命令检查。 * 不包含敏感信息，不依赖某个短期分支或端口。 例如，“这次不要改数据库”不能放入长期规则；“未经明确确认，不执行生产数据库写操作”可以成为稳定的安全规则。 复盘可以修改个人 `AGENTS.md` 或项目规则，但修改前要检查是否会与团队规则冲突。一次失败不能自动证明某个规则永远正确，先观察多次任务，再决定是否固化。 ### 个人记忆与 `AGENTS.md` 的边界 Memories 适合稳定、低敏感、可复用的上下文，例如常用技术栈和反复出现的工作习惯；必须每次生效的规则应写进 `AGENTS.md`。记忆通常是后台异步生成，不保证即时出现，也不能代替版本控制中的规则文件。 可以采用“使用旧记忆但暂不生成新记忆”的策略，具体配置以当前版本为准： ```toml theme={null} [features] memories = true [memories] use_memories = true generate_memories = false ``` 涉及外部网页、MCP、客户资料、安全事件或一次性实验时，应考虑通过 `/memories` 关闭当前会话的记忆使用或生成。关闭生成不会删除已有记忆；删除文件也不会自动关闭功能，两者要分别验证。 ## 任务分层：用合适的流程处理合适的事 所有任务都走完整计划会浪费时间，所有任务都直接执行会增加风险。可以使用四级分层。 | 层级 | 典型任务 | 推荐流程 | 默认算力和权限 | | ------ | ------------------ | ---------------- | --------- | | L0 机械 | 改错字、重命名、格式化单文件 | 直接修改，做 diff 检查 | 低推理，最小权限 | | L1 局部 | 单函数 bug、补测试、小型配置调整 | 四件套提示，跑相关测试 | 中低推理，默认审批 | | L2 跨模块 | API 变更、重构、依赖升级 | 先计划，分步实施，每步验证 | 中高推理，逐步审批 | | L3 高风险 | 生产、权限、数据迁移、发布 | 先取证和审批，准备回滚，双人复核 | 高推理，严格权限 | ### L0：机械任务 适合的请求： ```text theme={null} 把 @src/config.ts 中的变量 DEFAULT_TIMEOUT 重命名为 REQUEST_TIMEOUT。 只修改引用它的代码和相关测试，不改变行为。 完成后运行格式检查和相关测试，展示 diff；不要提交。 ``` 即使是机械任务，也要检查是否存在公开 API、生成文件或大小写敏感路径。简单不等于不需要验证。 ### L1：局部实现和修复 适合的请求： ```text theme={null} 目标：修复 @src/stats.py 的 average([]) 除零错误，空列表返回 0。 范围：只修改 stats.py 和对应测试。 约束：不引入依赖，不改变非空输入行为。 验收：覆盖空列表、[2, 4] 和负数输入；运行 pytest 对应测试。 先读取现有实现和测试，然后直接实施；完成后报告 diff 和测试结果。 ``` ### L2：跨模块任务 先让 Codex 读代码并回答：影响哪些接口、有哪些调用方、测试在哪里、回滚点是什么。计划确认后，一次只推进一个可验证步骤。 推荐拆法： 1. 盘点当前行为和调用关系。 2. 补充或固定失败测试。 3. 修改核心实现。 4. 更新直接调用方和类型定义。 5. 运行局部测试，再运行更大范围检查。 6. 审查 diff、兼容性和文档影响。 不要因为使用了 `/plan` 就让一次会话无限扩大。计划的作用是暴露决策，不是替代分阶段交付。 ### L3：高风险任务 高风险任务的第一步不是“执行”，而是建立证据链和回滚方案： ```text theme={null} 先不要修改生产状态。请确认： - 当前环境、账号和权限边界 - 原始症状、请求路径和时间范围 - 相关日志或指标，输出时脱敏 - 可能影响的用户、数据和服务 - 可回滚版本、备份或反向迁移 - 需要我确认的具体动作 把结果分为“已验证事实 / 待确认假设 / 下一步动作”。 ``` 生产修复、权限变更、支付、通知、批量删除和数据库迁移，不应仅凭个人默认偏好自动放行。即使 Codex 给出明确方案，也要由有权限的人确认实际影响。 ## 可持续工作流：从开始到结束 下面是一套可以每天重复使用的闭环。 ### 1. 开始前检查点 ```bash theme={null} pwd git branch --show-current git status --short codex --version ``` 确认目录、分支和未提交修改的归属。发现工作区很脏或包含其他人的改动时，先缩小范围，不要直接执行大规模修改。 ### 2. 选择任务层级 问自己：这次改动是否跨模块？是否改变公开接口？是否接触外部系统或敏感数据？是否有明确测试？根据答案选择 L0-L3，不要只按“代码行数”判断难度。 ### 3. 准备最小上下文 点名实现文件、测试、配置契约和完整错误。过滤无关日志、生成物、凭据和客户数据。对无法确认的内容标记为假设，不要把猜测写成事实。 ### 4. 写提示并定义完成 使用目标、上下文、范围、约束、验收五个槽位。验收优先写成命令、测试、退出码、接口响应或可观察界面行为。 ### 5. 探索或计划 L0、L1 可以直接读相关文件并实施；L2、L3 先只读分析和计划。确认计划时重点看：是否越界、是否改变兼容性、是否有回滚点、测试是否足够。 ### 6. 小步实施 每个步骤只解决一个连贯问题。修改后立刻看 diff；不要积累十几个未经检查的编辑再统一验收。 ### 7. 自验证和人工抽检 让 Codex 跑最小相关测试、lint、类型检查或构建，并要求它 review 自己的 diff。你仍需人工抽检边界条件、权限变化、文件范围和测试是否真的覆盖目标。 ### 8. 收尾和记录 结束时输出：修改了什么、为什么改、运行了什么、结果如何、哪些未验证、如何回滚。对有教训的任务写一条复盘，不要把秘密和原始个人数据带入记录。 ## 速度、质量和可持续性 速度不是单次响应最快，而是从目标到可信交付所需的总时间最短。减少返工通常比盲目降低推理强度更有效。 可以遵循以下顺序： 1. 先减少歧义，避免错误方向。 2. 再减少无关上下文，避免重复读取。 3. 再按任务难度选择模型和推理强度。 4. 对边界清楚的独立任务并行，但用 worktree 隔离文件。 5. 最后才考虑版本支持的快速模式，并确认额外用量成本。 简单任务使用较低推理强度通常足够；复杂调试、架构取舍和高风险任务应保留更多推理预算。不要把具体模型名写进跨项目的个人规则，除非你愿意随版本更新它。 并行时适合分出去的工作包括：只读探索、独立测试补充、日志归类和文档查找。两个会话不要同时写同一批文件；子代理的结论也要由主任务根据实际文件和测试复核。 ## 隐私注意：个性化越强，暴露面可能越大 个性化系统会积累更多上下文，因此隐私边界必须主动管理。 绝对不要写入个人规则、Memories、任务状态或公开日志的内容包括： * API key、密码、访问令牌、SSH 私钥和 Cookie。 * `.env`、完整数据库连接串和可直接访问的内部 URL。 * 客户姓名、联系方式、订单号、工单原文和未公开业务数据。 * 会议、私信、密码管理器和内部仪表盘的屏幕内容。 * 未公开漏洞、生产凭据、权限批准和安全事件细节。 使用占位符保留结构： ```text theme={null} Authorization: Bearer 用户邮箱： 订单号： 内部地址：https:/// 数据库连接：postgresql://:@/ ``` 如果使用屏幕相关记忆能力，先了解平台限制、权限要求、配额消耗、提示注入风险和本地明文存储。开会、处理客户资料或打开密码管理器前暂停；未经他人同意，不要记录包含他人沟通内容的屏幕。 定期检查记忆目录和配置，特别是在分享、备份或迁移 Codex 主目录之前。自动脱敏不是许可，发现秘密已经暴露时，要按所属服务流程撤销或轮换，不能只删除一行文本。 ## 常见失效方式 **偏好文件越来越长。** 只保留会反复改变结果的规则；把一次性任务移回提示或状态记录。 **个人规则和项目规则冲突。** 以项目硬规则和当前明确约束为准，并删除过时的个人偏好。 **默认输出过于简短。** 要求简洁时仍保留命令、退出码、关键证据和未验证项。 **把 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` 及官方文档为准。