正式分析先写 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，再决定是否授权执行。