趣味构思

一种结构化但轻量级的构思技能，旨在快速从想法转向可操作的方向。它保留了协作设计的严谨性——探索意图、评估权衡和验证决策——同时消除了那些无法适应中小型任务的流程开销。

目标很简单：理解用户想要什么，共同思考选项，选择一个方向，然后开始行动。没有多阶段的仪式，没有强制性的设计文档，没有无休止的澄清循环。只有足够做出好决策的结构，不多不少。

基本规则

在用户明确批准方向之前，不得编写任何代码、生成任何文件或采取任何实施行动。即使任务看起来很明显，这也适用。构思的全部意义在于在构建之前暂停并思考。请尊重这个界限。

流程

digraph 趣味构思 {
    rankdir=TB
    node [shape=box style=rounded]

    发现 -> 提出
    提出 -> 汇聚
    汇聚 -> 已批准 [label="是"]
    汇聚 -> 提出 [label="否 (最多 2 次)"]
    已批准 [shape=diamond]
    已批准 -> 记录
    记录 -> 实施
}

• 发现 — 评估项目上下文——代码库、约定、现有模式。提出最多 3 个重点问题（优先使用多项选择）以澄清意图、约束和成功标准。将相关问题分批提出。如果请求已经很清晰，则直接跳到提出。
• 提出 — 提出 2 种方法，并说明权衡利弊。从您的建议开始，并解释原因。每个选项保持在一个简短的段落内。根据任务的复杂程度调整详细程度——简单工作用几句话，复杂决策则需要更多推理。
• 汇聚 — 获得明确的用户批准。如果被拒绝，修订并重新提出——最多 2 轮。如果仍然无法达成一致，请用户直接说明他们想要什么。快速选择一个足够好的方向，比慢慢选择一个完美的方向要好。
• 记录 — 将所选方向（内容、原因、关键决策）作为内联注释记录在您创建的第一个文件中，或在聊天中分享。除非用户要求，否则无需单独的设计文档。

原则

• 速度优于仪式感 — 构思的价值在于思考过程，而不是它产生的文档。在不能增加实际价值的地方，跳过形式。一个快速达成好决策的对话，胜过一份延误决策的精美文档。
• 你不需要它 — 仅针对当前所需进行设计。不要为尚不存在的需求引入抽象、扩展点或灵活性。如果它们以后出现，到时候再处理。推测性设计带来的问题比解决的问题多。
• 偏向行动 — 当两个选项质量相近时，只需选择一个并继续。花额外时间试图找到理论上最优的选择，几乎永远不会带来回报。行动创造清晰度。通过构建学到的，比通过反复斟酌学到的更多。
• 批量发现 — 将您的澄清性问题一起提出，而不是跨多条消息一次一个。拖沓的发现过程会浪费用户的时间并打断他们的思路。在一轮中获取所需信息，然后继续前进。
• 深度与任务匹配 — 使流程的强度与任务的强度相匹配。一个小错误修复或配置更改可能通过一条消息就完成步骤 1 和 2。一个新子系统则需要在步骤 2 中进行更彻底的探索。让工作的复杂性来引导对话的复杂性。