| name | design-an-interface |
| description | 使用并行子代理为模块生成多个截然不同的接口设计. 当用户想要设计 API, 探索接口选项, 比较模块形状, 提到 "设计两版", "接口设计" 或 "design it twice" 时使用. |
设计接口
基于《软件设计的哲学》中的 "Design It Twice": 你的第一个想法不太可能是最好的. 生成多个截然不同的设计, 然后进行比较.
工作流程
1. 收集需求
在设计之前, 了解:
询问: "这个模块需要做什么? 谁会使用它?"
2. 生成设计(并行子代理)
使用 Task 工具同时生成 3+ 个子代理. 每个必须产生一个截然不同的方法.
每个子代理的提示模板:
为以下内容设计一个接口: [模块描述]
需求: [收集的需求]
此设计的约束: [为每个代理分配不同的约束]
- Agent 1: "最小化方法数量 -- 目标最多 1-3 个方法"
- Agent 2: "最大化灵活性 -- 支持多种用例"
- Agent 3: "为最常见的场景优化"
- Agent 4: "从 [特定范式/库] 中获取灵感"
输出格式:
1. 接口签名(类型/方法)
2. 使用示例(调用者如何使用)
3. 该设计在内部隐藏了什么
4. 这种方法的权衡
3. 呈现设计
展示每个设计, 包括:
1.** 接口签名** - 类型, 方法, 参数
2.** 使用示例** - 调用者在实践中如何使用它
3.** 隐藏的内容** - 保持内部的复杂性
按顺序呈现设计, 以便用户可以在比较之前吸收每种方法.
4. 比较设计
显示所有设计后, 对它们进行比较:
- 接口简洁性: 更少的方法, 更简单的参数
- 通用 vs 专用: 灵活性 vs 专注性
- 实现效率: 形状是否允许高效的内部实现?
- 深度: 隐藏大量复杂性的小接口(好)vs 实现薄弱的大接口(坏)
- 易于正确使用 vs 易于误用
以散文方式讨论权衡, 而非表格. 突出显示设计差异最大的地方.
5. 综合
通常最好的设计结合了多个选项的见解. 询问:
- "哪种设计最适合你的主要用例?"
- "其他设计中有值得整合的元素吗?"
评估标准
来自《软件设计的哲学》:
接口简洁性: 更少的方法, 更简单的参数 = 更容易学习和正确使用.
通用性: 可以在不更改的情况下处理未来的用例. 但要注意过度通用化.
实现效率: 接口形状是否允许高效实现? 还是强制笨拙的内部实现?
深度: 隐藏大量复杂性的小接口 = 深度模块(好). 实现薄弱的大接口 = 浅层模块(避免).
反模式
- 不要让子代理产生相似的设计 - 强制根本差异
- 不要跳过比较 - 价值在于对比
- 不要实现 - 这纯粹是关于接口形状
- 不要基于实现工作量进行评估
