检查 Claude Code 记忆索引的加载盲区
limitcast 0.16 可检查 MEMORY.md 是否超过文中所述的会话启动加载上限：200 行或 25 KB，以先达到者为准。新版还提供记忆审计和拆分命令，辅助整理过长索引及关联主题文件。
AI 深度解读
Claude Code 留下的项目笔记，未必都会在下一次会话开始时读到。MEMORY.md 的自动加载有上限：前 200 行或前 25 KB，哪个先到就停。limitcast 0.16 围绕这个边界增加了检查和整理命令。
它的价值是把「笔记是否进入上下文」变成可检查的问题。不过，作者自己的检查结果也说明：没有 Markdown 链接的文件，不一定就是废弃笔记。
笔记写进去了，为什么开场仍然读不到
按原文转述的 Claude Code 文档，每次会话开始只加载 MEMORY.md 的前 200 行或前 25 KB，超出部分不会自动进入开场上下文。这里限制的是索引文件，不代表整个 memory 目录都会一次性加载。
Claude Code 会在 Claude 写入索引后检查大小，并要求压缩接近或超过上限的内容。但长期积累、手动编辑的索引，仍可能超过限制。原文还指出，文档没有描述对失效链接、无人引用文件和过大主题文件的同类检查。
索引没有超限，只能说明开场内容没有被截断，不能说明整个笔记目录都健康。
主题文件也有读取成本：任务只需要其中一条约定，却可能打开一份包含大量无关内容的长文。索引截断和主题文件过大，需要分别处理。
检查结果里，哪些是真故障
在项目目录运行 limitcast memory，它会读取对应的 memory 目录，不修改文件。下面是作者构造的问题目录，并非实际项目测量：
$ limitcast memory
Memory: ~/.claude/projects/-home-you-app/memory
Index: MEMORY.md 21 / 200 lines, 0.8 / 25 KB
Topic files: 16
Not linked from the index (2): old-notes.md, scratch.md
Broken links (1): MEMORY.md -> deploy-notes.md
Over 150 lines or 24 KB (1): api-conventions.md (312 lines, 8 KB)
重点看最后一行：api-conventions.md 虽然只有 8 KB，但已有 312 行，超过工具的主题文件提示阈值，即 150 行或 24 KB。这个阈值与 Claude Code 索引的 200 行、25 KB 加载上限不同。
limitcast doctor 会把结果压成一行，并且只在索引超限时判定失败。例如索引达到 214 行、6 KB，虽然字节数仍在范围内，行数已经越界。普通示例里显示的 1/25 KB 则是 doctor 的显示结果，对应前面更精细的 0.8 / 25 KB。
作者自己的目录有 300 个主题文件，索引仅 54 行、7.0 KB，没有截断，却查出 116 个没有 Markdown 链接指向的文件。他通过少数目录文件和文件名模式查找笔记，因此这些文件不能直接判为孤立文件。
日常后台检查不显示 memory 检查项，因为记忆属于具体项目，需要进入项目运行 limitcast doctor。
拆文件之前，先确认是否值得拆
插件新增两个命令，都会先检查，获得同意后再修改。
/limitcast:memory-audit 检查索引上限、失效链接、无人引用的文件、引用了已不存在的文件或命令的笔记，以及相互矛盾的记录。结果先列机械修复项，再列需要判断的事项及证据；未经询问不会删除笔记。
/limitcast:memory-split 把过大的文件拆成简短入口和主题文件。但连续操作流程会保持完整，因为拆开可能让一次读取变成两次。确认适合拆分后，它先展示目录方案，等待确认，再原样移动文本、保留入口文件名，并检查旧引用是否仍能找到对应内容。
安装和检查入口如下：
npm install -g limitcast
cd your-project
limitcast memory
limitcast doctor
要注意 cd your-project：检查结果取决于当前项目。Claude Code 内还需依次执行 /plugin marketplace add SamStull9007/limitcast 和 /plugin install limitcast@limitcast，才能使用上述插件命令。
原文称 limitcast 从 0.15.0 起全部免费、采用 MIT 许可证，这些命令不需要 key；0.16.0 发布包提供 tarball，文末另提到介绍上一版本的 0.14 文章。
我的判断
我认可它把「确定的截断」和「需要调查的异常」分开。索引超限有明确边界；缺少链接则可能只是另一种导航方式。后者如果直接触发删除，容易误伤仍在使用的笔记。
但原文没有提供整理前后的 token 消耗、任务成功率或读取次数对照。作者的真实目录证明了工具能发现候选问题，也暴露了链接检查的局限，不能据此认定拆分一定提升效率。
相比手工缩短 MEMORY.md，这套工具多了目录检查和引用核对，适合笔记已经较多的项目。文件很少时，手工维护短索引同样可行。过期内容和矛盾记录能否准确识别，原文也没有给出准确率数据，仍需人工看证据。
能拿来做什么
- 在已有 Claude Code 记忆的项目里先运行检查，同时看行数和字节数，优先处理索引超过 200 行或 25 KB 的问题。
- 对前端或 Node 项目中混写多类约定的长笔记，先审阅拆分目录；连续部署流程等需要顺序阅读的内容，可以保持完整。
- 对未被链接的文件先查目录引用和文件名查找方式，再决定补链接、归档或删除，不要把提示名单直接当成清理名单。