---
name: trace
description: 在 Claude 内置团队模式中编排相互竞争的 tracer 假设的证据驱动追踪通道
agent: tracer
level: 2
---

# Trace 技能

当问题具有模糊性、因果性并且高度依赖证据时，请使用此技能；目标是解释某个观察结果**为什么**会发生，而不是直接跳进修复或重写代码。

这是构建在内置 `tracer` agent 之上的编排层。目标是让 tracing 像一条可复用的 OMC 工作通道: 重述观察现象、生成相互竞争的解释、并行收集证据、对这些解释排序，并提出能最快消除不确定性的下一步探针。

## 适合进入的场景

当问题具有以下特征时，使用 `/oh-my-claudecode:trace`:

- 模糊不清
- 以因果分析为核心
- 高度依赖证据
- 最适合通过并行探索相互竞争的解释来回答

示例:
- 运行时 bug 和回归问题
- 性能 / 延迟 / 资源行为
- 架构 / premortem / postmortem 分析
- 科学或实验结果追踪
- 配置 / 路由 / 编排行为说明
- "给定这个输出，向后追踪其可能原因"

## 核心追踪约定

始终保留以下区分:

1. **Observation** -- 实际观察到了什么
2. **Hypotheses** -- 相互竞争的解释
3. **Evidence For** -- 支持每个解释的证据
4. **Evidence Against / Gaps** -- 反驳它的内容，或仍然缺失的内容
5. **Current Best Explanation** -- 当前最有力的解释
6. **Critical Unknown** -- 让顶层解释彼此区分不开的缺失事实
7. **Discriminating Probe** -- 能以最高价值消除不确定性的下一步

**不要**退化成:
- 通用的修修补补式编码循环
- 通用的 debugger 摘要
- 原始的 worker 输出堆砌
- 在证据不完整时伪装成确定无疑

## 证据强度层级

把证据视为有层级排序，而不是平铺对待。

从强到弱:

1. **受控复现 / 直接实验 / 具有唯一判别力的产物**
2. **来源链清晰的一手产物** (trace 事件、日志、指标、benchmark 输出、配置、git 历史、file:line 行为)
3. **多个独立来源收敛到同一解释**
4. **单一来源的代码路径或行为推断**
5. **较弱的间接线索** (时序、命名、栈顺序、与以往 bug 的相似性)
6. **直觉 / 类比 / 猜测**

当存在更强的反证时，明确降低那些主要依赖较低层级证据的假设排名。

## 强反证 / 证伪规则

每一次严肃的 `/trace` 运行都必须尝试证伪它自己最偏好的解释。

对于每个顶层假设:

- 收集支持它的证据
- 收集反驳它的证据
- 说明它做出了什么有区分度的预测
- 说明什么样的观察结果会很难与它相协调
- 找出将它与次优替代解释区分开的最低成本探针

在以下情况下，降低某个假设的排名:

- 直接证据与之矛盾
- 它只能通过添加新的、未经验证的假设来存活
- 相比竞争者，它没有做出任何有区分度的预测
- 一个更强的替代解释用更少假设解释了同样的事实
- 它的支持主要是间接线索，而竞争者拥有更强层级的证据

## Team-mode 编排形态

对 `/trace` 使用 **Claude built-in team mode**。

主导者应当:

1. 精确重述已观察到的结果或 "为什么" 问题
2. 提取追踪目标
3. 生成多个刻意彼此不同的候选假设
4. 默认在 team mode 中启动 **3 条 tracer 通道**
5. 为每条通道分配一个 tracer worker
6. 指示每个 tracer worker 为其通道收集支持和反对证据
7. 在领先假设与最强剩余替代项之间运行 **rebuttal round**
8. 检测顶层通道是否真的不同，还是实际上收敛到同一个根因
9. 将发现合并为一个带有明确 critical unknown 和 discriminating probe 的排序综合结论

重要: worker 应追求刻意不同的解释，而不是并行追同一个解释。

## v1 的默认假设通道

除非 prompt 强烈表明存在更好的划分方式，否则使用以下 3 条默认通道:

1. **代码路径 / 实现原因**
2. **配置 / 环境 / 编排原因**
3. **测量 / 产物 / 假设不匹配原因**

这些默认项有意保持宽泛，因此第一轮切分可以同时适用于 bug、性能、架构和实验追踪。

## 强制交叉检验视角

在完成初始证据收集后，如相关，请使用以下视角对领先项进行压力测试:

- **Systems lens** -- 队列、重试、背压、反馈回路、上下游依赖、边界故障、协同效应
- **Premortem lens** -- 假设当前最佳解释并不完整或是错的；哪种失败模式会让这次追踪在事后显得尴尬?
- **Science lens** -- 对照组、混杂因素、测量偏差、替代变量、可证伪预测

这些视角不是填充内容。只有在它们能揭示遗漏的解释、隐藏依赖或薄弱推断时才使用。

## Worker 约定

每个 worker 都应是一个 **`tracer`** 通道负责人，而不是通用 executor。

每个 worker 必须:

- 只负责一个假设通道
- 明确重述自己的通道假设
- 为该通道收集支持证据
- 为该通道收集反对证据
- 给出其论据背后证据强度的排序
- 指出缺失证据、失败预测和剩余不确定性
- 说明该通道的 **critical unknown**
- 推荐最佳的通道特定 **discriminating probe**
- 除非被明确要求，否则不要退化成实现工作

有用的证据来源包括:

- 相关代码、测试、配置、文档、日志、输出和 benchmark 产物
- 通过 `trace_timeline` 获取的现有追踪产物
- 通过 `trace_summary` 获取的现有聚合追踪证据

建议的 worker 返回结构:

1. **Lane**
2. **Hypothesis**
3. **Evidence For**
4. **Evidence Against / Gaps**
5. **Evidence Strength**
6. **Critical Unknown**
7. **Best Discriminating Probe**
8. **Confidence**

## 主导者综合约定

最终的 `/trace` 回答应当是综合，而不是简单拼接。

返回:

1. **Observed Result**
2. **Ranked Hypotheses**
3. **Evidence Summary by Hypothesis**
4. **Evidence Against / Missing Evidence**
5. **Rebuttal Round**
6. **Convergence / Separation Notes**
7. **Most Likely Explanation**
8. **Critical Unknown**
9. **Recommended Discriminating Probe**
10. **Additional Trace Lanes** (可选，仅在不确定性仍然较高时)

即使当前已有一个解释明显领先，也要保留按排名排列的候选短名单。

## Rebuttal round 与收敛检测

在结束追踪之前:

- 让最强的非领先通道对当前领先者提出其最佳反驳
- 强制要求领先者用证据而不是断言来回应反驳
- 如果反驳实质性削弱了领先者，就重新排序
- 如果两个"不同"假设最终归约为同一个底层机制，就将它们合并并明确说明
- 如果两个假设仍然意味着不同的下一步探针，即使它们听起来相似，也应保持分开

不要仅仅因为多个 worker 使用了相似措辞就声称它们已经收敛。收敛必须满足以下之一:

- 相同的根因果机制，或
- 独立的证据流指向同一个解释

## 显式降权指引

主导者应明确说明一个假设为何被下调:

- 被更强的证据反驳
- 缺少它本应预测到的观察结果
- 需要额外的临时性假设
- 解释的事实比领先者更少
- 在 rebuttal round 中落败
- 收敛进一个更强的父级解释

这很重要，因为 `/trace` 应当教会读者**为什么**某个解释优于另一个解释，而不是只给出最终表格。

## 建议的主导 prompt 骨架

使用一个面向团队的编排 prompt，大致如下:

1. "精确重述观察结果。"
2. "生成 3 个刻意不同的假设。"
3. "使用 Claude built-in team mode 为每个假设创建一条 tracer 通道。"
4. "对于每条通道，收集支持和反对证据，给证据强度排序，并指出 critical unknown 与最佳 discriminating probe。"
5. "如果有用，对领先项应用 systems、premortem 和 science 视角。"
6. "在排名前两位的解释之间运行一轮 rebuttal round。"
7. "返回一个按排名排列的解释表、convergence 说明、critical unknown，以及单个最佳 discriminating probe。"

## 输出质量标准

好的 `/trace` 输出应当:

- 有证据支撑
- 简洁但严谨
- 对过早确定性保持怀疑
- 明确指出缺失证据
- 对下一步行动保持务实
- 明确说明为什么较弱解释被降权

## 最终综合示例结构

### Observed Result
[发生了什么]

### Ranked Hypotheses
| 排名 | 假设 | 置信度 | 证据强度 | 为何领先 |
|------|------|--------|----------|----------|
| 1 | ... | High / Medium / Low | Strong / Moderate / Weak | ... |

### Evidence Summary by Hypothesis
- 假设 1: ...
- 假设 2: ...
- 假设 3: ...

### Evidence Against / Missing Evidence
- 假设 1: ...
- 假设 2: ...
- 假设 3: ...

### Rebuttal Round
- 对领先者的最佳反驳: ...
- 领先者为何站住 / 失败: ...

### Convergence / Separation Notes
- ...

### Most Likely Explanation
[当前最有力的解释]

### Critical Unknown
[让不确定性仍然存在的单一缺失事实]

### Recommended Discriminating Probe
[下一条单一探针]

### Additional Trace Lanes
[仅在不确定性仍然较高时提供]