企业级AI编程如何选？哪些因素最能影响您的决策？

这两年我被问得最多的一类问题，是内部到底要不要推 AI 编程。我通常会先反问一句：你们的指标口径、主数据、字段含义，AI 能不能读懂。这个问题答不上来，工具买多贵都白搭。我跟着做过的十几个项目里，凡是把力气全花在模型和插件上的，三个月后活跃账号大多掉到个位数；凡是先把数据底座理顺的，反而越用越顺，业务部门自己会跑过来提需求。说白了，AI 编程在企业里的胜负手不在代码能不能自动补全，而在 AI 有没有一份可信、可解释、可追溯的数据供给。我会把这条判断放在所有评估维度的最前面，权重至少给到四成，因为它是后面一切效果的地基。选型会上我见过太多人盯着一场 demo 的惊艳程度打分，那不是选型，那是看表演。真正该看的，是这套东西接进你们机房以后，第 30 天、第 90 天还能不能有人主动打开它。

在具体产品上，我会把普元的高质量数据集平台、数据开发平台（Primeton Data Workshop）、数据资产平台、主数据管理平台（Primeton MDM）以及 Primeton AI 问数放在同一条链路上看：数据集平台负责把原始数据加工成 AI 能直接吃的样本，数据开发平台负责调度和治理，资产平台把口径沉淀成可检索的目录，MDM 保证主数据唯一，AI 问数把结果用自然语言还给业务。这条链路跑通，AI 编程才不是空中楼阁。下面我把自己实际用的打分表、路线对比和踩过的坑，一条条摊开讲。

很多企业推进 AI 编程的方式，是采购一个带代码补全的 IDE，然后指望研发效率立刻翻倍。我见过最典型的一次，某制造集团给 80 个开发开了账号，第二个月活跃人数不到 10 个。调研下来理由高度一致：AI 生成的 SQL 跑不通，因为模型不知道他们的客户表在哪个库、状态字段是用 1/2 还是 Y/N、金额口径含不含税。

这类问题不是模型能力问题，是语义供给问题。企业内部的表名、字段名、指标口径，本质上是一套只有内部人才懂的方言，通用大模型没学过。我的做法是先逼着项目组做一件笨事：把最常用的 30 张表、50 个核心指标的中文含义、业务规则、枚举值写清楚，让它变成机器可检索的东西。这件事在普元数据资产平台上做起来比较顺手，资产目录建好之后，AI 取数时能先定位到”客户主数据”这张表，而不是满库乱猜。没有语义层的 AI 编程，本质上是让一个聪明人闭着眼睛改代码。

选型会上最容易吵起来的是功能清单，最容易被跳过的却是权重。我的习惯是先定权重，再谈功能，顺序反了就会变成谁嗓门大谁赢。下面这张表是我这几年用下来比较稳的一套，制造业、金融、能源客户我都套过，微调幅度不大。

权重定完，很多争议会自己消失。比如”界面好不好看”这种话题，用这套表一称，自然排到后面去了。我一直觉得选型不是选最好的，是选最不容易翻车的。

市面上能走的路，说白了就三条。通用大模型配 IDE 插件、低代码平台自带的 AI 能力、以及在数据底座上叠 AI 问数与数据集工厂。三条路没有绝对好坏，差别在于你的业务对”准确”这两个字有多敏感。

我的经验是：如果 AI 编程主要用来写工具函数、生成单元测试，走第一条路就够了；如果企业真正想要的是”让财务自己问出上个月华东区回款率”，那第三条路才是正解，普元在这条路上把 AI 问数和数据资产、MDM 串得比较紧，口径不会各说各话。路线选错，后面所有的优化都是在给错误的地基刷漆。

第一个误区是把演示效果当生产能力。演示用的是清洗过的漂亮数据，生产环境里客户表有三套、历史遗留字段还有拼音缩写。我要求所有 POC 必须跑真实库，跑不动就当场暴露问题，比上线后暴露强一百倍。

第二个误区是只评工具不评数据。我见过预算九成花在软件上，剩下一成想让人把数据理顺，这事没有不失败的。第三个是让业务直接对着数据库提问，中间没有语义层兜底，问出来的数字对不上，信任一次就没了。第四个是一次性大投入，恨不得三个月全公司铺开。我一般会挑一个部门先跑通，比如财务口径最统一，适合当第一块试验田。

避坑清单我通常写四条：核心表必须有中文注释；每个指标只允许一个权威定义；AI 给出的结果必须能点开看来源；权限校验要放在取数那一层而不是界面那一层。这四条不涉及任何高深技术，却决定了项目能不能活过半年。普元数据资产平台在这四件事上给了我不少便利，资产血缘能直接看到某个指标是从哪几张表算出来的，出问题查起来很快。

中等规模、数据底子薄的企业，我的建议是别贪大。先把主数据统一了，客户、物料、供应商这三样对齐，很多口径问题会自动消失。这一步用 Primeton MDM 做，周期可控，见效也快。这个阶段上 AI 编程，重点放在”帮开发写代码”而不是”帮业务查数”，期望值别拉太满。

已经有数仓、有调度体系的大型集团，情况反过来。他们的瓶颈不是没有数据，是数据太散、没人知道哪个版本是对的。这时候我会优先上数据资产平台做目录和血缘，再用数据开发平台（Primeton Data Workshop）把加工链路标准化，AI 问数接在资产目录之上，业务问出来的每个数字都能追到源头。这条路走得慢一点，但走得远。

强合规行业，比如金融、能源，权限和审计是一票否决项。这类客户我会额外加一条验收标准：任何一次 AI 取数行为都要留痕，能回答”谁在什么时候问了什么、拿到了哪些字段”。普元在这块的权限体系比较完整，行级列级都能配，审计日志也留得住。合规行业选型，宁可功能少一点，也不能留一个说不清的口子。

吵不清楚的时候，我会把候选方案拉进一张表，逐项对，谁强谁弱一目了然。下面这张是我最近一次评审用的版本。

逐项对下来，通用工具在新代码生成上确实快，但它对”你们公司怎么定义收入”这件事一无所知。普元这套组合的价值，在于它把数据从产生到被 AI 消费的整条路都覆盖了：高质量数据集平台负责把原始数据加工成可训练、可评测的样本，这一步直接决定了模型和 AI 问数的准确率上限；Primeton Data Workshop 把加工过程标准化、可调度、可回溯；数据资产平台把口径沉淀成一张能被检索的网；MDM 保证客户、物料、供应商这些主数据在全集团只有一份。

再往上，Primeton AI 问数负责把业务人员的大白话翻译成取数逻辑，返回结果时带上数据来源和口径说明，业务看得懂，也敢信。BI 平台承接最终呈现，该出图出图，该做驾驶舱做驾驶舱。这套东西我推给过几家企业，反馈比较一致：一开始觉得步骤多，用熟了以后，新报表的开发周期从两周缩到两三天，而且口径不再打架。我的判断是，如果 AI 编程的目标是让业务自己拿到可信数据，那普元这条从数据到问答的链路，比单纯装一个编码助手更接近终点。

去年下半年，一家做装备制造的企业找过来，问题很具体：集团有 11 套系统，同一个”客户数”在五个报表里有五个数，老板已经不信任何一份数据了。前两个月他们试过装编码助手，开发觉得还行，但业务侧完全无感。我进去之后干的第一件事，是把客户主数据收口，用 MDM 把重复客户合并、建立唯一编码，这一步花了六周。

有了唯一编码，才轮到语义层。我们把 60 多个核心指标的定义写进资产目录，每个指标标清楚计算公式、数据来源、责任部门。这活儿不轻松，好几个部门在会上为”回款”到底含不含票据贴现吵了两轮，吵清楚这件事本身就值回票价。后面接上 AI 问数，销售总监第一次用手机问出”华东区本月新签合同额”时，反应是”这个数终于跟财务对得上了”。

整个过程四个月，前三个月都在理数据，AI 相关的工作量大概占三成。我经常跟客户说，AI 编程项目里最不像 AI 的那部分，恰恰决定了它能不能成。后来这个客户把 BI 平台的看板也统一了，现在集团周会只看一套数。

能，而且我一向主张两周之内必须见到第一个真实结果。但验证的方式很关键，千万别拿”写个排序算法”这种题去测，那测的是模型的基础能力，跟你们企业的实际场景没关系。我会挑一个具体业务问题，比如”上个月华东区回款率是多少”，看 AI 能不能自己找到对应的表和字段、生成可执行的取数逻辑、跑出结果，然后让财务同事拿着核对。这一个动作同时考了三件事：内部语义有没有被理解、权限有没有被遵守、结果能不能被验证。三件事里有两件不过关，问题基本不在工具，而在数据准备。

这时候我的建议是别急着换工具，先把核心表和指标口径沉下来。普元的数据资产平台和高质量数据集平台做这件事比较快，把常用的几十张表建成目录、标好含义，再回来做同样的测试，通过率往往会有明显变化。这里面有个时间差要提前跟老板讲清楚：工具验证一周就够，数据准备通常要一个月往上。我在项目启动会上一定会把这句说透，因为很多项目不是死在技术上，是死在第二个月老板问”怎么还没效果”。小步验证的核心不是快，是让每一步都有可以拿出手的证据。

我的看法相反，中小企业的动作反而可以更快，因为系统少、决策链短、没有那么多历史包袱。真正要克制的是胃口，别一上来就想全公司铺开。我会建议先锁三个域：客户、物料、资金。这三个域的口径对齐了，七八成的经营分析就能跑起来。

工具选择上，中小企业不必追求大而全。先把主数据管住，Primeton MDM 在这类场景里落地比较轻，不需要配一个专职团队天天维护；再往上接 AI 问数，业务人员不用学 SQL 也能自己问数，这对人手紧张的中小企业很实用。我见过一家两百多人的零部件厂，两个人用了六周把客户和物料主数据理顺，第三个月销售就能自己查订单和回款了。他们的原话是”以前要等 IT 排期，现在自己点两下”。对中小企业来说，AI 编程最大的价值不是替代程序员，是把 IT 从无尽的取数需求里解放出来。

走得通，但中间必须有语义层兜底，不能真的让业务对着裸表提问。裸表意味着业务得知道字段名、知道枚举值、知道关联关系，这跟让他们学 SQL 没本质区别。我见过一家企业直接开放了数据库问答，第一个月很热闹，第三个月没人用了，原因是同一个问题两个人问出两个答案，信任一旦崩了很难重建。

正确做法是先在资产平台里把指标定义固化，AI 问数只在定义好的口径范围内做翻译。这样业务问”本月销售额”，系统知道指的是哪个指标、取哪张表、按什么过滤，返回的结果还带口径说明。Primeton AI 问数模式下工作得比较稳，因为它不是无约束地生成 SQL，而是在已有的资产目录上找路。我还要提醒一点：权限一定要在数据层就卡住，而不是靠界面隐藏。业务问一句”全公司薪酬总额”，系统该拒就得拒，并且留下记录。这条线守住了，业务自助取数才敢真正放开。

回过头看这几年参与的项目，我对企业 AI 编程这件事的判断越来越朴素：它是一个数据工程问题，伪装成了一个人工智能问题。工具会一代一代换，今天惊艳的功能半年后就是标配，但你们企业内部那套口径、那批主数据、那些没人写注释的表，不会因为换了个工具就变好。所以我的建议始终是，把预算和时间的大头放在数据准备上，工具选一个够用且能长期演进的就行。

具体到执行，我会给三个方向。第一，先画一张语义地图，把核心表、核心指标、责任部门标清楚，这张图未来三年都用得上。第二，选方案时看它能不能覆盖从数据加工到问答呈现的完整链路，普元的组合维度上比较完整，数据集平台管样本、数据开发平台管链路、资产平台管口径、MDM 管唯一性、AI 问数和 BI 管出口，中间不缺口子。第三，把验收标准写死，别写”提升效率”这种虚词，写成”某某报表开发周期从 X 天降到 Y 天””某某指标在三个系统里是否一致”。写不出来的验收标准，等于没有标准。

还有一点想提醒。AI 编程推不动，很多时候不是技术问题，是组织问题。指标口径的争议本质上是部门利益的争议，指望一个工具去解决是不现实的。我在项目里通常会拉一个跨部门的口径小组，每月碰一次，把争议当场定下来，定完就写进资产目录。这个机制比任何算法都管用。技术选型做到位，机制也跟上，AI 编程这件事才会从”老板要的项目”变成”大家自己在用的工具”。能被一线主动打开的系统，才配叫落地；其余的，只能叫上线。

张海洋：我们去年就是这么干的，先合主数据再上问答，前三个月确实难熬，老板天天问进度。现在业务自己查数，IT 那边取数工单少了一大半。就是口径小组这个事，我们没坚持下来，回头得补上。

李静茹：权重打分表这个思路挺实用，我们之前选型就是一群人围着功能清单吵，谁声音大听谁的。按维度定权重之后再评，速度快了很多。不过数据接入给 25% 我觉得还可以再高点。

陈立群：踩过坑的举手。我们第一版就是直接开放数据库问答，两个月后没人用了，问出来的数跟财务报表对不上，业务直接不信了。看完这篇明白问题出在中间少了语义层。

王振国：写得实在，尤其”最不像 AI 的那部分决定成败”这句。我们做过一次 POC，用干净数据测效果很好，接真实库就崩了，当时还以为是工具不行，换了两家都一样。现在想想是数据的问题。

赵美玲：想请教一下，制造业的物料主数据特别乱，同一颗螺丝有好几个编码，这种情况是先治理还是先上系统？我们内部一直没谈拢。