讀時間： 約 6 分鐘 · 系列： 產品經理實踐 · 上一步： vs Chat / BI · 下一步： 品質底線
你是業務 / 運營？
若你的工作是 審 Plan、驗 Report、週會拍板（不是評估要不要推工具），請讀 業務與運營引言——本篇從 PM / 採用決策 視角說明協作。
各角色在流程裡做什麼
sequenceDiagram
participant PM as PM / 業務
participant Analyst as 分析師
participant Agent as Agent
participant Eng as 工程（可選）
PM->>Analyst: 提需求
Analyst->>Analyst: 聚焦專案
Analyst->>Agent: 啟動探索
Agent-->>Analyst: 草擬 Plan
Analyst-->>PM: 請審 Plan
PM->>Analyst: 批註 Plan
Analyst->>Agent: Resolve / 修訂
Agent-->>Analyst: 增量改 Plan
Note over Analyst,Agent: Execute 前：Agent 不代按、不擅自取數
Analyst->>Agent: 按 Execute
Agent->>Agent: 跑 SQL、寫 Report
Agent-->>Analyst: Report
Analyst-->>PM: 交付 Report
PM->>PM: 週會交付
Note over Eng: 連線 / MCP 等基礎設施（與分析流程並行）
PM 不需要 自己寫 SQL 或按 Execute（除非你就是分析師）。PM 需要 在 Plan / Report 上留下可追蹤的共識。
PM 最該參與的兩個時點
1. Plan 審閱（Execute 前）
這是 口徑簽核 的窗口。你應確認：
- 分析目標是否對應你的決策問題
- 分母、時間窗、stage 定義 是否符合業務理解
- 有沒有「預設了但我們從沒同意過」的假設
怎麼做： 在 Plan Visual 模式 選文字 → 批註。不要只在 Slack 說「改一下分母」——口頭容易漏改。分析師 Resolve 後，雙方可用 View changes 確認改動；已處理批註可 Archive 保持 Plan 面板整潔。
不要： 在 Plan 還在 Planning 時催「先出數」；Execute 前催只會把風險推到 Report。
2. Report 驗收（Execute 後）
看 數字是否回答你的問題，以及 limitations 是否誠實（例如未含退款、樣本期偏短）。
可批註修措辭、補充 context；若口徑錯誤層級，應 新 Plan 重跑，而不是只改 Report 文字。
Execute 為什麼必須「看得見是誰按的」
Execute = 人類明確授權：「這版 Plan 我（們）認可，可以正式取數。」
- Agent 不能 在 Planning 或聊天裡代替這個動作
- 按鈕在 Plan 工具列，不在 AI 對話裡藏指令
- 週會問責時，可以問：誰在什麼 Plan 版本上按了 Execute
這不是不信任 AI——是區分 探索 與 正式對外數字。
和 Slack / 會議的分工
| 渠道 | 適合 |
|---|---|
| Slack / 會議 | 提需求、排優先級、討論決策 |
| Plan 批註 | 口徑修改、假設確認 |
| Report | 對外引用、HTML 匯出、週會附件 |
Project .lantide |
跨人交付可審閱的 Plan／Report／批註（共享分析脈絡與結果；不含 SQL 分頁與資料檔） |
若分析師要把整個工作環境交給同事接續（含 SQL 分頁、連線設定、可選對話），那是 Workspace 匯出——見 USER_GUIDE §11.1.0 或 平台：.lantide 匯出匯入。
反模式： 會議說定口徑，Plan 沒改；或 Plan 改了三版，Slack 還在引用第一版截圖。
PM 不該做的兩件事
- 替分析師按 Execute 卻沒讀 Plan——問責仍會回到分析負責人
- 要求跳過 Plan 直接要 Report——短期快，長期口徑糾紛成本更高
若時間真的只夠 Quick 探索，明確標註「非正式數字」，不要拿進簽核流程。