Codex 总在文档里留下「不做」的幽灵规则：原因与处理办法

让 AI 帮忙整理项目文档或 Skill 流程时，很容易遇到一种别扭的情况：你明确要求删掉某个当前用不上的流程，它确实删了主体，却又在文档的某个角落补上一句「X 已明确排除，未来需要时再单独定义」。你想让这个行为彻底消失，它却把「不做」这件事刻在了文档上。

这类残留可以叫「幽灵规则」——它描述的是一段已经被排除的需求，而不是系统当前的样子。它通常不影响主流程跑通，但会让人读文档时一愣：这到底是仍然生效的约束，还是历史上的一个影子？下一轮对话里，AI 还可能把这句话当成既有规则继续引用，越滚越偏。

幽灵规则的典型形态

除了文档正文，它还会出现在几个地方：

• 流程与 Skill 设计：从流程里删掉某个工具调用后，安全守则里多出一条「禁止调用该工具」。
• 规格文档改写：删除某章节后补一句「该能力暂不支持」。
• 代码注释：注释里写「本次修改去掉了 X，原因是 Y」，把一次性的对话内容永久留在代码里。
• 需求说明：把「等年底再设计」这种时间安排当成正式条款写进文档。

共同点是：AI 把「否定的决策」和「当前的事实」混在了一起。文档本应描述系统现在是什么样，而不是记录它曾经被排除过什么。

为什么会出现这种行为

最小修改偏好

多数编程助手被训练成「能不删就不删」，以避免误删用户内容。当你的指令里提到「以后还会用到」「等某个时间再做」时，它更倾向于保留痕迹，而不是整体重写段落。

把解释当成规则

人和人说话时，解释原因是铺垫；但对模型来说，对话里的每一句都可能被当成指令。「用得少，先删掉，等年底我再单独设计」——前半句是原因，后半句是计划，模型很容易把后半句沉淀成文档条款。这是最常见也最容易自我修正的一条。

指令的主语和范围模糊

「流程 3 不需要调用 X 工具」这句话的主语其实有两种理解：指向工具有关的内容，或者指向流程 3。前者容易演变成一条全局禁令，后者才是你想要的局部删除。模型对主语很敏感，说法不同，落笔结果可能完全不同。

对否定和禁止过度敏感

安全、权限、数据损坏这类边界，模型会被刻意调教得更保守。于是任何带有「不要」「禁止」意味的表述，都可能被升级成一条守则，哪怕它只是一次性的操作要求。

多轮迭代是打补丁而非重写

连续几轮修改后，文档往往变成层层叠加的补丁，每轮都往里加一句说明，最后既冗长又自相矛盾。模型缺少「先整体理解再重写」的默认习惯。

模型与配置差异

不同模型、不同系统提示下的表现差异明显：有的更愿意对话式地理解意图，有的则更像严格执行指令的工具。同一句话在不同模型上、甚至同一模型的不同轮次上，结果都可能不一致，这个行为本身就不稳定复现。

解决方案

一、把「不要做」改写成「删干净并整理」

最有效的一步是改自己的说法。对比一下：

两个要点：明确删除范围，以及明确说明哪些话不要落到文档里。如果确实想解释原因，加一句「以下为背景说明，不要写入文档」作为分隔，比指望模型自己分辨要可靠得多。

二、在全局规则里加一条输出契约

如果不想每次都长篇解释，可以在 AGENTS.md 之类的全局指令里放一条约束，大意如下：

文档只描述当前有效的系统，不保存已被排除需求的影子。
当用户取消、纠正或排除某个行为时，默认让该行为从文档中消失，
不要额外写入「明确不做」「暂不支持」「未来需要时再处理」等反向说明。

只有以下情况才保留显式负面规则：
- 该行为很可能被默认习惯反复触发；
- 涉及安全、权限、数据损坏等高风险边界；
- 用户明确要求记录取舍过程；
- 文档本身是决策记录或历史变更日志。

这四条例外很关键：一刀切地禁止所有负面描述，反而会在安全边界上出问题。规则写清楚适用条件，比单纯写「不要写负面规则」更稳。

三、按任务类型拆分指令文件

如果同一个全局文件里混着代码、笔记、文档的规则，条目越多越容易被稀释。用 CLI 时可以为不同任务指定不同的配置目录，各自挂一份全局指令，把「代码注释写什么」「文档变更记录放哪里」分开定义，心智负担会小很多。

四、定期做一次文档瘦身

每隔一段时间，让 AI 只读当前文档和实际现状，找出过时的、描述「不做什么」的、以及和实现不一致的内容，输出修改建议或 diff，而不是直接覆盖。这个动作本身就能清掉不少历史残留。

五、改完做一次机械复查

肉眼扫一遍成本很低，尤其对短文档：

• 搜索「不」「禁止」「暂不」「未来」「后续」「已排除」「不再使用」等关键词；
• 逐条判断每处负面表述是否属于前面那四种例外；
• 检查注释里是否在讲「这次改动的原因」而不是「这段代码为什么这样写」；
• 检查是否残留只属于上一轮对话的时间安排、人名、临时决定。

文档较多时，可以用一次性的 grep 或一个专门的检查 Skill 扫否定句和旁白句，把候选行列出来人工确认。

六、长任务场景下的执行环境

如果经常跑 CLI 版助手做批量文档整理、定时复查这类持续任务，本地机器休眠或断网会中断执行。这种情况下，把执行环境放到一台长期在线的远程 Mac 上（例如整台机器放在机房的按月租用方案）是可选思路之一，能让长时间运行的任务更连续；它解决的是运行环境稳定性，不改变模型本身的行为习惯。

几种做法的取舍

• 每次写精确指令：最可靠，但需要改掉把 AI 当聊天对象解释半天的习惯，短期成本最高。
• 加全局规则：成本低、一次生效多次，但效果不稳定，规则越长越容易被忽略，也可能被后续修改冲淡。
• 拆分 profile：任务隔离清晰，适合多类型工作混用的人，代价是要维护几份指令文件。
• 事后人工复查：最保险，对外文档、共享文档建议保留这一步，但纯靠人看不可持续，适合作为最后一道关。

实际使用中通常是组合：精确指令为主，全局规则兜底，关键文档再人工过一遍。

需要注意的地方

• 不要用「永远不要」「绝对禁止」这类强语气去纠正，它们更容易被当成硬规则沉淀下来，反而制造新的幽灵规则。
• 这个行为本身不稳定复现，同一句话两次结果可能不同，别指望加一条规则就彻底解决，观察一段时间再判断是否有效。
• 涉及安全、权限、数据删除的边界，显式的负面规则是合理的，不要为了文档干净而删掉它们。
• 模型和工具的行为会随版本变化，具体配置项与写法请以官方最新文档为准。
• 对外交付或多人共享的文档，最终仍建议由人确认一遍再定稿。

小结

幽灵规则的本质，是模型把「一次性的解释与决策」当成了「需要长期沉淀的事实」。缓解方法有三层：说话时把删除范围和「不要写入文档」讲清楚；在全局规则里定义文档只描述当前有效系统，并给出保留负面规则的例外；最后用定期瘦身和关键词复查兜底。改变沟通习惯的收益最大，规则约束只是补充。