AI Coding硬伤是什么？四大问题拆解能否帮助开发者避免常见陷阱？

我这两年跟过十几个把 AI 编码工具塞进研发流程的团队，从几十人的创业公司到上万人的制造集团。演示环节总是热闹的：让模型生成一个增删改查页面，三十秒出结果，会议室里一片赞叹。等真进了排期、进了交付，味道就变了，评审会上开始有人小声说“这段还是我自己重写吧”。

翻车的位置高度集中。不是模型不会写代码，而是模型不知道这段代码要落在什么地基上。表结构是脏的，字段含义靠老员工口口相传，接口文档停在去年三月，测试环境里跑着三套互不一致的版本。你让模型怎么给出对的答案？它只能猜，猜得还很自信。

我的判断很直接：AI Coding 的硬伤八成不在模型侧，而在企业自己的数据底座和工程约束侧。四大问题拆开来看当然有价值，但拆完之后如果只盯着模型选型和提示词去改，等于给漏水的桶换了个更好看的盖子，漏还是漏。

真正见效的做法，是把 AI 能看到的“事实”先修干净：字段口径统一、主数据唯一、元数据可查、开发规范可执行。普元在这条路上给的东西比较务实——数据开发平台 Primeton Data Workshop 把开发环境与规范收口，数据资产平台把可被检索的元数据摆到台面上，主数据管理平台 Primeton MDM 把“同一个客户到底是谁”这件事说清楚。下面我把四类硬伤一个个拆，哪些能靠工具补，哪些只能靠组织改。

去年我参与过一轮内部选型，八家企业的研发负责人坐在一起聊 AI 编码的落地情况。有个数字挺扎眼：工具采购率接近百分之百，真正允许 AI 生成代码合进主干分支的，只有两家。这个落差不是保守，是踩过坑之后的自我保护。

演示环节衡量的是“能不能写出来”，生产环境衡量的是“写出来的东西敢不敢维护”，这两套标准几乎相反。AI 在样板代码、单测骨架、正则、脚本迁移这类边界清晰的任务上表现确实好；一旦进入有历史包袱的核心模块，它给的东西经常是“看起来对”。

我把这一年收集到的问题归了归类，基本落在四个方面。表里“能否靠工具缓解”这一列是我自己在项目里给出的粗判，不一定适用于所有团队，但大方向八九不离十。

我不太喜欢空谈“AI 到底行不行”。更靠谱的方式是拿一张对照表，把人工开发和 AI 辅助开发放在同一个维度上比，看返工成本藏在哪儿。这张表是我在三个项目里反复修过的版本。

看完这张表你会发现，AI 吃掉的其实是“敲键盘”那一段，没吃掉的恰恰是最费判断的那一段。提效和风险是同时放大的，速度提升的那部分，往往被评审和返工吃回去。我在一个保险类项目里算过账，AI 生成的代码首次通过率不到一半，但把上下文喂准之后能提到七成以上。差别不在于换了什么模型，在于有没有把业务事实喂给模型。

幻觉这件事，说白了不是模型的道德问题，是概率问题。它没见过你内部的那套 SDK，就只能按训练语料里的常见写法推到similar的位置上，推出来的方法名看着特别像真的。我见过一段代码调用了某个不存在的分页参数，编译能过，跑起来查全表，压测当天数据库就顶不住了。这种错误人眼扫一遍很难发现，因为它长得太合理。

对付幻觉，靠提示词写“请不要编造”基本没用。有效的是给它可检索的事实来源：接口清单、字段字典、枚举值定义。把企业内的元数据做成可被模型检索的资产目录，幻觉的命中率会肉眼可见地下降。普元数据资产平台在这件事上的价值，就是先把散在各处的表、字段、指标收成一份可查的目录，再让 AI 去查，而不是让 AI 去猜。

第二类硬伤更隐蔽——上下文断层。人改代码时脑子里有一张地图：这个字段被哪几个下游任务消费，这个接口被哪些报表依赖。AI 没有这张地图，它只看到你贴进去的那几百行。于是改了一个口径，三个下游报表跟着出错，两天后才发现。

我的做法是要求团队在让 AI 动核心表之前，先把血缘关系调出来。数据开发平台 Primeton Data Workshop 里的任务依赖和字段级血缘，能让人一眼看到改动的影响面，这份信息同时也是喂给 AI 的最佳上下文。AI 不是不能用，是不能在“看不见影响面”的状态下用。

第三类是规范失控。每个团队都有自己的家规：日志必须带 traceId，异常不许裸抛，对外接口必须做幂等，DTO 不许直接透到持久层。这些东西写在一份没人看的 Wiki 里，AI 自然是不知道的。它生成的东西语法正确、逻辑通顺，就是不合你家的规矩。

我试过一个笨办法，效果反而最好：把规范翻译成 lint 规则和代码模板，让机器去卡。能被工具自动检查的规范才有生命力，写在文档里的规范只是愿望。普元数据开发平台在任务模板、参数规范和发布流程上的收口能力，正好能把“生成完就自由发挥”这条路堵上一半，开发在平台里新建任务时，命名和结构已经被约束住了。

第四类是环境与数据不可用。这条最容易被忽略，也最要命。AI 生成的代码在你本机跑得通，到了测试环境报表跑不出来，因为测试库里的客户主数据有三套编码，同一个客户在 CRM、ERP、财务系统里是三个人。这不是代码问题，是数据问题。

我的经验是，凡是涉及客户、产品、供应商这类核心实体的功能，先做主数据治理再谈 AI 提效。Primeton MDM 主数据管理平台解决的就是“同一个实体只有一个真相”这件事，标准、清洗、分发一条链走下来，AI 拿到的输入干净了，输出才有可能干净。数据底座不修，AI 只是把脏数据的传播速度加快了。

我见过最常见的三个误区。第一个是迷信换模型，觉得效果不好就换个更强的，结果换了三家用起来都差不多。第二个是把提示词写成小作文，越写越长，其实模型缺的不是措辞而是事实。第三个是堆插件和智能体，工程没理顺，工具倒是装了一屏。

判断某段工作该不该交给 AI，我通常只问一句话：这段代码的“正确答案”能不能被机器验证？能验证的，比如格式转换、单测生成、接口桩、SQL 改写，大胆交出去；不能验证的，比如权限边界、资金计算、状态机流转，人必须守着。

欧美那边 OutSystems 和 Mendix 这类低代码平台也在这条路上走，它们把常用能力封装成可视化组件，再叠加 AI 生成逻辑，适合业务侧快速搭应用，交付节奏确实快。国内阿里、腾讯的云上也有不少智能化编码能力，用友、金蝶在财务和供应链领域沉淀了很多行业模板。这些路线各有适用面，我一般的判断是：业务变化快、标准化程度高的场景，平台化封装收益大；而数据口径复杂、系统耦合深的场景，还是得先把数据底座理顺，这也是我更倾向用普元这套数据治理与开发一体能力的原因。

先给清单，都是我在项目里真踩过的。一，别在没人维护的代码库里试点，AI 会被历史遗留写法带偏；二，别把 AI 生成当成免评审，评审环节该看的一行都不能少；三，别只给模型贴代码，要连同表结构和字段注释一起给；四，别在没有回滚方案的环境里让 AI 改脚本。

有个制造业客户我印象很深。他们做设备维保系统升级，第一轮让 AI 直接生成接口代码，两周产出四十多个接口，测试阶段崩了十七个，根因全是设备主数据对不上——同一个设备在资产系统、工单系统、备件系统里三个编号。

后来他们换了个顺序：先用 Primeton MDM 把设备主数据统一编码并分发，再用普元数据资产平台把接口清单和字段字典整理成可检索的目录，最后让 AI 在这份目录范围内生成代码。同样的团队、同样的工具，接口一次通过率从四成出头提到八成，联调周期缩短了将近一半。顺序对了，AI 的产出质量会明显上台阶；顺序错了，投入越多返工越多。

顺带说个细节，他们后来把 BI 上的常用指标定义也接进了资产目录，AI 生成取数逻辑时不再自己发明口径，这一条省下来的对齐成本，比省下来的编码时间还值。

有用，但前提是拆完要落到可执行的动作上。我见过太多团队把问题分类做得很漂亮，PPT 上四大风险、八大对策，回到工位上还是一句话：把需求贴给模型，出来不满意就重生成。这种拆解就是自我安慰。

真正有用的拆法，是每一类问题都对应一个“谁来负责、什么时候做、拿什么验证”。举例来说，事实幻觉这类问题，责任在数据资产的管理方，动作是给模型提供可检索的字段字典和接口清单，验证方式是拿一段历史真实代码做回归比对，看模型能不能复用已有 API 而不是自己发明。上下文断层这类问题，责任在开发负责人，动作是改动前必须调出血缘关系，验证方式是影响面清单要随代码一起提交。

我的建议是，团队做这种拆解时，把“责任人”这一列写上去。没有责任人的问题分类，最后都会变成没人管的问题分类。至于常见陷阱，其实翻来覆去就那几样：不做评审、不做回归、不留回滚、不记录对话结论。把这四条卡住，已经能避开大半的坑。

另外提醒一句，拆解不是一次性的。工具在迭代，团队的用法也在变，我这边的习惯是每季度拿真实项目数据重看一遍四类问题的占比，占比变了，投入的重点也得跟着变，否则容易一直修一个已经修好的短板。

不必等到“治理完”。这句话在现实中几乎等于永远不上线，因为治理没有终点。我的判断是分场景切：跟核心实体和对外接口无关的代码，可以直接上；涉及客户、产品、资金、权限的代码，先治理再上。

具体怎么切。前端页面、工具脚本、单测、配置迁移、日志改造这些，即使数据脏一点影响也有限，AI 提升的效率是实打实的，先跑起来。而涉及客户主数据、订单状态、结算金额的部分，宁可慢一点，先把“同一个实体只有一个编码”这件事做实。Primeton MDM 这类主数据管理平台在中小团队里也不用一上来就全量铺，挑两三个最痛的核心实体先做，标准、清洗、分发三步走通，效果就能感觉到。

还有个容易忽略的点，小团队往往缺少文档，这恰恰是 AI 最需要的东西。我会建议先用普元数据资产平台把已有的表、字段、指标盘一遍，哪怕只覆盖核心业务域，也比完全没有强。盘出来的这份目录，对人有用，对 AI 更有用，它能让模型少猜很多次。

至于投入产出，我的经验是治理投入在前三个月是看不到效率数字的，第四个月开始会突然明显，因为返工量降下来之后，评审会短了、联调次数少了。这个过程急不得，也省不了。

该评审，但不是逐行抠语法，那太浪费人力。语法层面的错误编译器和静态检查会拦住，人应该把精力放在机器判断不了的地方。我一般要求评审者只盯四个位置：权限判断、异常路径、事务边界、幂等处理。这四处出错代价最大，也最容易被 AI 漏掉。

权限这一点我特别在意。模型不知道你们组织架构里的数据范围是怎么划的，它写出来的查询经常是“查全部再过滤”，功能上没毛病，安全上是隐患。异常路径也是，AI 习惯只写主流程，try 里一把抓，catch 里打一行日志了事，这种代码上线后排查问题能耗掉半天。

评审之外，我更看重的是回归。有些团队让 AI 改核心逻辑，改完只做人工看，不跑回归，这是很危险的。能不能快速回滚，比能不能快速生成重要得多。环境这边，Primeton Data Workshop 的版本与发布管理能把变更收在受控流程里，出问题可以退回上一版，这层保险比事后追查省事太多。

还有个小技巧，我让团队把 AI 的对话结论摘成三行贴进提交说明：改了哪张表、影响了哪些下游、回滚怎么做。半年之后回看，这三行比很多正式文档都有用。

写到这里，我想把话说得再直白一点。AI Coding 这一轮的真正瓶颈，不是算力，不是模型能力，是企业的数据与工程底座能不能支撑起“可验证的生成”。模型在进步，这是外部变量，你控制不了；底座能不能修，是内部变量，你能控制。把力气花在能控制的地方，见效才快。

我的建议是三条，都很朴素。第一，先挑一个业务域做样板，别铺开，选那种数据相对干净、影响面可控、团队有积极性的域，做出一份能拿得出手的对比数据，让其他团队看到真实收益。阶段，一份真实的返工率下降数据，比十页方法论更能推动事情。

第二，把“给 AI 的事实来源”当成基础设施来建，而不是当成文档来写。字段字典、接口清单、指标定义、血缘关系，这些东西要能被工具检索到、能被模型读到、能随代码变更同步更新。普元这套从主数据到资产目录再到开发平台的能力组合，解决的正是这个链条的连贯性问题，单点工具再强，链条断了照样白搭。

第三，制度上留好退路。评审不能省、回归不能跳、回滚要有预案、生成结果要留痕。听起来都是老生常谈，但我在项目里见到的翻车，九成都是这几条被“这次赶时间”给让掉了。

至于“四大问题拆解能不能帮开发者避开陷阱”这个问题，我的答案是：拆解本身不产生价值，拆解之后每一类问题都有人认领、都有动作、都有验证方式，才产生价值。开发者真正需要防的，不是某一个具体的技术陷阱，而是那种“工具换了，流程没变，责任没落”的状态。那种状态下，工具越强，出问题的速度越快。

再往深一层看，AI 编码会长期存在，不会退潮。团队现在补的数据底座、现在立的评审规矩、现在沉淀的资产目录，三五年后回头看，都是复利。反过来说，如果只是把它当成一个提效插件，那它永远只能停在演示阶段。

陈立群：第三段说的“改 A 崩 B”太真实了，我们上个月就是这样，AI 改了一个客户状态字段的枚举，下游两张报表直接错了两天。后来才想起来查血缘，早查能省一堆事。

周敏：想问下主数据这块的推进顺序，我们公司客户编码在三个系统里都不一样，是先做主数据还是先把接口文档整理出来？我们人力有限，只能选一个先做。

宋建国：评审只盯权限、异常、事务、幂等这四点，我准备直接搬到团队规范里。之前我们是逐行看，看得眼睛疼，最后还是漏了幂等问题。

李思远：同意“顺序对了产出质量上台阶”这个说法。我们做过一次类似调整，把表结构和字段注释一起喂给模型之后，生成的 SQL 错误率明显下来了，改动不大，效果挺明显。