Claude Code 再强，也有一个很烦的老毛病：新会话一开，它像刚进组的新人。项目结构、历史决策、踩过的坑、下一步要改哪里，都得再讲一遍。
GitHub 上有个叫 Recall 的小工具，专门处理这个冷启动。它不是 Anthropic 官方产品，也不是成熟商业服务。目前只能看成一个 MIT 许可、Python 实现、约 13 stars 的第三方 Claude Code 插件。
但这个小仓库点到了一件真事：AI 编程的浪费，很多时候不在“模型不够聪明”，而在“上下文每次重建”。开发者花 token，也花耐心。
Recall 做的是本地续接，不是项目理解
Recall 的机制很朴素。它在项目目录下维护两个核心文件：
| 文件 | 用途 | 需要注意的点 |
|---|---|---|
.recall/history.md | 追加记录会话、提示、回复、触碰文件和命令 | 原始流水账，会持续变长 |
.recall/context.md | 生成下次会话可读摘要 | 下次续接主要靠它 |
会话过程中，Claude Code 的 hooks 把活动写进 history.md。你运行 /recall:save，或配置成会话结束自动保存，它会读取历史，覆盖生成新的 context.md。
下次打开 Claude Code，插件再把这份摘要拿出来，让你选择是否恢复上下文、是否继续记录。
它的承诺很克制：
- 不联网。
- 不需要 API key。
- 不调用外部模型。
- 不跑本地大模型。
摘要也不是 LLM 生成的。Recall 用的是 TF-IDF + TextRank：把文本切成句子，计算重要性和相似度，再抽出更“中心”的句子，按顺序拼回去。
numpy 只是可选加速。没有 numpy，也能走纯 Python 路径。
这点很关键。Recall 并没有真正理解你的工程语义。它更像一个本地会议纪要员：勤快、便宜、离线，但不会替你判断架构取舍。
对重度使用 Claude Code 的个人开发者，这已经够用了。你不一定需要一个“懂项目灵魂”的 AI。你先需要它别每次都问同样的问题。
本地记忆省事，但别把它当保险箱
Recall 最实用的地方，是把重复解释压缩成一个本地摘要文件。仓库给出的方向是让 context.md 控制在大约 1–2K tokens 级别，但省多少 token，取决于项目大小和使用习惯，不能当成固定比例。
几条路线放在一起看，差别更清楚：
| 路线 | 好处 | 代价 |
|---|---|---|
| 每次手动重讲项目 | 最透明，风险低 | 浪费 token，开发者累 |
| 把长文档直接喂给模型 | 信息更完整 | 成本高，噪音多，隐私压力大 |
| 用 LLM 做记忆摘要 | 语义压缩更强 | 要调用模型，成本和数据边界更复杂 |
| Recall 这种本地抽取摘要 | 便宜、离线、低摩擦 | 可能漏掉真正关键的语义关系 |
我更愿意把 Recall 看成“够用主义”的工具。它不炫技，但抓住了开发者的真实痛点：少解释一次，就是少烧一轮 token，也少打断一次工作流。
隐私卖点也是真的。没有网络调用，没有 API key，没有外部模型，这比再接一个远端记忆服务更让人放心。
但“本地”不等于“绝对安全”。仓库自己也承认，redaction 只是 best-effort。它会尝试处理常见密钥、token、.env 赋值、PEM key 这类敏感内容，但不是保证。
所以个人开发者如果要试，最现实的做法是：把 .recall/ 默认留在本地，必要时加入 .gitignore；如果要提交，先人工看一遍 history.md 和 context.md。
团队更要谨慎。
一旦把 .recall/context.md 提交进 repo，它就不再只是个人记忆。它会变成团队共享输入。下次 Claude Code 读到它时，里面的内容可能直接影响模型行为。
这就打开了提示注入入口。任何能改 repo 的人，都可能在 context.md 里塞入误导性指令。Recall 会把内容标记为不可信，并让 Claude 询问是否依赖，但信任边界已经变了。
团队维护者现在不该急着把它当知识库提交。更稳的动作是先观察三件事：context.md 有没有来源标注，过期内容怎么清理，共享记忆有没有审查规则。
没有这三件事，记忆越方便，投毒也越方便。
AI 编程的下一场竞争，是谁管得住上下文
Recall 这个项目本身很小。13 stars 的仓库，还谈不上生态影响力。
它真正有意思的地方，是把 AI 编程工具的下一层问题露出来了：模型会写代码只是门票，能不能稳定接活，要看上下文怎么保存、筛选、过期和共享。
“兵马未动，粮草先行。”放到 AI 编程里，粮草就是上下文。没有上下文，模型再强，也只能在一次次短会话里猜。
这和早期互联网工具有点像。最开始大家关心网页能不能打开。真进生产后，日志、权限、缓存、监控、备份，才决定系统能不能长期跑。
AI 编程也会走到这一步。按钮越来越多，模型越来越强，但工程现场真正麻烦的是这些小问题：
- 哪些上下文可信？
- 哪些记录已经过期？
- 哪些内容不能提交？
- 哪些记忆只属于个人工作区？
- 哪些可以共享给团队？
Recall 选了一条很不性感的路：本地优先，文件优先，传统算法优先。
我反而觉得这条路清醒。很多开发者并不想再养一个“记忆模型”，也不想为了省一点解释成本，把代码路径、命令记录、偶尔混进去的秘密交给更多服务。
真正的风险在另一边：烂记忆。
如果 context.md 越写越像一份陈旧纪要，模型读了，开发者信了，错误就会被包装成“项目事实”。这比失忆更麻烦。失忆最多多问几句，错记会把后面的判断带偏。
所以这类工具的上限，不取决于摘要算法多花哨。TF-IDF + TextRank 能压缩文本，但不能保证项目记忆正确。
上限取决于更脏、更工程化的东西：来源、版本、过期、审查、共享权限。
个人开发者可以试 Recall，把它当本地续接层，不要把它当权威知识库。团队可以观望，等它或同类工具把信任边界讲清楚，再考虑纳入流程。
这件事小，但提醒很准：AI 编程工具不能只卷“下一次回答多聪明”。生产力藏在更无聊的地方——谁能让模型少重来，少误信，少把旧账当新事实。