最近开发者社区里，弥漫着一股“越写越慢”的诡异焦虑。
按理说，Cursor 和 Claude Code 已经把“敲打键盘”的物理时间压缩到了极限。一个需求扔进去，几百行代码瞬间生成。但现实是，越来越多人发现：代码生成得越快，整个项目的交付周期反而拉长了。
如果你把这仅仅归结于“大模型喜欢写 Bug”，那就太表面了。
这场效率危机的本质，是一场软件工程的底层物理学坍塌。
<figure> <img src=“images/01-time-shift.png” alt=“时间分配的转移” /> </figure>
1. 成本不对称：O(1) 的生成 vs O(N) 的验证
在传统开发中，写代码和读代码的成本是相对对称的。你写每一行代码，大脑里都会同步构建起这块逻辑的上下文（Mental Model）。
但 AI 编程打破了这个对称性。AI 生成 500 行代码的成本是 O(1) 的（点一下回车），但人类要作为“审查员”去验证这 500 行黑盒代码是否符合业务逻辑、是否藏着并发竞争、是否会造成 OOM，认知成本是 O(N) 甚至 O(N²) 的。
这就导致了一个灾难性的后果：人类开发者被从“创作者”降级成了“高并发代码的质检员”。 垃圾代码的生成速度，超过了人类做 Code Review 的生理极限。你省下了一小时写代码的时间，却要在三天后花十个小时去排查一个极其隐蔽的逻辑雷。
2. 状态空间爆炸与“全局不变量”的失守
AI 为什么总是埋这种隐蔽的雷？因为当前的 LLM 严重缺乏“全局不变量（Global Invariants）”的概念。
资深人类工程师在写代码时，脑子里是有高压线的：表现层不能反向依赖数据层，领域模型必须保持单向数据流。人类正是通过这些架构上的“自我约束”，把程序可能出错的“状态空间”锁死在一个极小的、可控的范围内。
但 LLM 的运作逻辑是基于局部的 token 概率补全。只要能让眼前的这个 Feature 跑通，它会毫不犹豫地引入一个全局污染变量、穿透分层架构直接调底层接口，或者强行挂载一个生命周期钩子（Hook）。
它确实秒杀了当前的 Bug，但它同时也炸毁了你苦心经营的架构边界。 程序的可能状态空间随之发生指数级爆炸，最终引发牵一发而动全身的系统性崩塌。
这就是为什么你总觉得 AI 越用越累——它在前面一路狂飙，你跟在后面给千疮百孔的架构打补丁。
3. 下半场的解法：从“生成工程”到“约束工程”
认清了这一点，我们就该换个思路来使用目前的 AI 编程工具了。
过去一年，大家都在研究“怎么写 Prompt 才能让 AI 帮我生成更多代码”。但在懂行的老手眼里，现在的核心命题是“怎么写规则才能限制 AI 乱写代码”。
这也是为什么，最近 GitHub 上像 karpathy-skills（大神 Karpathy 的私人补丁）和 ECC 这样的 AI 防错配置文件会疯狂屠榜。
它们的本质，就是把人类脑子里的“全局不变量”硬编码下来，变成 AI 无法越界的紧箍咒。
不要再把 AI 当成一个“什么都能写的全栈架构师”。请把它当成一个不知疲倦、手速极快，但随时可能破坏承重墙的危险施工队。
在 AI 时代，慢就是快。
把你以前用来敲键盘的时间，全部转移到写集成测试、划定模块边界、以及死磕 .claudecode 里的约束条件上。
当 AI 把油门踩到底的时候，那个懂得怎么踩刹车的人，才是真正掌控项目的人。