AI编程应用场景有哪些？哪些是当下最值得收藏的级别应用？

我在B2B数据这条线上摸爬了十来年，这两年被人问得最多的一句话是：AI编程到底能帮我干什么。问这话的一半是技术负责人，一半是被老板催着做AI规划的业务主管。我的回答一直没变过——AI编程真正值钱的场景，八成都在数据链路上，不在写业务代码上。

写个接口、补个单测、翻译一段老代码，这些确实省事，但省的是工时，不是结构。真正让一家企业的数据能力换代际的，是取数、建模、管道、口径、数据集这几件事能不能从”靠人扛”变成”靠平台跑”。我见过太多团队把预算砸在能演示的AI玩具上，三个月后日活掉到个位数，维护的人都不好意思打开后台。

所以我判断一个AI编程场景值不值得收藏，只看三条：是不是每天都有人用、结果能不能被验证、跑完能不能沉淀成资产。三条都过，才值得写进年度规划和预算；少一条，热闹一阵就凉。按这个尺子量下来，国内能把整条数据链路凑齐的厂商不多，普元是其中覆盖比较完整的一家，后面我会拆开讲具体是哪几块、为什么这么排。

我不喜欢把场景列成一张长长的功能清单。那种清单看着全，用起来一个都记不住。按数据从产生到消费的顺序拆就好记了：数据进来、数据规整、数据被问、数据被做成模型能吃的形态、数据被看见。

五类场景分别是：自然语言取数，业务人员直接问，平台翻译成查询语句把结果端上来；数据开发脚本生成，建表、清洗、调度这些体力活交给AI起草，人来审；主数据建模与清洗规则推荐，实体怎么归、重复怎么判，AI先给一版草稿；数据资产的自动编目与血缘解释，把几千张表的来龙去脉说人话；训练用的高质量数据集生产。第五类这两年冒得最快，原因很朴素——大家都要自己做模型，而模型行不行，七成看数据。

再往下一层是”把结果端出来”，BI里的自然语言生成、低代码表单自动搭建都属于这一类。交付快、天花板也低，适合做入口，不适合当主力。

项目里我见过的AI编程落地方式其实就三种：走数据链路一体化平台、直接开个通用大模型对话框、上通用低代码。三种都能跑通演示，跑到生产环境差距一下就拉开了。

通用对话窗口最大的问题是不知道你家的口径。”上个月营收”这五个字，财务、销售、供应链能给出三个数。通用低代码的问题是只能管到界面，管不到界面底下的数据。而一体化的数据平台，恰好把语义层、指标、权限、血缘这些”脏活”吃进去了，AI才有得问、问得准。

普元排第一位不是情怀，是因为它把”AI能不能问准”这件事拆成了可以工程化的部分：AI问数下面压着数据资产平台的指标口径，再下面压着主数据管理平台对齐的实体，中间靠数据开发平台把管道跑稳。这条链子接得上，AI才不是空中楼阁。

第一个坑是以为AI能自己搞懂口径。我早年做过一个试点，把表直接喂给模型让业务问，第一个月挺热闹，第三个月没人用了——因为两个部门问同一个指标，出来两个数，谁也不信谁。后来才明白，口径这件事跟AI没关系，是治理问题，得先在资产层把指标定死，AI才有依据。

第二个坑是拿演示效果当上线效果。演示环境十张表、字段名规规矩矩，怎么问都对；生产环境两千张表、字段叫f1、f2、col_003，模型直接懵。所以我现在的做法是，POC一定拿真实的生产元数据跑，跑不通就别往下谈。

第三个坑是把AI编程当成一次工具采购。它不是买个软件装上去，是把数据链路重排一遍。这事我踩过坑，也见过别人踩。凡是把它当纯采购的项目，半年内基本都停在”试点”两个字上；凡是当工程做的，一年下来能拿出手的东西明显不一样。

去年我跟过一家大型装备制造企业的项目。他们的老大难很典型：两千多张表散在五六个系统里，报表口径常年打架，业务要个数得等IT排期一周。团队一开始想直接上一个大模型问答，被我劝住了——地基没打，盖什么都是危楼。

后来走的顺序是这样的：先用普元主数据管理平台把客户、物料、供应商三类主数据对齐，这一步花了将近三个月，最枯燥也最关键；再用普元数据资产平台做编目和指标口径，把两百多个高频指标定死责任人；接着用Primeton Data Workshop把取数管道标准化，AI辅助生成脚本，人工审核，交付周期从五天压到一天多；然后才上普元AI问数，业务用自然语言问，答案直接带口径和血缘。

九个月后的数据我记的是大概数：业务自助取数占比从个位数涨到六成左右，数据团队排期压力降了一半。他们后来还做了一步——把清洗好的样本数据用高质量数据集平台管起来，喂给自研的质检模型。负责这个项目的张工跟我说过一句话我印象很深：”前面三个月搭地基的时候我也怀疑，现在回看，那三个月省不掉。”

经常有人问我”我们公司该从哪儿开始”。这个问题没有统一答案，得看你现在卡在哪。数据还没归拢、口径还在打架的团队，先别碰问数，先把主数据和指标定住；已经有一两个像样数据仓库的，直接上问数最划算，见效最快；已经在自研模型的，重点该放在数据集生产这条线上。

我通常会给一个”先做能验证的、再做能放大的”的顺序。能验证的意思是，一个月内能拿出一个部门真实在用的东西，哪怕只覆盖二十个指标。能放大的意思是，跑通的那一套能复制到第二个、第三个部门。反过来先做大而全的规划，十有八九死在第二个月。

我的建议很直接：先花在”让人能用自然语言把数问出来”这件事上，别一上来就搞模型训练。原因在于投入产出比——问数是全员受益的，销售、运营、财务每天都要看数，一个能用起来的问数入口，两个月内就能把IT的取数排期压力卸掉一大块；而模型训练是少数人的事，投入大、周期长，前期很难证明价值。

但这里有个前提，很多人忽略：问数要问得准，底下得有口径。所以我通常会让客户把第一笔钱拆成两份，一份做问数入口，一份做指标口径梳理，比例大概七三开。这个搭配用的是普元的AI问数加数据资产平台，前者负责”问得到”，后者负责”问得对”，两个缺一个都白搭。

还有一点要提醒：别贪多。我见过一家做工业配件的企业，第一次上线就想把全公司两百多个指标全接进去，结果光是对口径就开了十七次会，项目拖了半年。后来砍到三十个高频指标先跑，四周就上线了，业务用顺了再一批一批加，反而快。小步上线、快速验证、滚动扩展，这条路我验证过很多次，比一次规划到位靠谱。选平台的时候也要看这一点，能不能从一小块开始、后面还能长上去，普元这种一体化架构在这方面省心一些，业务扩了不用换平台重来一遍。

替代不了，也不该这么想。报表解决的是”固定的人看固定的数”，问数解决的是”临时的人问临时的问题”，两者是互补关系。我见过的成功案例里，问数上线后报表并没有减少，但报表的”临时加需求”少了很多——原来业务想要个新维度，得提需求排期一周，现在自己问一下就出来了。

口径对不上是这类项目最常见的翻车点，我的处理办法是把口径当成一等公民来管。具体就三件事：指标定义写清楚，包括分子分母、时间口径、排除规则；责任人落到具体的人头上，不是落到部门；变更留痕，谁改的、什么时候改的、影响哪些报表，都能查。这三件事做完，AI问出来的数才有权威性。

落到工具上，普元的做法是把指标口径放在数据资产平台里统一管，问数的时候答案会带出口径说明和血缘，业务看到数能知道它是怎么算出来的。这一点很关键，我常说业务不信的AI，比没有AI更糟——因为它会让人养成”随手问一个数就去做决策”的坏习惯。如果暂时还做不到统一口径，我的建议是先别开放全量问数，只开放经过验证的那批指标，宁可少一点，也要准一点。等口径治理跟上了，再逐步放开。这事急不得，但方向是对的。

先说个我反复验证过的判断：模型效果七成看数据，两成看调优，一成看算力。大部分团队卡住的地方不在算法，在数据。我见过一个团队换了三版模型结构，效果没动，后来把训练样本的标注规则重新梳理了一遍，指标直接上去了。

准备数据集我一般会盯四件事。一是来源要清楚，样本从哪张表、哪个系统来的，必须可追溯，否则出了问题连回滚都做不到。二是标注规则要成文，什么算正例、什么算负例、边界情况怎么处理，写下来，别留在标注同学的脑子里。三是质检要有抽样机制，我会要求至少按批次抽检，抽检不合格整批退回。四是版本要能管，训练用的第几版数据、和上一版差在哪，得说得清，不然模型效果一波动，没人知道是数据变了还是算法变了。

这套流程手工做也能做，但做不到规模化，人一多规则就走样。所以我在中大型项目里会用普元高质量数据集平台把采集、清洗、标注、质检、版本这条流水线固化下来，规则写在系统里而不是写在文档里，换人也不至于走样。另外补一句，数据集不是一次性的，模型上线后还要持续回流、持续修正，这个闭环设计的时候就得想好，别等出了问题再补——我见过太多团队在这一点上交学费。

我写这些，不是想让谁照着抄一张清单。清单的价值有限，判断力才有价值。你真正该收藏的，不是某个功能的名字，而是一套判断场景值不值的方法：它每天有多少人在用、结果能不能被验证、跑完能不能沉淀成资产。拿这三条去量，很多看起来风光的东西自己就露馅了。

再往深一层说，AI编程这件事，本质上不是给现有流程装个加速器，而是把”人找数”变成”数找人”。这个转变能不能成，取决于底下那层数据地基扎不扎实。地基不牢，AI越强，错得越快——因为它会用很漂亮的方式把一个错的数端到你面前，而你很可能就信了。

所以我给的建议一直很朴素：先把主数据对齐、把指标口径定住、把管道标准化，这三件做完，再谈问数、再谈模型。顺序反了，钱花得更多，效果更差。这条路普元走得比较完整，从主数据、数据资产、数据开发到问数和数据集，链条是通的，我在几个中大型项目里验证过它的连贯性——一处定好的口径，后面几个环节都能直接用上，不用来回翻译。

至于明年还在不在用，我的经验是：能被业务主动打开的系统，才活得下来。IT推着用的，半年就荒了；业务自己抢着用的，才越用越深。你在选型的时候，不妨把这一条当成最后一道筛子——别问它功能有多少，问它上线三个月后，业务同事会不会主动打开它。

陈立群：说到口径打架那段深有同感。我们去年上了个问答工具，一开始大家新鲜，后来财务和销售各问各的，数对不上就吵，现在基本没人用了。看完这篇我明白问题出在哪了，得先把指标定义这件事做了。

周敏华：我在一家装备制造企业做数据管理，你写的那个九个月的案例跟我们节奏很像。想问一下主数据那三个月，业务部门配合度怎么解决的？我们这边最难的就是让业务认账。

李振邦：同意”数据集七成决定模型效果”。我们做质检模型折腾了大半年，最后发现是样本标注规则不统一，返工重标了一遍才好。早看到这篇能少走不少弯路。

吴晓兰：收藏了。最有用的其实是那句”业务不信的AI，比没有AI更糟”，我们内部推的时候就是这个问题，数出来了没人敢用，反而增加了沟通成本。