这事的起因其实特别朴素——星期二的早上我一进公司就被产品经理拦在工位上连着问了三个指标上个月华东区新签客户环比为什么掉了、成交金额前十里有没有异常、库存周转 60 天以上的 SKU 还有多少。这些答案我全都能在 BI 系统里查到但每一个都要打开报表、切筛选项、导出再算一遍。等第四个类似问题出现的时候我脑子里闪过一个想法如果 BI 系统自己听得懂人话就好了。我是个后端出身的数据开发对前端的了解停留在能看懂 HTML 标签、会用点 CSS 的水平要说工程化、组件化、打包部署那套完全没上手过。所以在动这个念头之前我给自己定了三条规矩不碰前端工程化、不改 BI 系统源码、不额外申请人力就靠平台现有能力和一个后端服务把 AI 智能体接进去。最终折腾了一天还真弄成了。这篇文章就把完整的思路、选型、代码骨架、提示词设计和踩过的坑一次性写清楚。目标是让和我一样不会前端的后端、数据工程师也能照着落地不要被前端两个字劝退。1. 为什么一个不会前端的人敢碰这件事1.1 先分清两件事做前端开发和做出一个能用的页面很多人一听要给 BI 系统加对话框第一反应是这得写 React/Vue 吧。其实这是一层很深的误解。前端工程化的核心是构建复杂交互、管理状态、处理组件通信而我们要做的只是一个对话入口、一个输入框、一块聊天记录展示区——这东西用一个后端模板引擎渲染的 HTML 页面就完全能搞定原生 JavaScript 三十行足够。我实际交付的页面长这样顶部一条输入框下面是一块消息列表右侧放几个高频问题快捷按钮。没有路由、没有状态管理、没有构建工具CSS 直接引 CDN 上的公共样式库。整个前端工作量加起来不到两小时剩下的时间全花在真正的难点上AI 智能体怎么理解业务问题、怎么从 BI 系统拿数据、怎么不让它胡说八道。1.2 AI 智能体的本质是一个查询翻译服务把 AI 智能体想象成一个后厨里的传菜员业务人员说的是自然语言上个月华东区新签为什么跌了后厨真正要执行的是精确的查询参数组合指标新签客户数区域华东时间上月对比环前期。智能体的价值就在于把前者翻译成后者再把后厨端出来的结果加工成业务人员能直接看懂的结论。这个能力不需要任何页面支撑本质上是一套后端服务加一个模型接口。UI 只是入口真正干活的是中间那层服务。想通这一点不会前端这个限制条件就被绕开了大半。1.3 第一版必须守住的边界我给自己划的功能边界是只做问答结论出处不做操作、不做编辑、不做复杂看板。也就是说它能回答某指标某个维度下的情况是什么、为什么变、和谁对比但不能代替用户在 BI 系统里改报表、建告警、配置权限。守住这个边界非常重要。一方面它把工程量控制在一周内另一方面它天然规避了 AI 在操作类指令上的风险。试想一下如果业务人员说了句把华东区的报表发给王总智能体稍有偏差就不是闹着玩的了。第一版只做只读问答后面再逐步扩展能力边界。2. 三种不写前端的嵌入路线我最后选了 iframe 方案理想情况是 BI 系统自带智能助手入口但多数公司没有买这个能力。我当时梳理出三条不碰前端工程化的接入路径逐条评估后选了一条最稳的。2.1 路线一BI 原生插件/自定义组件扩展某些 BI 平台提供自定义组件或插件机制理论上可以把对话功能封装成平台内部的一个面板。但这类扩展绝大多数要求用前端框架二次开发有的还要走平台特定的 SDK、构建工具链甚至需要前端同学做代码 review。这对不会前端的人来说学习成本太高文档不熟、构建报错都排查不了果断放弃。2.2 路线二iframe 承载后端渲染的轻量页面大多数 BI 平台都支持自定义菜单/自定义链接/网页集成之类的能力本质是允许你在系统里挂一个外部 URL。既然允许挂 URL那我就可以把后端渲染的对话页面挂进去让用户感觉就像 BI 系统里长出了一个 AI 智能体面板。前端部分只有一张 HTML 模板加少量脚本完全绕开了工程化。2.3 路线三BI 开放 API 旁路接入不碰 BI 界面直接在即时通讯工具或网页门户里放一个问答机器人让它通过 BI 平台的 Open API 去取数。这个方案的优点是完全不动页面缺点是使用者要切换上下文到另一个工具里反馈链更长交互感弱一些。三种路线的对比我整理成了下面这张表方案前端工作量平台依赖度用户体验落地速度原生插件扩展高需前端工程化能力极高依赖平台 SDK最好慢iframe 嵌入极低30 行原生 JS中等只需自定义链接能力较好沉浸感强快API 旁路接入零较高依赖 Open API 完整度一般需切换工具快最终我选了方案二iframe 为主入口同时预留方案三作为后续在消息群里做告警订阅的延展。原因很简单——它用最少的前端成分实现了最接近原生功能的使用体验而且对 BI 系统本身的改动最小上线后如果发现问题直接回滚外部 URL 配置就行风险完全可控。3. AI 智能体的后脑勺查询链路和提示词设计页面只是入口真正的核心是这套链路。这部分的每个环节都值得展开讲因为所有看起来智能的效果其实都是链路里每一环的设计结果。3.1 整条链路拆解一次完整问答的长这样用户在 iframe 页面里输入提问后端接收提问附上系统提示词和业务元数据发给模型接口模型返回一个结构化的 JSON包含意图、指标、维度、筛选条件后端校验 JSON 里的每个字段确认它们都在白名单范围内后端拿着校验过的参数去调用 BI 平台的数据接口或数据仓库查询拿到数据后后端把数据摘要再次发给模型让它生成自然语言结论结论连同数据出处报表链接、口径说明一起渲染回页面。类比一下第 3 步相当于让智能体把顾客的点菜口语翻译成后厨工单第 4 步是检查工单里没有奇怪的食材第 5 步是后厨出菜第 6 步是服务员把菜摆盘端出去。每一步职责单一中间的翻译环节和出数环节完全解耦这样查出来的任何数据错误都能快速定位到底是在翻译环节还是取数环节出的问题。3.2 最关键的设计让大模型只做翻译官我见过很多失败案例是把大模型当成全能选手让它直接生成 SQL 去连数据库。结果模型一旦对表结构理解偏了就编造字段或者把筛选条件拼错出的事故几乎没法排查。我的做法恰恰相反不让模型直接接触 SQL更不让它自由发挥口径只让它做一次从自然语言到受控参数的翻译。为此我给模型准备了一份业务元数据字典相当于告诉它公司里有哪些指标、每个指标是什么意思、可以按哪些维度筛选、每个维度的枚举值是什么。比如指标新签客户数口径当月完成签约的客户去重数量统计周期自然月维度区域枚举值华东/华北/华南/西南/西北/东北时间支持自然日/自然月/自然季默认最近 30 天。有了这份字典模型的活动范围就被框死了。然后我再要求它必须输出固定 JSON 结构类似这样{ intent: metric_query, metric: new_sign_customer_cnt, dimensions: [region], filters: {region: 华东, date_range: last_month}, comparison: mom }后端拿到 JSON 后先做一次参数合法性校验所有字段必须能在元数据字典里找到找不到就拒绝执行并要求用户换种说法。模型可能会犯错但校验环节保证了它犯的错不会真正影响数据读取。这一步是整个方案最关键的防线。3.3 与数据层对接的两种姿势我在实际对接时发现数据从哪来有两种常见选项各有利弊。第一种是走 BI 平台已发布的报表接口。BI 系统通常有看板/图表数据接口传入指标、维度、时间等参数就能拿回表格数据。这种方式最大的好处是沿用了 BI 平台自己的权限体系行级、列级权限不用重复实现。缺点是接口字段不是为程序化查询设计的有些指标不能灵活组合遇到任意维度的临时交叉分析就会碰壁。第二种是直连数仓或业务库做查询。灵活度可以做到很高但意味着要自己维护一套查询权限还要在中间加超时控制、结果集限制。第一版我强烈建议优先选第一种哪怕牺牲一些灵活度也要先把权限不出错这个底线守住。我当时的选型策略是常用高频问答走 BI 报表接口保证口径和权限完全一致数仓直连只作为兜底并且限定在几个特定指标上严格控制并发和返回行数。等这套链路跑稳了再逐步放开。3.4 一个完整示例从提问到回答用户问华东上个月新签客户为什么少了那么多第一轮模型返回{ intent: metric_query_with_analysis, metric: new_sign_customer_cnt, dimensions: [region], filters: {region: 华东, date_range: 2025-08}, comparison: mom }后端校验通过后调用 BI 报表接口拿到本月数量、上期数量、环比变化率以及按签约来源分组的明细。接着后端把这些数据摘要和用户的原问题一起发给模型让它做第二轮解读结论里必须包含数值变化、变化幅度、可能相关的维度表现并标注数据来源。于是页面最终显示华东区 2025 年 8 月新签客户数为 132 家较上月减少 38 家环比 -22.4%。其中来自线上渠道的签约量下降了 29 家是主要下拉项直销渠道基本持平。数据来源销售签约明细宽表统计口径为当月完成签约的去重客户数。这个回答里每一个数字都来自真实查询结果模型只负责概括和归因方向的描述没有编造率值的空间。3.5 提示词模板的避坑写法系统提示词里有一句话特别重要你只负责把用户问题翻译成 JSON 和基于数据做总结不确定的信息要明确说不知道不得猜测字段名、枚举值和计算口径。同时我在提示词里明确列了禁止行为不允许输出 SQL、不允许访问除元数据字典之外的字段、不允许在结论中给出没有数据支撑的因果推断。另一个坑是 **输