abstraction-concrete-examples

抽象阶梯框架

目录

• 工作流
  • 1. 收集需求
  • 2. 选择方法
  • 3. 搭建阶梯
  • 4. 验证质量
  • 5. 交付并说明
• 常见模式
• 防护措施
• 快速参考

阶梯包含 3–5 个层级，将普遍原则与具体细节联系起来。示例：

• L1：“软件应易于维护”
• L2：“采用模块化架构”
• L3：“应用依赖注入”
• L4：“UserService 注入 IUserRepository”
• L5：constructor(private repo: IUserRepository) {}

工作流

复制此清单并跟踪进度：

Abstraction Ladder Progress:
- [ ] Step 1: Gather requirements
- [ ] Step 2: Choose approach
- [ ] Step 3: Build the ladder
- [ ] Step 4: Validate quality
- [ ] Step 5: Deliver and explain

步骤 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