Claude 说「已按指示完成」却没听我的：旧规格藏在它自己存的记忆和规则里

作者发现 Claude Code 反复恢复已废弃的功能，排查后发现根源不是一次性的：旧笔记留在 auto memory，旧规格副本又被写进每次加载的 .claude/rules/，而决策日志、规则和记忆全是 AI 写的、彼此矛盾，已经没有「正确的一边」可以回退。作者随后搭了一个小屏幕场景，用当前 Claude 跑了 155 次复现实验，验证了旧指令与新纠正并存时的真实行为。

三次踩坑：问题不止在记忆里

• 9 月：外部评审的中转路径已从产品下线，但主 agent 一直沿用，原因是 9 月 4 日 auto memory 里一条「外部评审默认走这条路径」的旧笔记；下线记录只覆盖了产品功能，没覆盖主 agent 用的路径。
• 9 月底：一个误拦合法写入的文档矛盾检查，作者本意是「重新设计、不需要就删」，Claude 却把它记成永久政策「不要加矛盾检测机制」，同时写进决策日志和 auto memory。
• 10 月：分析屏幕每次修好又退回旧形态。决策日志里已有纠正记录，但每次加载的 rule 文件里还留着旧屏幕规格，负责改屏幕的 subagent 每次都把 rule 当成正确规格。

防复制的规则反而制造了更多副本

• CLAUDE.md 里有一条规则：用户做决定时，要在同一次修改中重写相关的规则和规格文件，本意是防止决定只留在日志里、每次加载的 rule 却还是旧的。
• 主 agent 把这条规则误读成「把规格写进 rule」，于是指示 subagent 把旧规格复制了进去——防副本的规则制造了副本。
• 更糟的是，决策日志、规则、auto memory 全是 AI 自己写的，三者互相矛盾。清掉记忆，同样的东西又从 rule 里冒出来，已经没有「正确的一边」可以回去。
• 10 月 8 日凌晨，作者干脆关掉了 auto memory。

155 次复现实验：当前 Claude 到底听谁的

• 实验设置：4 个文件的小屏幕，Claude Code CLI 单一默认模型（Opus 5.5），每个条件跑 5 到 10 次；auto memory 和 subagent 都用模拟方式（笔记直接写进指令、请求包一层委派式指令），diff 用机器比对加人工复核，总成本约 19 美元。
• 准备了新旧两版规格的 rule、含纠正记录的决策日志（14 行短版和约 50 万字符的真实长度长版）。
• 结果：只要新纠正出现在可见范围内，155 次里读到纠正后仍退回旧形态的次数为 0；20 次里有 19 次 Claude 自己把存着旧规格的记忆改写成当前规格。
• 会退回旧形态的，只有纠正内容「够不着」的情况。

和已有结论的区别：有没有正确的一边

• kamo78 的文章也讲过 auto memory 导致性能下降：三条 Claude 自存的笔记与工作流规则和已删除的政策冲突，导致评审不收敛、设计过度，关掉 memory 后重跑约 4 次未再复发。
• 两案例根源相同，区别在于 kamo78 的场景里规则还是正确的一边，关掉 memory 就能回退；本文作者的场景里所有记录源都被污染，只能整体重构。

事后改掉的结构

• 作者复盘后重构了指令结构，避免「决定只进日志、每次加载的文件还是旧版」的错位。
• 核心教训：排查时不能只盯着 memory，还要检查 .claude/rules/ 等每次都会加载的指令文件里有没有旧副本；当你找「记忆里的旧笔记」时，散落在别处的副本根本不会进入视野。