摘要：
在 LLM 席卷编程领域的当下，数据分析被视为下一个被“降维打击”的堡垒。然而，经过一年的落地实践，AskTable 团队发现：传统的 ChatBI（对话式商业智能）存在天然的交互局限。
本文来自 AskTable「AI 数据洞察」线下交流会现场分享，深入解读 AskTable 如何跳出“Chat”的窠臼，通过“画布（Canvas）”架构实现非线性的思维建模，并探讨在 AI Agent 开发中关于“可验证性”与“工程边界”的技术思考。
在进入 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 始终遵循以下原则：
- 低熵架构： 我们持续精简系统架构，从最初的繁杂环境演进到现在的轻量化部署，以降低实施和运维的熵值。
- 对齐标准： 我们不乱造文字和协议，除非有极其明确的需求。我们全面对齐 AI 行业的标杆协议。
- 核心解析器： 尽管 AI 很强大，但我们依然重视传统工程。我们手写了 SQL 解析器，用于解析用户 SQL 并定义边界，让 AI 的思路更加安全、可靠、可控。
六、结语：邀请一起探索交互的新可能
写一个 Agent 并不难，但在 2025 年这个时间节点，如何挖掘人与 AI 交互的新可能性才是真正的挑战。我们不希望把人和 AI 割裂开来，而是希望将琐碎的可验证工作封装在 AI 内部，让人能够自由地进行思维探索。
AI 负责繁琐、可验证的逻辑，人类专注在抽象思考与业务探索。
我们正在寻找对业务和数据敏感的伙伴参与我们的画布功能内测。如果你有任何想法，或者想借鉴我们的思路，欢迎与我们交流。 来官网联系我们申请内测：www.asktable.com/?utm_source…
