文件版本之外：用 Change Context 留下分析判断的转折
文件版本能留下修改，却未必留下改变判断的原因。Change Context 将正式资产修改与当时的理由、证据引用一起记录，也明确保留 unknown 与未确认的边界。
阅读文章 →Lantide Data 博客
关于可靠、可审阅的 AI 辅助数据分析的洞察与实践指南。
AI 分析洞察
查看全部 →与 AI 协作分析后，我为什么改用 SQL-first？
Python 的灵活曾让分析很方便，也让 Agent 产出的脚本、依赖与中间结果更难掌握。这是我选择 SQL-first 的取舍，以及仍然需要 Python 的地方。
阅读文章 →AI 完成了分析，谁来解释它为什么这样算？
AI 能快速交出结果，负责分析的人却仍要理解分母、假设与被放弃的路径。我如何把决策与证据留在工作区，减少接手与审阅时重建脉络的成本。
阅读文章 →通用 Agent 已经成熟，垂直应用还需要自己的 Agent 吗？
我如何让外部 Agent 保留通用能力，让内置 Agent 深入数据分析工作流，最后接入同一个 Control Plane。
阅读文章 →AI 把分析做快了，却让“这个结论怎么来的”更难回答
当 AI Agent 开始找数据、写 SQL、运行 Notebook 并修改报告，聊天记录与文件版本已不足以保存完整证据链。本文说明为什么数据分析需要 Analysis Lineage。
阅读文章 →Skills 在数据分析中的局限：为什么 Skills 不足以承担真实世界的数据分析？
Skill 能保存分析方法，也能打包具体案例的 SQL 与背景；但真实分析还包含数据版本、执行状态、人工决策、证据与限制。本文说明为什么分析需要一个可审核、可重跑的工作环境。
阅读文章 →AI Agent 和聊天机器人差在哪？从「回答问题」到「完成可验收的工作」
AI Agent 不只是把回答写得更长，而是能依状态使用工具、推进多步工作并留下可验收成果；本文用数据分析说明两者差异、评估方式、适用情境与导入边界。
阅读文章 →AI 做数据分析，最危险的不是算错，而是你不知道它怎么算
AI 分析最难发现的是口径、分母、JOIN 与时间窗造成的合理错误；本文提供 Plan、SQL、checkpoint、limitations 四层查核方法。
阅读文章 →自然语言都能查数据了，为什么 2026 年还需要 SQL？
自然语言能降低查询起点，却不能取代 SQL 对粒度、JOIN、筛选与聚合的可审阅证据；未来更合理的分工是 AI 起草、SQL 留证、人类审核。
阅读文章 →为什么正式分析要先写 Plan，再让 AI Execute？
先写 Plan 的目的，是在取数前对齐决策问题、分母、粒度、时间窗与验证方式；Execute 则把正式执行变成清楚的人类授权边界，避免模糊假设先被跑成数字。
阅读文章 →可重现的 AI 分析是什么？从一个答案到一条可重跑的证据链
可重现的 AI 分析必须保留输入数据、时间版本、转换 SQL、依赖、执行纪录与限制，让他人能用同一条证据链重跑、核对关键数字并解释新旧结果差异。
阅读文章 →AI 分析工具、聊天 BI、传统 BI：三者应该怎么分工？
AI 分析 Agent、聊天 BI 与传统 BI 解决的是不同阶段：快速问答、探索口径与稳定监控不应混为一谈；本文提供五维选型矩阵与三个实务分工场景。
阅读文章 →Local-first AI 数据分析：数据留在本机，究竟解决了什么？
Local-first 可减少数据搬运、直接查本机档案并保留可携工作成果，但不自动等于完全离线或零风险；本文说清实际收益、数据流检查与产品边界。
阅读文章 →Agent 治理
查看全部 →Context 不必等到满：让分析脉络随工作进度收敛
与其等 context 快满才压缩，我更想依口径确认、方向停止与结果待验证等工作节点收敛信息，同时保留证据位置，让细节需要时找得回来。
阅读文章 →分析整理成 Skill 之后，为什么 AI 还是用错口径？
Skill 记对了上次的做法，换个专案却可能用错。以付费用户分析为例，说明如何区分方法、共用规则、专案知识与本次分析决策。
阅读文章 →Prompt Engineering 过时了吗？Context Engineering 才是 Agent 成败的分水岭
Prompt Engineering 没有过时，但 Agent 还要管理工具、数据、状态、历史与记忆；Context Engineering 决定模型每一轮究竟看见什么。
阅读文章 →Context Window 越大越好吗？长任务真正会遇到的 Context Rot
Context Window 变大只代表能放入更多 token，不代表模型能同样可靠地使用每段资讯；长任务需靠压缩、结构化 artifacts 与按需载入控制 Context Rot。
阅读文章 →AI Agent Memory 不是「全部记住」：企业知识为什么需要审批？
Agent 长期记忆会跨对话影响分析，因此企业知识需要来源、范围、核准与淘汰机制；本文提供可直接采用的 Memory 治理框架与 Queued Knowledge 审批流程。
阅读文章 →MCP 是什么？为什么它正在成为 AI Agent 的数据与工具介面
MCP 用标准化的 client-server 协定连接 AI 应用、数据与工具；本文说明核心元件、安全边界，以及 Lantide 的双向 MCP 用法。
阅读文章 →MCP 接上数据库就安全了吗？从工具连线到最小权限的五层防线
MCP 只标准化连线，不保证最小权限。本文用 host、credential、scope、capability、approval 与 audit 检查 Agent 数据存取。
阅读文章 →AI Agent 治理怎么落地？别从政策文件开始，先画出「谁能做什么」
AI Agent 治理要先把使用者、Agent、工具与数据的能力边界划清楚，再配置核准、监控与复原；本文提供可直接填写、测试与指定 owner 的六格能力地图。
阅读文章 →Schema 都给 AI 了，为什么还是会算错？数据分析真正缺的是业务语意
数据表名称与栏位型别只能描述数据长相，无法定义有效客户、营收、转换率与时间窗。本文拆解 AI 分析需要的业务语意，以及如何把口径变成可审阅的分析契约。
阅读文章 →与 Lantide 集成
查看全部 →使用 Claude Code 与 Codex 做数据分析时，为什么还需要 Lantide？
Claude Code 与 Codex 擅长在终端机调度长任务与 MCP 工具；若分析必须留下可审阅 SQL、Plan 与 Report，可把 Lantide 当本机 MCP host，用 Access Mode 与 Approve & Execute 守住执行边界。
阅读文章 →使用 PostHog 时，为什么还需要 Lantide？
PostHog 擅长产品事件、漏斗与实验显著性；当你要把不宜上云的本机 CRM／财务数据与事件联立，或需要可审阅 SQL 与正式 Report 时，可用 Lantide 做本机诊断。
阅读文章 →使用 Hex 时，为什么还需要 Lantide？
Hex 擅长云端协作 Notebook、reactive 执行与 App 发布；当数据必须留在本机、或 adhoc 探索不想进入云端专案时，可用 Lantide 做 local-first 分析，再把已去敏结果交回 Hex。
阅读文章 →使用 dbt 时，为什么还需要 Lantide？
dbt 适合生产转换、测试与 CI；对一次性假说验证，不必每次都开完整 model／CI。可用 Lantide 在本机沙盒探索，确认口径后再把标准 SQL 回写 dbt repo。
阅读文章 →使用 Notion 时，为什么还需要 Lantide？
Notion 适合 PRD、知识库与 database chart；它不是本机 SQL 执行引擎。用 Lantide 完成可重跑分析后，再把 HTML 或 Markdown 成果贴回 Notion，让企划页引用的是有证据的结论。
阅读文章 →使用 Obsidian 时，为什么还需要 Lantide？
Obsidian 与 Dataview 擅长本机 Markdown 知识与笔记 metadata 查询；Lantide 补上 DuckDB SQL、可重跑分析血缘与受治理的 Agent memory。两者可用档案交换衔接，而非互相取代。
阅读文章 →数据分析实践
查看全部 →每周 CSV 或 Excel 报表如何重跑，不必每次从头开始
一套可实际执行的重复分析流程，保留输入文件、指标定义、SQL、验证检查与报告限制。
阅读文章 →用 AI 分析 CSV 前，先做这 8 个数据品质检查
AI 能快速探索 CSV，但不会替你定义正确数据。本文提供编码、型别、空值、重复、键、时区、单位与异常值的 SQL 检查表，并示范如何留下可重跑 checkpoint。
阅读文章 →不装数据库，也能用 SQL 查 Excel／CSV：DuckDB 适合哪些人？
DuckDB 是嵌入式分析数据库，可直接用 SQL 查本机 CSV、Parquet 与 Excel；适合档案型 adhoc 分析，但不取代共享数仓与排程 ETL。
阅读文章 →AI 写的 SQL 怎么审？不只看能不能跑的 7 点检查表
AI SQL 成功执行不代表回答正确。本文用 grain、JOIN、filter、NULL、时间、分母与 LIMIT 七点检查表，附最小验证查询。
阅读文章 →转化率为什么每个人算得不一样？先对齐分母、事件与时间窗
漏斗转化率没有唯一公式；使用者或事件粒度、cohort 或日历时间窗、事件顺序与取消规则不同，答案就会不同。本文附可复用 Plan 模板与最大流失检查方式。
阅读文章 →JOIN 后数字暴增？AI 数据分析最常漏掉的 Fan-out 陷阱
JOIN 后总额变大，通常不是加总函数坏了，而是表格粒度不一致造成 fan-out。本文用订单案例与 SQL 检查法，教你在 AI 查询交付前找出重复计算。
阅读文章 →快速问数还是正式分析？用风险而不是篇幅做决定
Quick Analysis 与正式分析的差别不在问题长短，而在答案错误的影响与未来是否要被追问。本文提供一张二维判断表，帮你选对分析流程。
阅读文章 →数据血缘不是只有大数据平台需要：一份本机报表也该知道从哪里来
数据血缘是数据来源、转换与输出之间的可追溯关系。即使只有本机 CSV 与月报，只要成果会更新、交接或除错，就值得留下最小血缘、命名规则与重跑路径。
阅读文章 →一份可信的 AI 分析报告，至少要有哪 6 个部分？
可信的 AI 分析报告不只要有摘要，还要交代决策问题、口径、主要发现、可回查证据、限制与下一步。本文附可直接套用、可连回 SQL evidence 的六段式模板。
阅读文章 →团队采用
查看全部 →团队做过的分析，怎么成为人与 Agent 都能接手的经验？
Data Context、领域知识与分析经验各有用途。从活动参与率的排查案例，看团队如何保存条件、证据与取舍，让人与 Agent 接得上过去的工作。
阅读文章 →数据基建做好了，AI 就能接手团队分析吗？
数据可取得，不代表过去的分析可以接手。团队还需要留下方法选择、验证与判断依据，让 SQL 和报告成为可理解、可验证、可延续的分析资产。
阅读文章 →PM 不会 SQL，也能审 AI 分析：Execute 前先问这 6 个问题
PM 审 AI 分析不必逐行改 SQL；只要在 Execute 前确认目标、对象、分母、时间、排除条件与验证方式，就能守住业务口径与决策责任。
阅读文章 →分析师如何和 AI Agent 分工？把时间留给口径、验证与解读
AI Agent 适合加速 schema 探索、SQL 草拟与报告初稿；分析师应掌握问题定义、口径、验证、异常解释与决策沟通。本文提供一套风险分工表。
阅读文章 →外部 AI Agent 要碰公司数据前，数据平台团队该准备什么？
外部 AI Agent 接触公司数据前，平台团队应先界定来源、能力、workspace、credential、正式 evidence、writer ownership、audit 与复原。本文提供导入检查表。
阅读文章 →从第一次试跑到团队采用：可治理 AI 分析的 30 天导入路线图
30 天 AI 分析试点应从真实、可控的复盘开始，逐步建立品质底线、审阅失败、权限与扩大条件。本文提供周次任务、必要产物，以及判断是否扩大的四组指标。
阅读文章 →