最近朋友圈和群里几乎天天有人晒AI写代码的成果十分钟拼出一个接口、一句话生成整个页面、报错信息贴进去直接吐出补丁。坦白讲我也在这么干确实快。但真正让我警惕的是 Code Review 时看到的AI味代码越来越多——格式工整、注释齐全、一眼看过去特别专业可一旦进入维护流程改一处崩三处问 AI 当时为什么这么写它只会告诉你这是常见模式。这篇文章不打算讨论 AI 写代码到底好不好用而是想扎扎实实聊一件事怎么避免 AI 当前的产出变成明天必须加倍偿还的技术债。1. 先认清技术债从哪来AI 代码的三个病灶1.1 AI 代码看着干净其实是精致的模式缝合很多团队现在对 AI 代码的第一印象是质量不错。这很正常因为 AI 生成的东西在格式层面几乎无可挑剔缩进对、命名风格统一、注释也补得整整齐齐。但这里藏着一个假象——AI 本质上是超大规模的模式补全器它擅长的是统计上最可能出现的写法而不是当前业务里最合理的写法。举个例子。你让它写一个订单查询函数它大概率会先拼where user_id ?再order by create_time desc然后分页。单看这个写法十有八九是没问题的。但它不知道你的订单表其实有软删除逻辑不知道已取消状态根本不该出现在列表里也不知道下游接口对返回体有 5 秒超时的硬约束。它只是把公开代码仓库里出现频率最高的片段搬过来再按你补全的上下文做局部适配。这个过程的本质是缝合AI 把业务逻辑当成一段统计上的概率文本去生成而不是当成一个有约束的系统去设计。所以它产出的代码大多数时候是表面干净、内在昂贵——它替你省掉了语法层面的低级错误却把业务语义层面的判断题留给了你。更麻烦的是这种代码从结构上看起来又是合理的于是很容易通过普通的人工 review直到改动需求和排查线上问题的时候才暴露成本。注意看到 AI 生成的代码先问三个问题它知道这条业务规则吗它处理了哪些异常路径它留下了什么隐含假设如果三个问题的答案都是不知道那这笔债已经记到账上了。1.2 技术债的三个层级语法债、结构债、语义债传统意义上大家聊技术债多半指的是代码烂、没注释、逻辑绕。但 AI 代码的技术债更值得用三个层级去看债的类型典型特征通常暴露的时点语法债编译告警、坏味道、显而易见的低级问题合入前就能发现结构债模块耦合、重复代码、抽象位置放错第一次需求变更时开始发作语义债业务含义理解偏差、隐含假设错误数据异常或线上故障时集中爆发语法债在 AI 生成的代码里其实很少见它训练得太充分了。真正危险的是结构债和语义债。结构债会让你的下一次改动拆东墙补西墙语义债则会让你在某个深夜发现AI 理解的订单状态流转和你业务里实际定义的订单状态流转根本不是一回事。我见过一个很典型的语义债案例有人让 AI 帮忙生成一个金额统计函数AI 直接用了浮点累加理由是统计常见写法就是这样。结果线上汇总数据偶尔差几分钱排查了半天才找到问题是 0.1 0.2 这类浮点误差。这绝不是 AI 写不出来定点运算而是它没有意识钱这个业务概念背后需要什么样的技术约束。它缺的不是代码能力是上下文。所以管理 AI 代码的技术债核心不是盯它生成的那一屏代码而是要盯住它不理解业务这个根因。2. AI 代码的典型病灶我在 Code Review 里最常看到的问题2.1 命名迷惑满屏的 temp、data1、result2命名这事AI 的表现在局部合理、全局拉胯。局部看它给变量起的名字通常还算通顺但一旦上下文稍微复杂变量就会退化成a、b、tmp、res这类无信息量的词。我在实际 review 里看到过这样一段补全const a await getUser(uid) const b a.orders const c b?.[0] sendNotify(c)代码本身能跑阅读时却需要一路追着 a、b、c 的赋值关系去猜含义。更麻烦的是这种命名习惯会被 AI 当成上下文里的风格持续复用。如果你是先写了几行缩写风格代码再让 AI 补全它会把整块代码都带进缩写泥潭。我的处理习惯是在生成 Prompt 里明确要求变量名必须能从名字直接推断含义不允许出现 single、temp、data1、result2 这类命名。生成之后做一轮本地扫描凡是命名模糊的让 AI 重写或者手工重命名。这个环节看起来很琐碎但它是防止结构债扩散的第一道闸门——因为后面所有业务逻辑的讨论都得建立在能看懂变量在干嘛的基础上。2.2 一次性抽象与过度设计并存另一个让我皱眉的 AI 代码特征是抽象倾向不稳定。有时候它极度保守一个函数里塞了 200 行如果条件分支是往左就一路顺着往下写完全不肯拆但反过来一旦你给它一点设计模式的暗示它又会开始疯狂输出——Builder、Strategy、Observer 全给你安排上给一个只需要两个判断的场景硬套三层层级结构。这两种极端都会制造技术债。过度保守的代码问题在于下一次改动时找不到合适的插入点只能继续往下堆过度设计的代码问题在于引入的抽象骨架比实际逻辑更耗维护成本新人在里面绕半天找不到真正干活的代码。我判断抽象是否必要只用一条标准这个抽象在没有 AI 的情况下我是否愿意为它多花两行调用代码如果答案是不愿意那就先把代码平铺着写。抽象是重构过程中生长出来的不是生成阶段一次性设计出来的。让 AI 写一个非常直接、非常笨的版本换个角度反而是可控的——因为一个直接版本出问题肉眼立刻能看出来一个充满了抽象层的版本出问题定位本身就成了项目。2.3 快乐路径综合征默认输入合法、网络正常、下游可用AI 生成代码习惯性地聚焦主流程。它默认用户传参是合法的默认接口返回结构是对应的默认网络不会断默认下游服务不会超时。我把它叫快乐路径综合征。最典型的表现是空值处理和安全边界缺失。让 AI 写一个根据用户 ID 查信息的函数它很少会在入口处判断 user 是否为 null让 AI 写一个 HTTP 调用它通常只处理200对401、429、500的态度是抛个异常就算完了。这些场景在教科书 demo 里无所谓在真实生产环境里却是基础素养。所以我在团队里立了一个规矩凡是 AI 生成的代码必须人工补三组测试和判空逻辑——空数据、异常值、超时/重试场景。AI 擅长为你搭起主看台但地下管网的活儿现阶段还是得人类来。这一步偷懒等于直接把故障隐患送进生产环境。2.4 重复代码与上下文割裂改了一个忘了另一个AI 生成的代码还有一个很容易被忽略的问题它没有全局记忆。今天在这个模块生成一个工具函数明天在另一个模块里它可能又生成一版功能几乎一样的工具函数。两版可能有点细微差别也可能一模一样但彼此完全独立。这种重复非常恶劣。表面上看起来只是有点冗余实际上它给后续维护挖了一个隐形坑——以后业务逻辑要改你很可能只记得改了一处而另一个重复实现仍然保留旧逻辑于是 bug 就成了薛定谔的 bug测试时看运气。尤其在比较大的代码库里AI 的重复代码很难被 review 出来因为两个文件之间的距离太远人眼根本不会把它们放在一起对比。我的应对方案是要求 AI 在生成前先查找现有代码Prompt 里带上先搜索仓库里是否存在同名或功能相近的函数如果存在就引用它。更重要的是把重复代码检测接入持续集成流程让机器来盯这个事人是真盯不过来。3. 把AI 产出改造成工程资产一套可落地的实操流程3.1 写 Prompt 时要输入业务规则输出边界约束很多人的 Prompt 只有一句话写一个订单列表接口。 这样写没问题但 AI 对业务约束的感知几乎为零。建议把 Prompt 当成一份迷你需求文档来写至少包含四块输入参数及其校验规则、核心业务流程、异常路径处理、明确禁止事项。我常用的写法是请实现一个获取用户订单列表的函数要求 - 入参userId、page、pageSize - 校验page 1pageSize 100不合法时抛参数异常 - 只返回 status paid 或 shipping 的订单 - 分页结果空时返回空数组不要返回 null - 不要修改传入对象不要引入新的第三方依赖 - 变量名要从名字直接看出含义你看不做什么往往比做什么更能约束 AI 的发挥空间。它可以帮你避开很多隐性坑不修改传入对象避免了副作用问题不引入新依赖避免了依赖膨胀分页空时返回空数组避免了下游到处判 null。这一通操作下来生成结果的质量起点就高了很多。3.2 生成之后的第一道自检逐行传话测试我自己有一个很笨但有效的习惯AI 生成代码后不急着合入先自己逐行讲一遍这段代码在干嘛。做法很简单——打开代码文件拿一支虚拟的讲解笔对每一行问三个问题这行代码读到了什么数据它把数据变成了什么它把数据送到了哪里如果某个函数我看着看着发现自己没法用一句话讲清楚它的职责就说明它该拆分了如果某个变量在传入之后被改了三次那就要重点检查它是不是被当成了共享状态。这个传话测试本质上是一次廉价的模拟评审。它不花钱、不占用人手但能抓住一大批 AI 代码里的隐性雷区。我见过很多 AI 生成的代码单独看每一段都成立但连起来执行时数据流会悄悄偏离原意——恰恰是这种局部成立、全局走样的代码最需要人工逐行过一遍。3.3 测试先行把回归成本压下来AI 代码最大的特点是生成快但验证慢。它一小时可以给你写出几千行代码你测试和审查的时间可能是它的十倍。这不能靠意志力硬扛要靠机制化解。我的建议是三步策略。第一步生成代码前先把核心业务场景的测试用例写好——哪怕测试还是红着的第二步让 AI 生成的代码负责把它们跑绿第三步当 AI 的输出出现版本迭代时比如你让它修复一个 bug把 bug 对应的用例固化进测试集防止它下次又把同样的错误写回来。测试覆盖率方面我的一个参考标准是核心业务模块行覆盖不低于 80%分支覆盖不低于 70%。这个数字不是拍脑袋定的而是基于我的实际经验——低于这个门槛AI 生成代码的回归风险会成倍上升。测试的价值不是测给领导看的而是给未来所有 AI 代码变更装一道护栏改坏了测试会先替你报警。3.4 小步重构从能跑到能维护AI 生成的代码第一版通常都只是能跑离能维护还有距离。所以生成之后的重构动作应该是一个单独步骤而不是生成阶段的事。我比较推荐小步重构一次只做一种操作做完立刻跑测试。比如第一轮只重命名变量让整个函数读起来像自然语言第二轮只抽分核心分支把主流程和异常路径分开第三轮再处理重复代码把已经存在的工具函数替换掉。千万别一次性把 AI 生成的代码大改特改——结构债叠加上人工重构的误操作会在短时间内制造出更大的混乱。重构的本质是让代码结构逐步接近组织对业务的理解它是慢功夫。有句话我特别认同AI 帮你写出第一版人类负责把它磨成能长期维护的样子两者的分工本来就不该混在一起。4. 工具与规则组合让 AI 代码交出一份体检报告4.1 静态检查不是摆设复杂度、重复度和覆盖率一起看应对 AI 代码人工审查是起点工程化手段才是长期防线。我把工具检查分成三个维度静态质量、重复度、覆盖率。静态质量检查不用追求复杂把常规的 Lint 规则全部打开就行。重点要看的指标是圈复杂度——如果 AI 生成的某个函数圈复杂度超过 15基本可以断定它塞了太多逻辑该拆了。重复度检测则用来揪出一个工具函数在三个地方各写一遍的问题很多时候 review 发现不了但机器扫一遍全暴露。覆盖率工具则是测试体系的哨兵告诉你到底有多少代码是被验证过的。我的做法是把这个三个维度全部接到持续集成流程里作为合并代码前的强制门禁任何 AI 生成的代码如果静态检查告警不清零、重复度超过阈值、覆盖率不达标直接挡在门外。这样做的好处是把AI 代码质量从个人自觉变成了系统约束——你不需要靠每个人 review 时都瞪大眼睛机器本身就提供了基础保障。4.2 一份可落地的 AI 代码审查清单光有工具还不够人工审查时最好有一份清单避免漏项。下面这份清单是我自己团队在用的核心思路是围绕 AI 最常犯的错来设计检查项审查项重点看什么命名可读性变量、函数是否一看名字就懂有没有 temp/data1 这类词空值与非法输入入口是否判空、参数范围是否校验、下游返回值是否判 null超时与重试外部调用是否有超时设置是否对瞬时失败有合理重试幂等与副作用重复调用时结果是否一致是否悄悄修改了外部状态业务假设注释和逻辑里是否藏着我认为应该这样的隐含假设重复代码新生成的功能是否与仓库已有函数重复异常路径除了主流程非 200、数据为空、类型不符有没有被处理测试配套生成代码是否配套了对应的单元测试用例这些项目不用每条都逐字核对但至少过一遍能过滤掉绝大多数 AI 代码里的典型坑。审查的关键不是流程繁琐而是有据可依。4.3 团队层面立一个AI 代码守则最后一块拼图是团队规范。技术债从来不只是个人问题它更像一种团队层面的集体默契。如果团队里 A 同学觉得 AI 代码随便改、B 同学觉得 AI 代码必须严防死守那协作效率一定会被这种认知分裂拖垮。我在团队里推行了几条简单的 AI 代码守则涉及钱、权限、数据迁移、状态流转的核心模块禁止直接使用 AI 全量生成只允许用它生成测试桩或文档注释。任何 AI 生成代码必须由原作者逐行阅读并理解后再提交禁止生成即合入。所有 AI 生成的代码分支必须在合入主分支前经过至少一人 review且 review 时标注出这段是 AI 写的。AI 修复问题后的补丁必须同时补一条对应测试用例防止回归。这几条规则非常朴素但实际落地效果很好。因为它们把 AI 代码该不该信 从个人感觉变成了团队纪律。一个团队里只要规则一致技术债的增长速度就能被显著控制住。5. 真实踩坑记录与排查思路5.1 第一个坑AI修复把事务给修没了有一次某个支付回调模块出现在高并发下偶发数据不一致的告警。团队里的人让 AI 分析原因AI 给出的建议是当前事务粒度太大建议去掉事务改用补偿机制。听起来挺合理但在这个场景里事务正是保证订单状态和数据流水一致性的核心约束。结果是按 AI 建议改完之后问题从偶发变成了常态。排查过程其实很朴素我们通过版本对比工具逐行 diff发现唯一的代码改动就是删掉了方法级事务注解。这个教训让我印象特别深AI 的建议经常在局部是优化在全局却可能是破坏。凡涉及数据一致性的核心逻辑AI 的建议只能作为参考最终拍板必须由懂业务的人做。5.2 第二个坑金额统计用了浮点差了几分钱另一个真实的教训是前面提到的浮点金额问题。AI 在生成统计函数时按最常用写法用了浮点累加单测全绿上线后数据汇总差了那么几分钱。排查时我们先怀疑数据库又怀疑接口传参绕了一圈才靠着一个加断言的单测暴露了浮点精度问题。从那以后凡涉及金额、计价、库存这类数值敏感场景我都会在 Prompt 里显式加上一句金额类数值必须使用整数最小单位禁止使用浮点数。这个习惯帮我省掉了无数个深夜告警。5.3 第三个坑循环外共享同一个对象数据互相覆盖还有一次AI 生成了一段批量处理逻辑。结构大致是先定义一个更新对象再进循环在循环里往这个对象里塞数据然后调用更新接口。乍一看逻辑没毛病但实际执行时所有数据都写到了同一个对象上循环下一次迭代直接覆盖了上一次的结果。单测通过了因为单测只跑了一条数据线上全部失败因为线上真实场景是批量。这个问题后来是靠加日志定位的打印每个批次的内存地址发现全都指向同一个对象。排查完最大的感受是AI 生成代码时的共享可变状态是一个高频陷阱它不会主动考虑并发、多实例、批量这些现实条件。5.4 排查技巧快速定位一段代码是不是 AI 写的雷最后分享一个小技巧拿到一段可疑代码先看提交信息和提交痕迹。AI 生成的代码往往带有比较统一的口吻比如提交信息写着feat: add xxx function而且一次提交里塞进了大量互相没有关联的改动。如果一段代码来自这种批量提交它大概率没有经过充分的逐行审查是技术债的重灾区。定位问题的顺序我一般是这样先用静态检查扫一轮把明显问题揪出来再用测试覆盖定位逻辑缺口最后才是人工逐行读。整个流程下来大多数问题都能在合入前暴露真正漏到生产环境的反而是少数。最后说几句个人体会用不用 AI 写代码这个选择题我早就选了用。它帮我写测试桩、搭框架、列注释这些重复工作确实又快又稳。但我也很清楚AI 当前产出的代码本质上是一个速度飞快、经验有限、不懂业务细节的初级开发者写出来的。所以我的态度是让它干活但绝不让它直接决定系统的核心逻辑。在实际操作里我会给它明确的任务边界会强制它遵循团队已有的代码风格会让静态检查、测试覆盖和人工审查组成三道防线。AI 代码本身没有原罪真正的问题在于人类放弃了本该属于自己的工程责任。再多说一句如果你对 AI 生成的代码抱着一口吃成胖子的期待建议早点放下。技术债的精髓在于利息现在省下的每一分钟审查时间最后都会在改 bug、加班、线上故障里连本带利还回去。把 AI 当工具使而不是当替身用这条路我自己踩过坑也希望大家走得更稳。