在 AI 能帮你写代码的 2026 年，为什么还要读这本 1994 年的经典？
技术背景：AI 编程时代的"模式觉醒"
2026 年，Claude Code、Cursor 这些 AI 编程助手已经能生成相当完整的代码。但一个有趣的现象正在发生：越是依赖 AI 生成代码的团队，越开始重视设计模式。
为什么？
因为 AI 生成的代码往往是"功能导向"的——能跑就行，但缺乏系统性思考。当你让 AI "帮我写一个用户管理系统"，它给你的是一堆散乱的函数，而不是一个清晰的架构。
这时候，《设计模式：可复用面向对象软件的基础》（GoF 设计模式）的价值被重新激活了——它不是教你写代码，而是教你造系统。
书籍核心内容：23 种模式的底层逻辑
这本书由四位作者（被称为 GoF——Gang of Four）于 1994 年出版，定义了 23 种经典设计模式，分为三大类：
创建型模式（5 种）
处理对象创建的问题，让系统更灵活地决定"何时创建什么"：
- 单例模式（Singleton）：确保一个类只有一个实例
- 工厂方法模式（Factory Method）：让子类决定创建什么对象
- 抽象工厂模式（Abstract Factory）：创建相关对象家族
- 建造者模式（Builder）：分步构建复杂对象
- 原型模式（Prototype）：通过复制创建新对象
结构型模式（7 种）
处理类和对象的组合问题：
- 适配器模式（Adapter）：让不兼容的接口能协同工作
- 装饰器模式（Decorator）：动态添加功能
- 代理模式（Proxy）：控制对象的访问
- 外观模式（Facade）：简化复杂系统的接口
- 组合模式（Composite）：树形结构的统一处理
- 桥接模式（Bridge）：分离抽象与实现
- 享元模式（Flyweight）：共享细粒度对象
行为型模式（11 种）
处理对象间的通信和职责分配：
- 策略模式（Strategy）：定义算法族，可相互替换
- 观察者模式（Observer）：对象间的依赖通知
- 命令模式（Command）：将请求封装为对象
- 模板方法模式（Template Method）：定义算法骨架
- 迭代器模式（Iterator）：遍历聚合对象
- 责任链模式（Chain of Responsibility）：请求沿链传递
- 状态模式（State）：状态驱动的行为变化
- 中介者模式（Mediator）：集中管理对象交互
- 备忘录模式（Memento）：保存和恢复对象状态
- 访问者模式（Visitor）：分离数据结构与操作
代码示例：策略模式在 AI Agent 工具编排中的应用
下面我用策略模式设计一个 AI Agent 的工具选择器——这正是当下热门的 Agent 架构场景：
from abc import ABC, abstractmethod
from typing import Dict, Any
import json
# 策略接口：定义工具执行的统一契约
class ToolStrategy(ABC):
"""工具策略的抽象基类"""
@abstractmethod
def execute(self, params: Dict[str, Any]) -> Dict[str, Any]:
"""执行工具并返回结果"""
pass
@abstractmethod
def get_tool_name(self) -> str:
"""返回工具名称"""
pass
# 具体策略：搜索引擎工具
class SearchTool(ToolStrategy):
def get_tool_name(self) -> str:
return "web_search"
def execute(self, params: Dict[str, Any]) -> Dict[str, Any]:
query = params.get("query", "")
# 模拟搜索逻辑
return {
"success": True,
"results": [
{"title": f"搜索结果: {query}", "url": "https://example.com"}
],
"tool_used": self.get_tool_name()
}
# 具体策略：代码生成工具
class CodeGenTool(ToolStrategy):
def get_tool_name(self) -> str:
return "code_generator"
def execute(self, params: Dict[str, Any]) -> Dict[str, Any]:
prompt = params.get("prompt", "")
language = params.get("language", "python")
# 模拟代码生成
generated_code = f"# Generated {language} code\n# Prompt: {prompt}\npass"
return {
"success": True,
"code": generated_code,
"language": language,
"tool_used": self.get_tool_name()
}
# 具体策略：数据库查询工具
class DatabaseTool(ToolStrategy):
def get_tool_name(self) -> str:
return "db_query"
def execute(self, params: Dict[str, Any]) -> Dict[str, Any]:
sql = params.get("sql", "")
# 模拟数据库查询
return {
"success": True,
"rows": [{"id": 1, "data": "sample"}],
"sql": sql,
"tool_used": self.get_tool_name()
}
# 策略上下文：Agent 工具编排器
class AgentToolOrchestrator:
"""
AI Agent 的工具编排器
使用策略模式实现工具的灵活切换和扩展
"""
def __init__(self):
# 工具注册表：存储所有可用策略
self._tools: Dict[str, ToolStrategy] = {}
def register_tool(self, tool: ToolStrategy) -> None:
"""注册新工具策略"""
self._tools[tool.get_tool_name()] = tool
print(f"✅ 已注册工具: {tool.get_tool_name()}")
def execute_tool(self, tool_name: str, params: Dict[str, Any]) -> Dict[str, Any]:
"""
根据策略名称执行对应工具
这是策略模式的核心：调用方不需要知道具体实现
"""
if tool_name not in self._tools:
return {"success": False, "error": f"工具 {tool_name} 未注册"}
tool = self._tools[tool_name]
print(f"🔧 执行工具: {tool_name}")
return tool.execute(params)
def list_available_tools(self) -> list:
"""列出所有可用工具"""
return list(self._tools.keys())
# AI Agent 主控逻辑
class AIAgent:
"""使用策略模式的 AI Agent"""
def __init__(self):
self.orchestrator = AgentToolOrchestrator()
self._setup_default_tools()
def _setup_default_tools(self) -> None:
"""初始化默认工具集"""
self.orchestrator.register_tool(SearchTool())
self.orchestrator.register_tool(CodeGenTool())
self.orchestrator.register_tool(DatabaseTool())
def process_request(self, user_input: str) -> str:
"""
处理用户请求，自动选择合适的工具
模拟 Agent 的工具选择决策
"""
# 简单的意图识别逻辑
if "搜索" in user_input or "查一下" in user_input:
result = self.orchestrator.execute_tool("web_search", {"query": user_input})
return json.dumps(result, indent=2, ensure_ascii=False)
elif "写代码" in user_input or "生成" in user_input:
result = self.orchestrator.execute_tool("code_generator", {"prompt": user_input})
return json.dumps(result, indent=2, ensure_ascii=False)
elif "数据库" in user_input or "查询数据" in user_input:
result = self.orchestrator.execute_tool("db_query", {"sql": "SELECT * FROM users"})
return json.dumps(result, indent=2, ensure_ascii=False)
else:
return f"可用工具: {self.orchestrator.list_available_tools()}\n请明确你的需求。"
# ============ 使用示例 ============
if __name__ == "__main__":
# 创建 Agent
agent = AIAgent()
# 测试不同场景
print("\n--- 测试 1: 搜索请求 ---")
response1 = agent.process_request("帮我搜索最新的 AI 编程工具")
print(response1)
print("\n--- 测试 2: 代码生成请求 ---")
response2 = agent.process_request("帮我写代码实现一个简单的 HTTP 服务器")
print(response2)
print("\n--- 测试 3: 数据库请求 ---")
response3 = agent.process_request("从数据库查询用户数据")
print(response3)
print("\n--- 测试 4: 动态注册新工具 ---")
# 新增工具：不修改现有代码，只需注册新策略
class WeatherTool(ToolStrategy):
def get_tool_name(self) -> str:
return "weather_query"
def execute(self, params: Dict[str, Any]) -> Dict[str, Any]:
city = params.get("city", "北京")
return {
"success": True,
"city": city,
"weather": "晴朗，25°C",
"tool_used": self.get_tool_name()
}
agent.orchestrator.register_tool(WeatherTool())
print(f"现在可用工具: {agent.orchestrator.list_available_tools()}")
这个代码展示了策略模式的三个核心价值：
- 开闭原则：新增
WeatherTool时，无需修改AgentToolOrchestrator或AIAgent的代码——只需注册新策略 - 单一职责：每个工具类只负责自己的执行逻辑，
Orchestrator只负责调度 - 依赖倒置：
AIAgent依赖的是抽象接口ToolStrategy，而不是具体实现
个人实践心得：三遍阅读的认知跃迁
第一遍：2020 年——"这是什么黑魔法？"
第一次读这本书时，我正处于"能写代码但不懂设计"的阶段。书中那些 UML 图、类名之间的箭头关系让我头昏脑涨。我把每一章都当作"必学知识"硬啃，结果读完就忘。
那时候的误区：把设计模式当作"标准答案"，以为学会就能写出好代码。
第二遍：2023 年——"原来是在解决特定问题"
第二次阅读时，我已经踩过足够多的坑。读到"装饰器模式"时，我突然理解了——这不就是我之前写日志框架时，用层层嵌套实现功能叠加的方式吗？
关键转变：不再问"这是什么模式"，而是问"这个模式解决了什么痛点"。
| 模式 | 解决的痛点 | 我的实际场景 |
|---|---|---|
| 单例 | 全局唯一实例管理 | 配置管理器、日志器 |
| 工厂方法 | 创建逻辑解耦 | 多数据库适配器切换 |
| 观察者 | 事件通知解耦 | 消息推送系统 |
| 策略 | 算法灵活切换 | 支付方式选择、工具编排 |
| 适配器 | 接口兼容 | 第三方 API 接入 |
第三遍：2026 年——"AI 编程时代的模式觉醒"
今年第三次阅读时，我正在研究 AI Agent 工具编排架构。突然发现：策略模式、责任链模式、命令模式，几乎是 Agent 工具系统的标配。
当 AI 开始帮你写代码时，设计模式的价值反而更高了：
- AI 生成的代码往往是"功能堆砌"，没有架构意识
- 你需要用设计模式告诉 AI："按这个结构来组织代码"
- 设计模式成为你与 AI 协作的"沟通协议"
适合人群与阅读建议
适合人群
| 人群 | 阅读价值 | 建议方式 |
|---|---|---|
| 初学者（< 2 年经验） | 建立设计思维萌芽 | 先读《Head First 设计模式》，更通俗 |
| 中级开发者（2-5 年） | 解决实际架构痛点 | 选择性阅读，带着问题找答案 |
| 高级开发者（> 5 年） | 系统化知识沉淀 | 通读后建立自己的模式库 |
| AI 编程从业者 | 工具编排、Agent架构 | 重点读策略、命令、责任链模式 |
阅读建议
- 不要从头到尾硬啃——这本书不是小说，是工具书
- 带着问题读——先问"我遇到了什么设计难题"，再去书中找答案
- 手写代码验证——光看 UML 图没用，必须写代码才能理解
- 结合实际项目——把书中的模式应用到你正在写的代码中
- 与 AI 协作——让 AI 帮你"用 XX 模式重构这段代码"，然后对比结果
结语：经典书的"时代穿越"能力
在技术领域，很多书籍"出版即过时"。但《设计模式》穿越了 30 年，依然在 AI 编程时代发光。
它的生命力来自一个本质：它不是讲某个语言或框架的技巧，而是讲系统设计的底层法则。语言会变，框架会换代，但"如何让代码组合得更灵活、更可扩展"这个问题，永远不会消失。
所以，当 AI 能帮你写代码时，你更需要这本书——因为 AI 写的是代码，而你造的是系统。
讨论：你在实际项目中用过哪些设计模式？有没有"踩坑后才理解模式价值"的经历？欢迎留言分享。
声明：本文为技术书评，无联盟推广链接。
