现在程序员的代码大多数都是用AI生成的,后面会成为屎山代码看不懂吗?

现在程序员的代码大多数都是用AI生成的，后面会成为屎山代码看不懂吗？ - BugBuster喵的回答 - 知乎

https://www.zhihu.com/question/2029155102292735529/answer/2073770486539014714

会，而且正在发生。

但是，这种新时代的屎山和我们过去十年见到的那种屎山，在表现形式上完全不一样。解决这些bug的时间成本，甚至可能比纯人工手写的旧代码还要高出好几倍。

很多人对目前行业现状的感知是有偏差的。到了今天，大厂里自动化生成代码的比例确实已经非常高。你Google在2025年第四季度的财报电话会明确说了，大约一半的代码是由智能体编写，然后由工程师来审查的。GitHub官方的Octoverse报告也显示，绝大多数新注册的开发者第一周就在用自动补全工具。结合Sonar和DORA近期的调查，整个行业里AI参与编写的代码比例哪怕没有绝对过半，也已经接近一半了。

所以，我们现在讨论的已经不是要不要用的问题，而是怎么给这种开发模式擦屁股的问题。

很多外行或者初级程序员对屎山的理解非常表面。他们觉得屎山就是缩进乱七八糟，变量名字叫a1、b2，或者一个函数写了一万行。如果你觉得这种叫屎山，那你可能会觉得AI写出来的代码简直是艺术品。AI生成的代码通常语法极其规整，缩进完美，变量命名符合规范，甚至还会贴心地给你加上规范的英文注释。光看当前这一个文件，你挑不出任何毛病，甚至看着还挺赏心悦目。

但工程语境中的系统灾难，从来不是因为缩进难看引起的。真正的灾难来自于技术债的无序积累，也就是模块边界混乱、重复实现业务逻辑、隐式依赖全局状态以及错误处理被强行吞掉。AI恰恰在制造这类深层结构性灾难上，效率高得惊人。

前几个月我们的一个核心业务线要做一个订单状态流转的重构。一个刚毕业不到两年的小伙子接了这个需求。他非常熟练地把需求文档喂给了一个高级智能体，让它去生成对应的状态机流转代码。几分钟后，几百行代码生成完毕，单元测试全绿，小伙子自己点了几下页面，功能正常，直接提了合并请求。当时负责审查的导师看代码写得很规整，注释也全，跑了下主流程没问题就批了。

三个星期后，线上开始零星出现订单状态错乱的客诉。用户明明已经付了款，但在某些特定并发场景下，订单状态却被重置回了待支付，导致系统自动触发了库存释放逻辑。

我带着几个人排查这个bug。如果是以前的人工手写代码，我大概率能猜到是哪个新手在处理并发时忘了加锁，或者数据库事务没控制好。但我去翻那段出问题的代码时，直接愣住了。

AI在生成这段状态流转时，为了让当时的单元测试通过，极其聪明地在缓存层做了一套极其复杂的异步补偿机制。代码逻辑自洽，甚至还用到了一些高级的并发设计模式。单看那个类，写得非常精妙。

但问题在于，我们公司的底层技术规范里明文要求，涉及资金状态的核心订单流转，必须强依赖底层数据库的事务一致性，绝对不允许在应用层做缓存状态补偿。AI根本不知道我们公司的这条历史规矩，它只看当前文件，觉得加个缓存能提升性能，并且能让测试跑通，就这么写了。更要命的是，那个小伙子只看了测试通过，根本没有去逐行理解这个异步补偿机制的底层设计。

为了修复这个看似简单的状态错误，我们需要重新梳理上游支付网关的回调链路，排查这套多余的缓存机制到底污染了多少个在途订单，最后还要把这套看似华丽但完全违背架构原则的代码全部删掉，老老实实按照公司规范重写一遍带悲观锁的数据库操作。

这就是为什么我一直跟组里的新人强调，无论AI工具多强大，你脑子里必须有一套清晰的分布式与数据架构底座。如果你对事务隔离、并发控制和数据一致性缺乏深刻认知，AI生成的这种隐形炸弹你根本看不出破绽。想把这些底层逻辑吃透，强烈建议去硬啃一下被称为后端架构圣经的 《数据密集型应用系统设计》（DDIA）。很多新人觉得第一遍读起来晦涩，可以搭配逐章精读资料一起看，搞清楚缓存、数据库与消息队列在真实业务里的权衡边界，才不至于在架构层面被AI带进沟里。

DDIA第二版更新，中文版以及配套逐章带读开放下载！

这就引出了我想回答你的第二个核心问题：出bug后，程序员到底要花多长时间来解决。

调试代码的时间成本，从来不是敲击键盘修改那几行代码的时间。排查一个bug的完整时间等于复现问题、定位问题、重建上下文、编写修复代码以及回归验证这五个环节的总和。

AI确实能帮你把编写修复代码的时间缩短到几秒钟，但它会把重建上下文和回归验证的时间无限拉长。

传统开发模式下，老员工写了一坨烂代码，虽然乱，但你至少知道那是个烂摊子。你自己写的烂代码，你心里至少有个隐约的心智模型，知道当时为什么那么写，比如因为赶进度，或者因为上游接口文档没给全。当你回去修bug时，你的大脑能迅速加载出当时的上下文。

但现在，这套流程变了。开发者把需求扔给AI，AI一次性修改了十几个文件。开发者看到界面能动，测试跑通，就直接合并了。这个时候，开发者对这套系统的认知是断层的。学术界把这个现象叫做理解债务。系统在跑，但没有任何一个活人脑子里有这套系统完整的结构图。

等到几个月后，边界条件触发了线上故障。原作者接到报警去看代码，他的反应和我去看一个陌生人的代码是一模一样的。他甚至会指着屏幕骂这到底是谁写的逻辑，直到查了版本控制记录发现那是他自己三个月前按回车键接受的AI生成方案。

在这个阶段，如果你问我需要花多大时间来学习和理解这个代码逻辑，我可以明确告诉你，在很多高复杂度的分布式系统里，理解和验证AI乱写的代码，其成本已经远远超过了把这块业务推倒重来的成本。

因为你面对的不是人类犯的那种常见逻辑错误，比如少写了个等于号或者空指针异常。你面对的是一种表面上逻辑闭环，但整体架构完全不符合现有系统生态的外星人代码。

AI为了解决当前的问题，最喜欢做的事情就是做加法。这一点GitClear在2026年发布的针对六亿多次代码变更的分析报告里表现得非常明显。数据显示，代码库里的跨文件函数复用率在断崖式下降，而重复的代码块和复制粘贴在急剧增加。

为什么会这样，背后的逻辑很简单。当你让AI去增加一个新功能时，如果上下文没有给足，AI很难主动去全库搜索你们公司是不是已经有一个祖传的工具类实现了类似功能。对它来说，当场给你按需写一个新的辅助函数，不仅速度最快，而且最不容易在生成阶段报错。

长此以往，你的系统里会出现五套不同的时间格式化函数，三套逻辑大同小异但入参不同的鉴权逻辑。每一个文件看过去都非常完美，但整个系统正在迅速膨胀。这种膨胀带来的不仅仅是体积变大，更是维护节点呈指数级上升。当上游的基础业务规则发生变化时，由于缺乏统一的抽象层，你根本不知道系统里到底有多少个角落藏着AI当初随手生成的同类逻辑。你改漏了一个，线上就是一场灾难。

不仅如此，AI在错误处理上经常有一种掩耳盗铃的倾向。为了让主流程跑通，为了不让类型检查器报错，它会生成大量捕获宽泛异常的代码。有些时候，它会在底层抛出异常时，直接返回一个空数组或者默认值。这种写法在测试环境简直无敌，所有的单元测试全亮绿灯。但到了生产环境，核心数据写库失败了，它不抛错直接返回成功，调用方以为流程结束了，继续往下走，最后在数据库里留下一堆无法关联的脏数据。

等你几个月后发现数据对不上，开始查日志溯源，你会发现这简直是个无底洞。表面上一切正常，但深层状态已经彻底溃烂。修复这种数据一致性bug所花费的时间，是以周甚至月为单位计算的。你要写数据清洗脚本，要订正历史数据，要补偿业务流程，这种时候，程序员流的汗和眼泪，就是当初无脑合并代码时脑子里进的水。

建议大家去深入研究一下静态代码分析工具的配置和原理。比如像SonarQube这类持续代码质量检查工具，现在已经成了拦截AI低级错误的最后一道防线。你不需要自己去肉眼找AI写错的空指针，但你必须知道怎么配置规则，让系统在代码合并前自动拦截那些圈复杂度超标或者安全规则违例的提交。

顺着静态分析这个话题，我们再往深层聊聊。现在很多研究，包括微软研究院和METR做的一些现场实验，都得出了一些看似矛盾的结论。有的实验说AI让开发提速了百分之三十，有的实验却说资深程序员用了AI反而变慢了百分之二十。

这个矛盾的根源，其实就藏在任务的复杂度里。

如果你的工作性质是写边界非常清晰的独立脚本，比如写个数据清洗的小工具，或者给已有的清晰接口写一套机械的增删改查页面。毫无疑问，AI能让你爽上天。你不需要动脑子，只要描述清楚输入输出，几秒钟搞定，测试跑通，准点下班。

但如果你是在维护一个有五年历史、几十万行代码的庞大遗留系统。系统里充满了各种因为历史原因妥协的临时兼容层，各个模块之间有着错综复杂的时序依赖。这个时候你指望AI一键生成需求代码，它大概率会给你惹大麻烦。资深程序员之所以觉得慢，是因为他们看出了AI生成的代码在全局系统里会引发蝴蝶效应。为了纠正AI偏离架构规范的写法，他们不得不花大量时间去微调提示词，或者干脆把AI生成的代码删掉一半自己重写。这个时候，原本的开发工作变成了一种让人血压升高的代码审查工作。

这其实反映了工业级研发与玩具项目之间的本质鸿沟——玩具代码只看单点功能跑通，而工业级系统看的是高并发下的吞吐、容错、数据漂移与时序约束。如果你想真正理解这种从本地Demo到工业界真实生产落地的系统设计思维，我很推荐你去读一下 Chip Huyen 的 《Machine Learning Systems Design》系统设计指南。它讲透了如何跨越从单点代码实现到复杂工业级系统架构这道鸿沟，建立起应对真实业务严苛考验的宏观架构视野。

告别本地调参：跨越工业界鸿沟的机器学习系统设计指南

DORA在近期的报告里非常敏锐地提出了验证税这个概念。什么意思呢，就是你用AI省下来的写代码的时间，并没有真正变成你的闲暇时间，而是转移到了验证环节。代码生成越快，你需要审核、测试、跑回归验证的压力就越大。

这就是为什么现在的工程流程正在发生根本性的变化。如果你的团队还在沿用三年前的那套人工结对编程或者随便扫两眼就合并的评审流程，你们的技术债会以过去十倍的速度堆积。

以前我们审查同事的代码，防的是他技术不行写错逻辑。现在我们审查代码，防的是生成工具压根不理解你们的业务常识。根据最新的开发者调查，有接近一半的受访者承认他们在提交AI辅助代码前不会去逐行仔细检查。同时又有近四成的老兵抱怨审查AI代码比审查人类代码更费脑子。

这就逼着行业进化。你看现在的GitHub，他们重点发力的方向早就不仅仅是补全代码了。他们在疯狂推进智能化的代码审查，集成各种安全漏洞扫描，甚至强制推行测试覆盖率门禁。核心逻辑就是，既然生成的源头已经快到人类管不过来了，那就必须在合并到主干之前，用机器的手段去对抗机器。

所以，面对题主的担忧，我给在座各位程序员以及技术管理者几个非常明确且直接的建议。这也是我们团队用真金白银和无数个熬夜加班换来的血泪教训。

第一，坚决杜绝黑盒式接收代码。任何人，不管是应届生还是十年老兵，只要是借助智能体大段生成的代码，提交前必须能够讲清楚这段代码的数据流向和状态变化。如果你说不清楚它底层是怎么运行的，仅仅因为测试绿了就往上提，查出来一律按照重大生产事故未遂处理。你必须强迫自己阅读代码，把你大脑对系统的理解和代码的实际运行情况同步起来。理解债务不能欠，欠了以后是要用命来还的。

第二，把测试的优先级提到史无前例的高度。这里我要推荐大家重新去翻一翻关于测试驱动开发的资料。这套理论曾经因为太费时间被很多敏捷团队抛弃，但在现在的自动化时代，它焕发了第二春。既然现在写实现代码不用你操心了，你的工作重心必须前移到写测试用例上。你把边界条件、异常分支、业务不变量全部用测试代码固化下来。只要你的测试写得足够严密，AI在里面怎么翻跟头都翻不出你的五指山。测试代码就是你控制AI这个脱缰野马的缰绳。没有测试覆盖的自动化生成，就等于在高速公路上蒙眼狂奔。

第三，重新审视你们团队的文档和架构规范。机器是不懂口口相传的默契的。过去你们可以靠老带新，靠口头交流说那个表里的状态字段有特殊含义不能乱改。现在不行了，AI看不到这些没有写在纸面上的规矩。你必须把领域知识、系统不变量、架构边界清晰地整理成机器可读的上下文。很多现代的智能体已经支持加载团队本地的知识库。你喂给它的规范越详实，它给你捣乱的概率就越低。这就要求高级研发人员必须具备极强的抽象和归纳能力。

如果你想看业内顶尖大厂到底是怎么把 Agent 技术与企业上下文、业务 API 深度结合并跑通工程闭环的，可以参考字节内部Agent手册。里面完整拆解了如何从底层架构设计、工具调用、API 集成到真实业务流中去规范和约束智能体行为。看看大厂一线在多业务场景下的全链路设计，能让你在搭建规范化上下文时少走很多弯路。

字节agent实践手册

第四，学会克制做加法的冲动，用机器清理机器留下的垃圾。既然AI容易生成重复代码，那我们就定期用自动化工具扫描代码重复率。既然它喜欢吞掉异常，那我们就通过静态分析工具全局禁用某些不规范的异常捕获写法。更重要的是，你要善于反向使用AI。它不仅能帮你写新功能，它更是梳理老代码的好帮手。你可以让它帮你给前人留下的烂摊子补全注释，让它帮你生成机械的单元测试，让它去批量替换那些废弃的接口。把原本单向膨胀的开发模式，变成边建边拆的良性循环。

在这个版块，我极度建议大家去跟进学习当下主流的持续集成部署管道的搭建。掌握如何在代码合入前自动化触发一系列的校验脚本。无论是安全扫描还是性能基准测试，只要把流水线搭建得足够坚固，就能拦截掉百分之九十以上看似完美实则致命的垃圾代码。这方面的实战经验和工具链整合能力，将直接决定一个团队在未来十年的研发效能。

现在大多数人写的代码，含机量的确极高。如果不加以限制和改变现有的工程管理模式，这些代码一定会变成人类完全无法维护的新型屎山。当这种结构性灾难爆发时，程序员需要花费的时间将是灾难性的，因为他们不仅要面对bug，还要面对自身对系统认知的全面丧失。

但这是悲观的终局吗，完全不是。新工具带来的挑战，终将由新规范来解决。那些只知道按回车键、不愿意深入理解系统架构的敲字员，确实会被这种新型屎山彻底埋葬。而那些懂得运用系统工程思维、牢牢把控架构边界、用严苛的自动化验证体系去约束生成代码的工程师，不仅不会被淘汰，反而会因为能够驾驭更庞大的系统而获得史无前例的价值放大。

代码生成的成本确实已经无限趋近于零，但这恰恰意味着，决定业务生死的设计能力、系统理解力和严格的验证把控能力，正在变得无比昂贵。这就是目前的真相，直白且残酷。拥抱变化，重塑工作流，才是我们唯一的出路。

编辑于2026-08-20 23:23