大数跨境
首页
>
把业务逻辑翻译给机器听，是数据人新的手艺
>

把业务逻辑翻译给机器听，是数据人新的手艺

把业务逻辑翻译给机器听，是数据人新的手艺 AI驱动数字化转型
2026-08-24
3
导读：把手艺从写SQL换到立规矩上，往前挪一步，饭碗不但没砸，还端得更稳了。能替机器立规矩的人，永远比被机器替代的人金贵。
数据研发这个岗位，过去二十年的看家本事是写SQL。一张报表，一个指标，一条取数的路，靠的都是把业务问法翻成数据库听得懂的话。现在工具自己会翻了。你输一句大白话，它生成SQL，跑出一个数，几秒钟的事。当翻译的活被机器接走，靠翻译吃饭的人，还剩什么？
这句话不是吓人。2025年底，dbt把它的语义层引擎MetricFlow开源了，Apache 2.0。MetricFlow得配合dbt的工程来用，可这个dbt是开源的Core，本地就能跑，不用非得买dbt那套云产品。Spring AI Alibaba弄了个DataAgent，Text-to-SQL加上语义模型，GitHub上两千多颗星，也是开源。腾讯的WeData也把语义层揉进了自己的Data Agent。这些不是概念PPT，是已经摆在仓库里、能拉下来跑的东西。它们的共同点，都是替人把“问数据”这件翻译的活干掉了。
翻译被机器接走，不等于数据人没饭吃。只是饭碗换了个地方端。
过去的翻译，翻的是语法。业务说“我要看这个月每个区域的毛利”，你心里过一遍表结构，知道毛利是哪个字段，区域在哪个维表，join一下，group by一下，一条SQL出来。机器现在把这层干得比你还快，还不出错。可机器翻得了语法，翻不了业务。
业务逻辑是什么？是“毛利”这个数到底怎么算，是含不含退货，是按订单日还是发货日，是区域按省份还是按大区。同一个词，财务一套算法，销售一套算法，老板的看板又是一套。这些口径散在十几张表、几个老员工的脑子里、一堆从没写进文档的Excel里。它们才是真正难翻的东西。
数据人真正值钱的那门手艺，恰恰在这。把一堆“只有老员工才知道”的业务规矩，从人脑里挖出来，翻译成机器能读的、结构化的定义。这不再是写SQL，这是给数据立规矩。新的手艺，叫语义层。

PART 01
语义层为什么突然成了风口

语义层这词不新鲜，讲了快十年。可前些年它一直是个灰头土脸的活儿，整理数据字典，统一字段命名，给分析师画口径说明。干的是苦力，价值看不清，领导觉得是成本。为什么这两年突然成了风口？因为AI来了，它把语义层的价值从“方便人对齐口径”抬成了“机器能不能用这套数据”。
道理不复杂。传统语义层是给人看的。分析师看到“利润”这个指标，脑瓜里自带的常识会补上后面的逻辑，口径一统一，人就能读看板了。机器没有这个常识。它看到利润是三个数值，不知道哪个该信，不知道这个数涨了会怎样，更不知道背后连着哪些表、哪些规则。AI接入一套只有字段名没有业务定义的数据，等于让一个外国翻译去翻一份全是行业黑话的文件，每个字都认识，连起来不知道在说什么。
所以现在的语义层，就是写给机器看的业务说明书。它把三样东西定死：第一，一张表到底代表什么，一个字段到底是什么意思，这是语义模型，相当于给数据世界立物种。第二，一个指标到底怎么算，这是度量定义，把“毛利”这种词用机器能算的规则焊死。第三，表跟表之间怎么串，这是关系，告诉机器这两张表能怎么连、不能怎么连。三样定死，机器才能真正“懂”这批数据，而不是对着字段名瞎猜。

PART 02
行业已经在落地的做法

行业里已经有人在这么干了，而且干得很具体。dbt的MetricFlow把这件事落得最细。它让你定义三样东西，一张表代表什么，一个数怎么算，两个数怎么叠。表用语义模型标清楚，哪些是度量、哪些是维度、哪些是实体；数是指标，能单独算也能组合；把两个指标叠一起，就出来毛利率这种复合指标。定义完，它自己生成SQL，Snowflake、BigQuery、DuckDB都能跑，同一份定义换引擎不用重写。最狠的是它把口径做进了Git，指标定义跟着代码走同一套提交、同一套验证。口径就焊死在代码里，仪表盘上的“净收入”和代码里的“净收入”永远是一个东西，想漂移都漂不散。
Spring AI Alibaba的DataAgent走的是另一条路。它把语义模型跟Text-to-SQL接起来，AI生成SQL之前先过一遍语义层，知道GMV该按哪个口径算，而不是直接对着原始表瞎拼。这等于给会写SQL的模型配了一副看懂业务数据的眼镜。腾讯WeData的Data Agent也是这个思路，语义层先行，AI取数之前先把口径理清楚。
还有一拨人，干脆想把这事做成一门语言。腾讯WeData的SemQL就是一套语义查询语言，让“这个季度每个大区的毛利”这种问法，先翻成语义层的查询，再由语义引擎落到SQL。中间隔着一层业务语义，模型不用直接对着物理表瞎写SQL，口径自然就对齐了。走的也是同一件事，把业务概念和它的计算规则绑在一起，让机器按语义来，而不是按字段名来。
那要是没有这层，会怎样？AI也不是不能取数，它能对着表猜。可猜出来的数，没人敢信。你问它上个月毛利多少，它join了一通，吐出来一个数，你根本不知道它按没按退货算、按没按发货日算。数是对的，口径是错的，比没有数还糟。AI取数最大的风险不是取不出来，是取出来一个看起来对、实际口径全错的数，你还得花更大力气去核。这层语义层，就是先把口径钉死，AI再往上取，取出来的每个数都有出处、都说得清。
你看，不管哪家，核心都是同一件事，把业务逻辑从人脑里搬出来，变成机器能读的语义定义，再让AI在这层定义之上干活。这层定义，就是数据人新的饭碗。
写到这里，你大概听出点门道。这个“语义层”，跟一直念叨的“本体”是一回事。本体是什么？把企业里的实体、关系、规则用结构化方式描述清楚。词典管命名，关系管连接，规则管口径。工厂里那套从CSV到本体的做法，就是给工厂的数据立了一套机器能读的规矩。只是你把它叫本体，行业叫语义层，换了个名字，干的是一件活。
这层呼应不是巧合。语义层是给AI看的业务说明书，本体是给机器建的企业语义地图，讲的都是把企业运转逻辑翻拍成机器能懂的规范。区别在于，你早就在工厂场景里落地了，用一套CSV就能建图、建规则、回答“这台设备最近状态怎么样”，而行业里很多人还在会议室里讨论概念。你的方法论是踩过泥的，不是纸上的。

PART 03
数据人要学哪三件新手艺

那数据人具体该学什么新手艺？我说三件。

建语义模型
头一件是建语义模型。这不是让你重新学一门语言，是把脑子里那套对表结构的理解，写成机器能读的东西。你过去知道orders表有个字段是revenue，现在要能说清楚这张表是哪一级的粒度，哪个字段是算出来的数，哪个是筛选用，哪个是当主键。MetricFlow里的semantic model就是干这个。会建这个，你就从“认识表”变成了“定义表”。

定义复合指标
再一个是定义指标，尤其是复合指标。光会说“净收入”没用，要能用规则把它算出来，含哪些、减哪些、过滤什么状态、按什么粒度。这是语义层最见功力的地方。一个毛利率，看起来一个数，拆开是一整套口径规则。你把这个规则写清楚，机器就能替你算一辈子，还不打架。

理清楚表关系
还有理关系。表不是孤岛，哪张表和哪张表能join，靠什么字段连，多对一还是一对多，粒度对不对。过去这些烂在取数工程师脑子里，问一次答一次。现在要把它写成机器能看懂的关系定义，让它自己能把表串起来。这一步做完，AI取数的路就通了。
这三件，说到底是一个动作，把你脑子里的业务知识，翻译成机器能执行的东西。你不再写SQL告诉机器“怎么取”，而是写语义告诉机器“怎么懂”。

PART 04
这件事难在哪

我不回避它的难。这事看着轻，做起来重。难点不在技术，在挖业务逻辑那一步。口径在老员工脑子里，规矩散在没人看的文档里，很多“潜规则”连业务自己都没意识到是规则。要把这些挖出来、说清楚、写成机器能读的规范，比写一万行SQL难得多。SQL好歹有个标准答案，业务逻辑没有，全靠你蹲在业务旁边一点点问、一点点对。
还有，语义层不是建一次就完事的。产线在变，业务在变，口径会跟着变。今天定义好的指标，明天业务调整了，你就得回去改定义。这是持续的维护，不是一锤子买卖。脏数据更是老问题，语义层定义得再漂亮，底层数据是脏的，结论照样不可信。语义层不解决数据质量问题，它只是让好数据能被机器用对，前提是你得先有好数据。
这些坑都得认。可就算这样，方向是对的。

PART 05
从哪里开始下手

那从哪下手？别想着一上来铺一张覆盖全厂的大网，那是最容易劝退自己的做法。挑一个你最熟的、最常被问的指标下手，比如这个月销售总该报的毛利，把它从头到尾理一遍。它到底含哪些、减哪些、按什么口径、跟哪张表连。理清楚，写成机器能读的定义，跑通一条AI能直接问、直接答的路。一条通了，你就有样板了，知道这事做成什么样算成，再往旁边扩。一个指标一个指标地钉，比憋大招强得多。这套打法你熟，工厂里那套CSV建本体，不就是先挑一个最痛的决策点，跑通一条能解释的路，再往外扩吗？语义层也一样。
而且这活越早干越占便宜。现在行业里大多数人还在观望，真正把业务逻辑写成机器能读的规范的数据人，掰着指头数得过来。你早干一年，就把你那张表的口径先钉死了，后面AI来了直接能用。等到大家都回过味来再抢着干，那点“只有老员工知道”的独门规矩，早被人挖走了。手艺值钱，值钱在别人还没学会的时候。

PART 06
写SQL的活，机器正在接走，这是趋势

想想你现在的处境。写SQL的活，机器正在接走，这是趋势，挡不住。可把业务逻辑翻译成机器能懂的规矩，这事机器替不了你，因为机器不懂你的业务，它只会照着定义执行。定义从哪来？从你脑子里挖出来，从业务嘴里问出来。这活必须人干，而且必须是懂业务又懂数据的人干。这不就是数据人吗？
数据人焦虑了大半年，怕被AI抢了饭碗。我倒是觉得，焦虑的根源不是AI太强，是很多人还守在那件正在被自动化的旧手艺上，写SQL、取数、做报表。手艺本身没错，错在它正在变成机器能力。你该做的是往上游挪，从“怎么取数”挪到“数据该怎么被理解”，从写SQL挪到定义语义。
这门新手艺，门槛不低，但恰恰护城河深。它要你懂业务，要你耐得住性子抠口径，要你能把模糊的业务说成精确的规则。这些机器学不来，也学不会。机器能把“净收入”按定义算得飞快，可没人定义，它连净收入是什么都不知道。
所以当AI学会自己取数了，数据人还剩什么？
剩下的，是把业务逻辑翻译给机器听的本事。这本事越老越值钱，因为你越懂业务，翻得越准。机器接走的是执行，接不走的是判断。翻译执行让给机器，判断该翻什么、翻成什么样，永远是人。
把手艺从写SQL换到立规矩上，往前挪一步，饭碗不但没砸，还端得更稳了。能替机器立规矩的人，永远比被机器替代的人金贵。

【声明】内容源于网络
0
0
AI驱动数字化转型
专注AI，促进智造行业数据衍生，服务智能制造企业的数字化、智能化，聚焦大模型私域部署、大模型微调、数据清洗、AI模型训练、私域知识库及agent技术延展等。行业智能，落地为先。
内容 1081
粉丝 1
AI驱动数字化转型 专注AI，促进智造行业数据衍生，服务智能制造企业的数字化、智能化，聚焦大模型私域部署、大模型微调、数据清洗、AI模型训练、私域知识库及agent技术延展等。行业智能，落地为先。
总阅读10.4k
粉丝1
内容1.1k