正式分析先寫 Plan，是為了在 AI 取數前把模糊需求轉成可審閱的分析契約；Execute 則是人類確認口徑與範圍後的授權事件。這多一道手續，卻能避免錯誤假設先被跑成一組看似確定的數字。
「先跑再問」如何固化錯誤
假設 PM 說：「請比較新版結帳頁上線前後的轉化率。」AI 若直接執行，可能自行選擇：
- 以進入結帳頁的 session 當分母；
- 以付款事件當分子；
- 上線日前後各 14 天；
- 排除測試帳號，但未排除退款；
- 一個 session 多次付款只算一次。
每個選擇都可能合理，組合起來卻未必是團隊要的答案。更麻煩的是，數字一旦出現在簡報裡，討論很容易轉向「為什麼升了 3.2%」，而不是回頭問「這 3.2% 的分母是什麼」。
Human-in-the-loop 不是在最後請人按「看過」，而是在高影響、難逆轉或意圖不明的節點，把決策交還給有責任的人。OpenAI 的 Agent 指南建議依工具風險設置 guardrails，對高風險動作設人類介入；Anthropic 也指出，有些缺口是偏好或意圖問題，只有使用者能解決。OpenAI Agent 指南、Anthropic：Trustworthy agents in practice
一份可執行的 Plan 要寫什麼
Plan 不該是「分析轉化率並給建議」這種待辦標題。最小版本可用以下模板：
決策問題：新版結帳頁是否值得全面推出？
分析對象：首次進入結帳頁的合格 session
分子／分母：14 天內完成付款 session／進入結帳 session
粒度：每個 session 一列；同 session 多次付款去重
時間範圍：上線前後各 14 個完整日，Asia/Taipei
排除：員工、測試流量、取消與全額退款訂單
Join key：checkout.session_id = payment.session_id
Checkpoint：每日樣本量、JOIN 前後 distinct session、裝置別分層
限制：同期行銷活動與星期組成可能干擾，不直接宣稱因果
這份 Plan 有三個作用。第一，非技術 owner 看得懂；第二，分析師能把它翻成 SQL；第三，Report 完成後能檢查執行是否偏離原始契約。
Execute 是授權，不只是播放鍵
在成熟工作流裡，探索和正式執行應分開。探索可以看 schema、確認欄位、抽樣資料；正式 Execute 才依核准 Plan 產生完整結果。這條邊界讓團隊能回答：「誰在什麼前提下同意跑這份分析？」
美國 NIST 的生成式 AI 風險管理框架強調，風險管理應涵蓋設計、使用與持續監測，也應界定人與 AI 的角色。它不是要求每個動作都人工核准，而是按情境配置控制。NIST AI 600-1 對低風險欄位預覽，逐步簽核可能過度；對會進財務預測或產品發布決策的結果，明確授權更有價值。
不會 SQL，也能審 Plan 的六個問題
- 這個結果最後要支持哪個決策？
- 誰被算進來，誰被排除？
- 分子和分母分別是什麼？
- 一列代表人、訂單、session 還是事件？
- 時間範圍、時區與資料截止日是什麼？
- 執行後用什麼 checkpoint 證明沒有重複或漏算？
只要其中一題答不出來，就值得先補 Plan，而不是期待 AI 自己猜對。
Lantide Data 如何落實這條邊界
在 Lantide Data 的 Project Analysis 中，Agent 可以探索資料並草擬 Plan，使用者則在 Plan 上審閱、批註與要求修訂。只有使用者按下 Approve & Execute，Plan 才進入 Executing，Agent 才依核准內容建立 SQL 步驟並產出 Report；操作狀態可見使用者指南的 Plan 狀態機，設計理由可見Agent 分析工作流。
這個機制適合口徑仍需協作、結果會被引用的正式分析。它不代表每個簡單問題都要建專案：一次性查欄位或驗證語法可用 Quick Analysis。Plan 也不會替你判斷商業策略；它只是把假設和責任邊界寫清楚，最後決策仍由人承擔。
結語
先 Plan、再 Execute 的價值，不是讓流程看起來更嚴謹，而是讓團隊在數字出現前先處理最便宜、也最關鍵的錯誤：問題定義錯了。下次準備正式分析時，先用六問清單審一次 Plan，再決定是否授權執行。