使用场景
适合那些不能只得到答案，还需要日后说明、重跑或交接的分析工作。
周期分析与报表更新
新数据、同口径、可重跑
要完成的工作
运营、财务与产品团队每周或每月取得新的 CSV、Excel 或数据库快照，需要沿用相同口径更新固定分析。
适合谁
需要定期更新指标、异常分析或管理报告的分析师与运营团队。
为什么现有方法会失效
一般聊天式分析每次都从新 session 开始。即使问题相同，用户仍要重新说明字段、口径、筛选条件、JOIN 与验证方式，也很难确认这次结果是否沿用上次正式版本。
Lantide 如何把它变成分析资产
- 1
保留正式口径与证据
前一轮的 Plan、SQL 证据、完整执行步骤、Report 与限制留在项目里，成为下一次更新的基准。
- 2
换上最新数据
重新连接新的文件或刷新数据源后，先检查 schema 与数据期间是否符合预期。
- 3
导出后接续重跑
Workspace 包默认包含本地数据文件夹文件、MCP cache 与 Agent query ledger；换机或交接后可通过 Source Run 更新受影响的步骤并产出新 Report。
结构化分析项目
A/B 测试、漏斗、异常检测
要完成的工作
电商、SaaS、游戏、订阅制产品等高度依赖数据决策的产品与成长团队，经常需要分析 A/B 测试、转换漏斗、留存变化与异常指标。
适合谁
需要评估产品、增长或运营决策的 PM、分析师与业务团队。
为什么现有方法会失效
产品团队想知道新版 onboarding 流程是否真的提升启用率，但用聊天式 AI 问数据时，结论散落在对话里，SQL、假设、筛选条件与分析逻辑都难以追溯。主管追问「这个结论怎么来的？」时，分析师只能回头翻聊天记录与 SQL 分页。
Lantide 如何把它变成分析资产
- 1
分析师与 Agent 协作撰写 Plan
分析师与 Agent 先共同把分析目的、数据范围、成功指标与方法论整理成 Plan，让 PM、主管与分析师在执行前先对齐问题定义。
- 2
批注审阅达成共识
审阅者可直接在 Plan 上批注，例如要求排除内部测试账号、拆分新旧客群，所有修改都保留在文档上下文中。
- 3
Execute 产出 Report
当 Plan 被确认后才执行分析，系统锁定 Executed Plan 并产出 Report，让结论、方法与版本完整对应，日后可以清楚追溯。
隐私与合规
本地优先、敏感数据
要完成的工作
医疗、金融、跨国零售等受到法规、合同或信息安全制度约束的企业团队。
适合谁
需要在明确数据与模型边界下工作的分析、安全与风控团队。
为什么现有方法会失效
公司已经有安全的 Azure 端点，也想引进 AI 提升分析效率，但一般云端 AI 助手仍常要求把敏感客户个资与交易 CSV 上传到外部环境。数据外送、可控性与审计边界不清，仍会让资安与合规审查卡关。
Lantide 如何把它变成分析资产
- 1
在本地 DuckDB 加载数据
分析师将本地文件夹指定为 Workspace，由 DuckDB 在用户设备上读取、查询与缓存数据。
- 2
关闭或确认 Knowledge
从对话整理出的新业务规则先进入 Queued Knowledge，只有用户确认后才会用于后续 Agent 上下文。
- 3
原始数据保持只读
SELECT-only 守卫阻止 AI 写回原始文件和数据库；根据 Agent 模式与人工确认，Agent 仍可创建或修改 Plan、Report 等工作区成果。
多步骤 SQL 管线
缓存串接、血缘追溯
要完成的工作
电商运营、供应链、金融分析与数据团队，需要把原始交易数据、用户事件、订单明细与产品维度表串成多步骤分析流程。
适合谁
需要维护多步 SQL、周期更新与中间结果的数据分析师。
为什么现有方法会失效
这类分析通常不是一段 SQL 就能完成。进入 AI 时代后，SQL 生成得更快、更长、也更多，但中间结果是否过期、查询彼此如何依赖、重跑顺序是什么，反而成为依赖管理与回溯的大问题。
Lantide 如何把它变成分析资产
- 1
建立多分页 SQL 与缓存
可以把每一步查询拆成清楚的 SQL 分页，并将中间结果缓存为可复用的数据表，不必每次从头重算。
- 2
Source Run 依 DAG 重算
当上游数据或某个查询被更新时，系统依照 Source Run DAG 判断依赖顺序，特别适合周期更新、但又常持续探索并衍生更深查询的分析场景。
- 3
查看血缘与来源 SQL
每个结果都能追溯到来源 SQL 与上游缓存，分析师可以快速回答「这个数字从哪里来」，也能更安心地交付给团队。
跨来源分析
文件 + 外部 DB + MCP
要完成的工作
零售、制造、SaaS、财务与运营团队的数据经常分散在本地 Excel / CSV、内部 PostgreSQL / MySQL、第三方系统导出文件与 MCP 工具中。
适合谁
需要整合文件、数据库与外部服务的运营与数据团队。
为什么现有方法会失效
团队想分析「广告投放是否造成某些地区缺货」这类跨部门问题，但数据散落在广告平台导出的 CSV、ERP 数据库、客服系统与本地 Excel。每次分析前都要先搬数据、转格式、对字段。
Lantide 如何把它变成分析资产
- 1
加载本地文件
分析师可直接把 CSV、Excel、Parquet 等本地文件加载到 Workspace，快速变成可查询数据表。
- 2
连接外部数据库
PostgreSQL 或 MySQL 可通过 DuckDB ATTACH 连接；SQL Server 与 Azure SQL 采用 staged 查询，先将单一远程来源物化到本地。
- 3
Agent 与用户共用逻辑表名查询
Agent 与分析师使用同一套逻辑表名与统一查询层；SQL Server 不支持透明的跨来源单条语句 JOIN，需先 staged 物化再在本地 JOIN。
利害关系人交付
给老板/客户的报告
要完成的工作
顾问公司、产品团队、营运团队与企业内部分析单位，经常需要把分析结果交付给主管、客户、投资人或跨部门利害关系人。
适合谁
需要向主管、客户或跨部门利益相关者交付分析的顾问与分析团队。
为什么现有方法会失效
分析师可以用 SQL 和 notebook 得到结果，但主管与客户不会阅读查询过程，也不想看聊天记录。他们需要的是有上下文、有结论、有图表、有建议的报告；手动复制到演示文稿或文档则耗时且容易出错。
Lantide 如何把它变成分析资产
- 1
Execute 产出 Report
分析完成后，系统根据已审阅的 Plan 产出结构化 Report，保留方法、发现、证据与建议。
- 2
生成 HTML 报告
分析师可以把 Markdown Report 转成独立 HTML 报告，并用 Quick Edit 在浏览器中微调成主管或客户习惯的语气与版面。
- 3
导出或记录外部交付
报告可在浏览器中展示或导出；External Delivery 只保存 Report 指向 P4、KM、URL 等位置的信息，不上传、验证或删除外部内容。