前兩期電子報 介紹讓我眼睛一亮 Magic Cue 之後，我回去筆記中複習我的「AI 白日夢清單」，想起另一個讓我超級期待的工具。雖然我還沒用過（甚至不確定它是否真的能用），但光是看到它的概念就讓我興奮不已：
nao：給資料科學團隊用的 Cursor
為什麼 Cursor 寫不出真正實用的 SQL？
我們先聊聊為什麽資料分析工作只靠 Cursor 不夠用。
別誤會，Cursor 真的很棒！寫 Python、JavaScript，甚至複雜的演算法都沒問題。但資料科學家們應該都有經驗，每次要它幫我寫 SQL 時，就會陷入一種「明明 SQL 語法都對，但就是不能用」的絕望。
舉個例子：我想分析上個月各地區的用戶活躍度。我跟 Cursor 說：
「幫我寫個 SQL，查詢上個月台灣用戶的每日活躍數據（DAU）」
Cursor 盡責地給我一個語法完美的查詢：
問題來了：我們公司的資料表根本不叫 user_activity，而是叫 events_log。國家欄位也不是 country，是用 region_code。
你有看出問題嗎？為什麼 Cursor 會這樣寫？
程式碼 vs 資料：一維與二維的差別
nao 的官方文章 提出深刻的觀點：寫程式是一維的，而資料分析是二維的。
寫一般程式時，輸入是程式碼，輸出也是程式碼，所以是一維。AI 只需要理解語法和邏輯就夠了。
但資料分析不一樣：
- 輸入：你的商業問題 + 實際的數據現況
- 輸出：SQL 程式碼 + 根據的分析結果
換言之，程式碼跟數據都得包含在 AI 看得到的脈絡（Context）才能分析，所以是二維。
Cursor 只看得到第一個維度（程式邏輯），完全看不到第二個維度（你的資料現在長什麼樣子）。
你可能會說：「那用 MCP（Model Context Protocol）不就好了？」
確實，像是 dbt MCP 這類工具可以讓 AI 「看到」你的資料庫結構。但問題是：
- 設定複雜：光是搞懂 MCP 怎麼連接我的 Snowflake 就花了半天
- 只給工具，不給脈絡：AI 還是得透過一堆 function calls 才能理解我的資料
- 體驗破碎：自動完成功能還是會有幻覺、產出不存在的資料表
就像給一個人一支手電筒，讓他在黑暗中摸索房間，而不是直接開燈讓他看清楚整個房間。
nao：我的資料分析白日夢
nao 聲稱要成為「資料團隊的 Cursor」，它的方法讓我眼睛為之一亮：
直接連接你的資料倉庫，把資料的 schema 當作 AI 的原生語言。
想像一下這個場景：
- 我：「分析上個月的用戶留存率，找出異常的地區」
- nao：立刻知道要用
events_log 資料表
- nao：自動生成正確的 SQL，執行查詢
- nao：產生視覺化圖表，標出異常地區
- nao：建議下一步分析方向
俐落、輕鬆、美好！
最棒的是，這些分析會被記住、成為脈絡之一。下次類似問題出現時，我不用重新解釋什麼是留存率，或是我們公司的資料結構。
相較之下，想想當紅、功能也特別多元的 AI 寫程式工具，包括 Cursor、Google AI Studio、Claude Code 等等，它們可以依照你要求生成 SQL，但你還是要到資料庫 *手動* 將 SQL 複製貼上查詢；慢慢等到資料回傳，還要再把資料 *手動* 傳給 AI 工具看、請它畫出圖表。以上這些機械化、反覆的動作，nao 宣稱它可以一次到位！
這些都是我在做白日夢的時候，期待資料科學 AI Agent 能做到的事情。
必須承認，我對 nao 的描述都是基於他們的公開資訊（和我的想像），我沒有實際使用過這個工具，甚至不確定它是否已經完全可用。
然而，在這個 AI 工具滿天飛的時代，每天都有一個新的「革命性」AI 產品出現，我都看到麻木了 (ｰ ｰ;)
找到像是 nao 這樣針對特定領域深度最佳化、又符合我的資料科學工作需求，已經讓我又燃起對 AI 工具發展充滿期待的心情。
關於我的「AI 白日夢清單」，我最近寫了一篇更完整的思考：
👉 2025 讓我充滿期待的三個 AI 產品
文章裡，我不只聊了 nao，還分享了其他聽起來很科幻、但真的有可能成真的 AI 產品概念。畢竟，我不想被動地接收 AI 資訊，偶爾我想從自己的需求出發，問自己：什麼樣的 AI 工具，才能真正改變我的工作和生活？
