告别ChatBI，重构数据思维：AI 时代数据分析的工作范式重构与 AskTable 的设计哲学

在进入 AI 领域之前，我一直从事模型和算法开发，持有一种非常传统的计算机科学（CS）视角。随着大模型的普及，我们观察到 AI 在编程领域（如 Cursor, Claude code）的表现进步最快，因为在这个闭环内，我们自己开发、自己使用、自己测试并优化数据。当时我们很自然地产生了一个想法：既然 AI 在代码领域表现如此惊人，那么在大数据分析领域，AI 难道不是"降维打击"吗？

但在实际落地过程中，我们发现这种想法过于理想化了。

---

一、幻灭与反思：为什么"对话"不是数据分析的终极形态？

过去一年，行业内涌现了大量 Text-to-SQL 或 Chat-to-Data 的产品。技术逻辑看似完美：用户提问 -> AI转译 -> 数据库执行 -> 返回结果。但在实际落地中，AskTable 团队识别出了两个核心痛点，这促使了技术路线的根本性调整。

1. 落地困境：组织协同的熵增

理想状态下，AI是连接业务人员与数据库的桥梁。但现实中，落地一个AI数据项目需要协调业务方（提需求）、数据团队（理口径）、Ops团队（开权限）以及老板（看结果）。技术支持团队往往被淹没在跨部门的沟通噪音中。AI并没有自动消除组织架构的壁垒，反而因为对数据准确性的高要求，增加了由于上下文缺失带来的沟通成本。

2. 交互悖论：线性对话 vs. 发散思维

这是更深层次的技术哲学问题。

• •人类的思考模式： 数据分析是一个"建模"过程。从模糊的心理表征出发，经历发散、探索、试错，最后收敛为一个可验证的结论（如SQL或图表）。这是一个非线性、增量式的过程。
• •Chat的交互模式： 传统的对话框是线性的（Q&A）。用户必须在提问前就在脑海中完成"降维"和"清洗"，将复杂的业务诉求压缩成一句Prompt。

结论： 对话（Chat）并不是人类思考数据的方式。强行用线性对话去承载发散性的分析思维，是对用户认知负荷的加重，而非减负。

---

二、架构重构：从"对话流"到"所想即所得"的画布（Canvas）

通过观察用户的反馈，我们意识到：对话，并不是人类思考数据的方式。

1. 业务查询是一个非线性过程

业务查询通常遵循"接收需求 -> 发散 -> 探索 -> 收敛"的过程。而对话是线性的——提出问题 A，得到结果 B。如果你想回过头做横向探索，对话框会变得非常笨重。对话无法包容分析师那种发散式的探索方法。

2. 心理表征与降维收敛

我们认为，数据分析本质上是一个建模过程。人类对世界、对业务在内心都有一个"心理表征"，这种表征很难被言语化。分析的过程，就是通过随手记录、拖拽、SQL 或代码等手段，将这种复杂的心理表征逐步"降维"，最终收束到具体场景中，给出一个图表、一个结论或一个决策参考。

用户说出来的那句话，往往是脑中无数想法筛选后的"简化表达"，它并不是对数据最真实的思考。

---

三、技术哲学：AI的边界与"可验证性"工程

如何界定AI在系统中的职责至关重要。AskTable 提出了一套清晰的工程原则：AI应用就是工程化所有"可验证"的事情。

1. 区分"可验证"与"不可验证"

• •可验证逻辑（Verifiable Logic）： SQL语法是否正确？Python代码能否跑通？数据计算结果是否符合逻辑？这些是有标准答案的，是AI擅长的领域（Code Generation）。
• •不可验证逻辑（Unverifiable Logic）： 商业决策的直觉、复杂的业务背景假设、某个领导的偏好。

AskTable 的策略是：绝不让AI去"猜"不可验证的东西（如凭空生成一个精美大屏），而是利用AI极低的边际成本，去解决所有可验证的代码生成和数据处理任务。

2. 稳定性压倒一切：测试驱动开发（TDD）

在企业级数据场景下，准确性是生命线。AskTable 强调：

• •SQL解析器的重要性： 不要盲目All-in端到端的模型输出。必须结合手写的SQL解析器（Parser）来界定安全边界。
• •评测集（Evals）： 必须建立针对特定业务场景的自动化评测集。AI在数据分析中不是"生成式创作"，而是"功能性执行"，必须像测试传统软件一样测试AI Agent。

---

四、探索新范式：从 Agent 到非线性画布

为了实现"所想即所得"，我们在产品中进行了两次核心探索：

1. Agent 实验环境

在做新产品探索之前，我们做了一个实验，尝试将 Agent 置于一个集成了 Python、SQL、DuckDB、VectorSearch、JavaScript等工具的融合环境中。给它一个目标，让它自己去试错、反馈、迭代，并生成包含思考过程（Plan）的深度报告。虽然目前这还未完全达到生产可用的地步，但它验证了 AI 在给定工具和初始条件下，能够给出意料之外的优质结果。

2. Canvas（画布）

这是我们最近内测的核心功能，旨在打破线性的束缚。

2.1 非线性点边关系：节点（Node）与流（Flow）

不同于传统BI的拖拽或ChatBI的问答，AskTable 的画布将分析过程抽象为可编排的节点。整个产品由"节点"组成，通过点与边表示数据的流向，而不是简单的问答历史。

• •数据节点（Data Node）： 承载原始数据或查询结果，这些数据可能来自MySQL、Oracle、StarRocks， 甚至是 Web网页。
• •图表节点（Chart Node）： 数据的可视化表达。
• •计算节点（Python/SQL Node）： 这一步是关键。AskTable 允许AI编写并执行Python代码（如Pandas、Numpy处理）或SQL，处理复杂的逻辑运算。

2.2 上下文管理

在画布中，用户可以通过连线或选中多个节点，显式地定义AI的Context（上下文）。

• •场景举例： 用户选中"最近20笔订单"的数据节点，连接到一个新的Python节点，并指令"分析这些客户的画像"。
• •技术实现： 系统会将前序节点的Schema、数据摘要甚至中间结果作为Context注入到Prompt中，实现了数据流与逻辑流的无缝传递。

这种架构让分析过程变成了一个可视化的思维导图。用户不再受限于编程语言或单一的对话窗口，而是通过节点的组合，完成从"心理表征"到"形式化表达"的映射。

---

五、我们坚持的工程原则

在技术实现上，AskTable 始终遵循以下原则：

1. •低熵架构： 我们持续精简系统架构，从最初的繁杂环境演进到现在的轻量化部署，以降低实施和运维的熵值。
2. •对齐标准： 我们不乱造文字和协议，除非有极其明确的需求。我们全面对齐 AI 行业的标杆协议。
3. •核心解析器： 尽管 AI 很强大，但我们依然重视传统工程。我们手写了 SQL 解析器 ，用于解析用户 SQL 并定义边界，让 AI 的思路更加安全、可靠、可控。

---

六、结语：邀请一起探索交互的新可能

写一个 Agent 并不难，但在 2025 年这个时间节点，如何挖掘人与 AI 交互的新可能性才是真正的挑战。我们不希望把人和 AI 割裂开来，而是希望将琐碎的可验证工作封装在 AI 内部，让人能够自由地进行思维探索。

AI 负责繁琐、可验证的逻辑，
人类专注在抽象思考与业务探索。

我们正在寻找对业务和数据敏感的伙伴参与我们的画布功能内测。如果你有任何想法，或者想借鉴我们的思路，欢迎与我们交流。

AskTable 团队致力于探索人机协作的下一个边界。