名称: 抽象-具体-示例 描述: 当需要在不同专业水平解释概念时使用，在抽象原则和具体实现之间移动，通过测试想法对抗场景来识别边缘情况，设计分层文档，将复杂问题分解为可操作步骤，或弥合策略执行差距。当用户提到抽象级别、使概念具体化或以不同深度解释时调用。
抽象阶梯框架
目录
目的
创建结构化的抽象阶梯，展示概念如何从高级原则转化为具体、可操作的示例。这有助于弥合沟通差距，揭示隐藏假设，并测试抽象想法是否在实践中可行。
何时使用此技能
- 用户需要向不同专业水平解释同一概念
- 任务需要在“为什么”（抽象）和“如何”（具体）之间移动
- 通过测试原则对抗特定场景来识别边缘情况
- 设计分层文档（概述 → 细节 → 具体内容）
- 将复杂问题分解为可操作步骤
- 验证高级目标是否转化为具体行动
- 弥合策略和执行差距
触发短语： “抽象级别”、“使这个具体化”、“以不同级别解释”、“从原则到实现”、“高级和详细视图”
什么是抽象阶梯？
一个多级结构（通常3-5级）连接通用原则到具体细节：
- 级别1（抽象）： 通用原则、理论、价值
- 级别2： 框架、标准、类别
- 级别3（中间）： 方法、途径、一般示例
- 级别4： 具体实现、具体实例
- 级别5（具体）： 精确细节、测量、边缘情况
快速示例：
- L1: “软件应可维护”
- L2: “使用模块化架构”
- L3: “应用依赖注入”
- L4: “UserService注入IUserRepository”
- L5:
constructor(private repo: IUserRepository) {}
工作流程
复制此清单并跟踪进度：
抽象阶梯进度：
- [ ] 步骤1：收集需求
- [ ] 步骤2：选择方法
- [ ] 步骤3：构建阶梯
- [ ] 步骤4：验证质量
- [ ] 步骤5：交付和解释
步骤1：收集需求
询问用户澄清主题、目的、受众、范围（建议4级）和起始点（自上而下、自下而上或中间向外）。这确保阶梯满足用户实际需求。
步骤2：选择方法
对于主题清晰的简单案例 → 使用resources/template.md。对于具有多个平行阶梯或特殊约束的复杂案例 → 研究resources/methodology.md。查看示例 → 向用户显示resources/examples/（api-design.md、hiring-process.md）。
步骤3：构建阶梯
创建abstraction-concrete-examples.md，包含主题、3-5个不同抽象级别、级别间连接和2-3个边缘情况。确保顶级通用、底层有可测量细节，且过渡逻辑。方向选项：自上而下（原则 → 示例）、自下而上（观察 → 原则）或中间向外（熟悉 → 双向）。
步骤4：验证质量
使用resources/evaluators/rubric_abstraction_concrete_examples.json自我评估。检查：每个级别不同、过渡清晰、顶级通用、底层具体、边缘情况揭示见解、假设已说明、无主题漂移、满足所述目的。最低标准：平均分数 ≥ 3.5。如果任何标准 < 3，在交付前修订。
步骤5：交付和解释
呈现完成的abstraction-concrete-examples.md文件。突出阶梯揭示的关键见解，注意发现的边缘情况或张力，并根据其原始目的建议应用。
常见模式
用于跨级别沟通：
- 与高管共享L1-L2（策略/原则）
- 与经理共享L2-L3（途径/方法）
- 与实施者共享L3-L5（细节/具体内容）
用于验证：
- 检查L5现实是否匹配L1原则
- 识别相邻级别间的差距
- 发现原则失效处
用于设计：
- 使用L1-L2指导决策
- 使用L3-L4指定需求
- 使用L5进行实际实施
防护栏
做：
- 在每个级别明确说明假设
- 测试挑战原则的边缘情况
- 使具体级别真正具体（数字、测量、具体内容）
- 使抽象级别广泛适用（不局限于领域）
- 确保每个级别基于前一级别可理解
不做：
- 使用模糊语言（“好”、“更好”、“适当”）而不定义术语
- 在级别间进行巨大概念跳跃
- 让不同级别漂移到不同主题
- 跳过验证步骤（必须使用标准）
- 前置专业知识 - 为目标受众清晰解释
快速参考
- 标准案例模板：
resources/template.md - 复杂案例方法：
resources/methodology.md - 学习示例：
resources/examples/api-design.md、resources/examples/hiring-process.md - 质量标准：
resources/evaluators/rubric_abstraction_concrete_examples.json