AI 会写代码后，YAGNI 更像一条架构红线

Kent Beck 最近又把 YAGNI 拿出来讲了一遍。

起因很小。他回忆早年项目里，Chet Hendrickson 想提前做一个更复杂的结构，理由是“三周后肯定会用到”。Beck 的回答反复只有一句：You aren’t gonna need it。

这次有意思的地方，不在怀旧敏捷开发，而在 AI 编程时代的新误读：既然模型几分钟能生成一套抽象层、适配器和配置系统，那是不是可以提前把未来可能需要的架构都搭好？

Beck 的答案很硬：不行。YAGNI 从来不是为了省打字。

YAGNI 不是少写代码，是别太早承诺

YAGNI 常被翻译成“你不会需要它”。很多人把它理解成：别写没用代码，省点工时。

这个理解太窄。

Beck 这次重申的重点是：YAGNI 不是反设计，也不是永远做最烂实现。真的需要，就做。问题只在时机。

过晚设计会痛。系统会长出补丁、绕路和技术债。

过早设计也会痛。你在需求还没清楚时，把团队锁进一个猜出来的结构里。

这两个痛不一样。前者是欠债，后者是下注。很多团队只怕欠债，不怕押错。

这对软件工程师很具体：不要因为 AI 能快速补齐“通用能力”，就把每个函数都包装成框架。先让需求跑出形状，再抽象。

对架构师也很具体：架构评审不该只问“这个设计能不能覆盖未来”，还要问“现在承诺这个未来，代价由谁付”。

两笔账：选择权和时间价值

Beck 把投机性结构的成本拆成两笔账。

第一笔是选择权损失，也就是 optionality loss。

你提前按一个未来需求搭结构，本质是在信息还没到之前做承诺。接口、目录、依赖方向、扩展点，一旦进了主干，就会影响后面的写法。

真正值钱的，往往不是那个提前做好的结构，而是“等需求清楚后再做正确结构”的权利。

第二笔是 NPV 损失。

这里不用按严格财报模型理解。它更像一个时间价值类比：你现在为三个月后的功能付成本，收益却要等功能上线后才回来。

成本提前。回报延后。中间这段时间，本身就是损耗。

最刺的一点在这里：预测正确也可能亏。

不是架构师不聪明，而是顺序错了。你可能猜中了未来需求，却提前花掉了选择权，也提前占用了团队注意力。

“欲速则不达”放在软件设计里并不玄。快，不是早点把所有东西都建出来。快，是在信息足够时，把该下的注下准。

历史上类似的事不少。铁路、电力、互联网平台都吃过“先铺大网、再等需求”的诱惑。技术扩张当然需要提前投入，但软件架构和基础设施不完全一样：代码结构越早固化，后续需求越容易被它反向塑形。

这就是 YAGNI 的边界。它不是禁止远见，而是要求远见接受时机约束。

AI 降低了打字成本，也放大了投机架构

我更在意的是这一层：AI 编程工具改变的不是架构规律，而是冲动成本。

过去要提前做一个通用框架，至少要有人写、讨论、review。这个摩擦很烦，但它会拦住一部分手痒的设计。

现在模型几分钟就能生成一套“看起来很专业”的结构：抽象层、插件机制、配置中心、统一错误处理、测试脚手架。团队很容易误以为自己变勤奋了。

问题是，生成便宜，不等于拥有便宜。

你仍然要理解它、维护它、调试它、迁移它。更麻烦的是，很多 AI 生成的结构不是烂在第一眼，而是漂亮到让人舍不得删。

这对正在引入 AI 编程工具的技术负责人尤其要命。

不要只盯着“人均代码产出”。更该盯三件事：

工程师可以调整一个习惯：让 AI 先写局部、具体、可删的代码，不要一上来让它设计“可扩展架构”。

架构师要改一个评审问题：不要只问“这套设计够不够优雅”，还要问“现在不做，会损失什么；现在做错，要付什么”。

技术负责人要管住一个入口：谁有权把结构提交进主干。

AI 进入研发流程后，产能会涨，结构噪音也会涨。设计纪律不能跟着放松，反而要收紧。

这里也有现实限制。不是所有提前设计都该砍掉。安全边界、数据模型、权限体系、合规约束，有些东西晚了会更贵。

所以判断标准不是“提前一定错”，而是看提前承诺有没有足够证据，回滚成本有多高，收益是不是已经近到能覆盖成本。

接下来最该观察的变量，不是模型还能多会写代码，而是团队怎么定义“可合入的结构”。

如果 AI 生成的抽象层默认可以进主干，YAGNI 会失守。如果团队把 AI 当加速器，但仍然要求真实需求、第二用例、可删除路径，YAGNI 反而会变成更硬的工程纪律。

代码可以由机器写得更快。承诺仍然由人承担。

Beck 这次提醒的，其实就是这件旧事：别把便宜的生成，误看成便宜的决定。