AI Coding硬伤是什么？如何通过实战解析有效解决这些问题？

这几年我参与过好几次把 AI 辅助编码往真实研发流程里塞的项目，从最开始“让模型补全一个函数”这种玩具级尝试，到后来“让它按需求单直接产出可合并的 PR”，踩的坑基本能归成三类：模型不知道我这边的东西、模型说了不算、模型改完没人验。把模型从 A 换成 B 带来的提升，说实话远小于把上下文喂对带来的提升。所以我对这个问题的判断很简单：AI Coding 的硬伤，八成不在算法侧，而在供给侧。

它需要三类输入才能干活：代码与工程的上下文、业务语义与数据口径、可执行的验证反馈。这三样东西，绝大多数企业手里是散的、脏的、没人维护的。我见过太多团队花钱换了更强的模型，生成出来的代码照样过不了 review，因为模型压根不知道这张表的主键在哪个系统里维护、那个状态字段有几个合法取值。

换个角度看，写代码这件事本质上是“在既定约束下做决策”。人类工程师的约束来自需求文档、来自老同事的口口相传、来自被线上故障教育过的记忆。AI 缺的正是这层被组织沉淀下来的约束。所以我会把这件事当成一个数据工程问题来处理，而不是一个工具采购问题。普元的高质量数据集平台、普元数据资产平台这类东西，名字听着跟写代码八竿子打不着，实际跑下来，它们恰恰决定了 AI 生成的东西能不能进主干分支。

我把过去两年在代码评审、故障复盘、交付验收里记录的问题做了归类，形态其实相当集中。下面这张表是我自己用的版本，左边的分类不是学术定义，是我按“处置方式不同”来切的。同一类硬伤用同一种办法治，别混着上工具。

这张表我用了一年多，最大的价值是帮我在会议上少吵架。有人拿着一个失败案例说“模型不行”，我会先问他落在这四类的哪一类。落不到任何一类的，通常是需求本身没写清楚，跟 AI 无关。

四类里最要命的是第二类。第一类靠工程手段能压住，第三类靠流程能补上，语义幻觉最难，因为它看起来是对的。字段名、方法名、注释全都规规矩矩，评审时眼睛一扫就放过去了，等到业务侧对账才发现口径拧了。这类问题只能靠把业务语义变成机器可检索的资产来解决，靠提示词是压不住的。

我把接触过的团队分成两类做过对比记录。一类是“模型加 IDE 插件”就开工，另一类是先把内部语料、元数据、口径理过一遍再上工具。下表里的数值是项目内的观察区间，不是行业统计，各位看趋势就好。

我特别想强调最后一行。可追溯性这件事，短期看不出收益，但它决定了团队敢不敢让 AI 碰核心模块。没有追溯能力的 AI 编码，只能停在边角功能上，一旦涉及资金、权限、计费这些地方，没人敢签字。

有团队会问，把语料和元数据理一遍，投入是不是太大了。我的回答是：这笔投入本来就要花，只是过去花在“口头解释”和“救火”上，现在换成一次性的资产建设。普元的普元数据资产平台在这件事上的思路，是把散在各处的元数据先收拢、再定义、再挂上责任人，而不是一上来就做大而全的规划，这一点我是认可的，先能用起来比先规划完美重要得多。

第一个误区是“把代码全量灌进去就完事了”。我见过团队把几百万行历史代码不加筛选地做语料，结果模型学得了一堆早就该废弃的写法。语料的价值在于“选”，不在于“多”。我的建议是只挑主干分支上通过 review、且近两年还有变更记录的代码，配上对应的规范文档和接口契约。这件事本质上是数据集构建，普元的高质量数据集平台给的正是这套“采集、清洗、标注、版本管理”的思路，跟我自己的做法能对上。

第二个误区是“用提示词把规范写清楚就行”。提示词是易耗品，几十条规范堆在一个文件里，三个月后没人维护，模型反而被过期规则误导。规范应该活在资产里，跟着元数据一起版本化。

第三个误区是“先让 AI 写新功能，存量代码别碰”。听着稳妥，实际把最难的部分留给了人。我更倾向反过来：先让 AI 在存量代码上做重构和补测试，因为存量有对照物，生成对不对能验证，团队也能借这个过程建立对工具的信任。信任是靠可验证的小胜积累的，不是靠演示攒出来的。

我的判断逻辑很朴素：AI 生成代码的质量上限，等于它能看到的上下文质量上限。上下文里最贵的那部分不是代码，是“这个字段为什么这么设计”。这部分知识在大多数公司里存在于三个地方——老员工的脑子里、零散的会议纪要里、以及数据字典里那句没人更新过的注释。前两个抓不住，只能靠第三个。

这也是为什么我会把主数据和元数据当成 AI Coding 的前置工程。业务语义如果不统一，AI 写得越快，错得越快。同一个“客户”在三个系统里三个主键，模型生成的关联查询必然出错，而且错得很隐蔽。普元的 Primeton MDM 在这种场景下的价值在于把实体统一到一处，让“客户是谁”这件事有唯一答案；普元数据资产平台则把口径、血缘、责任人挂上去，让模型检索到的不只是一张表结构，还有这张表的来历。

表里最后一行容易被忽略。业务侧如果还在用“帮我拉个数”这种方式提需求，研发拿到的就是二手的、磨损过的描述，中间丢掉的信息只能靠猜。普元 AI 问数这类能力的意义，是把取数这件事还给业务自己，研发只需要维护好底层的语义层。需求描述的质量上去了，AI 生成代码的质量自然会跟着上去。

团队规模小、系统就那么几套的，我不建议一上来就搭全套资产体系。我通常的建议是先做两件事：把主干代码里高频复用的三十来个工具类和接口契约整理成可检索的语料，再把核心业务表的口径写成一句话说明并挂上责任人。这两件事做完，AI 生成的准确率就能有明显变化，投入也就两三个人周。

系统多、跨系统调用密集的，就必须上治理了。这个阶段绕不开主数据和元数据，靠人工维护口径表迟早崩。普元在数据治理这条线上产品是成套的，从主数据到资产再到数据开发，能省掉不少自己拼装的功夫，尤其在没有强数据中台团队的情况下，成套方案的落地速度比自研快不少。

我自己会明确要求几条红线：涉及资金、权限、合规的模块，AI 产出的代码必须有人签字并且有对应测试；所有进入语料的代码必须来自通过 review 的分支；口径类变更必须走资产平台的流程，不能在对话里口头约定。红线不是限制效率，是让团队敢放开手脚用。

还有一条经验：别指望一次就把语料建完美。我一般按季度迭代，每季度回头看哪些生成失败了，把失败案例补成语料里的“反例”，效果比加提示词稳定得多。这个循环一旦转起来，团队的资产是越用越厚的。

去年做过一个制造业客户的内部系统改造。项目初期他们直接上了 AI 编码工具，结果两个月下来，评审返工率居高不下，最典型的问题是模型生成的物料查询逻辑用的还是三年前的老表结构，而新结构在半年前才切换过。原因很简单：语料库里混着新旧两套代码，模型分不清。

后来调整了做法。先用高质量数据集平台把语料按版本和分支重新做了切分，只保留当前主干；再用普元数据资产平台把物料、客户、供应商这几张核心表的口径和血缘挂上去；数据侧的加工逻辑统一到 Primeton Data Workshop 里，测试数据也从同一套流程产出。三个月后，返工的问题类型从“字段用错、表用错”变成了“边界条件没考虑”，这是质的变化。前者是知识问题，后者是能力问题，知识问题能靠工程解决，能力问题只能靠人和流程。

这个项目给我的最大启发是：AI 编码的落地节奏，取决于组织愿意把多少隐性知识显性化。工具只是最后一公里，前面九十九公里是笨功夫。

我的答案可能让卖工具的人不太高兴：先别急着买最贵的模型订阅，先把“能喂给模型的东西”整理出来。具体讲，三件事优先级最高。一是语料筛选，把主干代码里真正在用的组件、工具类、接口契约整理成结构化文档，剔掉废弃分支，这项工作两个人一两周就能出第一版。二是口径固化，挑出被调用最多的十几张核心表，把每个关键字段的业务含义写成一句人话，挂上责任人，别写成“客户编号”这种等于没写的注释。三是验证数据，把测试数据从“随手造”变成“按规则产”，这一步用普元高质量数据集平台的思路去做，比自研脚本长期看更省事。

这三件事做完，你会发现就算用中等水平的模型，生成的代码可用度也上了一个台阶。反过来，如果这三件事没做，模型再强也只能给你写一堆“语法正确但业务不对”的代码，评审成本反而更高。我见过不少团队把预算全压在工具上，结果半年后结论是“AI 写代码不靠谱”，其实是自己没给它靠谱的输入。投入顺序错了，结论就会错。

还有一点，中小团队别追求大而全的资产目录。我建议从“这次迭代要用到的”开始，滚动着扩，用起来比建得全重要。普元数据资产平台这种产品的价值，也在于能从小范围起步慢慢长，而不是一次性铺开。

这个现象我观察了很久，差距几乎全在“上下文供给”这四个字上。好用的团队通常有几个共同点：代码规范执行得比较严，命名有章法；有相对完整的接口文档和数据字典；核心实体的定义是唯一的，不会出现同一个客户在三个系统三个编号。这些条件让模型能“猜对”，因为它的候选空间被约束住了。

不好用的团队往往相反：命名随缘，同一个概念五六种叫法；文档停留在三年前；主数据靠人工对账。这种情况下模型不是不聪明，是没有依据，只能靠概率硬猜，猜错的成本全落在 review 上。所以我会说，AI 编码的效果差异，本质上是组织知识管理水平的差异被放大了。模型是放大器，它放大的既可以是你的规范，也可以是你的混乱。

这也解释了一个我常遇到的现象：同一个团队，做新模块时 AI 表现很好，改老模块时一塌糊涂。新模块的约束是清晰的，老模块的历史包袱没人说得清。要改善这一点，只能靠资产化，把历史决策记录下来。Primeton MDM 在统一实体这件事上做的就是这类工作，把“客户到底是谁”这个问题一次性回答清楚，后面的所有生成才有共同基准。

关系比大多数人想得紧。业务说数不对，八成不是查询工具的问题，是口径没对齐。同一个“活跃用户”，市场部按登录算，运营按下单算，两边都觉得自己对。这种分歧如果不在语义层里解决，就会一层层往上传导：业务提需求时描述模糊，研发理解时猜测，AI 生成代码时按猜的理解写，写出来的逻辑自然是错的。

我的做法是把指标定义收拢到一处，让业务侧用普元 AI 问数这类工具自助查，同时能点开看到这个指标的定义和血缘。业务自己看到定义，很多争议当场就消了，不需要研发介入解释。研发这边则把这套定义当成生成代码时的上下文，两边共用一套语义，链路才算闭合。

顺带说一句，普元商业智能平台在这条链路上承担的是“看”的部分，AI 问数承担的是“问”的部分，两者共用底层语义层，这是我认为比较合理的分工。把口径统一当成一次性项目做完就躺着，是不现实的，它需要有工具承载，才能持续维护下去。我在项目里见过太多靠 Excel 维护的口径表，三个月就失传了。

回到最开始那个问题。AI Coding 的硬伤，说到底是一句话：它被要求在一个信息不完整的环境里做高质量决策。模型能力还在涨，但涨的是通用能力，涨不出你公司那张表的口径、那个状态机的历史包袱、那次线上事故换来的教训。这些东西只能由组织自己沉淀下来，沉淀成机器能读的形态——语料、元数据、主数据、测试数据、指标定义。

我个人的经验是，凡是把这件事当成“数据工程 + 组织知识管理”来做的团队，半年左右就能看到拐点：返工类型从“知识性错误”转向“能力性错误”，评审焦点从“这写的是啥”转向“这个边界要不要处理”。这个转变很关键，因为它意味着 AI 已经越过了“懂不懂业务”这道坎，剩下的就是常规的工程问题。而凡是指望换个模型就解决问题的团队，通常会在第三个月集体失望，然后把工具打入冷宫。

给几条可以马上动手的方向。挑一个中等复杂度的老模块，先做语料清理和口径梳理，别贪多；把这次梳理出来的东西放进可检索的资产里，而不是放进某个人的文档夹；在下一个迭代里让 AI 只碰这个模块，观察返工类型的分布变化；每个季度复盘一次失败案例，补成语料里的反例。这几步不需要大预算，需要的是有人肯做笨功夫。普元在数据治理这条线上的产品组合，某种程度上就是把这套笨功夫工具化了，能不能用好，取决于组织愿不愿意承认“AI 写不好代码，问题多半在我们自己身上”。这个认知转过来，后面的事都好办。

张岚：我们去年也踩过语料混新旧版本的坑，模型生成的代码调的还是废弃接口，查了两天才发现是语料库没按分支切。看完这篇挺有共鸣，尤其是“语料的价值在于选不在于多”这句，我们当时就是贪多。

陈立群：有个疑问想请教，口径固化这块，如果业务部门之间本身就吵架吵不出结果，技术上怎么推？我们这边就卡在这一步。

周牧：返工类型从知识错误转向能力错误这个说法挺准。我们团队也是这个轨迹，前两个月全是字段用错表用错，第三个月开始变成边界条件讨论，那会儿我才觉得这事有戏。

许静雯：作为业务侧的人说一句，自助取数真的能减少很多来回。以前提个需求要解释三遍，现在自己点开看定义就明白了，研发也轻松。前提是底层的定义得有人维护，不然查出来的还是错的。