8D (Eight Disciplines) 是一种结构化的问题解决方法，由福特汽车公司开发，广泛应用于质量管理和问题解决。
学习时间: 2026-04-10
适用范围: 量化团队全体成员 (Master, Radar, Analyst, Risk, Coder)
| 任务 | 输出 |
|---|---|
| ------ | ------ |
| 识别问题 | 问题清单 |
| 收集初步数据 | 数据摘要 |
| 确定是否需要 8D | 决策记录 |
| 任务 | 输出 |
|---|---|
| ------ | ------ |
| 组建跨职能团队 | 团队成员列表 |
| 确定角色 | 角色分工表 |
| 明确目标 | 项目章程 |
| 要素 | 问题 | 示例 |
|---|---|---|
| ------ | ------ | ------ |
| What | 什么问题？ | 数据下载失败 |
| Who | 谁发现/影响谁？ | Radar 发现，影响 Analyst |
| When | 何时发生？ | 2026-04-08 15:30 |
| Where | 何地发生？ | 数据下载脚本 |
| Why | 为什么重要？ | 影响策略分析 |
| How | 如何发现？ | 任务失败警报 |
| How much | 问题规模？ | 1 天数据缺失 |
| 任务 | 输出 |
|---|---|
| ------ | ------ |
| 立即保护客户 | 临时方案 |
| 隔离问题 | 影响范围界定 |
| 防止扩大 | 遏制措施 |
| 验证有效性 | 验证记录 |
| 工具 | 用途 | 输出 |
|---|---|---|
| ------ | ------ | ------ |
| 5Why | 连续追问到根因 | 根因链 |
| 鱼骨图 | 原因分类 | 原因树 |
| 数据验证 | 确认根因 | 验证报告 |
5Why 正确示例（必须追问到真正的根因）:
问题：4 月 1-7 日数据量异常（7000+ vs 5500）
1Why: 为什么数据量异常？
→ 有重复记录，同一只股票有 2 条数据
2Why: 为什么有重复记录？
→ 股票代码格式不统一（000001 和 000001.SZ 同时存在）
3Why: 为什么有两种格式？
→ 历史数据下载脚本没有统一格式要求
4Why: 为什么脚本没有统一格式？
→ 脚本设计时未考虑格式验证和标准化
5Why: 为什么未考虑格式验证？
→ 没有数据质量标准文档和代码审查流程 ← 真正的根因
关键: 5Why 必须追问到系统性根因（流程/规范缺失），而不是停留在技术层面。
| 任务 | 输出 |
|---|---|
| ------ | ------ |
| 制定方案 | 方案列表 |
| 评估可行性 | 评估报告 |
| 选择最佳方案 | 决策记录 |
| 验证有效性 | 验证结果 |
验证不是当下的验证，而是验证下次是否还会发生：
| 验证类型 | 说明 | 示例 |
|---|---|---|
| ---------- | ------ | ------ |
| 当下验证 | 修复是否成功 | 修复后数据量正常 ❌ 这不是 D6 |
| D6 验证 | 下次是否还会发生 | 运行新数据下载任务，检查是否还有格式问题 ✅ |
D6 验证方法:
| 任务 | 输出 | 说明 |
|---|---|---|
| ------ | ------ | ------ |
| 更新标准/流程 | 修订文档 | 形成文件化规范 |
| 培训人员 | 培训记录 | 确保所有人理解 |
| 水平展开 | 展开清单 | 排查类似问题 |
| 建立预警 | 预警规则 | 提前发现问题 |
D7 核心要求:
| 任务 | 输出 |
|---|---|
| ------ | ------ |
| 总结经验 | 经验教训 |
| 表彰团队 | 表彰记录 |
| 归档报告 | 8D 报告 |
| 分享实践 | 知识库更新 |
| 场景 | 触发条件 | 主导 Agent |
|---|---|---|
| ------ | ---------- | ------------ |
| 数据质量问题 | 数据异常、重复、缺失 | Radar |
| 策略失效 | 策略连续亏损>3 次 | Analyst |
| 系统故障 | 任务失败、Gateway 异常 | Coder |
| 风控事件 | 止损触发、回撤>10% | Risk |
| Boss 指令 | Boss 要求用 8D 分析问题 | Master |
# 8D 报告 | [问题名称]
**报告日期**: YYYY-MM-DD
**团队负责人**: [Agent]
**状态**: D0/D1/D2/D3/D4/D5/D6/D7/D8
---
## D0: 准备
- 问题描述:
- 数据来源:
- 8D 必要性:
## D1: 团队
| 角色 | Agent | 职责 |
|------|-------|------|
| 负责人 | | |
| 成员 | | |
## D2: 问题描述 (5W2H)
| 要素 | 描述 |
|------|------|
| What | |
| Who | |
| When | |
| Where | |
| Why | |
| How | |
| How much | |
## D3: 临时措施
| 措施 | 状态 | 验证 |
|------|------|------|
| | ✅/❌ | |
## D4: 根因分析
**5Why 分析**（必须追问到系统性根因）:
问题：[问题描述]
1Why: [追问 1] → [答案 1]
2Why: [追问 2] → [答案 2]
3Why: [追问 3] → [答案 3]
4Why: [追问 4] → [答案 4]
5Why: [追问 5] → [根因] ← 必须是流程/规范层面
**根因确认**: [根因描述]
## D5: 永久措施
| 方案 | 可行性 | 选择 |
|------|--------|------|
| | | ✅/❌ |
## D6: 实施验证
**验证方法**（验证下次是否还会发生）:
- 验证时间:
- 验证方式:
- 验证结果: ✅ 通过 / ❌ 失败（返回 D4）
## D7: 预防再发
| 措施 | 状态 | 输出文件 |
|------|------|----------|
| 流程更新 | | |
| 规范文档 | | |
| 水平展开 | | 排查清单 |
| 人员培训 | | 培训记录 |
| 预警机制 | | 监控规则 |
## D8: 总结
- 经验教训:
- 团队表彰:
- 归档位置:
| 周次 | 日期 | 学习内容 | 实践案例 | 确认 |
|---|---|---|---|---|
| ------ | ------ | ---------- | ---------- | ------ |
| 第 1 周 | 2026-04-10 | 8D 流程、5W2H、5Why | 数据质量问题修复（重新分析） | ⏳ |
| 第 2 周 | 2026-04-17 | D3-D4 临时措施、根因分析 | 待应用 | ⏳ |
| 第 3 周 | 2026-04-24 | D5-D6 永久措施、实施验证 | 待应用 | ⏳ |
| 第 4 周 | 2026-05-01 | D7-D8 预防再发、团队表彰 | 待应用 | ⏳ |
完成条件: 4 次学习 + 4 个实际应用案例 → 关闭学习任务
| 8D 步骤 | 正确应用内容 |
|---|---|
| --------- | ---------- |
| D0 准备 | Boss 发现 4 月 1-7 日数据量异常（7000+ vs 5500），决定启动 8D |
| D1 团队 | Master(主导) + Radar(数据) + Coder(脚本) |
| D2 问题描述 | 4 月 1-7 日数据量比正常多约 2000 条/天，影响数据分析准确性 |
| D3 临时措施 | 暂停使用 4 月 1-7 日数据进行分析，等待修复 |
| D4 根因分析 | 5Why 分析: 1Why: 为什么数据量异常？→ 有重复记录 2Why: 为什么有重复？→ 同一只股票有 2 条（000001 和 000001.SZ） 3Why: 为什么有两种格式？→ 历史脚本未统一格式 4Why: 为什么未统一？→ 脚本设计无格式验证 5Why: 为什么无验证？→ 没有数据质量标准文档和代码审查流程 ← 根因 |
| D5 永久措施 | 1. 统一所有股票代码为带后缀格式 2. 数据下载脚本增加格式验证 3. 建立数据质量标准文档 |
| D6 实施验证 | 验证下次是否还会发生: - 等待 2026-04-11 数据下载任务执行 - 检查新数据是否还有格式问题 - 如果还有 → 根因没找对，返回 D4 - 如果没有 → 根因正确，继续 D7 |
| D7 预防再发 | 1. 形成文件: 《数据质量标准规范》 2. 流程更新: 脚本代码审查流程 3. 水平展开: 排查所有数据处理脚本 4. 人员培训: 团队数据规范培训 5. 预警机制: 每日数据量监控告警 |
| D8 总结 | 经验：数据质量必须从源头控制，建立标准和审查流程 |
状态: ⏳ D6 验证中（等待 2026-04-11 数据验证）
技能版本: 2.0
更新日期: 2026-04-10
评审周期: 每周一次，4 次后关闭
共 1 个版本