用途：在创建共享工具、组件、门面（facade）、Hook、服务包装器，或面对 DRY/WET 取舍时，判断应当抽象、复制、内联还是拆分代码。核心理念是“宁可复制，也不要错误抽象”，等待真实模式出现后再抽象，目标是让代码易于修改，只在能真正降低复杂度时才使用抽象。
主要规则：不足 3 处真实使用前不要抽象，除非有强领域理由；形状相似不等于行为一致；优先清晰复制而非参数繁多的辅助函数；避免每个调用方都要新增标志位的抽象；设计新抽象前先内联坏抽象；测试具体行为而非抽象的巧妙程度。
适合抽象的条件：同一行为出现在 3 处以上、需求稳定、调用方需要一起变更、名称与 API 显而易见、抽象减少的复杂度多于增加的复杂度。不适合抽象的条件：仅 1-2 处使用、需求仍在变化、调用方需要不同行为、API 需要大量可选参数、初级开发者必须同时学习包装器和底层工具、手动跨文件修改更简单。
门面规则：当门面能隐藏真实复杂度或强制有用约束时使用，例如日期选择器隐藏日历、本地化、键盘与无障碍逻辑，按钮强制设计系统变体；简单 HTML 或一次性样式则跳过门面。
修复错误抽象：将抽象内联到各调用方，删除各调用方中未使用的分支，保留临时重复，比较当前用例，仅重新提取稳定的共享行为。
审查问题：实际调用方是谁？它们是否因同一原因变化？哪些参数只为满足某个调用方而存在？复制是否更清晰？能否删除抽象让代码更简单？
输出格式为 Abstraction Review，包含 Decision（keep/duplicate/inline/re-extract）、Evidence（调用方与行为）、Risk（耦合、变更或没有）、Change（最小安全下一步）。参考资料包括 Sandi Metz 的 The Wrong Abstraction、Dan Abramov 的 The Wet Codebase、Kent C. Dodds 的 AHA Programming。具体安装与调用方式暂未提供。