文件版本之外：用 Change Context 留下分析判断的转折
文件版本能留下修改，却未必留下改变判断的原因。Change Context 将正式资产修改与当时的理由、证据引用一起记录，也明确保留 unknown 与未确认的边界。
阅读文章 →← 返回博客
文章分类
AI 分析洞察
共 13 篇文章
与 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 可减少数据搬运、直接查本机档案并保留可携工作成果，但不自动等于完全离线或零风险；本文说清实际收益、数据流检查与产品边界。
阅读文章 →