用 AI 写代码为什么越用越累：成本不对称才是真正的元凶

你大概有过这种体感：Cursor、Claude Code 已经把"敲键盘"这件事压到了极限，一个需求扔进去，几百行代码瞬间生成。按理说应该飞起来了。可现实是——代码生成得越快，整个项目交付反而越慢，你人也越累。

很多人把这归结成"大模型爱写 bug"。太表面了。如果只是 bug，多调几轮就好了。真正让你累的，是一个更底层的东西：用 AI 写代码，打破了写和读之间的成本对称。

这篇就把这个对称为什么崩、崩了以后你为什么被迫从创作者降级成质检员，讲清楚。看懂了，你才知道下半场该往哪使劲。

一、生成是 O(1)，验证是 O(N)

传统开发里，写代码和读代码的成本大致对称。你写下每一行，脑子里同步建起这块逻辑的心智模型（mental model）——为什么这么写、它依赖什么、改了会动到哪。写的过程，本身就是理解的过程。

AI 编程把这个对称砸碎了。

AI 生成 500 行代码的成本是 O(1)——点一下回车的事。但你作为审查员，去验证这 500 行黑盒里有没有藏并发竞争、会不会 OOM、符不符合业务，认知成本是 O(N)，复杂耦合下甚至是 O(N²)。

这个不对称，是你今天用 AI 写代码所有痛苦的总根源。生成端被按到了地板上，验证端纹丝没动。你省下的是写代码那一小时的体力活，换来的是三天后排查一个隐蔽逻辑雷的十个小时。

后果是一句话：人类开发者被从"创作者"降级成了"高并发代码的质检员"。 你站在一条全是盲盒的流水线尽头，干着整条线上最高危、最费脑、又最没法自动化的活。垃圾代码的产出速度，已经超过了人类做 code review 的生理极限。

二、它为什么总埋你看不见的雷

那 AI 为什么总往里塞这种隐蔽的雷？因为它脑子里没有"全局不变量"这根高压线。

一个资深工程师写代码时，脑子里挂着无数条红线：表现层不能反向依赖数据层；领域模型必须保持单向数据流；这张表谁都不许直连、必须走服务。人类正是靠这些"自我约束"，把程序可能出错的状态空间，死死锁在一个极小、可控的范围里。

但 LLM 的运作逻辑是基于局部 token 概率补全——只要能让眼前这个 feature 跑通，它会毫不犹豫地引入一个全局污染变量、穿透三层架构直接调底层接口、或者强行挂一个生命周期 hook。它确实秒杀了眼前这个 bug，但同时炸毁了你苦心经营的架构边界。

更要命的是 AI 的"顺向"性格。它是个极度迎合你的执行器：遇到一个由耦合导致的报错，它不会停下来说"你最初的模型设计就错了，该重构"，而是顺着这坨耦合，引入一个新库、写一段眼花缭乱的正则 workaround，把报错"掩盖"掉。一个局部的小聪明，换来一个全局的架构腐烂。状态空间随之指数级爆炸，最终牵一发而动全身。

这就是为什么你总觉得越用越累——它在前面一路狂飙踩油门，你跟在后面给千疮百孔的架构打补丁。

三、下半场：把劲从"生成"挪到"约束"

认清这一点，使用 AI 的姿势就该变了。

过去一年，所有人都在研究"怎么写 prompt 让 AI 生成更多代码"。但在懂行的老手眼里，下半场真正的命题是反过来的那个：怎么写规则，限制 AI 乱写代码。

这也是为什么 GitHub 上那些"AI 防错配置文件"会疯狂屠榜——它们的本质，是把人类脑子里的全局不变量硬编码下来，变成 AI 越不过去的紧箍咒。

别再把 AI 当成"什么都能写的全栈架构师"。把它当成一个不知疲倦、手速极快、但随时可能砸穿你承重墙的危险施工队。你的活，不是跟它比谁敲得快，而是在它动手之前，把笼子立好。

在 AI 时代，慢就是快。 把你以前用来敲键盘的时间，全部转移到写集成测试、划定模块边界、死磕约束条件上。当 AI 把油门踩到底的时候，那个唯一知道刹车踩在哪、方向盘往哪打的人，才是真正掌控项目的人。

至于怎么把这些约束从"靠 AI 自觉"升级成"它违反就根本过不去"的硬关卡——那是另一篇要讲的事。

我是随机比特，腾讯十年开发，天天拿 AI 干活、被坑过、把判断沉下来。更多 AI 工程化的硬核拆解，关注公众号「随机比特」，或来 rbits.uk 翻完整的 270+ 篇。

—— 随机比特