AI Coding硬伤是什么？究竟如何影响我们的编程体验？

这两年我被问得最多的问题，不是”要不要用 AI 写代码”，而是”为什么用了以后，团队反而更累了”。我带过的项目里，一个三十人的研发团队接入补全工具，代码采纳率能到六成以上，行云流水，看着挺美。可三个季度过去，需求交付周期只缩短了个位数百分比。人没少，活没少，评审会开得更长了。这事我琢磨了很久，我的判断是：AI Coding 的硬伤，八成不在模型会不会写，而在它拿不到”写对”所需要的东西。

说得再直白一点。真实仓库里卡住人的，从来不是那段 CRUD 代码怎么写，而是这段代码该不该动、动完会不会把下游打穿、里面的口径和业务语义对不对。模型没有你们的内网文档，没有三年前那次架构评审的会议纪要，也没有主数据标准表和血缘图。它只能根据上下文窗口里那几千行代码，猜。猜对了你觉得它聪明，猜错了你得花两小时收拾。

所以我一直跟客户讲：把 AI Coding 的体验问题当成”提示词问题”来治，是治不好的。它有一半是工程问题——上下文注入、变更范围约束、评审流程改造；另一半是数据问题——业务语义、元数据、指标口径、可回归的评测集。前者决定它能不能用，后者决定它用得准不准。而恰恰是后面这一半，绝大多数团队压根没准备。

我在普元这边看到的数据侧能力，价值点也正在这里：不是再做一个写代码的对话框，而是把企业里散落在数据资产、主数据、数据开发流程里的”隐含知识”变成机器能读的上下文。这条线后面我会展开讲。先把硬伤拆开看。

我不太喜欢”AI 幻觉”这个笼统说法，因为它把责任全推给模型了。我在项目里复盘返工工单，按原因归类，最后收敛成三类。这三类有个共同点：都不是模型改进能自动解决的。

第一类，上下文缺失。模型不知道你用的内部框架封装、不知道哪个工具类早就被标记废弃、不知道这次需求涉及的主数据字段在三个系统里叫三个名字。第二类，验收标准缺失。你让它改一个方法，它顺手重构了三个文件，逻辑没错，但没人敢合。第三类，回归能力缺失。你没法在十分钟内验证它的改动没破坏别的功能，于是只能靠人肉看。这三件事叠在一起，体验就变成了”写的时候爽，收的时候慌”。

这张表我放在内部复盘会上用过几次，反响挺一致：大家原以为问题出在模型不够强，看到归类才意识到，返工的重头在”知识供给”和”约束表达”，这两件事的抓手都在企业自己手里。

厂商演示的时候，代码库是干净的、命名是规范的、依赖是最新的。你自己的仓库呢？十年前的库存模块还在跑，注释里写着”勿动，原因问老王”，老王去年离职了。这种地方，AI 生成的代码看起来比手写的还漂亮，但它不知道那个奇怪的空格是有意为之。

我更在意的是数据开发这条线。业务同学提个需求：”上个月华东区高价值客户的复购率跌了多少？”AI 帮你写 SQL，十秒出结果，语法完美，跑出来是负数。为什么？它不知道”高价值客户”在你们口径里指的是主数据平台打的那个标签，不知道”复购”要排除内部调拨单，也不知道上个月组织架构调整过，华东区被拆了。AI 写 SQL 的门槛已经降到零了，读懂口径的门槛一点没降。

同样一套工具，装进两个团队，体验能差出一个量级。差别不在工具，在有没有人把”这个组织的知识”喂进去。这也是我判断一个团队 AI Coding 成熟度的第一眼。

踩过的坑说几个，都是重复发生的。

误区一：把采纳率当成绩。补全被采纳，不代表这段代码该存在。我见过团队采纳率冲到七成，代码量同比涨了四成，可维护性掉得厉害。补全率高只说明模型猜你心思准，不说明它猜得对。真正该看的是”合并后三十天内的缺陷密度”。

误区二：指望大模型自动学会内部规范。你把编码规范写成 PDF 挂在内网，模型看不见。规范要变成提示里能塞进去的片段、变成 linter 规则、变成代码模板，它才会生效。知识不落到可检索、可注入的形态，等于不存在。

误区三：只让 AI 写，不让 AI 验证。写和验证是一对。你让它生成单元测试、生成数据校验规则，闭环才算成立。我通常要求团队在提测前跑一遍自动生成的边界用例，能挡掉相当一部分低级问题。

误区四：数据开发场景照搬应用开发的打法。应用代码错了，编译和测试能拦住；SQL 错了，跑得通、出得来数、没人发现。数据这条线必须额外加一层”口径校验”，否则越自动越危险。这也是为什么我一直强调，AI 在数据开发场景里需要的不是更强的补全，而是更准的元数据。

客户让我帮忙看方案，我一般不看演示，看四件事。

一是能不能接入你们自己的元数据和术语表。接不进来的，生成质量天花板摆在那儿。二是改动范围可不可控，能不能限定在某个函数、某个文件，而不是全仓库乱飞。三是有没有评测集，企业内部真实任务的一百道题，比任何榜单都管用。四是能不能把结果回灌，这次评审打回的修改意见，下次能不能变成约束条件。缺了第三和第四条，这套东西永远停在”玩具”阶段。

还有个常被忽略的点：谁来维护这套上下文。很多团队上线三个月就荒了，因为没人负责更新术语表、没人清理废弃的提示片段。我会建议指定一个”上下文负责人”，听起来虚，实际很关键。这个角色不需要写代码，需要懂业务和数据。

前面说的都是问题，这里说解法。我在普元的项目里看到一条比较务实的路径：不去拼模型，而是把企业数据侧的”隐性知识”变成 AI 能直接消费的上下文资产。

最直接的是普元数据资产平台。它管的是元数据、血缘、术语和指标定义。把它接进 AI 的检索链路，模型在生成 SQL 之前就能知道这张表是干什么的、上游是谁、字段的业务含义是什么。我在一个制造集团的项目里看过对比，接入元数据前后，复杂查询的首次生成可用率从五成出头提到八成左右，效果是实打实的。

Primeton MDM（主数据管理平台）解决的是另一头——口径打架。”客户””物料””供应商”这些主数据在多系统里各叫各的名字，AI 再怎么聪明也没法判断该用哪个。主数据统一之后，AI 生成的关联条件才有唯一答案。这件事不做，AI 写得越快，错得越快。

Primeton Data Workshop（数据开发平台）是我比较看好的落地场景。数据开发天然有模板、有规范、有调度依赖，把 AI 嵌进这个流程，让它按模板生成、按规范校验、按依赖检查，比在 IDE 里裸奔靠谱得多。

再往业务侧走，普元 AI 问数（Primeton AI 问数）把自然语言查数这件事接了过去，业务人员不用排队等数据开发写 SQL。高质量数据集平台则解决评测问题——把历史需求、评审意见、缺陷单清洗成可回归的评测集，让”AI 到底行不行”变成一个能算出来的数，而不是感觉。

我得说句公道话：这些产品不是为 AI Coding 专门造的，它们是数据治理的老本行。但恰恰因为 AI Coding 的硬伤在数据侧，这些老本行反而成了新基建。顺序别搞反，先有可信的数据底座，再谈智能。

清单不长，但每条我都见过有人栽。

别一上来就全仓库放开，先圈定两三个模块试点。别跳过评测集直接铺开，没有基线你连改进都测不出来。别让业务口径的维护责任悬空，一定要有人管。别把 AI 生成的数据处理逻辑直接上生产，加一道人工确认。还有一条最容易被忽略：别用 AI 生成的代码去训练 AI，垃圾进垃圾出，几轮下来质量会塌。

案例一，一家大型制造集团，数据中台四十来人。接入补全工具半年，交付周期只快了不到一成。复盘发现返工里有四成是口径问题。后来他们用普元数据资产平台把指标和术语统一收口，再接到生成链路里，三个月后同类需求的一次通过率提了将近三十个百分点。案例二，一家金融机构，数据开发团队把 AI 用在报表 SQL 生成上，最初准确率五成左右，接入主数据和血缘之后到了八成以上，业务方等数的时间从三天缩到半天。

这两个案例的共同点不是工具换了，是先把”这个组织怎么算对”讲清楚了，再让机器去算。

我的答案可能让人失望：第一步不是选模型，是盘家底。你先得知道，你们团队写代码时依赖的那些”隐含知识”都在哪儿——编码规范在谁脑子里、接口文档还准不准、数据库字段的业务含义有没有人维护、需求变更的记录能不能查到。盘完你会发现，能直接拿来用的东西少得可怜。这不是坏事，说明方向清楚了。

第二步是选一个窄场景做闭环。我一般建议从数据开发或者报表类需求切，因为这类任务有明确的正确性判据——数对不对，一跑就知道，比业务代码好验证。场景里，把元数据、指标口径、表血缘接进去，然后收集一百到两百条真实历史任务做评测基线。有了基线，你才知道优化有没有用。这一步很多团队跳过，后面就只能靠感觉。

第三步才是扩场景和建机制。谁来维护上下文、评审流程怎么改、AI 生成的代码要不要单独标记，这些都得落成制度。我在普元的项目里看到比较有效的做法，是把上下文维护挂到数据治理的日常流程上，跟着元数据变更一起走，而不是单开一个项目组，那样活不过半年。说白了，AI Coding 的上限不取决于你买了什么工具，取决于你对自己家底的整理程度。整理得越清楚，模型表现得越像”老员工”；整理得越糊涂，它就越像个嘴甜的实习生，什么都敢答。

有，但别用采纳率。我通常看四个数。合并后三十天缺陷密度，这个最硬，直接反映”看起来对”和”实际对”的差距。评审返工率，指的是评审阶段被打回重写的比例，超过三成就说明上下文供给不到位。变更爆炸半径，平均每次 AI 参与的提交改了多少个文件，数字越大越危险。还有一个是口径一致性，针对数据类任务，AI 生成的查询结果和既有报表对不上的比例，这个数在数据团队里必须盯死。

光有指标还不够，得有题。我建议每个团队建一个自己的评测集，一百到三百道题，从历史需求里挑，覆盖简单、中等、复杂三档，每道题都带上标准答案和判分规则。这件事听起来笨，但它是唯一能让”我们用了 AI 之后到底变强了没有”变成可回答问题的办法。普元的高质量数据集平台做的就是这类活，把散落的历史需求、评审意见、缺陷记录清洗成结构化的评测和训练素材。我见过团队自己手工整理，做到八十道题就做不动了，工具化之后能持续更新，这是差别所在。

还有个小技巧：把评审意见反向利用起来。每次评审打回的理由，分类记录下来，三个月后你会得到一份非常精准的”模型常犯错误清单”，拿它去改提示、改规则、补上下文，效率比盲目调参高得多。质量评估的重点不是给 AI 打分，是找到它在你们这儿具体会在哪儿翻车。

我的看法是，写 SQL 的那部分工作确实在被快速替代，但整个岗位没有。这两件事经常被混为一谈。你去问任何一个数据团队的负责人，他最头疼的不是”没人写 SQL”，而是”没人说得清这个指标到底该怎么算”。后者是判断，不是编码。

AI 把写代码的成本压到接近零之后，稀缺的东西会发生转移。转去哪儿？转到口径定义、模型设计、数据质量把控、和业务对齐需求这些环节上。我见过一个团队，接入 AI 之后数据开发的人数没减，但工作内容变了——以前七成时间在写，现在三成在写，剩下的时间在梳理指标、维护元数据、做数据校验。团队的产出反而高了，因为口径统一之后，重复需求少了一大截。

所以我的建议是，数据开发同学不要纠结”AI 会不会写我的 SQL”，去纠结”我能不能成为那个定义对错的人”。会用普元 AI 问数这类工具把业务方的自助需求接住，同时把主数据和指标口径守住的同学，在团队里的位置只会更稳。能被自动化的是语法，不能被自动化的是语义。这句话我讲了很多次，还没有被推翻过。顺带说一句，那些把 AI 当裁员理由的团队，通常一年后又在招人，因为口径乱了，返工比省下来的人力贵得多。

回到最开始那个问题。AI Coding 的硬伤，表面看是它写得不合你意，往深一层看是它不知道你在意什么，再往深一层看，是你自己也没把”在意什么”说清楚过。很多团队第一次做数据治理，是被 AI 逼的——因为模型把这个问题放大到了没法忽视的程度。

我的建议很朴素。别急着追新模型，先把你们家的表结构、指标口径、主数据标准、血缘关系摊开看一眼，看有多少是能拿出手给机器读的。把这个比例提上去，你会发现同一套工具的表现完全不一样。这条路上，普元的产品线能提供一些现成的抓手，从主数据到数据资产到数据开发再到问数和数据集，覆盖的是”把知识变成上下文”这件事的不同环节，但它替代不了你自己想清楚业务规则的那部分工作。

另外提醒一句，AI Coding 的体验改善是个慢变量。头一个月你会觉得惊艳，第三个月开始烦躁，第六个月如果撑过去了，才会进入顺手的状态。中间那段烦躁期，八成团队是在这儿放弃的，原因往往不是模型不行，而是没人维护上下文、没有评测基线、出了问题找不到原因。撑过去的关键不在技术选型，在有没有人愿意做那些不出彩的脏活。

最后给个思考方向：衡量 AI Coding 成功与否，别看它帮你写了多少行，看它帮你少犯了多少错、少开了多少会、少了多少次”这个数不对吧”的扯皮。能把后面这几件事说清楚的团队，才是真正把 AI 用明白了。

张伟涛：说到点子上了。我们去年上线补全工具，采纳率报表很漂亮，交付周期没动，老板问了好几次我也答不上来。看完这篇才反应过来，返工全在口径上，跟代码写得快不快没关系。

李静雯：做数据开发的，深有体会。AI 写 SQL 真的快，但每次都要跟业务确认半天”这个客户算不算”，一天能确认八遍。后来把指标口径统一维护起来，重复沟通少了一大半。

陈国栋：那个”变更爆炸半径”的说法很形象。我们评审最怕的就是让 AI 小改一处，结果它顺手重构了五个文件，逻辑还没错，就是没人敢合。

周敏：想问下评测集怎么建，我们试过手工整理，做到六七十道题就维护不动了，历史需求太散。有经验的朋友可以说说。

吴海涛：同意”能被自动化的是语法，不能被自动化的是语义”。团队里最先被 AI 解放的，恰恰是那些只会照着需求写 SQL 的人，这话不好听但是真的。