Genie Code 把 Databricks 變 ML 指揮台

我把 Databricks 的 Genie Code 更新拆成一套可直接抄的 ML 工作流模板，重點是怎麼把長任務、排程和審核接進同一個工作區。

我用 agentic coding 工具一陣子了，越用越知道哪裡怪。Demo 很會講，叫它改個 notebook 也像那麼回事；但一碰到真的資料工作，就開始散成一地。Notebook 在這邊，SQL 在那邊，模型 run 又是另一頁，Serving endpoint 還躲在別的角落。最煩的是，對話 thread 也像快要壞掉的便利貼，關了怕丟答案，不關又一直卡著。我不是不想要 agent，我是不想再用一個只有聊天框、沒有工作台的東西。

這次我是在 Databricks 的 Genie Code 更新文章裡，第一次看到有人老實承認這個問題。文章作者是 Julia Powell、Gal Oshri、Weston Hutchins。Databricks 還提到 Genie products 成長超過 10x、而且有 90% customers 在用，這種數字很吵，表示它已經不是邊角料，而是被塞進預設流程裡了。

他們終於承認：單一 prompt 根本不夠

A user may need to inspect existing logic, update multiple assets, run code, review outputs, and refine the next step based on results.

翻譯一下就是：真正的資料工作不是叫 AI 寫一段字就結束，而是一路查、一路改、一路驗證。你今天要做的通常不是「幫我寫 query」，而是「先找出哪個假設錯了，再看 pipeline，修 notebook，重跑 job，比對輸出，最後把 dashboard 為什麼變掉講清楚」。這種事本來就不是一個 prompt 能收尾的。

Databricks 這次比較誠實的地方，就是它沒有假裝 side panel 的聊天框可以撐住這種工作。它把 Genie Code 拉成 full-page experience，我覺得這一步很對。因為 context 就是產品。當我同時在看 notebooks、SQL、Lakeflow pipelines、dashboards、jobs、models、serving endpoints、Unity Catalog assets 的時候，我不想把 agent 塞在旁邊像客服小工具。

我之前 debug 一個 pipeline failure 時就很有感。答案分散在三個頁面，model run 在一處，真正有用的線索又藏在 thread 裡。那種時候你需要的不是更會講話的 bot，而是一個能把整條線攤開的工作區。命令台式的設計，至少不會讓我每切一次工作就把腦袋打散一次。

實操上，我會直接把 agent workflow 從「一次性問答」改成「可續跑的 session」。任務要能被重新命名、搜尋、回頭看，還要能留下審核點。只要工作跨過一個 artifact，窄窄的 chat panel 就會變成負擔，不是幫手。

真正有用的不是聊天，是可以排隊並行

這篇文章裡我最在意的一點，是它支援多個 Genie Code threads。Databricks 說，使用者可以看到 thread 正在執行還是在等輸入，等結果回來再接著看。這句看起來很普通，但你只要做過十個半成品 investigation，就知道這是救命功能。

白話一點，這不是 conversation bubble，這比較像 work queue。對資料工程和 ML 來說，這個心智模型才對。我可以把一條 thread 留給 feature cleanup，另一條留給 model comparison，第三條留給 dashboard discrepancy，不用全部擠在同一個模糊 session 裡互相污染。

• 把 thread 改成可辨識的名字，兩天後才看得懂自己在幹嘛。
• 能搜尋舊 thread 就不要每次重開一個新的。
• 用狀態提示分清楚哪些在跑、哪些在等你補資料。

文章也提到 instructions、skills、connectors 更容易找了。這不是 UI 小修小補而已。這類工具會不會真的變好用，關鍵常常就卡在這裡：它知不知道你的規範、你的 workspace 習慣、你的資料來源。如果知道，它才不會一直問蠢問題。

我會把這種命令台當成 agent 的 control plane，不是 chat UI。把團隊規則放進去，把對應的 connectors 接好，再替每個 thread 定義 owner 和 outcome。沒有這些，最後只會多出一堆看起來很忙、其實沒收尾的工作。

ML 的重點從來不是訓練，是中間那堆爛事

Databricks 這篇有一句我很買單：大部分 model work 根本不是 training model，而是 feature、experiment、evaluation、productionization，還有上線後的維護。這才是團隊最耗時間的地方，也是很多模型最後沒真的進產線的原因。

Genie Code for machine learning 的定位，就是去打這個 boring middle。Databricks 說它不是另外一個你要重新學的工具，而是同一個 agent，往 production ML engineering 方向專門化。這點很重要，因為資料團隊最常死在切工具。Notebook 一套、model registry 一套、serving 又一套，每切一次就掉一次節奏。

文章還提到兩種 knowledge：一種是 Databricks 自己的 production ML 經驗，另一種是你團隊的 patterns，也就是它說的 Genie Ontology。我把這理解成：它不是只學通用語法，而是學你們團隊怎麼 build、怎麼 evaluate、怎麼決策。

這就是我最在意的地方。一般 coding agent 很會湊 syntax，但很不會處理 business tradeoff。它不知道哪個 metric 才算真的重要，不知道哪個 evaluation set 才是可信的，也不知道哪個 shortcut 會讓你在 prod review 被罵。若它真的能吸收團隊 pattern，那它幫的就不只是寫 code，而是在保存團隊記憶。

實操上，我會把 ML workflow 寫得夠明確，讓 agent 看得懂。feature pattern、evaluation script、promotion rule 都要文件化，不要藏在某個 senior 的腦袋裡。你要它幫 production ML，就得先給它地圖，不然它只會一直猜。

MLflow 和 serving 才是這次最像真的地方

Databricks 在這裡講得很具體，我反而比較信。Genie Code 可以讀 MLflow runs、artifacts、lineage、quality metrics 和 system metrics，也能看 Model Serving endpoint 的 health 和 performance。它還知道 compute，會去用 AI Runtime for GPU jobs，或者透過 workspace environment features 幫你把環境設好。

這就不是「會寫 code」而已了，這是「懂系統」。如果 agent 看得到你的 runs，它就能回答像是 GPU utilization 要怎麼調、模型該追哪些 metrics 這種問題。如果它看得到 serving health，它就能幫你查 endpoint 為什麼變慢、為什麼不穩。這比一個只會建議你重構的 generic bot 實用太多。

• 把 MLflow 當成 model experiment 問題的 source of truth。
• 遇到 latency、error、traffic 問題，就直接看 serving diagnostics。
• 讓 compute awareness 幫你省掉那些很煩但又必須做的 setup 步驟。

我看過太多團隊卡在「assistant 看得懂 code，卻看不懂 runtime」這種荒謬狀況。那在 production 裡根本不好笑。只要把 agent 接到 MLflow 和 serving，它就開始有機會碰到 lifecycle，不只是 notebook 裡那一小段。

實操上，如果你本來就在 Databricks 上做 ML，我會優先把 agent 接到已經定義你流程的 artifacts。不要叫它自己猜什麼重要，直接給 runs、metrics、lineage、serving data，然後用這些資料來做 review，而不是只看 code diff。

排程任務一上來，節奏就變了

文章裡說 scheduled tasks soon coming，這一段我覺得才是真正把 Genie Code 往前推的地方。你可以給它一個 prompt，再附 notebook、workflow 或 dashboard，然後讓它晚點自己跑。做完之後，它會把結果丟回一個 thread 讓你 review。

這看起來不大，但它解鎖的是整批原本很煩的工作：隔夜 job check、每週分析準備、dashboard metric 說明、模型表現會前整理。這些事我以前都得靠記憶和待辦清單硬撐，老實說很爛。人類很不適合做這種重複又沒新鮮感的排程工作。

我喜歡它還保留一個邊界：agent 可以先做，但最後還是要人 review。這才是資料和 ML 裡合理的 autonomy。我要的是它先整理證據、先寫草稿、先把診斷跑完，不是它自己覺得很有把握就去改 production。

文章也提到 Genie ZeroOps，會盯 live systems，先準備 fixes 再交給人看。這就是同一個模式，只是對準 production incident：model drift、serving errors、upstream pipeline problems。說穿了，就是讓 agent 先做第一輪 boring incident response，再由人決定要不要真的動手。

實操上，我會先分清楚哪些 recurring tasks 可以自動產出「草稿」，哪些只能停在建議。只要最後結果是 summary、diagnosis、recommendation，通常都適合先自動化。只要會碰 production，就一定要有人卡最後一關。這條線比行銷文案重要多了。

這篇真正的訊號，是 Databricks 在押 AI-native workflow

如果只看單一功能，很容易看不出來。但把整篇串起來看，方向其實很明白：Databricks 想做的是一個 agent 內嵌在平台裡、看得到資產、看得到 runtime、也能在 dev 和 ops 之間來回移動的 workflow。

這很符合現在資料團隊的現實。做 model 的人，最後常常也得去查 pipeline、看 dashboard、跟 PM 解釋 serving 行為。所謂 dev / ops 的分工，在資料系統裡本來就沒那麼乾淨。Genie Code 的設計，基本上就是順著這個混亂世界去長，而不是硬把世界切成兩半。

我覺得這是這次最務實的地方。不是在講 AI 會把 workflow 全部換掉，而是說：你原本那套 workflow，其實可以少一點切頁、少一點手動 glue、少一點找不到上下文的痛苦。

實操上，如果你在評估 agentic tools，我會直接問幾個問題：它看得到 data、model、experiment history、serving layer 嗎？它能不能跨 session 持續工作？它產出的是可 review 的東西，還是只是在那邊很會聊天？如果都不是，那你買到的只是有野心的文字框。

可抄的模板

# Databricks Genie Code ML 工作流模板（可直接套用）

## 1) 先把 thread 命名清楚
用一眼看得懂的名稱，不要用「test」或「fix this」。

範例：
- model-drift-daily-check
- feature-pipeline-debug
- serving-latency-investigation
- weekly-business-metric-review

## 2) 給 Genie Code 一個完整任務
不要只丟一句「幫我看一下」。要寫成工程任務。

模板：
"Inspect [asset]. Identify the root cause of [problem].
Use [notebook / workflow / dashboard / model / endpoint].
Compare the current result with [baseline].
Summarize findings, list risks, and propose the next action."

## 3) 附上真的有用的上下文
把它需要的 artifact 一起給：
- notebook
- SQL query
- Lakeflow pipeline
- dashboard
- MLflow run
- model registry entry
- serving endpoint
- Unity Catalog asset

## 4) 放進團隊規則
短一點、具體一點。

範例：
- 優先使用 Delta tables，不要亂拉 ad hoc extract。
- 以 MLflow metrics 作為實驗結果的 source of truth。
- 任何 feature leakage 風險都要標出來。
- 沒有批准前，不要改 production endpoint。
- 用 business terms 解釋 tradeoff，不要只講技術細節。

## 5) 先定義 review loop
開始前就先說清楚什麼叫 done。

模板：
- 已收集證據
- 已找出 root cause
- 已寫好 recommendation
- 人工 review diff 或輸出
- production change 另外批准

## 6) 把 recurring work 丟給 scheduled tasks
適合的情境：
- overnight job checks
- weekly model review
- dashboard metric summaries
- pipeline health summaries
- serving endpoint health checks

Prompt 模板：
"At [time], review [asset].
Summarize changes since the last run.
Call out anomalies, failures, or regressions.
Draft the next action for human review."

## 7) 留 audit trail
每個 thread 都記：
- owner
- date
- asset
- decision
- follow-up action

## 8) 不要自動化這些事
不要讓 agent：
- 在沒有 review 的情況下合併 production changes
- 在不穩定資料上自動 retrain model
- 偷偷改 business logic
- 用很有自信的口氣掩蓋不確定性

## 9) 可直接複製的總提示詞
"You are helping with a Databricks production ML workflow.
Inspect the attached asset(s), identify issues, compare against the baseline, and produce:
1. root cause
2. evidence
3. recommended fix
4. business impact
5. open questions
Do not make unreviewed production changes."

這份拆解是我根據 Databricks 原文整理出來的工作流版本，不是官方文件。原始來源是 https://www.databricks.com/blog/whats-new-genie-code-data-ai-summit-2026。裡面的結構和可抄模板是我重寫的，方便台灣開發者直接拿去用。