用途：这是一份 Python 设计模式技能，目标是用基础设计原则写出可维护的 Python 代码，让系统更易理解、测试和修改。
适用时机：设计新组件或服务；重构复杂、纠缠的代码；判断是否该引入抽象；在继承与组合之间选择；评估代码复杂度与耦合度；规划模块化架构。
核心概念：KISS（选择能解决问题的最简方案，复杂度需由具体需求证明）；单一职责（每个单元只有一个变更理由，关注点分离到聚焦组件）；组合优于继承（通过组合对象构建行为，而非扩展类）；三次法则（出现三处实例后再抽象，重复常优于过早抽象）。
用法要点：保持简单，选择可用的最简方案；单一职责，每个单元只有一个变更理由；分离关注点，各层职责清晰；组合而非继承，用对象组合获得灵活性；三次法则，抽象前先等待；函数保持短小（约 20-50 行，视复杂度而定），单一用途；依赖注入，用构造函数注入提升可测试性；先删再抽象，移除死代码后再考虑模式；逐层测试，对每个关注点做隔离测试；显式优于取巧，可读代码胜过优雅代码。快速示例给出简化写法：FORMATTERS = {"json": JsonFormatter, "csv": CsvFormatter}，以及 def get_formatter(name: str) -> Formatter: return FORMATTERSname。更详细的模式与实例放在 references/details.md 中，导航层信息不足时可阅读该文件。
常见问题处理：类变大且有多个职责但拆分感觉别扭时，用“变更理由”测试列出所有可能触发修改的变更，若跨不同领域（如 HTTP 解析、业务规则、格式化）则拆分；构造函数注入导致 7 个以上参数，说明类职责过多，应先拆分为更小单元；组合产生难以追踪的深层嵌套包装时，保持组合层级浅（2-3 层），必要时考虑基于 Protocol 的方式或简单函数组合；三次法则提示暂不抽象但重复已导致危险分歧时，应立即抽取并补充覆盖共享行为的测试；服务层导入 API 层属分层违规，应引入共享类型/模型层，让依赖方向保持向下（API → Service → Repository）。
相关技能：python-testing-patterns 可用此处建立的依赖注入结构对各层做隔离测试；python-project-setup 可从项目结构上强制层边界。
限制：资料未提供安装命令、价格、平台支持或性能数据，相关内容暂未提供。