214 lines
10 KiB
Markdown
214 lines
10 KiB
Markdown
---
|
||
title: 万师傅业务知识库（biz）— 分层原则与使用说明
|
||
source_status: 2026-07-31 基于三层知识模型完全重写，替代此前按"抽/不抽"二元判断的旧版本
|
||
---
|
||
|
||
# 这个知识库是什么
|
||
|
||
给**大模型**用的万师傅业务知识底座。目标是让模型在没有任何人解释的情况下，
|
||
理解万师傅的业务模式、运转逻辑、概念体系和专业术语，从而能正确地取数、答疑、判断、写代码。
|
||
|
||
人读是附带收益，不是设计目标——**当"给模型用"和"给人读"冲突时，以模型为准**。
|
||
|
||
---
|
||
|
||
# 一、核心：知识的三层模型
|
||
|
||
这是本知识库最重要的组织原则。所有"收不收、放哪、怎么写"的问题，都先回到这三层。
|
||
|
||
## 三层定义
|
||
|
||
| 层 | 名称 | 装什么 | 判定标准 |
|
||
|---|---|---|---|
|
||
| **L1** | 业务本质（根级） | 业务的世界观、前提、底层逻辑 | 从业者视为空气、从不言说，但**答错会让整条推理链歪掉** |
|
||
| **L2** | 概念体系（二级） | 有明确定义的名词、术语、实体、关系 | 需要被精确定义、跨场景复用、**容易混淆** |
|
||
| **L3** | 规则与口径（三级） | 有条件、有数值、可执行的判定规则 | 回答"具体怎么算/怎么判"，**有明确的权威归属方** |
|
||
|
||
**根级的识别测试**：老员工觉得"这还用说？"、新人问了会被当成傻问题，但答错后面全错。
|
||
典型例子——"师傅不是万师傅的员工"。没人会想到要写这句，但模型如果默认师傅是员工，
|
||
就会去问"师傅的绩效考核"，无法理解为什么要收保证金、为什么是"清出平台"而不是"辞退"。
|
||
|
||
## 三层的三个关键性质
|
||
|
||
理解这三条，比记住分层本身更重要。
|
||
|
||
### 性质 1 · 三层是"解释链"，不是重要性排序
|
||
|
||
向下是展开，向上是溯因。**每条 L2 概念都应能挂到某条 L1 之下，每条 L3 规则都应能挂到某条 L2 之下。**
|
||
|
||
由此得到两个可操作的推论：
|
||
|
||
- **挂不上去的知识是可疑的**：要么是孤儿内容该删，要么暴露了一条缺失的 L1/L2
|
||
- **可以用 L3 反向发现 L1**：问"为什么要收保证金？"→ 因为师傅是自主经营个体、平台无法用雇佣关系约束 → 挖出一条 L1
|
||
|
||
第二条是**补全根级的主要方法**。因为根级知识没法正面问——直接问"你们的商业模式是什么"，
|
||
业务方只会给你一段官网文案。拿一条具体规则追问"为什么"，追问两三层，才能挖到真正的前提。
|
||
|
||
### 性质 2 · 三层的生产方式完全不同
|
||
|
||
| 层 | 怎么获得 | 能否靠抽取 |
|
||
|---|---|---|
|
||
| L1 | 访谈、口述 **或从 L3 反向溯因** | ⚠️ 不能直接抽——从来没人正面写过；但能**间接反推** |
|
||
| L2 | 领域文档抽取 + 架构师确认 | ✅ 可以直接抽 |
|
||
| L3 | 指向权威文档 | ⚠️ **不该抽**——该做索引 |
|
||
|
||
这解释了一个实测结果：从 7 个来源（含两个部门级知识库、87MB 客服资料、官网）做**正面抽取**，
|
||
产出的内容几乎全是 L2——因为只有 L2 被人写下来过。
|
||
|
||
但 L1 并非完全够不着。**反向溯因是可行路径**：材料里的具体规则（L3）本身不进知识库，
|
||
但追问"为什么会有这条规则"，往往能反推出从没被写下的 L1。
|
||
|
||
> **实证**：从"免责次数""申诉机制""新师傅从轻处理"三条规则反推，
|
||
> 得到 L1 §9「治理力度受供给留存约束」——这条在任何文档里都找不到正面表述。
|
||
|
||
所以：**想补 L1 靠访谈或反向溯因，想补 L3 应该做索引，正面抽取只会得到更多 L2。**
|
||
|
||
### 性质 3 · 三层的加载方式不同（这是必须物理分文件的硬理由）
|
||
|
||
| 层 | 加载策略 | 体量约束 |
|
||
|---|---|---|
|
||
| L1 | **常驻上下文**（整份进 system prompt） | 必须短，**上限约 2000 字** |
|
||
| L2 | 按需检索（术语表式） | 可以长，但要条目化、便于检索 |
|
||
| L3 | 按需检索，且必须带时效标记和权威链接 | 只存索引，不存副本 |
|
||
|
||
如果三层混在一个文件里，L1 就无法常驻——不可能为了让模型知道"师傅不是员工"，
|
||
把整个规则库塞进 system prompt。**这是分层必须落到物理文件上的原因，不只是分类整齐。**
|
||
|
||
**L1 超出字数预算时怎么办**（按顺序判断，不要直接放宽）：
|
||
|
||
1. 先查是否混进了 L2 —— 有则下沉，这是最常见的原因
|
||
2. 确认全是真 L1 但仍超标 → 逐条重新过"答错会不会让整条推理链歪掉"，删掉只是"重要"但不致命的
|
||
3. 两步之后仍超 → 可放宽至 2500 字，但**硬上限 3000**，再多就失去常驻可行性了
|
||
|
||
### 性质 4 · 框架是发现工具，不只是整理工具
|
||
|
||
同一份材料，用不同框架去读，产出可以差一个数量级。
|
||
|
||
> **实证**：客服 SOP 合集按"抽 / 不抽"的二元标准读，只抽出 3 条；
|
||
> 引入三层模型后重读**同一个压缩包**，抽出一整块 L2（工单与治理体系）加一条 L1（治理边界）。
|
||
|
||
**推论：框架升级后，应当重扫已经抽取过的来源。**
|
||
"这个源已经抽过了"不构成跳过它的理由——判断标准变了，同一份材料的价值也随之改变。
|
||
|
||
---
|
||
|
||
# 二、判定流程
|
||
|
||
新知识进来时，按顺序走：
|
||
|
||
```
|
||
Q1: 模型能从代码 / DDL / 官网自己推出来吗？
|
||
能 → 不收（不要浪费上下文预算）
|
||
不能 → Q2
|
||
|
||
Q2: 它是"前提"、"名词"还是"规则"？
|
||
从业者从不言说的前提，答错整条链歪掉 → L1
|
||
需要精确定义、容易混淆的名词/实体/关系 → L2
|
||
有条件、有数值的可执行判定规则 → L3
|
||
|
||
Q3: 它能挂到上一层的哪一条之下？
|
||
挂不上 → 停下：要么这条该删，要么上一层缺了东西，先补上一层
|
||
|
||
Q4（仅 L3）: 数值会变吗？
|
||
会 → 只登记"有这条规则 + 归谁管 + 权威文档在哪"，不内嵌数值
|
||
不会 → 可内嵌
|
||
```
|
||
|
||
## 明确不收的内容
|
||
|
||
| 不收 | 为什么 |
|
||
|---|---|
|
||
| 工程实现细节（字段枚举、幂等键、分片规则、金额单位） | 属于技术约定，不是公共业务知识；应在技术知识库 |
|
||
| 系统集成模式（MQ 链路、回调、重试） | 同上 |
|
||
| 工作方法论、SOP（怎么澄清需求、怎么处理工单） | 属于协作方式，不描述业务本身 |
|
||
| 具体运营参数的副本（费用标准、扣分阈值） | 会腐坏。**登记它存在，链接到权威源，但不抄数值** |
|
||
| SQL / 表结构 | `../bd/` 的职责 |
|
||
| 运营指标、荣誉、营销文案 | 变化快且无推理价值 |
|
||
|
||
**关于腐坏**：短半衰期内容的问题不是"不重要"，而是**不能和长半衰期内容混放**——
|
||
读者无法分辨哪部分还有效，就会连带不信整个知识库。这是 L3 只做索引的根本原因。
|
||
|
||
各层的半衰期参考：L1 约 5-10 年（变了就是公司转型）、L2 约 1-5 年、L3 约 1 月-1 年。
|
||
|
||
---
|
||
|
||
# 三、目录结构
|
||
|
||
```
|
||
wiki/biz/
|
||
├── README.md 本文件 —— 分层原则与判定流程
|
||
├── L1-essence.md 根级：业务本质（常驻上下文，≤2000字）
|
||
├── L2-concepts.md 二级：概念体系（按需检索）
|
||
├── L3-rules-index.md 三级：规则索引（只索引，不内嵌数值）
|
||
└── _golden-questions.md 治理文件：完备性度量清单
|
||
```
|
||
|
||
`_` 前缀 = 治理文件，不是知识内容本身。
|
||
|
||
**新增知识前先问**：它能让 [_golden-questions.md](_golden-questions.md) 里的哪个问题
|
||
从答不出变成答得出？答不上来的内容，大概率不该收。
|
||
|
||
---
|
||
|
||
# 四、怎么用：加载配方与库间边界
|
||
|
||
## 各消费场景该加载什么
|
||
|
||
| 消费场景 | 加载 |
|
||
|---|---|
|
||
| 通用业务问答 / 新人 onboarding | **L1（常驻）** + L2 按需检索 |
|
||
| 取数 / 分析 Agent | **L1** + L2 + `../bd/` 全量 |
|
||
| 客服 / 风控 Agent | **L1** + L2 + L3 索引（据索引再去查权威源拿数值） |
|
||
| 编码 / 架构 Agent | **L1** + L2 + 对应系统的技术知识库 |
|
||
|
||
**L1 在所有场景都常驻**——它是理解其他一切的前提，不存在"这个场景不需要 L1"的情况。
|
||
|
||
## 与 `../bd/` 的边界
|
||
|
||
| 知识库 | 职责 |
|
||
|---|---|
|
||
| `biz/`（本库） | 业务事实：本质、概念、规则索引 |
|
||
| `../bd/` | 数仓、SQL、取数口径、表结构 |
|
||
|
||
**两库文件间不互相链接**，各自独立演进。但独立 ≠ 不能同时使用——见上面的加载配方。
|
||
|
||
两库在概念层出现互相印证是**好事**，说明知识是自洽的。例如 `bd/` 中
|
||
`penalty_sheet.business_type` 的枚举值（超时预约/超时签到/拒绝服务），
|
||
正好对应本库 L2 §7.4 记录的四个系统自动判罚节点——这类交叉验证应当记录，但仍不建立文件链接。
|
||
|
||
---
|
||
|
||
# 五、来源与维护
|
||
|
||
## 已抽取来源
|
||
|
||
| 来源 | 贡献层级 | 说明 |
|
||
|---|---|---|
|
||
| 业务方访谈 | **L1** | 产出根级知识最直接的途径 |
|
||
| 客服工单 SOP 与对外规则合集 | **L1** / L2 / L3 | 工单与治理体系全套概念；治理边界（反向溯因所得）；大量规则进 L3 索引 |
|
||
| 官网 [wanshifu.com](https://www.wanshifu.com/) | L1 / L2 | 交易模式、服务矩阵、保障体系 |
|
||
| 履约配置化 PRD、违规拒单 prompt | L1 / L2 | 履约骨架、非标性、TOC/TOB 结构 |
|
||
| `payment/ai-knowledge`（支付/风控等 8 系统） | L2 | 资金域概念。**⚠️ 按旧标准抽取，值得用三层框架重扫** |
|
||
| `dev-knowledge-base`（营销中台 15 服务） | L2 | 角色术语。**⚠️ 同上，值得重扫** |
|
||
| `../bd/` | L2 | 业务域缩写 |
|
||
|
||
抽取后即与源脱钩、独立维护，来源仅供溯源。
|
||
|
||
## 维护约定
|
||
|
||
- 只维护"当前有效状态"，改了直接覆盖，版本历史交给 git
|
||
- 每条内容标注来源
|
||
- **框架或判定标准变更后，重扫已抽取过的来源**（性质 4）——上表已标注待重扫的源
|
||
- L1 超过预算 → 按"性质 3"里的三步判断，不要直接放宽上限
|
||
- L3 出现具体数值副本 → 检查是否该改成链接
|
||
- 发现某条内容挂不到上一层 → 按性质 1 处理，别硬留
|
||
|
||
## ❓ 标记的生命周期
|
||
|
||
推测性内容必须标 ❓ 并注明"待确认"，**未确认前不得当作事实使用**。
|
||
|
||
- **只能由业务方确认后摘除**——不能因为"看起来合理""和其他材料不矛盾"就自行转正
|
||
- 确认后：去掉 ❓，在来源表注明"业务方访谈 + 日期"
|
||
- **长期无人确认的 ❓ 应保留，不要删**——它标记了一个已知缺口，
|
||
比假装没这回事强；`_golden-questions.md` 会把它计入缺口统计
|