Python设计模式Skill 用法详解

Python设计模式Skill：用 KISS、单一职责和组合优于继承，写出可维护的 Python 代码

• 不是教你背 23 种 GoF 模式，而是教你判断「什么时候不该用模式」：这个技能围绕 KISS、单一职责、关注点分离、组合优于继承、三的规则等基本设计原则，帮你在架构决策和重构时做出更克制的选择。
• 覆盖从「要不要抽象」到「怎么拆层」的全流程判断：设计新组件、重构纠缠代码、在继承与组合之间取舍、评估耦合与复杂度，都能拿到具体的判断依据和代码示例。
• 输出的是可落地的 Python 代码对比：每个原则都配有「过度设计 vs 简单实现」「坏味道 vs 好结构」的正反例，可直接对照改造自己的项目。
• 技能 ID 为 13201，英文名 python-design-patterns，通过支持 AI 技能机制的客户端一键安装即可调用，无需额外部署服务。
• 适合后端工程师、架构评审者、代码 Review 负责人，以及正在被「工厂 + 注册器 + 三层抽象」折磨的维护者。

该技能叫什么？如何一键安装 AI 技能提升开发效率？

技能基本信息

项目	内容
技能中文名	Python设计模式Skill
技能英文名	python-design-patterns
技能 ID	13201
定位	基于基本设计原则的 Python 代码可维护性顾问
触发时机	做出架构决策、重构代码结构、评估抽象是否适当时

它到底解决什么问题

很多 Python 项目的复杂度并不是「需求太复杂」，而是「抽象太早、分层太乱、继承太深」。常见的三类痛点：

1. 过度设计：为了「以后可能扩展」，给一个只有两种格式的格式化逻辑套上工厂类 + 注册装饰器 + 元类，最终代码量翻三倍，但没带来任何实际收益。
2. 职责混乱：一个 UserHandler 同时做 HTTP 解析、参数校验、SQL 拼接、响应格式化，改一处 HTTP 逻辑就把业务规则一起改坏。
3. 继承失控：EmailNotificationService 直接继承基类并内部 new 出 SMTP 客户端，导致无法用假对象测试，一写单测就要连真实邮件服务器。

这个技能做的事，就是在你准备「上模式」之前，先用水位线把你按回岸边：先问最简单的方案行不行，再看是否真的到了该抽象的时候。

一键安装的思路与步骤

AI 技能（Skill）的安装方式取决于你使用的客户端是否支持技能机制，通用流程如下（具体命令、入口与配额以官方说明为准）：

1. 确认前提：你的 AI 客户端 / 助手支持第三方技能（Skill）加载，并且已经完成账号登录与工作区（Workspace）初始化。

2. 找到技能入口：在客户端的「技能市场 / Skill 列表 / 扩展管理」中搜索技能 ID 13201，或直接搜索英文名 python-design-patterns。

3. 一键安装：点击安装 / 启用按钮，按提示确认权限（通常只需要读取当前对话内容的权限，不需要访问你的代码仓库）。

4. 绑定到会话：新建对话时在技能选择器中勾选「Python设计模式Skill」，或在项目设置中把它设为默认启用的技能。

5. 验证是否生效：发送一句测试指令，例如：

   我有一个只有两种输出格式的需求，原本想写工厂 + 注册器，帮我判断一下值不值得。

   若回复中能围绕「KISS / 保持简单」「三的规则」等原则给出「先用字典映射即可」类的判断，并附上正反代码对比，说明技能已正常工作。

提示：技能本身是「提示词 + 方法论」的封装，安装后不需要你额外安装 Python 依赖或运行命令行程序，零环境成本。

该技能的主要功能和特点

• 架构决策辅助：在设计新组件或服务时，先给出「最简可行方案」的评估路径，明确复杂度必须由具体需求证明，而不是由想象力证明。
• 反过度设计的判断标准：内置「三的规则」——在出现第三个实例之前不要抽象。技能会明确指出：重复通常比错误的抽象更好。
• 单一职责（SRP）拆解能力：把「一个类做所有事」的处理程序，拆成 Handler（HTTP 关注点）、Service（业务逻辑）、Repository（数据访问）三层，并解释拆完后各自的变更理由。
• 关注点分离的分层图景：提供 API 层 → 服务层 → 仓库层 的清晰依赖方向（每层只依赖其下一层），避免业务逻辑被 SQL 和 HTTP 反向污染。
• 组合优于继承的实操改造：把「继承基类 + 内部 new 依赖」改造成「构造函数注入多个 Sender」，让单元测试可以用 FakeEmailSender 直接替换。
• 依赖注入与可测试性设计：通过 Protocol 定义 Logger、Cache 等接口，生产环境注入 RedisCache、测试环境注入 FakeCache，同一份业务代码两套装配。
• 函数粒度的量化建议：函数超过 20–50 行（视复杂度浮动）、承担多个不同目的、或存在 3 层以上嵌套逻辑时，建议拆分。
• 反模式识别清单：例如不要把 ORM 模型直接当 API 返回值暴露、不要在业务函数里混写 SQL 查询，技能会给出「坏味道代码 → 改进代码」的对照。
• 和普通工具的本质差异：Linter 和格式化工具只能告诉你「代码不符合规则」，而这个技能能告诉你「这个抽象该不该存在」，属于设计层的判断而非语法层的检查。

如何使用该技能？

步骤一：明确你要决策的问题类型

在提问前，先把问题归类到技能支持的场景中，效果会明显更好：

• 要不要创建抽象（工厂、基类、装饰器）
• 要不要拆分层级（Handler / Service / Repository）
• 继承还是组合
• 函数是否太长、是否该拆
• 现有代码耦合太重，从哪儿开始重构

步骤二：贴入真实代码片段（上下文越具体越好）

技能的价值高度依赖上下文。建议按「现状 + 意图 + 顾虑」三件套提供信息：

# 现状：只有一个格式化入口，但我担心以后要加新格式
class Formatter:
    def format(self, data: dict) -> str:
        ...

意图：我想加 json / csv / xml 三种输出。 顾虑：同事说应该用工厂模式 + 注册器，是不是过度设计？

步骤三：阅读技能给出的「判断 + 正反对照 + 落地代码」

以格式化器为例，技能会明确指出工厂模式在这里「添加了代码而没有添加价值」，并给出更简单的写法：

# 简单：只使用字典映射
FORMATTERS = {
    "json": JsonFormatter,
    "csv": CsvFormatter,
    "xml": XmlFormatter,
}

def get_formatter(name: str) -> Formatter:
    """通过名称获取格式化器。"""
    if name not in FORMATTERS:
        raise ValueError(f"未知格式: {name}")
    return FORMATTERS[name]()

步骤四：按「分层改造」清单执行重构

如果需要拆分纠缠的处理器，可要求技能输出改造方案。典型输出形态：

class UserService:
    """仅业务逻辑。"""
    def __init__(self, repo: UserRepository) -> None:
        self._repo = repo

    async def create_user(self, data: CreateUserInput) -> User:
        user = User(email=data.email, name=data.name)
        return await self._repo.save(user)


class UserHandler:
    """仅 HTTP 关注点。"""
    def __init__(self, service: UserService) -> None:
        self._service = service

    async def create_user(self, request: Request) -> Response:
        data = CreateUserInput(**(await request.json()))
        user = await self._service.create_user(data)
        return Response(user.to_dict(), status=201)

输入示例：一段把 SQL 查询、折扣计算、日志打印混在一起的 calculate_discount 函数。 输出说明：技能会指出「I/O 与业务逻辑混合」，并改写为纯函数形式——calculate_discount(user, order_history) 只保留业务规则，数据访问交由仓库层完成，从而让折扣逻辑可以脱离数据库单独做单元测试。

步骤五：用「最佳实践总结」做 Review 检查表

技能内置了十条实践总结（保持简单、单一职责、分离关注点、组合优于继承、三的规则、保持函数小、注入依赖、抽象前先删除、逐层测试、明确胜于聪明）。你可以直接把这份清单当作 Code Review 的提问模板，逐条对照 PR 中的改动。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势	不足
python-design-patterns（Python设计模式Skill）	设计原则与架构判断顾问	KISS、SRP、关注点分离、组合优于继承、三的规则、依赖注入、反模式识别	低：在支持技能机制的客户端一键安装，具体入口以官方说明为准	架构决策、重构方案、抽象合理性评估	提供「该不该抽象」的判断，而非只查语法；有正反代码对照	不执行静态扫描，需用户主动贴入上下文
GoF 设计模式经典教程 / 技术文档	模式知识库	23 种经典模式的意图、结构与示例	中：需自行检索、筛选、迁移到 Python 语境	学习模式概念、面试准备	体系完整、权威、可离线查阅	容易诱发「为了用模式而用模式」，缺少「何时不用」的约束
静态代码检查工具（Ruff / Pylint / Flake8 一类）	代码规范与缺陷扫描	语法风格、未使用变量、复杂度告警、潜在缺陷	低：命令行或编辑器插件安装，需配置规则集	CI 流水线、提交前检查	自动化、可批量拦截、可量化	只判断规则符合性，无法判断「这个抽象是否有必要存在」
通用 AI 编程助手（无专门设计原则约束）	代码生成与补全	写函数、补测试、解释代码	低：IDE 插件即可	快速实现功能、补样板代码	生成速度快、覆盖面广	倾向于「上模式」给出复杂实现，容易放大过度设计

选型建议：把静态检查工具当作「语法层的守门员」，把本技能当作「设计层的参谋」，两者叠加使用效果最好；而通用 AI 助手在生成代码时，可以先用本技能确认结构方向，再让助手填实现。

该技能的典型应用场景与实际体验情况

场景一：后端工程师设计新服务，纠结要不要上工厂模式

• 角色与痛点：负责订单模块的 Python 后端工程师，面对三种订单类型，想提前设计一套「可扩展」的工厂 + 注册器 + 策略组合，但写完发现光骨架就两百行。
• 使用方式：把三种类型的差异点贴给技能，询问「三的规则在这里成立吗」。
• 实际体验：技能会引导先确认这三个类型的差异是「数据不同」还是「行为不同」。如果只是参数不同，一句字典映射就够了；只有在第三个真正独立的处理分支出现后，才值得考虑策略模式。上手难度低，关键在于提问时要给出足够差异细节，否则容易得到保守但笼统的结论。

场景二：维护者重构「上帝类」处理器

• 角色与痛点：接手一个 UserHandler，同时做 JSON 解析、邮箱校验、裸 SQL 插入、响应组装，改一处就崩一片。
• 使用方式：贴入完整类，要求「按关注点分离拆层，并说明每层只依赖其下一层」。
• 实际体验：技能会给出 Handler / Service / Repository 三层职责划分，并强调「HTTP 改动不影响业务逻辑，反之亦然」。注意点是拆分后需要同步改造依赖注入的装配代码，若项目已有全局单例风格，建议分两步走，避免一次改动过大。

场景三：测试工程师推动可测试性改造

• 角色与痛点：通知服务在 __init__ 里直接 new 了 SMTP 客户端，单测一跑就发真实邮件。
• 使用方式：要求「按组合优于继承与依赖注入原则改造，并给出测试环境装配方式」。
• 实际体验：技能会输出「构造函数注入 EmailSender / SmsSender / PushSender」的组合式实现，并给出生产用 RedisCache + 测试用 FakeCache 的双装配示例。效果直观，改造后即可用假对象完成隔离测试。注意事项：需要团队接受 Protocol 抽象，若代码库完全没有类型标注习惯，可先小范围引入。

场景四：技术负责人做 Code Review 与架构评审

• 角色与痛点：评审时凭直觉说「这里是不是太复杂了」，缺乏可复用的判断话术。
• 使用方式：把 PR 摘要交给技能，要求按「最佳实践总结」十条逐项打分并指出风险点。
• 实际体验：十条清单可直接转成评审提问模板，例如「这个函数是否有 3 层以上嵌套」「这个抽象是否满足三的规则」。效果稳定，但需注意技能输出的是建议而非硬性阻断项，最终取舍仍应结合团队规范与业务节奏。

该技能能为用户带来的价值

• 减少无效抽象带来的维护成本：通过「三的规则」和「KISS」两道闸门，把「为了扩展性而写的骨架代码」挡在合并之前。一个典型的注册器 + 工厂改造，往往能砍掉数十行只为「看起来专业」而存在的样板代码。
• 缩短重构决策时间：过去需要资深工程师凭经验判断「该不该拆」，现在可以在一次对话内拿到分层方案与正反例代码，把设计讨论从「我觉得」推进到「代码对比」。
• 降低可测试性改造的门槛：依赖注入 + 组合优于继承的组合拳，让「怎么让这段代码能被单测」从经验题变成模板题，新人也能照着改造。
• 统一团队的设计语言：KISS、单一职责、关注点分离、组合优于继承、三的规则这五个词，可以作为团队评审时的共同词汇，减少「风格之争」。
• 长期价值：可维护性是一种复利。今天少一层无谓的继承、少一个没人用的工厂，未来每一次需求变更都少一次「牵一发动全身」的排查。

常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？

A：在支持 AI 技能（Skill）机制的客户端中，通过技能市场或扩展入口搜索技能 ID 13201 或英文名 python-design-patterns，点击安装 / 启用即可，无需本地安装 Python 依赖。是否收费、是否有调用配额取决于你使用的客户端与技能商店策略，以官方说明为准。

Q2：它和 Ruff、Pylint 这类静态检查工具有什么区别？

A：静态检查工具判断的是「代码是否符合规则」，属于语法与风格层；本技能判断的是「这个抽象是否应该存在」，属于设计决策层。二者不冲突，推荐搭配使用：Linter 负责 CI 拦截，本技能负责架构评审。

Q3：它会不会直接帮我生成完整的项目代码？

A：不会。根据技能详情，它的定位是设计原则顾问，输出的是判断标准、正反代码对照和改造示例，例如字典映射替代工厂、三层分离替代上帝类。它的价值在于「帮你决定怎么写」，而非「替你写完整个项目」。

Q4：适合谁用？初级开发者用会不会看不懂？

A：主要适合 Python 后端工程师、技术负责人、代码 Review 负责人，以及正在维护遗留代码的重构者。初级开发者同样适用——技能给出的正反例都是可以直接对照的小片段（如把 50 行的 process_order 拆成四个职责明确的函数调用），比抽象的模式定义更易理解。

Q5：我的问题很具体，比如「继承还是组合」，应该怎么提问效果最好？

A：建议提供「现状代码 + 你的意图 + 你的顾虑」三段式信息。例如贴出一段在 __init__ 里 new 依赖的继承实现，说明「我想让它可测试」，技能会围绕组合优于继承和依赖注入给出改造方案，并附带用假对象装配的测试示例。上下文越具体，得到的建议越贴合你的项目。