有些 AI 團隊真正浪費時間的地方，不在模型費，也不在 GPU。
而是在那份「昨天明明跑過」的 notebook。
開會前十分鐘，工程師重新打開檔案，某張圖不見了。產品經理指著上週截圖說這格當時不是這個數字。有人說可能是 cell 順序跑亂了，也可能是某個中間變數還留在記憶體裡。最後大家只好把那次結果當成「先參考」，再花半天重跑一次。
這種場景在 AI 團隊很常見，尤其當 notebook 不只是研究筆記，而是 prompt 實驗台、資料清理台、embedding 比對台、eval 報告台，甚至是 demo 現場本身。
marimo 值得看的原因，就在這裡。
它不是單純做一個比較現代的 Python notebook，而是在重新定義一件事：AI 實驗到底能不能從一次性草稿，變成可交付、可版本控、可延伸成工具的工作台。
English TL;DR
- marimo is a reactive Python notebook designed to make experiments reproducible, git-friendly, scriptable, and deployable as apps.
- Its value for AI teams is not just nicer notebook UX. It reduces a real operational problem: notebooks that look correct in demos but fail to reproduce, collaborate, or ship.
- It is especially useful for teams doing LLM experiments, prompt evaluation, data QA, lightweight internal AI tools, and agent-assisted notebook workflows.
- But it is not for everyone. If your team is not Python-first, only needs a scratchpad, or is building a full production web product, marimo may be the wrong layer.
- Pragmatic takeaway: evaluate marimo when your notebook output needs to survive handoff, review, and reuse, not just a single author session.
你不是在選筆記本，你是在選實驗會不會在交付前變形
如果你是團隊裡那個要把 AI 實驗交給別人的人，你很快就會發現，傳統 notebook 最大的問題不是它不好寫，而是它太容易只對原作者自己成立。
marimo 的核心設計很直接。它把 notebook 做成 reactive 的執行環境，cell 之間的依賴關係會被分析，某格變了，相關的後續格子就跟著更新，或在 lazy 模式下被標記為 stale。刪掉一格，對應變數也會從記憶體裡清掉。它想處理的，就是 Jupyter 類工作流裡最常見的 hidden state 和 out-of-order execution。
這件事聽起來很像實作細節，但對 AI 團隊其實是管理問題。
因為今天 notebook 早就不是研究員個人的沙盒。它很可能會被拿去做 prompt 對照、模型比較、資料標註檢查、內部 demo、甚至直接變成給同事用的小工具。只要有第二個人要接手，那份 notebook 就不只是你自己的草稿，而是一種半成品系統。
marimo 讓我覺得值得寫的地方，是它很清楚知道自己不是在賣「更漂亮的 notebook」，而是在補這段半成品系統最常漏水的地方。
昨天那格有跑過，今天怎麼又不一樣
很多人對 notebook 的忍耐，其實建立在「反正只是探索」這個前提上。
但 LLM 時代把這前提悄悄改掉了。現在很多團隊會在 notebook 裡做的事情，不只是一張圖或一次分析，而是：
- 比較不同 prompt 與模型輸出
- 檢查抽取欄位與結構化結果
- 測 embedding、reranker 或 chunking 策略
- 跑小型 eval，給 PM 和老闆看版本差異
- 做一個能互動的內部 demo 給營運或客服試
這些工作都有一個共同點，它們不是只要「跑得出來」就夠，而是要讓別人能相信這次跑出來的東西還能再被重現。
marimo 用純 Python 檔儲存 notebook，而不是一大包 JSON。這讓它比較適合做 Git 版本控，也能直接當 script 執行，甚至用 marimo run 直接變成 web app。這個路徑很實際，因為很多 AI 團隊最後卡住的不是分析做不完，而是成果永遠停在「截圖、錄影、口頭說明」，很難再往前走一步。
我很在意的一個小細節是，marimo 官方文件花很多篇幅在講 reproducibility、no hidden state、script、app、testing，而不是只拚一堆炫技畫面。這種排序有點像在對使用者承認一件事：
AI 實驗最怕的不是不夠酷，是酷完之後沒人接得住。
它最有感的，不是研究炫技，而是三種很實際的工作
場景一，AI 產品團隊要做 prompt / model / data 的反覆比較
這是 marimo 最直接的戰場。
你今天可能要比三個模型、兩種 system prompt、兩個欄位抽取規則，再加上一份人工標註資料。若用傳統 notebook，常見情況是每個人各自複製一份、各跑一版，最後留下六個看起來很像、但不確定哪份才是最新的檔案。
marimo 比較適合這種反覆比較型工作，因為它把依賴關係、互動元件、Python 程式、SQL 查詢放在同一條工作流裡。你可以做 slider、dropdown、table filter，讓非工程角色也看得懂差異，而且這個產物不是只能存在你電腦裡的那份筆記。
對 AI 團隊來說，這意味著實驗開始比較像可審閱資產，而不是一次性操作紀錄。
場景二，分析 notebook 最後要長成內部工具
這種轉換在 AI 專案特別常見。
一開始只是想讓內部同事看看分類結果、文件抽取欄位、召回品質。後來營運說能不能自己選日期、自己過濾資料、自己切不同客戶。再過一週，它就變成一個「其實大家每天都會開」的小工具。
marimo 的優勢，是 notebook、script、app 三者之間的距離比一般流程短很多。你不一定要先把探索階段丟掉，重寫成另一套 UI。很多時候，把 code 隱起來、整理 layout、補幾個互動元件，就能先形成可用版本。
這很適合那些還不想正式開一條完整前端專案、但又不希望 demo 每次都靠原作者親自操作的團隊。
場景三，讓 agent 幫你改 notebook，但不是亂改
marimo 另一個和 AI 很貼近的點，是它把 agent 協作這件事做得比我預期更實際。
官方文件裡的 marimo pair，目標不是讓 AI 幫你自嗨生成幾格 code，而是讓 agent 能讀 notebook 內的變數、操作 cell、跑 scratchpad、調整 UI。這個方向很重要，因為 AI coding assistant 進入資料與實驗工作流後，最容易出事的地方，就是它只看檔案文字，卻不知道執行狀態。
如果你的團隊已經在用 Claude Code、Codex 這類 agent，marimo 這條線其實值得注意。它在補的是「代理能不能真的看懂你現在這份實驗活在哪裡」，不是只有 autocomplete。
有時候最貴的不是模型，而是你把草稿誤當系統
marimo 的價值，不是每個人一打開就會尖叫說好厲害。
它比較像那種你做過幾輪 AI 專案之後，會突然覺得「這段真的有人幫忙收乾淨了」的工具。
我看過很像真人現場才會出現的一幕。開評審會時，大家不是在討論模型理論，而是在安靜地追問一件很小但很致命的事：
「這個表到底是這版 code 算的，還是上一版留下來的？」
只要這個問題沒辦法被快速回答，後面所有判斷都會開始變虛。marimo 不是保證你做出更好的模型，但它有機會讓你少掉這種低級又昂貴的不確定感。
先別神化，它也有明確邊界
1. 它很吃 Python 世界，這不是每隊都合適
如果你的主要技術棧是 TypeScript、前端主導，或資料團隊本來就不在 Python，marimo 的吸引力會下降。它最強的地方，本來就建立在 Python notebook 工作流上。離開這個前提，它不一定是最划算的層。
2. reactive 模型雖然解決問題，也會帶來新習慣成本
對習慣手動控制每格執行的人來說，reactive notebook 一開始會有點不一樣。尤其當某些 cell 很貴，像是大量 embedding、遠端 API 批次呼叫、長時間資料處理，就要配合 lazy runtime、form、cache、persistent cache 一起設計，不然還是可能踩成本。
也就是說，marimo 不是魔法，它只是把混亂改成可管理，但你還是要管理。
3. 它可以把 notebook 長成 app，不代表它要取代完整產品前端
marimo run 很適合內部工具、展示頁、分析型互動介面。
但如果你要做的是重度多使用者產品、細緻權限、複雜後端邏輯、完整品牌化前端，它不是 React、不是 Next.js，也不是正式產品框架。把它當成整個產品層，通常會高估它。
4. 它不是 MLOps 平台，也不是 AI workflow orchestration 系統
如果你的問題是模型部署、批次排程、線上觀測、資料血緣、長流程任務編排，那 marimo 不是主解。它比較靠近「實驗與可交付介面層」，不是整條平台底座。
這點反而要先講清楚，才不會把一個好工具放到它不該扛的位置。
如果今天不選 marimo，多半是因為你在解別的問題
如果你只要最自由、最通用、全世界都會用的研究草稿環境，Jupyter 還是有它的地位。
如果你已經很確定目標就是快速包一個互動 app，Streamlit 或 Gradio 可能更直接。
如果你要的是完整產品級前端與後端控制，那就老實回到 web stack。
marimo 厲害的地方，不是全面取代它們，而是它站在一個很準的位置上：
當你的 notebook 不想再只是 notebook，但也還沒大到值得重開一條工程線時，它剛好補上那段尷尬地帶。
結尾判斷
marimo 不是那種靠一句「AI-native」就該被追的 repo。
比較務實的看法是，它解的其實是 AI 團隊近一年越來越明顯的一個工作問題：實驗產物要怎麼活過原作者那一台電腦。
採用判斷可以很簡單：
- 如果你們是 Python 為主的 AI / data 團隊，常用 notebook 做模型比較、資料檢查、prompt 實驗，且成果常常需要交給別人接手，marimo 很值得現在看。
- 如果你只想隨手探索、做一次性草稿，或你真正需要的是完整產品框架與平台能力，那先別急著上。
它不是最吵的 AI repo，但很可能是那種一旦進入工作流，就不太想退回去的工具。