智忆实践总结：从「召回了 218 次」到真正用得上

把 AI 接到团队日常开发之后，最先暴露的不是「会不会写代码」，而是写完就忘。同一个 Nuxt 启动坑、同一类 JDK 编译配置、同一套跨仓依赖问题，隔两周又被重新踩一遍——对话结束，经验也结束了。

智忆（zhiyi）做的事很直接：让 Agent 在动手前先 Recall，做完后按门禁 Submit，用过再 Feedback。下面是一段真实使用后的实践总结：哪些闭环跑通了，哪些数字会骗人，以及我们准备怎么改。

一、先把闭环跑起来

实践里最有用的不是「多存几篇经验」，而是把四步固定成习惯：

1. Recall：任务开始前按业务意图召回 Rule / Workflow / Experience；项目定位用独立字段（repository / module），不要塞进 task。
2. 执行：优先遵守命中的规范；和本地代码冲突时先说清楚再覆盖。
3. Submit：只有「真实新认知 + 可验证结果」才沉淀 Experience；规范缺口补 Rule/Workflow，而不是再堆一条流水账。
4. Feedback：真正用到的标 helpful / used，不对的标 not_helpful / outdated / wrong。

没有 Feedback，系统只能看见「被召回了多少次」，看不见「有没有帮上忙」。

二、一个会骗人的指标：1 / 218

统计页上曾经出现过这样一条 Experience：

• 标题大意：修复 Nuxt 3.16 开发启动时 #build 虚拟模块解析失败
• 模块：chat2x-web
• Recall 次数：218
• helpful：1

第一反应很容易是「这条经验质量极差」。把召回日志和反馈拆开看之后，真相更接近下面三点。

1）分母是召回次数，不是评价次数

217 次命中会话里，真正留下反馈的只有 2 条：1 次 helpful、1 次 not_helpful。
所以「1/218」更像闭环缺失，而不是严谨的「有用率」。更合理的口径至少应看：

• helpful / (helpful + not_helpful)
• 有反馈会话中的正反馈占比
• 跨仓命中占比（噪声有多高）

2）绝大多数是低置信误召

抽样复盘后大致是：

• 约 80% 跨仓命中（本仓 chat2x 少数，同模块更少）
• 平均 similarity 大约 0.07，大量命中甚至低于 0.08 的绝对地板
• 平均最终分极低，却仍常排进 Top 中后位「填满 limit」

典型误伤任务包括：JDK 编译、JWT 循环依赖、SQL 语法、Markdown 空格、SVG 数值修复……和「不要手写锁定 Vite 5」几乎无关。

3）内容过窄，还混装了两件事

这条经验的核心事实其实很窄：Nuxt 3.16 场景下不要在 devDependencies 手动 pin Vite 5，否则 #build/* 虚拟模块会挂。
但正文里又夹了助手 drafting / loading 状态同步。向量检索很容易被「修复 / Nuxt / Vite / 启动」这类泛主题吸住，真实适用面却极小——于是变成「爱被捞上来、却很少真正用得上」的热条目。

连那唯一一次 helpful，也是另仓 Nuxt/Vite 启动失败的弱相关命中，不是同一根因被精确复用。

三、实践里真正有效的几条习惯

1. task 只写意图，定位字段单独传

错误写法：把仓库名、模块名、环境词塞进 task，污染 query。
正确写法：task 描述业务问题；repository / module / currentFile 走独立字段。意图匹配优先于「同仓泛 Rule 硬抬」。

2. 提交前过「提交门」

• 执行问题（规范已有但没遵守）→ 不提交 Experience
• 规范缺口 → 补 Rule / Workflow，而不是再写一条个案经验
• 真实新认知（有取舍、有验证）→ 才写 Experience，并补齐 observation / decision / action

空 artifacts、标题复读正文、把两件无关修复揉成一条，都会在后续召回里制造噪声。

3. 窄约束优先结构化，别写成万能故事

像「Nuxt 3.16+ 不要手动锁定 Vite」这类可泛化约束，更适合沉淀成 Rule / Constraint；把「某次助手状态机修复」拆成另一条 Experience。混装会让向量既「什么都像」，又「什么都不准」。

4. 有召回就要有反馈

没有 Feedback，Ranking 学不到偏好，治理也分不清「热」和「好」。实践约定很简单：用到了就标，没用就标 not_helpful——宁可少召回几次，也不要长期养一条刷屏噪声。

四、引擎侧我们准备怎么改

结合这条高召回低有用样本，机制级方向比「再给 Agent 补一句提示」更重要：

1. 低置信截断必须生效：绝对 similarity 地板、Top1 过低整页清空、跨仓软顶；并在召回摘要里落盘 droppedByLowConfidence，方便复盘「地板误杀」还是「池子无货」。
2. Experience 跨仓更严：同仓 context 为 0 时，提高丢弃门槛，避免窄个案漂到所有仓库。
3. 高召回低反馈治理：对 recall 很高、正反馈接近 0 的条目自动冷却 / 降权 / 进治理队列，打断「越召越热」。
4. 统计口径升级：页面同时展示「有反馈样本的 helpful 率」和「跨仓命中占比」，避免被 1/218 误导。

这些改动的目标很明确：少把噪声塞进 Agent 上下文，而不是靠更长的 promptBlock 掩盖检索问题。

五、阶段性结论

智忆已经证明一件事：经验可以进入 Agent 工作流，而不只是写在 Wiki 里等人来搜。
但实践也证明另一件事：召回次数不等于价值；没有反馈的热度，常常是噪声放大器。

接下来最值得坚持的，不是「多存」，而是：

• 召回要对齐意图与仓库边界
• 沉淀要过提交门、避免混装
• 使用必须闭环反馈
• 引擎用截断与治理消灭低置信填空

当「被召回」慢慢变成「被验证有用」，智忆才会从记忆仓库，长成真正可复用的团队经验基础设施。