10 KiB
title, source_status
| title | source_status |
|---|---|
| 万师傅业务知识库（biz）— 分层原则与使用说明 | 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 超出字数预算时怎么办（按顺序判断，不要直接放宽）：
- 先查是否混进了 L2 —— 有则下沉，这是最常见的原因
- 确认全是真 L1 但仍超标 → 逐条重新过"答错会不会让整条推理链歪掉"，删掉只是"重要"但不致命的
- 两步之后仍超 → 可放宽至 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 里的哪个问题 从答不出变成答得出？答不上来的内容，大概率不该收。
四、怎么用：加载配方与库间边界
各消费场景该加载什么
| 消费场景 | 加载 |
|---|---|
| 通用业务问答 / 新人 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 | 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会把它计入缺口统计