我如何用AI生成SQL指標：從準備到驗證的實戰記錄

當AI coding在前端開發中覆蓋率突破80%時，數據部門為何仍在手搓代碼？本文作者親測AI生成SQL指標方案的實戰經歷，揭示了從指標字典準備到代碼驗證的全流程思考，以及如何通過AI解放人力創造更高價值。更重要的是，這一過程正在倒逼企業數據基建的規范化與標準化。

———— / BEGIN / ————

從今年1月份開始，筆者所在公司的前、后端開發們全都開啟了 AI coding（通過 AI 輔助編寫代碼）的工作模式。除了外采供應系統的改造開發外，其他端通過 AI 編寫代碼的覆蓋率最高甚至達到了 80% 以上?？晒P者所在的數據部門，幾乎所有的數倉依然“不忘初心”——通過手搓代碼的方式去建表、開發指標。后來和他們交流，都清一色的回復：“等我跟 AI 講清楚的時間，我自己早都寫好了”。

一開始筆者也和大多數數倉伙伴一樣，認為 AI 還替代不了數據相關的崗位，還沾沾自喜不會有裁員的風險。當每隔幾周 AI 界就會出現爆炸性的突破時，筆者突然意識到如果還拿防御性的態度對待 AI 時，那將失去和 AI 產生其他可能性的機會。今天筆者就從術與道兩個維度，結合指標 AI 生產的實踐聊聊自己的想法，也歡迎大家在下方留言討論。

忘掉自己的崗位屬性，不確定的讓 AI 來輔助你

“如果我先把這條路跑通呢？”這是筆者當時的想法，因為數據產品本身就要求了解 SQL（一種用于操作、管理關系數據庫的語言），天然對數據開發有更多的了解，于是筆者決定自己上手去干。

起初筆者想在網絡上找一些關于指標 AI 開發的成功經驗，但幾乎找不到一個可以復用的例子去模仿。后來想到 w 老師的一句話：“如果數據分析沒有思路，那就先假設一個結論，按這個方向去分析”，筆者索性假定 AI 大模型能夠執行這個任務，就問了大模型如下這句話：

我是想通過你幫我生成計算指標的 SQL ，我需要給你提供哪些必要信息？

經過一輪的調整對話后，豆包、Claude 分別給筆者輸出了各自的方案（部分截圖如下），因為 Claude 方案簡潔，我優先選定了 Claude 的方案去試驗。

理解 AI，給概率性思維設置目標與邊界

確認了方案選型后，筆者沒有立即啟動，因為 AI 開發本質是對語義的理解，理解的不同就會出現各種概率性的執行方式。這種機制對系統開發可能不會帶了極端影響，系統功能解決的是用戶需求，解決需求的結果也是多種多樣（比如，用戶登錄可以郵箱、手機登錄，也可以第三方或自己的域賬號登錄，最終結果是讓用戶可以訪問系統）?？蓴祿笜碎_發最終對應的是具體數值，且只有唯一準確的數值。所以筆者在試驗方案時，選擇以開發過的口徑復雜的指標為切入點，最終將兩段 SQL 執行的結果進行對比，驗證生成代碼的準確性。

在方案執行前，筆者準備了兩類文檔，一類是指標字典（包含指標計算口徑及其計算因子對應表、字段的血緣關系），另一類是元數據信息（包含字段名稱、字段說明等）和數據樣本，如下圖所示（數據樣本略）。

第一次讓 Claude 生成時，SQL 中的 where 條件多了三個筆者沒有在指標字典中聲明的內容。后來筆者在排查中發現了問題，因為元數據文檔我直接照搬了數倉伙伴的注釋，而這三個正好是唯一進行“值說明”的字段（如上圖紅框部分），就影響了 AI 的注意力權重。于是在調整提示詞后，筆者得到了最終的代碼。

AI 的價值不是替代人，而是解放人去創造價值

在最后執行兩段 SQL 代碼，AI 生成與數倉手搓的結果存在小數位的偏差。把兩段代碼提供給 Claude ，它快速定位到了不同點：數倉手搓的是按 SKU 單獨算天數再取整，而 AI 生成的是先匯總所有金額再統一算天數。后來在和數倉伙伴老川對數據二次計算校驗后，確認 AI 生成的計算邏輯更準確。首戰告捷，筆者非常開心，結合遇到的問題，整理出最終基于大模型的 SQL 代碼自動化生成方案（如下圖，已在筆者部門內應用）。

溫馨提示： 因為每次執行都是概率性，所以一次有效的執行動作一定要保存下來。如果經常使用可以把上述過程生成 skills，這樣以后任何時候對話，只要輸入“/技能名稱”就能調用。也可以把整個執行過程生成個文件，當下次對話時可以讓 AI 訪問這個文件，了解上次的成功經驗。

我們再回過頭來看看整個指標 AI 生產的過程，花費時間、精力最多的就是指標字典、元數據、表&字段血緣等信息的準備上，對于數倉來說確實是和 AI 對話的時間早都可以把 SQL 寫完了。但這不是一錘子的買賣，這個過程既反向要求數據部門做好數據基建（規范的數倉表架構、指標字典、元數據等），又能夠在其他數據應用上提供基礎（比如自助分析，下篇會介紹），是一個邊際成本遞減、效率不斷凸顯的過程。

讓我們成為在混亂中保持樂觀并推動事情發生的人吧~

本文來自公眾號：潮生兮 作者：潮生