目录 展开 收起
记得曾经处理过一个问题，却找不到当时的条件和改动，比忘记代码片段更麻烦。知识库能缩小查找范围，但找到相似笔记之后，仍要判断历史方案是否适用于现在。
以下使用构造场景：一个 React 页面出现重复请求，历史笔记记录了排查过程。它不是已经发生的个人案例，也没有“几秒找回”的实测承诺。行为依据是 ChatCrystal 提交 7642768 的检索路由与笔记服务。
确认有可检索的笔记
导入会话、生成笔记和建立向量是不同步骤。当前语义检索使用笔记向量，不会在缺少笔记时自动退回原始对话全文搜索。先选择实际历史中的一个非演示会话，按 入门流程 完成摘要与索引。
crystal --json notes list --limit 20从 items 中选择已知笔记的 ID，再读取详情：
crystal --json notes get <note-id>核对正文与 embedding_status。done 表示笔记向量处理完成，不表示摘要内容一定正确；pending、syncing、failed 需要先处理索引状态。经验门槛也可能正常过滤会话而不生成笔记。模型配置和重建的验收见 LLM 与 Embedding 的职责。
先写问题，再比较表述
在默认本机连接上，使用 JSON 输出让数量上限实际传入检索请求；符合条件的候选不足时，返回可以少于这个上限：
crystal --json search "React 页面重复请求，如何定位触发来源" --limit 5保留问题的辨识条件，例如技术栈、报错、发生阶段和预期结果。也可以尝试简短关键词。自然语言不保证总比关键词准确，更长的描述也可能引入无关概念。比较几种表述是否找到同一篇已知笔记，比笼统宣称“越具体越精准”更可检验。
搜索路由 返回候选的 note_id、conversation_id、标题、项目、标签和分数等字段，不直接返回完整笔记正文或原始对话片段。CLI JSON 已解包为数组；安装了 jq 时可提取标识：
crystal --json search "React 重复请求" --limit 5 |
jq '.[] | {note_id, conversation_id, title, score}'这里使用 .[]，不是 .data[]。检索结果是下一步阅读的入口，不是已经核验的调试答案。
阅读笔记，再回到原始记录
用候选的 note_id 获取详情，确认问题、结论、代码片段和项目名称。笔记的摘要可能遗漏环境条件；必要时通过 conversation_id 读取 GET /api/conversations/<id>，核对实际消息。
在这个构造场景中，需要回答：重复请求发生在开发还是生产环境？来自组件生命周期、用户事件还是请求重试？历史修改是否真正消除了故障，还是只是隐藏了现象？不要在没有证据时直接套用某个 React 配置。
检索实现 结合向量候选、词项匹配加分与笔记去重。返回分数不是纯粹的原始余弦值，也不是“方案正确的概率”。分数高只能帮助决定先读哪篇。
用正反查询检查恢复路径
至少记录两类查询：一条应找到已知方案的问题，以及一条知识库没有相关答案的问题。正例检查目标笔记是否进入候选、正文是否足够解释处理过程；反例检查系统是否返回空结果，或返回了哪些需要人工排除的候选。
没有结果时依次检查：真实笔记是否存在、向量状态是否完成、查询模型是否与已有向量匹配、表述与内容是否相关。不要直接把空结果归因于某个模型质量差。再次摘要已有笔记也不会自动重写它；当前摘要服务会先返回已有笔记 ID，不能把 summarize --all 描述成全库重新生成。
复用之前验证当前项目
把历史方案改写成可验证假设，在当前项目中复现问题、应用最小改动，再检查问题与相关回归路径。版本、依赖和部署条件改变时，重新核对对应官方资料。
只有检查过适用条件和结果，候选才成为本次任务的证据。若通过 MCP 让 Agent 检索，也应要求它展示找到的笔记、适用条件和验证步骤；提供工具并不保证 Agent 每次自动调用。进一步的检索与关系边界见 RAG 与知识图谱，写回质量边界见 知识记忆闭环。