前几天在几个 AI 开发者群里看大家聊天，有一张工程账单把我给逗笑了。
一位群友发了一条动态：“模型一周给我写了一万多行代码，随后我又花了一整周，一步步指导它把这一万多行代码全都删掉。”
紧接着另一位群友吐槽：“一个简单的 override 就能解决的事，模型为了显得架构优雅，给我硬生生拆出了五层转发、适配器和握手协议。” 还有人总结得更透彻：“现在 AI Coding 最大的问题，不是它不会写，而是它能用极其合理、看起来无比专业的姿势，把人忽悠过去。”
这几句话在群里引发了相当长的讨论。大家表面上是在吐槽 AI 喜欢“画蛇添足”和“浪费额度”，但如果你真正天天用 Claude Code、Cursor、OpenCode 或 Gemini 在生产环境里干活，你就会意识到这绝不仅仅是一个模型好不好用的小吐槽。
它背后暴露的是一个正在深刻发生的生产关系剧变：当生成代码的边际成本迅速趋近于零，工程稀缺性正在从‘如何把东西写出来’，全面转移到‘如何阻止不该存在的代码进入系统’。
换句话说：当写代码开始免费，删代码才成了工程师的正职。
一万行代码不是产出，而是待验收库存
“一周写一万行，下一周再删掉一万行”，听起来像个荒诞的幽默段子。但在工业生产里，这种现象有一个非常标准的名字：库存堆积。
过去的软件工程里，代码是稀缺的。一个设计方案能不能变成现实，最主要的瓶颈在于工程师手打代码的物理速度。代码行数在很长一段时间里，甚至被误当成了某种产出指标。
现在情况反过来了。在多 Agent 和长思考模型的加持下，十几套可选方案、五层抽象架构、二十个适配接口，可以在几秒钟内铺满你的屏幕。代码的制造成本被打到了地板上。
但很多人忽略了一件事：AI 生成的代码，并不直接等于可交付的工程产物。在没有经过人类严格审视、测试和验证之前，它唯一的身份是一堆‘待验收的工程库存’。
如果一个团队的生成速度远远超过了它的验证速度，所谓的“AI 带来十倍提效”，本质上只是在十倍速地制造待审核库存。
未读的 PR、未在边缘条件验证过的兜底分支、没有人真正理解的中间抽象层……这些代码停留在仓库里，就像堆在车间里的半成品。它们不仅不产生价值，还会持续消耗团队的注意力与维护精力。
单行代码生成得越便宜，组织拥有的代码总量往往膨胀得越快，而总体的维护成本和理解成本反而可能被推得更高。
AI Coding 的第一条生产纪律，可能不是多开几个 Agent 去狂飙代码，而是：代码的生成速度，绝不能长期超过团队的验证与收敛能力。
否则，你不是在写软件，你只是在为 AI 的生产过剩买单。
模型最危险的，不是写错，而是把多余写得很专业
如果 AI 只是写出明显的语法错误或逻辑 Crash，事情反而简单了。编译器会报错，测试用例会飘红，工程师扫一眼就能给它打回去。
真正昂贵且危险的，是群友吐槽的那种情况：逻辑正确、测试通过、结构规范，但根本没有必要存在的代码。
模型面对不确定性时，有一种天生的“过度防御”机制。你给它一个简单的业务需求，它不会主动问你“这个接口未来半年真的会变吗”，它会下意识地把这种不确定性翻译成复杂的代码形态：
- 增加一个抽象基类，预防未来的未知扩展；
- 增加一层适配器，隔离可能根本不会换的第三方服务；
- 增加一段复杂的握手与状态校验，防止极其罕见的边缘故障；
- 再加一个配置读取和多层转换，顺便把未来可能的变动也“顺手封装了”。
其中每一层代码单独拿出来看，都符合某种经典的设计模式，甚至能附带上一段写得非常漂亮的注释。这种现象可以称之为‘复杂度洗白’。
模型用正确的术语、成熟的范式和看似周密的逻辑，把没有证据支撑的复杂度包装成了“工程严谨”。它知道企业级架构长什么样，却不承担长久维护这个架构的痛苦。
我在《Skill 不该越写越重》里讨论过复杂度如何偷偷从能力沉淀演变成流程负担。在代码层面，这个过程因为 AI 的介入被放大了十倍。
如果工程团队失去警惕，形式上的成熟感就会迅速取代对必要性的证明。
而这正是 AI 给工程师挖下的最大陷阱：它用极低成本制造出了极高复杂度的幻觉，让你误以为自己拥有了一个庞大而完备的系统，其实你只是被它用看起来合理的方式忽忽了。
删代码的本质：缩小系统对未来的‘承诺面’
讨论“删代码”，很容易走进另一个极端：误以为代码行数越少越好，或者删得越多就显得越高级。
有些复杂度是业务本身天生带有的，有些显式的代码虽然读起来长，但比晦涩的简写更容易测试和维护。为了可观测性、故障隔离和安全审计而增加的防御代码，绝对不能简单归为冗余。
真正需要通过“删除”来控制的，不是代码的物理行数，而是系统的‘承诺面’。
在软件架构里，每新增一个公共接口、一种状态持久化、一条隐式路由、一层通用适配，本质上都是团队在对未来作出长期的承诺：
- 这个接口以后不能随意重构，因为可能有依赖者；
- 这个状态以后必须向下兼容，因为有历史数据；
- 这层抽象以后必须有人能看懂，否则没人敢动底层；
- 这个配置项以后需要长期支持，否则改动就会破防。
你每让 AI 多生成一层没有真实业务证据支撑的抽象，你就在系统的未来承诺面上多埋了一颗雷。
因此，AI Coding 时代的工程目标，绝不是追求最少行数，而是：用最少的长期承诺，换取足够且可验证的业务能力。
当你指导 AI 删掉那五层多余的转发、删掉那个根本用不上的配置转换、删掉那个预想中“未来可能用到”的插件机制时，你不仅是在清除冗余行数，你是在帮系统把敞开的风险暴露面重新收缩回来。
这种删除，是在保护系统未来的选择权。
工程师角色的三次迁移：最好的删除发生在生成之前
回看过去这几年，AI Coding 工具的普及正在推动工程师的角色经历三次关键迁移。
第一阶段：代码生产者。 业务需求给出来，工程师的主要精力放在敲击键盘、实现逻辑、把代码一行行拼出来。
第二阶段：AI 产出的清洁工。 AI 在几秒钟内给出一大串代码，工程师像个疲惫的审计员，在海量的生成结果里挑选、对比、修补、删减冗余。
如果工程团队长期停留在第二阶段，那是极其痛苦的：你相当于给一个无限产出垃圾代码的实习生当全职扫地僧。
更成熟的第三阶段：系统的设计者与约束者。 工程师不再试图在 AI 生产完堆积如山的代码后再去艰难清理，而是把精力前置，在代码生成之前就建立起硬性约束：
- 在 Prompt 和 Context 里明确限制：“只做最小可行修改，严禁引入未被要求的抽象层”；
- 强制要求：“新增任何公共接口或转发层，必须给出具体的业务证据，否则拒收”；
- 明确交付标准：“能用几行直接逻辑解决的问题，绝不接受超过两层的封装”；
- 把“如何证明这段代码不能更简单”作为自动化验收和 code review 的硬门槛。
最好的删除，不是代码写进仓库后再花一周去打扫，而是这段代码从一开始就不被允许生成。
结论：AI 负责制造可能性，人负责约束可能性
在传统的工程师评价体系里，我们习惯看一个人“写出了什么”：写了多少模块、搭了什么框架、推出了多少功能。
但在 AI 时代，这种评价标准正在发生根本性的倒转。
AI 的强项是制造可能性。只要你给它一个方向，它可以瞬间吐出一百种可行或看似可行的实现方式。然而，可能性不是免费的，每一份未经约束的可能性，都在拉大系统的状态空间与测试代价。
人类工程师最稀缺的价值，不再是和 AI 比拼谁能更快地把可能性变成代码，而是拥有足够的判断力、直觉与魄力，把那一片无限膨胀的可能性，狠下心来压缩成一个足够小、足够清晰、可以长期承担责任的最小实现。
AI 时代，工程师不再只对写出来的代码负责，也开始对那些被成功阻止、因此从未出现的代码负责。
阻止正确但多余的代码进入系统，这才是今天真正值钱的工程手艺。
