# Interface Design Lab

> 为模块生成多种截然不同的接口设计方案，通过并行探索产出多个接口签名、使用示例和封装说明，并详细对比其简洁性、通用性、深度与易用性。当用户需要设计API、探索接口方案、对比模块形态，或明确提及“设计两次”原则、并行设计、接口形态比较时触发。

- Skill: `haomingz/interface-design-lab` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add haomingz/interface-design-lab`
- Raw SKILL.md: https://api.skillmd.com/api/skills/haomingz/interface-design-lab/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: haomingz (https://skillmd.com/u/haomingz)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/haomingz/interface-design-lab

---


# 接口形态探索

基于《软件设计哲学》中的"设计两次"原则：你的第一个方案不太可能是最好的。先生成多种截然不同的设计，再加以比较。

## 工作流程

### 1. 收集需求

在开始设计之前，先了解以下信息：

- [ ] 这个模块要解决什么问题？
- [ ] 谁会调用它？（其他模块、外部用户、测试代码）
- [ ] 核心操作有哪些？
- [ ] 有什么约束条件？（性能、兼容性、现有模式）
- [ ] 哪些内容应该封装在内部，哪些需要暴露？

关键问题："这个模块需要做什么？谁会用到它？"

### 2. 生成设计方案（并行子代理）

同时启动 3 个以上的子代理（使用 Task 工具），每个子代理必须产出一种**截然不同**的设计方案。

```
每个子代理的提示词模板：

为以下模块设计接口：[模块描述]

需求：[已收集的需求]

本设计的约束条件：[为每个代理分配不同的约束]
- 代理 1："方法数量最少——目标 1-3 个方法"
- 代理 2："灵活性最大——支持尽可能多的使用场景"
- 代理 3："为最常见场景优化"
- 代理 4："借鉴 [特定范式/库] 的思路"

输出格式：
1. 接口签名（类型/方法）
2. 使用示例（调用方如何使用）
3. 该设计在内部隐藏了什么
4. 该方案的优劣权衡
```

### 3. 展示设计方案

每个方案需展示：

1. **接口签名** - 类型、方法、参数
2. **使用示例** - 调用方在实际场景中如何使用
3. **封装内容** - 内部隐藏了哪些复杂性

逐个展示方案，让用户充分理解每种思路后再进行对比。

### 4. 对比方案

展示完所有方案后，从以下维度进行对比：

- **接口简洁性**：方法越少、参数越简单，越容易学习和正确使用
- **通用性 vs 专用性**：灵活度与专注度的取舍
- **实现效率**：接口形态是否有利于高效实现？还是会导致内部结构别扭？
- **深度**：小接口封装大量复杂性 = 深模块（好）；大接口背后实现单薄 = 浅模块（应避免）
- **易用性** vs **误用风险**

用文字讨论权衡取舍，而非表格。重点指出各方案分歧最大的地方。

### 5. 综合提炼

最佳方案往往融合了多种设计的优点。可以问用户：

- "哪个方案最贴合你的主要使用场景？"
- "其他方案中有没有值得借鉴的元素？"

## 评价标准

出自《软件设计哲学》：

**接口简洁性**：方法越少、参数越简单 = 越容易学习、越不容易用错。

**通用性**：能够应对未来的使用场景而无需修改。但要警惕过度泛化。

**实现效率**：接口形态是否有利于高效实现？还是会迫使内部结构变得别扭？

**深度**：小接口封装大量复杂性 = 深模块（好）。大接口背后实现单薄 = 浅模块（应避免）。

## 反模式

- 不要让子代理产出相似的方案——必须确保方案之间有本质差异
- 不要跳过对比环节——价值就在于方案之间的碰撞
- 不要动手实现——这一步只关注接口形态
- 不要以实现难度作为评价标准