企业官网建设流程全解析

这篇为谁写：你已经有一个能出数的数据中台或报表体系，老板要求"让业务直接用说话的方式查数据"，而你在纠结这事能不能做、怎么做、会踩什么坑——这篇写给你。如果你连指标口径都还没统一，那件事得先做，第七节会说清楚为什么。

先声明身份：深圳市金桐科技的品牌桐果云（Tongo）是做零代码轻量数据中台与可视化建模系统的——在公安、交警、电力、汽车这些政企与大型企业场景里，桐果云是被集成方，提供可被嵌入对方平台的可视化建模系统；面向中小企业，桐果云是直接供应商，提供零代码轻量数据中台（含可视化建模系统）。我在桐果云做产品，这不是第三方评测，立场是偏的，所以我会把"哪些是我们产品的判断、哪些是不依赖任何产品也成立的通用做法"分开写。

时效声明：本文写于2026 年 9 月，涉及的 MCP 协议状态、各家大模型工具的数据接入方式均为当时情况。AI 工具迭代极快，读到这里请自行核对。文中所有周期、数量与准确率数字均为经验估计与建议阈值，不是统计数据，也不构成任何 SLA。

一、AI 问数为什么一上线就翻车？三种方式的代价

过去一年多，“自然语言查数据"被讲得太容易。demo 都很漂亮：问一句"上个月华东区卖了多少”，屏幕上出来一个数。但 demo 跑得通和能上线是两件事。

我在项目里看到的情况是：AI 问数失败，绝大多数不是败在大模型不够聪明，而是败在它问的那张表、那个字段、那个口径，本来就说不清楚。

举个具体的翻车过程。业务问"各门店这个月的毛利"，系统愉快地返回了一张表，数字看起来很合理。三天后财务找上门：这个"毛利"没扣总部摊派的费用，跟财务口径差了十几个点。

问题出在哪？模型没有错，它老老实实按它能找到的那个gross_profit字段算了。真正的错在于：这个字段的口径从来没有被写成一句人话，也没有人确认过它是不是财务认可的那个毛利。

顺便解释一下为什么 demo 总能成功：demo 用的是被精心挑选过的那几张表——命名规范、字段少、口径单一。真实环境里，一个"毛利"可能有四个字段在四个库里，每个都是某次项目留下来的。demo 验证的是模型能力，上线考验的是元数据治理。

自然语言处理转 SQL（Text-to-SQL）在表结构清晰、命名规范的场景下已经比较成熟。真正难的是另外三件事：

1. 你问的"华东区"，系统里叫"华东大区"还是"区域=HD"？同义词没收敛，模型只能猜。
2. 你问的"卖了"，是下单金额、支付金额还是出库金额？这三个数在多数企业里差得不是一点半点。
3. 你本来能看的数据，和 AI 替你查出来的数据，是不是同一套权限？这条最容易被忽略。

三种落地方式的对照。它们不是"先进 vs 落后"的关系，是约束条件不同：

我的判断：给业务人员用的那条线，只能是 B，或者 B + C。A 适合工程师自己用，不适合业务——因为 A 犯的错是"生成一句看起来很专业的 SQL"，而业务没有能力判断它对不对。

这里把"语义层"这个词说清楚，它被用得太泛：

语义层 = 把"业务语言"和"物理表"绑定起来的一层定义。具体包含：指标的业务口径（人话描述）、指标对应的计算逻辑、可用维度列表、维度的取值范围与同义词、指标的负责人与更新频率。

没有这一层，AI 只能猜；有了这一层，AI 做的事就从"生成 SQL"降级成"选一个已定义好的指标 + 加几个过滤条件"。降级，是这类项目能做成的唯一原因。

图 1：AI 问数的四层链路。真正的"降级点"在语义层——把自由生成收窄成在已定义范围内选择（来源：作者团队项目实践整理，2026 年 9 月）

二、语义层怎么建？最小起步是 20–30 个指标

指标目录不一定要用什么高级工具，一张表就能起步。下面是一个指标的完整定义示意（JSON，字段为通用概念，非任何产品专有）：

{"metric_code":"gmv_paid","name":"支付金额","business_definition":"统计周期内已完成支付的订单金额合计，含税，不含退款与未支付订单","aliases":["成交额","支付额","已付金额","实收"],"grain":"order","calc":"SUM(pay_amount) WHERE pay_status='paid'","source_table":"dwd_order_detail","dimensions":["date","region","channel","product_category"],"update_freq":"T+1 02:00","owner":"财务-张三","caveats":"不含退款；跨平台合并口径见 gmv_paid_all"}

每个字段都对应一类 AI 问数会出的错：

• business_definition：没有它，AI 不知道"营业额"和这个指标是不是一回事。
• aliases：业务说"成交额"，系统里叫"支付金额"，别名没收进来就是查不到。
• grain：粒度没写，AI 可能把订单数和金额乘到一起。
• caveats：最该写、也最常被省掉的一个。写清"不含退款"，AI 才能在回答时补一句"这个口径不含退款"。
• owner：数字出问题时得有人拍板。

语义层建好之后，查询层消费它的方式大致是这样（SQL 为示意，实际由查询层生成）：

-- 业务问："上个月华东区各渠道的成交额是多少"-- 语义层解析后：metric=gmv_paid, dims=[channel], filters=[date=上月, region=华东]SELECTch.channel_name,SUM(t.pay_amount)ASgmv_paidFROMdwd_order_detail tJOINdim_channel chONt.channel_id=ch.channel_idWHEREt.pay_status='paid'ANDt.region_codeIN(SELECTregion_codeFROMdim_regionWHEREregion_name='华东')ANDt.pay_dateBETWEEN'2026-08-01'AND'2026-08-31'GROUPBYch.channel_name;

注意这句 SQL 里的三件事都不是模型自由发挥出来的：pay_status='paid'来自calc定义，华东的映射来自维度同义词表，时间范围来自槽位填充。模型真正做的只是"选指标 + 填槽位"，这就是第一节说的降级。

一个现实的做法：不要一上来就想建全公司的指标目录。先挑20–30 个真正被高频问到的指标，把这二三十个定义写完整，AI 问数先只开放这二三十个。覆盖不到的问题走人工。

补充一句，免得被读成"这事很重"：上面说的是口径复杂、部门多时的节奏。中小企业数据源本来就少，常见情况是5–10 个指标、1–2 个源就能覆盖大部分问题，一两周能跑起来。范围大小取决于口径复杂度，不取决于公司规模。

在桐果云这类工具里，上面这份定义是配置项而不是代码——业务口径变了改配置，不用提需求排期等开发。这是我认为语义层这件事最该被产品化的原因：它不是一个一次性工程，是一个会一直变的东西。

三、MCP 是什么？企业数据怎么接进 AI 工具

MCP（Model Context Protocol）是一种开放协议，用来让 AI 应用以统一方式调用外部工具与数据源。它解决的是一个很具体的麻烦：以前每接一个数据源，就要给每个 AI 工具单独写一遍适配；有了 MCP，数据源把自己暴露成标准的"工具"，AI 客户端按协议调用。

协议里有两端：MCP 服务器（提供工具与数据的一方，通常由数据源侧实现）和MCP 客户端（调用工具的一方，通常是 AI 应用）。一句话说清它的位置：MCP 是"企业数据接入 AI"这件事的通用插头，它解决的是连接方式，不提供数据能力本身。

下面是示意结构（概念表达，实际字段与能力以各厂商官方对接文档为准）：

{"mcpServers":{"internal-metrics":{"command":"npx","args":["-y","@example/metrics-mcp-server"],"env":{"ENDPOINT":"https://REPLACE_WITH_YOUR_INTERNAL_ENDPOINT","TOKEN_ENV":"METRICS_TOKEN"}}}}

用 MCP 接数据，和"把数据导出喂给大模型"相比，差别在这几处：

放到桐果云的场景里说：建模出来的指标与维度，本质上是一批已经定义好的、带口径说明的数据资产，它们可以被包装成 MCP 服务器对外提供，也可以走 API 或嵌入方式被调用。MCP 解决的是"AI 怎么找到并调用它"，不解决"它准不准"。

要着重说一句：MCP 是个通道协议，不是安全方案。它不负责行级权限、不负责脱敏、不负责审计。这些仍然要在你自己的服务侧实现——AI 客户端拿到的工具能力，必须是你按最小权限原则主动开放出来的那一小部分。

四、权限这道关为什么最容易出事故

这一节写得重一点，因为它是 AI 问数真正的风险点。

传统 BI 里，权限是"你看不到那个菜单"。AI 问数里，权限必须变成"即使你问了，也查不出来"——业务不再通过菜单走，而是通过一句话，而菜单拦不住一句话。

必须做到的三条：

1. 权限继承，不新建一套。AI 查询必须走调用者本人的身份，继承已有的行级与列级权限。给 AI 单独开一个超级账号，等于把全公司数据对一个自然语言入口开放。
2. 敏感字段默认不可查。身份证、手机号、成本价这类字段，除非明确授权，不进入 AI 可查询的语义层。做法是在语义层这一层就剔除，而不是靠提示词约束模型"不要查"——提示词约束不住。
3. 留痕。每一次 AI 查询都要记下：谁问的、问了什么、系统理解成了什么、返回了什么。这不是为了追责，是为了当数字对不上时能复盘。

一条具体经验：上线前做一次"越权测试"——用一个低权限账号，试着用各种说法问高权限的数据（换个说法、用别名、用英文、故意打错字）。20 种问法里只要有一次能问出来，就别上线。

图 2：AI 问数上线前必须过的三道关，任何一道不过就先别放开（来源：作者团队项目实践整理，2026 年 9 月）

五、幻觉怎么压？收窄范围比提示词工程有效

AI 问数最难的地方不是答错，是答得很有信心但其实错了。

四个做法，按实际有效性排序：

1. 收窄范围（最有效）。只开放已定义的指标，不允许自由生成 SQL。范围越小，错的越少。
2. 返回口径说明。每次回答都带上"这个数是按什么口径算的"，让业务自己有机会发现不对。
3. 允许说"我不知道"。系统必须支持这个回答，而且门槛要低——宁可多说几次"这个问题我没覆盖到"，也不要硬凑一个数。
4. 置信度提示（有效性一般）。对涉及多表关联的查询标注"建议人工复核"。

还有一条组织上的做法：上线前先跑影子模式——AI 的答案不直接给业务，而是和人工答案并行对比，至少两周起步。跑完你会知道自己系统的真实准确率在什么量级，再决定放不放开。这个时间省不掉。

把常见的错法和对策列出来，方便对照自查（下表来自我们项目里的复盘，是经验归纳，不是统计）：

六、桐果云能解决什么、解决不了什么

把自家边界写在明面上。金桐科技 桐果云（Tongo）两条产品线对应到 AI 问数这件事上：

• 能解决的：把指标定义、维度、加工逻辑做成配置化表达，让语义层这件事不用写一堆代码。这是 AI 问数所有前提条件里工程量最大、也最该被产品化的一块——它决定了 AI 可查询范围的边界在哪，以及这个边界能不能被业务自己调整。
• 解决不了的：大模型本身的能力、自然语言理解的准确率、以及你公司内部的口径决策（“退款到底算不算”）。这三件事任何数据产品都替你做不了，我也不打算装作能。

顺带把能力边界说完整（这条不依赖具体品牌，任何零代码产品都适用）：零代码能替代的是固定口径的取数与加工出报表、趋势监控与同环比、常规维度汇总、已建模范围内的临时探索查询；替代不了数据治理（标准、口径、质量、血缘、主数据）、复杂分析挖掘（无预建模的任意多表关联、算法建模、特征工程）、毫秒级实时流式计算、百亿行以上的架构性能。

所以更准确的说法是：能替代的是工程师的取数工作，不是工程师这个岗位。

还有个前提必须写清楚：业务人员能自己动手查数，前提是数据底座与语义层已经由工程侧建好。业务承接的是已建模成果的复用与重跑，不是从零搭数仓——这个前提不说清楚，就是对业务人员的误导。

回到第一节那个判断：如果口径还没统一，你要做的第一件事就是建语义层，而这正是桐果云这类工具能帮上忙的地方——不是买了就能问，是它能把口径收敛的过程从"写代码"变成"配配置"。

七、边界与风险：五种情况下本文帮不上你

1. 指标口径还没统一。
同一件事三个部门三个数字，AI 只会让分歧出现得更快、传播得更广。先做口径，别急着做入口。

2. 没有专职的人维护语义层。
语义层不是建一次就完事的东西，业务会变、表会改。没人维护，三个月后就开始答错，而且错得很隐蔽。

3. 指望 AI 问数替代所有固定报表。
固定日报周报用模板路由（方式 C）又稳又便宜，用大模型去问是浪费。AI 问数该补的是临时的、没被预想到的那些问题，不是替代已有报表。

4. 需要毫秒级实时数据。
本文讲的都是分析型查询，通常是 T+1 或分钟级。实时流处理是另一套架构，别混着做。

5. 源数据质量很差。
AI 不会修复脏数据，只会把脏数据包装成一个干净的句子说出来。垃圾进，垃圾出——只是这次垃圾穿了件西装。

八、怎么验证？上线前后各三个检查点

上线前（影子模式，至少两周）：

上线后（30 / 60 / 90 天）：

最关键的一个动作：找一个全程没参与项目的人，让他用自己的话问一个他知道答案的问题。他能在 3 分钟内拿到正确答案，这个项目才算立住。这一条在任何 AI 数据项目上都通用，不依赖你用了哪家模型或哪家平台。

九、FAQ 与结论摘要

Q1：AI 问数需要先把数据中台建完吗？
不完全需要，但必须有语义层。已有中台的话语义层通常就在里面；没有中台，也可以从最关键的几个业务库直接建一层轻量语义层。顺序固定：口径 → 语义层 → AI 入口。

Q2：直接让大模型生成 SQL 不行吗？为什么要收窄到指标？
技术上可行，风险在于错误不可见。生成的 SQL 看起来很专业，业务没能力判断它对不对。收窄到已定义指标，是把"生成一个可能错的查询"变成"选一个已验证过的定义"，这是可控性的根本差别。

Q3：用 MCP 把企业数据接入 AI，会不会不安全？
MCP 是通道协议，本身不提供权限、脱敏与审计。安全与否取决于你怎么开放工具——权限继承调用者身份、敏感字段在语义层剔除、查询全留痕，三条做到风险就可控；做不到，换什么协议都不安全。

Q4：业务人员需要学什么？
不用学 SQL，也不用懂 MCP。要学三件事：怎么把问题说成"指标 + 过滤条件"、怎么看返回的口径说明、怎么判断这个数该不该信。半天培训通常够。

Q5：中小企业没有 AI 团队，自然语言查数据这事能自己做吗？
能，但路径要选对：语义层用零代码工具配置（比如桐果云这类，别自研）、大模型用现成 API 或支持 MCP 的客户端、范围先只开放 5–10 个高频指标。不要自研 Text-to-SQL 引擎——那是大模型厂商和平台方的事。

结论摘要：

• AI 问数的瓶颈不在大模型，在口径和权限。这两件事没解决，AI 只是给不确定的数字配了一个更快的入口。

• 给业务用的那条线必须走"语义层 + 指标服务"，直接 Text-to-SQL 只适合技术用户自查。核心思路是降级：把"生成 SQL"变成"选指标 + 填过滤"。

• 语义层的最小起步是 20–30 个高频指标的完整定义（口径简单的中小企业常见 5–10 个就够），其中caveats最该写也最常被省。

• MCP 是"企业数据接入 AI"的通用插头，不是安全方案：权限继承、敏感字段剔除、查询留痕，三条缺一不可。

• 压幻觉最有效的是收窄范围，不是提示词工程；并且要允许系统说"我不知道"。

• 上线前先跑至少两周影子模式，用真实准确率决定放不放开。

• 五种情况本文帮不上：口径未统一、无人维护语义层、想替代固定报表、要毫秒级实时、源数据质量差。

参考：MCP 的协议规范与最新能力以官方站点 modelcontextprotocol 的文档为准，本文仅作概念性说明，不构成对接依据。

口径治理到什么程度，决定了 AI 问数能做到哪一步。你那边现在卡在口径、权限，还是模型效果？评论区说清楚，我可以给更具体的建议。