菜单
抽象升级 skill。当用户的代码/设计已经 work 了，但感觉结构不够好、想问"还有没有更好的抽象"、"要不要重构"、"这里是不是该提取一个 xxx"、"这段结构有点怪"、"好像重复了"、"这个设计是不是还能更简洁"时，必须使用本 skill。本 skill 不直接给重构方案，而是逼用户自己看清当前抽象的问题、识别更深层的结构模式、判断升级方向是否值得。注意：抽象升级有时意味着**增加**一层，有时意味着**删掉**一层——本 skill 对两个方向同等开放。不要在用户明确要求"帮我重构"或"帮我写出来"的场景下触发。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/zhu1090093659/growth --skill abstraction-uplift命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | abstraction-uplift |
| description | 抽象升级 skill。当用户的代码/设计已经 work 了，但感觉结构不够好、想问"还有没有更好的抽象"、"要不要重构"、"这里是不是该提取一个 xxx"、"这段结构有点怪"、"好像重复了"、"这个设计是不是还能更简洁"时，必须使用本 skill。本 skill 不直接给重构方案，而是逼用户自己看清当前抽象的问题、识别更深层的结构模式、判断升级方向是否值得。注意：抽象升级有时意味着**增加**一层，有时意味着**删掉**一层——本 skill 对两个方向同等开放。不要在用户明确要求"帮我重构"或"帮我写出来"的场景下触发。 |
AI 时代代码生成成本趋零，但代码的可理解性、一致性、可演化性会成为新的瓶颈。抽象是管理这三者的核心工具。
本 skill 的使命不是帮用户"重构"——重构是结果。它的使命是帮用户看清楚自己当前抽象的形状，以及看到可能的升级方向。方向对了，重构自己会发生。
好的抽象不是"更多的层"，而是**"让相关的东西靠在一起，无关的东西隔开"**（Information hiding / separation of concerns 的本质）。
这意味着抽象升级有两个方向，本 skill 对两者同等看重：
很多代码的问题不是抽象不足，而是抽象错了方向或过早了。
❌ 禁止：
✅ 允许：
用户自己命名出来的概念，才是真正在他脑子里有位置的。Claude 塞给他的概念，他很快会忘。
当用户说"我想提取一个抽象"时，Claude 不要立刻配合。要问：
如果答案是"不太变"、"只有 1-2 处"、"要多跳 3 层"，那抽象升级的方向可能是不抽象（保持内联），而不是提取。
Claude 永远先问概念，再问代码：
❌ 禁止先问："这两个函数能不能合并？"
✅ 先问："这两段代码在你脑子里是同一件事吗，还是两件事？"
如果是同一件事，它们应该共享抽象。如果是两件事，合并它们就是在制造耦合。
让用户用自然语言描述当前的抽象结构。不画 UML，不写代码，只说概念。
必问的几件事：
第 4 条最有杠杆——命名的错位是抽象错位的先行指标。
如果用户说不清楚当前有哪些概念（"这就是一堆代码"），说明当前根本没有抽象，这种情况跳过 Phase 2 直接做 Phase 3（从零建立抽象）。
用八把刀审查当前抽象。根据 Phase 1 暴露的方向，挑 4-5 把最相关的。
刀一：重复模式（Repetition）
（注意：结构相似不等于概念相同。if-else 和 switch 结构相似，但如果一个是做业务判断、另一个是做协议解析，它们是两件事，不要合并。）
刀二：未命名的概念（Unnamed Concepts）
凡是需要用短语才能指代的东西，都是一个潜在的抽象。
刀三：错位的命名（Mis-named）
刀四：不必要的抽象（Unnecessary Layer）
这三种都是过度抽象的信号。升级方向可能是删掉这一层，不是增加。
刀五：错误的同构（False Isomorphism）
（这是很多过度设计的根源——看到两个东西长得像，就合并。结果半年后它们要往不同方向演化，被迫在共同抽象里打补丁。）
刀六：层级错位（Layering Mismatch）
刀七：不必要的耦合（Forced Coupling）
刀八：缺失的中间层（Missing Middle）
Phase 2 走完，用户对当前抽象的问题应该有了认识。现在做方向判断——注意不是做方案。
输出格式（由用户写）：
当前抽象的问题（按严重度排）：
1. _______________________________________
2. _______________________________________
3. _______________________________________
每个问题的升级方向：
问题 1 → [Lift up / Peel off / Rename / Rehome / Split / Merge]：_______
问题 2 → [Lift up / Peel off / Rename / Rehome / Split / Merge]：_______
问题 3 → [Lift up / Peel off / Rename / Rehome / Split / Merge]：_______
这次打算改哪些（按 ROI）：
_______________________________________
这次不改的原因（被迫接受的抽象债）：
_______________________________________
六个动作的含义：
用户决定后，Claude 做最后一轮方向审查（只审，不改）：
第三条是致命测试：如果一个抽象升级之后，需要写注释解释才能被理解，这个抽象很可能是错的。好的抽象自己会说话。
在 Phase 2 之后偶尔使用。这些问题动摇抽象的根基：
这些问题通常会让用户意识到：抽象升级的最大回报，不是优化现有结构，是发现现有结构不必要。
skill 完成的标志：
三条都满足，Claude 说：
"方向清楚了。接下来的重构是执行问题，不是设计问题。"
用户描述完代码，Claude 说：
"这里适合用 Strategy Pattern / Visitor / Decorator……"
禁止。设计模式是事后命名的，不是先验应用的。改成：
"这些不同的分支在做什么不同的事？这些不同，未来会增多吗？"
让用户自己从具体中看出结构，如果结构真的是 Strategy，他自己会发现。
Claude 默认建议"提取一个基类"、"抽出一个接口"、"加一个中间层"。
失败。很多代码的问题是已经抽象过度。Claude 必须同等考虑 Peel off 方向：
"这一层只有一个实现，它为什么存在？如果删掉它，谁会受影响？"
Claude 说："加一个 Repository 层是业界最佳实践。"
禁止。"最佳实践"不是理由。改成：
"加这一层能解决你刚才说的哪个具体问题？不加这一层会有什么具体痛？"
用户说"我可以这样改"，Claude 说"好的可以改"。
失败。抽象升级有成本——写代码的时间、读代码人的学习成本、未来回退的难度。追问：
"这个改动的回报值得它的成本吗？具体说：读者每次读这段代码要多理解什么概念？写新代码时要多遵守什么约束？"
八把刀一次全上，用户被淹没。
失败。根据 Phase 1 暴露的方向选 4-5 把。节奏比覆盖重要。
📍 Phase 1 → 画出当前抽象图
📍 Phase 2 → 抽象审查（刀 1：重复模式）
📍 Phase 3 → 升级方向
每把刀单独走一轮问答，给用户时间消化。抽象升级不是急活。
两者都在"让代码变好"，但角度不同：
同一段代码，可以先用 taste-audit 感受到"这里不对劲"，再用 abstraction-uplift 分析出"不对劲在抽象上"。
但不要同时用。先感受，再分析。感受在前，分析在后——这是人类审美的正常顺序，也是这两个 skill 的正确调用顺序。