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. 综合提炼

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

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

评价标准

出自《软件设计哲学》：

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

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

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

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

反模式

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