我曾经把 Planning 和 Diagnosis 分别做成 Skill。继续使用后，我发现它们更像每次任务都应遵守的工作纪律，而不是需要单独安装、单独触发的专业能力。
Planning 约束复杂任务如何拆分和验收；Diagnosis 约束遇到故障时如何收集证据、验证假设和确认根因。它们都不依赖特定技术栈，也没有需要携带的脚本或参考资料。与其增加两个 Skill 让 Agent 反复判断是否触发，不如把必要规则压缩进全局 AGENTS.md。
我现在把工作配置分成四层：
全局 AGENTS.md = 稳定的个人工作偏好和安全边界
仓库 AGENTS.md = 当前项目的结构、命令和交付规则
Skill = 有独立流程、资料或验证方式的专业能力
docs/ 与 .codex/ = 长期文档与本地任务产物这样做的目标不是让指令越来越多，而是让每条规则只出现一次，并放在真正拥有它的位置。
哪些规则值得全局保留
全局配置只保存跨仓库稳定成立的内容：
- 普通回答保持简洁，长任务只在状态发生变化时汇报；
- 修改范围只限当前任务，保护无关未提交内容；
- 复杂任务先拆分范围、依赖、步骤和验收条件；
- 故障处理必须区分症状、相关现象和根因；
- 只有工作面真正独立时才并行；
- 默认不直接修改
main，不自动创建 PR； - 发布、生产操作和外部写入需要明确授权。
仓库目录、构建命令、业务结构和专项验证不适合放在全局文件里。它们变化更快，也只有进入对应仓库后才成立，应该由仓库自己的 AGENTS.md 管理。
Planning 和 Diagnosis 不需要变成大段流程
Planning 最重要的不是输出一篇计划文档，而是让复杂任务具备可执行边界。每个任务项至少需要回答：改什么、不改什么、依赖什么、如何验证、什么证据代表完成。简单任务则直接执行，不为了形式生成计划。
Diagnosis 也不是固定运行一套命令。它约束的是判断标准：先记录实际症状和预期行为，再建立尽可能小的复现；根据代码、日志和运行结果提出可证伪的假设；一次尽量只改变一个变量；证据不足时明确保留不确定性。只有根因被证据支持后，才进入永久修复和原始失败路径复测。
Codex 本身会规划，也会搜索代码，但默认能力不能替代我的验收标准。全局规则的作用不是教模型“怎么思考”，而是声明我接受什么样的工作过程和完成证据。
模型路由属于结构化配置
AGENTS.md 负责行为边界，不应该同时承担模型选择。模型、推理强度、Plan 模式和子代理默认值都属于 ~/.codex/config.toml；具体角色的模型与权限放在各自的 Agent 配置文件中。这样调整模型时，不会让运行配置和自然语言规则互相冲突。
我当前采用的路由是：
| 用途 | 模型与推理强度 | 选择理由 |
|---|---|---|
| 主 Agent | Sol Medium | 负责需求判断、协调、验收和最终交付 |
| 内置 Plan 模式 | Sol High | 用于会改变实施方向的复杂规划 |
| 默认子代理与 Worker | Terra Medium | 承担边界明确的日常实施 |
| Explorer | Terra Medium | 负责较广的调用链和执行路径追踪，而不只是机械搜索 |
| Reviewer | Sol High | 独立检查正确性、回归和验证缺口 |
| Planner | Sol Medium | 处理会改变方向的复杂、架构或跨模块规划 |
| Batch Worker | Luna High | 处理明确、重复、可独立验证的批量工作，并先通过同会话 canary |
| 条件性 Luna Explorer / Worker | Luna High | 仅在对应角色通过同会话 canary 后处理专项任务 |
这套分工不是把模型简单排成高、中、低三个等级。模型能力与 reasoning effort 是两个维度，也没有可靠的跨模型等价式。我的实际配置让 Sol 承担主 Agent、规划和独立 Review，让 Terra 承担默认子代理、Worker 和 Explorer，让 Luna 只承担经过同会话 canary 的高强度批处理或条件性专项工作。具体配置仍应由代表性任务验证，而不是假设不同模型或推理强度可以互相等价。
运行默认值也保持保守：普通工具调用需要按请求审批，默认沙箱允许当前工作区内写入；Explorer、Planner 和 Reviewer 使用只读沙箱，Worker 和条件性批处理角色才允许写入。并行线程上限为 3，角色配置中的沙箱只是默认值，实际权限仍受当前会话边界约束。
当前使用的精简版本
下面是我现在使用的核心结构。机器路径和工具偏好带有个人环境特征，复制时应替换成自己的配置。
# 个人工作规范
## Scope And Precedence
- 当前对话中的明确要求优先；更近的 `AGENTS.md` / `AGENTS.override.md` 覆盖全局文件。
- 全局文件只保存跨仓库稳定偏好和安全边界。项目命令、架构、验证与交付约定放项目文档；模型、推理和沙箱等结构化设置放 `~/.codex/config.toml`。
## Communication
- 普通问答直接、简洁，只保留必要事实、判断、结果、风险和下一步；长任务仅在状态实质变化时更新。
- 分析、决策、研究和 Review 不默认认同用户前提。检查会改变结论的问题，区分已验证事实、基于证据的推断和未验证项；不为反对而反对。
- Review 先列问题、影响和位置；无问题时说明验证缺口与剩余风险。
## Workspace And Changes
- 未指定目录时，使用约定的默认工作目录，并读取入口文档和生效的 `AGENTS.md`。
- 涉及仓库工作时，先确认真实 cwd、Git 根、分支、status、生效指令和最小必要上下文；优先使用 `rg` 和点名文件。
- 修改只限当前任务，保护无关未提交内容，沿用现有结构、工具链和契约，不做顺手重构；需要授权时先完成不受阻塞的工作。
## Planning, Execution And Verification
- 简单线性任务直接完成；大型或模糊任务先解决会改变方向的决策，再以可端到端验证的最小切片推进。
- 只有独立可验收且收益明确时才委派。默认使用一个合适角色；仅在任务独立、无顺序依赖且文件不重叠时并行。
- 故障处理先记录实际与预期并建立最小失败复现；无法建立时说明证据缺口，不做永久修复。确认根因后再修改并复跑原始路径。
- 构建、静态检查和源码扫描只证明其覆盖范围，不替代运行时、浏览器、真机或生产验证。
- 需要任务产物且仓库无约定时，分别放在 Git ignored 的 `.codex/handoffs/`、`.codex/reviews/`、`.codex/artifacts/` 和 `.codex/tmp/`。
## Git And External Actions
- 默认不直接修改 `main`，不创建 PR 或 push；使用仓库约定的任务分支。
- 提交前只暂存相关文件并检查 `git diff --cached`；保留无关改动，不执行未经明确授权的破坏性 Git 操作。
- 浏览器任务默认使用宿主内置浏览器。外部浏览器、发布、生产操作、消息、评论、授权及其他外部写入必须有明确要求。本机配置和公开文章如何同步
完整个人习惯、真实路径、Provider、权限和受信项目仍保留在本机。~/.codex/AGENTS.md 和结构化配置负责实际生效；本机文档负责解释完整设计。Blog 只发布可公开、可复制的当前版本，不是运行配置的权威源。
我不会为每次本机调整都同步 Blog。只有公开原则、示例或解释发生实质变化时，才从本机来源选择允许公开的内容，删除或泛化机器信息，然后直接覆盖这篇中英文文章。公开前检查差异、敏感信息和站点构建结果，再决定是否提交和推送。
Blog 不保存额外的 workflow 历史版本目录。文章始终展示当前版本，历史由 Git 提交记录承担。同步方向保持单向：本机规则可以生成公开文章，公开文章不能反向覆盖本机配置。
现阶段也没有必要单独建立公开 workflow 仓库。只有公开配置开始需要独立下载、安装、版本兼容、Issue 或 Release 时，才值得把它当成独立产品维护。
继续增加偏好时如何处理
我不会因为出现一个新要求就新增章节。先判断它属于哪一类：
- 跨仓库长期稳定的行为偏好，合并进全局
AGENTS.md； - 只对一个项目成立的事实或命令，放进仓库
AGENTS.md； - 需要独立资料、脚本、输出合同或专项验证的能力，才做成 Skill；
- 已批准、脱敏且需要长期维护的说明进入
docs/，任务过程材料留在.codex/； - 只用一次的任务要求，留在当前对话里。
如果同一条规则开始出现例外、解释和多层引用，它通常已经不适合继续塞在全局配置里。全局文件应该短到能够快速读取，但不能为了短而删除授权、Git、未提交内容保护和证据标准。
对我来说，好的个人配置不是完整描述所有工作方式，而是把最容易反复遗漏、又会真实影响结果的边界固定下来。