与 AI 协作分析 · 2/7
以前我选 Python，是因为它快速、方便、灵活。AI 加入后，我开始重新考虑这个选择，原因也是它太快速、方便、灵活。
我用 Jupyter，它用 bash，原本以为没什么不同
在我接触的 AI 分析流程里，很常见的做法是用 Python 读入数据，用 pandas、NumPy 写计算脚本，执行 .py 文件，再读取结果进行分析。这个方法没有不好，过去自己独立完成分析时，我也是这么工作的，顶多我用 Jupyter，它用 bash。Python 很方便，无论是 AI 或我自己，都很难拒绝在一个脚本里处理好几个 dataframe，顺手完成清理、计算，再产出几份数据。
过去分析时，哪些结果可以覆盖、哪些要先保留、dataframe 之间依赖谁、执行顺序怎么排，大多由自己掌握（当然偶尔也会跑错 cell，然后假装没事 Restart & Run All）。这套方法除了 Python，其实还依赖一个没有写在 requirements.txt 里的东西：分析师脑中的执行状态。
「对不起，我不该覆盖你的文件」的崩溃时刻
换成与 AI 协作后，脚本大量产出、快速修改、反复执行，一个脚本又可能同时更新好几份数据。这时候要掌握的事情就多了：
- 这次修改只是调整计算，还是顺便重跑了清理？
- 哪份中间结果已经被覆盖？
- 下游报表引用的，还是不是刚刚确认过的那份数据？
即使脚本加了许多注释，也不代表这些依赖与执行状态就容易理解。更麻烦的是，本机分析环境即使有 Git，通常也只管了代码，没有替每一次数据产出保留版本。找回上一版 .py，不代表上一版结果也跟着回来了。
以前我们靠 Python 的灵活，搭配「可靠的自己」完成分析。现在旁边多了一个「对不起，你说得对，我不该覆盖你的文件，下次不会了」的 Agent，原本靠大脑掌握的分析产物，突然变得更难懂、更脆弱。我开始思考：AI 已经大幅降低写程序的成本，那我是不是可以接受工具少一点灵活，换取自己更容易理解、审阅和接手？
以 SQL 为基底，让 AI 做得快，人类跟得上
我得出的答案是 SQL-first。这是对分析工作流的选择，SQL 本身不会自动提供只读权限、依赖管理或数据版本；这些仍需要由查询环境与工作区落实。原因主要有两个：
- 边界比较容易限制：让 Agent 透过受控的只读查询分析数据，结果保存与更新则交给工作区管理
- 输出比较容易拆分：一段
SELECT对应一个结果集，方便命名、审阅与建立依赖，也更适合作为 Plan 里的计算契约
SQL 当然不是万灵丹，长起来一样可以很难读，统计、ML 和不少特殊处理也还是 Python 方便得多。所以我的作法是以 SQL 打底，再透过 workspace 模块补上需要的能力：
- 统一查询层：让不同来源的数据能在同一套查询方式下进行跨源分析
- 自动缓存：保存需要复用的中间结果，让后续查询可以继续引用
- DAG 执行：把结果之间的依赖与重跑顺序摊开，让人与 AI 都能清楚解读
- 统计模块：补上 SQL 较弱的分析能力，需要时仍然使用 Python
这些模块不会自动让每一份数据都有版本，但能把原本藏在脚本与脑中的依赖，变成工作区里看得见、管得动的「分析资产」。
当然，这比不上 AI 直接下 Python 的快上加快。但在无数次迷失于 AI 的 .py 海洋后，这个差异在我看来几乎可以忽略不计。我真正在意的，是从产出结果，到能理解、验证并拿来决策，总共花了多少时间。
延伸阅读
在 Lantide Data 中试用这套分析工作方式：下载 Lantide Data。
上一篇：AI 完成了分析，谁来解释它为什么这样算？ · 下一篇：分析整理成 Skill 之后，为什么 AI 还是用错口径？