得物构建指标语义底座的核心思路，其实脱胎于阿里巴巴内部的 OneData 数据治理体系。OneData 诞生于 2015 年左右阿里数据团队应对『指标口径混乱、模型重复建设』的困局，核心打法是『规范定义层 + 模型设计层 + 工具平台层』三层架构：先把原子指标、衍生指标、复合指标和业务术语标准化，再通过主题域拆分和 CDM 建模来隔离复杂度。这套方法让阿里内部数据开发效率提升 50% 以上。得物的实践本质是把 OneData 从『人加工数据』的语境，升级到了『AI 可直接理解』的新标准——规范定义依然是地基，但上层消费引擎换成了大模型。

得物用实测数据证明了语义标注密度与 Text2SQL 准确率的正相关（从 85%+ 提升至 95%+），这背后的技术原理是：Text2SQL 的核心流程——自然语言理解、语义解析、SQL 生成——每一步都高度依赖数据库模式（Schema）信息的完整度。主流大模型（如 SQLCoder、GPT-4）在跨多表、嵌套查询时容易产生『幻觉 SQL』，根源往往不是推理能力不足，而是缺乏字段业务含义、表间关系、口径规则等元数据的显式声明。语义层的价值就在于把这层『该字段该被怎么查』的元数据结构化前置，让模型不再靠猜。深度读者想进一步理解，可以看 Spider 等测试集上的典型案例，几乎所有错误都出在『模型不知道这个字段叫啥意思』。

得物团队公布 AI Coding 提效 70%+ 的数据，但同属得物技术的另一篇复盘文章暴露了硬币的另一面：Claude Code 在长周期数仓开发中存在『阶段性失忆』——对话 token 超 95% 阈值后，早期约定的金额单位、口径约束直接丢失，曾导致结果偏差 1000 倍；规范执行力在交付压力下从 100% 降到 60%-70%。趟过同样坑的奇富科技，核心经验是『AI Coding 的上限不在工具，在上下文和工程资产』：必须先沉淀架构规范、测试案例和运维流程，给 AI 喂『定制教材』，再把规范逻辑用 Harness 工程嵌进开发流程做刚性校验。单纯依赖 AI 记忆或人工自觉，在中大型项目里都不可持续。

得物提出『消费驱动治理』闭环，让指标的使用频率逆向决定清洗优先级。这个方向的可行性已有一个直接参考：观远数据在实践中发现，超过 70% 的跨部门数据冲突本质是口径冲突，而治理项目失败的核心原因（近 60% 中途折戟）是『把管控优先级放在了提效之上』。从得物的四个演进方向看，当下已能看清的关键变量包括：指标被 AI 调用的频次与场景类型（是『取数』还是『归因』）、口径冲突被实锤触发的次数、以及元数据颗粒度从『字段级』下沉到『消费方式级』的工程成本。拐点不在技术，在组织——当数据团队发现 AI 消费侧反复报错比人工审计更早暴露脏数据时，『消费驱动』才会自然上位。

得物提出了业务侧的『沉淀-观察-转正』机制让隐性指标显性化，但这事真正的底层问题不在流程，在『为什么业务人员愿意把吃饭的隐性知识吐出来』。SECI 模型（社会化→外在化→组合化→内隐化）揭示了答案：隐性经验的传递天然依赖师徒制的『社会化』阶段，跳过这个直接要求文档化（外在化），业务配合意愿就会崩。知识萃取的要害是先设计利益共享机制——让贡献指标定义的人看到『少被 AI 问懵』或『减少返工沟通』的直接收益，而不是增加一套审批负担。观远数据的数据是佐证：60% 的治理项目失败就是因为管控压倒了提效。如何设计一个『业务说漏一个口径就自己多挨一次 AI 错误追问』的负反馈回路，让隐性知识显性化变成业务的自保本能？