@lorrylurui/code-intelligence-mcp 2.0.6 → 2.0.7

package/README.md

@@ -45,106 +45,3 @@
 
 MYSQL\*SYMBOLS_TABLE=frontend_collections_symbols
 INDEX_GLOB=xxx/\*\*/\_.{js,jsx,ts,tsx}
-
-# 召回效果优化
-
-你这个场景里，“召回优化”建议按 3 层做，效果最好：
-
-**1. 先把候选尽量捞全（Recall 层）**
-
-1. 提高语义检索候选池：把语义 `topK` 从现在的小值提高到 `50~200`，不要在第一层就截断太早。
-2. 语义 + 关键词并行召回：同时跑向量检索、名称/路径/描述关键词检索、结构字段检索（props/hooks/sideEffects），最后并集去重。
-3. 做查询扩展：`affix` 自动扩成 `fixed/sticky/offsetTop/offsetBottom/固钉/吸顶/吸底/固定定位`，提升召回覆盖率。
-4. 加别名词典：为组件建立别名（如 `Affix -> 固钉, 固定定位, sticky`），召回时强制并入。
-5. 路径先验加白名单：`Components/`、components这类目录可加权，`demo/examples/pages`不直接过滤，但降权。
-
-**2. 再做精排（Ranking 层）**
-
-1. 两阶段排序：第一阶段只看“能不能进池子”，第二阶段再做质量门槛。
-2. 显式命中强加权：用户 query 出现明确词（如 `affix`）时，名称/文件名命中要有明显 boost。
-3. 避免 usage 绑架：`usage_count` 只做弱特征，别让高 usage 的 demo/page 抢过真实组件。
-4. 引入轻量 reranker：对 Top-50 用交叉编码器或规则+LLM 打分，可明显提升 Top-1 准确率。
-
-**3. 建立评测闭环（Offline Eval）**
-
-1. 做一套 50~200 条真实查询集（中英混合、别名、口语化）。
-2. 每次改召回都跑：`Recall@10`、`Recall@50`、`MRR@10`、`nDCG@10`。
-3. 对失败样本做“误杀分析”：是没召回、被质量门槛挡掉、还是排序被 demo 抢位。
-
-你这个仓库当前最该优先做的 3 个点是：
-
-1. 把第一阶段候选池再放大（至少 50+）。
-2. 固化 query 扩展词典（Affix 这类高频组件先做）。
-3. 把质量门槛后移，先召回后精排，减少“找到了但被早期过滤掉”。
-
-如果你要，我可以下一步直接给你一版“可落地参数表”（每个阈值给默认值与调参范围），方便你马上 A/B。
-
-# 待优化项
-
-修复优先级：
-✅8
-✅5
-✅134 done，但是第二层embedding需要优化，llm fallback太慢+漂移，也需要调整模型
-✅6
-✅27
-
-1.  meta里面有多个信息，哪些做结构化过滤，哪些做向量检索？
-    结论：ast normalizers后拼一个语义模板，用这个模板内容生成向量
-    ❓做法见qa-doc/semantic-phrase.md
-2.  对于 class类型，content字段保留关键方法或摘要，而不是完全为空
-    最新修改：content赋值为语义模板
-3.  category过于模糊，
-    这三层怎么做：category 优先使用规则和 embedding 分类，
-    LLM 只作为 fallback，避免不稳定和成本问题
-    ❓做法见qa-doc/category.md
-4.  type category meta.kind 字段是否多余了？type只有5个值，
-    type表达代码结构、category表达语义结构，kind？
-    type： function / component / hook / class / type / interface
-    category：最新的三层结构（还没实现，只有文档）
-    kind: 现在跟type重叠较多，建议弱化meta.kind → 只保留特殊情况：
-    ❓改造方法qa-doc/type-category-kind.md
-5.  在ci做增量索引时，把changed files,如果是1000+文件，性能爆炸，考虑用file hash 判断？embedding也没有优化缓存？
-    ❓见qa-doc/ci-hash-solution 方案：🥈 file hash + ast normalizer hash，新增semantic_hash
-    - CI 增量（git changed files 触发）
-      只需要 semantic_hash
-      file_hash 可省，因为文件必然变了
-    - 每日全量扫描
-      file_hash 用来跳过 AST 解析（CPU 优化）
-      semantic_hash 用来跳过 embedding（费用优化）
-      content_hash 删掉，职责完全被 semantic_hash 覆盖
-6.  大仓问题：
-    ❓big-repo.md
-    - ci embedding解耦，新增embedding_status, ci时，全量写入status='pending'-> ci finish
-    - ci如果检测到文件删除，则对被删除的代码块标记delete（这里需要新增字段）
-    - node+redis 消费写embedding job
-    - 对语义模板semantic_hash做向量缓存，semantic_hash相同即功能未变
-    - 大仓分片并行
-7.  content暂时用不到，但也不用删除，目前暴利截取4000字符需要优化：
-    content（降级为辅助字段）：✔ 不参与 embedding✔ 不参与排序✔ 不参与过滤✔ 用于：1. LLM改造建议 2.debug 3.future rerank
-    最简单：只存 signature
-    最优：content = {
-    signature: "function fetchData(url, options)",
-    snippet: "核心逻辑代码（<=300行）",
-    keyCalls: ["fetch", "cache"]
-    }
-8.  TopK???，首先去掉usage过滤，再做两次topk,1.根据余弦相似度选topk 2.对1的结果用现有的usage,updated_at等加权排序
-    ❓topK.md
-    现在：SQL过滤(type) → ORDER BY usage_count DESC LIMIT 3000→ embedding 相似度排序→ 取 top20
-    这个逻辑不对，导致query: "debounce function"，debounce 使用少 ❌ fetch 很热门 ✅，结果Top3000里全是 fetch / request， debounce 被过滤掉 ❌
-
-👉 优点：
-• 不阻塞 CI
-• 可扩展
-
-6. 大仓问题呢？
-
-# 简历里还没做的优化
-
-1. embedding基石 - 语义模板模板，使用ast数据拼装语义模板
-2. class的content为null
-3. category分层 1.规则 2.预设所有种类，使用embedding召回 3.llm兜底
-4. type meta.kind逻辑优化，现在太重叠了
-5. ci-hash-solution
-6. 大仓问题
-7. content优化
-8. ✅topk优化

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@lorrylurui/code-intelligence-mcp",
-    "version": "2.0.6",
+    "version": "2.0.7",
     "private": false,
     "description": "MCP server 提供仓库内可复用代码块（ts/tsx/js/jsx/css/less）的索引和查询能力，支持基于代码上下文的智能推荐。",
     "type": "module",