我曾经把 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 本身会规划，也会搜索代码，但默认能力不能替代我的验收标准。全局规则的作用不是教模型“怎么思考”，而是声明我接受什么样的工作过程和完成证据。
当前使用的精简版本
下面是我现在使用的核心结构。机器路径和工具偏好带有个人环境特征，复制时应替换成自己的配置。
# 个人工作偏好
## Communication
- 普通问答直接回答，只保留必要事实、问题、决策、结果和下一步。
- 长会话接近上下文边界时，提醒新开任务并提供可复制的续接摘要。
## Scope And Environment
- 未指定仓库时，使用约定的默认工作目录，并先读取入口文档和当前生效的 `AGENTS.md`。
- 涉及仓库、构建、测试或提交时，先确认路径、Git 状态和最小必要上下文；优先使用 `rg` 和点名文件。
- 修改只限当前任务，保护无关未提交内容，沿用现有结构、工具链和接口契约，不做顺手重构。
- 浏览器任务使用内置 Browser；Node 工具链使用 Volta。
## Execution Discipline
### Planning
- 复杂任务使用内置 Plan，明确范围、禁止修改范围、依赖、执行顺序、验收条件、验证命令和完成证据。
- 简单任务直接执行，不额外生成正式计划。
### Diagnosis
- 记录症状和预期行为，优先建立最小复现并收集代码、日志和运行证据。
- 提出可证伪的根因假设，一次尽量只改变一个变量，区分症状、相关现象和根因。
- 证据不足时标记未确认；根因确认后再实施永久修复，并复跑原始失败路径。
## Collaboration And Review
- 高风险或跨模块任务按“分析 → 执行 → Review/验证 → 是否可提交”推进；普通任务不创建 Subagent。
- 只在工作面独立、没有顺序依赖且文件不重叠，或任务完全只读时并行；主 Agent 负责最终判断和交付。
- Review 先列问题、影响和文件位置；没有问题时说明测试缺口和剩余风险。
## Task Artifacts
- 仓库没有自己的规范时，使用根目录下的 `.codex/` 保存本地任务产物。
- 跨任务续接放在 `.codex/handoffs/`，Review 和外部回复放在 `.codex/reviews/`，Design QA、截图、日志和评测放在 `.codex/artifacts/`，可丢弃中间文件放在 `.codex/tmp/`。
- 任务 ID 使用 `<YYYY-MM-DD>-<scope>-<purpose>`；这些目录默认不提交。只有经过批准、脱敏且具有长期价值的内容才提升到 `docs/`。
## Git And External Actions
- 默认不修改 `main`、不创建 PR；开发使用符合仓库约定的任务分支。提交前只暂存相关文件并检查 `git diff --cached`。
- 发布、安全扫描、外部写入和生产操作只在用户明确要求时执行。
当前对话中的明确要求优先；更具体的项目或子目录 `AGENTS.md` 适用于其对应范围。本机配置和公开文章如何同步
完整个人习惯、真实路径、Provider、权限和受信项目仍保留在本机。~/.codex/AGENTS.md 和结构化配置负责实际生效；本机文档负责解释完整设计。Blog 只发布可公开、可复制的当前版本，不是运行配置的权威源。
我不会为每次本机调整都同步 Blog。只有公开原则、示例或解释发生实质变化时，才从本机来源选择允许公开的内容，删除或泛化机器信息，然后直接覆盖这篇中英文文章。公开前检查差异、敏感信息和站点构建结果，再决定是否提交和推送。
Blog 不保存额外的 workflow 历史版本目录。文章始终展示当前版本，历史由 Git 提交记录承担。同步方向保持单向：本机规则可以生成公开文章，公开文章不能反向覆盖本机配置。
现阶段也没有必要单独建立公开 workflow 仓库。只有公开配置开始需要独立下载、安装、版本兼容、Issue 或 Release 时，才值得把它当成独立产品维护。
继续增加偏好时如何处理
我不会因为出现一个新要求就新增章节。先判断它属于哪一类：
- 跨仓库长期稳定的行为偏好，合并进全局
AGENTS.md； - 只对一个项目成立的事实或命令，放进仓库
AGENTS.md； - 需要独立资料、脚本、输出合同或专项验证的能力，才做成 Skill；
- 已批准、脱敏且需要长期维护的说明进入
docs/，任务过程材料留在.codex/； - 只用一次的任务要求，留在当前对话里。
如果同一条规则开始出现例外、解释和多层引用，它通常已经不适合继续塞在全局配置里。全局文件应该短到能够快速读取，但不能为了短而删除授权、Git、未提交内容保护和证据标准。
对我来说，好的个人配置不是完整描述所有工作方式，而是把最容易反复遗漏、又会真实影响结果的边界固定下来。