Claude Code 反复改错，可能是旧记忆作祟

Claude Code 反复把页面改回旧样子，未必是模型突然变笨了。作者排查后发现，AI 自己保存的记忆、规则文件和决策记录互相冲突，执行修改的代理拿着旧规格，仍然认为自己在认真完成任务。

作者随后做了 155 次小规模实验：凡是读到新修正的运行，都没有退回旧版。对程序员更有用的结论是：反复强调需求之前，先检查当前规格存在哪里，以及真正改代码的那个代理能否读到它。

为什么清了记忆，旧需求还会回来

作者遇到的问题分了三轮。

2026 年 9 月 12 日，他们停用了产品里用于外部 AI 评审的中转路径，但主代理仍然继续使用。原因是 auto memory 里留着一条 9 月 4 日的笔记，要求默认走这条路径。停用文档描述了产品功能的变化，却没有覆盖代理发起评审的工作流程。

第二轮是临时措施变成了永久政策。一个文档矛盾检查过于严格，作者先把它移除，准备再判断要不要重新设计。主代理却把这个动作记成了「不要增加发现矛盾的机制」，同时写进决策日志和 auto memory。一次暂时撤掉检查的操作，就这样成了后续任务的长期约束。

9 月 29 日，作者把记忆从 26 个文件、590 行，清理到 19 个文件、269 行。但到了 10 月，分析页面仍然反复回退：作者要求表格与图按相同单位展示，修正已经进入决策日志，.claude/rules/ 里却保留着旧版页面规格。负责改页面的子代理读到旧规则，又把页面改了回去。

更麻烦的是，防止这种情况的规则早就存在。CLAUDE.md 要求用户作出决定时，同步修改相关规则和规格文件。主代理却把它理解成「把规格写进规则」，继续制造副本。

一份修正写对了，不代表执行时读到的那份规格也已经更新。

到 10 月 8 日凌晨，作者关闭了 auto memory。此时问题已经超出记忆本身：决策日志、规则和记忆都由 AI 写过，而且互相冲突，关闭其中一个入口也无法自动恢复一致。

155 次实验，实际证明了什么

作者用一个由 4 个文件组成的小页面，调用 Claude Code CLI 测试。原文标注使用默认模型 Opus 5.5、单一配置，每种条件运行 5 到 10 次，总成本约 $19。

当前页面按图中的节点逐行展示，支持过滤、连接数排序和表图联动。旧规格则按连接数区间聚合成行，区间为 0-1、2-3、4 或更多，并包含合计行、CSV 导出和分页。

作者设置了三种请求：

1. 明确要求增加每行的最后更新时间列。
2. 模糊要求补齐当前规格缺失的内容。
3. 同时提出更新时间和补齐规格两项要求。

155 次运行里，85 次规则文件装着旧规格，另外 70 次使用当前规格作为对照。全部 18 次回退，都发生在没有读到修正的运行中。

没有决策日志、只有旧规则时，模糊请求在 15 次中有 13 次触发回退。模型补上聚合行、合计、CSV 和分页，有时还删掉现有的节点表格与排序。它的报告却认为自己补齐了规格中尚未实现的功能。

同样只有旧规则，明确要求增加更新时间列，5 次都只增加了这一列。请求越具体，模型需要自行决定的范围越小，旧规格介入的空间也越小。

另一组结果与任务委派有关。作者模拟主代理交办任务，在请求前指定规格位于 .claude/rules/ui-spec.md，并限制只能修改 index.html。当仓库有决策日志、但 CLAUDE.md 没有指向它时，10 次中有 5 次回退，这 5 次都没打开日志。

去掉这段委派说明，10 次全部主动找到日志；保留委派说明、但在 CLAUDE.md 增加日志入口，10 次也全部读到了日志。一个过于确定的规格入口，可能让执行者提前停止搜索。

长日志也没有必然阻断修正。作者把真实约 500,000 字节的日志，模拟成约 260,000 字节、5,948 行，把修正埋在第 3,132 行附近。20 次运行首次读取都在约第 1,271 行截断，但其中 19 次继续搜索并定位相关章节，另一次通过搜索结果附近的内容读到了修正。

模拟旧记忆的 20 次运行都读到了记忆和日志，其中 19 次主动把旧记忆改成当前规格。70 次对照运行没有真实回退，机器评分曾误判 1 次；不过，无日志且使用模糊请求的 10 次里，仍有 3 次增加了未要求的小改进。

这些结果支持一个有限结论：在这套实验里，修正能否进入执行上下文，比旧文本是否存在更能解释回退。

作者为什么开始用检查机制约束副本

作者后来把注意力从「再强调一次」转向了信息副本。

他们整理了 246 条过时或错误陈述，其中代码、数值、字符串和列表副本有 88 条，状态、版本和数量副本有 42 条，合计超过一半。其余包括写下时就错误的 43 条、预防性陈述 35 条、指向已不存在对象的 34 条，以及原因不明的 4 条。这份分类由 AI 完成，没有第三方复核。

副本也出现在代码中。发布文件清单漏掉 CSS，导致 2 个版本损坏。不同页面各算一遍子代理运行时长，作者拿 176 份会话日志中的 842 个子代理逐一比较，最初只有 4 个跨页面结果一致。修复后的复核又发现新差异，后续不一致数量从 27 降到 2，再降到 0；评审者此前读了 3 次也没发现问题。

这类错误靠实际结果对比暴露，比寻找某句旧文字更直接。

作者最终加入四项机制：每次委派任务时，通过 hook 自动附上当前权威规格；机器检查发现页面规格副本就失败；限制记忆写入，拦截子代理写入和缺少核验依据的事实；默认不写复述代码的注释。

他们还一次删除了 4,227 条源码注释，删除前后构建产物一致，TypeScript 类型检查通过，只把涉及用户数据和外部约束的 11 条说明转移到代码结构或规格文件。不过，作者没有统计删除后矛盾是否减少，也没有量化四项机制减少了多少返工。

我的判断

我认同作者把问题定位到规格管理和信息传递。对前端页面来说，表格按节点还是按连接数区间展示，是产品行为的根本差异。旧定义藏在自动加载的规则里，模型越认真补齐它，改动就可能越偏离当前需求。

但实验不能直接解释原来的事故。真实事故中，主代理曾明确要求读取决策日志，CLAUDE.md 也有入口；模拟实验则没有复现这种条件下的回退。每组只有 5 到 10 次，且只有一个模型、一个配置。auto memory 用直接插入的文本代替，子代理委派也只是单次运行中的模拟说明。

因此，155 次里读到修正后回退为 0，不能推广成 Claude 永远会正确处理新旧指令冲突。原文没有给出模型升级、关闭记忆和加入 hook 之间的严格对照，最终压力减少也是作者的主观反馈。

关闭记忆适合作为排查手段，但规则里若也有旧副本，问题仍在。默认删除注释也需要取舍：复述实现的注释容易过时，解释业务原因和外部约束的注释仍然有价值。作者保留并迁移的那 11 条说明，恰好体现了这种区别。

另外，原文没说明如何可靠识别语义相近的规格副本。检查若过于严格，也可能重演作者早期遇到的有效写入被拦截。这部分仍是经验方案，不能当成已经验证的通用配置。

能拿来做什么

• 页面反复回退时，把 CLAUDE.md、.claude/rules/、auto memory 和决策日志一起核对，围绕出错的具体行为寻找冲突，随后同步修正规格来源和入口。
• 给 AI 布置前端修改时，明确当前行为、目标改动和修改范围，例如保留按节点逐行展示，只增加更新时间列；减少「补齐规格」这类需要它自行选择依据的请求。
• 使用主代理和子代理协作时，把当前规格及决策日志路径一并传给执行者；若通过 hook 自动附加，先确认附加内容能随规格更新。
• 对多个页面重复计算的运行时长等指标，拿同一批记录比较输出；对发布文件清单与实际产物做核对，让验证覆盖真正交付的结果。