Garrett Galow, WorkOS · 19:05

這支影片在講：商業問題不要再排隊等 SQL

WorkOS Studio 把「請工程師幫我查一下」改成一個內部資料工作區：任何人可以用自然語言查 Snowflake、Linear、Notion，並把答案沉澱成可重跑的 widgets。

Published: 2026-06-11Video ID: iUWwcG-C8OU

01 / 問題

商業問題卡在工程排隊

每個需要 SQL 的問題都走同一個循環：解釋需求、等工程師、拿到答案、發現還要多 join 一張表、丟到 Slack，再重來一次。

02 / 反轉

答案要變成 widget

Studio 不只回傳一次性答案。LLM 會把探索結果寫成 declarative JavaScript widgets，之後直接呼叫資料來源，讓結果可重跑且便宜。

03 / 解法

可靠性來自三層防線

Preflight sequencing、要求模型不信自己的內部知識、以及 query validation，讓支援團隊也能安全使用資料工具。

Watch for this

影片最值得抓的四個訊號

Loop

SQL queue

問題不是資料不存在，而是每個問題都要經過人肉轉譯與工程排程。

Sources

3 systems

Studio 連到 Snowflake、Linear、Notion，讓資料問題不只停在 warehouse。

Output

Widgets

LLM 寫一次 declarative JavaScript，後續執行改走 deterministic data calls。

Reliability

Validate

每段 Snowflake query 在 hardcode 進 widget 前都先驗證，避免「合法但零結果」的錯誤。

Core story

WorkOS Studio 解掉的三個斷點

把商業語言翻成資料查詢

使用者不應該先學 schema、猜表名、補 join 條件。Studio 的入口是自然語言問題，背後再由工具取 schema、查資料並整理答案。

把一次答案變成可重跑元件

如果答案只留在 Slack，那下一個相似問題又要重做。Widget 的價值在於把查詢邏輯固定下來，讓後續執行 deterministic、便宜，而且可被團隊重用。

把模型的自信拆成可驗證步驟

影片特別強調不要讓模型憑記憶回答 WorkOS 的內部資料。它必須去 primary sources，並在寫入 widget 前驗證 query 行為。

Content map

章節地圖：從一次性查詢到可重跑工具

Part 1

重複出現的 SQL request loop每個商業問題先被翻成工程請求，等答案後又發現還需要補條件、補 join 或補資料來源。

Part 2

Studio 作為內部資料 workspace把 Snowflake、Linear、Notion 包進同一個自然語言入口，讓非工程同事能直接探索業務問題。

Part 3

把探索結果沉澱成 widgetsLLM 第一次負責理解需求與產生 declarative JavaScript；後續執行由 widget 直接呼叫底層資料源。

Part 4

可靠性來自三個 guardrails按需注入 schema、要求模型回 primary sources、發布前驗證 Snowflake query，避免把幻覺或空結果固定成工具。

Why it works

可靠性不是靠更長 prompt，而是靠工作流設計

Preflight sequencing 控制上下文污染Schema context 不是一開始全部塞進 prompt，而是在 tool 被呼叫的當下才注入。這讓 context window 保持乾淨，也降低模型抓錯線索的機率。

Layering rule 要求模型不信自己系統明確告訴模型：不要相信你對 WorkOS 的既有知識。需要答案時，回到 Snowflake、Linear、Notion 這些 primary sources。

Query validation 抓住零結果失敗有些 SQL 語法完全合法，但會回傳空結果。Studio 在 query 被 hardcode 進 widget 前先跑驗證，避免把錯誤固定成產品功能。

Widget 把 LLM 成本移到建立時LLM 負責第一次理解問題與生成邏輯；之後 widget 直接呼叫底層資料來源，不需要每次都重新推理同一件事。

Use this checklist

如果你正在做內部 data agent，先檢查這五點

常見問題是否都卡在同一個人工循環？如果團隊一直把問題丟給工程師查一次性 SQL，這不是缺 dashboard，而是缺可轉換成元件的資料工作流。

LLM 產生的答案能不能被重跑？一次性自然語言答案很快，但不能累積。把答案固化成 widget，才有機會讓每次探索變成團隊資產。

Schema 是否只在需要時注入？把所有 schema 預先塞進上下文，容易讓模型分心或選錯表。更好的做法是 tool invocation 時才補精準 context。

你是否明確禁止模型憑印象回答內部資料？內部系統會變，模型記憶不可信。資料 agent 應該被訓練成回 source 查，而不是表現得像知道答案。

合法 SQL 但零結果有沒有被測到？這類失敗最危險，因為它看起來沒有錯。Widget 發布前應該驗證 query 是否真的回到符合問題的資料。

Source video

原影片

AI Engineer · Garrett Galow, WorkOS · 約 719 viewsyoutube.com/watch?v=iUWwcG-C8OU speaker profile