使用情境
从痛点到解法，Lantide Data 如何支援真实分析工作
结构化分析专案
A/B 测试、漏斗、异常侦测
业务场景
电商、SaaS、游戏、订阅制产品等高度依赖数据决策的产品与成长团队，经常需要分析 A/B 测试、转换漏斗、留存变化与异常指标。
使用者
林 PM (Claire)，某 B2B SaaS 公司的产品经理，负责新功能上线后的成效评估。
痛点
Claire 想知道新版 onboarding 流程是否真的提升启用率，但过去用聊天式 AI 问资料时，结论散落在对话里，SQL、假设、筛选条件与分析逻辑都难以追溯。主管追问「这个结论怎么来的？」时，分析师只能回头翻聊天纪录与 SQL 分页，无法形成可审阅、可版本化的分析流程。
解决方案
- 1
分析师与 Agent 协作撰写 Plan
分析师与 Agent 先共同把分析目的、资料范围、成功指标与方法论整理成 Plan，让 PM、主管与分析师在执行前先对齐问题定义。
- 2
批注审阅达成共识
Claire 可直接在 Plan 上批注，例如要求排除内部测试帐号、拆分新旧客群，所有修改都保留在文件脉络中，不会消失在聊天气泡里。
- 3
Execute 产出 Report
当 Plan 被确认后才执行分析，系统锁定 Executed Plan 并产出 Report，让结论、方法与版本完整对应，日后可以清楚追溯。
隐私与合规
本机优先、敏感资料
业务场景
医疗、金融、跨国零售等受到 GDPR / ISO27001 严格法规监管的企业团队。
使用者
张经理 (David)，某外商银行资安与风控合规官。
痛点
公司已经有安全的 Azure 端点，也想引进 AI 提升分析效率，但一般云端 AI 助手仍常要求把敏感客户个资与交易 CSV 上传到外部环境。资料外送、可控性与审计边界不清，仍会让资安与合规审查卡关。
解决方案
- 1
在本机 DuckDB 载入资料
分析师直接将本机存放敏感资料的资料夹指派为 Workspace，资料立刻映射为 DuckDB 资料表，100% 物理隔离。
- 2
关闭或审批知识注入
大模型从对话中总结出的任何新业务规则，一律锁在 Queued Knowledge 待审伫列，未经审批绝不私自注入 AI 上下文。
- 3
分析结果留在工作区
搭载唯读守卫（SELECT-only），AI 只能读取与建立临时计算快取，不会写回原始资料，降低篡改、误删与未授权改动风险。
多步骤 SQL 管线
快取串接、血缘追溯
业务场景
电商营运、供应链、金融分析与资料团队，需要把原始交易资料、用户事件、订单明细与产品维度表串成多步骤分析流程。
使用者
陈分析师 (Mia)，某零售电商的资深数据分析师，负责每周营运仪表板与异常营收分析。
痛点
Mia 的分析通常不是一段 SQL 就能完成。进入 AI 时代后，SQL 产生得更快、更长、也更多，分析速度提升了，但中间结果是否过期、哪个查询依赖哪个查询、重跑顺序是什么，反而成为依赖管理与回溯的大问题。
解决方案
- 1
建立多分页 SQL 与快取
Mia 可以把每一步查询拆成清楚的 SQL 分页，并将中间结果快取成可重用的资料表，不必每次从头重算。
- 2
Source Run 依 DAG 重算
当上游资料或某个查询被更新时，系统依照 Source Run DAG 判断依赖顺序，特别适合周期更新、但又常持续探索并衍生更深查询的分析场景。
- 3
查看血缘与来源 SQL
每个结果都能追溯到来源 SQL 与上游快取，Mia 可以快速回答「这个数字从哪里来」，也能更安心地交付给团队。
跨来源分析
档案 + 外部 DB + MCP
业务场景
零售、制造、SaaS、财务与营运团队的资料经常分散在本机 Excel / CSV、内部 PostgreSQL / MySQL、第三方系统汇出档与 MCP 工具中。
使用者
王营运 (Kevin)，某跨境零售品牌的营运分析主管，负责整合订单、库存、广告与客服资料，找出影响营收的关键因素。
痛点
Kevin 想分析「广告投放是否造成某些地区缺货」这类跨部门问题，但资料散落在广告平台汇出的 CSV、ERP 资料库、客服系统与本机 Excel。每次分析前都要先搬资料、转格式、对栏位，真正开始分析前就已经耗掉大量时间。
解决方案
- 1
载入本机档案
Kevin 可直接把 CSV、Excel、Parquet 等本机档案载入工作区，快速变成可查询资料表。
- 2
ATTACH 外部资料库
对于存放在 PostgreSQL 或 MySQL 的营运资料，可以透过 DuckDB ATTACH 连接，不必手动汇出再汇入。
- 3
Agent 与人类共用逻辑表名查询
AI Agent 与分析师使用同一套逻辑表名与统一查询层，能自然 JOIN 跨来源资料，减少资料搬运与栏位理解落差。
利害关系人交付
给老板/客户的报告
业务场景
顾问公司、产品团队、营运团队与企业内部分析单位，经常需要把分析结果交付给主管、客户、投资人或跨部门利害关系人。
使用者
黄顾问 (Sophie)，某数位转型顾问公司的专案顾问，负责把客户营运数据分析整理成高阶主管看得懂的简报式报告。
痛点
Sophie 可以用 SQL 和 notebook 得到分析结果，但客户高层不会阅读查询过程，也不想看聊天纪录。他们需要的是有脉络、有结论、有图表、有建议的报告。过去 Sophie 还要手动把分析内容整理到简报或文件中，耗时又容易在复制贴上时出错。
解决方案
- 1
Execute 产出 Report
分析完成后，系统根据已审阅的 Plan 产出结构化 Report，保留方法、发现、证据与建议。
- 2
Generate HTML 报告
Sophie 可以把 Markdown Report 转成独立 HTML 报告，产生后也能用 Quick Edit 在浏览器中高频微调，细修成主管或客户习惯的语气与版面。
- 3
浏览器分享或汇出
报告可直接在浏览器中展示、分享或汇出，让分析交付从「工程产物」变成「商业沟通材料」。
团队协作审阅
PM 批注、分析师修订
业务场景
产品、数据、营运、财务等跨职能团队在做重要分析前，常需要多人共同确认问题定义、资料范围、假设条件与最终解读方式。
使用者
吴主管 (Angela)，某 SaaS 公司的 Growth Lead，负责协调 PM、数据分析师与业务团队，一起判断新定价策略是否有效。
痛点
Angela 的团队过去都在 Slack 或文件留言讨论分析需求，但意见分散在不同工具里。PM 补充商业脉络、分析师修改 SQL、主管调整决策问题，最后没有人能确定哪些意见已处理、哪些版本才是正式执行依据。
解决方案
- 1
PM 在 Plan 上批注
PM 与主管可以直接针对 Plan 的特定段落留言，例如补充分群逻辑、排除特殊客户或调整 KPI 定义。
- 2
分析师 Resolve 并修订
分析师根据批注逐项修改 Plan，并在 Resolve Comments 时把回馈变成下一版分析输入，避免讨论遗失。
- 3
达成共识后 Execute
团队确认 Plan 后才执行正式分析，让每一次 Execute 都建立在共同审阅过的版本上，协作过程可追溯、可交接。