Based on the "Design It Twice" principle from A Philosophy of Software Design: your first idea is unlikely to be the best. Generate several fundamentally different designs, then compare them.
Workflow
1. Gather requirements
Before designing, you need to understand:
- What problem does this module solve?
- Who are the callers? (Other modules, external users, tests)
- What are the key operations?
- Are there constraints? (Performance, compatibility, existing patterns)
- What should be hidden internally, and what should be exposed?
Ask: "What does this module need to do? Who will use it?"
2. Generate designs (parallel subagents)
Use the Task tool to launch 3 or more subagents simultaneously. Each subagent must propose afundamentally differentapproach.
每个子代理的提示模板：
为以下模块设计接口：[模块描述]
需求：[收集到的需求]
本次设计的约束条件：[为每个代理分配不同的约束]
- Agent 1："最小化方法数量——目标是最多 1-3 个方法"
- Agent 2："最大化灵活性——支持多种使用场景"
- Agent 3："针对最常见的情况进行优化"
- Agent 4："从[特定范式/库]中汲取灵感"
输出格式：
1. 接口签名（类型/方法）
2. 使用示例（调用者如何使用）
3. 该设计在内部隐藏了什么
4. 该方案的权衡
3. Present the designs
When presenting each design, include the following:
- Interface signatures - Types, methods, parameters
- Usage examples - How callers use it in practice
- What is hidden - The complexity kept internal
Present the designs in order so the user can understand each approach before comparing them.
4. Compare the designs
After presenting all the designs, compare them in the following respects:
- Interface simplicity: Fewer methods, simpler parameters
- Generality vs. special-purpose: The trade-off between flexibility and focus
- Implementation efficiency: Does the interface shape allow an efficient internal implementation?
- Depth: A small interface hiding a lot of complexity (good design) vs. a large interface with a thin implementation (bad design)
- Easy to use correctly vs Easy to misuse
Discuss the trade-offs in prose rather than tables. Highlight where the designs differ the most.
5. Synthesize
Often, the best design combines the strengths of multiple approaches. Ask:
- "Which design best fits your primary use case?"
- "Are there elements from other designs worth incorporating?"
Evaluation Criteria
From A Philosophy of Software Design:
Interface simplicity: Fewer methods, simpler parameters = easier to learn and use correctly.
Generality: Able to handle future use cases without modification. But be careful not to over-generalize.
Implementation efficiency: Does the interface shape allow an efficient implementation? Or does it force an awkward internal structure?
Depth: A small interface hiding a lot of complexity = a deep module (good). A large interface with a thin implementation = a shallow module (avoid).
Anti-patterns
- Do not let subagents produce similar designs - require them to be fundamentally different
- Do not skip the comparison - the value lies in the contrast
- Do not implement — this is purely a design discussion about the interface shape
- Do not evaluate based on implementation difficulty