# 文档检索与问答

本文件说明**怎么查、怎么读、怎么答**：先用 CLI 线索定方向，再在知识库的 `.md` 文件里 `Grep` **探路**、按命中与用户语义 **缩小范围**、`Read` **精读**，最后作答。查哪棵目录由 `SKILL.md` [意图细则](../SKILL.md#意图细则) 决定；默认「答疑与排障」查 `<SKILL目录>/assets/微信支付官网文档/` 全库。

回答正文须来自已 `Read` 的知识库文档；知识库没有时，再按[链接与联网](#链接与联网)取官方页。

## 规则

### 硬性约束

1. **先探路再锁定**：可依据已有线索（CLI search 返回的定位信息、用户给出的 URL/路径）做定向 `Grep`；**没有这类依据时**须在当前意图的检索路径上 `Grep`（答疑与排障为全树），不得在未看命中分布的情况下仅凭知识库索引猜测并锁定单一前缀。
2. **路径即判据**：文件名和目录已包含中文标题，路径明显相关时直接精读，**不要**批量读 `front matter` 做筛选。
3. **检索词忠实**：`Grep` 的 `pattern` 须保留用户原文中的 URL、接口路径、错误码、字段名等。
4. **精读节制**：按需精读与问题**直接相关**的文档（一般 3～5 篇，复杂 / 对比类可更多），**不要大面积无关扫描**、不要整篇通读；缩小范围后的 `Grep`/`Read` 应落在第三步确定的前缀或少数候选前缀内。
5. **禁止编造**：接口、字段、错误码须来自知识库 `Read` 结果，不凭模型记忆编造。
6. **检索有上限，未覆盖如实告知**：换方向找 **3 次**仍无相关命中即停止，明确告知用户该问题超出当前知识库覆盖范围，禁止用弱相关文档硬凑答案。
7. **简洁作答**：答案只含直接回答用户问题所需的信息；用户未问的不展开，不堆砌无关内容。

### 链接与联网

正文中遇到的链接按以下方式处理：

| 域名 | 处理 |
|---|---|
| `pay.weixin.qq.com` | **优先**在 `<SKILL目录>/assets/微信支付官网文档/` 内用 `Grep`（URL 路径片段、文档标题、`doc` 路径、文档 ID 等）定位对应 `.md` 再 `Read`；知识库内**未找到**对应或等价文档时，可对该 URL 使用 `WebFetch` |

其他外链先询问用户是否联网。

---

## 检索与作答流程（必须按顺序）

> 建议顺序：**读索引、拟检索词** → **Grep 探路** → **缩小范围** → **聚焦 `Grep` / `Read`** → **作答**。

### 第一步：读索引、拟定检索词

1. 知识库结构以已加载的 `<SKILL目录>/assets/wechatpay-docs-guide.md` 为准，未在上下文则再 `Read`。
2. 沿用核心工作流已产出的意图、理解后的问题、角色与 API 版本；未定时按 [如何理解用户问题](./如何理解用户问题.md) 处理，需澄清则停在本轮。
3. 抽出 **1～3 个**探路 `pattern`：优先原文中的 URL、接口路径、错误码、字段名、产品官方名；给了官网链接或文档 ID 时取纯数字 `doc_id`。要具体可命中，避免单独搜「支付」这类过宽词。

### 第二步：Grep 探路

用已有 CLI 线索（及用户给出的 URL / 路径）校准 `Grep` 前缀；CLI 没给线索时在当前意图的检索路径上搜（答疑与排障为全树）。固定入口文件直接 `Read`。看路径与文件名是否对题、片段是否覆盖所问、落在哪些角色 / 版本分支：

- **足够 → 第三步**：至少 1 篇（对比类每分支各 ≥1 篇）值得精读，不为凑数继续搜。
- **不够 / 没搜到**：先在当前前缀换 `pattern`，或回退到意图起点再搜。
- **换方向**：路径明显不对题、或换词与回退仍无相关命中，就换检索目标（另一产品 / 角色 / 版本分支）重新 `Grep`。次数按 [硬性约束](#硬性约束) 第 6 条。

### 第三步：缩小范围

把第二步命中收到最相关的若干篇（一般 3～5 篇），再进第四步精读。路径明显相关即可，不必先读 `front matter`；命中分散时可用知识库指南目录树辅助，与 Grep 冲突时以更贴题的命中文件为准。角色与版本按 [如何理解用户问题](./如何理解用户问题.md#角色与-api-版本判定) 收敛，跨多侧则停下询问（对比类各侧都保留）。

仍不够则回第二步：先换词或回退起点，再不行才换方向。

### 第四步：聚焦 `Grep` / `Read`

方向已定，只在当前范围内缩小与精读。

1. 在第三步确定的前缀下，用更精确的 `pattern` 做聚焦 `Grep`。
2. `Read` 最相关的若干篇 `.md`（一般 3～5 篇），只读与问题相关的段落。
3. 同一文档 ID 可能存在请求示例副本，接口说明以**主文件**为准；示例代码文件仅在需要代码示例时 `Read`。

> **对比类问题**：每个分支至少各取 1 篇，篇数按分支数量按需增加，只读相关的、别大面积无关扫描。

### 第五步：作答

按 `SKILL.md` 当前意图的细则组织答案。默认答疑格式如下：

- **极简**：只答用户所问，先给结论或做法，再补必要细节；不扩背景、不复述检索、不贴文档原文。
- **可溯源**：每条结论都对应到已 `Read` 的知识库文件，或知识库未收录时经 `WebFetch` 取得的 `pay.weixin.qq.com` 正文（须在答案中注明来源 URL）。
- **「⚠️ 注意事项」**：仅直接踩坑风险时输出，无则省略整个段落。
- **「📋 相关文档」**（必须）：只列实际引用过的知识库文档，一般 3～5 条。列之前读这些文件的 `front matter`，标题和链接原样取 `title_display` / `url_display`，不改写、不拼接。

需查单时走动态排障。

#### 作答格式

```markdown
## [简短答案，直接回答用户问题]

### 📋 相关文档
- **{front matter title_display}**：{front matter url_display}
- ...（一般 3～5 条）

### ⚠️ 注意事项
- [注意点]
```

## 示例

**用户**：「合作伙伴 `APIv3` 合单 JSAPI 下单里 `sub_mchid` 怎么传？」

前提：`SKILL.md` 核心工作流已完成理解（角色「合作伙伴」、版本 `APIv3`、意图「答疑与排障」）与本轮 CLI search，拿到线索（产品「合单支付」、商户类型「服务商」、版本 `v3`）。以下都在本地完成。

1. 第一步：索引已在前置加载；沿用理解后的检索词 `sub_mchid`、`合单`、`JSAPI`。
2. 第二步：用 CLI search 的线索在 `APIv3/合作伙伴/` 下定向 `Grep`，观察命中路径（如 `APIv3/合作伙伴/支付产品/JSAPI合单支付/...`）是否覆盖 `sub_mchid`；不够就同前缀换更细或更宽的 `pattern`。
3. 第三步：结合已识别的角色 / 版本与命中分布，将精读范围收敛到 `APIv3/合作伙伴/支付产品`。
4. 第四步：在该前缀下聚焦 `Grep`，`Read` 最相关的若干篇 `.md`（按需）。
5. 第五步：按 `front matter` 的 `title_display` / `url_display` 生成回答。