---
title: 找回调试方案：从搜索候选到验证可复用条件
description: 用一个明确标注的调试场景，检查笔记、向量和检索返回，再核对原始对话与当前项目，避免把相关分数当作正确答案。
image: "https://zengliangyi.com/og/blog/recover-debugging-notes.png"
---

记得曾经处理过一个问题，却找不到当时的条件和改动，比忘记代码片段更麻烦。知识库能缩小查找范围，但找到相似笔记之后，仍要判断历史方案是否适用于现在。

以下使用构造场景：一个 React 页面出现重复请求，历史笔记记录了排查过程。它不是已经发生的个人案例，也没有“几秒找回”的实测承诺。行为依据是 [ChatCrystal](/projects/chatcrystal) 提交 [`7642768`](https://github.com/ZengLiangYi/ChatCrystal/tree/764276814e5c5a33ecbfeae63754f74b9261a3a8) 的检索路由与笔记服务。

## 确认有可检索的笔记

导入会话、生成笔记和建立向量是不同步骤。当前语义检索使用笔记向量，不会在缺少笔记时自动退回原始对话全文搜索。先选择实际历史中的一个非演示会话，按 [入门流程](/blog/chatcrystal-getting-started) 完成摘要与索引。



```bash
crystal   --json   notes   list   --limit   20
```



从 `items` 中选择已知笔记的 ID，再读取详情：



```text
crystal --json notes get <note-id>
```



核对正文与 `embedding_status`。`done` 表示笔记向量处理完成，不表示摘要内容一定正确；`pending`、`syncing`、`failed` 需要先处理索引状态。经验门槛也可能正常过滤会话而不生成笔记。模型配置和重建的验收见 [LLM 与 Embedding 的职责](/blog/llm-and-embedding-separation)。

## 先写问题，再比较表述

在默认本机连接上，使用 JSON 输出让数量上限实际传入检索请求；符合条件的候选不足时，返回可以少于这个上限：



```bash
crystal   --json   search   "React 页面重复请求，如何定位触发来源"   --limit   5
```



保留问题的辨识条件，例如技术栈、报错、发生阶段和预期结果。也可以尝试简短关键词。自然语言不保证总比关键词准确，更长的描述也可能引入无关概念。比较几种表述是否找到同一篇已知笔记，比笼统宣称“越具体越精准”更可检验。

[搜索路由](https://github.com/ZengLiangYi/ChatCrystal/blob/764276814e5c5a33ecbfeae63754f74b9261a3a8/server/src/routes/notes.ts) 返回候选的 `note_id`、`conversation_id`、标题、项目、标签和分数等字段，不直接返回完整笔记正文或原始对话片段。CLI JSON 已解包为数组；安装了 `jq` 时可提取标识：



```bash
crystal   --json   search   "React 重复请求"   --limit   5   |  
    jq   '.[] | {note_id, conversation_id, title, score}'
```



这里使用 `.[]`，不是 `.data[]`。检索结果是下一步阅读的入口，不是已经核验的调试答案。

## 阅读笔记，再回到原始记录

用候选的 `note_id` 获取详情，确认问题、结论、代码片段和项目名称。笔记的摘要可能遗漏环境条件；必要时通过 `conversation_id` 读取 `GET /api/conversations/<id>`，核对实际消息。

在这个构造场景中，需要回答：重复请求发生在开发还是生产环境？来自组件生命周期、用户事件还是请求重试？历史修改是否真正消除了故障，还是只是隐藏了现象？不要在没有证据时直接套用某个 React 配置。

[检索实现](https://github.com/ZengLiangYi/ChatCrystal/blob/764276814e5c5a33ecbfeae63754f74b9261a3a8/server/src/services/embedding.ts) 结合向量候选、词项匹配加分与笔记去重。返回分数不是纯粹的原始余弦值，也不是“方案正确的概率”。分数高只能帮助决定先读哪篇。

## 用正反查询检查恢复路径

至少记录两类查询：一条应找到已知方案的问题，以及一条知识库没有相关答案的问题。正例检查目标笔记是否进入候选、正文是否足够解释处理过程；反例检查系统是否返回空结果，或返回了哪些需要人工排除的候选。

没有结果时依次检查：真实笔记是否存在、向量状态是否完成、查询模型是否与已有向量匹配、表述与内容是否相关。不要直接把空结果归因于某个模型质量差。再次摘要已有笔记也不会自动重写它；当前摘要服务会先返回已有笔记 ID，不能把 `summarize --all` 描述成全库重新生成。

## 复用之前验证当前项目

把历史方案改写成可验证假设，在当前项目中复现问题、应用最小改动，再检查问题与相关回归路径。版本、依赖和部署条件改变时，重新核对对应官方资料。

只有检查过适用条件和结果，候选才成为本次任务的证据。若通过 MCP 让 Agent 检索，也应要求它展示找到的笔记、适用条件和验证步骤；提供工具并不保证 Agent 每次自动调用。进一步的检索与关系边界见 [RAG 与知识图谱](/blog/rag-and-knowledge-graphs)，写回质量边界见 [知识记忆闭环](/blog/agent-knowledge-memory-loop)。

分享：

##  相关文章

[##  语义搜索与关系上下文：发现隐藏依赖但保留验证

用构造的重构场景组合直接检索和一跳关系扩展，解释分数、候选和来源字段，不把关联线索写成依赖证明。          曾亮懿       2026年10月3日      阅读约 3 分钟

#ChatCrystal

#语义搜索

#知识图谱](/blog/semantic-search-relation-context)    [##  语义搜索流程：请求、候选去重与关系扩展

沿 ChatCrystal 实现检查查询向量、候选升级、词项加分和关系扩展，用实际 API 区分笔记列表筛选与语义检索。          曾亮懿       2026年10月3日      阅读约 3 分钟

#ChatCrystal

#语义搜索

#RAG](/blog/semantic-search-workflow)    [##  AI 对话格式差异：事件、快照与跨库消息定位

对照五个固定适配器，区分 JSONL 容器、事件语义与 SQLite 键布局，用两个内存数据库观察消息索引、孤立数据和未知版本。          曾亮懿       2026年10月7日      阅读约 4 分钟

#ChatCrystal

#Node.js

#SQLite](/blog/ai-conversation-format-divergence)

##  从文章到代码

到我的 GitHub 看看 ChatCrystal、开发者工具和日常学习记录，欢迎交流实现细节。

[访问我的 GitHub](https://github.com/ZengLiangYi)

```json
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "ZengLiangYi Blog",
  "alternateName": [
    "Zeng Liangyi",
    "ZengLiangYi",
    "zengliangyi.com"
  ],
  "url": "https://zengliangyi.com",
  "description": "曾亮懿的个人网站。记录 AI Native 探索、开发者工具与全栈产品实践。"
}
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "找回调试方案：从搜索候选到验证可复用条件",
  "description": "用一个明确标注的调试场景，检查笔记、向量和检索返回，再核对原始对话与当前项目，避免把相关分数当作正确答案。",
  "url": "https://zengliangyi.com/blog/recover-debugging-notes/",
  "image": "https://zengliangyi.com/images/blog/recover-debugging-notes.svg",
  "datePublished": "2026-10-03T00:00:00.000Z",
  "dateModified": "2026-10-03T00:00:00.000Z",
  "author": {
    "@type": "Person",
    "name": "曾亮懿",
    "url": "https://zengliangyi.com/about"
  },
  "publisher": {
    "@type": "Organization",
    "name": "ZengLiangYi Blog",
    "logo": {
      "@type": "ImageObject",
      "url": "https://zengliangyi.com/favicon-96x96.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://zengliangyi.com/blog/recover-debugging-notes/"
  }
}
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "首页",
      "item": "https://zengliangyi.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "文章",
      "item": "https://zengliangyi.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "找回调试方案：从搜索候选到验证可复用条件",
      "item": "https://zengliangyi.com/blog/recover-debugging-notes/"
    }
  ]
}
```