# KB建设方法论指导书
**适用对象：SAP资深专家（产品KB）/ SAP项目经理（项目KB）**
**版本：v1.0 | 日期：2026-06-09**

---

## 写在前面：为什么要建KB，KB是什么

AI在回答SAP问题时有两类严重错误：
1. **编造功能**：说某个功能"支持"，实际上不在公有云范围内
2. **编造ID**：给出根本不存在的Scope Item编号

KB（知识库）的作用是**用官方事实锁住AI的输出边界**——AI不再凭"印象"回答，而是从KB中查找事实再输出。

> KB不是培训材料，不是用户手册，不是文档仓库。
> **KB是AI的外挂大脑，专门存放AI容易答错的那部分内容。**

---

## 第一部分：通用方法论（产品KB和项目KB都适用）

### 七条建设原则

在动手写任何文件之前，必须逐条回答以下七个问题：

---

#### 原则一：明确目的

**问自己：这个KB是给谁用的，在什么时刻打开它，解决什么具体问题？**

| 要回答的问题 | 示例：SA产品KB | 示例：项目KB |
|------------|--------------|------------|
| 用户是谁？ | Solution Architect（售前顾问） | 实施顾问、项目经理 |
| 什么时候用？ | 客户问"2602支不支持XX功能" | 项目执行中查"这个配置我们决定怎么做" |
| 解决什么问题？ | 快速准确给出Scope Item选型建议 | 防止团队成员重复问同一个问题、遗忘已有决策 |

**目的不清晰 → 内容边界不清晰 → 什么都往里塞 → AI不知道该信哪部分**

---

#### 原则二：依赖关系双向映射

**问自己：这个KB依赖哪些其他KB？建完后哪些KB会依赖它？**

画出依赖关系图，再开始动工：

```
示例：
SAP产品KB（SA KB）
    ↓ 被依赖
SAP顾问KB（SC KB）← 继承产品KB的Scope Item目录和功能边界
    ↓ 被依赖
项目KB-A / 项目KB-B ← 继承产品KB的事实，叠加客户专属决策
```

**关键规则：下层KB不重建上层KB已有的内容，只叠加自己独有的部分。**

如果两个KB里有重复内容，维护时一定会漂移——A更新了，B忘了更新，结果AI同时读到两个版本产生矛盾。

---

#### 原则三：锚定源头文档，明确其权威性边界

**问自己：这个KB里每一条内容，来自哪份官方文档的哪个章节？**

不同来源的权威性不同：

| 来源 | 权威性 | 适用内容 |
|-----|-------|---------|
| SAP官方FSD（功能说明文档） | ★★★★★ | 功能是否存在、有什么限制 |
| SAP官方Scope Item目录 | ★★★★★ | Scope Item ID和名称 |
| SAP官方E2E最佳实践PDF | ★★★★☆ | 流程步骤、业务价值数据 |
| 顾问项目经验 | ★★★☆☆ | 判断逻辑、选型建议 |
| 会议纪要、客户决策记录 | ★★★★★（项目内） | 项目专属事实 |
| AI自己补充的内容 | ★☆☆☆☆ | **不允许作为KB内容** |

> **原则：没有官方来源的内容，不放进产品KB。**
> **项目KB的来源是会议纪要和客户签字文件，不是顾问的"印象"。**

---

#### 原则四：定义KB单元和颗粒度

**问自己：一个文件应该装多少内容？**

判断标准：**一个文件 = 一次典型查询所需的全部上下文，不多不少。**

| 问题 | 判断 |
|-----|------|
| 这两段内容经常被同时引用吗？ | 是 → 放同一文件；否 → 可以分开 |
| 这个文件超过5000字了吗？ | 是 → 考虑拆分，但每个子文件必须能独立回答问题 |
| 这段内容只是另一个文件的重复？ | 删掉，用引用代替 |

**常见错误：把所有文档都导入作为KB**
→ 文件太多太大，AI找不到关键内容，反而答错
→ 正确做法：提取，而不是导入

---

#### 原则五：设计元导航层和Agent行为规则

**问自己：AI怎么知道去哪个文件找答案？多个KB并存时，AI怎么知道信哪个？**

每个KB必须有一个**导航文件**（类似目录），告诉AI：
- 这个KB有哪些文件
- 每个文件回答什么类型的问题
- 遇到不同类型的问题，先查哪个文件

多个KB并存时，还需要一个**元导航层**，定义：

| 需要定义的规则 | 示例 |
|------------|-----|
| 问题路由规则 | 产品功能问题 → 产品KB；客户决策问题 → 项目KB |
| 权威优先级 | 项目KB > 产品KB（客户的实际决定优先于产品默认） |
| 冲突处理规则 | 两个KB答案不同时，优先采信哪个，并说明原因 |

**Agent行为规则**（写进System Prompt）定义AI的行为边界，例如：
- "没有在KB中找到来源，必须说'KB未覆盖'，不得推断"
- "Scope Item ID必须来自KB目录，不得自行编写"
- "项目KB的内容优先于产品KB，但项目KB不覆盖的功能边界问题，必须查产品KB"

---

#### 原则六：用多AI交叉验证建立验收题库

**问自己：怎么证明这个KB是好用的？**

不依赖"更懂的人"来验收，而是用**多个AI互相对打**的方式发现问题：

```
第一步：出题
  → 覆盖该KB的核心场景，必须包含：
    · 陷阱题（常见错误答案，测试KB能否纠正AI）
    · 反向陷阱题（常识性错误，测试KB能否守住正确结论）
    · 边界题（超出KB范围的问题，测试AI能否正确说"不知道"）

第二步：对打
  → AI-A（带KB）回答
  → AI-B（带KB）回答
  → AI-C（不带KB）回答
  → 比较三者答案：分歧处是问题所在，共识处增加信心

第三步：锚定
  → 对所有AI一致同意的答案：追溯到官方文档章节
    · 找到引用 → 确认为"硬答案"，可作为验收标准
    · 找不到引用 → 标注为"软答案"，暂不作为扣分依据，持续验证

第四步：更新
  → 发现KB有误 → 修正KB
  → 发现题目答案有误 → 修正题库
  → 题库和KB同步进化
```

> **验收不是一次性动作，而是持续运行的循环。**
> **AI对打发现的问题既是KB的问题，也是题库本身的问题。**

---

#### 原则七：指定Owner和更新触发机制

**问自己：这个KB建完之后，谁负责它不过时？**

没有Owner的KB不应该上线。上线前必须明确：

| 需要定义 | 产品KB示例 | 项目KB示例 |
|---------|----------|----------|
| Owner是谁 | 指定的SAP资深顾问 | 项目经理 |
| 什么事件触发必须更新 | SAP发布新版本；发现KB有误 | 蓝图决策变更；配置选择更改；里程碑完成 |
| 更新流程 | 修改 → 交叉验证 → 发布 | 记录决策 → 更新KB文件 → 通知团队 |
| 退役条件 | 新版本KB上线后归档 | 项目收尾后归档，不再更新 |

---

## 第二部分：产品KB建设指南（SAP资深专家适用）

### 你的任务

把SAP官方文档里关于某个产品/版本的核心知识，结构化地提取成AI可以检索的文件集合，让AI能准确回答售前和实施顾问的产品问题。

### 原始材料清单（动工前必须备齐）

| 材料 | 哪里获取 | 对应KB层 |
|-----|---------|---------|
| FSD（功能说明文档，按版本号） | SAP官方发布 | 功能边界层 |
| Scope Item官方目录（Excel/CSV） | SAP官方发布 | Scope Item层 |
| E2E最佳实践文档（L2C/S2P/P2F等） | SAP官方发布 | 架构层 |

**检查**：拿到材料后先确认版本号一致，Scope Item格式是2-4位字母数字（如`J58`），不是`1.1.1`这类格式。

### 文件架构（参考2602 KB的验证模型）

```
【架构层】  E2E选型判断树 + 业务价值数据     ← 选型首选入口
    ↓
【流程层】  系统操作步骤 + 凭证流             ← 操作指引
    ↓
【Scope Item层】  ID + 名称 + 依赖关系        ← ID权威来源
    ↓
【功能边界层】  功能有无 + 限制（来自FSD）     ← 功能权威来源
```

加一个**导航文件**（告诉AI各文件定位和查询路由），合计约25-30个文件。

### 产品KB特有的质量红线

- Scope Item ID必须来自官方目录，格式必须是2-4位字母数字
- FSD中标注"不支持"或"仅限On-Premise"的功能，必须在KB中明确标注，不得省略
- 不同文件引用同一个Scope Item时，名称必须完全一致
- 跨文件引用必须用完整文件名，不能用缩写（如不能写"参见P2F"，必须写"参见P2F_11_Plan_Manufacturing.md §3.2"）

### 验收题库设计要点

产品KB的题目必须覆盖：
- 该产品版本的**功能边界**（这个版本有没有XX功能）
- **Scope Item选型**（这个场景需要哪些ID）
- **陷阱场景**（把On-Premise功能包装成公有云功能的问法）
- **版本边界**（问下一个版本的新功能，AI应该说"超出本KB范围"）

---

## 第三部分：项目KB建设指南（SAP项目经理适用）

### 你的任务

把项目执行过程中产生的客户专属决策、配置选择、未决问题，结构化地记录成AI可以检索的文件集合，让项目团队成员不用重复问同样的问题，也不会遗忘已经做过的决定。

### 项目KB和产品KB的根本区别

| 维度 | 产品KB | 项目KB |
|-----|-------|-------|
| 内容来源 | SAP官方文档 | 会议纪要、客户决策、配置文件 |
| 更新频率 | 跟随SAP版本（季度级） | 跟随项目里程碑（周级） |
| 内容生命周期 | 长期有效 | 随项目阶段变化（蓝图决策在上线后可能失效） |
| 权威来源 | FSD章节 | 客户签字的决策文件 |
| 退役时机 | 新版本上线时 | 项目收尾时 |

### 项目KB应该记录什么

**放入项目KB的内容**：
- 客户做出的配置选择（"该客户选择了集中采购，而非分散采购"）
- 项目范围内/外的决定（"本次实施不包含EWM，仅用基础库存管理"）
- 未决问题和待确认事项（带时间戳和负责人）
- 关键集成接口的约定
- 测试中发现并修复的问题

**不放入项目KB的内容**：
- 产品功能描述（这是产品KB的职责，直接引用）
- 顾问的推测和建议（这是意见，不是事实）
- 每次会议的完整记录（太多，AI找不到关键内容）

### 项目KB的文件结构建议

| 文件 | 内容 | 更新时机 |
|-----|------|---------|
| `项目概况.md` | 客户基本信息、实施范围、关键干系人 | 项目启动时建立，有变更时更新 |
| `蓝图决策记录.md` | 每个模块的关键配置选择，格式：决策+原因+日期+负责人 | 每次蓝图确认会后更新 |
| `未决问题清单.md` | 尚未确认的配置项，带状态（未决/已决/已关闭） | 每周更新 |
| `集成约定.md` | 与第三方系统的接口约定 | 接口设计阶段建立 |
| `测试问题记录.md` | UAT/SIT发现的问题及解决方案 | 测试阶段更新 |

### 项目KB特有的质量红线

- 每条决策必须注明**日期、负责人、决策依据**（会议纪要编号或邮件）
- 未决问题必须有状态标注，已决的必须及时更新
- 项目KB不允许包含产品功能判断（"这个功能2602支不支持"），这类问题指向产品KB
- 项目收尾时，PM必须做一次KB清理：过时内容归档，有效内容整理成"项目交接手册"

### 项目KB的验收方式

项目KB的验收不依赖Scope Item题目，而是用**真实项目场景**测试：

- 把实际发生过的三个典型团队提问，让AI用项目KB回答
- 对比AI的回答和实际决策记录，是否一致
- 特别测试：问一个"超出项目KB范围"的问题，AI应该指向产品KB而不是自行推断

---

## 第四部分：快速检查清单

### 建设前必须回答（7条原则对应）

- [ ] 这个KB给谁用？在什么场景下打开？解决什么问题？
- [ ] 它依赖哪些KB？哪些KB会依赖它？
- [ ] 每条内容的权威来源是什么文档的哪个章节？
- [ ] 一个文件装多少内容合适？单文件是否超过5000字？
- [ ] AI怎么知道去哪个文件找答案？多KB并存时信哪个？
- [ ] 有没有验收题库？题目有没有覆盖陷阱场景？
- [ ] Owner是谁？什么事件触发必须更新？

### 上线前必须通过的验收红线

- [ ] 所有AI版本在陷阱题上答案一致且正确
- [ ] 回答中无任何格式异常的ID（产品KB专用）
- [ ] 问超出KB范围的问题时，AI能正确说"超出范围"而不是推断
- [ ] 至少两个不同AI用相同KB给出高度一致的核心答案

---

## 附录：本方法论的来源

本指导书基于以下实践经验提炼：
- SAP S/4HANA Cloud Public Edition 2602 KB建设全程（5层26文件，System Prompt v1.67）
- 20题Benchmark双KB对比评测（两份KB各独立评分）
- 7条原则通过结构化推演逐步验证，非凭空提出

参考文件（均在同一目录下）：
- `KB_建设最佳实践_v1.0.md` — 2602 KB的技术复制手册
- `KB_团队内部文档_v1.0.md` — 2602 KB的架构详解和踩坑记录
- `BOS_SA_Agent_Benchmark_v1.0.md` — 完整验收题库（含答案和评分标准）
- `SYSTEM_PROMPT_Agent1_v1.67.md` — Agent行为规则模板

---

*KB建设方法论指导书 v1.0 | 2026-06-09*
*基于BOS SAP CE2602建设经验及结构化方法论推演*
