1. 先聊几句AI写代码这件事我为什么会越用越慌我在某公司做了快八年的技术负责人从去年开始研发团队基本把AI编程助手当成了默认工具。新功能先让AI写一版人再改这个流程已经在好几个项目组里跑成了标准动作。前两个月确实爽本来排三天的新功能一天半就能合入迭代速度肉眼可见地提上来了业务方也很满意。但到第三个月我开始在Code Review里频繁看到一些让我后背发凉的东西——不是大段报错也不是那种一眼就能看出来的逻辑崩溃而是你说它错吧它不报错你说它对吧它哪哪都不对劲的代码。这里要先把标题里的技术债三个字说透。技术债Technical Debt不是玄学它的本质是你今天为了速度选择了省事的方案代价是未来某一天要花更多时间返工、排查、重构。欠债本身不可怕可怕的是你不知道自己欠了债或者欠了债但没有记账更没有还款计划。而AI生成代码最大的问题就是它把欠债的速度拉快了十倍。以前一个人一天手写两百行现在一天能生成两千行债务不是按代码行数增长的是按决策点增长的——每一个你没仔细看清就合入的AI分支、每一个你没验证过的接口调用都是一张借条。先声明一点我不反对用AI写代码我自己每天都在用没有这工具我现在根本扛不住需求迭代的速度。但这篇文章想说的是另一件事怎么把AI代码用成资产而不是用成负债。我会把自己实际踩过的坑、团队后来一起定的规则、以及一套可以抄走的防债流程全部摊开来讲。如果你是写代码的人、带团队的人或者刚入行、正被AI工具喂大的工程师这篇应该能帮你省掉至少几个月的返工时间。2. AI代码到底在哪儿埋雷四类最典型的技术债源头2.1 看着能跑其实跑错了逻辑边界和隐藏假设AI写代码有一个非常迷惑人的特点它生成的东西语法完全正确测试环境轻轻一点就过看起来能跑。但能跑和正确之间隔着一层东西叫边界。举个特别常见的例子。我需要一个分页查询接口当时图省事让AI按既有代码风格直接生成。它很快给我写了一个标准的分页功能参数校验、排序、返回结构都有模有样。代码Review时我只扫了一眼挺整齐就放过了。结果上线后第三天数据库CPU直接拉满排查了半天才发现AI为了计算总页数先执行了一次全表查询拿到总数又执行了一次带偏移的查询取当前页数据。在数据量只有几百条的时候这破绽完全看不出来等涨到几十万条一次分页请求要全表扫两个来回。这已经不是性能问题是核心业务逻辑的边界判断出了问题。AI生成代码时天然不会操心你的数据量级、并发量、权限模型这些隐性约束。它只是根据你给的上下文片段推断出一个看起来最合理的答案。它不会问这个表有多大不会想这段逻辑在并发场景下会不会炸。所以代码里那些隐藏假设——比如默认列表只有几条、默认字段不为空、默认单线程执行——就成了第一类雷。这类雷最阴险因为它们平时不响一响就是线上的大事。2.2 缝合怪式扩展AI最擅长把简单问题做复杂第二类雷是过度设计。很多人可能觉得AI生成代码只会偷懒恰恰相反它对复杂这件事有一种莫名的热情。有一次我让AI写一个简单的配置读取工具类需求就一句话从配置文件读取某个key的值带个默认值兜底。AI给了我将近两百行的类里面包括一个抽象接口、两个不同存储实现的子类、一个缓存策略、一个学习用的注解。我当时人都看傻了看完第一遍甚至有点自我怀疑——是不是我需求没讲清楚这个功能原来这么复杂后来在实际维护中这种缝合怪代码极难处理。因为AI经常把网上各种框架的最佳实践、设计模式、防御性编程混在一起一股脑塞给你。单独看每一段都说得通但拼在一起就是一辆每个零件来自不同厂家的车轮子能用方向盘能用但它们之间没有共同的设计语言。等到要改逻辑的时候你根本判断不了哪个部分是必要的哪个部分是AI自己给自己加的戏。这种代码最费时间因为它不是坏代码而是做了太多不必要的设计决策的代码。你要逐个拆掉才知道什么是你真正需要的。2.3 幻觉依赖不存在的API和过期用法幻觉这个词在AI圈已经不算新闻了但落到代码里它的杀伤力比自己想象得大得多。AI模型在训练语料里见过大量代码但它记住的依赖版本、接口签名、方法名很可能不是你当前项目里那个版本。我记得有次让AI迁移一段旧代码到新框架它毫不犹豫地调用了一个看起来非常合理的工具类方法。结果一编译直接报错没有这个方法。更糟的是它不是只报一处错而是好几处都引用了那个不存在的API。当时我以为是版本问题查文档、试替代方案折腾了大半天后来才发现那段代码是AI从某个旧版的示例脚本里缝合过来的那个API在三个版本前就已经废弃了。这种幻觉依赖之所以容易变成技术债是因为AI出错的方式太平均了它是从统计概率里选一个最像样的答案而不是像人一样在编写时知道某个API在当前版本是否可用。所以凡是AI涉及依赖、调用、框架集的改动都必须当成高危操作来处理。如果团队里没人有意识地去核对依赖版本和API签名这类代码会悄悄积累直到某次升级依赖的时候全面爆发。2.4 风格混乱一个人生成的东西能有八种性格最后一类比前几类讨论得少但对团队伤害一点不小风格问题。人类程序员写代码通常有自己的习惯要么遵循团队规范要么沿用文件里已有的写法。但AI没有这种延续感。你让它写一个服务它按A风格写另一个同事让它写另一个服务它可能按B风格写同一个服务里两次生成它可能一次用了函数式一次用了面向对象。这种混乱在代码量小的时候不值一提但项目到了两万行以上问题就来了新人看代码会乱代码搜索会漏代码折叠、跳转、自动重构统统失灵。更麻烦的是风格混乱往往伴随着重复代码同一个校验逻辑这个文件里写了一遍那个文件里又用另一种方式写了一遍只因为AI每次生成的思路不同两处代码长得完全不一样导致根本发现不了它们其实是同一个东西。这个问题我放在后面的防债守则里细讲因为它不是靠技术能解决的靠的是流程。3. 三个真实案例复盘AI代码是怎么一步步变成烂账的3.1 假分页的查询差点打挂数据库开头提到的分页问题后来被我当成团队反面教材讲了很多次。当时那个接口上线后PV稍微上来一点数据库连接池就告警了。我在Grafana上看到一个接口的慢查询高达三秒点进去才发现问题。AI生成的代码正确处理了当前页的数据却用了一个全表count来计算总数而那个count是实时执行的没有任何缓存。当时修这个问题的过程很戏剧化我起初以为是索引问题加了索引还慢以为是网络问题排查了很久最后翻到代码本身才发现是那行看似平平无奇的count。那一刻我有两个感受一个是羞耻因为我Review时真的放过了它另一个是后怕要是早两天上线到核心链路事故规模会更大。这事的教训就一条AI代码必须按最高风险等级来审不能因为它看起来是个常规写法就降低警惕。尤其是涉及查询、聚合、循环、状态变更的代码AI写的每行都要有性能和安全的基本判断。3.2 一个万能工具类变成了谁也不敢碰的老鼠窝另一个案例是团队里一位同事经典的AI缝合现场。他负责一个公共模块陆续让AI添加了十几个工具方法什么日期格式化、字符串截断、集合判空、脱敏处理……听起来都很正常对吧但等我去看那个类的时候已经快三千行了。更可怕的是里面有大量逻辑重复三个方法做的是同一件事只是参数类型不同一个方法里有两段几乎一样的分支只是AI在生成第二批的时候忘了第一批已经写过这个逻辑。这时候就出现了我很熟悉的人传人现象新同事接手时看这个类头大想改功能不敢动最后只能往上加新方法。没人愿意删除那些看起来有用但不知道谁在用的代码也没人敢重构因为测试覆盖根本不到位。这个类就变成了一个不断膨胀的黑洞任何人在这里改动都是负收益于是大家默契地绕开它。这就是典型的技术债变成老鼠窝的过程不是某一次灾难性故障拖垮了项目而是每一次微小的不信任感慢慢把代码的维护性磨没了。3.3 看似优雅的重构把配置中心改成了迷宫第三个案例最让我心疼因为它是好心办坏事。一个核心服务的配置项越来越多我让AI帮忙重构一下配置管理。AI给了一套方案思路很漂亮把散落的配置按领域拆分成多个配置类再通过一个统一的配置中心管理。看起来架构更清晰也确实优雅。但AI忽略了一件事这个服务的发布流程是另有一套规范的涉及灰度、回滚和多环境。AI重构出来的代码把所有环境变量、配置来源都抽象了一层导致发布平台读取的配置路径变了灰度机器一直拿不到新配置回滚脚本也失效了。那次折腾了两天最后只能把重构整体回退。这件事让我意识到一个更深的道理AI设计出来的优雅方案往往是教科书里的优雅不是你项目里的优雅。教科书里的方案默认系统是全新的、团队是理想配置的、约束是全面已知的但实际项目里有大量祖传限制老运维脚本、旧发布链路、历史接口兼容。这些信息不会写在需求和注释里AI更是完全没有感知。凡是牵一发而动全身的重构AI可以帮忙写代码片段但绝对不能让它做架构决策。4. 让AI代码不变成债务我总结的六条实操守则4.1 写Prompt之前先写边界说明书很多人在用AI的时候习惯直接甩一句帮我写个用户注册接口然后对着生成的代码改来改去。这条路必然踩坑因为AI根本不知道你的约束条件。我的做法正好反过来先花几分钟写一份边界说明书明确四件事——输入边界、输出边界、异常情况、性能要求。比如同样是写注册接口我会把这样一段话喂给AI实现用户注册逻辑。输入参数已经在校验层处理不需要重复校验用户名重复时需要返回业务错误码1002密码加密使用项目common包里的encode方法不要自己实现加密接口在500并发下平均响应时间不得超过200ms。不要额外加装饰器不要新建文件不要改配置代码风格参考同目录下UserService.java。你看这个Prompt最后出来的代码基本可以直接用因为AI没有发挥空间。它做的工作从设计与决策降级成了填空与翻译这个降级非常重要。4.2 不让AI一次性生成超过一个认知单元这个说法是我自己发明的。所谓认知单元就是一个需要人完整看懂才能保证正确的代码块。我给自己和团队定的线是AI每回生成的东西必须在三十秒内能被一个中等水平的工程师看懂。如果生成的内容超过了这个范围要么拆成多次生成要么干脆自己写。为什么定这条因为我发现AI代码出问题的概率和代码量不是线性关系而是指数关系。当它只生成一个函数时你Review一遍就够了当它生成一个完整服务、一套数据模型加一个控制器时你的注意力根本覆盖不了一百多个隐性假设。代码量一上来隐藏的边界错误、错误取舍、重复逻辑就会成倍增加。所以我现在会让AI一步一步来先生成数据模型我看了没问题再生成访问层然后生成业务逻辑最后才是接口。每一步都有检查点任何一步出现可疑模式都能立刻纠正避免一个模块里混着好几类错误事后返工。4.3 AI提交的代码必须走三个强制门这块是我觉得最值得抄走的部分。我们团队现在对AI生成的代码执行三道强制关卡和普通人工写的代码分开管理第一道是编译门AI代码合入前必须在本地跑完整的编译和静态检查。这一步专门用来拦截幻觉API、缺失依赖、过期引用。第二道是测试门必须有针对AI改动的最小测试集至少覆盖正常路径和两个异常分支。不要跟我说这只是工具类很简单不用测AI代码最怕的就是没有测试兜底。第三道是人工走查门AI提交的PR必须在代码评审里被点名标注AI生成评审人要额外关注逻辑边界、隐藏假设、过度设计这三个点。这三道门听起来很死板但它真正的作用不是拦下多少烂代码而是建立一种心理预期AI进入代码库的门槛被抬高了大家也就不再以能用就行的心态对待AI产出。有了这个预期AI代码的质量标准和人工代码对齐了债自然就少了。4.4 核心模块人工写边缘代码AI写这话可能有人不爱听但它是我们团队踩坑总结出来的真实经验技术债成本最高的地方恰恰是核心业务链路。认证、支付、订单状态机、库存扣减——这些地方只要逻辑错一次事故级别就是P0返工成本高到没法计算。所以现在这些模块我基本禁止AI独立生成最多允许AI提供代码片段做参考最终实现和合入一定是要人来完成的。反过来哪些地方适合用AI我觉得是三类一是样板代码比如DTO转换、配置文件生成、重复性模板二是胶水代码比如把现有接口拼接一下、做一个简单的适配三是探索性代码比如帮我把这段逻辑写个demo看下效果。这些代码本身价值密度不高即便出问题影响的也是局部改起来也快。用AI把这类工作接走把人的精力留给真正有价值的核心逻辑这才是AI编程工具的合理打开方式。4.5 给AI代码设立独立的技术债记账我有个很难坚持但确实有用的习惯每个月固定抽出一点时间专门review当月合入的AI代码并把其中暂时能用但将来要还的部分登记成债项。记账不复杂就是一个内部文档表格包含几列位置、问题简述、风险等级、预计修复成本、计划还款时间。举个例子某次AI生成了一段临时用的兼容逻辑当时为了赶版本直接上线了我给它记了一笔债风险中级等两个月后旧接口下线就可以删掉。当时被同事笑话说这是自己给自己找事但后面真的用上了——因为那个接口生命周期延长了如果当时没记账这段兼容代码很可能就在核心链路里躺上两三年再也没人知道它为什么存在。记账的核心价值不是把债马上还完而是让债务可见、可追踪、可排序。看不见的债才是最高利的债。4.6 团队约定人始终为代码负责最后这条守则听起来很虚但我觉得它是最重要的不管代码是AI写的还是人写的署名和责任永远是人的。一个PR标注AI generated只是用来提示评审人注意风险不是说出了问题可以甩锅给AI工具。我在团队里反复强调一句话AI是无限量供应的实习生它可以在你指挥下干很多活但所有决策责任都在你身上。有了这个共识大家在用AI的时候才会主动加校验、补测试、做Review而不是生成完粘贴就跑。技术债的根源从来不是工具而是人用工具时的心态。5. 团队管理侧技术债要记账更要排期消化5.1 把代码按资产属性分级债和资产分开技术债这个东西说起来总是负面但实际操作中要区分良性债和恶性债。有些债是值得的比如为了赶活动上线临时写一段会变丑但确定能跑通的代码风险可控用完即删。良性债可以接受。而恶性债是AI生成了你没把握的代码你没有验证就合入了之后既没有测试覆盖也没有还款计划它就这么躺在系统里成了定时炸弹。所以我建议团队在代码资产上做分级核心链路、高频路径、基础设施属于A类A类代码不允许有未评估的AI生成内容普通业务功能属于B类允许AI参与生成但要走完三道门边缘工具、脚本、demo属于C类可以放开使用AI。每个季度做一次资产盘点看B类里有没有升级成A类的代码C类里有没有悄悄长成B类体量的东西。这样债务是流动的、可管理的而不是像垃圾场一样无限堆叠。5.2 给存量AI代码设立专项清理窗口除了管理新代码旧代码里的AI债也要专门留出清理时间。我们团队的做法是每个月选一个周五下午做技术债清理窗口不接新需求专门处理之前记账的债项。这个习惯一开始阻力很大因为业务方会问这个下午为什么不排需求。后来我用一个数据说服了他们过去半年里生产环境的故障有一半以上来自之前遗留的、没有记账的AI生成代码。用一个固定半天换掉一半的故障风险这笔账非常合算。清理窗口的节奏也分享给你一次窗口只处理2到3个债项不要贪多。每次清理必须带着测试去改改完跑全量回归确保没有副作用。不要试图一口气解决所有问题一次性改动范围越大引入新问题的概率越高。这个慢慢还债的思路比大动干戈的重构日更可持续。5.3 新人培养把AI工具定位成辅助而不是拐杖最后讲一个偏文化和人的问题。团队这两年来了几个应届生他们写代码的习惯和老人很不一样遇到需求第一反应不是想逻辑而是打开AI框直接提问然后把生成的代码粘过来。有个很典型的小事有次我让一个新人改一个正则表达式他说我让AI生成一个我看不懂但我试了能跑。这句话让我很警惕。我不排斥新人用AI但我要求每个新人在合入代码时必须能回答三个问题这段代码是做什么的它为什么这么写如果出现异常会有什么后果答不上来就说明你对自己合入的东西没有ownership而这种无主代码恰恰是技术债的种子。所以我们的带教节奏是一个月内手写为主、AI为辅把基本功打牢三个月后可以放开用AI但每次生成的代码要能讲清楚。这比直接告诉他们不许用AI有效得多因为工具本身没错要培养的是对代码负责的意识和能力。6. 常见症状与排查技巧实录这篇文章写到最后我把团队在实际处理AI代码时遇到的典型问题整理成了一张排查表方便你在出现类似症状时快速定位症状可能的根因排查与对策代码风格乱、重复逻辑多AI每次生成思路不一致缺少统一约束在Prompt里规定风格参照文件定期用重复代码检测工具扫描编译报错提示找不到方法或依赖AI幻觉引用了不存在的API或过期版本核对依赖版本和API签名不要让它自己引入新的依赖线上数据量变大后接口变慢隐藏了全表扫描、无索引查询等边界问题Review时关注查询条件、索引使用、分页实现压测前先审代码核心链路偶发数据异常AI生成的并发控制、事务边界有漏洞重点Review锁、事务、幂等逻辑补并发场景测试模块越来越复杂没人敢改AI生成的缝合怪过度设计不做大重构先做代码清理和测试补齐再逐步瘦身重构后发布链路异常AI不理解项目的部署和回滚约束重构类改动必须由人来设计AI只能做片段实现新人交付质量不稳新人过度依赖AI生成缺乏理解用讲清楚三问检查强制理解后再合入再分享几个排查小技巧。第一遇到可疑的AI代码最快的办法不是一行行读而是先看它有没有多余的防御逻辑——比如明明不需要判空的地方判了空、没必要加缓存的地方加了缓存这些往往是AI自行发挥的产物删掉反而更清晰。第二用diff工具对比AI生成代码和项目里既有代码的差异重点看它是否引入了原有项目不存在的模式如果两处代码的风格明显不属于同一体系就要警惕。第三AI代码进Review时标注生成工具和生成时间这看起来像形式主义但后面排查问题时它能帮你快速判断这段代码是哪个阶段引入的省掉不少考古时间。我个人在实际排查中还养成了一个习惯对AI生成的代码默认不信任、但也不全盘否定。先跑测试再看实现再改边界最后用自己的话把这段代码重写一遍甚至两遍——这个过程虽然费时间但它恰好是理解代码、发现隐患的过程也是把人脑和AI对齐的过程踩过几次坑之后你会发现多花半小时Review比线上多熬三小时强太多了。7. 一点个人体会这篇文章没有别的意思就是把我这一两年看到的、踩过的、想明白的东西记录一下。我从最开始对AI代码的新鲜狂热到后来Review时各种不放心再到现在形成一整套可操作的流程中间经历了很多次教训。最想告诉大家的是AI写代码的速度是巨大的效率红利但这个红利只有在你心里给它划清了边界、设好了护栏之后才拿得稳。别把AI当成闭眼签字的自动完成机把它当成一个能力很强但经验不足的协作者设定规则、明确责任、定期还债那些看起来又快又爽的代码才能真正变成明天的资产而不是明天的债。