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 写得更漂亮，而是让团队在数字跑出来以前，先同意那个数究竟代表什么。