yuanze-root-cause-diagnosis

name	yuanze-root-cause-diagnosis
description	把一个反复出现的问题从"直接原因"（动词层，某人忘了/某步漏了）追到"根本原因" （形容词层，人/文化/结构上的系统缺陷），一次修好、多次受益。激活信号：某类问题 在 3 个月内第 2 次以上出现；团队一提出问题就讨论方案而没人问"为什么会这样"； 补丁越打越多但同类问题不减；个人层面某个习惯/错误反复。不适用于：一次性偶发 事件、紧急灭火期（先救火再复盘）、伦理/审美问题。与五步流程（yuanze-five-step-process） 的区别：本 skill 是五步流程的第 3 步单独抽出来，可以独立使用；与问题免疫 （yuanze-find-and-dont-tolerate-problems）的区别：问题免疫关注"找出问题"， 本 skill 关注"问题已经发现后挖根因"。
source_book	《原则》 瑞·达利欧
source_chapter	生活原则 · 2.3 / 工作原则 · 第 12 条（诊断问题）
tags	["diagnosis","problem-solving","management","root-cause"]
related_skills	[{"slug":"yuanze-five-step-process","relation":"composes-with"},{"slug":"yuanze-find-and-dont-tolerate-problems","relation":"composes-with"},{"slug":"yuanze-organization-as-machine","relation":"composes-with"},{"slug":"yuanze-right-person-first","relation":"composes-with"},{"slug":"yuanze-two-barriers","relation":"composes-with"},{"slug":"yuanze-pain-plus-reflection","relation":"contrasts-with"},{"slug":"yuanze-decision-two-steps","relation":"composes-with"}]

诊断问题根源（直接原因 vs 根本原因）

R — 原文 (Reading)

"人们最常犯的错误就是把遇到的问题当成一时的差错，而没有借机对机器的运转进行 诊断，以便实施改进。……直接原因通常是导致某件事发生的具体动词或动作（我没查 时刻表、我迟到了），根本原因则深得多，常常用形容词表达（我健忘、我们的流程 不健全）。找根本原因的方法，是不断问'为什么'。"

— 瑞·达利欧，《原则》工作原则 · 12.1

---

I — 方法论骨架 (Interpretation)

诊断的关键区分是两个语法层：

• 直接原因用动词表达："我忘了"、"服务器崩了"、"客户没付款"。这是症状。
• 根本原因用形容词或名词表达："我健忘"、"我们没有错误检测机制"、 "我的客户筛选流程里没有信用评估"。这是系统特质。

修直接原因只解决本次；修根本原因一次受益多次。作者的纪律：

1. 先诊断再行动——停止解决冲动至少 15 分钟。
2. 追问至少 3 层为什么，直到落到形容词层。
3. 诊断必须点名（ce05）——"团队 / 我们"式的泛指是第二大错误。把问题和 具体人/岗位挂钩，不是"对事不对人"的冷漠，是改进循环的前提。
4. 区分"人的问题"和"流程的问题"（ce19）——问反事实："换另一个人做这件事 会不同吗？" 换人依然失败 = 流程问题；换人就好 = 人岗不匹配。

关键洞察：根本原因一定是关于人或结构的特质（一种"惯性"），不是一次性 事件。

---

A1 — 书中的应用 (Past Application)

案例 1: Ross 忘记执行交易 → 错误日志诞生（c09）

• 问题：交易员 Ross 漏掉一笔客户资金建仓，造成几十万美元损失。
• 方法论的使用：达利欧没停在直接原因（Ross 忘了）、也没开除 Ross。他追问： 为什么？→ 没有检查清单。为什么？→ 部门文化里没有"错误日志"制度（形容词 层）。
• 结论：根因是部门没有问题暴露机制，不是个人健忘。
• 结果：与 Ross 一起建立错误日志，成为桥水第一块"机器化管理"基石，后来 扩展为全司制度。

案例 2: 鲍勃团队不能落地（c23）

• 问题：债券研究团队总是推不动执行。
• 方法论的使用：直接原因层（"进度慢"）被推翻；追问 3 层后发现根因是 人格选型同质化——鲍勃挑的所有人都跟他一样偏"理念型"，结构上缺执行型。
• 结论：形容词层根因 = "团队人格分布失衡"。
• 结果：催生桥水的人才池管理和九维度识别体系。

案例 3: 2008 金融危机预警（c19）

• 问题：债务危机的发生机制。
• 方法论的使用：直接原因层（"次贷违约")被快速跳过；根因 = "偿债成本增速

  现金流增速"这个结构性特征。

• 结果：桥水对冲到位，2008 +14%。

---

A2 — 触发场景 (Future Trigger) ★

用户会在什么情境下需要这个 skill?

1. 某类问题在 3 个月内第 2 次或更多次出现（漏发、拖款、沟通误解）。
2. 团队会议上一提问题就直接跳到"怎么办"，没人问"为什么会这样"。
3. 补丁/SOP 越打越多但同类问题不减。
4. 换了 3 个人做同一岗位仍然失败（可能是流程问题而非人）。
5. 个人层面反复同样的错（不是情绪驱动的那种，更偏结构性）。

语言信号 (用户的话里出现这些就应激活)

• "这次又 XX 了 / 上个月也是这样"
• "我们该怎么办 / 怎么避免下次再出"（在问"办法"，需引导先问"为什么"）
• "我不知道为什么同样的问题总是来"
• "这个流程我们改了好几次还是不行"
• "换了人还是这样"

与相邻 skill 的区分

• 与 yuanze-five-step-process 的区别：五步流程包含诊断作为第 3 步；本 skill 是那一步单独抽出，可用于"目标已清晰，只卡在诊断"的场景。
• 与 yuanze-find-and-dont-tolerate-problems 的区别：问题免疫关注识别问题 的存在（容易被掩盖的慢速恶化）；本 skill 关注问题已识别后怎么挖根因。
• 与 yuanze-pain-plus-reflection 的区别：痛苦+反思以个人情绪为起点；本 skill 以项目/系统问题为起点。

---

E — 可执行步骤 (Execution)

1. 先停止解决

   • 动作：明确声明"接下来 15 分钟我们只诊断，不讨论方案"。写在白板或共享文档 开头。
   • 完成标准：所有"那我们应该 X"的发言被礼貌挡回。
   • 判停：若现场真的在灭火（服务器挂了、客户正在走），先灭火，复盘放 24h 后。

2. 写下直接原因 + 追 3 层为什么

   • 动作：第 1 层写直接原因（动词层）。然后问"为什么"→ 第 2 层。再问 → 第 3 层。 至少到形容词层（人 / 结构 / 文化 / 习惯特质）才停。
   • 完成标准：最后一层的答案不能用动词，必须用形容词或名词短语。
   • 示例：
     • L1：早报漏发（动词：发送任务没触发）
     • L2：因为 cron 任务调度失败（动词）
     • L3：因为没有"发送后回写校验"（名词短语：机器缺监控部件）← 这是根因

3. 诊断必须点名

   • 动作：说明问题发生时的具体人和岗位（不是"团队"）。问"是这个人的问题、还是 这个岗位设计的问题"。
   • 完成标准：要么定到具体人（A 岗的 B 不适合做 C 类任务），要么定到岗位 设计（任何人来做 D 这件事都会失败）。
   • 判停：点不出人名 / 岗位 → 回到第 2 步，你还没挖够。

4. 做反事实检验

   • 动作：问"换一个同等能力的人做这件事，会不同吗？"
     • 会不同 → 人岗不匹配 → 分叉到 yuanze-right-person-first。
     • 不会不同 → 机器/流程问题 → 重新设计那个部件。
   • 完成标准：给出明确分叉并进入对应动作。

5. 写入"根因档案"

   • 动作：把"问题 X 的根因 = Y（形容词层）" 记录下来，每月回看是否还在发生。
   • 完成标准：形成可搜索的条目（不是一次性的白板笔记）。

---

B — 边界 (Boundary) ★

不要在以下情况使用此 skill

• 一次性偶发事件（雷击、临时供电故障）——硬追根因会得出废话。
• 紧急灭火中——先救火，诊断放凉 24h 后。
• 伦理 / 审美 / 创造性问题（"这个设计为什么不美"、"要不要离婚"）——根因分析 不适合非结构化问题。

作者在书中警告的失败模式

• ce04 跳过诊断直接行动：最常见的管理错误。每次问题出现就修补表面，机器 本身从不被改进。
• ce05 诊断时不提个人姓名：第二大错误。用"我们/大家/这个部门"泛指，保护 关系牺牲真相。
• ce19 人问题 vs 流程问题混淆：两种对称错误——给不胜任的人加流程补丁、或 开除一个又一个结果下一个新人同样失败。反事实检验是关键。

作者的盲点 / 时代局限（ce22 + ce23）

• ce22 算法化边界：根因分析在金融、工程、流程问题上非常有效，但在伦理、 审美、创造性问题上会扭曲问题本身。征兆：挖根因时发现每一层都没法用 形容词简单表达，或答案总是"因为价值观"——这就是信号，换工具。
• ce23 幸存者偏差：达利欧诊断出根因的案例大多是成功的；但"诊断出了根因但 没修成/不能修"的案例不在样本里。诊断出根因 ≠ 自动解决。
• 东亚面子文化：作者要求诊断必须点名——在本地组织里直接点名可能触发巨大 防御。修正：先私下一对一点名建立共识，再在小范围会议里用"A 同事在 B 环节出现 C 挑战"的结构化语言（比"A 搞砸了"柔和），最后才上大范围。核心是 保留点名信息，换外壳。

容易混淆的邻近方法论

• 5 Whys：同样追问为什么，但不要求落到形容词层，也不要求点名。本 skill 是 5 Whys 的加强版。
• 鱼骨图 / Ishikawa：枚举可能原因类别（人/机/料/法/环），但没有追问深度。 可作本 skill 第 1 步的辅助。
• "对事不对人"（东亚管理常识）：与本 skill 相反——作者要求对事必须 对到具体的人，否则无法修复。

---

相关 skills

• composes-with: yuanze-five-step-process — 五步流程包含诊断作为第 3 步；本 skill 是那一步单独抽出，可用于"目标已清晰，只卡在诊断"的场景。
• composes-with: yuanze-find-and-dont-tolerate-problems — 问题免疫系统负责发现，本 skill 负责挖根因。前者是触发器，后者是下一步动作。
• composes-with: yuanze-organization-as-machine — 机器框架强制把讨论分"案例层 vs 机器层"，本 skill 的"形容词层根因"恰好对应机器层——两者常同时被调用。
• composes-with: yuanze-right-person-first — 第 4 步反事实检验（换个人会不同吗）若答"会"，就分叉到找对人 skill。
• composes-with: yuanze-two-barriers — 当根因追到"某人反复犯同类错"时，可能的上游是两大认知障碍——从机器层回到认知层。
• composes-with: yuanze-decision-two-steps — 决策两步的"了解"阶段里，本 skill 是追问根因的具体工具。
• contrasts-with: yuanze-pain-plus-reflection — 痛苦+反思以个人情绪为起点，处理单次事件的规则提取；本 skill 以项目/系统问题为起点，处理一类问题的结构根因。

---

审计信息

• 验证通过: V1 ✓ / V2 ✓ / V3 ✓
• 蒸馏时间: 2026-04-19
• 优先级: P0