3 层数据交付

L3 抽取原始数据 · L2 融合聚合 · L1 交付用户
L3 确定性 · 无 LLM L2 LLM 生成融合 MCP · 初级开发者审 L1 静态 HTML · 自动拉 L2 · 用户定制
结论：数据交付拆成 3 层 = 3 道信任门。L3 确定性抽取全部字段 + 字段说明（不聚合、无 AI）；L2 由 LLM 现生成融合 MCP——融合 spec + 只读查询工具，初级开发者审完即部署为常驻服务；L1 是用户定制的静态 HTML，通过本地 Node 桥自动拉取 L2 MCP 数据，刷新即最新数字、零 LLM token。改口径 → 重新生成 MCP；改展示只动 L1。

总架构 · 三层流水线

L3 · 原始数据抽取 确定性 · 无 LLM · 全量不聚合 拉取全部 SQL 字段 + 字段说明 保留明细，不做任何聚合 产物: 全量字段 + 字段说明 监督: schema / 系统 职责 = 字段完整 + 说明准确 非 AI 职责：不缺字段、不丢明细 绿灯: 确定性，可全量跑 失败信号: 字段缺失 / 说明不准 全量字段 + 字段说明 L2 · 融合 MCP（LLM 生成） LLM 生成 spec + 查询工具 → 常驻 MCP LLM 读全量字段说明，生成 join 键 / 粒度 / 指标 编译为只读查询工具，部署为常驻 MCP server 产物: 融合 MCP + 查询工具 监督: 初级开发者 审 join 键 / 粒度 / 聚合口径 审 查询工具定义 + 只读约束 审过 → 部署常驻运行态 黄灯: 回炉重生成，版本可回滚 融合数据 JSON 本地 Node 桥 HTTP 127.0.0.1:8787 · CORS 开放 · 只转发 JSON → 渲染 L1 · 静态 HTML 交付 用户定制 · 打开即自动拉 L2 数据 单文件静态 HTML，布局 / 图型 / 配色由用户调 JS fetch 本地桥 → L2 MCP 查询 → JSON 渲染 产物: 可视化看板 · 自动刷新 监督: 用户 定制 L1: 图型 / 配色 / 粒度 业务校验: 数字对得上问题吗 改口径 → 触发重新生成 MCP 紫灯: 用户最终拍板 改口径 → 重新生成 MCP 决策者 · 用户 看板常开 · 读图决策 · 零 LLM token

三层职责 · 窄门对比

点击表头排序 · 每层只交换最小必要信息
层 核心动作 监督人 是否 LLM 产物 失败信号
L3全字段抽取schema / 系统否（确定性）原始宽表 / 完整结果集字段缺失、说明不准
L2生成融合 MCP初级开发者是（生成时）融合 MCP / 查询工具join 键错、口径错
L1可视化交付用户否（渲染）表格 / 图表 / 仪表盘看不懂、口径对不上业务

示例 · sql-query 实战

问题: “护舒宝品线每天消耗和 ROI”
L3 · 原始产物 全量字段 + 字段说明，无缺省 SELECT date, 品线, ADVERTISER_ID, SUM(consum) AS 消耗, SUM(revenue) AS 收入 FROM fact_ads GROUP BY date, 品线 字段说明: consum = 广告花费 revenue = 归因收入 ROI = 收入 / 消耗 拉全部字段，不做判断 L2 · 融合 MCP（LLM 生成） spec → 查询工具 → 常驻 MCP LLM 生成查询工具: query_ads_fusion( date_from, date_to, product_line = '护舒宝' ) -> { date, 消耗, ROI } 初级开发者审阅: ✓ join 键 / 粒度 / 口径 ✓ 工具只读 · 参数有界 审过 → 部署常驻 MCP L1 · 静态 HTML（用户定制） 打开即自动拉 L2 数据 柱 = 消耗 · 折线 = ROI（示意） JS fetch → 本地桥 :8787 → L2 MCP 查询 → JSON → 渲染 刷新零 LLM token · 用户定制

现实映射 · 本项目落地对照

本仓库已按此三层落地，逐层对照（缺口已标）
层概念本项目落地状态
L3全字段 + 字段说明video-management-ontology-fork MCP · 37 张 QC_* 表 · db_query / ont_get_table✅ 落地
L2融合层 · 只读查询工具scripts/data-ontology-bridge/server.mjs 桥 · 8 融合 SQL · 60s 缓存 · hexagonal⚠️ 手写 SQL，非 LLM 生成
L1静态 HTML 自动拉workspace/analytics/qianchuan-dp-dashboard.html + huggies 子报告 · fetch 桥 → MCP✅ 落地
部署：看板 https://qianchuan-dp-dashboard.pages.dev（静态壳公网，数据经 tailnet 桥 100.125.95.86:8320）· 本页 https://l3-l2-l1-delivery.pages.dev

关键概念

L3

全字段抽取

拉全部 SQL 字段 + 字段说明，不挑、不聚合。字段全不全 = L3 唯一质检。

L3

字段说明

每字段给中文释义 + 样例值，作为 L2 生成口径的依据。

L3

明细保留

不提前聚合。聚合属于 L2，L3 只保证无损。

L2

融合 MCP（LLM 生成）

LLM 读全量字段说明，生成融合 spec + 只读查询工具，编译成常驻 MCP server。不是写死的报表。

L2

初级开发者监督

技术审：join 键成立、口径正确、指标定义清晰。审过才放行。

L2

MCP 版本化

每次重生成留 spec hash + 查询工具定义，MCP 可回滚到旧版本。

L1

静态 HTML 看板

单文件静态 HTML，模板含表格 / 折线 / 柱状 / 仪表盘，用户选型定制。

L1

用户定制

布局、配色、图表类型、粒度由用户改。L1 只负责怎么展示，怎么算归 L2。

L1

自动拉取 · 零 LLM token

JS fetch 本地桥 → L2 MCP → JSON。刷新数字不经 LLM，token 只花在 L2 生成那一刻。

L1

口径回环

用户发现口径不对 → 触发重新生成 MCP（LLM 一次）→ 初级开发审 → 部署 → L1 自动生效。改展示只动 L1。

·

本地 Node 桥

薄 HTTP 服务，把 L1 静态 HTML 的 fetch 转发给 L2 MCP，CORS 开放，只转发不计算。

·

信任边界

三层 = 三道门，每层一个监督人：L3 系统、L2 初级开发者、L1 用户。职责不串。

·

可审计下钻

任意图表可下钻到聚合 spec，再下钻到原始字段。每层产物留痕。

落地行动清单

0 / 8 已勾选
设计要点 · 为什么这样分
  • ·单一监督人：每层只有一个人负责。L3 交给系统（确定性），L2 交给初级开发者（技术），L1 交给用户（业务）。多人交叉审核三层 = 责任稀释。
  • ·LLM 只花在 L2 生成那一刻：LLM 生成融合 MCP 一次，之后 L1 刷新数字走桥走 MCP，零 LLM token。L3 用 LLM 浪费（确定性抽取），L1 用 LLM 抖动（展示该稳定）。
  • ·L1 是静态 HTML，不是后端页面：单文件 + 本地桥 + MCP 查询工具 = 自动刷新看板，不背服务端渲染。
  • ·窄网关：L3→L2 只传“全量字段+说明”，L2→L1 通过 MCP 查询工具只传所需字段。每层不背邻居的上下文。
  • ·口径回环是闭环：用户改口径 → 重新生成 MCP（LLM 一次）→ 初级开发审 → 部署 → L1 自动生效。改展示只动 L1。
  • ·可审计：任何一张图都能下钻到查询工具、再到原始字段。信任来自可复现。
来源：独立概念设计（三层数据交付 L3→L2→L1）· 与本项目代码无关，本会话未探索 repo
文件：/tmp/l3-l2-l1-delivery-onepager.html · 生成：onepager 窄门单页 · 单文件自包含，无 CDN / 无外链
L1 静态 HTML 经本地桥拉 L2 MCP：桥需带 Access-Control-Allow-Origin: * 才能被 file:// 页面 fetch