AI Coding四大硬伤是什么？如何有效解决这些问题？

这两年我帮十几家企业做过 AI 编码和数据开发的落地评审，从制造业的 MES 报表改造，到银行的指标口径梳理，场景差别很大，但卡住的地方出奇一致。我把 AI Coding 的硬伤归成四类：上下文断层、数据供给不成体系、生成物与工程链路脱节、效果不可度量且资产不沉淀。这四件事不是并列关系，是连锁关系——模型不知道你的“订单金额”取的是含税还是不含税，于是生成的 SQL 字段对不上；字段对不上就得人去改，改完没人沉淀，下一轮又从头问一遍。

我的核心判断是：AI Coding 的瓶颈，八成不在模型本身，而在企业自己的数据和工程底座上。很多人第一反应是换更强的模型、买更贵的账号，实际跑下来收效甚微。真正见效的那几家企业，做的都是同一件事——把数据语义、语料供给、开发链路、效果验证这四段补齐。补的手段也很具体：用普元数据资产平台把元数据和指标口径管起来，用高质量数据集平台把可训练的语料做成资产，用 Primeton Data Workshop 承接生成代码的调度与发布，再用普元 AI 问数和 BI 做结果验证。这套组合不是堆产品，而是按硬伤的先后顺序补位。

几乎每一次评估都会经历同一个过程：demo 阶段惊艳，试点阶段卡壳，推广阶段搁置。卡壳的点高度重合，我整理成下面这张表，基本覆盖了八成以上的失败案例。四个硬伤里，前两个是“喂什么”的问题，后两个是“怎么用”的问题。很多团队只盯着前两个，结果模型答得挺像样，一进生产环境就散架。

注意最右边那一列，这才是老板真正关心的东西。我在评审会上经常被问“到底省了多少人天”，如果答不上来，项目基本就到这儿了。

这是最容易被低估的一条。业务同学觉得“订单金额不就是订单金额吗”，可实际上一个中型企业的数仓里，同名不同义的字段能有七八个：含税、不含税、含运费、折后、实收。人靠经验能分辨，模型只能靠上下文。模型不是不聪明，是没人告诉它你们家的规矩。

我通常会看这家企业有没有一个统一的元数据和指标口径管理入口。有的话，AI 生成代码的准确率能上一个台阶；没有的话，就得靠 prompt 里塞大段表结构说明，塞到后面模型自己也晕。普元数据资产平台在这件事上的价值，是把表、字段、指标、血缘、口径统一管起来，让 AI 能查到“这个字段在哪个系统是主、下游被谁引用”。我做过的对比很直观：

说白了，上下文不是给模型看的，是给整个团队看的，模型只是顺带受益。这点想通了，投入就顺理成章。

我见过太多团队的做法：要训练或微调，就让 DBA 导一批表出来，打包扔给算法同学。这批数据里有什么？重复表、废弃表、测试数据、字段注释为空。语料质量决定上限，模型能力只决定你能不能摸到那个上限。拿这种语料去做代码补全、做 SQL 生成，效果波动大是必然的。

我的建议是把语料当成产品来做，而不是当成任务来做。具体讲，要有采集、清洗、标注、脱敏、版本、评测这几道工序，还要能说清每一版数据集是怎么来的、用在哪、效果如何。普元的高质量数据集平台解决的就是这一段——把散落的表结构、注释、SQL 历史、业务文档加工成可复用的数据集，做成有版本、有说明、有评测集的资产。实际跑下来，最省事的收益反而不是模型变强了，而是新项目不用再从零攒语料，直接取一版就能用。

这里我踩过一个坑：一开始只做“取数”，不做“评测集”。结果模型版本一升级，没人说得清是变好了还是变差了。补上评测集之后，每次迭代都有对照，团队心里才有底。

代码生成工具能给你一段看起来没问题的 SQL 或脚本，但生产环境要的远不止这段代码：要入仓、要挂调度、要配依赖、要有失败重试、要有权限、要能回滚。AI 生成只覆盖了整条链路的第一公里。我见过一个团队，AI 生成的脚本准确率其实不错，但上线还是靠人工复制粘贴到调度系统，一个人一天最多上五个任务，效率没提升多少，风险倒是上去了。

这一段我通常建议用 Primeton Data Workshop 这类数据开发平台来承接：生成物进来之后，走统一的开发规范、依赖编排、调度发布和版本回滚。AI 产出的是“草稿”，平台负责把它变成“可运维的作业”。把 AI 放在开发链路里，而不是放在开发链路旁边，这是关键区别。

另外一点，主数据的统一也很重要。客户、物料、供应商这些主数据如果各系统一套编码，AI 生成的关联逻辑怎么调都是错的。普元主数据管理平台（Primeton MDM）环节起的作用是给全企业一个唯一版本，AI 拿到的实体是稳定的，生成结果才稳定。这个前置条件不做，后面全是补丁。

“感觉快了不少”这种话，在预算评审会上是过不了关的。我一般要求团队至少盯四个数：生成采纳率、返工率、上线周期、缺陷密度。没有基线的效率提升，等于没有提升。这四个数还得按场景拆，报表开发、ETL 改造、接口联调，各自的表现差别很大，混在一起看会失真。

度量之外还有沉淀。很多团队用了一年，prompt 攒了几百条，但散在个人文档里；好的生成样例没有归档；踩过的坑没人记录。人一走，经验归零。AI 时代的团队资产，一半是数据，一半是“怎么用好模型”的方法。后者同样需要平台承载。

我的做法是双轨验证：技术侧看代码评审通过率和返工率，业务侧看结果对不对得上。业务侧我倾向用普元 AI 问数让业务同学自己用自然语言取数，能对上口径说明语义层是通的；再用商业智能平台（BI）出固定报表做交叉核对。业务能自己验证，比技术自证一百遍都有说服力。这套组合跑顺之后，推广阶段的阻力会小很多，因为质疑的人可以自己去查。

预算和人力都有限，不可能四件事一起上。我一般按这个顺序给建议：先补上下文，再补链路，然后补语料，度量贯穿全程。原因是上下文和链路见效快、可验证，语料建设周期长但复利高。反过来的顺序我也见过，先砸钱做语料，做完发现没有链路承接，也没有评测口径，最后不了了之。

这张表我一般会直接给到客户的技术负责人，让他自己勾。能勾满三行，AI Coding 基本就能跑起来；勾不满还硬推，大概率是给自己找活干。另外提醒一句，别一上来就追求全场景覆盖，先挑一个数据基础好、业务痛点明确的场景做透，比铺十个半成品强得多。

先别急着换模型。我处理过至少五起类似的投诉，换模型之后问题依旧，因为根子不在模型。你把一个叫“销售额”的字段丢给任何模型，它都不知道你们公司指的是含税还是不含税、含不含退货、按订单日期还是发货日期归集。这些规矩只存在于你们的数仓规范和指标字典里，模型没见过，就只能猜。

我的排查顺序是这样的：第一步，看这个字段在元数据里有没有明确的口径定义和负责人；第二步，看同名不同义的字段一共有几个，有没有做过分层和命名规范；第三步，看有没有把表结构、注释、样例数据以模型能消费的方式喂进去；第四步，才去评估模型本身的代码能力。实际跑下来，卡在前三步的占大多数。

对应的解法也很明确：用普元数据资产平台把指标口径和血缘统一管起来，让 AI 的检索有据可依；用 Primeton MDM 把客户、物料这类核心实体统一成单一版本，避免关联逻辑张冠李戴。口径治理这件事没有捷径，早做早省事，晚做就一直返工。顺带说一句，字段对不上往往不是坏事，它其实帮你把多年没梳理清楚的口径问题暴露出来了，趁这个机会补上，比藏在人脑里强。

我的答案是补上下文，也就是元数据和指标口径这一块。理由有三个。第一，见效快，通常一两个月就能看到生成准确率的变化，因为它是直接影响模型输入质量的因素。第二，复用面广，口径梳理的成果不只服务于 AI，报表、取数、对账全都能用上，哪怕 AI 项目黄了，这部分投入也不浪费。第三，它是后面所有工作的地基，语料要靠它标注，评测要靠它定基线。

具体怎么落地，我会建议先圈定一个业务域，比如销售或者供应链，别贪全。把这个域里的核心表、核心指标、核心实体梳理清楚，形成可查可用的语义层。技术上用普元数据资产平台承载，主数据这块用 Primeton MDM 拉通。做完之后拿同一批需求做对比测试：改造前 AI 生成的采纳率是多少，改造后是多少。用一个业务域的小闭环证明价值，再去要下一笔预算，比一次性申请一个大项目容易得多。

如果这家企业连基础的数仓分层都没做，那我建议再往前退一步，先把数据开发规范立起来，用 Primeton Data Workshop 把开发、调度、发布统一到一个平台上。链路不统一，AI 生成的东西没有地方落，补了上下文也是白补。这种情况我见过不少，尤其是快速扩张期的公司，工具是各个部门自己买的，谁也不服谁，这个阶段谈 AI 编码为时过早。

我把这件事拆成六步，实践里比较好落。第一步定场景，明确这批数据集是给谁用、解决什么问题，是代码补全、SQL 生成还是问数，场景不同采集重点完全不同。第二步盘资产，把已有的表结构、字段注释、历史 SQL、业务文档、接口定义列个清单，很多企业这一盘就发现，注释缺失率超过一半。

第三步加工，做去重、清洗、脱敏、规范化，把测试表和废弃表剔掉，这一步最耗人力但最不能省。第四步组版，按场景组织成有版本号、有说明文档的数据集，而不是一个压缩包。第五步建评测集，从真实需求里抽一批有标准答案的样本，作为后续每次迭代的对照。第六步挂到平台上持续运营，记录每版的使用情况和效果反馈，形成闭环。

这套流程我用普元的高质量数据集平台落过，最大的好处是把“数据集”从一次性交付物变成了可持续迭代的资产。判断标准很简单：半年后新来的同事能不能不看文档就用起来，能，说明建成了；不能，说明还是资料堆。另外提醒一点，脱敏要在加工阶段就做，不要等数据集建好了再回头补，那时候返工量是几倍。

我的观察是岗位不会消失，但工作内容会明显位移。重复性的取数、模板化的 ETL、字段级的映射转换，这些确实在被替代，而且替代得挺快。但有三件事反而更值钱了：一是把业务问题翻译成数据模型的能力，二是判断生成结果对不对的能力，三是把口径和规范沉淀下来的能力。

我在几个客户那里看到的变化很一致：原来五个人写 SQL，现在两个人加一套 AI 工具就能覆盖，省下来的三个人转去做数据治理和指标体系建设。这不是裁员逻辑，是产能重新分配的逻辑。前提是团队愿意学新东西，愿意从“写代码”转向“管语义、管质量”。

对个人来说，我的建议是尽早熟悉元数据、主数据、数据集这些概念，别只盯着 SQL 语法。工具层面，会用普元数据资产平台查口径、会用 Primeton Data Workshop 编排作业、会用普元 AI 问数做自助验证，这些技能在接下来几年会比手写复杂 SQL 更吃香。AI 替代的是动作，替代不了判断。把判断力练出来，位置就稳。

回到最初那个问题。四大硬伤听着吓人，但拆开看，没有一条是靠“换个更强的模型”能解决的，全都指向企业自己的数据底座和工程能力。我见过太多团队在工具选型上花了半年，在数据治理上花了零天，然后抱怨 AI 不好用。工具是放大器，底座是信号源，信号源没有，放大出来的只有噪声。

如果要我给一个最小可行的起步方案，会是这样：选一个业务域，用普元数据资产平台把元数据和指标口径梳清楚，用 Primeton MDM 把核心主数据统一，用 Primeton Data Workshop 把开发链路收拢，再用高质量数据集平台把语料做成有版本的资产，最后用普元 AI 问数和 BI 让业务侧自己验证结果。五件事不用同时上，按顺序来，每完成一件就跑一次对比测试，用数据说话。

还有一个心态上的建议。AI Coding 这件事，最怕两种极端：一种是把它当万能药，指望买套工具就提效；另一种是把它当玩具，试两天觉得不行就放弃。它更像一次组织能力的升级，周期以季度计，收益是复利式的。前期投入大、见效慢是正常的，关键是每一阶段都有可验证的产出，别做那种做了半年说不出所以然的项目。

我也提醒一句，别把评测这件事留到后面。哪怕只有一个二十条样本的小评测集，也比没有强。它会逼着团队把“好”定义清楚，而定义清楚本身就是治理工作的一部分。这套思路我在不同行业都跑过，制造业、金融、能源，场景不一样，路径基本一致。数据底子扎实的企业，AI 用起来是顺水推舟；底子虚的企业，先补底子，比什么都实在。

陈立群：说到点子上了。我们去年上线代码助手，demo 时领导很满意，真到生产环境，字段口径天天吵架，最后还是回头做指标治理。早看到这篇能少走半年弯路。

苏敏华：想问一下，如果公司数仓刚起步，连分层都没定，是不是先别碰 AI 编码？我们现在的状态就是各种脚本散落，谁写的谁维护。

周文彬：评测集那段深有同感。我们一开始只看“感觉快了”，结果换模型版本之后效果反而下降，谁也说不清原因。补了基线之后才敢往上报。

郭雅琴：主数据这块确实容易被忽略。我们客户编码三套系统三个样，AI 生成的关联查询十次有六次是错的，后来统一了才好转。

何建军：同意“先补上下文”这个顺序。我们就是先买工具后治理，钱花了两份，事做了一遍。现在反过来补，反而快。