docs: add SOP-016 执行前检索强制规则 + SOP-017 知识缺口上报SOP (BIZ-83/84)
This commit is contained in:
@@ -0,0 +1,194 @@
|
||||
# SOP-017：知识缺口上报 SOP
|
||||
|
||||
> **版本**: v1.0
|
||||
> **起草人**: 胡蓉（projectmanager）
|
||||
> **批准人**: 刘炜承
|
||||
> **生效日期**: 2026-07-06
|
||||
> **关联 Issue**: BIZ-82
|
||||
|
||||
---
|
||||
|
||||
## 1. 目的
|
||||
|
||||
解决 BIZ-45 巡检发现的全平台零知识缺口上报问题。各 Agent TOOLS.md 有"知识缺口记录"章节但无明确触发条件和上报流程，导致知识缺口被忽略、遗忘，长期影响任务交付质量。
|
||||
|
||||
---
|
||||
|
||||
## 2. 适用范围
|
||||
|
||||
全部 Agent（产研线 + 运营线 + 职能线），共 14 个。
|
||||
|
||||
---
|
||||
|
||||
## 3. 知识缺口定义
|
||||
|
||||
**知识缺口** = 执行任务时发现知识库（memory / wiki / 思源）中找不到的、且影响任务交付的知识。
|
||||
|
||||
### 属于知识缺口的情况
|
||||
|
||||
| # | 类型 | 示例 |
|
||||
|---|------|------|
|
||||
| 1 | 核心 SOP 缺失 | 没有淘宝上架 SOP，运营不知道怎么操作 |
|
||||
| 2 | 技术规范缺失 | 没有代码审查规范，开发不知道标准 |
|
||||
| 3 | 决策依据缺失 | 选型时缺乏对比数据，无法做出有依据的决策 |
|
||||
| 4 | 模板/指南缺失 | 没有 PRD 模板，每次手写格式不一致 |
|
||||
| 5 | 外部信息缺失 | 需要某个 API 文档但找不到 |
|
||||
|
||||
### 不属于知识缺口的情况
|
||||
|
||||
| # | 场景 | 应对方式 |
|
||||
|----|------|----------|
|
||||
| 1 | 可通过 web_search 快速获取的公开信息 | 自行检索 |
|
||||
| 2 | 可通过 memory_search / wiki_search 检索到的现有知识 | 自行读取 |
|
||||
| 3 | 可通过联系对应 Agent 获得的信息 | 直接联系 |
|
||||
| 4 | Agent 自身职责范围内的常识 | 不需上报 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 触发条件
|
||||
|
||||
执行 SOP-016（执行前检索）后，以下情况触发上报：
|
||||
|
||||
1. **检索无结果**: memory_search + wiki_search + 思源全文搜索均无匹配
|
||||
2. **检索结果不足以支撑决策**: 有部分信息但缺少关键环节
|
||||
3. **任务执行中发现缺少必要规范/模板/指南**: 执行中途发现被忽略的知识需求
|
||||
|
||||
---
|
||||
|
||||
## 5. 上报流程
|
||||
|
||||
```
|
||||
发现知识缺口
|
||||
↓
|
||||
Step 1: 记录 — 在 memory/当日日志.md 中记录缺口
|
||||
↓
|
||||
Step 2: 通知 — 通过 sessions_send 通知 COO（陆怀瑾）
|
||||
↓
|
||||
Step 3: 创建 Issue — 在 Gitea 仓库创建 Issue（标题格式：知识缺口-<领域>-<关键词>）
|
||||
↓
|
||||
Step 4: COO 审核 — COO 评估后决定：接受 / 拒绝 / 升级
|
||||
↓
|
||||
Step 5: 创建 WorkBoard 卡片 — COO 创建补全卡片，分配给合适的 Agent
|
||||
↓
|
||||
Step 6: 补全完成 — 补全 Agent 完成后通知上报 Agent + COO
|
||||
↓
|
||||
Step 7: 闭环 — COO 确认补全质量，关闭 Issue 和卡片
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 上报格式
|
||||
|
||||
### 6.1 memory 日志记录格式
|
||||
|
||||
在 `memory/YYYY-MM-DD.md` 中追加：
|
||||
|
||||
```markdown
|
||||
## 📚 知识缺口上报
|
||||
|
||||
**缺口类型**: [核心SOP缺失 | 技术规范缺失 | 决策依据缺失 | 模板/指南缺失 | 外部信息缺失]
|
||||
**缺口描述**: [具体缺什么，越详细越好]
|
||||
**使用场景**: [在做什么任务时发现的，为什么需要这个知识]
|
||||
**影响范围**: [哪些任务/Agent 受影响]
|
||||
**紧急程度**: [P0-阻塞当前任务 | P1-影响效率 | P2-改进建议]
|
||||
**建议补全方式**: [希望怎么处理——新建SOP/更新现有/外部采购等]
|
||||
**已执行的检索**: [列出已尝试的检索方式和query]
|
||||
**上报时间**: [YYYY-MM-DD HH:MM]
|
||||
```
|
||||
|
||||
### 6.2 通知 COO 的消息格式
|
||||
|
||||
通过 `sessions_send` 发送给 COO（sessionKey: `agent:coo:feishu:coo:direct:ou_9f73b4e54af59f038e2b754793ea0908`）：
|
||||
|
||||
```
|
||||
【知识缺口上报】
|
||||
类型: [缺口类型]
|
||||
描述: [缺口描述]
|
||||
场景: [使用场景]
|
||||
紧急: [P0/P1/P2]
|
||||
已记录: memory/YYYY-MM-DD.md
|
||||
请审核并决定是否创建补全卡片。
|
||||
```
|
||||
|
||||
### 6.3 Gitea Issue 格式
|
||||
|
||||
- **标题**: `知识缺口-<领域>-<关键词>`
|
||||
- **标签**: `knowledge-gap`
|
||||
- **描述**: 包含缺口类型、描述、使用场景、影响范围、紧急程度、建议补全方式
|
||||
|
||||
---
|
||||
|
||||
## 7. 优先级分级
|
||||
|
||||
| 优先级 | 定义 | 响应时限 | 补全时限 |
|
||||
|--------|------|----------|----------|
|
||||
| P0 | 阻塞当前任务，无法继续执行 | COO 4h 内响应 | 24h 内补全 |
|
||||
| P1 | 影响效率，有 workaround 但不理想 | COO 1 工作日内响应 | 3 工作日内补全 |
|
||||
| P2 | 改进建议，当前可正常运行 | COO 1 周内响应 | 按排期补全 |
|
||||
|
||||
---
|
||||
|
||||
## 8. COO 审核标准
|
||||
|
||||
COO 收到上报后，按以下标准审核：
|
||||
|
||||
| 审核项 | 标准 |
|
||||
|--------|------|
|
||||
| 是否真的缺口 | 上报人是否已充分检索（检查已执行检索记录） |
|
||||
| 是否属于知识缺口 | 对照第3节定义判断 |
|
||||
| 优先级是否合理 | 根据影响范围和紧急程度判断 |
|
||||
| 补全方式是否可行 | 评估建议的合理性 |
|
||||
|
||||
### 审核结果
|
||||
|
||||
| 结果 | 处理方式 |
|
||||
|------|----------|
|
||||
| **接受** | 创建 WorkBoard 补全卡片，分配给合适 Agent |
|
||||
| **拒绝** | 说明理由，告知上报人自行解决 |
|
||||
| **升级** | 转交承哥决策（涉及预算、外部采购等） |
|
||||
|
||||
---
|
||||
|
||||
## 9. TOOLS.md 注入模板
|
||||
|
||||
各 Agent 的 TOOLS.md 中需注入以下章节：
|
||||
|
||||
```markdown
|
||||
## 📚 知识缺口上报
|
||||
|
||||
> 完整 SOP 见 specs/SOP-017_知识缺口上报SOP.md
|
||||
|
||||
### 触发条件
|
||||
执行 SOP-016 检索后，以下情况需上报知识缺口：
|
||||
1. 核心业务数据/SOP/决策依据缺失
|
||||
2. 缺失影响任务交付质量或决策准确性
|
||||
3. 无法通过 memory_search / wiki_search 检索到
|
||||
|
||||
### 上报流程
|
||||
1. **记录**: 在 memory/当日日志.md 中记录缺口（标准格式见 SOP-017）
|
||||
2. **通知**: 飞书通知 COO（sessionKey: agent:coo:feishu:coo:direct:ou_9f73b4e54af59f038e2b754793ea0908）
|
||||
3. **创建 Issue**: Gitea 仓库创建 Issue（标题格式：知识缺口-<领域>-<关键词>）
|
||||
4. **跟进**: COO 评估后创建 WorkBoard 补全卡片
|
||||
5. **闭环**: 补全后 COO 通知可使用
|
||||
|
||||
### 标准格式
|
||||
[见 SOP-017 第6节]
|
||||
|
||||
### 不属于知识缺口的情况
|
||||
- 可通过 web_search 快速获取的公开信息 → 自行检索
|
||||
- 可通过 memory_search / wiki_search 检索到的现有知识 → 自行读取
|
||||
- 可通过联系对应 Agent 获得的信息 → 直接联系
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 10. 生效与维护
|
||||
|
||||
- **生效日期**: 2026-07-06
|
||||
- **维护人**: 胡蓉（projectmanager）
|
||||
- **revision 周期**: 每季度 review 一次，根据上报数据调整流程
|
||||
- **下次 review**: 2026-10-06
|
||||
|
||||
---
|
||||
|
||||
*本 SOP 由 projectmanager 胡蓉起草，经刘炜承批准后生效。*
|
||||
Reference in New Issue
Block a user