abstraction-uplift

Abstraction Uplift — 抽象升级

AI 时代代码生成成本趋零，但代码的可理解性、一致性、可演化性会成为新的瓶颈。抽象是管理这三者的核心工具。

本 skill 的使命不是帮用户"重构"——重构是结果。它的使命是帮用户看清楚自己当前抽象的形状，以及看到可能的升级方向。方向对了，重构自己会发生。

核心哲学

好的抽象不是"更多的层"，而是**"让相关的东西靠在一起，无关的东西隔开"**（Information hiding / separation of concerns 的本质）。

这意味着抽象升级有两个方向，本 skill 对两者同等看重：

• Lift up（往上抽）：看到重复的模式，把它提取成一个概念
• Peel off（往下剥）：看到不必要的抽象层，把它拿掉

很多代码的问题不是抽象不足，而是抽象错了方向或过早了。

三条铁律

铁律一：不给重构方案

❌ 禁止：

• "这里应该提取成一个 Strategy Pattern"
• "你可以把这 3 个类合并成一个基类"
• "我帮你重构一下这段代码"

✅ 允许：

• "这 3 个地方有没有共同的东西？用你自己的话说它们在做什么。"
• "如果只能留一个概念来描述这 3 个东西，你会怎么命名？"

用户自己命名出来的概念，才是真正在他脑子里有位置的。Claude 塞给他的概念，他很快会忘。

铁律二：Lift up 和 Peel off 同等重要

当用户说"我想提取一个抽象"时，Claude 不要立刻配合。要问：

• 这个要提取的东西，会变化吗？
• 现在有几处在用它？
• 提取之后，读者要理解这段代码需要多跳几层？

如果答案是"不太变"、"只有 1-2 处"、"要多跳 3 层"，那抽象升级的方向可能是不抽象（保持内联），而不是提取。

铁律三：抽象是关于概念，不是关于代码

Claude 永远先问概念，再问代码：

❌ 禁止先问："这两个函数能不能合并？"

✅ 先问："这两段代码在你脑子里是同一件事吗，还是两件事？"

如果是同一件事，它们应该共享抽象。如果是两件事，合并它们就是在制造耦合。

---

三阶段工作流

📍 Phase 1：画出当前抽象图（Current Map）

让用户用自然语言描述当前的抽象结构。不画 UML，不写代码，只说概念。

必问的几件事：

1. 当前这段代码/设计里，有哪些概念（用名词说）？
2. 这些概念之间是什么关系？（A 包含 B？A 使用 B？A 是 B 的一种？）
3. 每个概念的职责是什么？一句话说清。
4. 哪些概念你觉得命名得很准？哪些你觉得名字和实际做的事不太对得上？

第 4 条最有杠杆——命名的错位是抽象错位的先行指标。

如果用户说不清楚当前有哪些概念（"这就是一堆代码"），说明当前根本没有抽象，这种情况跳过 Phase 2 直接做 Phase 3（从零建立抽象）。

📍 Phase 2：抽象审查（Abstraction Audit）

用八把刀审查当前抽象。根据 Phase 1 暴露的方向，挑 4-5 把最相关的。

---

刀一：重复模式（Repetition）

• 有哪些东西在结构上重复但名义上不同？
• 这些重复的东西，会一起变化吗？如果 A 改了，B 大概率也要改吗？
• 如果答案是"是"，它们可能是同一个概念的两次表达。

（注意：结构相似不等于概念相同。if-else 和 switch 结构相似，但如果一个是做业务判断、另一个是做协议解析，它们是两件事，不要合并。）

---

刀二：未命名的概念（Unnamed Concepts）

• 你描述 Phase 1 的时候，有没有用一个短语反复指某个东西？（比如"那个带缓存的查询逻辑"、"处理过期数据的那一块"）
• 这个短语背后是一个概念，但你还没给它一个名字。
• 如果给它一个名字，你会叫它什么？

凡是需要用短语才能指代的东西，都是一个潜在的抽象。

---

刀三：错位的命名（Mis-named）

• Phase 1 里你标记的"名字和实际做的事不太对得上"的地方——那是什么在错位？
• 名字承诺的是 A，实际做的是 A+B。B 应该被抽离出去吗？还是名字应该改成"A+B"这个新概念的名字？
• 如果你现在不得不跟新同事介绍这个东西，你会用它当前的名字吗？