Menü
证据驱动的追踪通道，在 Kimi 的 Agent 工具中编排互相竞争的 tracer 假设
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
oh-my-kimi 的目录入口，包含面向 Kimi CLI 的 agent、skill、hook 与 MCP 套件，衍生自 oh-my-* 谱系。
面向密钥、注入、authz/authn、不安全 IO、依赖与数据外泄风险的安全评审
LLM Wiki —— 跨会话持续累积的 markdown 知识库（Karpathy 模型）
面向作家的 agentic 记忆系统 —— 跟踪人物、关系、场景与主题
跑只读的深度仓库分析，返回一份带置信度排序的综合结论，附具体文件引用、清晰区分证据与推断。当用户说 'analyze'、'investigate'、'why does'、'what's causing'，或在提任何改动方案之前需要跨文件的有据解释时使用。
取消任何活跃的 oh-my-kimi 模式（autopilot、ralph、ultrawork、ecomode、ultraqa、swarm、ultrapilot、pipeline、team）
| name | trace |
| description | 证据驱动的追踪通道，在 Kimi 的 Agent 工具中编排互相竞争的 tracer 假设 |
| argument-hint | <observation to trace> |
| agent | tracer |
| level | 2 |
当问题是模糊的、因果的、证据密集的，目标是解释为什么会发生某个观察到的结果，而不是直接动手修代码或重写代码时，使用本 skill。
这是建在内置 tracer agent 之上的编排层。目标是让 tracing 像一个可复用的 oh-my-kimi 操作通道一样：复述观察、生成互相竞争的解释、并行收集证据、对解释排序、提出能最快折叠不确定性的下一步探针。
当问题是以下情形时，使用 /oh-my-kimi:trace：
例子：
始终保留下面这些区分：
不要塌缩成：
把证据按层级看待，而不是平的。
从最强到最弱：
当存在更强的反证时，对主要依赖低层证据的假设显式降级。
每一次严肃的 /trace 都必须尝试证伪自己最偏爱的解释。
对每个头部假设：
在以下情况下对一个假设降级：
/trace 使用 Kimi 的 Agent 工具。
Lead 应当：
重要：worker 应当追求有意不同的解释，而不是同一个解释的并行复制。
除非提示明显暗示更好的划分，默认使用这 3 条通道：
对通道 3，跨实体差异在升级前需要做一次前提审计：枚举实体维度，检查零行或不匹配的结果是源于把一个键应用到多个实体上，还是源于真正的系统缺陷；结果可能是验证方法本身的缺陷。
这些默认值刻意宽，让第一刀切片能跨 bug、性能、架构与实验追踪都适用。
在初轮证据采集之后，相关时用下面的透镜对领先者施压：
这些透镜不是凑数。只在它们可能挖出被忽略的解释、隐藏依赖或弱推断时使用。
每个 worker 应当是一条 tracer 通道的拥有者，而不是通用 executor。
每个 worker 必须：
有用的证据来源包括：
trace_timeline 拿到的已有 trace 工件trace_summary 拿到的已有聚合 trace 证据建议的 worker 返回结构：
最终的 /trace 回答应当是综合，而不是堆叠。
返回：
即使当前已经有一个主导解释，仍保留一份排序的候选清单。
在收尾前：
不要因为多个 worker 用了相似语言就声称汇聚。汇聚需要要么：
Lead 应当显式说明为什么一个假设下移：
这很重要，因为 /trace 应当教读者为什么一个解释胜过另一个，而不是只甩出一张最终表。
使用面向团队编排的提示，大致如下：
好的 /trace 输出是：
[发生了什么]
| 排名 | 假设 | 置信度 | 证据强度 | 为什么领先 |
|---|---|---|---|---|
| 1 | ... | 高 / 中 / 低 | 强 / 中 / 弱 | ... |
[当前最佳解释]
[让不确定性悬而未决的单一缺失事实]
[单一下一步探针]
[仅当不确定性仍然很高时]