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. 综合提炼 最佳方案往往融合了多种设计的优点。可以问用户： - "哪个方案最贴合你的主要使用场景？" - "其他方案中有没有值得借鉴的元素？" ## 评价标准 出自《软件设计哲学》： **接口简洁性**：方法越少、参数越简单 = 越容易学习、越不容易用错。 **通用性**：能够应对未来的使用场景而无需修改。但要警惕过度泛化。 **实现效率**：接口形态是否有利于高效实现？还是会迫使内部结构变得别扭？ **深度**：小接口封装大量复杂性 = 深模块（好）。大接口背后实现单薄 = 浅模块（应避免）。 ## 反模式 - 不要让子代理产出相似的方案——必须确保方案之间有本质差异 - 不要跳过对比环节——价值就在于方案之间的碰撞 - 不要动手实现——这一步只关注接口形态 - 不要以实现难度作为评价标准