周五下午团队用 AI 一下午生成了一套后台管理系统的增删改查接口测试环境跑得顺滑周一演示老板很满意。三个月后客户反馈对账金额偶尔差一分钱三个人排查了两天最后发现问题出在一段 AI 生成的金额计算里——浮点数直接做减法特定边界条件下精度丢失。生成这段代码花了十秒找到它花了三个团队人天。从那天起团队开始认真问一个问题AI 生成的代码质量到底靠不靠谱敢不敢直接放进正式项目。这个问题没有是/否答案只有在什么条件下敢用的答案。这篇文章把 AI 代码的质量问题拆成三类讲清楚每类的检测手段与漏网概率给一套可落地的质量闸门流程最后回答五个被问得最多的问题。概念卡幻觉代码。指 AI 生成代码里看起来对但实际不存在的部分——调用不存在的 API、引用不存在的参数、使用库的过期用法。它源于语言模型的概率本质模型在预测下一个最合理的词而不是验证每一行能否运行。幻觉代码是三类问题里最容易发现的一类编译和测试就能抓住大半真正危险的是下一节的隐蔽 bug。一、AI 代码的三类质量问题第一类幻觉代码——看得见的错。调用了不存在的接口、记错了参数顺序、用了三年前就已废弃的写法。这类问题特征鲜明一跑就报错静态检查和编译能抓住大半剩余的靠单元测试兜住。它给团队的惊吓感最强实际伤害最小——因为发现得早。对这类问题的正确态度是流程化的别指望 AI 不产生幻觉指望闸门拦住幻觉。值得说明的是幻觉率本身在持续下降——模型换代、工具引入实时检索与代码库校验后编造 API的频率比早期低了不止一个量级。但下降不等于消失更不等于可以撤掉闸门幻觉的问题从来不是频率而是它出现的位置不可预测。第二类隐蔽 bug——主路径全对错误路径全错。AI 生成的代码有个系统性倾向乐观假设。假设输入总是合法的、网络总是通的、并发总是不存在的、上游返回的数据结构永远是文档里写的那样。于是主流程演示完美异常分支一触即溃空列表没判、超时没处理、两个请求同时改同一条记录时状态错乱。这类问题的危险在于传统测试恰好覆盖不到——测试用例也倾向于测主路径。安全漏洞也属于这一类SQL 拼接、权限校验遗漏、敏感信息写进日志都不会影响功能演示但会在真实环境里暴雷。第三类可维护性问题——当时不发作半年后发作。风格漂移同个项目里十种错误处理写法、过度防御套了五层的空值检查掩盖了真正该处理的逻辑、重复实现项目里已有工具函数AI 又写了一个略有差异的版本。更根本的问题是代码是人审查通过的但没有人真正理解它——下次改动时团队面对的是自己仓库里的陌生代码。代码能跑但没人敢改是技术债的标准形态AI 把生成代码的成本降到极低也把制造这种债的速度提到了极高。二、根源AI 是概率匹配不是逻辑推演理解质量问题的分布规律先理解 AI 生成代码的机制它在做模式匹配与补全擅长的是常见问题的常见解法。由此可以推出两条实用规律。规律一越通用越稳越贴业务越要人盯。列表分页、标准库调用、常规算法实现这些是海量训练数据里的高频模式AI 生成质量相当稳定而对账规则为什么用分为单位、状态机为什么只允许特定迁移顺序、那个字段的 null 为什么有历史含义——这些是只存在于你项目里的约束AI 不知道你不告诉它它就按通用做法来而通用做法在你的项目里可能就是错的。规律二上下文给得越足质量越稳。不同工具给上下文的方式不同Cursor 靠代码库索引支持跨文件理解Claude Code 以终端 Agent 擅长复杂任务规划GitHub Copilot 依托 VS Code 做实时补全——但上下文决定质量这条规律是共通的。质量问题的归属因此清晰了AI 出幻觉是工具的特性用幻觉代码污染生产环境是流程的失职。三类问题在真实代码里的分布还有个实用特征它们经常叠在同一段代码里。一段生成得太顺的代码——命名规范、结构漂亮、一眼看去无懈可击——恰恰最值得警惕因为人对它放松了审查。反过来带点笨拙、能看到 AI 在局部纠结痕迹的代码反而说明模型在如实处理你给的特殊约束。这个规律没有统计背书是大量使用后的经验观察但值得写进评审清单越是漂亮的生成结果越要问一句错误路径在哪。还有一类边界情况要单独说AI 有时会生成对但没用的代码——比如为一个简单查询套上完整的缓存层或者给内部工具加上企业级的配置中心接入。这类代码没有 bug但抬高了系统的复杂度属于第三类可维护性问题的变种。识别信号是这段代码解决的问题你并没有提出过处理方式是直接要求删掉重生成而不是留着以防万一。三、四道质量闸门各抓各的缺一不可闸门能抓住什么抓不住什么成本静态检查lint、类型检查、SAST幻觉 API、类型错误、常见安全漏洞业务逻辑对不对极低全自动自动化测试主路径逻辑错误、回归问题没写到的路径、并发时序、真实环境边界中需要持续投入人工评审业务约束是否满足、设计是否合理评审疲劳后的细节遗漏高占用资深人力运行时监控与灰度发布真实环境的边界情况已经造成的影响中依赖基础设施这张表的读法四道闸门是按成本从低到高排列的递进结构顺序不能乱——没过静态检查的代码不进测试没有测试覆盖的代码不进人工评审。常见的错误做法是跳过前两道直接上人工评审等于用最贵的资源去抓机器一秒就能抓出的错评审人很快疲劳真正的业务问题反而漏过去。另一条读法每道闸门都有明确抓不住的东西所以任何一道都不能当唯一防线我们有人工评审和我们有测试单独拎出来都不构成敢用 AI 代码的理由四道齐上才构成。四、场景分级哪些敢放手哪些必须拉满敢放手用的场景原型与演示、内部工具、管理后台的增删改查、有完善测试兜底的项目里加新功能、脚手架与样板代码、一次性数据处理脚本。共同特征出错影响小、易回滚、有自然的安全垫。必须闸门拉满的场景金额与结算、权限与认证、并发处理、与外部系统的集成、核心业务状态机。共同特征错误代价高且未必立刻暴露。现阶段别用的场景安全关键系统、没有任何回归测试的遗留系统核心逻辑、强合规审计要求逐行可追溯人工责任的场景。最后一类要特别说明限制不是 AI 能力问题是责任链问题——出了事故必须有一个人能对每一行代码解释为什么这么写这个责任目前无法委托给模型。分级还有个实操细节模块不是静态的。今天的管理后台明天可能加一个涉及资金的操作按钮——模块的风险等级要跟着功能演进重估。建议把分级评审挂在迭代计划里每个迭代排期时过一眼涉及模块的等级标签有跨级变化低风险模块里出现了高风险功能就当场升级处理。分级表是活文档一年不更新的分级表比没有分级表更危险因为它给人过期的安全感。评审 AI 代码的清单也要跟评审人写代码的清单分开。传统评审四件套——风格、命名、逻辑、设计——前两件在 AI 代码上基本可以撤掉模型产出的风格一致性通常比人还好省下的时间投给后两件里 AI 特有的薄弱处。一份为 AI 代码定制的评审清单可以长这样输入边界空值、超长、非法格式在入口处拦了吗、失败路径外部调用超时或报错后系统处于什么状态、并发两个请求同时到会怎样、业务约束AI 不知道的隐含规则是否被描述过、存在性用到的每个接口是否真实存在。五项过完才算评审完成比泛泛地看一遍既快又全。五、落地路径给团队建一套 AI 代码质量闸门第一步模块分级。按第四节的分级给代码库逐模块贴风险标签放手用 / 拉满闸门 / 禁用。判断标准每个模块有书面等级新人看表就知道哪里的 AI 代码要细审而不是靠老人的口头经验。第二步闸门前移。把静态检查、类型检查、单测接入提交流程AI 代码必须先过全部机器闸门再进人眼。判断标准进入人工评审的 AI 代码已零静态告警评审时间里不再出现格式问题。第三步改造评审清单。AI 代码的评审重点从风格转向三件事业务约束是否满足对照第二条规律、错误路径是否处理空值、超时、并发、与既有代码的集成点是否安全。判断标准评审清单完成修订机器能查的项已全部移出人工清单。第四步度量与回看。记录 AI 参与代码的线上缺陷类型与占比每个季度回看一次据此调整分级。判断标准能拿出AI 代码与人工代码的缺陷结构对比而不是感觉 AI 写的不行/很行。看一个典型过程。某 30 人 SaaS 团队第一年全员使用 AI 编程工具交付速度明显起量半年后线上问题集中出现复盘发现集中在两处——结算模块的边界处理和一批风格各异、没人细看过的工具类。团队随后做了三件事模块分级结算与权限模块的 AI 代码强制双人评审加全量用例管理后台模块改为抽检闸门前移静态检查与单测成为评审前置条件季度回看按缺陷记录调整分级。此后 AI 代码占比继续上升线上问题没有同步上升。这个团队的关键变化不是换了更强的模型而是把对 AI 的信任从感觉它行换成制度上敢让它行。这类画像在中小软件团队里相当普遍。时间投入上给个粗略预期避免期望错位模块分级是一次性工作一个中等规模的代码库两三天能贴完标签闸门前移看基础设施底子已有持续集成流水线的团队一两天接完从零搭的大致以周计产出变化最快的是第二步——静态闸门一接上评审质量当天就能感觉到差别因为评审人终于只看机器查不出的问题了。真正的回报周期在季度回看之后前两个季度是攒数据第三个季度起分级表开始有依据地动态调整敢放手的模块逐步变多团队对 AI 的使用强度和信任度才进入正向循环。反过来的预期错配最伤士气第一天全员上 AI第一周就指望线上问题率下降——闸门还没建好这个期待注定落空。六、五个常见的追问追问一怎么快速识别幻觉代码编译与类型检查抓大半对没见过的 API 保持怀疑让 AI 给出调用出处并对照官方文档核对运行期抓不住的靠针对性单测针对 AI 声称的行为写断言而不是针对它写的实现写断言。追问二测试覆盖率多少才敢用 AI 代码没有魔法数字。思路是分层资损、权限、数据一致性这类核心路径必须覆盖边缘路径靠静态检查与运行时监控兜底。覆盖率是手段改动前有兜底可跑才是目标。追问三AI 代码会加速积累技术债吗会而且速度更快因为代码有了、理解没了的缺口被放大。对冲方法是让产出不止于代码文件配套的文档、用例与需求关联一起沉淀。全流程研发平台走的这个方向例如麦芽AI 这类产品把代码与需求、文档、测试用例做结构化关联为的就是半年后改这段代码的人能查到它为什么存在。用纯编码工具的团队可以用纪律弥补AI 参与的模块强制附设计说明。追问四用了 AI 还需要资深工程师吗更需要。AI 把写代码变便宜的同时把判断代码对不对变成稀缺能力。初级重复劳动被压缩架构约束、业务校验、异常设计这些判断的权重显著上升。团队结构从金字塔变成哑铃少数资深的人把关中间层靠工具。追问五用 AI 评审 AI 的代码行不行作为第一道闸可行让另一个模型自查能抓出一部分问题但不能当最终闸门。同类模型有重合的系统性盲区——生成时没意识到的乐观假设自查时同样意识不到。提升 AI 自查有效性的实用技巧是换角色换视角让评审模型以安全审计员或接手维护者的身份看代码并明确要求它只报错误路径与业务约束问题角色错开后能抓出的问题明显变多。但无论技巧多好最终责任必须落到人这一条不因工具进步而改变。顺带回应一个团队规模相关的常见顾虑小团队没有专职测试四道闸门配得齐吗答案是按自动化比例配——静态检查全量自动零人力、单测只覆盖核心路径少量人力、评审靠交叉互查每人看别人的、监控用现成的 APM 服务配置一次。这个配置的成本比想象中低真正花人力的只有核心路径的单测。小团队最不该做的是因为人少就跳过闸门直接上 AI 代码人越少返工对交付节奏的冲击越大闸门的性价比反而越高。结论问题不在 AI 可靠不可靠在你的闸门配不配AI 生成代码的质量是分布明确的通用模式稳定可靠业务定制需要人盯错误路径是重灾区。所以正确的问法不是AI 代码可靠吗而是我的验证体系配得上我的使用强度吗。低风险场景放手用拿满效率红利核心场景把静态检查、测试、评审、监控四道闸门拉满用制度的确定性对冲模型的不确定性。工具会继续变强幻觉率会继续下降但这套闸门逻辑在可见的周期里不会变——它本来就是软件行业几十年质量管理的底子AI 只是让它更重要了。