diff --git a/skills/lark-doc/references/lark-doc-search.md b/skills/lark-doc/references/lark-doc-search.md index 92affe613..66f79196c 100644 --- a/skills/lark-doc/references/lark-doc-search.md +++ b/skills/lark-doc/references/lark-doc-search.md @@ -196,6 +196,8 @@ lark-cli docs +search --query "方案" --format json --page-token '' - 参数传递：只要用户给了搜索关键词，就必须显式使用 `--query "<关键词>"`。不要生成 `lark-cli docs +search 方案`、`lark-cli docs +search xxx（搜索关键词）` 这种位置参数写法。 - 查询语义：必须优先利用 --query 的高级语法（如 intitle:、""、-）将过滤逻辑下推给服务端。当用户要求“标题精确等于 X”时，直接使用 --query "intitle:\"X\""，严禁先进行模糊搜索再做客户端二次筛选。只有在遇到服务端语法无法覆盖的复杂本地比对场景时，才允许在客户端过滤，且比对前必须先去掉 title_highlighted 里的高亮标签。 +- 同义词改写：对“主题式 / 概念式”检索（如“XX 优秀案例”“YY 客户故事”“ZZ 最佳实践”），即使第一轮 --query 有相关命中，也不要立即锁定答案，应至少再跑 1-2 轮同义词 / 近义改写（例如把“案例” ↔ “优秀案例 / 客户案例 / 实践 / 故事”互换，或在中英文术语之间互换），以覆盖不同标题风格下的 expected 源。只有在多轮改写仍收敛到同一批命中时，才认为召回已稳定。 +- 下钻到 BITABLE / WIKI 节点：当 `docs +search` 命中 `BITABLE` / `WIKI` 节点且用户问题是“从这个表 / 知识库里找某个主题的记录”时，不要只用 `base +record-list` 或 `wiki` 里的标题字段做一次性过滤。应先用 `base +field-list` / `wiki +node-list` 了解字段 / 子节点结构，再对“推荐理由 / 标签 / 工具栈 / 摘要”等**非标题语义字段**一并执行关键词或同义词比对；只按 title 过滤容易漏掉标题未命中但语义相关的记录。 - 实体补全：如果用户要按“某个群里分享的文档”搜索，先用 `lark-im` 拿 `chat_id` 再填 `chat_ids`；如果用户要按“某人分享的文档”搜索，先用 `lark-contact` 拿 `open_id` 再填 `sharer_ids`。 - 零结果回退：如果因为用户的显式类型约束加了 `doc_types` 且结果为 0，可以提示“按指定类型没搜到”；只有在不违背用户明确约束的前提下，才建议放宽类型重试。 - 入口选择：用户说“找表格标题”“找名为 `X` 的电子表格”“搜某个报表”时，也默认走 `docs +search`。不要误用 `sheets +find` 做跨文件搜索。