最近朋友圈和群里，几乎天天有人晒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 >= 1，pageSize <= 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 当工具使，而不是当替身用，这条路我自己踩过坑，也希望大家走得更稳。
