这是园区数字化落地系列的技术第六篇。前五篇分别讲四层架构与数据建模、四端协同的事件驱动架构、指标口径中心、读时建模与多源异构接入、NL2SQL 的落地链路。第五篇把一句人话怎么变成 SQL 讲完了这一篇接着往后看SQL 跑完之后平台怎么把结果变成业务方敢拍板的东西。第五篇末尾那张踩坑表里有一行叫「结果不可核对」写的是只给一个数业务方问哪来的答不上。这一行不是随手写的。我们上线头两个月被老板问住的次数八成出在「数给你了但你说不清它怎么来的」。本篇就拆这件事看平台怎么把一次查询变成四样东西让每条回答都带证据链。一、只给结论的产品为什么没人敢用问数平台最容易做成黑盒。用户问一句屏幕弹一个数完事。这个数对不对全凭信任。园区里信不过黑盒。财务拿到「本月收缴率 92%」第一反应不是高兴是问「按哪个口径含不含历史欠费」。运营拿到「空置房源 37 间」会去翻房源表核对楼栋分布。只要答不上来源这个数就不算数还不如当初让人自己查。我们后来把验收标准定死一次问答必须同时产出四样缺一样业务方就拒收。这一条比模型准不准还靠前。二、一次问答的四件套产物这四样分别是结论、图表、明细、来源。结论是一句话的答案比如「本月收缴率 92%较上月升 3 个点」。它必须能被图表和明细支撑不能单独出现。图表是结论的可视化折线看趋势柱状看对比饼图看占比。图表的数据点要能点开不能只是装饰。明细是支撑结论的原始行业务方想深挖就能下载到每一笔账单、每一间房。业务方要核对原始账就得靠它。没有明细结论再漂亮也没法验证。来源标注这条结论从哪个库、哪张表、哪个字段、哪个口径版本、什么时间窗口算出来的。来源说不清前三项都站不住。四件套里明细和来源最容易被偷懒省掉却恰恰是业务方最看重的。我们强制在服务端塑形不依赖前端兜。三、产物怎么从 SQL 长出来第五篇的 L4 叫执行回填本篇把它拆细。一次查询从 SQL 到四件套走四步。第一步只读账号执行 SQL拿到原始结果集。这一步不碰原业务库写权限纯粹读。第二步结果塑形。把结果集按意图拆成聚合层和明细层聚合层喂给结论和图表明细层落一张临时导出表。第三步口径挂接。从口径中心拉出这条指标的定义、计算 SQL、数据时间戳、版本号贴到来源标签上。第四步三级下钻装配。结论卡、图表、明细入口、来源标签组装成一个回答页前端各取所需。塑形这一步我们踩过坑。最初让前端自己决定哪些字段做图、哪些做表结果不同端展示不一致同一个数在网页和手机上长的两样。后来把塑形逻辑收归服务端前端只负责渲染一致性才稳住。四、支撑四件套的数据模型四件套不能只在内存里拼一下就返回得落库不然没法审计、没法回溯、没法版本化。我们建了三张表。sql-- 产物元数据, 每次问答的产物登记, 四件套各挂一项 CREATE TABLE answer_artifact ( answer_id VARCHAR(64) NOT NULL COMMENT 一次问答的编号, kind VARCHAR(16) NOT NULL COMMENT conclusion/chart/detail/source, payload MEDIUMTEXT NOT NULL COMMENT 结论文本 或 图表配置 或 明细表名 或 来源 JSON, metric_code VARCHAR(64) COMMENT 关联的指标编码, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (answer_id, kind), INDEX idx_metric (metric_code) ) COMMENT问答产物; -- 口径血缘, 每个指标标注取数路径与版本 CREATE TABLE metric_lineage ( metric_code VARCHAR(64) NOT NULL COMMENT 指标编码, 如 collection_rate, version VARCHAR(16) NOT NULL COMMENT 口径版本, 如 v202610, catalog_path VARCHAR(128) NOT NULL COMMENT catalog 路径, 如 park/room/bill, calc_sql TEXT NOT NULL COMMENT 该版本的计算 SQL, data_as_of DATETIME NOT NULL COMMENT 数据时间戳, 取数快照点, owner VARCHAR(32) NOT NULL COMMENT 口径负责人, PRIMARY KEY (metric_code, version) ) COMMENT指标口径血缘; -- 明细导出任务, 支撑下载的原始行 CREATE TABLE detail_export_job ( job_id VARCHAR(64) NOT NULL PRIMARY KEY, answer_id VARCHAR(64) NOT NULL COMMENT 所属问答, src_sql TEXT NOT NULL COMMENT 取明细的原始 SQL, 含权限裁剪, row_count INT COMMENT 导出行数, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待跑 1完成 2失败, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) COMMENT明细导出任务;三张表各管一段answer_artifact记产物metric_lineage记口径来历detail_export_job记明细出处。业务方质疑时拿 answer_id 一查四件套和来源全在。五、口径来源怎么标注来源标签是业务方最在意的我们把它做成结构化字段而不是一句话描述。每个指标在metric_lineage里登记 catalog 路径、计算 SQL、数据时间戳、版本。查询时平台先取指标的当前生效版本再把血缘拼进来源标签。sql-- 取指标的当前生效口径, 拼进来源标签 SELECT l.catalog_path, l.calc_sql, l.data_as_of, CONCAT(l.metric_code, , l.version) AS lineage_tag FROM metric_lineage l WHERE l.metric_code collection_rate AND l.version ( SELECT MAX(version) FROM metric_lineage WHERE metric_code collection_rate );来源标签返回到前端长这样业务方一眼看到数从哪张表、哪个版本、什么时点算的。json{ metric: collection_rate, lineage_tag: collection_ratev202610, catalog_path: park/bill/collection, data_as_of: 2026-10-22 23:59:59, calc: 实收金额 / 应收金额, 含本期及历史欠费 }数据时间戳这道关很关键。园区口径常按月结十月二十二号问的数应当快照到九月三十号的账期而不是实时库里还在变的流水。data_as_of就是把这点钉死避免同一个人早晚问出两个收缴率。六、明细下钻的取数结论和图表是聚合层明细是原始层。下钻时不能再去重算一遍聚合 SQL那样慢且易错。我们的做法是聚合层和明细层共用同一条带权限的底层 SQL聚合做 GROUP BY明细直接 SELECT 原始行。sql-- 底层带权限的取数 SQL, 聚合与明细共用 SELECT b.building_name, bil.tenant_id, bil.bill_no, bil.receivable, bil.received, bil.due_date FROM fact_bill bil JOIN dim_building b ON bil.building_id b.building_id WHERE bil.period_month 2026-09 AND bil.building_id IN ( SELECT building_id FROM user_visible_building WHERE user_id u_1024 ); -- 结论与图表, 在底层结果上聚合 SELECT building_name, SUM(received) / NULLIF(SUM(receivable), 0) AS rate FROM ( /* 上面的底层 SQL */ ) t GROUP BY building_name; -- 明细, 直接取底层原始行, 落导出任务 INSERT INTO detail_export_job (job_id, answer_id, src_sql, status) VALUES (dj_8841, ans_5520, /* 底层 SQL */, 0);这样聚合和明细永远对得上不会出现图显示 92% 但下载的明细加起来是 88% 的尴尬。明细落任务表后异步跑前端拿 job_id 轮询大表也不卡界面。七、口径版本怎么治理口径会变。九月收缴率含历史欠费十月财务改主意要剔除非本期账单口径就漂移了。漂移不可怕怕的是悄悄变昨天答的和今天答的用的不是一套算法业务方却不知道。我们把口径当成带版本的配置管变更要走灰度、通知、回滚、审计四步。yamlmetrics: - code: collection_rate versions: - tag: v202609 calc_sql: | SELECT SUM(received)/SUM(receivable) FROM fact_bill WHERE period_month2026-09 data_as_of: 2026-09-30 23:59:59 owner: 财务-王磊 status: archived - tag: v202610 calc_sql: | SELECT SUM(received)/SUM(receivable) FROM fact_bill WHERE period_month2026-09 AND is_current_period1 data_as_of: 2026-10-22 23:59:59 owner: 财务-王磊 status: active rollout: gray_ratio: 0.2 # 先放 20% 查询命中新口径 notify: [财务群, 运营群] # 变更群内播报 rollback: v202609 # 出问题一键回退 audit: true # 每次口径命中留审计记录灰度让新口径先在小流量验证通知让相关方知情回滚保底审计兜底。口径变更走配置某个工程师改条 SQL 就自动生效的事不会再发生。历史回答挂的是当时的版本号回头查九月的数拉 v202609不会被十月的改动污染。八、权限与审计可核对的前提是可查可查的前提是权限守得住。平台用专用只读账号连库不等于能翻任意一张表。我们在三个层面收口。账号层给问数平台单独开一个只读账号权限范围由 DBA 配原系统读写账号绝不共用。对象层可查对象走白名单。语义层只登记允许被问的表和字段没登记的表生成层根本看不到更不会进 SQL。审计层每次查询落一条记录谁问的、问了什么、跑了哪条 SQL、命中哪个可见范围、返回多少行、耗时多少全记下来。json{ account: rd_askbot_ro, privilege: read_only, visible_objects: [dim_room, dim_building, fact_lease, fact_bill], query_log: { user_id: u_1024, question: 本月各楼栋空置房源数, final_sql: SELECT ... AND building_id IN (SELECT building_id FROM user_visible_building WHERE user_idu_1024), row_scope: building1,3,7, result_rows: 42, elapsed_ms: 318, asked_at: 2026-10-22 14:05:11 } }权限这道锁宁可多一道不嫌烦。我们试过只靠提示词约束模型别查敏感字段十次里有两次还是查了。改成账号层只读、对象层白名单、召回层剔除三层同时收口敏感字段从一开始就进不来。九、工程踩坑表按踩到的频率排长这样。坑现象解法只给结论弹一个数业务方问来源答不上强制四件套结论图表明细来源一个不少明细缺位图显示 92%下载明细对不上聚合与明细共用同一条带权限底层 SQL口径漂移同日问同指标前后两版算法口径带版本号变更走灰度回滚审计数据时点乱早晚问出两个收缴率口径钉死 data_as_of 快照点前端各做各网页和手机展示不一致塑形逻辑收归服务端前端只渲染敏感字段泄露提示词约束模型偶尔还查账号只读对象白名单召回剔除三层收口明细卡界面大表直接查界面转圈明细落导出任务异步跑前端轮询来源一句话来源写成自然语言不可机读来源结构化catalog 路径SQL时间戳版本口径改动无痕工程师改条 SQL 就生效口径当配置管变更群内播报留痕历史污染查九月的数被十月改动影响历史回答挂当时版本号回溯不受影响十、关于本文涉及的两套系统这套可核对工程不是凭空长出来的它的输入和运行环境靠两套系统配合。智慧园区系统四端一体的运营平台负责把业务在线办完、过程留痕、数据结构化沉淀。房源、租客、合同、账单都从这里出是问数平台的唯一数据源。没有它语义层就没有可问的对象明细和来源也无从谈起。数智安全问数平台鲁联数智提供在园区系统之上加一个问数入口。只读接入不改原业务表结构NL2SQL 把人话翻成 SQL本篇讲的四件套塑形、口径血缘、明细下钻、版本治理是它把数变成证据链的实打实工程。一句话智慧园区系统管发生问数平台管看懂可核对是看懂这件事能不能让人服气的那道关。