从 Claude Code 历史对话提炼长期规则

dev.to · AI#Claude Code#上下文管理#开发工具

Editor brief · 编辑速览

nomore 扫描本地 Claude Code 对话，统计反复出现的指令，并标记 CLAUDE.md 中仍被忽略的规则。使用 --apply 可逐条接受、拒绝或修改建议，仅将用户批准的内容写入。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

反复告诉 Claude Code「别再用这个词」，下次它却照说，问题可能出在纠正只留在聊天里。作者认为，对话压缩（compaction）会把这些要求概括掉，新会话也不会自动继承，因此他们做了一个 CLI：nomore，从本地历史记录里找出反复出现的指令，帮助用户写进 CLAUDE.md。

它值得关注的地方，是把「发现重复要求、人工筛选、保存规则」串成了流程。不过，重复出现的话未必就是规则，写进文件也不代表模型一定遵守。

作者列出的抱怨很具体：别再说「load-bearing」，别用「Two things…」收尾，要说「verifiable」而不是「falsifiable」。

这些并非作者随手举例。按原文统计，自 7 月以来，220 个 Claude Code issue 提到「load-bearing」，其中 #53454 有 185 个反应；另外两个措辞问题分别对应 #90799 和 #97305。这些数字说明用户有共鸣，但不能据此算出问题的发生率。

作者把原因归结为指令存放的位置：聊天会被压缩，新会话会遗忘，而 CLAUDE.md 能持续保留项目要求。原文还提到，曾有人在空闲期间触发压缩后，不得不从历史记录手动重建指令，对应 #98747，后来已修复。

临时纠正要变成长期约束，需要进入持久保存的规则文件。

这里要分清两个目标：让要求保存下来，以及让 Claude 每次都照做。nomore 主要处理前一个，也尝试发现后一个出了哪些问题。

运行 npx @globalmpc/nomore，工具会扫描本地 Claude Code 对话记录，展示反复出现的指令、出现次数和最近一次出现的时间。它还会标记那些已经写在 CLAUDE.md 里、Claude 却仍在违反的规则。

需要写入时，使用 npx @globalmpc/nomore --apply。工具逐条展示建议，用户选择接受、拒绝或编辑，只有批准的内容才会写入。

这个人工环节很关键。作者在自己的会话里发现，不少重复内容只是「commit」「continue」这样的普通任务。频率高，只能说明经常说，不能直接证明它适合成为长期指令。

工具全部在本地运行，不上传数据，默认不使用 LLM。原文没有交代具体的重复识别算法，也没有给出候选规则的准确率，因此目前能确认的是它的工作流程，无法判断它能替用户省掉多少筛选时间。

此外，项目提供了一个包含 20 条 CLAUDE.md 规则的入门包，素材来自近 10,000 个公开 Claude Code issue，每条都关联来源。工具免费，采用 MIT 许可证。

nomore 自身也是一次 Claude Code 开发实践：35 次提交中有 33 次由 Claude Code 编写，项目使用 TypeScript，包含 125 个测试。作者团队提供了项目 CLAUDE.md，要求宣布完成前先跑测试，每次修复 bug 都补回归测试，并审核每一步。

但它仍犯过明显错误：最初的分组阈值把 1,489 个互不相关的 issue 合进了同一组。团队检查实际输出后才发现。

这个案例说明，规则和测试能约束开发过程，却不能替代对结果的检查。尤其是分组、筛选这类功能，程序顺利跑完，并不能证明输出有用。原文没有说明当时哪些测试已经通过，不能把这次错误直接解释成「125 个测试全部漏检」。

我认可作者把反复纠正当作规则候选的思路。相比完全靠记忆维护 CLAUDE.md，历史记录可以补回那些当时说过、后来忘记整理的要求；逐条确认，也能拦住明显不适合持久化的任务指令。

但作者没有提供对照数据：使用 nomore 前后，Claude 违反规则的次数下降多少，整理指令节省多少时间，都没说清。这仍是团队经验和工具实践，不能直接当成效果已验证的方法。

对于规则不多的项目，手动维护 CLAUDE.md 依然直接。nomore 的价值更可能出现在历史会话较多、纠正已经散落各处时。至于入门包，公开 issue 能提供线索，却不能证明其中每条都适合你的项目。

规则能被保存，不等于规则能被可靠执行。

在前端或 Node 项目中使用 Claude Code 时，可以先运行 npx @globalmpc/nomore 查看候选项，区分长期要求与「提交代码」「继续处理」这类当次任务。
使用 --apply 时逐条审核，把含糊的抱怨编辑成明确要求，再决定是否写入 CLAUDE.md。
如果工具标记某条已有规则仍被违反，先检查这条规则是否清楚，再看实际输出，避免只靠重复追加相同指令处理问题。
让 Claude Code 开发工具时，可以借鉴作者团队的做法：完成前跑测试，修 bug 补回归测试，并抽查真实输入下的输出结果。