因果发现问题这几年在 AI 圈子里越来越热但很多开发者的第一反应仍然是这不就是统计学里的相关性分析加一张图吗实际接过业务需求就会发现完全不是一回事。无论是推荐系统里判断“用户停留时长增长到底是不是新功能引起的”还是智能运维里定位“某个接口超时率上升的根因是不是最近一次配置变更”都绕不开一个核心问题你只能看到数据之间的关联却没法直接看到谁导致了谁。GENESIS 这个项目标题里的关键词是“Explainable Causal Discovery”也就是“可解释的因果发现”。它真正想做的事情不是再提供一个跑完输出一张因果图的算法包而是把因果发现的整个过程——从输入数据、变量选择、假设条件到最终生成因果图、验证每条边的可靠性——变成可以被审计、被理解、被业务方信任的工程能力。这篇文章我会从因果发现的实际价值讲起分析它和传统关联分析的本质差异然后重点拆解“可解释性”在因果发现里的具体含义。由于 GENESIS 的相关资料目前以论文标题和设计目标为主我不会编造它的 API 或实测数据而是结合因果发现领域通用且成熟的技术路线给出一个可运行的最小实验工作流帮你理解这类框架在解决什么问题、工程上如何验证因果图结果、以及接入生产环境前需要避开哪些坑。读完你应该能判断你的业务场景到底需不需要因果发现以及如果要用应该从哪个环节开始设计验证方案。1. 因果发现为什么突然变重要了过去几年机器学习模型的主要战场是“预测”。用户会不会点击、设备会不会故障、交易是不是异常这些问题本质上都是在给定特征的情况下估计一个条件概率 P(Y|X)。预测模型做得好不好看 AUC、看准确率、看召回率就够了。但业务方很快就发现了一个尴尬的事实预测模型可以告诉你“会出问题”却很难告诉你“为什么出问题”更不能告诉你要不要采取某个动作。举个例子。一个内容平台的推荐系统发现“用户在某类视频上的停留时长”和“次日留存”高度相关。如果只是做预测这个相关性可以直接进入特征工程。但如果产品经理想推动一个运营策略把这类视频的曝光量提高 20%期待次日留存也同步提升问题就来了——相关性不等于因果性。很可能是因为留存用户本来就喜欢看这类视频而不是这类视频带来了留存也可能是一个隐藏变量在同时影响这两个指标比如用户当天是否闲、是不是周末、网络环境是否稳定。这正是因果发现要解决的问题。它试图从观测数据中推断变量之间的因果结构输出一张有向图谁直接影响谁谁是谁的原因谁是谁的结果。在智能运维里因果发现可以用于根因定位在医学数据分析里它可以用于寻找症状和指标的潜在驱动关系在推荐系统里它可以用于评估某个策略改动是否真的带来了指标变化。和传统的 A/B 测试相比因果发现的最大优势是不一定需要随机实验可以从历史观测数据出发快速给出可能的因果结构假设。但这里必须说清楚因果发现不是在预测时代替代机器学习而是补上“预测之后怎么办”这一段。它回答的是“如果干预 XY 会不会变”的问题。这本质上是一个决策问题而决策需要依据依据需要可解释。这也是为什么 GENESIS 这类把“Explainable”写进标题的项目会进入公众视野AI 的能力正在从“知道是什么”走向“知道为什么”而“知道为什么”必须让人类能看懂、能复核。从技术栈的角度看因果发现也不是一个单一算法而是一整套流程。数据清洗、变量选择、假设检验、图结构学习、方向判定、结果验证每一步都可能出错。传统工具往往把这套流程封装得太黑盒开发者只能看到输入和输出中间全是自动推断。可一旦业务方问“为什么这两条边是反的”“为什么这个变量被排除了”项目就卡住了。GENESIS 代表的思路恰恰是把这些中间环节显式化让因果发现成为一个可对话、可调试的过程。2. 因果发现与关联分析的边界很多开发者第一次接触因果发现时会误以为它就是“升级版的相关性热力图”。这个误解需要尽早澄清。相关性分析回答的问题是“两个变量是否一起变化”因果发现回答的问题是“如果我改变一个变量另一个变量是否会发生可预期的变化”两者的逻辑基础完全不同。对比维度关联分析因果发现核心问题X 和 Y 是否相关X 是否导致 Y数学基础相关系数、条件独立性结构因果模型、有向无环图输出形式相关系数矩阵、热力图有向图、因果效应估计可否支持干预不能可以如 do-演算对业务决策的意义可用于特征筛选可用于策略评估和根因定位主要风险混淆变量导致伪相关未观测混淆变量导致方向错误用通俗的话解释相关关系是“两者同时出现”因果关系是“先有鸡还是先有蛋”这个问题的结构版本。因果发现工具输出的是一个有方向的图结构。比如 A → B 表示 A 是 B 的直接原因A ← B 表示反过来A → B ← C 这种结构则表示 B 同时受 A 和 C 影响A 和 C 本身独立。这种结构信息是相关性分析永远给不出来的。但要注意因果发现也不是万能工具。它依赖几个关键假设观测数据中没有遗漏的重要混淆变量变量之间的关系可以用有向无环图描述样本量足够支撑统计检验数据生成过程满足稳定性假设。这些假设在真实业务中经常被违反所以可解释性才如此重要——如果框架能告诉你它做了哪些假设、哪些步骤置信度高、哪些步骤可靠性存疑开发者才能判断结果能不能用。从项目落地的角度看我觉得最实用的理解方式是关联分析是“描述性分析”因果发现是“决策性分析”。如果你的目标只是给模型加特征关联分析就够用如果你的目标是回答“要不要改策略、要不要上线这个功能、要不要调整资源配置”那才需要进入因果发现的范畴。GENESIS 这类项目要做的就是让“决策性分析”在工程实践中变得可信可查。3. 可解释性因果发现落地的那道坎如果只看论文标题很多人会以为 GENESIS 只是给因果发现加了一个可视化模块把网络图画得更漂亮。实际上“Explainable”这个词在因果发现里远比可视化复杂。我认为它至少包含三个层次。第一个层次是图形可解释。输出一张 DAG有向无环图每个节点是一个变量每条边是一个因果方向。这个层次确实依赖可视化工具但核心要求不是画图好看而是让观察者能快速理解图的整体结构和关键路径。比如在运维场景里工程师需要一眼看出“配置变更”和“错误率上升”之间是否有直接路径还是经过某个中间变量间接影响。第二个层次是机制可解释。因果图本身只给出“谁指向谁”但没有解释“通过什么机制指向”。比如 A → B 这条边A 是通过直接改变 B 的取值还是通过改变某个中间变量 C再由 C 影响 B有些因果发现算法会把多条路径全部输出有些则只给出简化图。如果框架能支持边权值、置信度、子路径分析那么业务方就能追问这条因果关系的强度有多大哪些路径贡献最大第三个层次是验证可解释。因果发现的结果不是真理而是假设。可解释的框架必须允许开发者对结果进行验证给定一个因果图能不能估计出每条边的因果效应大小能不能用领域知识对某些边进行人工修正能不能做敏感性分析观察当某个假设被放松时图结构是否稳定很多因果发现项目在实验环境跑得很漂亮一到生产环境就失败原因就是缺少这个验证层业务方无法确认结果是否可靠。GENESIS 标题里的 “Towards”本质上是在承认因果发现距离真正可解释还有距离。这是一个研究方向的声明不只是一个产品功能。它强调的是一种设计目标把因果发现从“输入数据、输出答案”的问答模式转变为“输入数据、输出证据链、人类参与决策”的协作模式。这其实和当下大模型应用里的 RAG、思维链、可溯源引用是同一种思路——AI 给出结论的同时必须给出让人信服的推理过程。在实际项目中可解释性的价值会直接体现为“推进速度”的差异。一个不可解释的因果模型业务方可能会花两周时间反复质疑结果一个自带验证机制、能展示中间步骤的因果发现流程业务方可能一天内就能确认哪些边可信、哪些边需要补充数据再确认。两边的技术含量可能差不多但后者明显更容易走进生产环境。4. GENESIS 的定位与核心设计理念基于现有材料GENESIS 现在更接近一个研究方向或框架原型而不是一个已经非常成熟的工业级工具。从名字看“GENESIS”有“起源、创世”的含义结合 “Towards Explainable Causal Discovery”可以理解为它希望从因果发现的“源头”开始构建一套让整个推断过程可解释的方法论和工具链。这种思路和当前因果推断领域的主流变化是吻合的。早期因果发现研究更关注算法本身的性能在多少个变量、多少噪音、多少样本下算法能恢复出多少比例的因果边。研究方向偏“结果指标”。而近几年的趋势是研究者开始关注“过程指标”算法的输出稳定性如何置信度是否精确当假设不满足时算法会给出怎样的错误提示人类能不能干预算法决策。GENESIS 如果延续这个思路它的核心贡献可能会集中在三块第一把因果发现中常用的假设检验和条件独立性检验显式化让每一步判断都留下日志第二为最终的因果图提供可解释的边证据比如“这条边是根据哪个变量组合、哪个统计量、哪个显著性水平确定的”第三支持领域知识注入让专家可以锁定某些边的方向或排除某些变量。这些能力如果做扎实会比单纯提出一个新的图结构学习算法更贴近工程需要。另外要注意的是GENESIS 与近期热词里的 Qwen3.6-35B-A3B、Hermes V7 这类大模型项目没有直接关联。之所以这些词同时出现在热点里大概率是因为它们都涉及“模型能力”“自动推理”“可解释性”等话题检索系统将它们聚合到了一起。写代码和跑实验时不要指望 GENESIS 是一个大模型 Agent 框架它本质上是因果推断领域的工具或方法论跟 LLM 的关系是可以互相配合LLM 负责抽取变量、提供领域知识摘要GENESIS 这类框架负责结构因果推断。从定位上判断GENESIS 更适合的读者是这几类一是智能运维和可观测性平台的技术负责人想用因果图做根因分析二是数据科学团队的成员要评估策略效果但无法频繁做 A/B 测试三是研究因果推断的学生和开发者需要一个能解释中间过程的实验框架。如果只是想在推荐系统里增加一个特征它可能不是你的第一选择因为引入因果推断的成本远高于简单的特征筛选。5. 环境准备与最小实践搭一个因果发现实验环境虽然 GENESIS 本体的代码尚未有公开的稳定版本信息但因果发现领域的通用工具链已经足够跑通一个最小实验。我建议你从以下几个库开始pandas 负责数据处理networkx 负责图结构操作python-igraph 或 pygraphviz 负责可视化statsmodels 和 scipy 做统计检验lingam 或 causal-learn 提供因果发现算法。版本请以实际项目为准本文重点演示的是通用思路不同库的 API 略有差异但整体流程是一致的。# 建议使用 Python 3.9 以上版本 pip install pandas numpy networkx scipy statsmodels pip install lingam # 如果希望尝试更多因果发现算法可以安装 causal-learn pip install causal-learn安装完成后先不要急着跑因果发现算法。我强烈建议你先构造一个你完全知道答案的模拟数据集用来验证工具链是否正常、算法是否能恢复出真实结构。这是一个容易被忽略但极其重要的步骤因果发现算法的输出不是唯一解同一份数据用不同假设可能得到完全不同的图。只有在模拟数据上先建立“预期——输出——对比”的反馈循环你在真实业务数据上才敢相信框架的结果。模拟数据的核心是定义一个真实的因果生成过程。比如你设定 X 影响 YY 影响 ZX 和 Z 独立。然后按这个结构生成数据再让因果发现算法去恢复它。如果算法恢复不出这个简单结构那说明数据规模、噪音水平或参数设置有需要调整的地方。这个步骤也直接对应了 GENESIS 这类框架强调的“可解释”只有你知道真实答案才能逐步理解算法每一步为什么会给出某个结果。# 模拟因果数据生成 import numpy as np import pandas as pd np.random.seed(42) n_samples 5000 # 真实因果结构: X - Y - Z, 且 X 与 Z 之间没有直接边 x np.random.normal(0, 1, n_samples) y 1.5 * x np.random.normal(0, 0.5, n_samples) z 2.0 * y np.random.normal(0, 0.5, n_samples) df pd.DataFrame({ X: x, Y: y, Z: z }) print(df.corr())运行这段代码后你会发现 X 和 Z 的相关系数并不为 0。因为 X 通过 Y 间接影响了 Z所以两者会表现出相关性。这就是因果和相关最经典的背离场景X 和 Z 相关但 X 不是 Z 的直接原因。真正的因果结构是 X → Y → Z。相关分析完全无法区分直接因果和间接因果而因果发现算法要做的正是这件事。6. 核心流程拆解从数据到可解释因果图因果发现的工程流程不是“一行算法调用”而是一套需要模块化拆解的流水线。以下是我在实践中验证过比较可靠的五步流程。第一步变量选择与数据预处理。这是最容易被低估的一步。因果发现对输入变量的选择非常敏感漏掉一个关键混淆变量输出图的错误率可能远超你的预期。预处理时要检查缺失值、异常值、时间对齐和单位差异。因果发现的数据通常需要满足独立同分布或平稳性假设如果数据是时间序列要先考虑平稳性和滞后结构。第二步相关性分析与条件独立性检验。这一步不是用来定因果而是用来做“候选过滤”。你要计算变量两两之间的相关性或互信息也要做条件独立性检验比如偏相关检验。条件独立性的核心思想是如果在控制 Z 的条件下X 和 Y 变得独立那么 X 和 Y 之间的相关关系可能是由 Z 引起的。这是很多因果发现算法的基础操作。# 偏相关检验控制 Z 后X 和 Y 是否还相关 from scipy import stats import pandas as pd import numpy as np def partial_corr(df, x, y, control): 计算控制 control 变量后x 与 y 的偏相关系数和 p 值 # 回归残差法 def get_residual(data, target, covariates): X np.column_stack([np.ones(len(data)), data[covariates]]) beta, _, _, _ np.linalg.lstsq(X, data[target], rcondNone) pred X beta return data[target] - pred res_x get_residual(df, x, control) res_y get_residual(df, y, control) r, p stats.pearsonr(res_x, res_y) return r, p # 对模拟数据做偏相关检验 print(控制 Z 后X-Y 偏相关:, partial_corr(df, X, Y, [Z])) print(控制 Y 后X-Z 偏相关:, partial_corr(df, X, Z, [Y])) print(控制 X 后Y-Z 偏相关:, partial_corr(df, Y, Z, [X]))这段代码输出的结果会非常有信息量。控制 Z 后X 和 Y 之间仍然相关因为 X → Y 是真实因果控制 Y 后X 和 Z 的偏相关接近 0说明 X 和 Z 之间的相关关系完全由 Y 解释。这个检验就是在给因果图提供“证据”也正是可解释性的重要一环不是直接扔出一张图而是告诉你看哪几个偏相关系数为什么这一步会这样连接。第三步运行因果发现算法并生成候选图。这里我用 LiNGAM 算法演示因为它对线性非高斯数据有较好的效果而且输出相对直观。如果你用的是其他库思路类似。import lingam import pandas as pd model lingam.DirectLiNGAM() result model.fit(df) # 输出邻接矩阵 print(邻接矩阵 (行 - 列 表示影响方向):) print(result.adjacency_matrix_) # 转为 graphviz 格式查看 labels df.columns graphviz_output result.to_dot() print(graphviz_output[:500])LiNGAM 的邻接矩阵中行列之间的数值表示因果效应的强度。如果矩阵某个位置非零就表示行对应的变量对列对应的变量有直接影响。在模拟数据上清晰的输出应该是 X 影响 Y、Y 影响 Z而 X 对 Z 的直接效应接近零。这样你就能直接验证算法是否恢复了真实结构。第四步方向判定与领域知识融合。因果发现算法会自动确定方向但这个方向不一定符合真实世界。比如在业务数据里算法可能把“广告曝光量”和“点击量”之间的方向判反。这时你就需要领域知识来干预。可解释的框架应该支持“约束注入”比如手动指定某条边存在或不存在指定某个方向必须为真。这个步骤在工程上非常重要因为完全依赖算法自动判方向在变量多、样本少时极易出错。第五步结果验证与敏感性分析。验证是因果发现中最容易被省略但最该做扎实的环节。你需要问自己四个问题一因果图上的每条边在统计上是否显著二边的方向是否对参数选择敏感三样本量减半或改变随机种子后图的结构是否仍然稳定四如果在数据中加入一个与已知变量相关的噪音列算法会不会产生伪边这些问题回答不了因果图就不适合进入生产决策。下面的代码演示了一种简单的稳定性检查用自助采样法跑多次算法看每条边出现的频率。# 稳定性检查多次自助采样统计每条边出现的频率 from sklearn.utils import resample edge_count {f{a}-{b}: 0 for a in labels for b in labels if a ! b} n_bootstrap 50 for _ in range(n_bootstrap): sample resample(df, n_sampleslen(df), random_stateNone) try: resample_model lingam.DirectLiNGAM() resample_result resample_model.fit(sample) adj resample_result.adjacency_matrix_ for i, a in enumerate(labels): for j, b in enumerate(labels): if i ! j and abs(adj[i, j]) 1e-6: edge_count[f{a}-{b}] 1 except Exception: # 某些自助样本可能因数值问题失败这里跳过 continue for edge, freq in sorted(edge_count.items(), keylambda x: -x[1]): if freq 0: print(f{edge}: {freq / n_bootstrap:.0%})这段代码的价值不在于算法有多高级而在于它把一个因果图从“结果”变成“带置信度的证据链”。当你向业务方展示某个根因判断时你可以说这条边在 50 次抽样中出现了 42 次稳定性较高那条边只有 8 次建议谨慎使用。这种表达方式远比直接丢出一张完整因果图更有说服力也更能体现 GENESIS 标题里 “Explainable” 的含义。7. 运行结果与效果验证完成上面流程后如何判断实验是成功的不要只看因果图结构对没对要看几个更细的指标。第一真实因果边是否被恢复。在模拟数据里你应该能看到 X → Y 和 Y → Z而 X → Z 的直接效应趋近于零。如果算法输出了 X → Z 的强边先检查数据是否有问题再检查算法假设是否适用。第二置信度是否合理。自助采样后真实边的出现频率应该很高伪边的出现频率应该很低。第三解释材料是否齐全。能否讲清楚为什么选择这个算法、为什么选择这些变量、每条边的统计证据是什么。如果只拿到一张图却说不出任何解释那这个实验还不能算闭环。预期运行结果可以这样描述模拟数据上相关矩阵显示 X 与 Z 的相关系数约为 0.87 左右显著不为零但偏相关检验控制 Y 后X 与 Z 的偏相关接近 0p 值不再显著。LiNGAM 的邻接矩阵中X 到 Y、Y 到 Z 的系数明显非零X 到 Z 的系数微弱。自助采样边频表中X→Y 和 Y→Z 的出现频率稳定在 80% 以上X→Z 的频率低于 20%。这样的结果就构成了一条完整的证据链。如果运行失败第一步要看的不是算法参数而是数据格式和样本量。因果发现算法通常要求数据以 DataFrame 形式传入所有变量必须是数值型不能有缺失值。样本量低于几百条时统计检验的可靠度会大幅下降图形结果会出现较大波动。另外不同因果发现算法的假设差异很大LiNGAM 假设数据是非高斯线性PC 算法假设数据是高斯分布且满足因果充分性FCI 算法则允许未观测混淆变量的存在。用错算法结果基本不可信。因此在项目启动时就要想清楚你的数据属性匹配哪个算法族而不是挨个试一遍。8. 常见问题与排查思路问题现象可能原因排查方式解决方案因果图的边方向与业务认知相反数据中存在强混淆变量或算法假设不适用检查变量是否有隐含的共同原因加入领域知识约束或改用允许未观测混淆变量的算法同一份数据多次运行结果不稳定样本量不足或算法陷入局部最优增加样本量使用自助采样观察边频扩大数据采集周期或对结果做稳定性筛选偏相关检验 p 值普遍不显著变量间关系不是线性的检查散点图改用互信息或核方法检验对变量做合适的非线性变换或使用基于条件互信息的算法算法输出大量伪边变量过多、样本不足或存在共线性绘制变量相关性热力图检查方差膨胀因子先用特征工程压缩变量再做因果发现因果效应估计结果与因果图不一致图中存在碰撞结构或对撞偏误检查是否存在“两个变量同时指向第三个变量”的结构分别计算不同路径的效应再综合判断数据含缺失值导致算法直接报错多数因果发现算法不支持缺失值查看缺失率分析缺失模式使用多重插补或删除高缺失率变量这里重点说一个新手最容易踩的坑把时间先后当作因果方向。很多工程师觉得 A 变量在时间上早于 B 变量所以 A 一定是 B 的原因。在时间序列场景中这个逻辑有合理性但真实业务里存在大量“前因不必然导致后果”的情况。比如某天早上先发生了一个应用重启A随后出现了响应变慢BA 发生在 B 之前但真正的根因可能是底层宿主机资源争抢C它同时触发了应用重启和响应变慢。因果发现算法如果只用两两相关性很可能会错误地识别出 A → B。这个时候引入领域知识和更严格的混淆变量控制就变得至关重要。另一个常见问题是过度依赖因果图的“方向”。因果发现输出的方向是统计推断的结果不是上帝视角的真相。如果你拿不到干预实验数据最好不要用因果图去做“把某个变量调大、预测另一个变量会涨多少”这类精确预测。因果图更适合用来生成假设、筛选关键变量、辅助根因定位而不是替代严格的随机对照实验。理解这个边界你才不会在因果图上寄予不切实际的期望。9. 最佳实践与工程建议从工程落地角度看因果发现项目最大的阻力往往不是算法而是组织协作。数仓团队提供的数据质量、业务团队提供的领域知识、算法团队提供的统计建模能力三者缺一不可。因此我建议从第一天就建立一个“因果发现验证清单”而不是先跑模型再补解释。清单里至少包括每个变量的业务含义、数据来源、业务预期的因果路径、风险假设、验证指标。安全边界同样需要重视。因果发现本质上是统计推断工具它会基于数据给出一个看起来“科学”的因果图但这个图可能因为遗漏变量而完全错误。如果在生产环境里用错误的因果图做自动化决策后果可能比直接用预测模型更严重。所以实践中有三条红线不要碰第一不要在没有领域专家复核的情况下把因果图上生产策略第二不要用单一算法、单一数据集直接下结论至少要做自助采样和敏感性分析第三不要把因果效应估计结果输出为精确数值型结论而要输出“区间估计置信度不确定性说明”。代码层面我建议把因果发现流程封装成可复用的类或流水线函数输入是 DataFrame输出是一个包含图结构、统计数据、边置信度和可视化对象的字典。这样每跑一个场景都会留下完整日志方便回溯和审计。如果团队规模足够还可以考虑用一个简单的配置文件来管理因果发现任务包括数据路径、变量列表、算法选择、方向约束和敏感性分析参数。日志记录和可复现性也必须重视。每次运行因果发现要记录数据版本、数据摘要、算法名称、算法参数、随机种子、运行时间、每一步的中间结果文件路径。这样无论是后续调参还是应对业务方质疑都能快速定位。尤其是随机种子很多因果发现算法内部有随机性不固定种子两次运行的结果可能对不上这在团队协作中是致命的。命名规范也建议统一。变量名尽量不要用 x1、x2 这种无意义符号而要用业务可读的简称比如 pay_amount、click_rate、config_ver。因果图的节点标签如果全是 x1、x2业务方很难参与讨论改成业务名称后领域知识校验的效率会成倍提升。部署策略上从最小可行项目起步。不要一开始就做一个覆盖几十个变量的大因果图那样既难验证也难解释。建议先选一个业务上最关心的子问题比如“配置变更是否是故障率上升的根因”用五到八个核心变量跑一遍完整流程。拿到足够清晰、可解释的结果后再逐步扩展变量集合。渐进式搭建比一次求大求全更容易在组织内建立信任。10. 总结与后续学习方向GENESIS 这个项目名字本身就在传递一个信号因果发现不能停留在算法竞赛的层面它必须回到“可解释、可验证、可干预”的工程语境里。今天这篇长文没有去虚构 GENESIS 的具体实现而是把因果发现落地的关键环节拆开讲了一遍——从概念边界到模拟数据验证从偏相关检验到自助采样稳定性分析。这样做是希望你先建立一个判断框架等 GENESIS 或者类似框架真正发布完整代码时你可以很快评估出它的核心能力在哪里是否值得接入你的技术栈。下一步实践建议分三条路走。如果你偏算法研究可以把 causal-learn 或 LiNGAM 的源码读一遍弄清条件独立性检验和图结构学习之间如何配合如果你偏工程应用可以从一个具体业务问题出发造一个带真实答案的模拟数据把今天这段完整流程跑通如果你对可解释性本身感兴趣可以重点关注因果发现与知识图谱结合的方向思考如何把因果图与已有的实体关系图融合形成更强的解释能力。无论选择哪条路都要记住一个核心提醒因果发现的价值不在那张图而在图背后的证据链。能讲清楚“为什么是这个原因”的工具才配谈可解释因果发现。