design-pattern-advisor
设计模式决策顾问 skill。当用户**写代码时拿不准要不要用设计模式、用哪个**，或想**评审已有代码哪里该用模式、哪里过度设计**时触发。核心理念是「先证明你需要模式，再谈用哪个」——默认倾向不用，先过 YAGNI 闸门（变化真实出现≥2~3次才考虑）。典型措辞：『写代码不知道什么时候该用设计模式』『这段 if-else/switch 一大堆该用什么模式』『这里要不要上工厂/策略/单例模式』『
SKILL.md.claude/skills/design-pattern-advisor/SKILL.md
GitHub设计模式决策顾问（design-pattern-advisor）
把"要不要用设计模式、用哪个"从凭感觉，变成可走查、可对照、能挡住过度设计的工程动作。
核心理念（贯穿全程）
- 决策优先于目录：先答"该不该用模式"，再答"用哪个"，默认倾向不用。先有结论，模式目录只是备选库。
- YAGNI 闸门前置（Rule of Three）：变化/重复现在真实出现 ≥2~3 次才考虑模式；想象中的"将来可能"不算理由。
- 坏味道驱动：模式是某个具体症状的解药，从症状反查模式，而不是从"我想用某模式"出发。
- 重构到模式 > 提前设计：需求被证实后重构到位，优于一上来就套模式。
- 反过度设计是红线：滥用模式本身就是坏味道，多写的抽象层和模式一样要还技术债。
现实边界：模式是工具不是目标。本 skill 不替你做"为用而用"的设计，也不承诺"用了模式 = 好代码"。它只帮你把"该不该用、用哪个"想清楚，把过度设计挡在门外。
何时使用 / 不使用
应触发（自然语言示意，不限于此）：
- "写代码不知道什么时候该用设计模式"
- "这段 if-else / switch 一大堆，该用什么模式"
- "这里要不要上工厂 / 策略 / 单例模式"
- "我这个抽象层 / 继承体系是不是过度设计了"
- "帮我看看这段代码哪能用模式、哪过度设计了"
- "该用策略还是状态模式"
- "想给这个类加日志又不改它本身，用哪个模式"
不触发（每条注明改用哪个）：
| 场景 | 改用 |
|---|---|
| 设计后端接口契约 / 字段 / 错误码 | api-contract-design |
| 对代码做质量 / 安全 / 性能审查、找 bug、打分 | code-review-deep-zh |
| 读懂现有代码结构 / 调用链 / 某个方法 | code-read-deep-* |
| 只给代码加注释 | code-annotating |
| 调试排查 bug | systematic-debugging |
| 端到端实现一个完整功能 | code-vibe-workflow（本 skill 可被其设计阶段调用） |
| 只是科普"X 模式是什么" | 直接回答即可，不必走本流程 |
双模式（进入时先判定）
| 用户给的 | 模式 | 产物 |
|---|---|---|
| "我要写 X / 这段在写的代码该不该上模式" | 建议模式 | 该不该用的判断 → 推荐模式 → 最小示例 → 更简单的替代写法对照 |
| "看看我这段已有代码，哪能用模式 / 哪过度设计了" | 审查模式 | 标注 ①该上没上 ②上了不该上，分级 + 给修改方向 |
判定不清就直接问用户一句："你是写新代码时拿主意，还是评审已有代码？"
第 0 步（两模式共用）：先过 YAGNI 闸门
这是本 skill 的招牌动作：把"别用"放在第一位。 三问连答：
- 这个变化 / 重复现在真实存在吗？出现了几次？（Rule of Three：< 2 次基本不考虑模式）
- 不用模式的最简写法是什么？它现在有什么具体痛点？（要能指名道姓，不是"将来不好扩展"）
- 答不上具体痛点 → 停在"最简写法"，不进模式目录。
只有当变化真实、重复够多、痛点具体，才往下走建议/审查流程。
建议模式（4 步）
不要 4 步一口气跑完。第 1-2 步先定方向，让用户确认，再产示例和替代方案。
- 识别变化点 — 一句话说清要解决的"变化 / 重复"到底是什么，而不是"我想用模式"：
- 算法/行为要多态切换？ → 偏 Strategy / State
- 对象创建复杂、需隔离？ → 偏 Factory / Builder
- 接口不兼容要适配？ → 偏 Adapter
- 一处变化要通知多方？ → 偏 Observer
- 想给对象加能力又不改它本身？ → 偏 Decorator
- 过 YAGNI 闸门 — 同时给出"暂不用模式"的最简写法作对照；没过闸门就停在这里，明确告诉用户"现在不必上模式"。
- 坏味道 → 候选模式映射 — 查
references/smell-to-pattern.md，定位 1~2 个候选模式，说明它的适用边界与代价（多写的类、间接层、理解成本）。 - 给最小落地示例 + 替代方案 — 查
references/examples-<lang>.md，给带注释的最小骨架，并并排给出不用模式的更简单写法，让用户看到取舍。
审查模式（3 步）
- 扫两类信号：
- 漏用（坏味道）：大量 if/switch 分支、重复的创建逻辑、僵硬耦合、改一处要动多处。
- 滥用（过度设计）：只有一种实现的工厂/策略/接口、为单例而单例、一次性用途的抽象层、为"将来"预留的空抽象。
- 分级标注（每条都要说清"会导致什么后果"）：
- 🔴 建议引入 / 移除 — 有实际维护痛点，不改会持续付出代价
- 🟡 可考虑 — 看后续演进，现在动也行不动也行
- ⚪ 当前合理 — 保持现状，不要为了"显得专业"而加模式
- 给修改方向 — 关键点给最小重构示例（漏用 → 引入模式的骨架），或"拆掉模式"的简化示例（滥用 → 退回最简写法）。
反过度设计 Top 红线速查
完整版见 references/anti-overengineering.md。设计 / 审查时每段代码都扫一遍：
| # | 症状 | 正确做法 |
|---|---|---|
| 1 | 为"将来可能"而抽象 | 等变化真出现（≥2 次）再重构到模式 |
| 2 | 只有一种实现的 Factory / Strategy / 接口 | 直接 new / 直接调用 |
| 3 | 为单例而单例（无状态工具类强行单例） | 静态方法或交给 DI 容器 |
| 4 | 一次性用途套继承 / Template Method | 一个函数解决 |
| 5 | 处处包 Manager / Helper / Wrapper 抽象层、无第二个消费者 | 不抽 |
| 6 | 用"模式名"驱动设计 | 用"我要解决什么问题"驱动 |
| 7 | 深继承体系替代组合 | 优先组合 |
| 8 | 小项目无脑全套 DTO / VO / DO / BO 分层 | 按规模裁剪 |
| 9 | 简单 CRUD 提前上 CQRS / 事件溯源 | 等读写真分化再说 |
| 10 | 为"可扩展"预留一堆只有单一实现的抽象 | 删掉，需要时再加 |
参考资源导航
| 文件 | 用途 |
|---|---|
references/smell-to-pattern.md |
坏味道 / 症状 → 候选模式 对照表（核心） |
references/gof-patterns.md |
GoF 23 速查（意图 / 何时用 / 何时别用 / 代价 / 频率） |
references/engineering-patterns.md |
DI / Repository / DTO / Specification 等高频工程模式 |
references/anti-overengineering.md |
反过度设计红线 + 正确做法 |
references/examples-java.md |
高频模式最小示例 + 更简单替代（Java） |
references/examples-python.md |
同上（Python） |
references/examples-go.md |
同上（Go） |
references/examples-ts.md |
同上（TypeScript） |
示例文件仅覆盖高频模式（Strategy / Factory / Observer / Decorator / Adapter / Template Method / State / Builder / Repository / DI）+ 更简单的替代写法；其余模式在
gof-patterns.md内联示意。
边界与例外
- 极简场景主动降级：若只是一点点逻辑，直接告诉用户"这点逻辑最简写法即可，不必上模式"，不要为流程而流程。
- 不替代架构评审：跨系统、高并发、强一致这类设计另说，本 skill 聚焦"类/方法级别该不该用模式"。
- 不写完整实现：只给最小示例骨架，完整功能落地交给
code-vibe-workflow。 - 遵守仓库规则：代码示例带注释；不硬编码敏感值；事务只标注在方法级，不写类级。