1. 先说说能跑这个最低标准有多不靠谱我以前刚用AI辅助编程的时候判断标准特别简单粗暴程序能跑起来就算完事。后来线上出过一次事故凌晨两点被叫起来回滚——AI生成的代码逻辑跑通了一条主链路但那条主链路刚好绕过了所有异常分支数据校验形同虚设上线四小时后全量脏数据入库。那次之后我花了不少时间琢磨一件事AI写完代码后到底在什么条件下我们才敢在验收单上签完成两个字先说结论代码能运行和完成之间隔着的距离大概相当于菜能入口和这桌菜能摆上宴席之间的距离。功能跑通只是起点后面还有边界条件、异常路径、资源释放、兼容性、可维护性、安全合规一长串关卡。而且AI生成的代码有个比较隐蔽的特点——它在正确路径上往往写得特别顺手因为训练语料里大量示例都是理想输入、理想环境但真实业务里的脏数据、超时、并发、配置缺失AI并不会天然替你兜住。这篇文章我不会去讨论某个具体模型的好坏而是想把我自己实践下来的一套验收流程拆开讲清楚。这套流程的核心问题是AI写完代码怎样才算真正完成我把它拆成了五个层次从功能跑通到人机协作边界每一层都有对应的检查手段和翻车教训。不管你是刚接触AI编程没多久还是已经在团队里推AI辅助开发这套验收框架应该都能用上。2. 功能的完成只是一层皮核心链路之外全是盲区2.1 主流程跑通之后真正的活才刚开始很多人在AI辅助编程时的做法是给AI描述需求拿到代码跑一遍主流程看起来没问题就收工了。这个流程我自己也走过而且翻过车所以现在我对主流程通过这个结论保持高度警惕。请先记住一句话AI生成的代码在演示路径上的可靠程度要显著高于它在非演示路径上的可靠程度。原因并不复杂——训练数据里的代码示例绝大多数都是展示这个功能怎么用而不是展示这个功能在各种极端条件下怎么不崩。所以你让AI写一个文件上传接口它通常会把正常文件传上去的路径写得很顺但文件格式错误、文件名超长、上传中断、磁盘空间不足这些情况AI可能压根没考虑。我给自己定了一条强制规矩AI写完代码后第一轮评审不看成功路径专门挑失败路径来审。具体来说我会拿着代码问自己几个问题如果输入参数为null、空字符串、超长字符串代码会怎样如果外部接口超时或返回非预期格式这段代码是否做了防御如果并发请求同时进来共享资源会不会被踩坏如果中间某一步失败了前面已经做的操作能不能回滚这些问题拿给AI生成的代码一测往往会找出不少漏洞。有次我让AI写一个批量导入功能主流程一次通过但当我故意往Excel里塞了一行缺列数据时代码直接抛了个裸异常出来错误提示还是英文的堆栈信息用户完全看不懂。这要是直接上线客服电话会被打爆。2.2 用破坏性测试清单来验收功能完成度我自己整理了一份破坏性测试清单每次AI写完代码我会按着清单逐项过全部过了才算功能层完成。这份清单干掉了不少看起来能用、实际一碰就碎的代码检查维度具体测试手段常见翻车点输入边界传null、空集合、超大值、超长字符串AI没做参数校验直接NPE或栈溢出异常链路模拟外部接口超时、返回空数据、返回脏数据异常被吞掉或裸抛没有兜底逻辑幂等性同一个请求重复提交两次重复插入数据没有去重机制并发安全多线程同时操作共享状态共享变量没加锁数据互相覆盖资源释放连续调用多次观察连接数、内存占用文件流、数据库连接没关闭泄漏可恢复性处理到一半进程重启观察数据状态没有事务半截数据永久残留这套清单的执行成本其实不高把测试脚本写好后每次AI交付代码跑一遍就行。但它对完成的定义会瞬间拉高一截——你会发现AI产出的代码里能一次通过所有检查项的比例远远低于想象。另外还要说明一点破坏性测试发现问题不代表AI这轮工作就是失败的。AI编程本身的定位就该是快速生成主体骨架处理常规逻辑把这些盲区补齐这部分工作恰恰是人机协作里人要做的最重要的事情之一。功能层的完成应该定义为主流程顺畅边界受控失败可预期三者同时成立才算数。3. 代码质量关AI产出能否体面地交到下一任手里3.1 可读性、可维护性与AI的训练集惯性功能层过了很多人就觉得完成度已经很高了。但真正在团队里干过活的都知道代码是写给人看的顺带让机器执行。AI生成的代码功能正确了但可读性和可维护性可能一塌糊涂。让我说几个实际遇到过的情况第一命名惯性。AI偏好使用非常通用的命名比如data、result、temp、item。单独看每一行都对但整个函数读下来你完全不知道这个data到底是什么数据。第二函数长度失控。AI有时会把一个很长的流程怼进一个函数里几十行甚至上百行里面夹杂着各种if分支。功能上没错但维护的人想改一点逻辑得先花半天时间理清它到底干了什么。第三过度设计。有时候AI会生成一些根本没用到的抽象层——接口、策略、工厂全套上齐但实际调用方只有一处纯属把简单问题复杂化。这些问题的根源恐怕跟训练数据有关——AI学的是海量开源仓库里的平均写法而不是你所在团队的编码规范。开源代码里命名随意、函数冗长、注释缺失的案例并不在少数AI只是忠实地把这种平均风格复刻出来了。所以我在验收时新增了可读性评审这一步。标准很简单粗暴我会找团队里另一个没参与这个需求的人让他只看代码、不看需求文档然后问他这段代码大概在干什么。如果他完全说不出来那这段代码无论功能多正确都得让AI重写或者人工重构。因为代码真正的价值在于它要被人持续维护如果只有写它的人或者生成它的AI能看懂那它就是个定时炸弹。3.2 我整理的可维护性打分卡为了减少我觉得行这种主观判断我后来做了一张可维护性打分卡每次AI交付代码后逐项打分低于某个分值就进入返工流程。分享给大家参考命名意图清晰变量名、函数名能直接说明用途满分10分函数单一职责一个函数只做一件事可读性高满分10分注释适度复杂逻辑有注释冗余注释不出现满分10分重复代码比例抽公共逻辑合理不大量复制粘贴满分10分模块依赖方向清晰高层模块不反向依赖底层细节满分10分错误处理统一有统一异常规范不是到处catch又吞掉满分10分我的个人经验总分低于35分的代码直接返工——让AI重写或者自己重构别抱着能用就行的心态留着。因为代码债务是会利滚利的每次在上面改需求都要额外交一遍理解费。而如果是在AI辅助环境下这个返工成本其实很低你只需要把评分结果和具体要求重新喂给AI让它按规格重写通常一轮就能明显改善。这里也分享一个小技巧如果AI写出来的函数过长你与其笼统说给我拆成小函数不如给它具体的拆分指令比如把数据校验部分抽成独立函数返回错误码而不是抛异常。给AI限定职责边界和输出契约效果远好于让它自由发挥。AI是很诚实的执行者你指令里的约束越具体它的产出就越可控这一点贯穿整个AI代码验收流程始终。4. 边界与安全性AI代码翻车率最高的三个区域4.1 安全校验缺失AI默认信任所有输入AI生成代码的安全性我自己是持保守态度的。不是说AI一定写出漏洞而是它在安全意识上的表现不够稳定——尤其在对输入数据的信任程度上。AI默认倾向于假设输入是正常的而真实世界的输入什么鬼样子都有这中间就出现了明显落差。具体来说SQL注入、路径穿越、越权访问这几类问题如果需求描述里没有明确提及AI几乎不会主动防御。有次我让AI写一个根据用户ID查询详情的接口它直接拼了个字符串SQL出来参数原封不动怼进去。我拿?id1 OR 11一测全表数据全出来了。这种代码不能说AI写得错但从交付标准看它离完成差着十万八千里。所以我在验收清单里加了一条硬性环节安全检查。不是让你拿它当专业渗透测试工具用而是至少覆盖这几个基础项——所有外部输入是否经过校验和白名单过滤SQL查询是否使用了参数化方式文件操作中用户可控的路径是否做了约束越权场景A用户能否操作B用户数据敏感信息是否被写入日志这五类问题用AI生成代码时出现的概率相当高。每轮都要人工过一遍别省。4.2 并发与资源竞态训练语料里最稀缺的样本另一个AI代码翻车的高发区是并发与资源竞争。我可以负责任地说AI在单线程、顺序执行的代码上表现得相当靠谱但一旦涉及多线程、分布式、共享状态它产出的代码经常在看起来对和实际有竞态条件之间飘忽不定。举个例子。有次让AI写一个库存扣减的逻辑它给出的第一版代码是if stock 0: stock - 1这种先检查后操作模式。单线程下没有任何问题但一旦放到并发环境里两个请求同时通过检查、同时扣减库存就变负数了。这属于最经典的竞态条件——check-then-act。AI并不是不懂并发问题但它的训练语料中教科书式的、正确演示并发控制的代码占比远低于顺序执行的示例所以它在常规需求下默认给出顺序逻辑的概率非常自然。针对这类问题我的验收手段是主动制造竞争。写一个多线程并发调用的压力测试比如同时发起20个请求去扣库存然后检查最终数据是否仍然一致。过不了就让AI修改并且要在提示词里明确给出约束方向例如使用原子操作或者数据库行锁保证扣减一致性返回错误码如果库存不足。你给它指明道路它通常能交出正确的代码。你不给它方向它大概率会再给你一版看起来合理但经不住并发考验的逻辑。4.3 配置与依赖管理跑不起来的主要原因第三类高发问题不在代码本身而在代码之外的配置和依赖管理。AI写代码时往往会假设某些库已经装好了、某个配置文件已经存在了、某个环境变量已经设置了——因为它在训练语料里看到的项目前提条件都是齐备的。而你的实际项目环境可能缺东少西。我遇到过的真实案例AI生成了一段调用第三方支付SDK的代码跑起来直接报NoClassDefFoundError查了半天发现漏引了一个依赖包。还有一次AI在代码里使用了某个新特性而项目当前的运行时版本根本不支持一运行就语法报错。这些问题不会出现在AI的功能自测里因为AI压根不会真正去跑你的项目——它只是生成代码文本并不会感知你的本地环境。所以我在验收流程里给环境验证单独立了一项不能只看代码对不对必须把代码拉到本地在真实依赖环境下重新构建并运行一遍。构建失败、依赖缺失、版本冲突这些都是未完成需要把具体错误信息喂回给AI让它去补或者改。你不要替AI做这个排查——你只需要当一个转述错误的人把报错信息和相关配置文件丢给它它通常能比你自己翻文档更快地找到解决方案。5. 从能跑到真完成这五道工序一字不能省到这里你可能已经感觉到了AI写代码这件事真正的核心不是让AI写出代码而是建立一套让代码能安全落地的验收流。我把它浓缩成五道工序每道工序都有明确的产出物和验收标准。只要按着这个流程走完才算真正走完了AI写完代码之后的完成定义。5.1 第一道工序需求锁场动手让AI写代码之前先把需求完整地写下来。不是那种三五行的大白话需求而是包含输入输出定义、边界条件、异常处理要求、性能要求、约束条件的完整描述。这一步做扎实了后面能少吃很多苦头。我在实践中的体会你把需求写得越清晰AI一次交出可用代码的概率越高代码返工的可能性越低。那些AI写的代码不能用的抱怨有相当一部分是因为需求描述本身就模棱两可。5.2 第二道工序单元自测AI生成代码后先不要急着接进项目里。尤其是核心算法、复杂逻辑单独拎出来写单元测试把正常输入、边界输入、异常输入都测一遍。这个过程有一个额外的好处——你在写单元测试的同时相当于对AI代码做了一次逐行审查。写测试的过程中发现这段逻辑我没有完全看懂本身就是重要的质量信号。5.3 第三道工序集成运行本地环境把代码集成进项目完整地编译、启动、跑一次真实业务流程。这一步是为了抓出代码与项目的环境不匹配问题。依赖缺了、版本错了、配置没对上都会在这里暴露出来。别跳过这步——AI生成的代码在它脑子里是运行正常的但你的项目环境才是唯一的裁判。5.4 第四道工序破坏性验证回到我前面那份破坏性测试清单把边界条件、异常链路、并发场景都过一遍。这一步没有快捷方式但可以用自动化脚本固定下来每次AI交付代码后直接跑。跑过的前几轮你可能觉得烦但当你跑到第十个AI交付的代码时你会庆幸自己有这道工序兜底。5.5 第五道工序代码评审与入库最后一步把AI生成的代码交给人类评审。评审看什么可读性、可维护性、命名、结构、是否符合团队规范。实际经验是AI代码通过这个评审的比例远低于通过前面几道工序的比例——因为AI学不会你的团队规范它只会生成平均水平的代码。你的团队规范是在实际协作中长出来的带着你们业务的血泪教训。这一步必须用人脑来判断这也是AI无法替代的关键环节。这五道工序全走完了我才会在验收单上写完成。你可能会觉得这个流程有点重但换个角度想这些工序是过去人类程序员写代码时本来就该做的事——提需求、写单测、集成、测试、评审。AI没有消灭这些工序只是把其中写主体代码这一步提了速。速度上去了质量控制反而要更严谨否则那些原本人写代码时也会犯的错误会被AI以更快的速度批量复刻出来。风险不会因为编程者从人变成AI就自动消失它只是换了一种更隐蔽的方式存在而验收的意义就是把它们挖出来、堵住。6. 我看AI编程完成度的几个实际感受讲完流程最后说几个我自己的感受。这些纯粹是个人经验不一定适合所有团队但我觉得比较有参考价值。第一AI编程最危险的心态是因为快所以松。人写代码的时候因为知道写得慢、写得贵所以每一行都会反复想但AI写代码是秒级的于是很多人的潜意识里会把验收标准也一起降下来——到处都是反正AI写得快出了问题让AI再改就是了。这种心态害人不浅。当修改成本趋近于零的时候大家就会倾向于不一次做对而是一遍遍试错。但代码改对了需求可没改业务逻辑的复杂度也没变那些出错的地方往往不是因为代码写错了而是因为需求理解错了——而需求理解错了你让AI改一百遍也没用它只是忠实反映你给的错误前提。第二AI是放大镜不是创作器。你的需求清晰度、系统设计水平、领域理解深度都会在AI的产出里被放大。需求模糊AI会给你模糊的代码边界条件没定义AI给你任性的代码错误处理策略没定AI给你随缘的异常逻辑。所以那些说AI不够聪明的人我建议先把需求文档拿出来看看多半问题出在人的这一侧。第三验收流程一定要文档化、自动化。我前面分享的破坏性测试清单、可维护性打分卡都是文档化的具体形式。为什么强调文档化因为只有写在纸上的标准才是长期稳定的标准。靠脑子记的检查项第一周记得住三个月后早就忘光了。自动化则是为了控制成本——AI生成代码的边际成本这么低如果你的验收成本高于生成成本那这套流程就不可持续。把能脚本化的检查全部脚本化让AI的代码每次提交后自动跑一遍人工只需要处理失败项这个投入产出比非常划算。如果你也在用AI辅助写代码建议从今天开始就做一件事把你认为AI起碼要做到什么程度才算完成的标准列出来写成一张checklist打印出来贴在显示器旁边。不写下来你就会被AI的速度推着走一步步滑向能跑就行的深渊。我自己踩过这个坑所以我知道这个建议值得听。写完这篇我也再复盘了一句AI对不对得起写代码这个动作其实不太重要。重要的是你有没有在它交出来的东西面前守住一个人类工程师该有的判断力和底线。只要这个守住了AI写代码这件事就撑得住——它担得起提效二字而你担得起验收二字整个闭环才算真正的完成。