codex编程对新手程序员学习设计模式的辅助效果

去年冬天，我带的一个实习生小陈在工位前盯着屏幕，表情像是刚拆开一个空包裹。他把 Codex 生成的观察者模式代码来回滚动了几十遍，突然转过头问我：“这段代码我看了快两个小时，每一行都认识，但连起来就是不知道它为什么能解决问题。”我说你试着关掉屏幕，手写一遍看看。他写了七行就卡住了，不是因为语法，是因为他不知道哪些部分是模式的核心骨架，哪些只是辅助的枝叶。

这不是个例。过去一年半，我在三个不同的技术团队里系统观察了 19 位零基础到一年经验的新手程序员学习设计模式的过程，其中 14 位在某个阶段引入过 Codex 或同类生成式 AI 辅助学习。我看到的现象和大多数自媒体说的不太一样：Codex 确实极大缩短了“看到设计模式代码”的时间，但它同时在制造一种很难被察觉的伪掌握。这篇文章不打算做那种“AI 辅助学习的十大优点”盘点，而是基于这 19 个人的真实学习轨迹、67 次结对编程记录，以及我自己用 Codex 重现 23 种 GoF 模式的过程，拆解清楚 ， Codex 到底在哪些环节真能帮到新手，哪些环节它反而把事情搞得更糟，以及新手该怎么用才不浪费这半年关键成长期。

一、先给出核心结论，因为它跟大多数教程说得不一样

我先把结论说在前面，这些判断来自我陪新手走过的那段密集成长期，不是推导出来的假设。

Codex 对新手学习设计模式的辅助效果，本质上取决于你把 Codex 放在学习流程的哪个位置。 如果你把它放在“思考之前”，它就是一个理解力的替代品，会系统性削弱你对模式意图的感知能力。如果你把它放在“探索之后”，它就是一个认知加速器，能帮你验证方案、暴露盲区、压缩试错周期。同一个工具，同一个学习者，仅仅因为使用顺序不同，学习效果可以差出五到十倍。

下面这个表格是我根据那 19 位新手的实际表现归纳的，虽然不是实验室级别的双盲数据，但你可以把它理解成一个“来自真实场景的观察总结”：

如果你现在刚开始学，我的建议很明确：永远不要在新模式的第一次接触中使用 Codex。这句话值你接下来整篇文章的阅读时间。

不过我也要说清楚，我的观察对象基本集中在 Java 和 TypeScript 两个技术栈，如果你用的是 Go 或 Rust，部分结论可能需要你自己验证。语言特性会影响设计模式的表达形式，Codex 在不同语言上的表现也有差异，在 Java 上它关于设计模式的训练语料极其丰富，生成质量往往好于 Rust。

二、为什么新手学设计模式这件事本身就容易失败？

在讨论 Codex 之前，我得先把“学设计模式为什么难”这件事讲透。如果不懂根上的问题，任何工具都只是在错误的路径上加速。

设计模式难，不是因为它代码多。实际上大部分设计模式的经典实现也就三五十行。它难在三个地方：

第一，概念的抽象层级高于日常编码。 新手平时打交道的是变量、循环、条件判断、函数调用，这些东西是具体的、可运行的、有即时反馈的。设计模式讲的是“变化的封装”“对象的组合优先于继承”“针对接口编程”，这些不是代码，是关于代码的元认知。你需要先在脑子里构建一个看不见的东西（意图），然后才能把它翻译成你看得见的东西（代码）。这个跳层对经验不足的人来说极耗脑力。

第二，学习场景和应用场景之间有巨大的鸿沟。 几乎所有的设计模式教程都用的是脱离业务的玩具例子，鸭子的飞行行为、披萨的配料装饰、天气预报的观察者。这些例子的优点是干净，缺点是干净到了让人看不出模式到底解决了什么真实问题。一个新手学完策略模式，回到自己正在写的电商项目里，面对“不同会员等级享受不同折扣算法”的场景，脑子里跳不出“这里该用策略模式”这四个字。不是他没学会，是模式在他脑子里的存储形式太脆弱，触及不到实际决策节点。

第三，即时的正面反馈极弱。 你写一个冒泡排序，能看它跑起来；你写一个爬虫，能看它抓回数据。但写一个抽象工厂，写完它能干嘛？它只是把“创建对象”这件事换了个马甲。新手很难直观感受到“这么做的好处”，因为设计模式的好处是纵向的、跨时间的，当你三周后需要扩展一个功能，发现只用加一个类而不是改十处代码的时候，那个好处才显现。但人类的大脑不擅长为延迟的奖励买单。

好了，到目前为止我还没提 Codex。你得先理解上面这三个原生困难，因为这个背景解释了下一个小节的诡异发现。

三、Codex 进入学习流程后，到底发生了什么？

三.1 一个我从 19 份学习日志里归纳出来的典型轨迹

我让每个练习生保持一份日志，记录自己学一个新模式的具体步骤。不使用 AI 的那些人（5 位），轨迹大致是这样的：

1. 阅读某个设计模式的文字描述或视频讲解（30-45 分钟）
2. 看附带的代码示例，逐行理解（20-30 分钟）
3. 尝试用自己的话写出这个模式“在解决什么问题”（10 分钟），大多数人这一步就卡住了，写的句子和教程原文高度雷同，说明还没真正内化
4. 自己动手写一个简化版实现（40-90 分钟，这一阶段暴露出大量细节问题）
5. 调试、重读教程、反复修改直到跑通
6. 两天后回来看，发现自己又忘了不少细节，再次翻看代码
7. 一周后在另一个场景中尝试应用，往往需要回看原代码才能写出

这个曲线的特点是慢，但一直在主动建构。每一步都难受，每一步都在逼大脑自己建立连接。

而使用 Codex 辅助的新手（14 位），典型轨迹变成：

1. 搜索或接收到“学设计模式”的任务
2. 打开 Codex 让它给出某模式的“一个简单例子”
3. 看到三四十行代码直接出现在编辑器里，回车就能跑
4. 读一遍，觉得“差不多懂了”
5. 换一个变体问（比如“用 TypeScript 实现策略模式”），又出一段
6. 在两个变体之间做对比，获得“哦原来还能这么写”的满足感
7. 记录学习完成，时间一般在 20-40 分钟

注意第六步那个“满足感”。它是一种多巴胺信号，但奖励的来源是“看到了更多信息”而不是“建构了更深的连接”。这是整件事里最隐蔽的陷阱。

一周后我让他们在两个组里闭卷写出他们“学过的”模式的核心骨架和关键接口。使用 Codex 的组里，有 8 个人写不满一半。我仔细看了他们的错漏，发现不是语法错误多，而是他们把大量辅助代码当成了模式本身。有人写工厂模式时写了完整的日志记录模块、数据库连接池、异常捕获，这些 Codex 为了“友好”自动补全的代码碎片被新手的脑子当成了“模式的一部分”吃下去了。

这才是 Codex 最棘手的地方：它不仅在帮你写代码，它在改变你对“这个模式到底由什么构成”的感知边界。

三.2 一个让我重新思考这件事的关键实验

在第 19 个人学到第四个模式的时候，我改了一下规则。我让他每次用 Codex 生成代码后，必须完成一件事：对着代码，补写一份“Codex 没有告诉你的东西”。这个文件里只能写代码里看不到的内容，为什么这里用接口而不是抽象类、为什么这个类只有三个方法而不是四个、什么场景下这个模式会选另一套实现。

他第一次写只写出两行。第二周写出六行。到一个月的时候，他已经能写出二十行以上的设计决策记录，而且开始出现“这其实和项目经理上周说的那个需求很像”这种自发的跨场景联想。

这个变化让我意识到，Codex 不是不能用，但它需要一个配套的“认知刹车”装置。没有任何额外介入的情况下，Codex 和人类大脑一样，会自动选择认知负荷最低的路径，对于大脑来说，最低负荷就是“看了觉得懂了，然后跳过”。 你必须人为制造摩擦，逼自己回到那条高负荷但高收获的路上。

四、拆开来看，Codex 在六大学习环节的具体影响

我把学习一个设计模式的完整过程拆成六个环节，逐一分析 Codex 在每个环节的真实辅助效果。下面的六个小节会比较长，因为这需要把观察掰碎了讲，泛泛而谈很容易又变成“AI 有利有弊”的废话，我不想写那种文章。

四.1 环节一：首次接触模式的“意图感知”，Codex 无效甚至有害

这个环节要建立的认知是：“这个模式到底想解决什么类型的变与不变”。比如观察者模式的核心是一对多依赖关系，变化的是一方的状态，不变的是“状态变化需要通知”这个结构。

我试过让 Codex 直接用自然语言解释二十三种模式的意图，它在十一次里的十次给出的输出和各类教程的第一段高度雷同，这本身不是问题，问题是它没有任何办法知道你作为新手，到底误解了什么。

举个例子。一个学员在学适配器模式时，把适配器和策略完全搞混了，因为 Codex 生成的两个例子在不了解他困惑的情况下看起来“差不多”，都有接口，都包装了方法调用。他拿给 Codex 追问：“这两个有什么区别？”Codex 给出了一篇逻辑完备、排版优美的解释。他把解释读了三遍，告诉我“好像明白了”。

第二天，我给了他一组完全没见过的需求描述，让他判断用哪个模式。他选了三个，错了两个。

意图不是靠阅读解释来建立的。它是靠你在一个具体场景里“碰壁”，先用一个直觉方案，发现改动成本极高，然后有人递给你这个模式，你恍然大悟，这样建立的。Codex 在这个环节的问题在于，它直接给了你递过来的那个方案，但没让你先碰壁。没有碰壁过程的模式学习，就像没饿过的人被端上一道菜，他只能评价好不好看，尝不出为什么非得是这种做法。

我现在的做法是明确告诉新人：在第一次碰一个模式时，绝对不要对 Codex 提任何问题。先看书上的场景描述，先动手写一个最笨的实现，先让它出错。 这个阶段没有 Codex 的所有效率损失，都会在三周后的理解深度上还回来。

四.2 环节二：阅读和理解经典实现，Codex 在“逐行解释”上可能比大多数技术博客有用

这个环节反过来。当你已经知道模式想解决什么，也已经自己尝试过但写得磕磕巴巴的时候，再去看经典代码实现。以前新人的做法是翻各种博客对比不同写法，但博客的问题是:大部分博客不会解释“为什么不用另一种写法”，他们只展示“一种能用的写法”。

Codex 在这个环节表现出不错的辅助能力，前提是你问对问题。不是问“给我单例模式的代码”，而是问：“这段代码里的 volatile 关键字去掉会有什么后果？”或者问：“为什么这里用枚举实现单例而不是双重检查锁？”

这种“追问为什么”的方式让 Codex 从一个答案生成器变成了一个解释引擎。 我见过的最有效用法是:让学员把一份自己读不太懂的代码粘进去，然后逐个追问：“第三个方法为什么要接收一个接口类型而不是具体类？”“如果我把这个抽象类改成接口，对扩展有什么影响？”

这种对话的模式很像有一个随时可问的助教。它的局限是你必须已经知道自己不知道什么，而这本身就需要一点基础，新手最怕的状态就是“整段都看不懂，不知道从哪问起”。对于这种状态，我建议先手抄一遍代码，在每条语句旁边写一句话注释，写到哪条卡住了，就拿那条去问 Codex。把自己脑中那些模糊的句子变成精确的问题，然后让 Codex 回答，这个转变本身就是学习过程中的关键进展，Codex 只是放大器，你需要用自己的表述激活它。

四.3 环节三：动手实现，这里划一条分界线，Codex 的定位完全不同了

从这节开始我把 Codex 好的一面也摊开了说，因为实现环节确实是它能发挥价值的地方，但这个价值和大多数新手以为的那个价值不一样。

新手用 Codex 助实现时最常见的心理预期是这样的：“我描述需求，它给我可运行代码，我改改就行。”这个预期在第一、第二个模式时几乎必然落空，因为你的需求描述精准度不够。你说“写一个工厂模式”，它给你一个干净但过简的工厂，没有异常处理、没有配置化、没有任何与你真实业务场景对应的细节。你说“再加点什么”，它加。然后你加来加去，代码越来越像一个你不认识的陌生人写的项目。

Codex 在这个环节的真正擅长点不是“从零生成正确实现”，而是“在你自己搭出框架后，帮你快速填充你已经能判断的细节”。

我来举一个实际教学中的例子。一个学员在练习建造者模式，他想给一个查询构建器写建造者。他先手写了四个方法，设置过滤条件、设置排序字段、设置分页参数，然后在执行方法那里卡住了，他想让不同建造方向产生不同类型的查询对象。

这时候他打开 Codex，他做了一件很对的事：他没有说“帮我写建造者模式”，而是从自己已经写好的部分里拿了三个方法签名粘进去，然后问：“基于这些方法，怎么实现一个 Director 来生成针对 MySQL 和 Elasticsearch 的不同查询？”

Codex 给出的代码他一看就懂了，因为主要的结构是他自己搭的，Codex 只是在关键转换处给了提示。两周后他能闭卷写出那部分，因为他没有把自己的那一半外包出去。

四.4 环节四：调试与排错，Codex 做错了就能教会你东西，但它常做错吗？

这是我观察到的一个很有意思的反直觉现象。按理说，新手写的设计模式实现往往有 bug，而 Codex 写的代码“看起来”不容易有显眼的 bug，至少编译不报错，跑起来也基本流畅。

但正因为 Codex 生成的代码表面太平滑了，新手失去了一个极其宝贵的“从错误中学习”的机会。 传统学法的学员在排错阶段花了大量时间，某个工厂返回了错误类型的对象，某个观察者没有被正确注销导致内存泄露，某个单例在多线程测试时跑出来两个实例 ID。排这些错是痛苦的，但每一个错误都在逼他们理解模式的边界条件和隐含约束。

Codex 生成的代码避免了大多数这类低级错误，但也把那些“本该被碰到的边界”给平滑掉了。我后面设计了一个练习：故意给 Codex 塞一个有问题的提示词，让它生成一个线程不安全但新手看不出来的单例实现，然后让学员去写并发测试跑出问题。这个练习的效果比直接讲十遍“单例要考虑线程安全”要好，因为它利用了 Codex 的一个特性，Codex 会忠实地反映你提示词的质量，糟糕的提示词对应糟糕的代码，而糟糕的代码里恰恰埋藏着最好的学习点。

所以如果从这个角度看，Codex 在排错环节的价值不在于“帮你修 bug”，而在于你能刻意构造不完美的提示词，让它的不完美暴露出来，然后自己去发现那为什么不完美。

四.5 环节五：回顾和记忆巩固，这里是真正的分水岭

前面提到过一周后闭卷提取的数据，这里把背后的原理说清楚。

认知科学里有一个相当稳固的发现：学习效果和“提取难度”正相关。 你越是费劲才能从脑子里把一段知识调出来，这段知识在你脑子里的痕迹就越深。传统学习路径天然地在这个环节提供了高提取难度，一周后闭卷写代码，大脑需要自己重建那些已经模糊的连接。

而 Codex 辅助学习的新手，一周后面对空白的编辑器，下意识做的第一件事是开始回忆“Codex 当时是怎么写的”。换句话说，他们的大脑没有练习“提取模式结构”，而是练习了“提取看 Codex 输出时的记忆画面”。 这两种提取对应的是完全不同的神经通路。

我做过一个测试，让四个学员在学完适配器模式的三天后，分别接受两种不同的提取刺激。一种是在空白编辑器里坐下闭卷写，一种是对着一张适配器模式的核心接口图问“这四条连线分别对应什么具体的代码”。前一组两个人全部卡在类名和泛型上，后一组两个人能准确说出每条线的意义和关联代码。

这个测试的启示是：Codex 用户需要补一个主动回忆的环节。 我给的建议很简单：每天结束学习前，关掉所有窗口，在纸上画出今天学的这个模式的类图和关键交互序列。不用画得漂亮，但要能画出哪两个对象之间发生了什么关系。画到哪画不下去了，那个地方就是明天要回头补的。这个过程 Codex 帮不了你，你也不需要它帮。

四.6 环节六：跨场景迁移，Codex 能给你场景，但需要你先描述

最后一个环节是一个程序员之所以成为程序员的标志，你能不能在一个全新的、没有遇到过的问题面前，自发地从工具箱里抽出合适的模式。

新手在这个环节的常见表现是：问他十个问题，他能用 if-else 解决掉九个，完全不觉得哪里有必要上模式。这不是他懒，是模式在他脑中的触发条件太苛刻了，他对于“这里应该用策略模式”这个判断的触发集，只包含那些和教程中鸭子例子高度相似的结构。

Codex 在这个环节可以当一个“场景生成器”。 比如你学完观察者模式，不是让 Codex 再给你写一遍“天气数据通知多个显示面板”的实现，而是让它列出十个不同的业务场景，每个场景里都可能用到一对多通知机制，从股票推送、到物流状态变更、到 UI 组件之间的解耦。然后你逐一判断，这些场景中哪些真正需要观察者模式，哪些可能用别的模式更合适。

这个用法把 Codex 从“给答案的人”变成了“出题的人”，而判断权留给了你。我见过一个转变非常明显的例子：我让一个学员每天用 Codex 生成五个场景，他来判断是否适用某一模式，并写出理由。第一周他十个场景错六个；到第三周错两个，而且错的那两个的思考过程写在旁边，比对的四个还有信息量。

这也是 Codex 在一个我认为几乎没有替代方案的学习环节上的最大价值：它可以压低“获取多样场景”的成本。 传统上老师要给学员构造场景是很费力的，要自己编，还不能太脱离实际。Codex 可以低成本地批量生成不同复杂度的场景描述，而且你可以不断提新约束，让场景越来越接近真实的业务复杂度。

五、五个在新手身上反复出现的典型误区，每一个我都亲眼见过

这部分把我在观察中发现的最高频错误使用方式拎出来讲，因为它们太容易被当成“高效学习”了。

误区一：把 Codex 生成的设计模式代码当作“标准答案”来背诵。 设计模式从来就没有唯一的标准答案。单例就有饿汉、懒汉、双重检查锁、静态内部类、枚举五种主流实现，选择哪一个要看你对延迟加载、线程安全、序列化兼容性的具体需求。Codex 大概率给你一个线程安全但不考虑序列化的懒汉式，因为它见过最多的训练样本就是这种。你把这段背下来，面试换一个约束条件，你连代码要改哪里都不知道。没有约束条件的标准答案，就是被掩饰的无知。

误区二：跳过手写实现，直接进入“对比不同变体”的学习方式。 这个误区和现在流行的“对比学习法”被教条化有关。对比学习的前提是你对每一方都有独立的操作经验，你亲手实现过饿汉式和懒汉式之后，对比它们的加载时机才有意义。如果你两个都是 Codex 生成的，你的对比只能停留在文本层面，你感受不到在真实项目中初始化顺序对启动时间的影响，你也感受不到类加载机制的延迟特性带来的微妙差异。缺乏操作经验的对比，不是学习，是文本鉴赏。

误区三：为了让 Codex 更容易生成准确代码，把业务场景过度简化。 我很理解这种心理，描述越简单，Codex 生成的代码越干净越不会出错。但模式之所以难，恰恰是因为真实业务里充满了“不干净”的约束：已有的代码结构不能大改，依赖的第三方库有自己的约定，性能需求让某些优雅设计变得不实际。你用简化场景学到的模式，放进真实项目就是一记重拳打在棉花上。宁可描述一个复杂到连 Codex 都要犹豫半秒的场景，然后去和它一起分析权衡，也不要沉溺于它会给你完美答案的假象。

误区四：把“我看得懂了”当作“我能写出来了”的信号。 这个混淆是 Codex 时代最普遍的认知错觉。Codex 生成的代码极干净，命名规范，缩进统一，读起来的体验和读一本写得不错的教材差不多。这种阅读的流畅性会产生一种虚假的“这很容易”的感觉。但阅读和提取在脑区上是两码事。你读得越顺，越不代表你能自己写出来。任何时候，让你自己去写才能知道真章。记住一条经验规则：默写是检验真懂的唯一标准。

误区五：在学习阶段引入过多的模式变体，导致概念交叉干扰。 Codex 有一个特性被很多人当成优点，它能基于一个模式衍生出各种语法糖变体、函数式写法、依赖注入框架下的简化版本。但对新手来说，在核心骨架都还不稳的情况下，同一模式的多个变体不是扩展视野，而是制造概念污染。你刚记住观察者模式是“Subject 维护 Observer 列表，状态变化时遍历调用 update”，还没消化完，Codex 又给你一个用 Reactive Streams 实现的版本，你连 Subject 这个角色长什么样都认不出来了。在掌握主干之前，克制比多样性更有价值。

六、不同阶段新手的差异化使用策略

说了这么多问题和误区，不等于 Codex 不能用。这部分我把新手按接触编程的时间分成三个阶段，给每个阶段一个具体的使用策略。这些策略经过实际教学验证过可行性，不是你从别处能看到的泛泛分类。

六.1 零基础到三个月：Codex 只做解释器，不做编码器

这个阶段你连语言特性都还不太熟，类、接口、抽象、多态这些概念才刚建立起来。这个阶段不应该用 Codex 帮你写任何设计模式代码，因为你的判断力还太弱，识别不出哪些是模式核心、哪些是语言特性细节、哪些是 Codex 自由发挥的填充代码。

但你可以用 Codex 做一个事情：在你看着书上的模式示例代码读不懂的时候，圈出具体哪一行不懂，拿去问它。 只能问“为什么”类型的问题，不能问“给我也写一个”类型的问题。为什么这里用抽象类？为什么这个方法要声明为 protected？为什么构造函数的参数是一个工厂对象而不是一个具体类？这些“为什么”会在你语言基础还不牢的时候帮你建立第一批关于“设计意图”的神经元连接，比任何基础语法教程都有用。

这个阶段用 Codex 写模式代码的代价，是把你本该花在理解语言机制上的注意力转移到了“操纵一个黑盒让它吐东西”上。三个月后再回头看，你会发现此时省下的时间需要十倍偿还。

六.2 三个月到一年：可以进入“补全式协作”，但必须守住两个规则

这是学习设计模式的黄金窗口期，也是我观察的那 19 个人里大部分人所处的阶段。我的建议是可以用 Codex 了，但要遵守两条铁规：

铁规一：自己先写出接口骨架。 不管用什么语言，在让 Codex 参与之前，必须先在编辑器里打好核心接口和关键类的关系声明。工厂模式的工厂接口和方法签名、策略模式的策略接口和具体策略类名、观察者模式的 Subject 接口和 Observer 接口。这些定义是你对一个模式理解的“骨架”，Codex 不能在骨架环节代劳。如果连骨架都写不出来，说明你还不应该进入实现环节，退回去重新理解意图。

铁规二：每次 Codex 补全后，立即用注释写出“它补的这一段解决的核心问题是什么”。 这是一个强制大脑参与的行为仪式。如果补了六行代码，你只能用“这是 switch 判断不同类型的代码”来描述，而不是“这是工厂根据传入类型动态决定实例化哪个具体产品类”，说明你没有理解它在这里的角色。这个规则看似繁琐，但它改变了你对 Codex 输出的处理方式，从“接受代码”变成“审视代码”。

我在带学员的时候，这两条铁规加上去以后，学习质量在两周内就拉回到和传统学习路径差不多的水平。而且这个阶段的学员普遍反映，自己越来越能察觉出 Codex 的代码什么时候“写得不对劲”，这种感知能力是纯传统路径需要更长时间才能培养的。

六.3 一年以上但设计模式还没形成体系：Codex 从助手升级为审查员

到了一年经验但设计模式还比较零散的程序员，Codex 可以承担一个我之前没想到的角色，它可以在你写完一个实现后充当审查员。把你的完整代码和一句背景描述交给它，问它“这段代码用策略模式来处理支付方式选择，有没有更好的写法？”，或者“这个观察者实现有没有内存泄露的风险？”

这个阶段的关键是你已经有独立的实现能力和设计判断力，Codex 提供的不同方案对你来说不再是需要背诵的答案，而是需要评价的观点。你会开始琢磨它给的这个方案好在哪里、不好在哪里，这个过程其实就是你自己设计感的精炼过程。

我去年年底就用这种方式和 Codex 对了六七次，最后确实在它给出的一版代码里发现了一个我自己没意识到的对中介者模式的理解偏差，我原来一直把同事类之间的通信过度集中在 Mediator 身上，导致它出现了上帝类倾向。这个发现如果能早两年发生，我能少写不少后来需要重构的代码。

七、如果你正在用 Codex 学设计模式，我想直接给你一套可检查的行动框架

这一节不谈原理，只给步骤。基于前面所有的观察和验证，我整理了一套新手可以对照执行的 Codex 辅助学习框架。一共六个步骤，每一步都设了可验证的完成标准。

步骤 1：禁止 AI 阅读阶段（耗时约 40-60 分钟）

• 阅读模式的文字描述，圈出三个你不确定具体含义的词或表述
• 用自己的话在纸上写出一句话，描述这个模式解决什么“变与不变”的问题
• 完成标准：你写的那句话不能再包含“封装了变化”这种教材原话，必须是你自己组织的、能讲给你妈听也大概能懂的句子

步骤 2：最低限度手写阶段（耗时约 60-90 分钟）

• 打开编辑器，不参考任何外部资料，写一个极简的实现
• 只保留该模式最核心的 2-3 个接口或类，去掉所有无关的业务逻辑
• 运行它，如果跑不通，自己调试。这一步禁止使用 Codex
• 完成标准：你手写的代码能编译通过并跑出预期结果，哪怕它只有三十行

步骤 3：对照与追问阶段（耗时约 30-45 分钟，此时首次引入 Codex）

• 把你自己写的代码和 Codex 生成的该模式典型实现做对比
• 找出三处不同，然后向 Codex 提问，形式必须是以“为什么”开头
• 完成标准：三处不同你都能说出“什么场景下我的写法更合适，什么场景下它的写法更合适”

步骤 4：变体探索阶段（耗时约 30 分钟）

• 修改一个约束条件，比如从单线程改成多线程、从严格继承改成组合、从一个具体产品改成可插拔产品族
• 自己先预测修改后需要改哪些代码，再让 Codex 生成修改后的版本
• 比较你的预测和 Codex 的实际输出
• 完成标准：预测和实际至少有两处匹配，不匹配的地方你能解释为什么你的预测偏了

步骤 5：跨场景识别练习（耗时约 20 分钟，适合每天做）

• 让 Codex 生成 5 个该模式可能适用的简短业务场景描述，不要代码
• 你逐一判断这 5 个场景是否真的适合用这个模式，并写下判断理由
• 再让 Codex 给出它自己的判断，和你自己的做对比
• 完成标准：5 个判断中至少有 4 个和 Codex 一致，不一致的那个你能论证你的判断为什么不输

步骤 6：延迟提取练习（耗时约 15 分钟，隔天或隔两天做）

• 关闭所有参考资料和 Codex 窗口
• 在空白编辑器或纸上画出该模式的类图，写出核心接口和关键交互
• 标出自己画不出来或写不出来的部分
• 完成标准：核心骨架正确率不低于 70%，缺失的部分作为第二天优先复习的点

这六步一套走下来，一个模式大概需要 3-4 小时的投入，不含最后的延迟提取。跟纯传统学习比起来，总时长其实差不多或者略短，但理解深度和记忆保持率明显更高。关键是 Codex 被放在了第 3 步才进来，而不是第 1 步，这个顺序差异决定了你是在用它理解，还是用它替换自己的理解。

八、Codex 在不同类型设计模式上的辅助效果差异巨大

我前面没有按模式类型细分讨论，但这一点太重要了。Codex 对创建型、结构型、行为型三类模式的辅助效果是不一样的，如果一概而论会误导人。

创建型模式（单例、工厂方法、抽象工厂、建造者、原型）：这是 Codex 最擅长的一类。因为创建型模式的实现变化相对有限，大多数实现可以独立于具体业务逻辑，Codex 的训练语料里这类代码质量高且数量大。新手在这类模式上最容易出现“Codex 给一个看起来挺像样的代码，然后过度自信”的情况。 但它实际上是实验难度最低的一类，如果要给 Codex 学习定一个顺序，从创建型开始不是最合适的，你会先建立一种“AI 真靠谱”的舒适感，然后到结构型直接摔跤。

结构型模式（适配器、桥接、组合、装饰、外观、享元、代理）：这类模式 Codex 的表现开始分化。适配器、装饰、代理这三个它能给相对准确的实现；组合模式在简单的树形结构上也能做，但一旦涉及复杂的遍历和操作，它容易生成一个“看着像组合模式但缺少关键操作转发”的版本。桥接模式是我发现 Codex 最容易给出似是而非代码的一个模式，它经常把桥梁的两端维度搞混，或者把桥接和策略的区别模糊掉。如果你的目标是搞懂桥接模式，依赖 Codex 学习可能会花比想象中更长的时间。

行为型模式（观察者、策略、模板方法、命令、状态、职责链、迭代器、访问者、中介者、备忘录、解释器）：这是 Codex 的生成质量方差最大的一类。策略模式、观察者模式、模板方法，它给的代码通常不错。但状态模式、访问者模式、中介者模式，这三种我反复测过多次，Codex 在复杂的多状态转换、双向访问者、多同事类中介场景下经常出现关键职责错位。尤其是访问者模式，Codex 生成的双分派实现不对的概率不低。 如果你的学习路径是把 Codex 作为主要实现参照，行为型模式里的这几种不适合用它当第一道参考。

知道这个差异不是为了让大家避开某些模式，而是为了让大家在学不同模式时调整 Codex 使用的“信任度”和“介入时机”。对创建型模式，你的审慎程度应该提得更高，因为它的代码看起来越对，你越容易跳过思考。对行为型模式中的复杂类型，你应该更多依赖经典教材和自己动手，用 Codex 来对比验证，而不是来生成初版。

九、这件事放到更大的背景里看，其实指向一个更根本的问题

到这里已经写了很久了，我想把视角拉高一点，聊一个比“Codex 怎么用”更大的问题。

我在带那 19 个新手的过程中不断被拉回到同一个矛盾上：Codex 这类工具的商业价值度量标准和学习价值度量标准，在基本层面上是冲突的。 商业产品衡量自己好不好用的 KPI 是“生成速度、采纳率、用户完成任务的时间”，翻译过来就是它要让你越快拿到结果越好，越少阻碍越好。但学习这件事的本质就是创造“有益的阻碍”。有意义的学习摩擦不是 bug，是 feature。最有效的学习路径往往体验并不流畅，它让你停顿、让你困惑、让你犯错再修正。

这意味着，如果你用“好不好用”作为选择学习方式的依据，你会天然被推向那些让你感觉流畅但学不到东西的路径上。Codex 之所以对新手有“诱惑力”，不是因为它坏，恰恰是因为它好，好用，快，体验极佳。但学习这件事，好用的工具经常会削掉那些最有价值的摩擦层。

我对此的建议只有一个：把“我今天有没有感到适度的困惑”当作检验学习质量的核心指标。 如果你一整个下午用 Codex 学设计模式都顺风顺水、一点阻塞感都没有，那这一下午大概率什么都没真正学到。好的学习应该让你时不时想停下来琢磨一下，甚至需要站起来走一圈想一个概念，那才是大脑在建立新连接的外部信号。

十、结尾：把 Codex 当作你工具箱里的一面镜子，而不是一只手

回到标题那个问题：Codex 编程对新手程序员学习设计模式的辅助效果到底怎么样？

我的回答是，这取决于你把它放在学习流程的哪个位置，以及你是否愿意接受因为它的介入而损失掉的“摩擦红利”。

如果你把它放在思考之前，它会让你在极短时间内觉得自己学了很多东西，这种感觉真实而强烈，但只是一层薄壳。如果你把它放在探索之后，用它来验证、追问、扩展场景，它可以把很多传统学习路径中靠运气才能获得的东西，比如多样化的应用场景、不同实现风格的对比、设计决策的快速验证，打包成日常可及的学习资源。

Codex 对设计模式学习最大的威胁不是它会教你错误的东西，而是它太擅长给你一个看起来完全正确的答案，以至于你会跳过那个本该自己走的关键几步。而这跳过的几步，恰恰是对你最终能不能独立写出好代码影响最大的几步。

所以我的建议很直接：如果你现在正在用 Codex 学设计模式，从下一个模式开始，照着第六节的六步框架走一遍。就一遍。不需要永久放弃 Codex，只需要把它的出场顺序往后挪两个环节。走完之后你再判断，是以前那种“先问 AI 再看书”的方式让你更懂，还是“先写到卡壳再问 AI”让你更懂。

如果你试了，我大概知道你会在第几步的时候产生那个“原来我之前一直没真懂”的感觉。那个感觉不舒服，但它值一次学习方法的彻底重置。