# Jevmem 0.3 秒决定记什么，但 TypeSafe 看到了转折

**Summary:** Jevmem 让项目记忆自动化且可审计，但默认路径会将每个 Claude Code 对话轮次都发送给 TypeSafe。我只会在我认为记忆收益值得跨越该数据边界的地方试用它。

- Canonical: https://markhuang.ai/zh/news/jevmem-memory-gate-typesafe-sees-turn
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-09-25
- Section: News
- Tags: Jevmem, Claude Code, 项目记忆
- Source: [Jevmem on GitHub](https://github.com/Avinash-jetwani/jevmem)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![对话片段通过一个狭窄的决策门，随后一张选中的卡片进入项目记忆文件](https://cdn.markhuang.ai/news/jevmem-memory-gate-typesafe-sees-turn/hero.webp)

*自动记忆远看像一本整洁的台账。关键在于每一轮对话都要先过那道门。*

[Jevmem](https://github.com/Avinash-jetwani/jevmem) 是一个 MIT 许可的新工具，负责把编程助手对话里出现的决策、约束、bug 和待办事项写进一份共享的 `JEVMEM.md`。2026 年 9 月 25 日的 changelog 已经到 0.4.5，作者报告在 66 个留出的对话轮次上，记忆决策的中位耗时是 0.30 秒。

我的看法是，Jevmem 解决了一个真实麻烦，而且代价摆在那里看得清楚。编程会话中间做的决定能留下来，写进 Git review，带到 Claude Code、Codex、Cursor 里都能用。但在 Claude Code 的默认路径上，每一轮对话结束后都会发给 TypeSafe，由 Jev 判断要不要存进记忆。

比起速度这个数字，我更在意的是那道边界。我不会因为记忆门槛低、跑得快，就把它装进一个敏感仓库。我会先想清楚哪些对话可以离开这台机器，再看存下来的记忆到底有没有帮到后面的工作。项目测过写入准确率，但还没测召回质量。

## 最有用的设计其实很无聊：一份你能 review 的文件

Jevmem 最聪明的设计就是这种无聊。最后留下来的是一份 commit 进 Git 的 Markdown 文件，不是绑死在某个助手或某台电脑上的黑盒记忆。每一行都有类型、ID、时间戳和置信度。后面如果决策变了，Jevmem 不会删掉旧行，而是标记成已取代。Git 历史和 code review 都能看到这个过程。

自动化程度因客户端而异。Claude Code 通过 `Stop` hook 自动捕获，通过 `UserPromptSubmit` 自动召回。Anthropic 的 [hook 文档](https://code.claude.com/docs/en/hooks)确认这两个事件每轮各触发一次，分别在对话结束和下一条 prompt 之前。Codex 只有在 `jevmem watch` 跑着的时候才是自动的；否则 Codex 和 Cursor 都得靠 agent 自己调 MCP，或者写在 repo 指令里。

区别之所以重要，是因为团队得逐个客户端验证。在 Claude Code 里全自动的记忆流程，换到 Cursor 可能就变成一条 agent 得自己记得执行的约定。

## 隐私问题不止一行数据

Jevmem 的[安全文档](https://github.com/Avinash-jetwani/jevmem/blob/main/SECURITY.md)把默认数据路径写得很清楚。每次 Claude Code 触发 `Stop`，它会把当前用户消息、前两轮对话的截断版，以及最多 200 行经过关键词过滤的实时记忆发给 TypeSafe 的 API。如果启发式规则判断对话涉及提问、调查或 bug 报告，还会带上助手回复。召回时则发送新 prompt 和最多 60 条实时记忆，让 Jev 挑出要注入的内容。

传输前工具会清洗常见的 API key 格式、私钥、邮箱、16 位数字和几种凭证格式。同一份文档也承认有漏网之鱼：姓名、电话、邮寄地址、身份证号、未知格式的凭证可能还在。这种坦诚是好的，但尽力而为的清洗器不等于安全策略。仓库里的对话可能夹着客户信息、内部 URL、未发布计划甚至专有代码片段——这些东西看起来并不像密钥。

Jevmem 可以设 `zeroDataRetention` 标志，但文档说具体承诺取决于网关或 TypeSafe 的条款，工具本身不验证。如果存记忆时用了可选的 OpenAI 或 Anthropic writer，源文本也会发给对应的 provider。我会把 TypeSafe 路径和 writer 路径分开看。

> **Info:**
>
> 我的采用原则：自动记忆应该继承仓库的数据分级。如果一轮对话对配置的记忆 provider 来说太敏感，那它对自动捕获来说也太敏感。

## benchmark 测的是门，不是收益

公开的 [benchmark](https://github.com/Avinash-jetwani/jevmem/blob/main/docs/benchmark.md) 有用，因为它把测试框架和局限性都摊开了。Jevmem 在"存 vs 跳过"上拿到 98.5%，在"存 + 记忆类型"上拿到 95.5%。中位数 300 毫秒，远快于测试的六个通用模型（2.8 到 4.3 秒）。每次决策 $0.000127，比六个对比模型里的五个都便宜。

这些数字来自作者在 66 个留出轮次上跑的一次实验。仓库自己也提醒，差一两个轮次就在 run-to-run 噪声范围内。它还说五轮的 harness 测不了跨周的漂移，召回质量也没测。一个快的分类器能决定存什么，但证明不了存下来的东西能帮 agent 在下周二做出更好的改动。

这和我在 [Jev 的类型化决策模型](https://markhuang.ai/news/jev-schema-guarantee-wrong-decision)里看到的是同一条边界。概率和代码级的 threshold 让门变得可测，但不让它的判断变得正确。放在记忆工具里，假阳性会留住一条错的规则，假阴性会悄悄丢掉这个工具本来该保护的那个决策。

## 漏掉的轮次得有人管

Jevmem 给每次 Jev 调用两秒预算。服务慢了或者挂了，文档里的处理方式是跳过这轮、写一条本地日志，然后继续，不重试。这对保持编程会话的响应速度来说是合理的，但也制造了一种安静的失败模式——开发者以为记忆是自动的，结果当天最重要的决策根本没写进 `JEVMEM.md`。

在正式依赖这套系统之前，我会先把这个缺口暴露出来。试点阶段要跟踪丢了多少轮、存错了什么、漏掉了哪些决策、有哪些行被取代了，以及召回的记忆到底有没有让回答或 patch 变得更好。提交进 Git 的记忆文件应该像代码一样被 review，尤其是涉及架构、安全策略或版本兼容的条目。

我的第一轮测试会选一个把对话上下文发给配置 provider 没有问题的仓库。跑几周之后，我会拿记忆文件和团队的实际决策做对比，再看本地审计日志。如果大家一直在手动改这个文件，或者 agent 很少用对那条记忆，那自动化只是又多了一个要维护的东西。

## 要不要装

对于项目记忆，Jevmem 给出的答案比再来一个不透明的本地数据库要好。记忆是纯文本，决策被推翻时旧记录仍然可见，阈值写在配置文件里，安全文档说清楚了什么会过网络。作者甚至主动承认了两件还没证明的事：更好的召回效果，以及长期稳定性。

这种坦诚让我更愿意试一试。即便如此，我的第一次部署也会控制范围。0.30 秒的门确实快，但速度只回答了记忆能不能跑在每一轮上。更难的问题是：每一轮到底该不该过那道门。