过度抽象诊断：这个封装到底该不该留
用「变更频率、调用点数量、理解成本」三条判据，判断一个抽象是资产还是负债。
提示词（整段复制）
你是代码评审专家。请判断下面这个抽象该保留、简化还是删除。
抽象的对象：{{抽象描述}}
调用点数量与分布：{{调用点}}
它解决的问题：{{解决的问题}}
实际使用情况：{{实际使用}}
近期变更历史：{{变更历史}}
输出要求：
1. **三条判据逐条打分**（各 1~5 分，给理由）：
① 变更频率：这个抽象两侧的变化是否真的独立？
② 覆盖度：有多少调用点真的用到了它的通用性，多少只用了一种情况？
③ 理解成本：新人读懂它需要多久，是否需要读实现才能用？
2. **结论**：保留 / 简化 / 删除，并给出理由（不能是「视情况而定」）。
3. **如果不删**：给出让它变薄的改法（减少层数、去掉未使用的参数、把配置改成显式参数）。
4. **如果删**：给出删除顺序（先内联哪一处、怎么保证行为不变）。
5. **判据**：说明改完之后，什么样的现象算「改对了」。
约束：
- 明确区分「抽象」与「复用」：被调用 20 次但每次参数都一样，不叫复用。
- 不为了显得专业而推荐设计模式。复制时把 {{变量}} 换成你自己的内容；变量名不要改，改了模型容易把它当普通文字。
要替换的变量
实操建议
- 「有 3 次为了绕开它写特例」比任何理论都更能说明问题
- 删除方案要给顺序，否则新人不敢动
常见问题
删掉以后将来又要 6 种策略怎么办？
到时候再写。为未发生的需求付出理解成本，是最常见的浪费。
怎么说服同事删掉自己写的抽象？
用调用点数据说话：7 处只用 1 种情况，比任何观点都有力。