有了 AI，合入的 PR 比去年翻了一倍。需求卡片一张接一张被拖进「已完成」。很多团队连建单都跟不上，不少改动干脆没有单子，直接合进主干。那么，用户得到的东西、业务上的数字，也翻倍了吗？
如果没有，那就是数错了东西。关掉的需求单、合入的 PR、AI 生码率、交付周期——它们回答的都是「什么时候、完成了多少」，是产出，是一个个点。而业务价值是在上线之后、在持续被使用的日子里一点点攒起来的。它不是点，是随时间铺开的面积。
工程师的工作，不是堆产出，也不是拼速度，而是让手里每一行要长期背着的代码，撑起尽可能大的面积。
上线那天，你的代码价值为零。
只有用户开始用，价值才会按某个速率流出来：保住的收入、省下的人力、躲开的风险、依赖它的项目。这个速率，乘以它持续有用的时间，就是面积。上线晚、没人用、三天两头出故障——只要占一条，提交记录再热闹，面积也小。
ROI 也好，人效也好，分子都是这块面积。上得再快，没人用，分子就是零，只有分母上的成本在涨。这不叫低成本买到了价值，只是为一个没人用的功能付了钱和时间。
真正能扩大面积的工作，逃不出这五类：
- 早点上线——把起点往前挪，让价值流得更久。
- 把价值做厚——提高单位时间的成果，把用户的问题解得更透。
- 守住眼下的价值——故障、走不通的链路、没人察觉的 bug。把面积上的窟窿补上。
- 别丢掉将来的价值——停止维护、被迫升级、被锁死的底座。防止未来的面积凭空消失。
- 让系统一直改得动——保持可改性，别让下一次改动越来越贵。
新功能大多作用于 1 和 2，维护和稳定性工作作用于 3 到 5。瞄准的是同一块面积，只是推的边不同。
但不管选哪一招，最后手里都会留下代码。
想象你是一栋楼的房东。每加盖一层，就多一份租金。随之而来的，是建造成本、招租、维修、应付租户、退租交接，还有物业费。哪怕整层空着，维修和物业费照样年年交。代码也一样。真正送到用户手上的功能在替你收租；而你留下的每一行，都带着 review、测试、迁移、oncall，还压在下一个读它的人脑子里。开源项目还得加上回 issue 和兼容性承诺。不管这一行有没有在产生价值，这些都跑不掉。
代码总量越大，维护占的比例越高。人不加、摊子铺大，能投到新价值上的力气只会越来越少。要维护的东西不减，还想一直往前走，就只能一直加人。就算 AI 能用比人更低的成本接手维护，也只是多出一笔维护 AI 的成本。
出路只有一条：减少要维护的东西。
所以删除和清理不是闲下来才做的大扫除，而是工程的本职工作。能在不损失价值的前提下做减法，才是顶尖工程师的标志。
没人用的功能和配置项、早已下线的活动和实验留下的残骸、为兼容某个早就没人用的东西打的补丁——这些是业务债。和空置的楼层一样，只有成本，没有面积。该删就删。要删的是没有面积的代码，不是把代码压缩到没人看得懂。能把同一类错误彻底堵死的抽象，哪怕行数变多，价值也在涨。
剩下的，往往是技术债：还在产生价值，却很难安全改动的代码。这部分不删，而是在不破坏现有面积的前提下修、合并。目的不是好看，是让下一块面积造得更便宜。拖着不还，最后还是得还——连本带息，而且多半是在故障或被迫迁移的当口。
就算软件工厂成了黑灯工厂，成群的 AI 日夜构建、维护，管工厂的仍然是人。
管理后台的看板上，今天照例是合入的 PR 数。某天，出了一个 AI 修不好的故障，你第一次走进工厂里面。里面是一座屎山，勉强还能出货。
你会怎么做？
先删，对吧。找出没有面积的代码，对留下的每一行追问：它在产生什么价值？这个问题不必等工厂停摆才开始问。从今天的 diff 就可以。
AI 时代，堆代码的诱惑前所未有。要顶住。
让每行代码的业务价值最大化。
