PM 審 AI 分析的責任，不是逐行證明 SQL 正確，而是在 Execute 前確認六件事：要支持什麼決策、分析誰、分母是什麼、看哪段時間、排除哪些情況、如何驗證。這六項是業務契約；分析師或 Agent 再把它翻成 SQL，雙方各守住自己的專業邊界。
1. 這個分析要改變哪個決策？
「分析付費表現」範圍太大。更好的問題是：「判斷是否要延長新客試用期，觀察首次試用後 30 天內的付費轉換與退款。」
先確認輸出要支持的行動，才能知道需要哪些切分、比較基準與證據。若只是滿足好奇心，就不必承擔正式分析的成本。
2. 我們在分析誰，資料一列代表什麼？
問清楚對象是帳戶、使用者、訂單還是事件。一位使用者可能有多張訂單；一張訂單可能有多個品項。若 Plan 沒寫 grain，JOIN 後的重複列可能讓數字放大。
PM 不必說出 SQL 寫法，只要留下批註：「最終轉換率以 account 為單位，同一帳戶多次付款只計一次。」
3. 分子與分母分別是什麼？
「paid users」可能指曾付款、目前有效訂閱，或完成付款且未退款。分母則可能是所有註冊者、進入 checkout 者或符合資格的新客。
把公式寫成白話：
30 日付費轉換率 = 30 日內完成首筆有效付款的帳戶數 ÷ 當期首次啟用試用的合格帳戶數。
只要這句無法取得共識，現在就不該 Execute。
4. 時間從哪天算到哪天？
確認時區、日曆窗或 cohort window，以及最後一批對象是否已經有完整觀察期。例如 7 月 31 日註冊者在 8 月 1 日顯然還沒有完整 30 日資料。比較前後版本時，也要問兩組是否跨到促銷、連假或追蹤規則變更。
5. 哪些情況要排除？
測試帳戶、員工、退款、取消、重複事件、機器流量與資料缺漏，都可能改變結論。排除不是越多越好，而是每一條都要有決策理由。
一條好的 Plan 批註很具體：
paid users請排除全額退款與內部測試帳戶；部分退款保留，但在 limitations 說明。
6. 跑完後，怎麼知道數字沒有悄悄偏掉？
要求至少一個驗證 checkpoint，例如：
- 分母與既有註冊報表的量級差異是否可解釋；
- JOIN 前後 distinct account count 是否一致；
- NULL、重複 key 與未知狀態占比；
- 抽查 10 個帳戶是否符合定義；
- 新舊口徑並列，說明差異來自哪條規則。
驗證的目標不是證明「AI 一定對」，而是建立能推翻錯誤的檢查點。
一張 Execute 前的 PM 審核卡
[ ] 決策：這份結果會支持哪個選擇？
[ ] 對象：分析單位與母體是誰？
[ ] 分母：公式能否用一句白話說清楚？
[ ] 時間：時區、日期與觀察窗是否完整？
[ ] 排除：退款、測試、缺漏如何處理？
[ ] 驗證：哪個 checkpoint 能發現口徑或 JOIN 錯誤？
Lantide Data 如何讓不寫 SQL 的人參與審閱
在 Lantide Data 的 Project Analysis 中，Agent 先產出可閱讀的 Plan；PM 可直接對文字選段批註，分析師或 Agent 再依批註修正。只有使用者按下 Approve & Execute，Plan 才進入正式執行。詳見 不會 SQL 也能審 Plan 與 品質底線。
這讓 PM 專注在目標、口徑與驗收，而不是假裝成 SQL reviewer；SQL 仍會留下供分析師複查，Report 則應包含數字、evidence 與 limitations。Plan 核准也不會抬高外部 MCP connection 的 Observe／Execute／Admin 權限上限。
Lantide 能提供審閱介面與授權節點，但不能替 owner 建立業務定義，也不能保證審過的 Plan 就沒有資料缺陷。高風險決策仍應配置具領域與資料能力的 reviewer。
結語
把下一份 AI 分析 Plan 拿來，只留六條批註也可以：決策、對象、分母、時間、排除、驗證。PM 的價值不是把 SQL 寫得更漂亮，而是讓團隊在數字跑出來以前，先同意那個數究竟代表什麼。