快速问数与正式分析的分界，不是问题有几句或 SQL 有多长，而是「答案错了会造成多大影响」与「之后被追问或重跑的机率」。低影响、低重用的栏位探索可直接 Quick；会进周会、财务、客户沟通或跨期追踪的数字，应留下 Plan、SQL、验证与 Report。
两个问题就能先分流
把任务放进这张矩阵：
| 不太会被追问／重跑 | 很可能被追问／重跑 | |
|---|---|---|
| 错了影响低 | Quick：看栏位、查前 20 列 | 保留 SQL：例行自助查询、可重用探索 |
| 错了影响高 | 至少加验证 checkpoint | Project：Plan → 审阅 → Execute → Report |
例如「status 有哪些值」通常属于左上；「本周 paid users 有多少，要放进董事会资料」即使只需一行 SQL，也属于右下。风险来自用途，不来自技术复杂度。
以下任一条成立，就应考虑升级为正式分析：
- 数字会影响预算、人员、定价或客户承诺；
- 需要跨表 JOIN、定义分母或排除例外；
- 下周、下月还要用同一口径重跑；
- 会有另一个人接手、审阅或引用；
- 结论需要说明限制，而不是只回一个数字。
Quick 不等于草率，Project 也不等于官僚
Quick 的合理交付可以很轻：问题、查询与一句口径提醒。目的是降低探索成本，不必把每次看 schema 都变成签核流程。
Project 则把几个容易遗失的决定显性化：分析目标、分母、资料粒度、时间窗、join key、验证方式，以及结果不能回答什么。它的价值是让答案经得起第二次提问，而不是增加文件篇幅。
一个实用的升级讯号是：当对话开始出现「这里的用户是注册还是付费？」「退款算不算？」「可以按市场拆吗？」就别再把答案堆在聊天里。此时问题已从查值变成口径协作。
Lantide Data 的双轨工作方式
Lantide Data 同时提供 Quick Analysis 与 Project Analysis。Quick 适合栏位探索、SQL 语法与一次性验证；Project 则走 Plan、批注、使用者按下 Approve & Execute、正式 SQL 与 Report。详细分流可参考 Quick vs Project 指南。
这套设计的产品心智是「把治理成本放在值得的地方」：不是所有问题都流程化，也不让正式数字只存在聊天里。即使在 Project 模式，人仍须判断口径与验收限制；Lantide 不会替团队决定什么风险可接受，也不是多人 BI 监控系统。
结语
下次问数前先标记两项：错误影响为低／中／高，重跑机率为低／高。只要其中一项偏高，就至少保留 SQL 与验证；两项都高，采正式分析。流程应跟风险成比例，而不是跟问题字数成比例。