可稳定传递的数据指标加工逻辑语义体系研究与落地
项目聚集： 数据指标加工逻辑语义真源是什么 数据指标加工逻辑语义如何实现跨 LLM 智能体稳定传递 人与 LLM 智能体如何实现高效协同
第一部分：需求理解与目标
先把问题定义清楚，再说明这件事为什么值得做、为什么值得持续投入
第二部分：技术方案
围绕语义真源、闭环流程和交接载体，建立一套可落地的受控体系
第三部分：升级路线
从当前可落地的单表场景，逐步走向全域治理与真实数据环境中的智能作业
问题不在于是否能自动化生成 SQL，而在于业务语义能否被稳定沉淀与接力
当前仍主要依赖人类闭环
现有模式能交付结果，本质仍是人理解业务、人确认口径、人组织交付
核心痛点与现实难点
- 业务持续运营，数据加工与分析需求就会持续产生
- 主要成本不在写代码，而在指标口径的理解、确认和传递
- 一旦脱离原参与人，逻辑就容易漂移并引发返工
- 直接让 LLM 写 SQL，也解决不了口径漂移问题
要建设的不是一次性生成能力，而是可持续传承的数据语义资产
行业已经证明方向成立，真正难的不是生成，而是把业务语义沉淀成稳定依据
语义建模与指标层
- 代表项目：LookML、dbt Semantic Layer / MetricFlow、Malloy、Cube
- 共同特点：先定义业务含义，再派生查询和下游消费
面向 AI 的受控语义层
- 代表项目：Snowflake Cortex Analyst、Databricks Genie、Power BI Copilot
- 共同特点：AI 想稳定工作，必须先拿到结构化语义和解释信息
结构化上下文与协议层
- 代表项目：dbt structured context、dbt Agents / MCP Server、OSI、ODCS
- 共同特点：跨工具、跨智能体协同时，必须有统一上下文和交接规则
行业正在形成同一条演进路径：把业务定义从代码中抽离，把智能能力建立在受控语义与统一上下文之上
本项目要补上的，正是这条路径中最关键也最稀缺的一环：让业务语义先成为可稳定传递的正式资产
项目目标不是自动化生成 SQL，而是让数据加工逻辑被稳定理解、接力和沉淀
让人更容易把逻辑说清、接住、沉淀
- 把零散需求收敛成清晰、可审阅、可确认的数据加工逻辑
- 让接手人摆脱对原参与人口头解释的依赖，并让已确认逻辑沉淀为可复用资产
让智能体更稳定理解、接手和派生逻辑
- 让智能体拿到稳定、明确、边界清楚的输入，而不是依赖自由猜测
- 让不同智能体围绕同一份逻辑稳定接手与派生，把交付变成可校验、可回退、可复用的过程
先解决效率与交付问题
- 让无代码能力的业务人员也能完成高质量交付
- 减少重复澄清、重复解释和返工，并让新接手人和新智能体更快进入可工作状态
成为组织数智化能力的重要基石
- 把数据指标口径语义沉淀为组织级基础资产，为全局语义治理和跨系统统一口径打基础
- 只有先解决数据指标口径语义的精准表达，后续数智化能力才可能真正做深做稳
先把数据加工逻辑固定成真源，再让人和智能体围绕真源稳定协作与接手
先把数据加工逻辑逐项写清，形成统一真源，并嵌入人和智能体协作流程
再把真源装入交接载体，让不同智能体接手时仍按同一口径持续工作
短期阶段：先把单目标表场景做稳
当前阶段人负责目标、边界和裁决，智能体负责整理、派生和执行
把一张目标表的加工逻辑逐项写清，固定成唯一依据
围绕真源派生说明材料、交接材料和 SQL
先把最常见、最刚需的一类任务做稳做透
先解决语义确认、冻结、开发和审阅反复漂移的问题
中长期阶段：把稳定接手扩展为持续治理能力
能力放大前期积累的语义资产继续作为统一基准
把同一份逻辑稳定交给不同智能体持续接手
让不同阶段、不同智能体围绕同一份逻辑持续工作
让智能体在更大范围承担管理、开发和协同任务
再把稳定接手升级成稳定控制，让语义在不同智能体之间持续传递
数据加工逻辑语义真源是一张目标表的业务定义底稿，让逻辑写得清、审得动、接得稳
它不是代码模板，而是把聊天、说明和 SQL 中分散的业务语义抽离出来，沉淀成一张目标表的唯一业务依据
对人类，逻辑按目标、粒度、规则、字段逐项写清，可读、可审、可接手
对智能体，真源可派生镜像 YAML 和交接工件，在受控边界内稳定收敛同一份数据加工逻辑
自然语义
上手快“做一张用户按天统计支付金额的表，只算支付成功订单”
SQL
可执行INSERT OVERWRITE ... SELECT user_id, trade_dt, SUM(pay_amt) AS trade_amt FROM ... WHERE order_status = 'success';
数据加工逻辑语义真源
推荐形态目标表 = ads_user_trade_day 统计粒度 = 用户 + 交易日 统计规则 = 仅统计支付成功订单 指标定义 = trade_amt = 支付金额汇总 输出字段 = user_id / trade_dt / trade_amt
审阅材料、口径确认稿
镜像 YAML、交接协议包、语义断言集、接手理解回执
SQL、DDL、测试案例
新闭环把“反复解释”改造成“分阶段冻结”，让人的工作从机械补材料抬升到定目标、定边界和做裁决
| 角色 | 旧流程状态 | 新闭环职责 | 变化结果 |
|---|---|---|---|
| 人 | 反复解释、反复补材料、反复纠细节 | 定目标、定边界、做裁决、做最终确认 | 工作重心上移到思考、规划、设计和把关 |
| 智能体 | 更像被动生成器 | 归纳理解、组织问题、整理结构、受控派生 | 承接重复整理和执行性工作，放大人的判断效率 |
提出目标
人给出目标、已知事实和已有边界
整理问题
智能体归纳语义空白，组织待确认问题
关键裁决
人在关键口径节点给出明确裁决
沉淀真源
智能体按裁决结果整理业务真源
冻结放行
人完成最终确认，进入受控派生
交接载体让智能体接手变成可约束、可校验、可回退的正式流程
只靠提示词，锁不住数据指标加工口径
- 只能告诉智能体“尽量这样做”，不能规定读取顺序和执行顺序
- 理解是否一致无法核对，换实例或换模型都可能漂移
- 所以能写出 SQL，不等于指标加工逻辑真正对齐
本项目把接手约束做成正式交付
明确这次接手必须读取什么
把真源转成机器稳定消费格式
约束读取顺序、允许动作和禁止动作
锁住关键口径不得偏移
先回执理解，再决定是否继续
用 ALLOW / DENY 明确放行与回退
交接载体不再是补充资料，而是把接手质量变成可控制、可追溯的制度能力
真实运行形态是人发起任务，Cline 在规则与工具约束下完成受控接手
把交接协议包目录作为主输入，不再逐个粘贴文件
明确本次要完成回执、派生还是校验
按需要指定派生产物的落点
门禁未通过时，人回到真源或回执环节做修订
当前真实形态不是把资料塞进对话，而是让 Cline 在工作区规则、协议包和 WhisperMesh MCP tools 约束下完成接手
先读 `.clinerules`，再按清单读取真源镜像与回执模板
执行 `validate / prepare_receipt / gate / derivation` 等关键动作
把结果写回 manifest，并显式给出 `ALLOW / DENY`
人不再反复口头解释逻辑，只在目标设定、关键裁决和回退修订时介入
先返回对真源的理解，再进入下一步判断
把是否允许继续变成显式门禁结果
通过则派生文档、SQL、测试案例，不通过则回退修订
项目真正要占住的，是智能体进入数据开发领域的关键入口
先把数据指标加工逻辑语义写清，再把全局口径管住，最终把真实数据作业接过来
谁先建成这条能力链，谁就更有机会把数智化真正落进未来的数据开发体系
先接手口径语义
当前还不能直连真实生产数据，先承担指标口径整理、冻结后派生和受控接手
智能体首先成为数据开发中的语义协作助手
再接管全局口径
当语义真源规模化沉淀后，统一管理组织中的数据指标加工逻辑语义
智能体成为实际掌握全局口径的治理中枢
最终接管真实作业
当算力、合规、安全和权限条件成熟后，直接加工、管理和分析真实数据指标
智能体由治理中枢进一步演进为数据开发主体
术语、来源和附页统一收口，便于现场按需展开
避免被名词打断，也方便从主汇报一键展开到细节
术语说明
当前任务中唯一有效的业务逻辑依据
本报告正式说法，业务真源是其简写
单目标表数据加工逻辑的标准写法
本报告对外用语，对应仓库中的“人机协作工作流”
交给接手智能体的标准化交接载体
决定是否允许进入下一步派生的显式校验结果
引用文档与附页入口
同类项目主要收敛为三条路径：语义建模与指标层、面向 AI 的受控语义层、结构化上下文与协议层
| 一、语义建模与指标层项目 | 代表项目 | 已证明的内容 | 对本项目的启发 | 不能直接复用的部分 |
|---|---|---|---|---|
| BI 语义建模 | LookML | 业务定义不应散落在 SQL 与报表里 | 说明独立语义层不是伪命题 | 默认建模已完成，不负责碎片语义澄清 |
| 指标 / 语义层 | dbt Semantic Layer / MetricFlow | 统一指标定义和语义复用是现实需求 | 说明语义真源与执行层分离是合理方向 | 更偏指标治理，不覆盖裁决闭环 |
| 语义查询语言 | Malloy | 先建可复用定义，再派生 SQL 可以落地 | 与 Table-DLC 到 SQL 的思想高度相通 | 更偏分析建模语言，不等于跨智能体交接协议 |
| 通用语义层 | Cube | 一处定义、多处消费成立 | 支持真源分层思想 | 不解决需求澄清和口径裁决 |
核心判断
- 这条路径已经充分证明，把业务定义从 SQL 中抽离出来是成立方向
- 对本项目最直接的启发，是先建真源，再做派生
- 但现成产品并不负责碎片语义澄清和口径裁决，这一段仍需本项目自己补上
| 二、面向 AI 的受控语义层项目 | 代表项目 | 已证明的内容 | 对本项目的启发 | 不能直接复用的部分 |
|---|---|---|---|---|
| AI 分析问答 | Snowflake Cortex Analyst | 没有语义模型时 NL2SQL 容易偏移，有语义模型后精度更可控 | DLC-YAML 的方向是对的 | 主要解决如何消费语义模型，不解决如何生成真源 |
| AI / BI 问答 | Databricks Genie | 仅靠表结构不够，必须补足说明、示例和指令层 | 单靠真源镜像通常不足，还要有额外壳层 | 偏问答和自助分析，不是项目级语义成卡体系 |
| BI Copilot | Power BI Copilot | Copilot 输出质量强依赖语义模型质量 | 术语、同义词、字段说明必须成为正式资产 | 仍是既有模型上的辅助生成，不等价于业务语义真源建设 |
核心判断
- 这条路径已经证明，AI 想稳定工作，必须先吃到结构化语义层
- 对本项目最重要的启发，是纯真源镜像通常不够，还要有解释层、指南层和校验层
- 这说明交接载体不是附属文档，而是智能体稳定接手的必要条件
| 三、结构化上下文与协议层项目 | 代表项目 | 已证明的内容 | 对本项目的启发 | 不能直接复用的部分 |
|---|---|---|---|---|
| 结构化上下文 | dbt structured context layer | Agent 的可靠性取决于能否获得结构化上下文 | 项目不应只做文档，还应做可消费上下文层 | dbt 的上下文来自现成工程资产，不是需求澄清产物 |
| 任务型 Agent | dbt Agents / dbt MCP Server | 跨工具共享同一语义上下文是行业方向 | 说明跨智能体高一致性交接值得单独设计 | dbt 不是当前语义真源的直接宿主 |
| 语义互操作标准 | OSI | 语义互操作已是公开议题 | 说明跨智能体、跨平台交接是核心痛点 | OSI 不会替本项目定义中文语义卡写法 |
| 数据契约标准 | ODCS | 结构化协作协议可以标准化 | 对格式约束和协作边界有借鉴意义 | ODCS 不是业务口径澄清协议 |
核心判断
- 这条路径已经证明，跨工具、跨智能体共享统一上下文和交接规则，是未来演进的基础能力
- 对本项目最核心的启发，是跨 LLM 接力不能继续依赖会话记忆，必须外置成结构化载体
- 但现有标准和框架仍无法直接替代中文业务语义成卡、裁决流程和单表真源写法
来源依据：内部评估材料，公网版本不展开原文
Table-DLC 规范把一张目标表的数据加工逻辑固定为中文结构化真源
Table-DLC 是单目标表数据加工逻辑语义真源的标准写法，用来把一张目标表的目标、粒度、规则、字段和校验固定成唯一业务依据
业务只审这份中文真源，镜像 YAML 等结构化格式只做无损导出，供智能体消费和派生
| 固定区块 | 必须写清的内容 | 作用 |
|---|---|---|
| 目标表 | 唯一目标输出表名 | 锁定这张卡到底描述哪张表 |
| 粒度 | 每一行成立的唯一业务粒度 | 避免“按天统计”这类模糊表达 |
| 时间口径 | 统计所依据的业务时间定义 | 避免把字段名误当成业务口径 |
| 主体 | 本表统计和描述的核心对象 | 确保统计对象边界稳定 |
| 事件 | 被统计或加工的业务记录集合 | 明确哪些记录算、哪些不算 |
| 来源 | 输入表别名与物理表名 | 让规则和字段都能回指来源 |
| 表级规则 | 记录集如何形成的规则链 | 固定关联、保留、排除、去重、派生、汇总顺序 |
| 输出字段定义 | 字段口径、来源、加工逻辑、依赖规则、空值处理 | 把字段级语义写清写透 |
| 校验 | 输入场景与期望结果 | 验证逻辑没有发生偏移 |
设计原则
- 单真源：最终版 Table-DLC 是目标表数据加工逻辑的唯一业务依据
- 一卡一表：一张卡只描述一张目标输出表和一种最终粒度
- 中文优先：先保证人类可理解、可校验、可裁决
- 无待定项：最终真源中不允许写入“待定”“后续确认”等内容
- 表级加字段级双层完整：既写记录集形成规则，也写字段口径和加工逻辑
- 纯格式镜像：JSON / YAML 只做无损导出，不新增推断、不改写语义
固定模板
目标表: 粒度: 时间口径: 主体: 事件: 来源: 表级规则: 输出字段定义: 校验:
| 关键填写要求 | 必须满足 | 常见错误 |
|---|---|---|
| 粒度 | 必须写成字段组合 | 只写“按客户每天统计” |
| 时间口径 | 必须写业务定义 | 直接把字段名当口径 |
| 来源 | 必须列出别名与物理表名 | 只写“交易表”“客户表” |
| 表级规则 | 每条规则都要有编号，并只用受控动词 | 把字段口径和规则链混写在一起 |
| 输出字段定义 | 每个字段都要写字段类型、口径、来源、加工逻辑、依赖规则、空值处理 | 只列字段名或只写一个公式名 |
| 指标字段 | 必须写清聚合前加工和聚合后加工顺序 | 直接把结果写成 `avg(txn_amt)` 这类黑盒表达 |
| 校验 | 必须给出输入场景和期望结果 | 只写“后续测试”“待验证” |
生成前置条件
- 目标表、粒度、时间口径、主体、事件都已经明确
- 关键待确认问题已经完成裁决，不再存在默认假设
- 表级规则可以连续写出，输出字段都能给出字段级定义
- 至少已有最小校验样例
- 只要不满足以上条件，就还停留在问题清单、裁决或差异澄清阶段
纯格式镜像原则
- 镜像 YAML / JSON 只负责把中文真源无损展开给机器消费
- 不允许新增推断字段，不允许改写中文规则语义，不允许重排依赖关系
- 业务只审核中文 Table-DLC，镜像格式不构成新的业务真源
拆卡规则
- 目标表不同，必须拆卡
- 粒度不同，必须拆卡
- 主体定义不同，必须拆卡
- 事件定义不同，必须拆卡
- 如果只是字段很多、指标很多或中间步骤很多，不构成拆卡理由
术语与语义约束
- “粒度”必须写字段组合，不能和“维度”混用
- “时间口径”强调业务定义，不能退化成字段名
- “表级规则”只写记录集形成逻辑，不写字段口径细节
- 规则句只允许使用关联、保留、排除、去重、派生、映射、汇总
- 最终版 Table-DLC 不允许出现待定项，同一张卡也不得同时承载多张目标表逻辑
来源依据：内部规范材料，公网版本不展开原文
当前阶段协作闭环的细化链路是：先收集最小事实，再集中澄清问题，再做口径裁决，最后冻结真源
各环节职责
- 初始输入：只提交最小必要背景，先锁定目标表、业务目标和已知约束
- 待确认问题：把还不能写入真源的缺口集中列出
- 口径裁决：对存在分歧的事项做显式裁决，并标明影响范围
- 冻结确认：确认真源已无待定项，再决定是否进入交接协议包
退出条件
- 单目标表范围明确
- Table-DLC 已完成且无待定项
- 关键口径已有裁决或已写入真源
- 冻结确认单明确同意进入下一阶段
来源依据：内部流程材料，公网版本不展开原文
交接载体展开后，本质是一套让智能体按顺序读、按边界做、按门禁停的运行协议
组成要点
- 协议包负责把真源转成智能体可稳定消费的交接单元
- 运行约束负责限定读取顺序、可执行动作和禁止动作
- 本地工具与 MCP 负责校验、派生和过程支撑
- 门禁结果负责决定放行、回退或补充裁决
为什么不是文档堆叠
- 它不仅告诉智能体“看什么”，还规定“先看什么、后做什么”
- 它不仅提供资料，还能校验齐备性、理解状态和放行条件
- 它让接手从经验动作变成可执行、可回退、可追溯的制度化流程
来源依据：内部交接协议材料，公网版本不展开原文