设计模式这话题放在生成式AI时代聊其实挺微妙的。一边是很多人觉得“AI都能自动写代码了谁还学设计模式”另一边是真正在项目里把AI用的顺手的人发现不懂设计模式连给AI提需求都提不明白。这篇是“生成式AI设计模式”系列的第四篇我不准备再聊那些“AI会取代程序员”的焦虑也不想停留在“让AI帮你写个单例模式”这种玩具级别。我想认真聊聊一个更实际的问题当我们要用生成式AI来学习、理解、应用、甚至审查23种经典设计模式时到底应该怎么做才最高效、最不容易踩坑。这系列前面几篇如果看过你会发现我一直强调一个观点——设计模式不是被AI淘汰的旧知识反而是驾驭AI输出的“语法框架”。这一篇我就把这个观点彻底落地给你一套我自己反复打磨过的实操方法论覆盖从记忆口诀到面试模拟、从代码重构到模式误用排查的全流程。无论你是在准备软考、应付期末大作业、刷设计模式面试题还是已经在用Java、C、C#写业务代码这篇的内容应该都能直接抄作业。1. 为什么生成式AI时代反而更需要懂设计模式很多人有一个误区觉得设计模式是“老古董”是前人代码能力不足时积累的妥协方案。实际上这个理解恰恰反了。设计模式本质上是被反复验证过的、针对特定场景的代码结构最优解它不是限制而是经验压缩包。在生成式AI出现之后这个经验压缩包的价值不仅没有下降反而急剧上升了原因有三点。第一AI是个“博学但缺乏常识”的生成器。你让它写一个订单状态流转模块它大概率能写出来但很可能写出一个几百行的if-else地狱或者把状态判断散落在各个业务方法里。这时候如果你在提示词里注明“使用状态模式组织状态逻辑”AI的输出质量会立刻上一个台阶。换句话说设计模式就是你对AI输出的“约束条件”约束越清晰生成结果越稳定。这不是玄学而是提示词工程里非常核心的原则——给AI限定结构框架远比让AI自由发挥可靠。第二设计模式提供了一套精确的词汇表。团队协作时你说“这里用观察者模式解耦”所有人脑海里浮现的是同一个结构图而对AI来说你说“用观察者模式”比说“帮我设计一个当某个对象变化时通知其他对象更新的机制”要精准得多。这种语义压缩能力在人与AI协作时尤其宝贵因为你本质上是在用设计模式的名字给AI下发一份微型需求规格说明书。第三生成式AI生成的代码虽然越来越像样但最容易翻车的地方恰恰是代码组织方式类与类之间的关系、依赖方向、扩展点的预留。而这些正是设计模式最擅长解决的问题。你自己懂模式才能判断AI给的代码到底是合理运用了策略模式还是在强行套一个抽象工厂导致过度设计。所以结论很清楚AI是放大器它放大的是你已有的设计能力如果你脑子里没有模式库AI给什么你用什么那代码质量就是碰运气。我经常打一个比方设计模式之于AI编程就像语法之于写作。你不会因为有了润色软件就不学语法恰恰相反你得懂语法才能看出润色软件改得好不好。这个逻辑放在生成式AI和设计模式的关系上完全成立。2. 用生成式AI学习23种经典模式的“三层加速法”既然设计模式这么重要那怎么用生成式AI把它吃透我根据自己的实践总结了一套“三层加速法”分别是认知层、记忆层、应用层。这三层对应的是“看懂、记住、会用”这三个递进阶段每一层都有对应的AI用法和实操要点。2.1 认知层让AI帮你翻译成“人话”学设计模式最大的门槛不是代码而是那些绕口的概念定义。什么“提供一个创建一系列相关或相互依赖对象的接口而无须指定它们具体的类”——这句话如果你硬背背十遍也未必真懂。我的做法是直接把这类定义扔给AI让它用大白话重新解释一遍并且强制要求给出生活化类比。比如我问AI“请用三句话以内的大白话解释抽象工厂模式并给一个生活类比不要出现云原生化之类的词。”它给我的回答大概是这样的抽象工厂就是“一个生产整套配套家具的车间”——你只管说要一套中式家具不用关心里面具体是椅子还是桌子怎么做反正出来的东西风格统一。买家具的人不需要知道车间里有多少条生产线这就是“抽象”的意义。这个过程的本质是把模式的定义转化为你已有的经验域里的概念映射。每个人熟悉的领域不同AI的价值在于它可以根据你的背景定制类比。你跟一个餐饮行业转行编程的人聊模式适配器就是饭店里的“翻译”你跟一个搞过音视频的人聊适配器就是转接头。这种个性化翻译是教科书给不了的。但这里我要提醒一句AI给的类比可能会有失真。毕竟类比只是帮助你建立第一印象不能替代对模式本质的理解。所以拿到类比之后一定要求AI再给你对应一段最小代码示例对照着看一遍才算真正过了认知层。2.2 记忆层让AI帮你编口诀和记忆锚点23种设计模式就算全理解了也很容易记混。尤其是创建型、结构型、行为型这三类的归属问题——软考、期末考、面试前突击最常考的就是“这模式属于哪个类型”“适用场景是什么”。这块我之前用笨办法死记硬背效果很差后来发现让AI生成口诀和记忆锚点是真的好用。比如你让AI用一句话把创建型的五个模式串起来“工厂Factory里有个抽象Abstract说要做个单例Singleton建造Builder好了原型Prototype再复制。”虽然这句不算特别通顺但确实比死记五个名字强。你还可以让AI针对你最容易混淆的几组模式做对比记忆比如“工厂方法 vs 抽象工厂”“适配器 vs 外观”“策略 vs 状态”让AI把它们的区别整理成对照表。我个人强烈推荐一个用法让AI生成“灵魂拷问式”记忆卡。就是让AI扮演考官随机出一个模式的场景描述你快速判断该用哪个模式AI当场给反馈。这个过程很像背单词用的间隔重复卡片但内容是模式知识效率比反复看笔记高很多。我在准备软考期间每天通勤路上就是用手机和AI做这种问答大概两周时间23个模式的归属和适用场景基本就条件反射了。2.3 应用层让AI模拟真实场景检验你的理解看得懂、记得住离“会用来设计代码”还有一段距离。应用层的核心训练方式是用AI构造接近真实的业务场景题你做设计AI当评审。比如我经常这样练给AI一个模糊需求——“一个电商系统用户下单后可能走多种支付渠道每种渠道的对接参数不一样而且未来可能新增渠道”让它扮演一个严格的技术负责人要求我给出设计方案。我先自己说思路用策略模式定义支付策略接口每种支付方式实现一个策略类再用一个工厂类根据入参返回对应策略。然后AI会追问渠道配置信息存哪策略类如何处理加载是否需要把策略的选择逻辑与业务逻辑解耦这一问一答间我的设计能力提升非常快。这个场景比看书刷题强在哪强在它逼着你做决策。选择题只是识别设计题才是综合运用。而且AI永远不嫌你烦可以无限次模拟演练这在找真人导师陪练时是不可能实现的。你要做的只是准备好一个固定的演练框架“我描述方案你指出漏洞并追问最后给出改进建议。”用这个提示词模板AI的反馈质量相当稳定。3. 我常用的四大实战场景直接抄作业的Prompt模板理论说再多不如看几个能直接用的实战场景。下面这四个场景是我日常使用频率最高、效果最明显的每一个我都会给出提示词框架和要点解析。你可以直接复制去用根据自己的场景微调就行。3.1 场景一代码重构助手——“这段烂代码该用什么模式”这是我自己在重构老项目时几乎每天都会用的场景。操作很简单把一段写得比较乱的代码贴给AI让它先分析问题再给出重构建议最后说明为什么选某个模式而不是另一个。提示词模板你是一个有15年经验的软件架构师。请分析下面的代码存在哪些设计问题重点看职责划分、耦合度、扩展性然后给出重构方案。如果涉及设计模式请明确指出用哪个模式并解释为什么这个模式适合当前场景以及不使用该模式会有什么后果。代码贴代码实际用下来的经验是代码不要太长控制在100行以内最好。一次贴一整段上千行的业务代码AI容易抓不住重点给出的建议也会偏向泛泛而谈。我习惯先把问题代码块单独抽出来或者先让AI整体浏览一遍代码架构再针对某一个类展开分析。另外一个技巧是如果AI给出的模式建议你认为不合理不要直接否定而是追问一句“有没有其他更轻量级的方案对比一下优缺点”。很多时候过度设计就是在这一问一答中被及时拦下来的。我举个例子。之前项目里有个类是负责解析不同格式的报表文件代码里是一大串if-else判断文件类型再分别调用不同的解析方法。我把这段代码丢给AI它建议用策略模式定义一个解析器接口每种格式实现一个策略再用一个工厂根据文件后缀返回对应策略。我当时追问了一句“这样不会类爆炸吗”AI补充说如果解析逻辑比较简单也可以用简单工厂录仪表的方式避免每个策略都新建一个类。这种多方案对比的讨论比任何一个设计模式专栏都更贴近真实场景。3.2 场景二面试官模拟器——“今天我来应聘你来面我”设计模式面试题是Java、C、C#后端开发面试的高频区这块用AI做模拟面试的效果出奇地好。关键是要给AI设定清晰的角色和范围。提示词模板你现在是一名大厂技术面试官面试岗位是Java后端开发。接下来你会向我提8个关于设计模式的问题难度从基础到深入渐进。每个问题等我回答后再追问一次细节然后点评我的回答并给出标准答案。开始吧。用这个模板练过几次之后你会发现AI的追问其实非常有水平。比如我回答“工厂方法模式和抽象工厂模式的区别”时可能只提到“一个是一个产品等级结构一个是多个产品等级结构”AI就会追问“那在你的理解里如果一个系统需要支持多套皮肤皮肤风格切换应该用哪个模式结合Spring的BeanFactory和FactoryBean的关系来谈。”这种把模式和框架实现结合起来的追问恰恰是面试中真正会遇到的深度。练完后还有一个步骤不能漏让AI给你做一个复盘清单。我通常会追加一句“请总结一下我回答中暴露的3个薄弱点并给出针对性的复习建议。”这样每次模拟面试都能得到一个精确的查漏补缺清单比漫无目的地刷题库效率高太多。3.3 场景三UML类图设计推演——“画图前先让AI帮你理结构”虽然现在很多工具支持文本生成UML图但我的使用习惯不太一样。我更看重的是在画图之前让AI帮我推演类之间的关系是否合理。因为UML图上画错关系比如把聚合画成组合、继承和接口搞混靠AI直接生成图往往是看不出来的。我的做法是用文字把候选方案描述给AI让它扮演UML评审专家。比如我要实现一个消息推送系统支持短信、邮件、站内信推送。我初步计划定义一个MessageStrategy接口包含send方法SmsMessageSender、MailMessageSender、InAppMessageSender分别实现它再建一个MessageContext类持有策略对象由调用方决定传入哪种策略。请从UML设计角度评价这个方案指出类之间应该用什么关系表示以及是否需要引入工厂来管理策略对象的创建。AI会指出MessageContext与MessageStrategy之间是组合/聚合关系而非简单依赖具体要看生命周期管理需求如果策略对象是无状态的可以复用那么用单例模式管理策略对象是更优选择如果策略对象的创建逻辑复杂可以引入工厂。这一轮讨论下来你在画图工具里需要表达的每个箭头关系都有了明确的依据画出来的图不再只是“形似”而是逻辑严谨的设计蓝图。3.4 场景四期末大作业/软考速记双保险这个场景主要面向还在读书、或者正在准备软考的读者。期末大作业通常是“用某种语言实现一个XX系统体现设计模式思想”软考则侧重于“给定场景判断该用什么模式、各模式之间的关系”。大作业这块我的建议是不要直接让AI生成整个项目代码那样答辩时一问就露馅。正确姿势是用AI做“脚手架的搭建者”和“过程的引导者”。你可以问AI“我要写一个坦克大战游戏准备用到工厂方法模式创建不同坦克、观察者模式处理碰撞事件、状态模式管理坦克状态。请帮我规划项目包结构以及每个模式的类职责清单。”然后自己动手按这个蓝图写代码。遇到具体类不知道怎么设计再单独问AI。这样既高效又能真正理解每个类为什么存在。软考速记这块我前面提到了“让AI出题考你”这里再补充一个技巧让AI把容易混淆的模式编成排除式单选题和场景匹配题。比如“下面哪个场景最适合使用装饰器模式A. 动态给对象增加职责 B. 定义对象创建接口 C. 让算法可以互相替换 D. 将客户端与子系统解耦”。这种题型就是软考真题的风格AI生成这种题的能力很强多练几组考点就慢慢熟了。4. 构建自己的“设计模式AI助手”提示词工程进阶心法如果你只用上面那些零散的Prompt去问AI时间久了会发现一个问题每次都要重新描述背景信息浪费token而且AI的回复风格不稳定。更进阶的玩法是搭建一个专用的“设计模式AI助手”会话提前把角色、知识范围、输出格式一次性设定好后续所有的问答都在这个框架内进行。4.1 角色预置定义一个“接口清晰”的AI对象你可以把AI助手的设定当成一个“类的定义”属性是它的背景知识和行为约束方法是它能响应的各种指令。我一般这样定义角色命令一次设定之后全程有效从此刻起你是一个名为DPMaster的设计模式专家助手。你的知识范围限定在GoF的23种经典设计模式及其变体。你具备以下能力1. 用生活化类比解释模式2. 生成不同语言的模式代码示例默认Java可切换3. 分析现有代码并给出重构建议4. 模拟面试问答5. 评估UML类图设计方案的合理性。你的回答风格是先给结论再给理由最后给代码或例子。当用户输入内容不符合规范时提示用户说明需求类型。设定好之后你会发现后续的交互质量上了一个大台阶。它不是每个问题都像个新AI一样重新理解你的意图而是像一个配置好的框架收到的每个请求都在既有协议下处理。这就是为什么我说设计模式本身也是一种“提示词模式”——你在用定义接口的方式约束AI的行为规范。4.2 建立“设计评审”工作流把AI当成结对编程伙伴进阶玩法不止是问答而是建立一套固定的评审工作流。我日常最常见的用法是我给出代码段AI先做静态评审然后我要求它按优先级输出问题列表。我的标准指令是这样的请按照下面的流程评审我接下来给出的代码第一步列出代码中的设计模式相关使用情况第二步指出模式误用或可以引入更合适模式的地方第三步分析代码的可扩展性和可测试性第四步最后给出修改建议清单每个建议标注优先级高/中/低。这个流程的好处是稳定、结构化避免AI东一句西一句。用熟之后AI的输出基本就是一份可以参考的Code Review记录可以直接粘贴到团队评审文档里再加工。4.3 让AI教你“反套路”什么场景不要用设计模式这一点是我特别想强调的。设计模式学习最大的坑不是不会用而是滥用。我见过太多同学写一个Hello World级别的作业硬生生套上抽象工厂加装饰器代码量翻了两倍可读性下降了一半。这不是设计模式的错是用的人不理解“模式的适用代价”。生成式AI在这件事上能帮一个很大的忙让它当“反模式警察”。我会在助手设定里加一条规则当用户给出的场景比较简单时应主动提醒“此处引入XX模式可能导致过度设计建议优先使用简单方案”。实际对话中AI也确实能给到不少中肯的提醒。比如我问它“一个只有两种实现的支付模块该不该上策略模式”它会说如果实现之间差异很小且未来大概率不扩展用简单if就可以强行策略模式反而增加类数量和维护成本。如果你想让AI在这方面的建议更可靠可以这样追问“请从YAGNI原则和我当前场景的复杂度角度评估这个方案是否合理。”强制让AI从“过度设计”的方向审视一遍它给出的答案往往会让你少走很多弯路。5. 常见问题与排查技巧实录用生成式AI学习或应用设计模式效果很好但也不是没坑。下面这些坑都是我自己踩过之后总结出来的我按“现象—原因—解决办法”的套路整理成了一份速查表。5.1 AI一本正经地“乱配模式”这个最坑。有时候你贴一段代码AI给出的重构建议里会出现“建议使用中介者模式来解耦”但实际代码里根本不存在多个对象之间复杂的网状交互。对这种问题要记住一句话AI的建议本质是基于统计概率的推测不是基于逻辑必然性的推导它很可能因为你代码里出现了一些关键词而联想到某个模式。解决办法是收到建议之后不要直接照做先反问AI一句“请说明这个模式的适用条件是哪些当前代码是否完全满足这些条件是否存在更简单的替代方案”。让AI自己论证一遍很多不靠谱的建议就会被证伪。还有一个小技巧是让AI给建议时注明“置信度”凡是它自己都没把握的建议直接忽略。5.2 AI生成的代码“像个模板但不像活物”很多时候AI生成的模式示例代码结构是对的但缺乏业务细节比如没有异常处理、没有参数校验、没有边界条件判断、没有日志记录。原因很直接你给的提示词没提这些要求AI默认输出最小可运行版本。解决方法是在提示词里追加质量约束比如“生成的代码必须包含参数校验和异常处理”“必须考虑多线程安全性”“请在关键逻辑处补充注释”。这个补充成本很低但对生成的代码质量提升非常大。我自己常用的一句话是“请以生产级代码质量来编写”AI输出的完整度会明显上一个台阶。5.3 AI混淆相近模式的边界“状态模式和策略模式到底啥区别”“装饰器和代理是不是一回事”——这种问题是AI最容易讲得含糊其辞的地方。因为这两个模式在类结构上几乎一样区别在于语义意图而AI很难准确抓住意图层面的差异。我的对策是让AI使用“同一场景两种模式对比”的方式来讲。比如我给它一个“文本编辑器光标的输入处理”场景让它分别用状态模式和策略模式设计一遍然后对比两种设计的侧重点。这种方式比直接问“它俩有什么不同”有效得多因为模式的意义只有在具体设计中才能显现。什么时候AI开始不耐烦或者回答得颠三倒四你就知道它对这个边界其实也是模糊的这时候最好换一本书去查别跟AI死磕。5.4 AI对“何时不用模式”的提醒不足前面说过AI默认倾向于给你“更复杂”的方案。你要是问它“这个代码有没有优化空间”它有大概率会把简单代码建议改造得花里胡哨。这不是AI笨而是训练数据的分布里“优化建议”往往意味着“引入更多模式”。所以我在使用它时明确加了一条规则每次提建议后必须附一段“不这样做的代价与收益分析”。如果AI说“建议用建造者模式解决构造参数过多的问题”那它也得讲清楚如果用传统构造函数重载坏处是什么、好处是什么以及在这个具体项目中哪种取舍更合理。逼着AI做成本收益分析能有效抑制它“为模式而模式”的倾向。5.5 过度依赖AI导致自己的设计能力退步最后一条是我自己的切身体会。有一段时间我写代码前习惯先让AI给方案结果发现自己独立设计的能力明显下降——离开AI之后面对一个新需求脑子里一片空白总想着“这个还是让AI想吧”。这是个危险的信号。我的调节办法是先设计再让AI评审。也就是无论需求多简单先逼迫自己画出类图、列出模式候选、说明理由然后才允许把方案拿给AI“找茬”。AI从“代笔”的角色变成“评审”的角色这样既利用了AI的效率又保住了自己独立设计的能力。这个习惯我一直维持到现在也是我觉得使用生成式AI最健康的一种姿势——工具始终是工具决策权永远在自己手里。最后再多说一句。这篇文章我刻意避开了那些“AI自动写代码”“你用AI做设计模式大作业”的速成路子因为那些东西不长久。真正从生成式AI里拿到长期红利的永远是那些把AI当磨刀石、而不是当拐杖的人。我自己从开始尝试“AI设计模式”的结合到现在最大的收获不是记住了23个模式的名字而是养成了一种任何时候都在追问“这个设计的本质意图是什么、换一个约束条件方案该怎么变”的思考习惯。这大概才是设计模式这门知识在整个AI时代里不可替代的价值所在——它教的不是某种固定的写法而是一种在任何技术浪潮更迭下都能稳定发挥的抽象能力。 
长河君 · 2026/11/4 23:37:38 · 阅读 1.2k 生成式AI时代，用AI高效学习与应用23种设计模式的实操指南
设计模式这话题放在生成式AI时代聊其实挺微妙的。一边是很多人觉得“AI都能自动写代码了谁还学设计模式”另一边是真正在项目里把AI用的顺手的人发现不懂设计模式连给AI提需求都提不明白。这篇是“生成式AI设计模式”系列的第四篇我不准备再聊那些“AI会取代程序员”的焦虑也不想停留在“让AI帮你写个单例模式”这种玩具级别。我想认真聊聊一个更实际的问题当我们要用生成式AI来学习、理解、应用、甚至审查23种经典设计模式时到底应该怎么做才最高效、最不容易踩坑。这系列前面几篇如果看过你会发现我一直强调一个观点——设计模式不是被AI淘汰的旧知识反而是驾驭AI输出的“语法框架”。这一篇我就把这个观点彻底落地给你一套我自己反复打磨过的实操方法论覆盖从记忆口诀到面试模拟、从代码重构到模式误用排查的全流程。无论你是在准备软考、应付期末大作业、刷设计模式面试题还是已经在用Java、C、C#写业务代码这篇的内容应该都能直接抄作业。1. 为什么生成式AI时代反而更需要懂设计模式很多人有一个误区觉得设计模式是“老古董”是前人代码能力不足时积累的妥协方案。实际上这个理解恰恰反了。设计模式本质上是被反复验证过的、针对特定场景的代码结构最优解它不是限制而是经验压缩包。在生成式AI出现之后这个经验压缩包的价值不仅没有下降反而急剧上升了原因有三点。第一AI是个“博学但缺乏常识”的生成器。你让它写一个订单状态流转模块它大概率能写出来但很可能写出一个几百行的if-else地狱或者把状态判断散落在各个业务方法里。这时候如果你在提示词里注明“使用状态模式组织状态逻辑”AI的输出质量会立刻上一个台阶。换句话说设计模式就是你对AI输出的“约束条件”约束越清晰生成结果越稳定。这不是玄学而是提示词工程里非常核心的原则——给AI限定结构框架远比让AI自由发挥可靠。第二设计模式提供了一套精确的词汇表。团队协作时你说“这里用观察者模式解耦”所有人脑海里浮现的是同一个结构图而对AI来说你说“用观察者模式”比说“帮我设计一个当某个对象变化时通知其他对象更新的机制”要精准得多。这种语义压缩能力在人与AI协作时尤其宝贵因为你本质上是在用设计模式的名字给AI下发一份微型需求规格说明书。第三生成式AI生成的代码虽然越来越像样但最容易翻车的地方恰恰是代码组织方式类与类之间的关系、依赖方向、扩展点的预留。而这些正是设计模式最擅长解决的问题。你自己懂模式才能判断AI给的代码到底是合理运用了策略模式还是在强行套一个抽象工厂导致过度设计。所以结论很清楚AI是放大器它放大的是你已有的设计能力如果你脑子里没有模式库AI给什么你用什么那代码质量就是碰运气。我经常打一个比方设计模式之于AI编程就像语法之于写作。你不会因为有了润色软件就不学语法恰恰相反你得懂语法才能看出润色软件改得好不好。这个逻辑放在生成式AI和设计模式的关系上完全成立。2. 用生成式AI学习23种经典模式的“三层加速法”既然设计模式这么重要那怎么用生成式AI把它吃透我根据自己的实践总结了一套“三层加速法”分别是认知层、记忆层、应用层。这三层对应的是“看懂、记住、会用”这三个递进阶段每一层都有对应的AI用法和实操要点。2.1 认知层让AI帮你翻译成“人话”学设计模式最大的门槛不是代码而是那些绕口的概念定义。什么“提供一个创建一系列相关或相互依赖对象的接口而无须指定它们具体的类”——这句话如果你硬背背十遍也未必真懂。我的做法是直接把这类定义扔给AI让它用大白话重新解释一遍并且强制要求给出生活化类比。比如我问AI“请用三句话以内的大白话解释抽象工厂模式并给一个生活类比不要出现云原生化之类的词。”它给我的回答大概是这样的抽象工厂就是“一个生产整套配套家具的车间”——你只管说要一套中式家具不用关心里面具体是椅子还是桌子怎么做反正出来的东西风格统一。买家具的人不需要知道车间里有多少条生产线这就是“抽象”的意义。这个过程的本质是把模式的定义转化为你已有的经验域里的概念映射。每个人熟悉的领域不同AI的价值在于它可以根据你的背景定制类比。你跟一个餐饮行业转行编程的人聊模式适配器就是饭店里的“翻译”你跟一个搞过音视频的人聊适配器就是转接头。这种个性化翻译是教科书给不了的。但这里我要提醒一句AI给的类比可能会有失真。毕竟类比只是帮助你建立第一印象不能替代对模式本质的理解。所以拿到类比之后一定要求AI再给你对应一段最小代码示例对照着看一遍才算真正过了认知层。2.2 记忆层让AI帮你编口诀和记忆锚点23种设计模式就算全理解了也很容易记混。尤其是创建型、结构型、行为型这三类的归属问题——软考、期末考、面试前突击最常考的就是“这模式属于哪个类型”“适用场景是什么”。这块我之前用笨办法死记硬背效果很差后来发现让AI生成口诀和记忆锚点是真的好用。比如你让AI用一句话把创建型的五个模式串起来“工厂Factory里有个抽象Abstract说要做个单例Singleton建造Builder好了原型Prototype再复制。”虽然这句不算特别通顺但确实比死记五个名字强。你还可以让AI针对你最容易混淆的几组模式做对比记忆比如“工厂方法 vs 抽象工厂”“适配器 vs 外观”“策略 vs 状态”让AI把它们的区别整理成对照表。我个人强烈推荐一个用法让AI生成“灵魂拷问式”记忆卡。就是让AI扮演考官随机出一个模式的场景描述你快速判断该用哪个模式AI当场给反馈。这个过程很像背单词用的间隔重复卡片但内容是模式知识效率比反复看笔记高很多。我在准备软考期间每天通勤路上就是用手机和AI做这种问答大概两周时间23个模式的归属和适用场景基本就条件反射了。2.3 应用层让AI模拟真实场景检验你的理解看得懂、记得住离“会用来设计代码”还有一段距离。应用层的核心训练方式是用AI构造接近真实的业务场景题你做设计AI当评审。比如我经常这样练给AI一个模糊需求——“一个电商系统用户下单后可能走多种支付渠道每种渠道的对接参数不一样而且未来可能新增渠道”让它扮演一个严格的技术负责人要求我给出设计方案。我先自己说思路用策略模式定义支付策略接口每种支付方式实现一个策略类再用一个工厂类根据入参返回对应策略。然后AI会追问渠道配置信息存哪策略类如何处理加载是否需要把策略的选择逻辑与业务逻辑解耦这一问一答间我的设计能力提升非常快。这个场景比看书刷题强在哪强在它逼着你做决策。选择题只是识别设计题才是综合运用。而且AI永远不嫌你烦可以无限次模拟演练这在找真人导师陪练时是不可能实现的。你要做的只是准备好一个固定的演练框架“我描述方案你指出漏洞并追问最后给出改进建议。”用这个提示词模板AI的反馈质量相当稳定。3. 我常用的四大实战场景直接抄作业的Prompt模板理论说再多不如看几个能直接用的实战场景。下面这四个场景是我日常使用频率最高、效果最明显的每一个我都会给出提示词框架和要点解析。你可以直接复制去用根据自己的场景微调就行。3.1 场景一代码重构助手——“这段烂代码该用什么模式”这是我自己在重构老项目时几乎每天都会用的场景。操作很简单把一段写得比较乱的代码贴给AI让它先分析问题再给出重构建议最后说明为什么选某个模式而不是另一个。提示词模板你是一个有15年经验的软件架构师。请分析下面的代码存在哪些设计问题重点看职责划分、耦合度、扩展性然后给出重构方案。如果涉及设计模式请明确指出用哪个模式并解释为什么这个模式适合当前场景以及不使用该模式会有什么后果。代码贴代码实际用下来的经验是代码不要太长控制在100行以内最好。一次贴一整段上千行的业务代码AI容易抓不住重点给出的建议也会偏向泛泛而谈。我习惯先把问题代码块单独抽出来或者先让AI整体浏览一遍代码架构再针对某一个类展开分析。另外一个技巧是如果AI给出的模式建议你认为不合理不要直接否定而是追问一句“有没有其他更轻量级的方案对比一下优缺点”。很多时候过度设计就是在这一问一答中被及时拦下来的。我举个例子。之前项目里有个类是负责解析不同格式的报表文件代码里是一大串if-else判断文件类型再分别调用不同的解析方法。我把这段代码丢给AI它建议用策略模式定义一个解析器接口每种格式实现一个策略再用一个工厂根据文件后缀返回对应策略。我当时追问了一句“这样不会类爆炸吗”AI补充说如果解析逻辑比较简单也可以用简单工厂录仪表的方式避免每个策略都新建一个类。这种多方案对比的讨论比任何一个设计模式专栏都更贴近真实场景。3.2 场景二面试官模拟器——“今天我来应聘你来面我”设计模式面试题是Java、C、C#后端开发面试的高频区这块用AI做模拟面试的效果出奇地好。关键是要给AI设定清晰的角色和范围。提示词模板你现在是一名大厂技术面试官面试岗位是Java后端开发。接下来你会向我提8个关于设计模式的问题难度从基础到深入渐进。每个问题等我回答后再追问一次细节然后点评我的回答并给出标准答案。开始吧。用这个模板练过几次之后你会发现AI的追问其实非常有水平。比如我回答“工厂方法模式和抽象工厂模式的区别”时可能只提到“一个是一个产品等级结构一个是多个产品等级结构”AI就会追问“那在你的理解里如果一个系统需要支持多套皮肤皮肤风格切换应该用哪个模式结合Spring的BeanFactory和FactoryBean的关系来谈。”这种把模式和框架实现结合起来的追问恰恰是面试中真正会遇到的深度。练完后还有一个步骤不能漏让AI给你做一个复盘清单。我通常会追加一句“请总结一下我回答中暴露的3个薄弱点并给出针对性的复习建议。”这样每次模拟面试都能得到一个精确的查漏补缺清单比漫无目的地刷题库效率高太多。3.3 场景三UML类图设计推演——“画图前先让AI帮你理结构”虽然现在很多工具支持文本生成UML图但我的使用习惯不太一样。我更看重的是在画图之前让AI帮我推演类之间的关系是否合理。因为UML图上画错关系比如把聚合画成组合、继承和接口搞混靠AI直接生成图往往是看不出来的。我的做法是用文字把候选方案描述给AI让它扮演UML评审专家。比如我要实现一个消息推送系统支持短信、邮件、站内信推送。我初步计划定义一个MessageStrategy接口包含send方法SmsMessageSender、MailMessageSender、InAppMessageSender分别实现它再建一个MessageContext类持有策略对象由调用方决定传入哪种策略。请从UML设计角度评价这个方案指出类之间应该用什么关系表示以及是否需要引入工厂来管理策略对象的创建。AI会指出MessageContext与MessageStrategy之间是组合/聚合关系而非简单依赖具体要看生命周期管理需求如果策略对象是无状态的可以复用那么用单例模式管理策略对象是更优选择如果策略对象的创建逻辑复杂可以引入工厂。这一轮讨论下来你在画图工具里需要表达的每个箭头关系都有了明确的依据画出来的图不再只是“形似”而是逻辑严谨的设计蓝图。3.4 场景四期末大作业/软考速记双保险这个场景主要面向还在读书、或者正在准备软考的读者。期末大作业通常是“用某种语言实现一个XX系统体现设计模式思想”软考则侧重于“给定场景判断该用什么模式、各模式之间的关系”。大作业这块我的建议是不要直接让AI生成整个项目代码那样答辩时一问就露馅。正确姿势是用AI做“脚手架的搭建者”和“过程的引导者”。你可以问AI“我要写一个坦克大战游戏准备用到工厂方法模式创建不同坦克、观察者模式处理碰撞事件、状态模式管理坦克状态。请帮我规划项目包结构以及每个模式的类职责清单。”然后自己动手按这个蓝图写代码。遇到具体类不知道怎么设计再单独问AI。这样既高效又能真正理解每个类为什么存在。软考速记这块我前面提到了“让AI出题考你”这里再补充一个技巧让AI把容易混淆的模式编成排除式单选题和场景匹配题。比如“下面哪个场景最适合使用装饰器模式A. 动态给对象增加职责 B. 定义对象创建接口 C. 让算法可以互相替换 D. 将客户端与子系统解耦”。这种题型就是软考真题的风格AI生成这种题的能力很强多练几组考点就慢慢熟了。4. 构建自己的“设计模式AI助手”提示词工程进阶心法如果你只用上面那些零散的Prompt去问AI时间久了会发现一个问题每次都要重新描述背景信息浪费token而且AI的回复风格不稳定。更进阶的玩法是搭建一个专用的“设计模式AI助手”会话提前把角色、知识范围、输出格式一次性设定好后续所有的问答都在这个框架内进行。4.1 角色预置定义一个“接口清晰”的AI对象你可以把AI助手的设定当成一个“类的定义”属性是它的背景知识和行为约束方法是它能响应的各种指令。我一般这样定义角色命令一次设定之后全程有效从此刻起你是一个名为DPMaster的设计模式专家助手。你的知识范围限定在GoF的23种经典设计模式及其变体。你具备以下能力1. 用生活化类比解释模式2. 生成不同语言的模式代码示例默认Java可切换3. 分析现有代码并给出重构建议4. 模拟面试问答5. 评估UML类图设计方案的合理性。你的回答风格是先给结论再给理由最后给代码或例子。当用户输入内容不符合规范时提示用户说明需求类型。设定好之后你会发现后续的交互质量上了一个大台阶。它不是每个问题都像个新AI一样重新理解你的意图而是像一个配置好的框架收到的每个请求都在既有协议下处理。这就是为什么我说设计模式本身也是一种“提示词模式”——你在用定义接口的方式约束AI的行为规范。4.2 建立“设计评审”工作流把AI当成结对编程伙伴进阶玩法不止是问答而是建立一套固定的评审工作流。我日常最常见的用法是我给出代码段AI先做静态评审然后我要求它按优先级输出问题列表。我的标准指令是这样的请按照下面的流程评审我接下来给出的代码第一步列出代码中的设计模式相关使用情况第二步指出模式误用或可以引入更合适模式的地方第三步分析代码的可扩展性和可测试性第四步最后给出修改建议清单每个建议标注优先级高/中/低。这个流程的好处是稳定、结构化避免AI东一句西一句。用熟之后AI的输出基本就是一份可以参考的Code Review记录可以直接粘贴到团队评审文档里再加工。4.3 让AI教你“反套路”什么场景不要用设计模式这一点是我特别想强调的。设计模式学习最大的坑不是不会用而是滥用。我见过太多同学写一个Hello World级别的作业硬生生套上抽象工厂加装饰器代码量翻了两倍可读性下降了一半。这不是设计模式的错是用的人不理解“模式的适用代价”。生成式AI在这件事上能帮一个很大的忙让它当“反模式警察”。我会在助手设定里加一条规则当用户给出的场景比较简单时应主动提醒“此处引入XX模式可能导致过度设计建议优先使用简单方案”。实际对话中AI也确实能给到不少中肯的提醒。比如我问它“一个只有两种实现的支付模块该不该上策略模式”它会说如果实现之间差异很小且未来大概率不扩展用简单if就可以强行策略模式反而增加类数量和维护成本。如果你想让AI在这方面的建议更可靠可以这样追问“请从YAGNI原则和我当前场景的复杂度角度评估这个方案是否合理。”强制让AI从“过度设计”的方向审视一遍它给出的答案往往会让你少走很多弯路。5. 常见问题与排查技巧实录用生成式AI学习或应用设计模式效果很好但也不是没坑。下面这些坑都是我自己踩过之后总结出来的我按“现象—原因—解决办法”的套路整理成了一份速查表。5.1 AI一本正经地“乱配模式”这个最坑。有时候你贴一段代码AI给出的重构建议里会出现“建议使用中介者模式来解耦”但实际代码里根本不存在多个对象之间复杂的网状交互。对这种问题要记住一句话AI的建议本质是基于统计概率的推测不是基于逻辑必然性的推导它很可能因为你代码里出现了一些关键词而联想到某个模式。解决办法是收到建议之后不要直接照做先反问AI一句“请说明这个模式的适用条件是哪些当前代码是否完全满足这些条件是否存在更简单的替代方案”。让AI自己论证一遍很多不靠谱的建议就会被证伪。还有一个小技巧是让AI给建议时注明“置信度”凡是它自己都没把握的建议直接忽略。5.2 AI生成的代码“像个模板但不像活物”很多时候AI生成的模式示例代码结构是对的但缺乏业务细节比如没有异常处理、没有参数校验、没有边界条件判断、没有日志记录。原因很直接你给的提示词没提这些要求AI默认输出最小可运行版本。解决方法是在提示词里追加质量约束比如“生成的代码必须包含参数校验和异常处理”“必须考虑多线程安全性”“请在关键逻辑处补充注释”。这个补充成本很低但对生成的代码质量提升非常大。我自己常用的一句话是“请以生产级代码质量来编写”AI输出的完整度会明显上一个台阶。5.3 AI混淆相近模式的边界“状态模式和策略模式到底啥区别”“装饰器和代理是不是一回事”——这种问题是AI最容易讲得含糊其辞的地方。因为这两个模式在类结构上几乎一样区别在于语义意图而AI很难准确抓住意图层面的差异。我的对策是让AI使用“同一场景两种模式对比”的方式来讲。比如我给它一个“文本编辑器光标的输入处理”场景让它分别用状态模式和策略模式设计一遍然后对比两种设计的侧重点。这种方式比直接问“它俩有什么不同”有效得多因为模式的意义只有在具体设计中才能显现。什么时候AI开始不耐烦或者回答得颠三倒四你就知道它对这个边界其实也是模糊的这时候最好换一本书去查别跟AI死磕。5.4 AI对“何时不用模式”的提醒不足前面说过AI默认倾向于给你“更复杂”的方案。你要是问它“这个代码有没有优化空间”它有大概率会把简单代码建议改造得花里胡哨。这不是AI笨而是训练数据的分布里“优化建议”往往意味着“引入更多模式”。所以我在使用它时明确加了一条规则每次提建议后必须附一段“不这样做的代价与收益分析”。如果AI说“建议用建造者模式解决构造参数过多的问题”那它也得讲清楚如果用传统构造函数重载坏处是什么、好处是什么以及在这个具体项目中哪种取舍更合理。逼着AI做成本收益分析能有效抑制它“为模式而模式”的倾向。5.5 过度依赖AI导致自己的设计能力退步最后一条是我自己的切身体会。有一段时间我写代码前习惯先让AI给方案结果发现自己独立设计的能力明显下降——离开AI之后面对一个新需求脑子里一片空白总想着“这个还是让AI想吧”。这是个危险的信号。我的调节办法是先设计再让AI评审。也就是无论需求多简单先逼迫自己画出类图、列出模式候选、说明理由然后才允许把方案拿给AI“找茬”。AI从“代笔”的角色变成“评审”的角色这样既利用了AI的效率又保住了自己独立设计的能力。这个习惯我一直维持到现在也是我觉得使用生成式AI最健康的一种姿势——工具始终是工具决策权永远在自己手里。最后再多说一句。这篇文章我刻意避开了那些“AI自动写代码”“你用AI做设计模式大作业”的速成路子因为那些东西不长久。真正从生成式AI里拿到长期红利的永远是那些把AI当磨刀石、而不是当拐杖的人。我自己从开始尝试“AI设计模式”的结合到现在最大的收获不是记住了23个模式的名字而是养成了一种任何时候都在追问“这个设计的本质意图是什么、换一个约束条件方案该怎么变”的思考习惯。这大概才是设计模式这门知识在整个AI时代里不可替代的价值所在——它教的不是某种固定的写法而是一种在任何技术浪潮更迭下都能稳定发挥的抽象能力。