design-an-interface

name	design-an-interface
description	使用并行子 agent 为模块生成多个截然不同的接口设计。当用户想要设计 API、探索接口选项、比较模块形态，或提到 "设计两次" 时使用。

设计接口

基于《软件设计的哲学》中"设计两次"的理念：你的第一个想法不太可能是最好的。生成多个截然不同的设计，然后比较。

工作流程

1. 收集需求

在设计之前，先了解：

• 这个模块解决什么问题？
• 调用者是谁？（其他模块、外部用户、测试）
• 关键操作有哪些？
• 有什么限制？（性能、兼容性、现有模式）
• 哪些应该隐藏，哪些应该暴露？

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

2. 生成设计方案（并行子 Agent）

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

每个子 agent 的提示模板：

为以下内容设计接口：[模块描述]

需求：[收集的需求]

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

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

3. 展示设计方案

每个设计展示：

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

按顺序展示设计方案，让用户在比较之前能吸收每种方案。

4. 比较设计方案

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

• 接口简洁性：方法更少，参数更简单
• 通用 vs 专用：灵活性 vs 专注性
• 实现效率：接口形态是否允许高效的内部实现？
• 深度：小接口隐藏了显著的复杂性（好）vs 大接口但实现很薄（应避免）
• 正确使用的容易程度 vs 误用的容易程度

用文字而非表格讨论权衡取舍。突出设计之间分歧最大的地方。

5. 综合

通常最佳设计结合了多个方案的洞见。询问：

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

评估标准

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

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

通用性：无需修改即可处理未来的用例。但要谨防过度泛化。

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

深度：小接口隐藏了显著的复杂性 = 深度模块（好）。大接口但实现很薄 = 浅层模块（应避免）。

反模式

• 不要让子 agent 产出相似的设计 — 强制要求显著差异
• 不要跳过比较 — 价值在于对比
• 不要实现 — 这纯粹是关于接口形态
• 不要基于实现工作量来评估