通过 claude code 学习设计模式并生成相关代码实例

去年秋天，我在一个遗留系统重构项目里踩了个大坑。那是一个用 Python 写的支付路由模块，核心逻辑是一个策略模式，至少代码注释里是这么写的。问题出在运行时，当新增的“微信分期”渠道被触发，整个路由突然退化成一个 300 行的 if-else 分支。后来复盘才发现，当初接手这个模块的同事让 Claude Code 生成了那版代码，他把 AI 的输出直接当成了“标准答案”。

这件事迫使我重新思考一个问题：用 AI 学习设计模式，到底学的是模式本身，还是 AI 对模式的“理解”？

我花了三个月时间，用 Claude Code 系统性跑完了 GoF 23 种设计模式，产出了 200 多个代码样本。这篇文章不是教程，不是 Prompt 模板合集，而是一个资深开发者在 AI 辅助编程时代的反思报告。我会告诉你：AI 生成的设计模式代码里藏着什么陷阱、哪些“变体”会让你在代码评审时丢脸、以及如何用批判性思维把 AI 从一个“答案机器”变成一个真正的学习伙伴。

读完这篇文章，你会拥有一个全新的视角：不要把 Claude Code 当老师，要把它当成一面镜子，它照出的不是“正确答案”，而是你对设计模式理解的深度。

一、核心结论先行：AI 时代学设计模式的三个反直觉真相

在我开始系统实验之前，我和大多数开发者一样，对 AI 辅助学习设计模式抱有三个朴素的期待：它能快速生成样板代码、它能解释模式结构、它能帮我节省时间。这三个期待都实现了，但实现的方式完全出乎我的意料。

第一个真相：AI 生成的代码“看起来对”和“真的对”之间存在巨大鸿沟。

Claude Code 在生成单例模式时，95% 的情况下能给出双重检查锁定的懒汉式实现。表面上看，这很专业，它甚至会自动补齐 volatile 关键字（Java）或使用 synchronized 块。但当我要求它“用 Go 语言实现同样的单例”时，它给出的代码里有三分之一直接忽略了 Go 的 sync.Once，而是手写了 sync.Mutex 加标志位。这里暴露的问题不是语法错误，而是 AI 没有真正理解“为什么 Go 用 Once、Java 用 volatile”，它只是在做模式匹配，不是在推理设计意图。

第二个真相：用 AI 学习设计模式的最大价值，不是它给出的正确代码，而是它产出的“微妙错误”。

这是我实验到第二个月才领悟到的。当 Claude Code 生成一个“工厂模式”时，它有时会生出一个把所有产品创建逻辑塞进一个巨大 switch-case 的“伪工厂”。这恰恰是初学者最容易犯的错误，把工厂模式理解成“用一个类来 new 对象”。这些微妙错误，比教科书上的标准代码更有教学价值，因为它们逼着你问：“为什么这个实现不对？我该怎么纠正它？”这个追问过程，才是真正的学习。

第三个真相：Prompt 技巧的尽头是苏格拉底式追问，而不是模板化指令。

网上流行的 Prompt 模板，“请用工厂模式实现 XXX”，只能得到“差不多”的代码。真正让我在设计模式理解上产生质变的，是一个简单的追问习惯：“为什么选择这种变体而不是另一种？”、“如果不使用这个模式，设计会差在哪里？”、“这个实现违反了哪个 SOLID 原则？”这些问题没有标准 Prompt 模板，但它们让 AI 从代码生成器变成了设计决策分析器。

基于这三个真相，这篇文章的核心论点可以凝练成一句话：Claude Code 是学习设计模式的绝佳工具，但前提是你得学会“审问”它，而不是“请教”它。

二、实验场的真实场景：我如何让 Claude Code 跑了 23 种模式

在展开具体发现之前，我需要交代清楚我的实验设置。这不是一个随意的“试试看”，而是一次有方法论的探索，这很重要，因为你读到的所有结论都建立在这个实验条件之上。

2.1 实验环境的搭建

时间跨度： 2024 年 10 月至 2025 年 1 月，每周投入约 8-10 小时。

工具版本： Claude Code 的多次迭代版本（从 2024 年 10 月到 2025 年 1 月经历了数次模型更新），实验最后阶段的版本在处理复杂设计意图上相比最初提升了约 30% 的表达准确度，我将在后面给出具体对比数据。

编程语言： 我选择了三种语言来覆盖不同的范式特征，

• Java： 静态强类型，接口和抽象类体系完善，是设计模式的“标准语种”。
• Python： 动态类型，鸭子类型（Duck Typing）让很多模式的实现方式发生根本变化。
• Go： 静态类型但接口是隐式实现的，组合优于继承的设计哲学。

每种设计模式我都至少用两种语言跑过。这意味着 23 种模式 × 2+ 种语言 × 3-5 次 Prompt 追问 = 超过 200 个代码样本。这个样本量足以观察出模式化规律，而不仅仅是个案。

对比基线： 我不是凭空评价 AI 的代码质量。对每一个模式，我都对比了三类实现，

1. GoF 原书中的标准实现（用 Java/C++ 重写为实验语言）
2. 我从过去 8 年工作经验中沉淀的手写实现（作为人类基线）
3. Claude Code 在不同 Prompt 策略下生成的变体

2.2 实验的评判框架

为了不陷入“凭感觉评价”的泥潭，我设计了一个四维评判框架。每次 Claude Code 生成代码后，我都从这四个维度打分（1-5 分）：

四维评判框架说明：

• 结构准确性： 类的结构、接口定义、关联关系是否符合该模式的核心定义。这是 AI 表现最好的维度，因为它本质上是在做“模式识别+代码翻译”。
• 语言惯用性： 实现是否充分利用了目标语言的特性。例如 Python 实现是否使用 __call__、装饰器；Go 是否使用隐式接口、channel。这是 AI 频繁失分的维度。
• 健壮性： 考虑并发场景、边界条件、资源释放。这是 AI 最薄弱的维度，它默认代码运行在理想环境中。
• 可扩展性： 在不修改核心代码的前提下，新增一个产品/策略/观察者的便利程度。

2.3 为什么这个实验设置对你的学习至关重要

很多开发者的学习路径是：有一个好奇心 → 打开 Claude Code → 提一个 Prompt → 得到代码 → 满意地关闭对话框。这个路径的问题在于，你得到的是一个“看起来对的答案”，但你不知道它在什么条件下是对的，也不知道它在什么条件下会错。

我的实验设置刻意复现了“追问-对比-反思”的循环。这篇文章里你看到的每一个发现，都是这个循环的产物。我不会只告诉你“AI 能生成单例模式”，那是垃圾信息。我会告诉你：“AI 生成的单例模式在某些语言下是正确的，在某些语言下是危险的，理解这个差异比你背下单例模式的类图重要 100 倍。”

三、误区拆解：关于 AI 和设计模式的五个普遍迷思

在正式进入具体模式的实验分析之前，我必须先拆掉几个地基不稳的认知框架。这些误区是我在过去三个月里，无论在技术社区、微信群还是代码评审中反复看到的。

迷思一：“AI 生成的代码等同于标准模式实现”

这是最致命的误解。在我的 200+ 样本中，结构准确性评分达到 4.5 以上的样本仅占约 60%。这意味着每 10 个 AI 生成的“设计模式代码”里，有 4 个存在结构性的“伪模式”特征。

什么算“伪模式”？我举一个具体例子。当要求 Claude Code “使用观察者模式实现一个事件通知系统”，它在 10 次尝试中有 2 次生成了这样的代码：所有观察者被塞进一个列表，通知时直接遍历调用。这看起来像观察者模式，有 Subject，有 Observer，有关系。但仔细观察会发现：观察者的注册、移除、通知逻辑全部耦合在 Subject 的一个巨型方法里。 这不是观察者模式，这是“被叫做观察者模式的上帝对象”。

真正的观察者模式的核心是解耦两个变化的维度，Subject 状态变化和 Observer 的响应方式。AI 给出的代码在结构上满足 UML 类图，但在设计意图上完全偏离。你用这样的代码学习，学到的是“类的命名规范”，不是设计思想。

迷思二：“我只要给出足够详细的 Prompt，AI 就能给出生产级代码”

我在实验中反复测试了这个假设。对于同一个需求，“用策略模式实现一个支持扩展的折扣计算器，要求线程安全，能处理并发请求”，我不断提高 Prompt 的详细程度。

• 初级 Prompt（一句话）： “用策略模式实现折扣计算” → 结构准确性 4，健壮性 2。
• 中级 Prompt（加上约束）： “用策略模式实现折扣计算，要求线程安全” → 结构准确性 4.2，健壮性 3。
• 高级 Prompt（加上场景和边界）： “用策略模式实现折扣计算，支持并发请求，要求无状态策略对象可被复用，有状态的上下文需要隔离” → 结构准确性 4.5，健壮性 3.5。

细节的提升是存在的，但有一个天花板，健壮性评分始终没有突破 4 分。原因在于：AI 不理解“生产环境”意味着什么。它不知道你的并发模型（是线程池还是协程）、不知道你的资源约束（内存池还是堆分配）、不知道你的日志和监控体系。没有这些上下文，再详细的 Prompt 也只是在描述一个“更复杂的理想环境”。

结论：不要把 Prompt 优化当成万能药。AI 生成代码和它理解你的生产环境之间，有一道算力填不平的鸿沟。

迷思三：“AI 时代不需要读 GoF 原书，直接让 AI 解释就行”

这个观点在技术社区非常流行，因为它听起来很“高效”。但它是错的。

GoF 原书的价值不在于给你可运行的代码，恰恰相反，它的大部分代码示例在今天看来已经过时。它的价值在于解释每个模式的 意图、动机、适用场景、结构、参与者、协作关系和后果。这是一套分析框架，不是一套代码模板。

当 Claude Code 解释“为什么用抽象工厂”时，它可能说：“因为需要创建一系列相关的产品对象。”它在复述定义。但当《Design Patterns》这本书解释同样的问题时，它会从“一个用户界面工具箱需要支持多种窗口系统”这个具体场景出发，一步步推导为什么 SimpleFactory 不够、为什么要解耦创建和使用、最终引出抽象工厂的设计决策。

区别在哪里？AI 在复述“是什么”，GoF 在展示“为什么演化”。学习设计模式，真正要学的是那个演化过程，因为你的项目不会是车间的 UI 工具箱，你需要把演化逻辑迁移到你的场景里。

迷思四：“模式代码生成是语言无关的”

很多文章用 Java 生成完设计模式就得出通用结论，这是有误导性的。在我的实验中，同一种模式在不同语言下的 AI 生成质量差异巨大。

观察者模式在不同语言下的表现对比（Claude Code 生成质量）：

Go 语言在所有维度上都显著偏低。为什么？因为设计模式的大部分经典实现是建立在“抽象类/接口+继承”这个基础之上的，而 Go 根本没有继承机制。当 AI 被要求生成 Go 版本的观察者模式，它有时会强行模拟一个“类层次结构”，用嵌入（embedding）+ 接口的方式，但嵌入不等于继承，它的行为语义是不同的。

这说明了一个关键点：用 AI 学习设计模式必须结合目标语言的特性。 如果你用 Java 例子学，然后用 Go 写，你学到的是 Java 的模式，不是 Go 的设计习惯。

迷思五：“AI 能帮我理解什么时候该用、什么时候不该用模式”

这是最隐蔽的误区，也是我在实验后半段才意识到的。我试过反复追问 Claude Code：“策略模式和状态模式有什么区别？在支付场景下该用哪个？”它的回答总是正确的、全面的、无可挑剔的，然后毫无用处。

因为它会告诉你“策略模式强调算法的可替换性，状态模式强调行为的内部状态依赖”，这个回答在学术层面完美无缺。但当你面对一个具体的支付系统，支付成功后的跳转行为和退款流程的状态扭转，这两者的边界往往是模糊的。真正的架构决策不是基于模式的学术定义做出的，而是基于你对业务演化方向的预判。

我举个真实例子。在支付项目中，“支付渠道选择”通常用策略模式实现。但如果支付流程本身有复杂的状态迁移（待支付 → 支付中 → 回调验证 → 已支付 → 退款中 → 已退款），有人会建议用状态模式管理这个流程。这时你该用哪个？

Claude Code 会给你两者的对比，但不会告诉你决策的关键考量：“支付渠道选择”的变化频率远高于“支付状态迁移规则”的变化频率。渠道可能每月新增，所以用策略模式隔离变化；状态规则是整个支付平台的基础契约，半年不变一次，过度抽象反而是浪费。这个判断是基于业务节奏的，不是基于设计模式定义的，AI 没有你的业务上下文，它做不出这个判断。

四、三大关键实验：单例、工厂、策略模式的 AI 生成深度解剖

现在是这篇文章最硬核的部分。我选择了三个最具代表性的设计模式，单例、工厂、策略，进行深度解剖。这三个模式分别代表了创建型、结构型-创建型交界、行为型三个类别，也是初级开发者最常“学完就用”但最容易用黄的三个模式。

对于每个模式，我会展示 Claude Code 生成代码中的典型“变体”和“陷阱”，然后从设计原则角度解释为什么这些陷阱值得警惕。

4.1 实验一：单例模式，AI 真的懂线程安全吗？

单例模式是设计模式中最简单、也是最容易出问题的。简单在于它的目标清晰，“一个类只有一个实例”，问题出在“怎么保证只有一个实例”这个实现细节上。

4.1.1 实验过程

Prompt（保持一致）： “请用 [语言] 实现一个线程安全的单例模式。”

我分别用 Java、Python、Go 各执行 5 次，共获得 15 个实现样本。

4.1.2 Java 单例：AI 的一致性很高，但变体选择暴露问题

Claude Code 在 Java 单例上表现出很高的一致性，80% 的样本采用了双重检查锁定（Double-Checked Locking, DCL）。这确实是最经典的写法。

AI 标准输出（DCL 写法）：

public class Singleton {
private static volatile Singleton instance;

private Singleton() {}

public static Singleton getInstance() {

if (instance == null) {

synchronized (Singleton.class) {

if (instance == null) {

instance = new Singleton();

}

}

}

return instance;

}

}

这个代码结构准确、惯用性高、健壮性也不差（volatile 防止指令重排，双重检查避免不必要加锁）。如果只看到这里，你会觉得 AI 完美解决了问题。

但问题藏在下一次追问里。

当我追问：“除了 DCL，还有哪些线程安全的单例实现？请对比它们的适用场景。”AI 给出了枚举单例、静态内部类单例、饿汉式单例等。到这里还是正确的。

当我再追问：“如果你的单例需要支持序列化和反序列化，这些实现会有什么问题？”AI 的回答开始模糊。它提到了 readResolve() 方法，但忽略了枚举单例天然防御序列化攻击的事实；它提到 DCL 需要额外处理 readObject，但没有解释为什么，因为 DCL 依赖 volatile 的语义仅限于 JVM 内存模型，不覆盖反序列化的对象重建过程。

关键发现：AI 的状态停留在“知识点”层面，没有形成“知识网”。 它知道 DCL 的代码怎么写、枚举单例的代码怎么写、序列化需要 readResolve，但它不会主动把这些知识点串联成一个攻防体系，除非你追问到具体的交叉领域。

4.1.3 Go 单例：AI 暴露了对语言特性的浅层理解

同样的 Prompt 在 Go 语言下，情况完全不同。

AI 初始输出（5 次中有 3 次）：

package singleton
import "sync"

type singleton struct {}

var instance *singleton

var mu sync.Mutex

func GetInstance() *singleton {

if instance == nil {

mu.Lock()

defer mu.Unlock()

if instance == nil {

instance = &singleton{}

}

}

return instance

}

这段代码在 Go 中是非惯用的。Go 标准库提供了 sync.Once，它的设计意图正是“确保一个函数只执行一次”，和单例的目标完全一致。用手写 sync.Mutex 的方式实现单例，不仅代码冗长，而且在极端并发下有微妙的性能差异（sync.Once 使用了原子操作+互斥锁的优化组合）。

更关键的陷阱是：上面的代码没有考虑 Go 的内存模型，instance 变量在极端情况下可能被 CPU 缓存，导致其他 goroutine 看到的 instance 不是最新的。虽然概率极低，但在高并发系统中这会是一座休眠火山。

Go 惯用写法：

package singleton
import "sync"

type singleton struct {}

var instance *singleton

var once sync.Once

func GetInstance() *singleton {

once.Do(func() {

instance = &singleton{}

})

return instance

}

两种写法在 99.99% 的场景下行为一致，但 Go 社区强烈偏好后者。为什么 AI 没给出后者的比例更高？ 因为 AI 的模式匹配是基于它训练数据中的模式频率的。DCL 模式在 Java/C++ 中是主流，AI 把这种习惯“迁移”到了 Go 语言中，忽略了 Go 自有生态的方案。

这对学习者的影响是什么？ 如果你是一个 Go 新手，用 Claude Code 学习单例模式，你很可能会学到一种“能在 Go 中运行的 Java 单例”，而不是“符合 Go 设计哲学的单例”。你在无知觉中吸收了另一种语言的思维习惯。

4.1.4 Python 单例：AI 对动态语言的“过度设计”

Python 单例又是一个截然不同的故事。

AI 初始输出（5 次中有 4 次采用元类）：

class SingletonMeta(type):
_instances = {}

def __call__(cls, *args, kwargs):

if cls not in cls._instances:

cls._instances[cls] = super().__call__(*args, kwargs)

return cls._instances[cls]

class Singleton(metaclass=SingletonMeta):

pass

这个实现从技术上没有问题，元类是 Python 实现单例的标准方式之一，能处理继承和多线程（如果加上锁）。但问题在于：在 Python 中，大多数“单例”场景压根不需要元类。

Python 有模块级单例，模块在第一次导入时初始化，后序导入共享同一个对象。如果你的单例不需要懒加载，模块级变量就是天然的线程安全单例。很多情况下，一个简单的模块级实例就够了，元类单例是杀鸡用牛刀。

当我把这个观点告诉被 AI “教”会了元类单例的同事时，他愣住了。他不是不知道模块级单例，而是 AI 从来没提过这个选项，因为他的 Prompt 是“实现线程安全的单例”，AI 自动跳到了“需要显式保证线程安全”的思维框架里，忽略了 Python 模块导入本身就是线程安全的。

这里有一个更深层的教训：AI 生成的代码是基于你的提问框架的。 你问“怎么实现线程安全的单例”，它就给你一个主动管理线程安全的实现。你问“Python 中最简单的单例是什么”，它才会告诉你模块单例。你的提问水平，决定了你能从 AI 那里获得的信息层次。

4.1.5 单例实验的核心教训

1. 不要用单例模式作为判断 AI 代码质量的基准。 因为单例太简单，AI 很容易给出“看起来对”的实现。但“对”和“好”之间的差距，惯用性、语言特性利用、极端并发处理，正是 AI 的短板。
2. 不同语言的单例“最佳实践”差异巨大。 用 AI 学单例时，一定要追问“这个实现是 [语言] 社区推荐的吗？”或者“有没有更符合 [语言] 习惯的写法？”
3. 单例是对抗反序列化攻击、反射攻击、克隆攻击的“重灾区”。 AI 生成的单例默认不设防，如果你把它用于生产环境，需要自行验证这些攻击面。

4.2 实验二：工厂模式，当 AI 给出一个“超重”的工厂

工厂模式是另一个 AI 频繁交出“表面漂亮、结构臃肿”答卷的重灾区。问题不在于 AI 写不出工厂，而在于 AI 倾向于写出“过度设计”的工厂，它在没有明确约束的情况下，会把简单工厂、工厂方法、抽象工厂三者混在一起，产出一个四不像的“万能工厂”。

4.2.1 实验过程

Prompt： “请用工厂模式实现一个跨平台的 UI 按钮创建系统，支持 Windows 和 Mac 两种平台。”

追问 Prompt： “这个实现违反了哪些设计原则？请自我评估。”

这个追问是整个实验的精华，它不是让我来挑错，而是让 AI 自己识别自己的问题。

4.2.2 AI 的初始输出：一个过度膨胀的“超级工厂”

Claude Code 的初始输出通常包含以下结构（以 Java 为例）：

// 产品接口
interface Button { void render(); }

// 具体产品

class WindowsButton implements Button { ... }

class MacButton implements Button { ... }

// 工厂接口

interface GUIFactory {

Button createButton();

}

// 具体工厂

class WindowsFactory implements GUIFactory {

public Button createButton() { return new WindowsButton(); }

}

class MacFactory implements GUIFactory {

public Button createButton() { return new MacButton(); }

}

到这里还是标准的抽象工厂模式。问题出现在 AI 往往会“贴心”地追加一个工厂提供者类：

class FactoryProvider {
public static GUIFactory getFactory(String osType) {

if ("Windows".equalsIgnoreCase(osType)) {

return new WindowsFactory();

} else if ("Mac".equalsIgnoreCase(osType)) {

return new MacFactory();

}

throw new IllegalArgumentException("Unknown OS");

}

}

加上一个客户端代码示例：

public class Application {
private Button button;

public Application(GUIFactory factory) {

button = factory.createButton();

}

public static void main(String[] args) {

String os = System.getProperty("os.name");

GUIFactory factory = FactoryProvider.getFactory(os);

Application app = new Application(factory);

app.button.render();

}

}

这个代码的问题在哪里？ 表面上，它使用了抽象工厂模式，通过多态解耦了产品和创建逻辑。但 FactoryProvider.getFactory() 这个方法，实际上是一个伪装的简单工厂，它根据一个字符串参数决定返回哪个具体工厂。

4.2.3 追问后的自我评估：AI 的批判性反省

当我给出追问 Prompt，“这个实现违反了哪些设计原则？”，Claude Code 的自我评估出奇地诚实且准确：

AI 的自我评估输出：

1. 开闭原则（OCP）： 当新增 Linux 平台时，需要修改 FactoryProvider 中的 if-else 分支，而不是扩展现有代码。
2. 单一职责原则（SRP）： FactoryProvider 同时负责工厂创建和平台判断两个职责。
3. 依赖倒置原则（DIP）： Application 的 main 方法依赖了具体类 FactoryProvider，违反了“高层模块不应依赖低层模块”。

这个自我评估完全正确，而且是我自己如果在代码评审中也会指出的问题。

但这引出了一个更重要的问题：如果 AI 知道自己生成的代码违反了设计原则，为什么不在第一次生成时就避免？

答案在于 AI 没有“设计约束意识”。它生成代码时优先级是这样的：

1. 第一优先：满足 Prompt 的基本要求（“工厂模式”、“跨平台”、“按钮”）
2. 第二优先：给出一个可运行的完整示例
3. 第三优先：让代码结构看起来有层次感（这可能解释了为什么它喜欢加额外层）
4. 未激活的优先级：符合 SOLID 原则、满足极端场景

换句话说，AI 默认的生成策略是“先求全，再求问”。它不会主动应用设计约束，除非你的 Prompt 中明确包含了这些约束，或者你像做代码评审一样追问它。

4.2.4 如果我需要的是一个“简单工厂”呢？

这是很多实际项目中的真实情况，你只需要根据一个配置参数创建不同对象，不需要完整的抽象工厂。但 AI 很少给出简单工厂，除非你明确要求。

当我调整 Prompt 为：“只需要一个根据操作系统类型返回按钮工厂的简单工厂，不需要抽象工厂层级”，AI 的输出立即变得简洁：

class ButtonFactory {
public static Button createButton(String osType) {

switch (osType.toLowerCase()) {

case "windows": return new WindowsButton();

case "mac": return new MacButton();

default: throw new IllegalArgumentException("Unsupported OS");

}

}

}

关键洞察：AI 的“默认档位”是过度设计，而非恰到好处。 这一点对学习者的影响是深远的，如果你没有明确的设计约束能力（什么时候用简单工厂就够了，什么时候需要抽象工厂），AI 会“教”你一种默认的复杂方案，而你因为缺乏对比，会以为这就是标准做法。

4.2.5 工厂实验的核心教训

1. 工厂模式的本质不是“用一个类来 new 对象”，而是“解耦创建逻辑和使用逻辑”。 AI 能生成后者的结构，但不能帮你判断“这个解耦在当前场景下是否过度”。
2. FactoryProvider 这类“工厂的工厂”是 AI 过度设计的红旗标志。 当你看到 AI 的代码中出现这种模式，立刻追问：“去掉这个类会怎样？”你会惊讶地发现，大部分场景下它根本不需要。
3. 学习工厂模式时，最好的方式是让 AI 生成三种变体（简单工厂、工厂方法、抽象工厂）并对比它们的优缺点。 这种对比学习的效果远好于学一个标准实现。

4.3 实验三：策略模式，AI 容易陷入的“类海洋”陷阱

策略模式是我实验中发现 AI 表现最稳定的模式，但稳定不代表没问题。问题不在代码错误上，而在 AI 生成的策略模式有一种“把一切行为都抽象成独立类”的倾向，这会导致所谓的“类爆炸”。

4.3.1 实验过程

Prompt： “请用策略模式实现一个电商折扣计算系统，支持以下策略：无折扣、满减折扣（满300减50）、百分比折扣（8折）、VIP折扣（根据VIP等级浮动）。要求易于扩展新策略。”

4.3.2 AI 的标准输出

Claude Code 对这个 Prompt 的响应通常是教科书级别的：

// 策略接口
interface DiscountStrategy {

BigDecimal calculate(BigDecimal originalPrice, Customer customer);

}

// 具体策略

class NoDiscount implements DiscountStrategy { ... }

class FullReductionDiscount implements DiscountStrategy { ... }

class PercentageDiscount implements DiscountStrategy { ... }

class VIPDiscount implements DiscountStrategy { ... }

// 上下文

class PriceCalculator {

private DiscountStrategy strategy;

public PriceCalculator(DiscountStrategy strategy) {

this.strategy = strategy;

}

public BigDecimal calculate(BigDecimal price, Customer customer) {

return strategy.calculate(price, customer);

}

}

结构准确性：5 分。可扩展性：5 分。 但这张漂亮的类图背后，藏着三个实际开发中的陷阱。

4.3.3 陷阱一：策略类之间的隐式依赖

看 VIPDiscount 的实现细节：

class VIPDiscount implements DiscountStrategy {
public BigDecimal calculate(BigDecimal originalPrice, Customer customer) {

int vipLevel = customer.getVipLevel();

if (vipLevel == 1) return originalPrice.multiply(new BigDecimal("0.95"));

if (vipLevel == 2) return originalPrice.multiply(new BigDecimal("0.90"));

if (vipLevel == 3) return originalPrice.multiply(new BigDecimal("0.85"));

return originalPrice;

}

}

这段代码有个微妙的坏味道：VIP 等级的折扣规则硬编码在策略类内部。 如果营销部门明天调整了 VIP 折扣表（从固定折扣改为根据消费额度阶梯折扣），你需要修改 VIPDiscount 类的代码，这违反了开闭原则。

更隐蔽的问题是：VIPDiscount 和 Customer 类之间产生了强耦合。它需要调用 customer.getVipLevel()，这意味着：

• Customer 类的接口变化会影响 VIPDiscount
• 单元测试必须构造完整的 Customer 对象
• 如果另一个折扣策略也需要 VIP 信息（比如满减 + VIP 叠加），它也会耦合到 Customer

AI 没有识别这个坏味道，因为它不关心“什么会变”。它只保证当前代码满足功能需求。

4.3.4 陷阱二：“策略上下文”的权力边界模糊

PriceCalculator 承担了策略的持有和调用职责。但在实际业务中，这个“上下文”很快会膨胀：

class PriceCalculator {
private DiscountStrategy strategy;

private CouponService couponService;  // 新需求：优惠券叠加

private TaxCalculator taxCalculator;   // 新需求：税费计算

public BigDecimal calculate(BigDecimal price, Customer customer) {

BigDecimal discounted = strategy.calculate(price, customer);

// 这里开始出现复杂逻辑：折扣和优惠券谁先算？税基是什么？

BigDecimal afterCoupon = couponService.applyCoupons(discounted, customer);

return taxCalculator.calculateTax(afterCoupon, customer.getRegion());

}

}

PriceCalculator 从策略模式的“上下文”变成了一个业务流程编排器。它不再仅仅是“持有一个策略并调用它”，而是开始承担业务规则编排的职责。这个演化是自然的、正确的，但策略模式的标准 UML 图没有覆盖这个问题，因为它假设上下文只是一个策略的容器。

AI 生成的策略模式代码，上下文永远是轻量级的、只做策略代理的。你拿着这个代码投入生产，一个月后 PriceCalculator 就会发福成一个 500 行的怪物。

4.3.5 陷阱三：函数式替代方案被系统性忽略

这是 AI 生成策略模式时最让我遗憾的地方。在 Python 和现代 Java（8+）中，很多策略模式的场景根本不需要一组独立的类。

Python 的函数式替代：

def no_discount(price, customer):
return price

def full_reduction(price, customer):

return price - 50 if price >= 300 else price

def percentage_discount(rate):

return lambda price, customer: price * rate

使用时

strategy = percentage_discount(0.8)

final_price = strategy(999, customer)

这段代码用函数替代了四个类，行为完全等价，代码量减少 70%，可读性反而提升。

Java 8+ 的 Lambda 替代：

Map> strategies = new HashMap<>();
strategies.put("NO_DISCOUNT", (price, cust) -> price);

strategies.put("FULL_300_MINUS_50", (price, cust) ->

price.compareTo(new BigDecimal("300")) >= 0 ? price.subtract(new BigDecimal("50")) : price);

strategies.put("PERCENT_80", (price, cust) -> price.multiply(new BigDecimal("0.8")));

这个实现不需要 DiscountStrategy 接口，不需要四个实现类，不需要工厂。它用语言的一等公民，函数，解决了策略模式要解决的问题。

为什么 AI 默认不生成这种实现？ 因为训练数据中策略模式的示例绝大多数是“接口+实现类”的 OOP 经典写法。函数式变体在代码库中的比例远低于经典写法，AI 自然倾向于生成主流模式。但作为学习者，你需要知道：设计模式的精神是“封装变化”，不是“多写几个类”。 函数式和 Lambda 是更轻量的封装手段。

4.3.6 追问 AI：“如果我有 20 种折扣策略，这个设计还能用吗？”

这是我做的一个压力测试追问。Claude Code 的回答非常务实：

“当你拥有 20 种折扣策略时，类爆炸确实是一个问题。建议引入以下优化：

1. 使用注册表模式管理策略实例
2. 将可参数化的策略合并（如所有满减策略使用同一个参数化实现）
3. 考虑使用规则引擎替代硬编码策略”

这个建议是专业的。但请注意，这个专业建议是在我追加了“20 种策略”的压力条件下才出现的。如果初始 Prompt 没有这个约束，AI 不会主动考虑类爆炸问题，因为它默认你的策略数量是个位数。

这验证了我的核心论点：AI 的代码质量高度依赖于你的提问深度。 它不是没有能力生成高质量代码，而是默认不激活“设计评估”能力，你需要用追问来触发它。

4.3.7 策略实验的核心教训

1. 策略模式的本质是“算法可替换”，不是“多写类”。 用 AI 学习时，主动要求它对比 OOP 实现和函数式实现的差异，这是理解模式本质的最佳途径。
2. 上下文类的职责膨胀是生产环境的常见问题，但 AI 的代码从来不展现这个演化过程。 你需要在 AI 代码的基础上，主动思考：“三个月后这个类会长成什么样？”
3. “类爆炸”是策略模式在大型系统中必然面临的问题。 AI 能帮你生成漂亮的初始代码，但设计注册表、策略组合、规则叠加这些进阶话题，需要你自己追问。

五、高阶追问：苏格拉底式 Prompt 如何改变 AI 输出的质量

经过三个实验的详细解剖，你可能会问：既然 AI 有这么多陷阱，是不是每次都需要人工深度评审才行？答案是：不一定需要手动评审所有的，但需要建立一套追问系统。

我在实验中最有价值的发现是：同样的 Claude Code，用不同的追问方式，输出质量可以差出两个等级。 这部分分享我总结的苏格拉底式追问框架。

5.1 什么是苏格拉底式追问？

苏格拉底式追问的核心不是“给我更好的代码”，而是“让我理解你的设计决策”。它不是结果导向（“对不对”），而是过程导向（“为什么这么选择”）。

我把它归纳为四层追问：

5.2 每一层追问的具体示例

第一层（定义追问）示例：

• “你生成的这个工厂模式是简单工厂、工厂方法还是抽象工厂？请给出判断依据。”
• “代码中的 DiscountStrategy 接口是策略模式的核心角色吗？它和 State 模式的状态接口有什么区别？”

这一层的作用是校准 AI 的概念准确性，同时逼你自己建立“结构-定义”的映射。

第二层（约束追问）示例：

• “如果我的 UI 系统需要支持 Linux 平台，当前代码的改动点在哪里？如果支持 20 个平台呢？”
• “如果折扣规则需要支持‘满减+百分比’叠加，当前设计需要推倒重来吗？”

这一层的作用是测试代码的可扩展性，这是 AI 输出最薄弱的环节。好的设计在新增需求时改动量小且局部；差的设计需要骨架改造。

第三层（原则追问）示例：

• “请用 SOLID 原则逐条检查你的代码，找出违反的地方并给出重构方案。”
• “你生成的这段代码，和 GoF 原书中该模式的‘意图’描述有偏差吗？偏差在哪里？”

这一层是AI 的自我批判能力测试。我惊讶地发现，Claude Code 在这层追问下表现出了相当诚实的自我评估能力，它会主动指出自己的代码违反了 OCP 或 DIP，并给出改进建议。这说明 AI “知道”什么是更好的设计，只是默认不激活这个能力。

第四层（演化追问）示例：

• “一年后这个支付系统每天处理 500 万笔订单，当前设计在并发和内存分配上有什么瓶颈？”
• “如果团队人数从 3 人扩展到 30 人，每个人都要修改策略模式相关的代码，当前设计在协作上有什么问题？”

这一层是培养架构敏感度。AI 的回答通常会指出缓存、连接池、分布式一致性等问题，驱动你从“代码层面”上升到“系统层面”。

5.3 具体数据：追问前后 AI 输出质量对比

我在 10 个设计模式上做了对比实验。每个模式先生成一个“基础实现”（一次 Prompt），然后用苏格拉底追问四层框架进行深度追问，观察最终输出的变化。

追问前后的质量变化统计（10 个模式 × 2 个版本 = 20 个样本）：

健壮性的提升幅度最大（29%），原因在于追问过程触发了 AI 对并发、异常处理、边界条件等“隐藏需求”的考虑。这些在初始 Prompt 中很少被主动提及，但在追问中被迫浮出水面。

5.4 把苏格拉底追问变成肌肉记忆

分享一个实操建议：在 Claude Code 里创建一个“设计评审人格”的 System Prompt。

我不是在卖 Prompt 模板，但这是我经过多次迭代后沉淀下来的有效方式：

在对话开始时（或项目初期），给 Claude Code 设置这样一个角色：

> “你是一个严格的设计评审专家。在我每次让你生成设计模式代码后，你需要主动指出至少一个可改进的设计问题。你的评审维度包括：SOLID 原则符合度、设计模式使用恰当性、代码可扩展性、语言惯用性和健壮性。不要等我追问，每次生成代码后自动附上评审意见。”

这个简单的角色设定，能显著提高 AI 的“设计约束意识”。在我测试中，设置了“设计评审人格”后，AI 初始输出的健壮性和可扩展性评分平均提升了 15-20%。

但有一个副作用需要注意：AI 在评审模式下有时会“过度自我批评”，指出一些不构成实际问题的细节。我的经验是保留这个人格，但给它加一句约束：“指出的问题必须是中等严重度以上的设计问题，不要纠结于命名或格式等低优先级细节。”

六、反思与框架：AI 辅助学习设计模式的三阶段模型

基于三个月的实验和 200+ 个代码样本，我归纳出一个三阶段模型。这不是一个理论框架，而是我观察到自己和学习小组中其他人的真实进化路径。

6.1 阶段一：代码消费者（Code Consumer）

特征：

• 依赖 AI 生成代码，不加批判地接受
• 追求“跑通”而不是“理解”
• 注意力在“怎么写”而不在“为什么这么写”
• 学习路径：需求 → Prompt → 复制代码 → 运行测试

典型行为：

“Claude，给我写一个线程安全的单例。好的，代码扔进项目，启动没报错，搞定。”

这一阶段的陷阱：

你在学习 Claude Code 的代码风格，而不是设计模式的思想。你吸收的是 AI 的偏好（DCL、万能工厂、类爆炸），误以为它们是标准答案。

识别信号：

如果你看到一个设计模式代码，只能评价“能跑”或“跑不了”，而不能评价“好在哪”或“坏在哪”，你就在阶段一。

6.2 阶段二：设计评审者（Design Reviewer）

特征：

• 主动对 AI 生成的代码提出批判
• 开始追问“为什么”而不是“怎么写”
• 能识别出“伪模式”和过度设计
• 学习路径：需求 → Prompt → 审查代码 → 追问 → 对比分析 → 重构

典型行为：

“Claude，你生成的这个工厂模式里的 FactoryProvider 是不是违反了开闭原则？去掉它会怎样？请给出没有 FactoryProvider 的版本，对比两者的扩展成本。”

这一阶段的拐点：

你开始意识到 AI 是信息源，不是答案。 你不再问“这样对不对”，而是问“这样好不好”。你开始享受和 AI 辩论设计决策的过程，因为你知道，辩论过程中你的理解在加深。

这是学习效率最高的阶段。 在这个阶段，AI 扮演的是“一个反应极快但缺乏判断力的高级实习生”，它能源源不断地产出代码方案，但由你来判断方案的优劣。这种高密度的“方案生成+评审”循环，在传统学习方式中不可能实现。

6.3 阶段三：模式设计师（Pattern Designer）

特征：

• 不再依赖 AI 生成模式代码，而是用 AI 探索模式的边界
• 能在具体业务场景中判断“这里该不该用模式”
• 能识别何时模式会成为负担
• 学习路径：业务需求 → 识别变化维度 → 选择模式（或不选）→ 用 AI 验证方案 → 手动实现核心逻辑

典型行为：

“这个支付路由场景有三个变化维度：渠道、优惠规则、结算周期。渠道适合策略模式，优惠规则适合责任链，结算周期不需要模式，直接用配置表。Claude，帮我验证这个判断：用策略模式实现渠道部分，看看我的接口定义是否合理。”

这一阶段的标志：

AI 从“老师”退位为“助手”。你主导设计决策，AI 负责快速验证和原型生成。你不再问“这个模式对不对”，而是问“用这个模式在这个场景下，三个月后的维护成本是多少”。

我现在勉强摸到了这个阶段的边。 说实话，23 个模式中我还有大约 5 个模式（访问者、解释器、备忘录等）停留在阶段二，因为这三个月中这些模式在我的工作项目中很少用到，缺少真实场景的验证。

6.4 我踩过的最大的坑：在阶段一停留太久

坦白说，我的第一个月实验就是在阶段一度过的。我沉迷于“让 AI 生成各种变体”的效率快感里，看着 23 个模式的代码一个个被生成出来，有一种虚假的掌握感。

直到有一天下班前，同事让我评审他写的一个观察者模式实现，一个我自认为已经“通过 AI 学会”的模式。我盯着他的代码看了五分钟，一个字都说不出来。我知道它的结构，但我说不出它哪里不好。

那一刻我意识到：我看似学会了，实际上只是“看熟”了 AI 的代码风格。 当面对一个人类写出的、带有微妙缺陷的实现时，我没有任何判断力。

如果你现在正在用 Claude Code 学习设计模式，我强烈建议你做这个自测：找一个同事手写的设计模式代码（或者 GitHub 上的开源项目片段），尝试独立评审。如果你只能说“结构对”或“结构不对”，而说不出“为什么好”或“为什么不好”，立刻切换到阶段二的追问模式。

七、场景化建议：不同情况下如何最大化 AI 的学习价值

前三章是“道”和“法”的层面，误区和框架。这一章是“术”的层面，具体场景下的操作建议。设计的出发点是：不同学习阶段、不同项目类型，AI 的使用策略应该完全不同。

7.1 场景一：你是设计模式初学者

你的处境： 刚读完 GoF 原书或者某个教程的工厂模式章节，概念懂了但写不出代码，或者写出来总觉得别扭。

AI 的正确用法：

1. 用 AI 做“代码翻译”，不做“代码生成”。 把 GoF 书中的 C++ 示例交给 Claude Code：“请把这个 C++ 的工厂方法模式示例翻译成 Python，保留原书的结构和设计意图。”这比让它从零生成要好，因为你有标准答案可对照。
2. 建立“定义-代码”的双向映射。 每学一个模式，做两个练习：

• 正向：给 AI 模式定义 → 让它生成代码 → 你在代码中标注角色（谁是 Creator、谁是 Product）
• 反向：给 AI 一段未知代码 → 让它判断使用了哪些模式 → 你对答案

用多语言对比加深理解。 同一模式，让 AI 生成 Java、Python、Go 三个版本，对比它们的差异。差异处才是模式本质和语言特性的交界点，是学习的富矿区。

AI 的错误用法（我亲眼见过的）：

• 直接让 AI 生成一个模式的所有代码，然后读代码试图理解（效率极低，因为缺乏对照系）
• 用 AI 替代阅读 GoF 原书（关于为什么不行，文章第三节已经详细论述过）
• 只看 AI 生成的一种语言版本，得出“我学会了”的结论

7.2 场景二：你是有项目经验但模式基础薄弱的开发者

你的处境： 写了几年代码，日常工作中可能无意识地用过一些模式，但没有系统学过。现在想做架构设计或系统重构，需要补上设计模式这一课。

这是 AI 辅助学习设计模式的黄金场景。 你有真实项目作为锚点，AI 的价值从“教”变成了“连接”，它能把你的经验和教科书知识连接起来。

推荐路径：

1. 从你已经“半用过”的模式开始。 翻出你最近三个月的代码提交，找出一段你觉得“写得挺优雅”但不确定是不是设计模式的代码。交给 Claude Code：“这段代码使用了什么设计模式？（如果没有使用，它可能适合用哪个模式重构？）”
2. 用真实业务场景驱动学习。 不要按 GoF 目录学。从你当前 Sprint 的需求里提取场景：“我下周要实现一个动态表单生成器，不同用户角色看到的表单项不同，哪种设计模式适合？”AI 会推荐可能的模式，你再深入学那一个。
3. 重写你过去的“烂代码”。 找到你项目中一段100行以上的 if-else 分支或 switch-case（这种代码每个项目都有），交给 AI：“这段代码根据 X 条件执行不同逻辑，请用策略模式重构它。”

一个我个人验证过的练习：

在实验期间，我翻出了2019年写的一个报表生成模块，一个1200行的 God Class，根据不同的报表类型用巨型 switch-case 生成不同的 Excel。那时候我不知道策略模式，这是我的历史债务。

我把它交给 Claude Code：“请用策略模式 + 工厂模式重构这段代码。”30 秒后，AI 给出了重构版本，一个 ReportStrategy 接口，8 个具体策略类，一个 StrategyFactory。代码量增加到 1500 行，但每个类不超过 80 行，单测覆盖率从 0 提到了可行的架构。

但这不是最重要的。最重要的是：我对比了我当年的烂代码和 AI 的重构版本，就像看“恐怖电影前-后对比照”一样。 这种视觉冲击比任何教科书示例都深刻，因为那烂代码是我亲生的。

7.3 场景三：你在做代码评审，需要快速识别设计问题

你的处境： 同事提交了一个使用了设计模式的 PR，你需要在半小时内判断这个模式用得是否恰当。

AI 的加速用法：

1. 粘贴代码 + 一句话 Prompt： “这段代码使用了 XXX 模式，请从 SOLID 原则和模式使用恰当性两个维度给出评审意见。”
2. 追问链： 如果 AI 指出了问题，追问：“这个问题在什么业务场景下会变成事故？”（逼 AI 具象化风险）
3. 让 AI 生成“对比方案”： “请给出不使用这个模式、但能完成同样功能的最简实现，对比两者的优劣。”

我的实战经验：

在实验期间，我评审过一个同事的“装饰器模式实现日志系统”。PR 里有 6 个装饰器类，每个包装一层日志逻辑。AI 在 10 秒内指出了我15分钟才看出来的问题：“这些装饰器的顺序会影响日志输出的格式，如果顺序不对，Stack Trace 会丢失信息。这是装饰器模式的顺序敏感性问题，当前实现没有防御。”

这是我以前不知道的，装饰器的顺序敏感性在 GoF 原书中有提及，但我从没在实战中遇到过。AI 的评审帮我补上了这个盲区。

7.4 场景四：你在设计一个新系统，需要选型

你的处境： 新项目启动，你有机会从零设计架构，不想重复过去的“补丁式设计”。

AI 的用法和边界：

AI 在这个场景下不适合直接给你推荐模式，因为模式选择依赖于业务上下文，而 AI 没有你的上下文。

有效的用法是：

1. 描述业务场景 → 让 AI 列出可能的模式 → 你自己根据业务判断选择哪一个。 不要让 AI 替你选。
2. 让 AI 模拟“时间考验”： “如果选择策略模式处理支付路由，一年后支付渠道从 3 个扩展到 20 个，这个设计会有什么问题？如果选择规则引擎呢？”
3. 生成两种方案让它们“互相攻击”： “请分别以策略模式支持者和规则引擎支持者的身份，辩论在支付路由场景下各自方案的优劣。”

最后这个用法我在实验中试了 3 次，效果超出预期。AI 生成的辩论暴露了我自己没想到的盲点，比如策略模式在支付路由中难以处理“渠道优先级+熔断”的组合逻辑，而规则引擎在这方面天然支持。

一个坦诚的提醒： 架构选型没有银弹。AI 能帮你加速方案生成和对比，但最终决策只能由你做出，因为你要为这个决策负责 3 年，AI 不需要。

八、超越代码：用 AI 培养“设计嗅觉”

前面七章都在讲代码和分析代码，这一章我想讲一点更“虚”但更重要的东西。

设计模式学到深处，不是背下 23 个类图，不是写出符合 UML 的代码，而是培养出一种设计嗅觉，你看到一个需求，本能地感知到它有哪些变化维度、哪里该抽象、哪里该写死。

AI 能不能培养这种嗅觉？我最初是悲观的。但三个月的实验改变了我，AI 可以加速这种嗅觉的培养，但方式不是“教你”，而是“让你看到对比”。

8.1 通过“变体对比”建立判断力

传统学习路径上，你学工厂模式时看到的是教科书上的标准示例，一个不变的、完美的 UML 图。你永远不会看到这个模式用错时的样子，除非你在项目中亲自用错一次。

AI 时代的优势是：你可以让 AI 刻意生成“用错了的模式”，然后用这些反面案例训练自己。

我在实验中刻意要求 Claude Code 做的一件事：“请用工厂模式实现这个需求，但故意犯三个常见的误用错误。”它生成的“错误版本”包括：

• 把简单工厂叫做抽象工厂
• 在不需要产品族的情况下使用了抽象工厂（过度设计）
• 把工厂方法和静态工厂方法搞混

研究这些错误案例，比研究正确案例更有教学价值。因为正确案例只能告诉你“这样做”，错误案例能告诉你“为什么不能那样做”。

8.2 通过“模式边界探索”培养取舍能力

设计模式最难的不是“怎么用”，而是“什么时候不用”。大多数教程只讲前者，不讲后者。

我在实验中发展出一个有效的练习：让 AI 用和不使用某个模式分别实现同一个需求，然后自己判断哪个版本更好。

例如，一个简单的表单校验逻辑（3 个字段，校验规则固定）：

• 使用策略模式： 一个 ValidationStrategy 接口 + 3 个具体策略类 + 一个 Context
• 不使用模式： 3 个 if 语句

在这个场景下，不使用模式的版本更好，代码更短、更易读、维护成本更低。策略模式的抽象层在这里纯粹是噪音。

但这种判断力的前提是：你能同时看到两种实现。 传统学习里你看不到“不用模式”的版本，因为教材假设你已经过了“该不该用”的阶段。AI 让你可以随时对比，这正是它加速判断力培养的机制。

8.3 通过“跨模式对比”区分相似模式

有一些设计模式在结构上极其相似：策略和状态、装饰器和代理、工厂方法和模板方法。GoF 书中有详细的概念对比，但纯文字对比很难内化，你需要“看代码对比”。

我用 Claude Code 做了一个练习：“请用策略模式和状态模式分别实现一个文档编辑器的打印功能（策略：不同打印机使用不同打印逻辑；状态：文档在草稿、审核、发布三个状态下打印行为不同）。”

两个实现的代码并排放在一起，相似结构之下的设计意图差异就显性化了：

• 策略模式的上下文是静态的，选择策略后，打印行为就固定了
• 状态模式的上下文是动态的，状态变化后，打印行为自动切换

这个差异在代码中一目了然，但在纯概念描述里总是模糊的。AI 的“瞬时生成代码对比”能力，让这种对比学习变得零成本。

九、总结与行动建议

三个月，200+ 代码样本，23 种设计模式，三种编程语言。

结论不是“AI 是好工具”或“AI 不可信”这种二元判断，而是更精确的：

Claude Code 是一个极佳的设计模式学习加速器，但它加速的是你的“信息输入”，不是你的“判断力形成”。 如果你把它当答案手册用，你的设计能力会在“看起来都懂、一评审就懵”的水平上停滞。如果你把它当辩论对手用，不断追问、对比、质疑、重构，你的设计嗅觉会在短时间内产生质的飞跃。

如果你只能带走三个建议：

建议一：永远不要让 AI 的第一个回答成为你的最终理解。

AI 的初始输出是“广度优先”的，它试图覆盖功能需求，但不保证设计质量。把第一次输出当作对话的起点，而不是结论。追问一次，价值翻倍；追问四层（定义-约束-原则-演化），价值乘十倍。

建议二：用多语言对比打破 AI 的语言偏见。

不要把设计模式绑死在一种语言上。同一模式用 Java、Python、Go 各跑一遍，观察 AI 代码的差异。那些差异背后，是设计模式的本质和语言特性的交汇点，学透一个交汇点，胜过背下十张类图。

**建议三：建立你的“反面案例库