使用 AI 编程工具一段时间后，很容易积累大量“以后都这样做”的指令。真正困难的不是把它们写下来，而是决定它们应该出现在哪里。

同一句要求既可以留在当前对话，也可以写成 Prompt、放进 AGENTS.md，甚至做成 Skill。四种形式都能影响 AI，但维护成本和适用范围完全不同。

先判断它影响多大范围

我现在按下面的顺序判断：

只影响当前任务             -> 当前对话
需要以后复制和修改输入      -> Prompt
在一类工作中持续生效        -> 个人或仓库 AGENTS.md
拥有独立流程、资料和验证方式 -> Skill

一次性的发布日期、文件清单或具体修复要求，不需要离开当前对话。它们被永久保存后，通常很快就会过期。

Prompt 适合表达一个可以重新填写输入的任务。例如定时主题摘要会改变关注主题、时间窗口和输出语言，但来源验证与去重规则保持不变。它需要被复制和修改，却不需要安装成一个持续触发的能力。

AGENTS.md 保存的是默认行为。保护未提交内容、复杂任务先定义验收条件、根因证据不足时不宣称已经确认，这些规则不应该每次手动粘贴。全局文件负责跨仓库偏好，仓库文件负责当前项目的目录、命令和交付边界。

Skill 则需要更强的独立性。它应该有清楚的触发条件、非触发条件、授权范围、工作流程、输出合同，以及无法仅靠几行配置表达的参考资料或验证方式。

五个判断问题

面对一个新规则，我会问：

  1. 它需要自动生效，还是需要用户主动填写输入？ 自动生效更像配置；需要反复修改输入更像 Prompt。

  2. 它是否只对一个仓库成立？ 构建命令、目录和业务事实属于仓库 AGENTS.md，不应进入全局配置。

  3. 它有没有独立的授权边界？ Review、实现和 Git Delivery 的权限不同，不能为了减少数量强行合并。

  4. 它是否需要自己的资料、脚本或专项验证？ 如果只有几条行为要求，通常不值得建立 Skill 包。

  5. 现有能力是否已经覆盖？ Codex 已经会规划和搜索代码。新增资产应该补充明确的验收标准，而不是重新描述模型默认会做的事情。

减少重复比选择名称更重要

分类错误最直接的后果是漂移。比如同一套 Git 规则同时存在于全局配置、仓库文档、Review Prompt 和 Delivery Skill，后续任何一次修改都可能只更新其中一处。

我会为每条稳定规则指定一个权威来源：

个人执行偏好 -> ~/.codex/AGENTS.md
项目事实     -> 当前仓库 AGENTS.md
可复制任务   -> blog / Prompts
专业能力     -> idaibin/skills
经验和判断   -> blog / Notes

其他位置可以链接或简短说明，但不复制完整正文。

什么时候应该删除

即使一个 Prompt 或 Skill 曾经有用，也可能不再需要。出现以下情况时，我会优先合并或删除：

保留 Git 历史已经足够记录过去。当前目录应该表达今天仍然推荐的使用方式，而不是陈列所有曾经存在过的想法。