可重現的 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、依賴、執行與限制反向走一次；斷掉的地方，就是最值得先補的分析基礎設施。