design-an-interface

name	design-an-interface
description	使用并行子代理为一个模块生成多个截然不同的接口设计。当用户想设计 API、探索接口方案、对比模块形态，或提到 "design it twice" 时使用。

设计一个接口

基于《软件设计的哲学》（A Philosophy of Software Design）中的"设计两次"（Design It Twice）：你的第一个想法不太可能是最好的。先生成多个截然不同的设计，然后进行对比。

工作流

1. 收集需求

在设计之前，先弄清楚：

• 这个模块解决什么问题？
• 谁是调用方？（其他模块、外部用户、测试）
• 关键操作有哪些？
• 有什么约束？（性能、兼容性、既有模式）
• 哪些应当隐藏在内部 vs 暴露出来？

询问："这个模块需要做什么？谁会用它？"

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

使用 Task 工具同时启动 3 个以上子代理。每个都必须产出一个截然不同的方案。

每个子代理的提示模板：

为以下对象设计一个接口：[模块描述]

需求：[收集到的需求]

本设计的约束：[为每个代理分配一个不同的约束]
- 代理 1："最小化方法数量——目标是最多 1-3 个方法"
- 代理 2："最大化灵活性——支持多种用例"
- 代理 3："针对最常见的情况进行优化"
- 代理 4："从 [某个特定范式/库] 中汲取灵感"

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

3. 呈现设计

展示每个设计，包含：

1. 接口签名 —— 类型、方法、参数
2. 使用示例 —— 调用方在实践中实际如何使用它
3. 它隐藏了什么 —— 保留在内部的复杂性

按顺序逐个呈现设计，以便用户在对比之前能够吸收每一个方案。

4. 对比设计

展示完所有设计后，从以下维度对它们进行对比：

• 接口简洁性：更少的方法、更简单的参数
• 通用 vs 专用：灵活性 vs 聚焦
• 实现效率：这种形态是否允许高效的内部实现？
• 深度：小接口隐藏大量复杂性（好）vs 大接口配薄实现（差）
• 易于正确使用 vs 易于误用

用文字而非表格来讨论权衡。突出设计之间差异最大的地方。

5. 综合

最好的设计往往结合了多个方案的洞见。询问：

• "哪个设计最契合你的主要用例？"
• "其他设计中是否有值得纳入的元素？"

评估标准

出自《软件设计的哲学》：

接口简洁性：更少的方法、更简单的参数 = 更易于学习和正确使用。

通用性：能够在不改动的情况下应对未来的用例。但要警惕过度泛化。

实现效率：接口的形态是否允许高效的实现？还是会迫使别扭的内部结构？

深度：小接口隐藏大量复杂性 = 深模块（好）。大接口配薄实现 = 浅模块（应避免）。

反模式

• 不要让子代理产出相似的设计——强制要求截然不同
• 不要跳过对比——价值正在于对照
• 不要实现——这纯粹是关于接口形态
• 不要基于实现的工作量来评估