沉淀只是开始，召回才是价值
摩擦信号机制解决了「经验怎么进来」的问题，但知识库的价值兑现在另一个方向：新成员的 AI 在干活时，能不能自动用上这些经验？
如果答案是否定的——知识躺在库里等人来查——那它和 Confluence 里三年没人翻的文档没有区别。召回（recall）要解决的就是「用起来」：在合适的时机，把合适的知识，注入合适的 AI 上下文。
teamai-cli 内置了完整的召回体系。这篇讲它的组成、用法和调优。
召回体系的四个组件
组件一：相关性预检
不是每次 AI 交互都需要召回。相关性预检在召回动作之前做一层判断：当前任务和知识库有没有可能相关？无关的任务直接跳过召回，不浪费检索开销、不往上下文里塞噪音。这是「召回质量」的第一道闸门。
组件二：BM25 + 图谱增强排序
命中的候选知识怎么排序？teamai 用的是混合方案：
- BM25——经典的词频相关性算法，负责「字面上像」的基础打分
- 图谱增强——知识之间的关联关系参与排序。一条经验如果和当前任务涉及的模块、工具有图谱层面的关联，即使字面匹配度不高也会被提上来
纯 BM25 的痛点是「换个说法就搜不到」，图谱关联恰好补上这一层：经验 A 记录的是「部署服务的坑」，图谱知道它关联「K8s」「发布流程」，于是问「为什么发布总失败」时它也能被召回。字面相关 + 语义关联双层排序，这是召回质量的关键设计。
组件三：召回子智能体
排序后的知识注入上下文的方式很有意思：teamai 派出一个召回子智能体——一个专职「查资料」的 AI agent，它带着检索结果汇入主会话。主对话的 AI 拿到的是「被整理过的相关知识」，而不是一堆原始文档碎片。
这个设计避免了知识注入的常见副作用：把大段原始文本塞进上下文，反而稀释了任务指令的权重。子智能体相当于给主 AI 配了一个「随行资料员」。
组件四：手动检索兜底
自动化召回覆盖不到的场景，用 teamai recall 手动检索：
teamai recall "微服务超时配置的经验"适合主动学习场景：新人系统性地了解某个领域的团队经验，或者排查问题时主动翻一翻「前人踩坑记录」。
代码仓库知识图谱：teamai import
teamai-cli 的召回体系还有一个重量级输入源：你的代码仓库本身。
teamai import --from-repo <仓库地址>这个命令解析代码仓库，生成知识图谱——模块之间的依赖关系、关键路径、核心概念的关联结构。它解决的问题是：团队知识不只是踩坑经验，代码结构本身就是最大的知识体。
新成员的 AI 在接手一个陌生模块时，图谱召回能把「这个模块依赖哪些底层服务、历史上踩过什么坑、相关规范是什么」一次性带到上下文里——相当于配了一位熟悉全部代码历史的导师。
启用召回后（teamai recall enable），这套体系对日常会话完全透明：AI 该用的时候自己用，你不需要改变任何工作习惯。
召回质量的调优
召回体系上线后，按这三个信号判断是否需要调优：
信号一：召回太吵。 AI 上下文里经常出现不相关的知识条目——说明排序阈值偏松，或知识库巡检没跟上（过时知识占了检索权重）。处理：清理过时条目，收紧相关性预检。
信号二：该召回的没召回。 团队明明沉淀过某条经验，AI 干活时却没用上。排查方向：知识条目的描述是否用了「团队黑话」之外的说法（图谱关联依赖实体匹配）；或者该知识缺少与代码图谱的关联——用 teamai import 补一次仓库解析。
信号三：召回的内容过时。 经验跟着环境变，老经验可能已经失效。这就是为什么知识库也要治理节奏——召回系统忠实呈现库里的一切，包括过时的部分。
召回命令速查表
召回体系涉及的命令集中在这里，部署与日常排查各取所需：
| 命令 | 作用 | 使用时机 |
|---|---|---|
teamai recall enable | 启用自动召回 | 部署阶段执行一次 |
teamai recall "<查询语句>" | 手动检索团队知识 | 主动学习、排查问题时 |
teamai import --from-repo <仓库地址> | 解析代码仓库生成知识图谱 | 部署时，以及代码结构大改后 |
/teamai-share-learnings | 沉淀一条摩擦经验 | 踩坑当下、收到提醒时 |
teamai push | 把沉淀内容提交进知识库 | 总结完成后走审核流程 |
teamai status | 确认知识库同步状态 | 排查「为什么没召回」时 |
知识召回 FAQ
Q：开启召回后，日常工作习惯要变吗？
不需要。teamai recall enable 之后整套体系对会话透明：相关性预检判断要不要召回，召回子智能体负责检索和整理，主 AI 该用的时候自己用。唯一需要养成的习惯是踩坑时顺手做三十秒沉淀——那是知识库唯一的进项。
Q：召回的内容会不会把上下文撑爆、稀释任务指令？ 这正是召回子智能体存在的原因：它带着检索结果汇入主会话，主 AI 拿到的是整理过的相关知识，而非原始文档碎片。加上相关性预检把无关任务挡在门外，噪音控制在设计之内。
Q：明明沉淀过的经验没被召回，先查什么？
按顺序查三样：知识条目的描述是否用了团队黑话之外的说法（图谱关联依赖实体匹配）；该知识是否缺少与代码图谱的关联——用 teamai import 补一次仓库解析；知识库是否过时条目堆积——按治理节奏巡检清理。三样都正常仍不召回，再考虑收紧或放宽相关性预检。
Q：teamai import --from-repo 需要定期重跑吗？
代码结构大改之后值得重跑——图谱反映的是解析那一刻的仓库结构，模块依赖变了而图谱没跟上，召回就会带着过时的结构知识。把它挂进大版本重构的收尾清单，和文档更新放同一批。
Q：手动 teamai recall 和自动召回是什么关系？
自动化召回覆盖「干活时顺手用上」的场景，手动检索覆盖「系统性了解」的场景——新人入职把某领域的团队经验翻一遍、排查疑难问题时主动检索前人踩坑记录，都属后者。两条通路查的是同一个库，互相补充。
与 RAG 的关系：工程化的一次收敛
熟悉 RAG（检索增强生成）的读者会发现，teamai 的召回体系就是一套面向「团队知识」场景的 RAG 工程：预检 ≈ 查询意图判断，BM25+图谱 ≈ 混合检索与重排，子智能体 ≈ 受控注入。它没有发明新技术，但把 RAG 的通用组件针对「AI 编程协作」场景做了完整落地——知识源自动生长（摩擦信号）、图谱自带代码结构（import）、召回对用户零感知。
这三点恰好是通用 RAG 方案在团队场景最难做好的部分。工具已经就位，剩下的变量只有一个：你们团队沉淀的纪律性。从今天的第一条摩擦信号开始。