與 AI 協作分析 · 2/7
以前我選 Python，是因為它快速、方便、靈活。AI 加入後，我開始重新考慮這個選擇，原因也是它太快速、方便、靈活。
我用 Jupyter，它用 bash，原本以為沒什麼不同
在我接觸的 AI 分析流程裡，很常見的做法是用 Python 讀入資料，用 pandas、NumPy 寫計算腳本，執行 .py 檔案，再讀取結果進行分析。這個方法沒有不好，過去自己獨立完成分析時，我也是這麼工作的，頂多我用 Jupyter，它用 bash。Python 很方便，無論是 AI 或我自己，都很難拒絕在一個腳本裡處理好幾個 dataframe，順手完成清理、計算，再產出幾份資料。
過去分析時，哪些結果可以覆蓋、哪些要先保留、dataframe 之間依賴誰、執行順序怎麼排，大多由自己掌握（當然偶爾也會跑錯 cell，然後假裝沒事 Restart & Run All）。這套方法除了 Python，其實還依賴一個沒有寫在 requirements.txt 裡的東西：分析師腦中的執行狀態。
「對不起，我不該覆寫你的檔案」的崩潰時刻
換成與 AI 協作後，腳本大量產出、快速修改、反覆執行，一個腳本又可能同時更新好幾份資料。這時候要掌握的事情就多了：
- 這次修改只是調整計算，還是順便重跑了清理？
- 哪份中間結果已經被覆寫？
- 下游報表引用的，還是不是剛剛確認過的那份資料？
即使腳本加了許多註解，也不代表這些依賴與執行狀態就容易理解。更麻煩的是，本機分析環境即使有 Git，通常也只管了程式碼，沒有替每一次資料產出保留版本。找回上一版 .py，不代表上一版結果也跟著回來了。
以前我們靠 Python 的靈活，搭配「可靠的自己」完成分析。現在旁邊多了一個「對不起，你說得對，我不該覆寫你的檔案，下次不會了」的 Agent，原本靠大腦掌握的分析產物，突然變得更難懂、更脆弱。我開始思考：AI 已經大幅降低寫程式的成本，那我是不是可以接受工具少一點靈活，換取自己更容易理解、審閱和接手？
以 SQL 為基底，讓 AI 做得快，人類跟得上
我得出的答案是 SQL-first。這是對分析工作流的選擇，SQL 本身不會自動提供只讀權限、依賴管理或資料版本；這些仍需要由查詢環境與工作區落實。原因主要有兩個：
- 邊界比較容易限制：讓 Agent 透過受控的只讀查詢分析資料，結果保存與更新則交給工作區管理
- 輸出比較容易拆分：一段
SELECT對應一個結果集，方便命名、審閱與建立依賴，也更適合作為 Plan 裡的計算契約
SQL 當然不是萬靈丹，長起來一樣可以很難讀，統計、ML 和不少特殊處理也還是 Python 方便得多。所以我的作法是以 SQL 打底，再透過 workspace 模組補上需要的能力：
- 統一查詢層：讓不同來源的資料能在同一套查詢方式下進行跨源分析
- 自動快取：保存需要復用的中間結果，讓後續查詢可以繼續引用
- DAG 執行：把結果之間的依賴與重跑順序攤開，讓人與 AI 都能清楚解讀
- 統計模組：補上 SQL 較弱的分析能力，需要時仍然使用 Python
這些模組不會自動讓每一份資料都有版本，但能把原本藏在腳本與腦中的依賴，變成工作區裡看得見、管得動的「分析資產」。
當然，這比不上 AI 直接下 Python 的快上加快。但在無數次迷失於 AI 的 .py 海洋後，這個差異在我看來幾乎可以忽略不計。我真正在意的，是從產出結果，到能理解、驗證並拿來決策，總共花了多少時間。
延伸閱讀
在 Lantide Data 中試用這套分析工作方式：下載 Lantide Data。
上一篇：AI 完成了分析，誰來解釋它為什麼這樣算？ · 下一篇：分析整理成 Skill 之後，為什麼 AI 還是用錯口徑？