讀時間： 約 5 分鐘 · 系列： 業務與運營實踐 · 上一步： Report 轉 HTML · 下一步： 與 BI 看板分工
好批註 vs 壞批註
| 壞批註 | 好批註 |
|---|---|
| 「再算一下」 | 「分母改為 paid orders，排除 status=cancelled」 |
| 「數字不對」 | 「時間窗應為 5/20–6/20，不含預熱期」 |
| 「跟上次不一樣」 | 「stage2 應為已付款，不是已建單」 |
| 「快點 Execute」 | 「上述三點確認後再 Execute」 |
批註要 可執行：分析師或 Agent 讀完知道改 Plan 的哪一句、改成什麼。
怎麼操作（概要）
- 打開專案中的 Plan，切到 Visual 模式
- 選取 要改的句子或表格
- 點批註，寫下修改意見
- 分析師 Resolve 後，Agent 只改被批註段落
Resolve 之後：
- 已處理批註可用 View changes 對照修改前後（Popover 或長文對話框）
- 確認無需再追蹤的批註可 Archive，保持右側面板可讀（history 仍保留）
- 若你大幅改過正文、批註出現 錨點失效，需由分析師 Re-anchor（重新反白原文）——業務方通常只留批註、不自行 Re-anchor
完整步驟見 USER_GUIDE §11.7。
你不該做的兩件事
- 替分析師按 Execute 卻沒親自讀 Plan — 問責仍會回到分析負責人
- 要求跳過 Plan 直接要 Report — 短期快，長期口徑糾紛成本更高
若時間只夠 Quick 探索，請分析師明確標註 非正式數字，不要拿進簽核流程。
與 Slack、會議的分工
- 會議：對齊決策與優先級
- Plan 批註：把決議寫進口徑契約
- Slack：通知「Plan 已更新，請再看第三段」— 但 不能代替 Plan 上的批註
你現在可以做的一件事
練習一條批註模板：「請將 [原文摘要] 改為 [你的定義]，原因：[業務背景一句]。」下次審 Plan 直接套用。
下一步
- 與 BI 看板、週會簡報的分工
- PM：跨角色協作（PM 視角）
- 業務與運營引言