haomingz 接口形态探索
基于《软件设计哲学》中的"设计两次"原则：你的第一个方案不太可能是最好的。先生成多种截然不同的设计，再加以比较。
工作流程
1. 收集需求
在开始设计之前，先了解以下信息：
- 这个模块要解决什么问题？
- 谁会调用它？（其他模块、外部用户、测试代码）
- 核心操作有哪些？
- 有什么约束条件？（性能、兼容性、现有模式）
- 哪些内容应该封装在内部，哪些需要暴露？
关键问题："这个模块需要做什么？谁会用到它？"
2. 生成设计方案（并行子代理）
同时启动 3 个以上的子代理（使用 Task 工具），每个子代理必须产出一种截然不同的设计方案。
每个子代理的提示词模板：
为以下模块设计接口：[模块描述]
需求：[已收集的需求]
本设计的约束条件：[为每个代理分配不同的约束]
- 代理 1："方法数量最少——目标 1-3 个方法"
- 代理 2："灵活性最大——支持尽可能多的使用场景"
- 代理 3："为最常见场景优化"
- 代理 4："借鉴 [特定范式/库] 的思路"
输出格式：
1. 接口签名（类型/方法）
2. 使用示例（调用方如何使用）
3. 该设计在内部隐藏了什么
4. 该方案的优劣权衡
3. 展示设计方案
每个方案需展示：
- 接口签名 - 类型、方法、参数
- 使用示例 - 调用方在实际场景中如何使用
- 封装内容 - 内部隐藏了哪些复杂性
逐个展示方案，让用户充分理解每种思路后再进行对比。
4. 对比方案
展示完所有方案后，从以下维度进行对比：
- 接口简洁性：方法越少、参数越简单，越容易学习和正确使用
- 通用性 vs 专用性：灵活度与专注度的取舍
- 实现效率：接口形态是否有利于高效实现？还是会导致内部结构别扭？
- 深度：小接口封装大量复杂性 = 深模块（好）；大接口背后实现单薄 = 浅模块（应避免）
- 易用性 vs 误用风险
用文字讨论权衡取舍，而非表格。重点指出各方案分歧最大的地方。
5. 综合提炼
最佳方案往往融合了多种设计的优点。可以问用户：
- "哪个方案最贴合你的主要使用场景？"
- "其他方案中有没有值得借鉴的元素？"
评价标准
出自《软件设计哲学》：
接口简洁性：方法越少、参数越简单 = 越容易学习、越不容易用错。
通用性：能够应对未来的使用场景而无需修改。但要警惕过度泛化。
实现效率：接口形态是否有利于高效实现？还是会迫使内部结构变得别扭？
深度：小接口封装大量复杂性 = 深模块（好）。大接口背后实现单薄 = 浅模块（应避免）。
反模式
- 不要让子代理产出相似的方案——必须确保方案之间有本质差异
- 不要跳过对比环节——价值就在于方案之间的碰撞
- 不要动手实现——这一步只关注接口形态
- 不要以实现难度作为评价标准