大多数需要用 AI 分析数据的人并不是数据科学家。他们可能是一名想弄清楚究竟是哪个营销活动真正带来了注册量的营销人员，一位盯着流失率导出数据发愁的创始人，或者一位被丢过来一份 4 万行 CSV、还要在周一前交付的运营主管。如果这就是你，那么好消息是：当下这一批 AI 数据工具在很大程度上正是为你打造的——那些对自己的业务了如指掌、却从没学过 pandas 的人。
坏消息是，这些工具会满怀信心地把一个错误的数字递给你，而那个错误的数字看起来和正确的数字一模一样。
本指南涵盖你的数据所在的三个地方（文件、电子表格、数据库）以及每种情况适配哪类工具，什么时候一个普通的聊天模型就够用，什么时候它开始编造统计数据，以及那个能保护你免受所有这些问题困扰的习惯。
先看你的数据在哪里，而不是先看工具
工具盘点通常从功能讲起。跳过这一步。对于一名被迫上阵的分析者来说，决定性的问题更简单：数据现在到底在哪里。
- 一个文件：来自 Stripe、Shopify 或你的 CRM 的 CSV 或 Excel 导出文件。一个具备代码执行能力的聊天模型能很好地处理这类情况。
- 一个电子表格：你的团队每周都在编辑的动态数据。你需要的是原生支持电子表格的 AI，而不是来回复制粘贴。
- 一个数据库：Postgres、MySQL 或一个数据仓库。你需要的是文本转 SQL 工具，而且要在只读凭据下使用它们。
下面的所有内容都围绕这三种情况展开。选定你的赛道，跳过其余部分。
什么时候一个聊天模型就足以用 AI 分析数据
对于导出文件的一次性分析，一个通用聊天模型往往就是你所需要的全部。来自 OpenAI 的 ChatGPT 可以接收上传的 CSV，针对它编写 Python 代码，运行那段代码，并把结果连同图表一起返回给你。对于「上个季度哪个地区增长最快」或「找出这份客户名单中的重复项」这类问题，那个循环（上传、提问、检查）确实已经够用了，我也会建议大多数非分析人员从这里入手。
关键的区别在于模型是如何得出这个数字的。有两种模式，而它们在聊天窗口里看起来一模一样：
- 模型运行了代码。它写了一段脚本，针对你的实际文件执行，并报告了输出结果。算术运算来自计算机，而不是语言模型。这是值得信任的模式。
- 模型把你的数据当作文本来读，并靠模式匹配凑出一个答案。没有代码运行。它给你的那个「平均值」只是一个听起来合理的猜测。这正是被凭空捏造的统计数据的来源：编造出来的相关性、对不上任何一列的均值、加起来等于 104 的百分比。
当文件太大而无法处理时，当你粘贴数据而不是上传它时，或者当你追问一个后续问题、而模型是凭着对先前结果的记忆作答、而不是重新运行任何计算时，聊天模型就会滑向第二种模式。同样的界面，同样自信的口吻，可靠性却截然不同。
所以操作原则是：一个聊天模型给出的数字，好坏完全取决于其背后的代码。这就引出了那个比任何工具选择都更重要的习惯。
「把查询给我看」原则
永远不要相信一个你无法追溯到某个查询、某个公式或某行已执行代码的数字。
每一款严肃的 AI 数据工具都能展示它的工作过程：它生成的 SQL、它运行的 Python、它写下的公式。把要求查看这些变成一种条件反射。你不需要会写 SQL，也能抓出一个在错误的日期列上做筛选、或者把订单和客户表连接了两次从而重复计算了营收的查询。生成出来的查询会以可读的方式出错。
三个成本低廉的验证习惯，按投入程度从低到高排列：
- 在任何你打算转述给另一个人的答案之后，都问一句「把你用的查询/代码给我看」。如果工具拿不出来，那这个数字就是猜的。
- 把同一个问题换个说法问两遍。得到两个不同的答案，就意味着至少有一个是错的，而现在你知道该深入挖一挖了。
- 用最笨的方法抽查一个数字：一个数据透视表、一个 COUNTIF、一次筛选后用眼睛核对。如果 AI 的总数在某一个切片上和你算的对得上，那么你对其余部分的信任就是挣来的，而不是想当然的。
这与研究人员对待引用的纪律如出一辙：一个论断的可信度，只取决于你实际能核查的那个来源。
电子表格 AI：在数据已经所在之处做分析
如果你的数据是一份活的电子表格，而不是一份死的导出文件，那么每周把它搬进聊天机器人很快就会让人厌烦。原生支持电子表格的工具弥合了这道鸿沟。
Rows AI 是一款围绕 AI 重新打造的电子表格：你用自然语言提问，它就地导入、清洗并汇总数据，无需任何公式。代价是它确实是一款不同的电子表格：如果你团队的工作流程已经和 Excel 或 Google Sheets 焊死在一起，迁移就是一项实实在在的成本，我只会为新项目支付这项成本，而不会去移植旧项目。
Sourcetable AI Spreadsheet 采用同样的「电子表格加 AI」形态，但它更侧重于连接：它能从数据库和业务应用中拉取数据，因此你可以用自然语言查询实时数据，并在此基础上构建模型和图表。需要注意的是，这一点正是其卖点的另一面：它的价值取决于它是否能连接到你的那套特定技术栈，所以在下决心之前先查一查它的连接器列表。
Formula Bot AI Data Analytics 是更轻量的选择：一个 AI 数据分析师，你把它对准一份电子表格，就能用平实的英语提问、生成图表，并为演示准备数据。当交付物是一张幻灯片、而不是一套系统时，它就很合适。如果你需要的是定期、可重复的报告，那就跳过它：一个问答工具算不上一条流水线。
不写 SQL 也能与你的数据库对话
最重的问题藏在生产数据库或数据仓库里，隔着一门你可能不会说的语言。文本转 SQL 工具就是那道翻译层，它们有两种形态。
第一种形态为你生成 SQL，让你自己去运行。Text2SQL.AI 把一个平实的英语问题变成一条 SQL 查询，你可以把它粘贴进你团队使用的任何客户端里——当有开发人员为你配好了访问权限、而你只需要那几句话时，它就很合适。AI2SQL 更进一步：它生成、解释并优化查询，还能通过只读连接接入多种数据库类型。那个「解释」功能被低估了：把一位同事写的查询粘进去，就能得到一段英文描述——这正是「把查询给我看」原则的反向运用。
第二种形态是对话式的：AskYourDatabase AI 连接到你的数据库，让你直接与它对话：它写 SQL、运行、把结果绘成图表，还能组装仪表盘，并对谁能触碰什么提供细粒度的访问控制。
关于整个这一类别，有一个诚实的警告：文本转 SQL 的质量在很大程度上取决于你的 schema。如果你的表名叫做 tbl_fct_ord_v2 之类，而真正的营收逻辑活在某个人的脑子里，那么 AI 会写出干净、看似合理、却是错误的查询：通常是那种悄无声息地重复计数的糟糕连接。在一个杂乱的 schema 上，阅读生成的 SQL 不是可选项；它就是这份工作本身。
| 工具 | 你的数据所在之处 | 最适合 | 需要提防 |
|---|---|---|---|
| OpenAI（ChatGPT） | 上传的文件 | 一次性的 CSV 分析 | 不运行代码就作答 |
| Rows AI | 它自己的电子表格 | 在表格内用自然语言分析 | 从 Excel/Sheets 迁移出来 |
| Sourcetable | 电子表格 + 已连接的应用 | 在熟悉的网格里处理实时数据 | 对你技术栈的连接器覆盖 |
| Formula Bot | 电子表格 | 快速的图表和演示 | 并非为可重复报告而生 |
| AI2SQL | 数据库 | 生成并解释 SQL | 杂乱的 schema 会产出看似合理却错误的连接 |
| AskYourDatabase AI | 数据库 | 无需 SQL 的对话式仪表盘 | 仍需验证生成的查询 |
| Deepnote | 笔记本（Python + SQL） | 可重复、可共享的分析 | 假定你愿意读一些代码 |
| Pecan AI | 业务数据源 | 无代码的预测模型 | 需要真实的历史数据量 |
隐私：在你上传任何东西之前
这是人们会跳过、然后又后悔的一节。在公司数据进入任何 AI 工具之前，先过一遍四项检查。它们只需五分钟。
- 弄清楚工具的数据政策。具体来说：你的数据是否会被保留，以及它是否会被用于模型训练。同一款产品的消费者版和企业版的答案往往不同。如果你找不到答案，那本身就是答案。
- 剥离掉分析用不上的东西。上传前删掉姓名、邮箱和地址这些列。「按地区计算的平均订单金额」需要的个人身份信息为零。聚合值和匿名化的 ID 能回答大多数业务问题。
- 任何要连接数据库的东西，都用只读凭据。一个能生成 SQL 的工具，也能生成一条
DELETE。只读访问把一场可能的灾难变成一条错误信息。 - 在样本上做原型。先针对一份 50 行的假数据提取来构建你的问题，只有在验证过之后，才对真实数据运行那条查询。
对于数据已经处于合规约束下、存放在数据仓库里的团队，有一个架构层面的答案：Snowflake Cortex AI 在 Snowflake 环境内部运行托管的 LLM 和文本转 SQL，因此分析就发生在数据已经所在的地方，而不是把数据运送给第三方。只有当你本来就在用 Snowflake 时，它才说得通。但如果你身处受监管的行业，这就是该和你的数据团队谈的那场对话。
当你不再满足于聊天：笔记本与预测
到了某个时刻，每周的一次性问题会变成每周同一个问题，而再去问一遍聊天机器人就不再合理了。
Deepnote 是自然的下一步：一个协作式笔记本，分析在其中以 Python 和 SQL 的形式存在，由 AI 生成代码，队友们在旁评论，结果则以仪表盘和数据应用的形式发布。老实说，它的代价是笔记本假定你最终会去读——不是写，是读——一些代码。实际上这是一个优点：它把「把查询给我看」原则变成了永久的，因为那个查询就是文档本身。
Pecan AI 指向另一个方向：向前。它是一个无代码的预测分析平台，在你的业务数据上构建模型（哪些客户可能流失，哪些线索可能转化），并把这些预测推送到你的 CRM 里。有两点需要注意。预测需要有意义的历史数据。几百行训练不出任何有用的东西。而且，在你还没做过描述之前，别急着去做预测：如果你连上个季度的流失率是多少都还说不上来，那么一份流失预测不过是装饰。当你的胃口大到超出无代码之后，机器学习工程师所用的工具就是更上一层的那一架。
还有一个值得点名的相邻情况：自由文本数据。问卷答案、客服工单和评论都塞不进数据透视表，而聊天模型在批量分类它们方面也只是勉强及格。那是它自己的一个类别——情感分析工具——如果文本是你主要的原始素材，那就值得单独评估一番。
上面这些工具是我自己真正会从中入手的，但它们只是一个大得多的领域里的一个样本。你可以浏览用于分析数据的 493 款工具的完整目录，并按你的技术栈、预算和数据源进行筛选。
常见问题
ChatGPT 能准确分析 Excel 或 CSV 文件吗？
能，当它针对上传的文件运行代码时：算术运算来自已执行的 Python，而不是来自语言模型。当你把数据作为文本粘贴、文件超出了它能处理的范围、或者它凭记忆回答后续问题而不是重新运行分析时，准确性就会下降。让它把执行的代码给你看；如果没有代码，就把那个数字当作猜测。
我怎样才能阻止 AI 在我的数据里编造数字？
只相信有可检验之物支撑的数字：一个查询、一个公式，或已执行的代码。在任何重要的答案之后都问一句「把你用的查询给我看」，并用数据透视表或 COUNTIF 手动抽查一个结果。把同一个问题换个措辞问两遍是一个成本低廉的绊网：不一致的答案意味着至少有一个是编造的。
把公司数据上传到 AI 工具安全吗？
这取决于工具的保留和训练政策，你应该在上传任何东西之前读一读它。企业版通常比消费者版提供更有力的保证。先剥离掉姓名、邮箱和其他个人列，因为大多数分析在匿名化数据上都能跑得很好。对于数据库，用只读凭据连接；对于受监管的数据，则优先选择在你现有数据仓库内部进行分析的平台。
如果 AI 能替我写 SQL，我还需要学 SQL 吗？
你不需要写 SQL，但学会读它会在一周之内就有回报。生成的查询会以清晰易懂的方式出错（错误的日期列、一个重复计数的连接），而抓出这些错误所需的技能，远比从零写查询要少。那些用平实英语解释查询的工具能当一个不错的老师。
分析电子表格最好的 AI 工具是什么？
这取决于电子表格在哪里以及输出是什么。在一张全新的表格内做分析，选 Rows AI；对于需要来自数据库和应用的实时数据的电子表格，选 Sourcetable；对于在一份现有文件上进行快速的平实英语提问、并生成可用于演示的图表，选 Formula Bot。对于一份导出文件的一次性分析，把它上传到 ChatGPT 是最快的路径。