可重现的 AI 分析，不是保留最后一段回答，而是让另一个人能找到相同输入、重跑相同转换、核对执行条件，并理解结果为何相同或不同。最小证据链包含来源、版本／时间、SQL、依赖、执行纪录与限制。
「把聊天存起来」还不等于可重现
美国 National Academies 将 computational reproducibility 定义为：使用相同输入资料、计算步骤、方法、程式与分析条件，取得一致结果。Reproducibility and Replicability in Science 这个定义放到商业分析同样实用。
一段对话也许记得「请算月营收」，却未必保存：当时用哪个档案、资料更新到哪天、退款何时回补、JOIN 哪个 key、模型中途建立哪些表，以及最后数字连到哪段 SQL。即使把整串对话汇出，仍可能只有操作叙事，没有可执行证据。
最小证据链的六个环节
1. 来源
记录资料表或档案名称、工作表、外部连线别名，以及必要的资料拥有者。若来源本身会变动，档名不够，还要有快照、查询时间或资料截止日。
2. 版本与时间
至少回答「何时取得」与「涵盖到何时」。同一段 SQL 明天重跑，若订单补登、退款更新或汇率表改变，结果不同可能是正常的，而非分析坏掉。
3. 转换 SQL
保留清洗、JOIN、筛选与聚合逻辑。自然语言适合说明目的，SQL 才能让人精确比较哪个条件被改动。若使用统计工具，也要保留输入表与参数。
4. 中间结果依赖
月营收可能依赖 clean_orders，后者又依赖原始订单与退款表。依赖关系若只存在执行者记忆里，重跑时很容易漏掉上游。W3C PROV 提供描述实体、活动与责任关系的标准资料模型，说明 provenance 并非只有大型平台才需要的概念。W3C PROV Overview
5. 执行纪录
记录哪些步骤成功、失败或被重试，以及实际执行的查询。只保存「预计步骤」不能证明它真的被跑过；只保存结果则无法解释如何产生。
6. 限制
可重现不等于正确，更不等于因果成立。若资料缺少取消原因、客群标签可能过期、成本资料晚一周结算，这些限制要和结果一起交付。
用「月毛利下降」做一次重跑演练
假设 Report 显示 6 月毛利率下降。合格的重跑路径应该是：
orders.csv + refunds.csv + product_cost.xlsx
→ clean_orders SQL
→ order_margin SQL
→ monthly_margin SQL
→ Report 的 6 月毛利率与限制
重跑前先核对三件事：来源是否仍是同一快照；product_cost.xlsx 是否新增回溯成本；退款表的截止时间是否改变。接着依依赖顺序执行，而不是只跑最下游。最后比较新旧 numerator、denominator 与 distinct order count。这样即使数字不同，也能定位差异来自资料、逻辑还是执行条件。
可重现不等于「永远一模一样」
若资料来源持续更新，重跑得到新数字本来就是预期行为。此时应区分两种需求：要验证旧结论，就使用相同快照与条件；要更新营运结果，就使用新资料，但保存新旧截止时间与 SQL 差异。若查询含随机抽样、机器学习或外部 API，还需记录 random seed、工具版本或外部回应版本。
同样地，成功重现只能证明同一套输入与方法可得到一致结果，不能证明方法回答了正确问题。错误分母也能被完美重跑；因此可重现性必须和 Plan 审阅、资料品质检查及 Report limitations 一起使用。
Lantide Data 的证据链如何组成
在 Lantide Data，持久 SQL 分页可保留转换逻辑；执行后的本机快取可供下游 SQL 引用，持久分页之间可形成 lineage，Source Run 依 DAG 重算上游。Project Analysis 再把核准的 Plan、执行 evidence 与 Report 串起来。工程语意可见统一查询层与 Source Run，操作可见使用者指南第 7–8 章。
但要清楚区分：Lantide 的 DuckDB TEMP 快取是目前工作区内的分析中间结果，切换工作区或重启可能清除；它不是永久资料表，也不是数仓。若需要精确重现某个历史截面，仍要在来源端保留快照或版本，必要时保存外部环境与统计工具版本。Lantide 能保留分析逻辑与依赖，不能替上游系统创造不存在的历史版本。
一分钟可重现性检查
- 我能指出每个关键数字的来源与截止时间吗？
- 我能找到产生它的 SQL 或统计参数吗？
- 我知道中间结果的上游与正确执行顺序吗？
- 我能分辨「计划要做」与「实际有执行」吗？
- 资料更新后结果改变时，我能定位原因吗？
- Report 是否保留口径与 limitations？
若有两题答「不能」，目前保存的多半是答案，不是证据链。
结语
可重现分析的目的，不是让每次重跑永远得到同一个数字，而是让差异可以被解释。先挑一份常被追问的月报，沿着来源、SQL、依赖、执行与限制反向走一次；断掉的地方，就是最值得先补的分析基础设施。