---
name: flywhlway/dtc-root-cause
source: https://app.decimal.ai/s/flywhlway-dtc-root-cause@1/SKILL.md
source_sha256: d6dd4f01d347
---

# DTC 根因分析

多码并发时找出**首发根源码**，把伴生码从处置清单里剥离。
核心方法：**时序 + 拓扑 + 电源域三重证据交叉**，单一证据不下结论。
脚本负责关联与聚类等确定性工作；模式辨析（尤其是反例陷阱）是你的工作。

## 执行流程

### 第 0 步 · 路径分流

- **单码口头询问且无数据文件** → 轻量路径：读 `references/dtc_structure.md`
  确认编码含义，结合 `references/root_cause_sop.md` 对应模式给排查方向，
  **不跑脚本**。但必须声明：单码无冻结帧、无伴生码上下文，
  结论为**方向性而非确定性**。
- **有 DTC 导出文件 / 多码 / 车队级问题** → 完整路径，进第 1 步。

### 第 1 步 · 归一化

```bash
python scripts/parse_dtc.py <导出文件> -o dtc_norm.json
```

支持 CSV 与 JSON 两种导出格式。看 stderr：

- **丢弃率 > 10%**：向用户确认导出模板版本；脚本已列出前 5 条丢弃原因
  （缺字段／status_byte 无法解析），据此判断是模板不符还是个别脏数据。
- **`WARN: first_seen 全部相同`**：TSP 平台按读取时刻覆盖了首发时间，
  首发排序将降级为 occurrence 计数器排序——报告中必须声明置信度降低。
- **`WARN: first_seen 与 occurrence 均不可用`**：只能做拓扑分析，
  报告须明确声明该局限，不要假装能排首发。

### 第 2 步 · 关联分析

```bash
python scripts/correlate_dtc.py dtc_norm.json -o correlated.json
```

脚本做三件确定性工作：

1. **首发排序**：按 confirmed 时间戳（或降级用 occurrence）排出每车的候选根源码
2. **传播标注**：依 ecu_topology 邻接关系，把「根源候选下游的通信类 U 码」
   标为 `suspected_secondary`
3. **车队聚类**：码 × 软件版本 三维聚集度，给出 `pattern_hint`

若 stderr 出现 `WARN: 拓扑表未覆盖的 ECU`，该 ECU 的传播判断不可用——
在报告中标注，并提示维护者更新 `references/ecu_topology.md`。

### 第 3 步 · 领域裁决（你的核心工作）

读 `references/root_cause_sop.md`，按脚本给出的 `sop_section` **只定位到对应节**：

| 脚本标注的 pattern | SOP 节 | 含义 |
|---|---|---|
| `POWER_DOMAIN_CASCADE` | §1 | 电源类码首发 + 多域 U 码伴生 |
| `BUS_SEGMENT_LOSS` | §2 | 同段 ECU 集体 U 码，无功能码 |
| `SINGLE_ECU_INTERNAL` | §3 | 单 ECU 功能码，无伴生 |
| `MIXED_REVIEW_REQUIRED` | §1–§3 | 混合形态，需人工辨析（脚本不裁决） |
| `NO_CONFIRMED` | §5 | 仅 pending，confirmed 不落 |
| 车队 `SW_VERSION_CLUSTER` | §4 | 同码同版本聚集（车队级，与单车模式叠加） |

**对照 SOP 的判据逐条核对，特别注意每节的「反例」**——表象相同但根因不同的
陷阱场景。脚本给出的 pattern 是**基于规则的初判**，反例辨析是它做不到的：

- 最典型的陷阱：`BUS_SEGMENT_LOSS` 与 `POWER_DOMAIN_CASCADE` 表象都是"多域 U 码"，
  区别在冻结帧电压是否越限（脚本已给 `voltage_abnormal` 字段，但**你要核对
  伴生码的冻结帧电压是否也越限**——只有根源码越限而伴生码正常时，
  电源假设不成立）。
- 第二个陷阱：搭电救援后的历史遗留码，时序集中且此后无 pending 复发，
  不是活动故障。

### 第 4 步 · 交付

报告必须包含：

1. **根源码判定**：含置信度与依据（三重证据分别说明是否支持）
2. **伴生码清单**：明确写出"这些码不需要单独处置"——这是本技能的核心价值，
   避免维修端对着一屏故障码逐个排查
3. **处置顺序**：按 SOP 的处置节给出动作序列
4. **若为批次问题**：圈定影响面的**查询条件**（版本号／批次号／ECU 供应商代码），
   而不是只说"建议排查批次"

## 错误处理与 fallback

- **冻结帧缺失**：降级为时序 + 拓扑双证据，报告中显式降置信度，
  并说明"补充冻结帧后可提升至确定性结论"。
- **时间戳全同**：见第 1 步；改用 occurrence 排序，二者皆无 → 只做拓扑分析
  并声明局限。
- **拓扑表未覆盖的新 ECU**：脚本列为 `unknown_nodes`，该 ECU 相关传播判断
  标注为不可用；不要凭 ECU 名称猜测它挂在哪条总线上。
- **`MIXED_REVIEW_REQUIRED`**：脚本明确表示无法裁决。此时逐条核对 §1–§3 判据，
  若仍不能定论，交付"两个假设 + 各自的验证方法"，不要强行二选一。

## 边界

- **上下文中出现"升级／刷写／OTA"字样 → 立即声明移交 `ota-log-diagnosis`，
  不做部分分析。** 移交话术示例："这些故障码出现在 OTA 升级过程中，
  属于刷写失败的伴生现象，我按 OTA 诊断流程来分析会更准确。"
- 清码操作指导、维修工艺 → 超出本技能，指向售后工艺文档体系。
- 纯科普问题（"P0 和 U0 开头有什么区别"）→ 直接回答即可，不必走本流程。