// 抽象升级 skill。当用户的代码/设计已经 work 了，但感觉结构不够好、想问"还有没有更好的抽象"、"要不要重构"、"这里是不是该提取一个 xxx"、"这段结构有点怪"、"好像重复了"、"这个设计是不是还能更简洁"时，必须使用本 skill。本 skill 不直接给重构方案，而是逼用户自己看清当前抽象的问题、识别更深层的结构模式、判断升级方向是否值得。注意：抽象升级有时意味着**增加**一层，有时意味着**删掉**一层——本 skill 对两个方向同等开放。不要在用户明确要求"帮我重构"或"帮我写出来"的场景下触发。
| 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 的正确调用顺序。
意图精炼 skill。当用户描述一个想做的事但表述模糊、想定义一个需求/spec、在纠结某个目标怎么表达、说"我想做个 XX"、"帮我定义一下 XX"、"我要实现的是 XX"、"我的目标是 XX"、"这个需求应该怎么写"时，必须使用本 skill。本 skill 不帮用户写需求，而是通过逼问把用户模糊的意图炼成精确、可验证、无歧义的一句话 spec。适用于做产品需求、定义 skill、写 API 合约、设计实验、制定个人目标等场景。不要在用户已经提供了清晰 spec 并要求执行的场景下触发。
判断红队 skill。当用户做出某个决策、倾向某个方案、要下判断、说"我决定做 X"、"我觉得应该 Y"、"我想选 Z"、"我的判断是……"、"我要 xxx 了"时，必须使用本 skill。本 skill 不帮用户做判断，而是扮演最锋利的反对者，系统性攻击用户的决策，逼用户看清自己的盲点、前提漏洞、失败场景。适用于技术选型、架构决策、职业选择、投资决定、产品方向等一切需要下注的场景。不要在用户只是在征求信息（"X 是什么"）或明确请求 Claude 给建议的场景下触发。
品味审查 skill。当用户展示一段代码、一个设计、一个架构方案、一个 API，或者一段文字内容（文档、文案、邮件），并想判断"这东西好不好"、"是不是还能更优雅"、"有没有哪里丑"时，必须使用本 skill。当用户说"你帮我看看这个"、"这样写对吗"、"有没有更好的写法"、"这个设计怎么样"时，也应触发。本 skill 不给评价，不给答案——它只问问题，逼用户自己看出美丑。不要在用户明确要求"直接给建议"或"帮我写"的场景下触发。