微信
飞书
选择您喜欢的方式加入群聊
扫码添加咨询专家
2024 年初，在一场技术峰会的休息区，我们听到最多的词是"大模型"。每个展台都在讲参数量、benchmark 分数、训练成本。但当我们问一个更朴素的问题——"你打算用它解决什么具体的业务问题？"——回答往往变成了沉默。
那个时候，AskTable（我们内部也叫它"奥斯卡"）刚刚从一个技术原型起步。团队的判断很简单：大模型在编程领域进步最快，因为它形成了一个"自己开发、自己使用、自己测试"的完整闭环。那数据分析呢？能不能也让业务人员用自然语言直接和数据对话？
这个问题引领了我们接下来两年的全部工作。
在这个过程中，我们亲历了市场从技术狂欢到焦虑蔓延，再到理性回归的完整周期。我们看到了 Agent 概念的兴起与迭代，经历了 MCP 协议的诞生，见证了 Skill 从模糊概念到可定义、可组合的能力模块。我们也看到了自媒体的噪声场如何膨胀——造神叙事、焦虑营销、以 AI 之名卖课卖工具——以及这些噪声如何掩盖了真正重要的问题。
这篇文章，是我们以 AskTable 的两年产品实践为线索，对 2024-2026 年 AI 市场变化的一次冷静梳理。我们试图回答一个核心问题：
当大模型的能力不断水涨船高，做应用层产品的我们，到底是水涨船高，还是会被潮水淹没？
2024 年的 AI 市场，主角非常清晰：模型研究员、算法工程师、算力供应商。
技术讨论的焦点是参数量、训练成本、benchmark 排名。这些指标令人兴奋，但也离绝大多数人很远。对于一家企业的财务总监来说，"70B 参数 vs 100B 参数"不是一个她能感知到的差异；对于一个销售经理来说，"context window 从 128K 扩展到 256K"也不意味着他明天就能更好地做决策。
这个阶段的 AI，是一个"少数人的春天"。
但在这个春天里，做 AskTable 的我们看到一个信号：大模型在编程能力上的进步远超预期。它能理解代码逻辑、能生成结构化查询、能处理复杂的语义推理。如果我们能把这种能力引导到数据分析领域——让业务人员用自然语言提问，AI 理解意图、生成查询、返回结果——那将是一个全新的范式。
我们的起点很朴素：尝试用大模型做 Text-to-SQL。
第一层困难很快就浮现了。SQL 生成只是冰山一角，真正难的问题藏在海面之下：
ord_dtl 对数据库来说是标识符，但对 AI 来说需要理解为"订单详情"这些不是模型能力的问题，而是业务理解的问题。模型可以写出语法完美的 SQL，但如果它不理解业务语义，写出来的 SQL 就是错的。
这个阶段的 AskTable 产品形态简单、粗糙，但它验证了一个关键假设：AI 确实能降低数据查询的门槛，但前提是有人替 AI 理解业务。
2024 年的市场生态已经初步成型，但呈现出一种有趣的分裂：
timeline
title 2024 年 AI 市场参与者演进
2024 Q1 : 模型研究员
: 算法工程师
: 算力供应商
2024 Q2 : AI 创业者
: 早期投资人
2024 Q3 : 技术博客作者
: 自媒体入场
2024 Q4 : 少数先锋企业开始试点
: 江浙/珠三角创业者试探性入场
自媒体生态已经相当成熟：融资喜报铺天盖地、"AI 将改变一切"的叙事满天飞。但沉默的大多数企业还在观望——在评估、在等"别人先踩坑"。
只有少数群体开始真正行动：以江浙、长三角和珠三角为代表的年轻创业者们。他们规模不大，但反应敏捷，已经开始试探性地把 AI 引入自己的业务流程。这种务实的态度，和市场上的喧嚣形成了鲜明对比。
2025 年发生了一个关键变化：AI 开始大规模进入开发者的日常工作。
Cursor、Claude Code 等工具让"AI 编程"从概念变成日常。越来越多的开发者发现，AI 不仅能补全代码，还能理解需求、设计架构、审查代码。随之而来的是一个更广泛的讨论：AI 会不会替代程序员？
这个讨论从 IT 圈子蔓延到了所有从业者。每个人都开始意识到，自己正在做的事情——写代码、做表格、写报告、做设计——AI 都能做，而且做得更好、更快。
做产品的人自然会想到一个问题：如果 AI 能写代码，那 AI 能不能直接做数据分析？答案是肯定的，但这引出了下一个问题：当 AI 什么都能做的时候，你的产品凭什么让别人选你？
MCP（Model Context Protocol）在 2025 年的出现，是一个被广泛低估的事件。
表面上看，它只是一个协议——定义了 AI 模型如何与外部工具和数据源交互。但它的意义远不止于此：MCP 解决了 AI 孤岛问题，让 AI 助手能直接访问企业数据。
这正是 AskTable 一直在做的事情。我们比 MCP 协议早几个月就开始思考同一个问题：如何让 AI 安全、可控、有权限地访问企业数据？MCP 给了我们一个标准化的答案。
但更重要的是我们意识到的一个判断：当连接变得标准化，连接本身就不再是壁垒。真正的壁垒在于"连接之后做什么"。
graph TB
subgraph 2024["2024: AI 孤岛"]
A1["AI 助手"] -.无法直接访问.-> B1["企业数据"]
end
subgraph 2025["2025: MCP 连接"]
A2["AI 助手"] -- MCP 协议 --> B2["MCP Server"]
B2 -- 访问 --> C2["企业数据"]
end
subgraph 2026["2026: 能力编排"]
A3["AI 助手"] -- MCP --> B3["AskTable"]
B3 -- Skill 系统 --> C3["数据分析能力"]
C3 -- 输出 --> D3["业务决策"]
end
从"AI 孤岛"到"MCP 连接"再到"能力编排"——这是技术架构演进的三个段，也是 AskTable 在这三年里经历的技术路径。
关于 MCP 的更多细节，可以阅读我们的 MCP 入门指南 和 MCP 快速开始指南。
2025 年下半年，Agent 的"技能"从一个模糊概念变成了可定义、可组合、可编排的模块。
这不是一个简单的命名变化。它的本质是：AI 的能力从"通用对话"走向了"结构化能力"。
AskTable 的 Skill 系统在这一时期成型：异常检测、归因分析、预测趋势、周报生成……这些不是随手列出的功能清单，而是我们从大量企业落地实践中抽象出来的经过验证的分析能力封装。
每一个 Skill 背后，是大量对业务场景的理解、对数据口径的对齐、对输出格式的打磨。它们之所以有价值，不是因为"AI 能做这些"，而是因为"我们知道企业需要什么，并且把这种需要封装成了 AI 可以执行的 Skill"。
更多关于 AskTable 的 AI Agent 架构设计，可以参考 AskTable AI Agent 工作原理。
2025 年，自媒体生态在 AI 领域形成了清晰的三层结构：
这三层结构叠加在一起，形成了一个巨大的噪声场。真正务实的企业决策者在这个噪声场中反而感到更加困惑——不是信息不够，而是噪声太多。
我们做产品的人，选择很明确：不造神、不贩卖焦虑、不承诺"一招见效"。 我相信，AI 对企业的价值是真实的，但它不是一键生效的魔法，而是需要理解、规划和持续投入的系统工程。
到了 2026 年，市场出现了一个关键性的共识转变：
AI 对生产力的影响不是 10 倍、100 倍的渐进改善，而是 1000 倍、10000 倍的范式转换。
这个判断的依据来自一线观察：
但这种量级跃迁也带来了一个新的问题：当底层 AI 能力每年以 1000 倍的速度进化时，建立在这些能力之上的应用层产品，如何保证自己的价值不被模型本身的进步所稀释？
这是我们思考最多、也认为最值得分享的一个问题。
用一个比喻来理解：
大模型的能力就是"水"，每年都在涨。 应用层产品是浮在水面上的"船"。
如果一艘船的价值仅仅建立在"调用了一个好模型"上，那水涨的时候你确实会升高——但水退了（或者别人用了更好的模型）的时候，你就会被淹没。
真正让船浮起来的，不是水，而是船本身的构造。
这个比喻引出了 AskTable 最核心的战略思考：我们做了哪些事情，是不被大模型进步所淹没的？我们建造了怎样的"船体"，使得无论水位如何变化，我们都能稳定航行？
graph LR
A["领域专业知识\nDomain Expertise"] --> E["AskTable\n护城河"]
B["数据基础设施\nData Infrastructure"] --> E
C["产品思维\nProduct Thinking"] --> E
D["用户理解\nUser Understanding"] --> E
style A fill:#4ecdc4,color:#000
style B fill:#45b7d1,color:#000
style C fill:#96ceb4,color:#000
style D fill:#dfe6e9,color:#000
style E fill:#ff6b6b,color:#fff
SQL 生成只是一个技术动作。真正难的是理解：
这些知识不是模型预训练能覆盖的——它来自大量企业落地实践的积累，来自与不同行业客户的深度对话，来自对业务场景的反复打磨。
AskTable 在这方面的积累包括：服务超过 260 家企业客户、覆盖 9 个行业智能体、构建完整的业务语义层。这些积累不会因为下一个模型发布而过时——它们是时间的产物。
关于 AskTable 如何设计和思考 AI 分析范式，可以参考 AskTable 设计哲学。
模型不懂你的数据库结构、权限体系、数据质量状况。它也不知道：
AskTable 在这方面的投入包括：20+ 数据库适配、行级/列级权限控制、数据脱敏、SQL 安全守卫。这些都是"脏活累活"，但正是这些不性感的细节，构成了难以被模型复制的壁垒。
更多内容可以参考 AskTable 数据源接入指南 和 AskTable 数据安全最佳实践。
这是 AskTable 最引以为傲的一层。
我们的演进路径是：从 ChatBI 到 Canvas。这个转变不是因为技术上做不到 ChatBI，而是因为我们发现——"对话"并不是数据分析的正确交互方式。
ChatBI 的问题在于：它假设数据分析是一个线性的问答过程。但真实的数据分析是非线性的——你需要同时看多个指标、做对比、做关联、做验证。Canvas（画布）架构就是为了解决这个问题：它允许用户在一个可编辑的空间里同时操作多个分析组件，像搭积木一样构建分析逻辑。
更多关于这个演进的思考，可以参考 从 Chat 到 Canvas。
最终使用 AskTable 的，不是技术人员，而是业务人员、管理者、决策者。
他们的需求不是"更聪明的 AI"，而是"更可靠的回答"。他们不需要 AI 展示它能写多复杂的 SQL，他们需要的是：当我问一个问题时，给我的是一个我可以拿来用的答案——口径正确、权限合规、格式清晰。
这也是为什么我们强调：让每一个答案都值得信任。 这个信任不是来自模型的自信，而是来自我们对数据口径的严格把控、对权限体系的精密设计、对输出格式的反复打磨。
以上四层护城河是 AskTable 的个性化答案。但我们认为，从这两年的实践中可以提炼出一些对任何 AI 应用层产品都有参考价值的通用法则。
积极接入最新模型——Qwen 3.6-Plus、Claude Opus、GPT-5——享受每一轮模型迭代带来的能力红利。AskTable 的模型即插即用架构就是为了实现这一点：底层模型升级，不影响上层能力。
但与此同时，持续积累模型无法复制的东西：行业知识、数据连接、产品体验、用户信任。这些东西不会因为换了一个模型而过时——它们是时间的产物，是复利的来源。
关于 AskTable 如何接入最新模型，可以参考 AskTable 率先支持千问 Qwen 3.6-Plus。
行业里有很多漂亮的 AI 概念，但落地的关键是处理那些不性感的细节：
这些事做不了营销素材，但决定了产品能不能用、好不好用、用户信不信任。AskTable 投入大量精力建设手写 SQL 解析器、评测集体系、TDD 原则——这些投入在 PPT 上看不出亮点，但在生产环境里全是壁垒。
2024-2025 年的主流叙事是："AI 将替代 XX 岗位"。这种叙事制造了大量焦虑，但也制造了大量误解。
2026 年的现实更加清晰：AI 不是替代数据分析师，而是让每个业务人员都能成为数据分析师。不是替代管理者做决策，而是让管理者在做决策时有更充分的数据支撑。不是替代创业者思考，而是让创业者把时间花在真正需要人类判断力的地方。
关于这个主题，我们之前的文章 AI 不会取代数据分析师 有更深入的讨论。
AI 市场的噪声会持续存在。焦虑营销不会停止，因为焦虑是一门好生意。造神叙事会不断出现，因为故事比事实更吸引眼球。
但真正能活下来的产品和企业，不是最能喊口号的，而是最能持续交付价值的。AskTable 从 2024 年到 2026 年，产品迭代了多个版本，服务了超过 260 家客户，但核心方向从未改变：让业务人员用自然语言获取可信的数据洞察。
这种"不变"——在噪声中保持方向感的能力——恰恰是长期竞争中最大的差异化优势。
回到开篇的那个问题：水涨船高，还是被潮水淹没？
答案取决于一个选择：你是做"模型的外壳"，还是做"价值的载体"？
模型的外壳会随着模型升级而过时——今天你用 GPT-4 做了个壳，明天 GPT-5 出来了，你的壳就旧了。价值的载体会随着时间积累而增值——领域知识、数据基础设施、产品思维、用户理解，这些东西不会因为下一个模型发布而贬值，反而会因时间的沉淀而更加厚重。
做 AskTable 的过程中，我们的选择很清楚：做价值的载体，不做模型的外壳。把大量精力投入到模型"够不到"的地方——业务理解、数据治理、产品设计、用户信任。拥抱每一轮模型升级，但从不把产品的命脉押在任何一个模型上。
潮水会继续涨，但好船不需要怕水。
如果你对 AskTable 如何帮助企业用 AI 做数据分析感兴趣，欢迎 访问官网 了解更多信息，或 预约企业咨询 与我们的团队交流。