22条软件工程定律,AI每一条都在踩

2026年1月，一个开发者让Google的AI编程工具Antigravity清理项目里的node_modules文件夹。路径中有个空格——”Obsidian Vault”——shell转义失败，AI执行了一条覆盖全盘的删除命令。不可逆。P0级灾难。

出错的原因不是AI不懂代码，而是一个空格。墨菲定律说得明明白白：会出错的事情一定出错。AI只是让”一定”来得更快了。

先看看AI coding已经渗透到了什么程度。Sonar《2026年开发者调查报告》显示，72%的开发者每天都在使用AI编程工具，AI生成和辅助的代码占比已经达到42%，2023年这个数字只有6%。三年，从6%到42%。JetBrains的报告更进一步：73%的团队超过30%的新增代码由AI生成。谷歌CEO皮查伊2026年4月披露，谷歌内部75%的新增代码由AI生成，一年半前还只有25%。微软部分项目中20%-30%的代码由AI编写；Meta要求2026年上半年65%的工程师用AI编写超过75%的代码。Cursor平台每天产出近10亿个字符的AI生成代码。Y Combinator 2025冬季批次中，25%的初创公司95%的代码由AI生成。

AI coding已经不是”要不要用”的问题，而是”已经在用了”。

但速度的另一面是：CodeRabbit的研究显示，AI生成代码的缺陷数量约为人工代码的1.7倍；Snyk的报告指出，AI代码的安全漏洞发生率高出2.7倍；Google Research的盲评则发现，AI代码在并发和事务场景的正确率只有54%。技术债的积压速度达到了传统开发的2.4倍，过去一年半才形成的”屎山”，现在三到五个月就堆起来了。没有这42%的AI代码渗透率，就不会有2.4倍的技术债加速，问题恰恰出在”已经在用了”这件事上。

于是有了一种声音：AI coding最大的风险是技术债。

这话对，但只对了一半。

技术债是慢病，它会慢慢腐蚀系统的健康度，让每一次迭代都更沉重。但还有一个更急迫的风险，正在被大多数人忽略：人们以为有了AI就不需要软件工程了，工程实践本身先崩掉。技术债是利息越滚越大的贷款，抛弃工程定律是直接把地基拆了。楼不是慢慢歪的，是突然塌的。

这篇文章要说的就是这件事。22条软件工程定律，每一条都在AI时代被更快地违背、更狠地踩踏、更早地爆雷。传统开发里违背Gall定律可能两年才出事，AI coding里三个月系统就撑不住了；传统开发里Conway定律的效应是慢发酵，AI coding里一个Agent就打破了组织边界，架构跟着散架。每一条定律的”被违背周期”都被AI压缩了。

AI coding是工具，是加速器，但它加速的不只是好代码的产出，也加速了坏代码的灾难化。在错误的方向上越努力，崩溃得越快。

一、AI让你更快地写出坏代码

你第一次用AI写代码的时候，大概率是兴奋的。描述一下需求，代码就出来了。跑一下，居然能跑。那一刻你会觉得，编程的门槛真的被踩平了。但门槛低了，不代表坑少了。AI让你更快地掉进那些老坑里，而且掉得更深，因为你自己都不知道在掉。

在传统开发里，违反KISS原则通常是因为工程师想炫技，用设计模式堆砌，用微服务拆分，把一个feature flag做成独立服务，配上数据库、缓存、管理界面、WebSocket推送、A/B测试模块。结果呢？一个JSON配置文件就够了。这种事在创业公司里天天发生。

AI让这个问题变得更严重了，但原因变了。不是炫技，是”默认复杂”。你让AI实现一个功能，它不会给你最简方案，它给你”完整方案”。50行脚本能搞定的事，AI生成500行，还附赠你没要求的错误处理、日志框架、配置管理和多环境适配。腾讯混元团队度量了5万段AI代码，冗余代码率11.4%，人工代码只有4.2%。AI给的不是最简方案，而是最完整方案，而最完整往往是最危险的。

更麻烦的是，你很难让AI”简单一点”。那些多余的抽象层和”防御性设计”看起来都挺合理，直到某天你发现系统里有一半的代码在做你根本不需要的事情。

传统开发里，违反DRY最经典的案例是按代码行数发奖金，结果全公司都在复制粘贴。这不是笑话，是真事。

AI时代，复制粘贴换了个马甲。AI每次生成代码都是从零开始，它不会主动去翻你项目里已有的模块，看看是不是已经有人实现过类似功能。你在文件A里让AI写了一个日期格式化函数，在文件B里又让它写一个，它不会告诉你”嘿，这个你上次已经写过了”。它只会再生成一个，可能逻辑一样，可能略有差异，但绝对不是同一个。

JetBrains 2025年的报告给出了一个触目惊心的数据：代码重构占比骤降60%，复制粘贴代码量首次超过了迁移代码量。开发者不再把”把重复代码抽成公共函数”当作日常动作了。AI生成就生成了，能跑就行，谁还去重构？DRY原则在AI时代不是被违反了，是被遗忘了。

传统开发里的经典反面教材：用户还不到10个人的创业公司，花大量时间搭Kubernetes集群来应对百万用户。结果百万用户没来，公司先倒了。

AI让过早优化从”主动决策”变成了”默认行为”。你让AI写一个数据查询接口，它不会给你一个简单的SQL查询，它会给你加上缓存层、消息队列、分库分表策略、读写分离配置。还没跑起来呢，架构图已经画到了百万QPS的规模。AI缺乏对”当前规模”的感知，它总是按”最佳实践”生成代码，而最佳实践往往是面向大规模场景的。这跟KISS原则叠加起来尤其致命。AI同时违反两条定律，既复杂又过早优化。你拿到的是一套面向百万用户的架构，但你的用户可能只有一千个。维护这套架构的成本，远超过它带来的收益。

AI恰好是Boy Scout规则的反面。AI只写不改，每次交互都是新增代码，从不删除或简化。你让AI修一个bug，它不会去找到根本原因然后重构相关模块，它会在旁边加一段补丁代码绕过问题。你让AI加一个功能，它不会考虑现有代码能不能复用，它会在旁边新建一个函数从零实现。代码重构占比骤降60%这个数据，不只是DRY的悲剧，也是Boy Scout规则的葬礼。AI生成的代码只增不减，没人让代码比来时更好。时间一长，代码库就像一个只进不出的房间，东西越堆越多，没人清理，直到某天你想找个东西，翻遍整个房间都找不到。

AI把抽象泄漏推到了一个前所未有的高度。AI本身就是一层超级抽象，你输入自然语言，它输出代码，中间的过程是个黑盒。开发者不知道AI生成了什么，也不知道它为什么这样生成。代码能跑，但为什么能跑？出了问题从哪里查？

但这还不是最可怕的。最可怕的是”双重抽象泄漏”：你用AI生成代码，AI又用了各种框架和库来生成这段代码。你面对的不是一层抽象，而是两层。ORM的SQL抽象会泄漏，但至少你知道自己在用ORM；AI生成的代码里用了ORM，你可能都不知道，因为AI没告诉你它选了这个方案。传统开发里，抽象泄漏时你至少知道抽象下面是什么；AI时代，你可能连”这里有个抽象”都不知道。

Google Research的盲评数据给出了答案：AI代码语法通过率92%，但并发、事务、异常场景的正确率骤降至54%。这些恰恰是抽象泄漏的高发区，正常运行时一切看起来很好，边界条件一旦触发，抽象就漏了。而双重抽象泄漏意味着，你连泄漏点在哪都找不到，因为你不完全理解AI的代码，更不理解AI代码背后的框架逻辑。

AI是死代码的量产机器。腾讯混元的数据显示，AI代码冗余率11.4%，是人工代码的3倍。但冗余率只统计了”明显多余”的代码，那些AI生成的”防御性代码”，各种异常处理、边界检查、兜底逻辑，大部分永远不会被执行，但它们占着空间、增加阅读负担、拖慢编译速度，最关键的是：没人敢删。

因为你不确定删了会不会出问题。这段异常处理看起来多余，但万一某个边界条件真的触发了呢？AI生成的代码没有注释说明”为什么这样写”，只有代码本身，你甚至无法判断这段代码是”有意的防御”还是”AI的冗余”。传统开发里的死代码，你至少知道是自己写的，多少能回忆起当初为什么写；AI生成的死代码，你完全不知道它的意图，所以更不敢删。AI的”防御性代码”尤其危险：那些异常处理、边界检查、兜底逻辑看起来都很合理，但大部分永远不会被执行。这种”看起来有理的死代码”比传统死代码更危险，因为它更难识别，也更难下决心删除。

你的AI生成了一段API，返回的JSON里字段顺序是按字母排列的。你没有指定这个顺序，AI也没有声明这是有保证的。但前端同事看了返回结果，直接按顺序解析了。三个月后你让AI优化这段代码，返回顺序变了，前端全崩了。

AI生成的代码充满了这种隐式行为：响应时间的量级、错误信息的文字格式、分页参数的默认值、空值是返回null还是空数组。这些都不是显式接口的一部分，但一旦上线，就会被依赖。而AI不会告诉你”这个行为是隐式的，可能会变”，它甚至不知道自己做了这个决定。这条定律跟后面要讲的Hyrum定律是一对：Hyrum定律说的是”只要有足够多的用户，你API的任何行为都会被人依赖”；隐式接口定律说的是，AI生成的代码尤其容易产生隐式接口，因为AI不写接口文档，只生成”能跑”的代码。

2024年7月19日，CrowdStrike修改Falcon Sensor配置，导致850万台Windows设备蓝屏，全球航空、医院、银行瘫痪。一个配置修改，引发了全球级灾难。

2026年1月的Antigravity删库事件展示了AI版本的墨菲定律：一个空格。路径中”Obsidian Vault”的空格导致shell转义失败，AI执行了覆盖全盘的删除命令。一个在任何代码审查中都有可能被忽略的空格，在AI的执行链条里被放大成了P0级灾难。

Snyk的数据显示，AI生成的代码每1000行就有1.7个高危CWE，Top3是SQL注入、路径遍历和反序列化漏洞。Veracode的测试更直白：最先进的模型生成的代码中，45%存在安全缺陷。将近一半的代码有安全问题。墨菲定律说的是”会出错的事情一定出错”。AI让”会出错的事情”变多了，也让”一定出错”来得更快了。

二、AI一键生成系统时，架构定律被踩得更狠

初级程序员违反KISS，多写了几百行代码，顶多自己多维护一会儿。架构师违反Gall定律，直接生成一个复杂系统，那是一整个团队要还的债。而AI让”一键生成复杂系统”这件事变得太容易了，你不需要理解架构，不需要经历演变，一句话就够了。AI让犯错的成本降低了，但犯错的后果放大了。

这不是经验之谈，这是被无数项目验证过的铁律。Instagram的前身叫Burbn，是一个功能臃肿的签到应用，有照片、有打卡、有社交、有积分。创始人意识到太复杂了，砍到只剩照片分享，Instagram诞生了。反面的例子是Google Wave，试图把邮件、即时通讯、文档协作、版本控制全部塞进一个产品，15个月后宣告失败。一个从简单演变而来，一个从复杂直接设计，结果天壤之别。

AI时代的Gall定律危机在于：它让”从头设计复杂系统”变得前所未有的容易。你对AI说”帮我开发一个在线商城后台管理系统”，它直接给你生成用户管理、订单处理、支付集成、库存管理、数据报表的完整代码库。一句话，一个复杂系统就出来了。但Gall定律告诉我们，这样生成的系统几乎不可能正常运行。问题不在代码有bug，而在它跳过了演变过程。一个真正可运行的复杂系统，是在简单系统运行的过程中，逐步发现需求、逐步添加功能、逐步调整架构，每一步都有真实用户反馈作为校准。AI跳过了所有这些校准，直接给你一个”看起来完整”的系统。看起来完整和真正可用之间，隔着无数个迭代周期。

这正是Vibe Coding（氛围编程）的核心问题。Andrej Karpathy在2025年初提出这个概念，用自然语言模糊描述驱动AI快速生成代码。2025年《柯林斯词典》年度词汇，风头无两。Vibe Coding的产物就是Gall定律的反面：没有简单系统的起点，没有逐步演变的路径，只有一句话和一个复杂系统。

但Vibe Coding的问题不只是”跳过了演变”。更深层的是它的根本矛盾：用自然语言的模糊性去驱动代码的精确性。你说”做一个商城”，AI理解的可能跟你完全不同。你想要一个简单的二手书交易平台，AI给你生成了一套企业级电商中台。你不会知道这个理解的偏差，因为AI不会跟你确认”你说的商城是哪种？”它只会生成。而Gall定律要求的”从简单系统逐步演变”，每一步演变都是一次理解的对齐。用户用了一版，反馈了问题，下一版针对反馈调整。Vibe Coding跳过了所有对齐，直接从模糊跳到了复杂。

所以2025年下半年，行业开始转向Spec Coding（规约编程），先产出结构化、零歧义的规格文档，再让AI根据规格生成代码。GitHub Copilot Workspace推出了”计划模式”，强制AI在生成代码前先产出详细实施计划；Anthropic强调”显式约束”，为模型提供严格的工具调用规范和环境限制。2026年初，OpenAI和Anthropic进一步提出Harness Engineering（驾驭工程），构建约束系统让AI自主可靠执行，人类设计”马具”。从Vibe Coding到Spec Coding再到Harness Engineering，三者的演进方向本身就是Gall定律的回归：不是一步到位，而是逐步约束、逐步演变。

Conway定律不是”可能如此”，是”必然如此”。因为系统的边界，本质上是人与人之间沟通的边界。跨团队的协作成本高于团队内部，所以人们自然会把需要频繁协作的功能放在同一个模块里，架构就这样被组织结构塑造了。

Amazon是逆向运用Conway定律的典范。他们不是让架构被动反映组织，而是先设计想要的架构（微服务化），再重组团队来匹配（每个微服务配一个小团队，即”两个披萨团队”）。这叫”逆向Conway播种”，先想清楚要什么样的系统，再搭建什么样的团队。

AI时代的Conway定律危机在于：AI Agent打破了组织边界，但组织结构没变。一个AI Agent可以同时写前端、后端、数据库代码，跨越了原本需要三个团队协作的边界。听起来很高效，但你的团队还是按前端、后端、数据库分的。AI替你”跨团队”开发了，但没有人来维护这些跨边界的代码。出了bug，前端团队说”这是后端的事”，后端团队说”这是AI生成的”，数据库团队说”我们不知道有这个表”。架构跟着散架，因为组织结构和系统架构脱节了。AI打破了边界，但没有人建立新的边界。

最经典的案例是SimCity。这款游戏在Windows 3.x上有一个use-after-free的内存漏洞，它释放了内存之后还在继续使用。但Windows 3.x的内存管理器不会立即回收释放的内存，所以游戏运行得很好。Windows 95改进了内存管理，会立即回收释放的内存，SimCity就崩了。微软的解决方案？专门为SimCity设计了一个特殊的内存分配模式，如果检测到SimCity在运行，就回到旧的行为。SimCity的bug成了Windows的”功能”。

AI时代的Hyrum定律被加速了。AI生成的代码没有接口文档，用户只能依赖”实际行为”，API的响应时间、错误信息的格式、JSON字段的顺序、分页参数的默认值。这些都不是显式契约，但一旦上线，就会被依赖。而AI代码的”怪癖”比手写代码多得多，因为AI不知道哪些行为是”有意的”哪些是”偶然的”，它只是生成了能跑的代码。更危险的是速度。传统开发里，Hyrum定律的效应需要时间，用户慢慢发现并依赖你的隐式行为，这个过程可能持续几个月甚至几年。AI时代，代码以从未有过的速度被部署和上线，隐式行为被依赖的速度也跟着加快。你今天生成的代码，明天可能已经有人依赖了它的某个”怪癖”。

AI时代的CAP定理危机在于：AI不会替你做这个取舍，但它会替你假装这个取舍不存在。你让AI生成一个分布式系统的代码，它不会问你”如果网络断了，你是要一致性还是要可用性？”它只会生成一段代码，而这段代码背后隐含了一个选择，通常是默认”网络不会断”，完全忽略分区容错。AI不做架构决策，但它会替你假装不需要决策。而假装不需要决策，本身就是最危险的决策。Google Research的盲评数据印证了这一点：AI代码在并发和事务场景的正确率只有54%。这些正是CAP定理最关键的决策点，AI没有做决策，它只是假装不需要决策。

AI违反接口隔离原则，是默认行为。AI倾向于生成”万能接口”，一个API返回所有字段，一个服务暴露所有方法。因为对AI来说，生成一个大接口和生成三个小接口，工作量是一样的，但一个大接口”看起来更完整”。它不会问”调用方真的需要所有这些吗？”它只会把能想到的都给你。

一个真实的场景：团队让AI生成一个用户信息API，AI返回了50多个字段，基本信息、登录历史、支付记录、权限列表、操作日志、偏好设置，全塞在一个响应里。移动端只需要用户昵称和头像5个字段，却被迫解析50多个字段的JSON。某次后端把”用户状态”字段的类型从整数改成了字符串，一个看似无害的变更，移动端解析崩溃，因为客户端代码里对这个字段做了整数运算。如果接口是隔离的，移动端只依赖自己的5个字段，这个变更根本不会影响到它。这跟DRY原则的违反叠加起来更糟：AI既在不同地方重复生成相似代码，又在同一个接口里塞入过多功能。代码既冗余又臃肿，维护成本双倍。

AI时代，单一职责原则被踩的频率和烈度都上了一个台阶。AI不理解”职责”这个概念，它理解的是”功能需求”。你让AI”实现订单处理”，它会在一个函数里塞入订单验证、库存扣减、支付调用、物流通知、邮件发送。对AI来说，这些都是”订单处理”的一部分。它不会主动思考”这些是不是应该拆成不同的服务？”

这种耦合爆雷的速度比想象中快。一个真实的场景：某团队让AI实现用户注册功能，AI生成的注册函数里包含了邮箱验证、权限初始化、欢迎邮件发送、数据同步到CRM系统。看起来很完整，注册嘛，确实需要这些步骤。但两个月后，市场团队要改欢迎邮件的模板，开发者改了邮件发送的代码，结果权限初始化的逻辑被意外影响，新注册的用户全部获得了管理员权限。原因？AI把邮件发送和权限初始化放在同一个函数里，共享了一个状态变量。改邮件模板的时候，这个变量被重置了。如果注册函数只负责注册，邮件发送是独立服务，权限初始化是独立服务，改邮件模板根本不可能碰到权限逻辑。单一职责原则是防火墙：职责混在一起时，改任何一处都可能点燃另一处。

AI时代，”惊讶”的来源变了，而且变得更加隐蔽和危险。AI生成的代码语法正确，但逻辑可能完全出人意料。你让AI写一个数据查询函数，它生成了异步代码，但没有标注async，也没有在函数名里体现。调用方以为这是同步调用，直接拿返回值用，结果拿到的是一个Promise对象。运行时没报错，但数据全是undefined。你排查了半天，才发现这个函数是异步的，AI觉得异步”更高效”，就自作主张了。

你让AI写一个简单的缓存函数，它在里面埋了一个定时任务，每隔5分钟自动清理过期缓存。你不知道这件事，直到某天线上出现间歇性的性能抖动，每5分钟一次。你花了一整天排查，最后发现是AI在缓存函数里加了一个你从未要求的定时器。

这些”惊讶”有一个共同特点：代码能跑，但行为不是你想要的。而AI不会告诉你”我做了这个决定”，它只是做了。AI生成的代码最危险的地方，是你不知道它做了什么。Stack Overflow 2025年的调查数据很能说明问题：84%的开发者在使用AI编程工具，但只有29%信任AI输出的准确性。那些不信任的开发者，都被AI代码”惊讶”过。语法没问题，能编译能跑，但行为出人意料，而这种”惊讶”往往在运行时才暴露，在生产环境才爆雷。

传统开发里，对抗熵增的手段是持续重构。定期清理死代码、提取公共函数、重命名变量、拆分模块，这些都是在做”减熵”的工作。mobile.de团队甚至硬性规定25%的时间资源用于减少技术债，就是在对抗熵增。AI加速了熵增，同时削弱了减熵的能力。JetBrains的数据显示，技术债积压速度是传统开发的2.4倍；代码重构占比骤降60%。一边是AI以2.4倍的速度制造无序，另一边是重构能力下降60%。减熵的速度远远赶不上增熵的速度。代码的熵增从慢性病变成了急性病，过去一年半才堆起来的屎山，现在三到五个月就成型了。

三、管理定律在AI时代的变异

AI coding给管理者制造了一个幻觉：看起来效率提升了，代码量暴涨了，AI代码占比达标了。但数字在说谎。管理定律在AI时代没有失效，而是变异了，你以为的加速，可能是另一种形式的减速。

有一个真实的案例：一个8人团队项目延期，管理层决定扩招2人。但在新人到岗的过渡期，2位老员工离职了，团队缩减到6人。结果沟通效率反而提升了，产出比8人时更高。人少了，沟通少了，干活多了。

AI时代的Brooks定律变异了：加AI Agent不等于加人，但沟通协调成本一样涨。表面上，AI Agent不需要培训，不需要熟悉项目，不需要跟人开会，它直接写代码。但问题在于，人需要审查AI写的代码。AI一天能产出2000多行代码，但PR超过500行时，人类reviewer的缺陷发现率从63%暴跌到28%。你不是在加一个帮手，你是在给自己加审查任务。AI加速了产出，但没有加速理解。

更深层的问题是：AI加速了编码，但思考、检查、修错这些串行步骤无法并行。就像那句老话：九个女人也不能一个月生出孩子。九个AI也不能一个月生出孩子。你可以让AI更快地产出代码，但你不能让人类更快地理解和验证这些代码。Brooks定律的本质没有变：有些工作的瓶颈不在产出速度，而在协调和验证。

AI时代的Zawinski定律更隐蔽了。传统开发里，功能膨胀是一个主动决策，产品经理提需求，工程师评估工作量，管理层拍板。每个人都知道自己在”加功能”，都有机会说”不”。AI让功能膨胀从主动决策变成了默认行为。你让AI”实现一个用户注册功能”，它不会只给你注册，它还会给你密码找回、邮箱验证、第三方登录、用户画像、权限管理。AI默认生成”完整功能”，而不是最小可用版本。它不会问”这个功能真的需要吗？”它只会生成。AI不会说”不”，这是它最大的优点，也是它最大的危险。Vibe Coding的典型产物就是Zawinski定律的加速器：一句话生成完整系统，功能膨胀是自动的、无声的、不可见的。你不需要做决策，功能就已经膨胀了。等你发现的时候，系统已经包含了你从未要求过的十几个功能，每一个都是维护成本，每一个都可能是安全漏洞的入口。

柏林勃兰登堡机场是这条定律的经典注脚。2006年开工，原计划2011年启用，最终拖到2020年才运营，工期从5年膨胀到14年，预算从约20亿欧元飙升到近70亿欧元，超支约3倍。规划者不是不知道项目会延期，他们已经加了缓冲时间，但实际延期还是超出了加了缓冲的预期。Hofstadter定律的可怕之处就在这里：即使你知道它会超预期，它还是会超出你的超预期。

AI时代的Hofstadter定律有了新版本：你以为AI加速了开发，但调试AI代码的时间翻倍了。Uplevel 2025年的研究给出了一个让很多人意外的数据：使用Copilot的开发者，代码出错频率反而高出41%。AI写代码快了，但写出来的代码更容易出问题，而排查和修复这些问题的时间，远超AI节省下来的时间。Stack Overflow 2025年的调查更直白：45%的开发者认为调试AI代码比调试人类代码更耗时、更令人沮丧。

调试AI代码为什么这么慢？传统调试的思路是”我写的代码，我知道它在干什么”，你从假设出发，逐步排除，定位问题。但AI代码打破了这条假设。你不知道AI为什么这样写，所以你不知道bug藏在哪里。你看到的症状是”数据不对”，但原因可能在AI三行代码之前的一个隐式类型转换，可能在AI引用的一个你没注意到的库函数的边界行为，可能在AI生成时做了一个你根本没要求的”优化”。所有线索都在，但你不知道哪些是线索，哪些是干扰。”AI写代码快了3倍，但调试AI代码慢了5倍”，这是Hofstadter定律在AI时代的精确表述。你预期AI能加速3倍，但实际调试成本抵消了加速甚至倒亏。而且这个”5倍”本身可能还是低估了，因为AI代码的bug往往更隐蔽、更难复现、更难定位。Hofstadter定律的自我指涉在这里完美应验：即使你知道调试会慢，它还是比你预想的更慢。

软件工程里这条定律的案例比比皆是。按代码行数发奖金，结果全公司都在复制粘贴；按PR数量考核，结果频繁提交无意义的小PR；按bug修复数衡量绩效，结果开发者先写bug再修bug。

AI时代，Goodhart定律有了新的变异体。代码行数被AI注水，AI一天能产出2000多行代码，但这些代码的质量如何？CodeRabbit的研究显示，AI生成提交平均检出约10.83个问题，人类代码只有6.45个。代码量上去了，质量下来了。

更荒诞的是”tokenmaxxing”。一些团队开始把AI的token消耗量当作效率指标，消耗越多，说明AI用得越多，说明团队越”AI化”。于是开发者开始让AI生成更多不必要的代码，消耗更多token，来证明自己在”高效使用AI”。一个原本用来衡量AI采用率的指标，变成了一个被优化的目标，而它衡量的东西，真正的开发效率，反而被牺牲了。指标达标了，效率死了。

还有更隐蔽的：当”AI代码占比”成为考核指标，团队会故意让AI生成更多低质量代码来达标。Meta要求2026年上半年65%的工程师用AI编写超75%的代码，这个目标本身可能就在催生Goodhart效应。工程师为了达标，会把本可以手写的高质量代码也交给AI生成，然后再花时间修改。指标达标了，效率反而下降了。

mobile.de团队的做法是硬性规定25%的时间资源用于减少技术债。这不是慷慨，这是理性。不还债，利息就会越滚越多，直到整个系统被债压垮。

AI时代，技术债的利率变高了。JetBrains的数据显示，技术债积压速度是传统开发的2.4倍。代码重构占比骤降60%，还债的速度远远低于欠债的速度。mobile.de的25%还债比例在AI时代远远不够，因为欠债的速度已经翻倍了，而还债的能力反而下降了。为什么还债能力下降了？因为AI生成的代码更难重构。你理解自己写的代码，所以你知道怎么重构。你不完全理解AI写的代码，所以重构的风险更高、成本更大。你删掉一段看起来多余的异常处理，结果某个边界条件触发了，系统崩了，你才知道那段代码不是多余的。你合并两个看起来重复的函数，结果发现它们的微妙差异是有意的，但AI没有注释说明为什么有意。于是技术债形成了一个恶性循环：AI加速欠债，代码更难理解，重构更困难，还债更慢，债越积越多，系统越脆弱，AI生成的补丁代码更多，欠更多债。

利率在涨，本金在涨，还贷能力在降。这不是技术债，是技术次贷。

2008年金融危机的根源是什么？不是没有人还房贷，而是房贷被打包成衍生品，衍生品又被杠杆放大，风险层层叠加但没人看得到底层资产的真实质量。AI时代的技术债正在走同样的路：AI生成的代码就像次级贷款，快速产出、质量堪忧、缺乏审查；这些代码又被其他AI代码依赖和引用，就像衍生品层层打包；代码审查的缺失就像评级的失灵，PR超过500行时，人类reviewer的缺陷发现率从63%暴跌到28%，而AI一天就能产出2000多行代码。你甚至不知道底层”资产”（代码）的真实质量，但你已经在上面构建了整个系统。技术次贷的爆雷，只是时间问题。

这条定律在AI时代格外重要，因为AI工具已经可以打破组织边界，但组织架构还没跟上。AI Agent可以同时写前端和后端，但你的团队还是前端一组人、后端一组人。AI替你跨团队开发了，但代码的归属、维护、责任都没有重新划分。AI加速了跨边界代码的产出，但组织没有为这些跨边界代码建立对应的协作机制。AI不是在帮你，它是在加速你的混乱。

AI时代最被低估的管理风险：工具跑在了组织前面。你给团队配了最先进的AI编程工具，代码产出速度翻倍了，但代码审查流程没变、团队协作方式没变、架构治理机制没变。速度上去了，治理没跟上，结果不是更快地到达目的地，而是更快地翻车。Vibe Coding、Spec Coding、Harness Engineering，从”氛围编程”到”规约编程”再到”驾驭工程”的演进，本质上就是组织在追赶工具的过程。Vibe Coding是工具跑在最前面，Spec Coding是组织开始制定规则，Harness Engineering是组织终于建立了约束系统。这个演进方向本身，就印证了康威逆定律：不是工具决定架构，而是组织决定架构。工具再快，组织不跟上，只是加速混乱。

写在最后

22条定律，从写代码到搭架构到管团队，贯穿始终的是同一个判断：AI不是让错误变多了，而是让错误更快地变成灾难。

传统开发里，违反KISS原则，可能半年后才发现代码难以维护；AI时代，三个月就动不了了。传统开发里，违反Gall定律，可能两年后系统才撑不住；AI时代，一句话生成的复杂系统，上线即崩。传统开发里，技术债的利息是慢慢滚的；AI时代，利率翻倍，还贷能力反而下降。这不是技术债，是技术次贷。

有人会说：AI还在进步啊，今天的bug明天可能就修了。没错。但定律不是bug。KISS不是bug，DRY不是bug，Gall定律不是bug，Conway定律不是bug，它们是对复杂系统本质规律的描述。AI可以修bug，但AI修不了定律。定律不是代码的问题，是复杂度的问题，而AI恰恰是复杂度的加速器。

AI coding是工具，是加速器，用好了确实能提升效率。但加速器有两个方向：加速好的代码，也加速坏的代码；加速正确的架构，也加速错误的架构。你踩的是油门，但方向盘还是你在握。

佐治亚理工SSLab追踪的数据：可明确归因于AI生成代码的CVE，从2025年8月的2个飙升到2026年3月的35个。研究员指出，实际数字可能比检测到的高5到10倍。这不是AI的错，是人们以为有了AI就不需要工程纪律的错。技术债是慢病，抛弃工程定律是急症。慢病要治，急症要先救命。

而救命的方法，就是重新认识这些定律，不是把它们当作过时的教条，而是当作AI时代的安全绳。定律不会过时，因为它们描述的不是技术，而是复杂度的本质。技术换了，复杂度没换。

下次用AI写代码之前，先问自己三个问题：

三条问题，对应三层定律。不需要记住22条，记住这三个问题就够了。