今年2月，一篇知乎帖子记录了这么一次翻车：作者让AI重构一个2000行的烂摊子项目，AI反手就在微服务架构里塞了一个单例模式。知乎单例进微服务，相当于每个服务都要共享一个全局实例——这基本是把教科书背得滚瓜烂熟、但完全不知道自己在干什么的经典翻车现场。
但作者自己得出的结论恰恰相反——AI正在让设计模式从教科书里的死知识，变成活生生的生产力工具。知乎
从那以后，"AI写代码的时代，设计模式是不是过时了"这个问题就没消停过。我翻了知乎、公众号、抖音、头条、小红书上这半年的热门讨论，发现这事比"过时"或"不过时"有意思多了。
两派吵了半年，其实说的不是一件事
过时派的逻辑很直白： AI几秒钟就能生成一个标准的策略模式实现，你花一周背23种模式的代码模板，图什么？还有人的说法更极端，一篇公众号文章记录了一位群友的原话：别讲什么设计模式代码优化，写代码就是一把梭，先用token砸到它躺下去，再砸到它跪下来。微信公众号Vibe coding火了之后，这个声音越来越大。
反过时派的反击也很硬： 而且反击的正是开头那位翻车帖的作者。他自己做了个实验，让GPT-4、Claude、Cursor分别实现同一个"多支付方式+优惠券+积分"的订单系统；又让AI写电商购物车，代码能跑，但"耦合度高得像个毛线球"。你丢一句"用策略模式处理折扣逻辑"，它瞬间拆得明明白白。他的总结很狠：AI把写代码的门槛打到了地下室，但把设计代码的门槛抬到了天花板。知乎
8月份一篇讲AI做游戏的公众号文章把这事说得更透：你让AI加个Boss，它会自动上状态机；加武器词条，它会自动上装饰器；加成就系统，它会自动上事件总线——每个模式单看都用得"正确"，但几轮需求下来，一次挥剑的伤害结算要穿过血量、阶段、事件、词条统计、成就奖励一整条链，调试一次攻击要跳过十几个文件。微信公众号
看完全网这些帖子，我的判断是：两派根本不矛盾，他们吵的是两个不同的东西。
设计模式这件事其实分两半：一半是"怎么写"（How）——某个模式的类图和代码实现；另一半是"什么时候写"（When/Whether）——这里值不值得隔离、隔离到什么程度。AI已经把前一半干到接近零成本，甚至比你手写得更标准。但后一半——判断哪里真的会变、变化会沿着哪些依赖传播、团队愿意为隔离变化付出多少复杂度——AI给不了你，因为它不知道你项目的真实变化方向、团队能力、性能底线和历史包袱。
用那篇游戏文章的话说，模式应该作为方案的结果出现，而不是作为提示词里的配额。微信公众号
真正的新问题：AI太爱用设计模式了
这半年讨论里最有价值的信号，不是"要不要学"，而是一个新痛点的集中爆发：AI过度工程化。
你只要一个函数，它给你搭一个框架：工厂模式、抽象类、接口层、配置文件、错误处理、日志系统全上，代码量是你要的10倍，真正有用的部分可能就20%。一个简单的if-else能解决的事，它非要给你搞策略模式加工厂方法。改起来比自己写还慢——改一个地方要动5个文件。今日头条
社区已经开始用脚投票了：6月份有个叫Ponytail的开源项目走红，据发文者说上线两周涨了1.7万星。今日头条它干的事特别简单粗暴——给你的AI编程工具装一套YAGNI规则，强制AI"不需要的抽象层砍掉、不需要的设计模式砍掉、不需要的配置文件砍掉"，让AI像团队里最懒的那个高级开发一样写代码：够用就行，别整花活。
两周1.7万星这个数我没法独立核实，但这个工具能火本身就说明问题：被AI过度设计坑过的人，已经多到能撑起一个热门项目了。
那2026年，设计模式到底该怎么学？
把全网讨论里靠谱的部分筛出来，动作其实就三个：
第一，学判断，不背代码。 判断点是这些：分支只有3个，if-else就够了，别上策略模式；5种以上且还在频繁加，再考虑；装饰器叠加时顺序决定行为（限流在日志前面，被限流的请求就不进日志），这个顺序AI不会替你想；工厂模式的核心不是"创建对象"这个动作，而是"未来会不会新增产品类型"这个问题。微信公众号面试也一样——2026年的面经里设计模式仍是必考题，但面试官想听的是你在项目里为什么用了它，而不是它的定义是什么。微信公众号
第二，学会给AI下对指令。 8月那篇游戏文章给了个可以直接抄的模板：不要说"请用工厂、观察者、策略模式重构"（这等于让AI做模式填空题），而是把约束丢给它——“未来半年最可能变的是哪几块、旧数据必须兼容、调用链要在两个文件内追完——给我三种边界方案，分别说清楚隔离了什么、新增了什么间接层、最坏情况下改动会传到哪”。再让它扮演维护者和故障排查者反驳自己的方案。出来的东西质量完全不一样。微信公众号
第三，给AI装个刹车。 如果你在用Claude Code、Cursor这类工具，可以在项目规则文件里写明"不要过度设计、不要引入当前不需要的抽象、优先直接实现"。微信公众号Ponytail这类工具做的就是这件事的现成版本。让AI"多写"很容易，让AI"少写"才是2026年的技术活。
最后说下谁该看这篇
正在秋招准备后端面试的：设计模式还是必考项，但准备重心从"背实现"挪到"讲清楚项目里的取舍"，方向别搞反。微信公众号
日常让AI写正经项目的：这是你此刻最需要的——不是学更多模式，而是学怎么管住AI手里的模式。
只是vibe coding写个小工具自用的：可以略过这篇，简单能跑就行，别让模式成为负担。
一句话收尾：设计模式没过时，它只是换了个考法——以前考你"会不会写"，现在考你"能不能管住那个会写的AI"。
你被AI的过度设计坑过吗？或者你有什么管AI的独门规则？评论区聊聊。
