shrimp-brainstorming

Shrimp Brainstorming

概述

使用此技能，可将早期项目或商业想法转化为经过充分推敲的方向，而不必强行套用僵化的访谈流程。整个过程以研究为导向、以用户为主导：用户可以随时提问、质疑发现、提出限制条件或改变方向。

目标不是制造确定性，也不是生成一份泛泛的想法清单，而是找到最可信的切入点，揭示薄弱假设，确定成本最低且有用的测试；并在用户提出要求时，生成一份独立完整的 final-spec.md，说明结论以及得出结论的过程。

适用场景

用户遇到以下情况时使用：

• 提出一个模糊的产品、服务、初创公司、创作者事业、工具或商业想法。
• 希望围绕该想法开展市场、竞争对手、定价、可行性、变现、分销或客户研究。
• 希望验证、完善、转向或放弃该想法。
• 希望为项目或商业方向准备完整的文档交接材料。

以下情况不要使用：

• 只是查询简单事实，没有相关的项目或商业决策。
• 产品和范围已经确定，任务也已明确为具体实施工作。
• 泛泛地要求提供大量随机的初创点子，但并无意愿深入调查其中任何一个。

对话模式

这是由用户主导的探索，而非强制性的提问流程。

默认循环：

User raises an idea or question
→ research and return a useful, opinionated response
→ user reacts, redirects, or asks the next question
→ update the working record after a material change

只有当真正的歧义可能导致研究偏离正确的领域、客户或问题时，才提出澄清问题。与其反复停下来征求许可，不如说明假设并开展有用的工作。

不要默认采用一次只问一个问题的盘问方式。用户可以通过提问、要求研究、质疑前提或改变目标来引导对话。

工作模型

在整个探索过程中持续维护以下概念：

概念	含义
目标	本次探索必须明确的事项，例如决策、验证计划或交接规范。
当前论点	对机会和切入点的最佳当前表述。它可以改变。
决策前沿	接下来值得解决的关键问题或测试。
迷雾区	范围内尚不够明确、无法精确调查的不确定事项。
范围之外	有意推迟或排除在本次工作之外的内容。
已否决的路径	曾考虑但已否决的替代方案及其原因。

这些是组织工作的工具，不是问题工单，也不是强制工作流程。

工作流程

1. 明确方向

找出初始想法、预期目标，以及用户已经说明的重要限制条件。

• 必要时说明假设。
• 区分已知、推测和未知的内容。
• 在模糊想法尚未充分明确之前，不要将其扩展成详细规范。

完成标准： 已形成简短的当前论点和初步决策前沿。

2. 调查实际情况

研究决定该想法是否值得推进的事实。

根据想法的不同，调查以下内容：

• 直接竞争对手、相邻产品、替代方案和灵感来源。
• 客户、买家痛点、付费意愿和现有支出。
• 市场时机、分销、平台限制和技术可行性。
• 定价、商业模式、风险和可信的替代方案。

将陈述标明为证据、推断或假设。不要把“没有找到直接竞争对手”误当成“这是个好想法”。

完成标准： 最重要的陈述都有来源，或明确标注为尚未证实。

3. 找到切入点

将宏大的目标转化为范围明确的第一步。

• 相比宽泛的品类主张，优先明确具体买家、问题和结果。
• 确定哪些方面具有差异化，哪些属于常规能力，以及哪些难以复制。
• 直接指出薄弱假设。
• 优先采用小规模、快速、低成本的验证方式，而不是复杂的计划。

完成标准： 当前论点明确说明目标用户是谁、首先要做什么，以及第一步为何可行。

4. 给出 Shrimp Verdict

只要证据足以支持判断，就坦诚地给出结论。随着新证据出现，结论可以修订。

• **Shrimp-Yes：**推进当前切入点。说明原因，并指出下一项测试。
• **Shrimp-Maybe：**前景不错，但取决于某个尚未解答的具体问题或验证步骤。
• **Shrimp-No：**按目前的设想，不值得推进。说明原因，只有在存在可信的替代方向时才提出转向建议。

避免虚假的精确性。结论是辅助决策的工具，而非保证。

**完成标准：**用户能够理解建议、相关证据，以及哪些因素可能改变结论。

5. 维护持续更新的记录

对于不止是快速回复的探索，应维护一个轻量的创意文件夹：

idea-name/
├── concept-brief.md       # Current source of truth
├── research-ledger.md     # Findings, sources, confidence, implications
├── brainstorm.md          # Optional raw transcript, preserved unchanged
└── final-spec.md          # Complete clarified handoff, created on request

经过实质性研究、约束条件、方向调整或决策后，更新概念简报和研究记录。

不要悄悄删除被否决的假设。将其移至 Rejected paths，并说明调整原因。

如果用户提供了名为 brainstorm.md 的转录稿，请原样保留。如果没有完整转录稿，请创建明确标注的摘要，而不是捏造内容。

**完成标准：**无需重读整个聊天记录，也能还原当前论点、决策边界和推理过程。

6. 创建最终交接文档

只有在用户要求最终交接文档，或明确表示方向已足够确定、可以记录时，才创建 final-spec.md。

final-spec.md 不应只是最终创意的快照，而应是一份自包含、易于阅读的探索记录。即使读者从未看过对话，也应能理解最初的想法、发生了哪些变化、变化原因、哪些方向被否决，以及接下来该做什么。

使用 templates/final-spec.md 中的模板。

**完成标准：**交接文档包含决策历程、证据、尚存的不确定性，以及明确的下一步或实施计划。

常见误区

1. **盘问用户，而不是提供帮助。**主动研究并提供有用的信息。只有真正阻碍下一项有效行动的问题，才需要询问。
2. **过早确定结论。**在证据消除疑问之前，明确保留各项假设。
3. **竞争对手研究过于笼统。**将竞争对手归类为直接竞争者、相邻产品、替代方案、灵感来源或无关选项，并说明其影响。
4. **过早扩大范围。**如果狭窄的切入点或人工测试就能验证核心主张，就不要设计完整平台。
5. **忽略探索历程。**最终交接文档必须说明得出结论的过程，而不能只呈现润色后的最终结果。
6. **将缺乏竞争对手视为验证。**检查客户痛点、现有支出、替代方案、分发渠道，以及用户改变行为的意愿。

验证清单

结束头脑风暴或交付最终交接文档前，请确认：

• 当前论点明确指出用户、问题和合理的首个切入点。
• 重要事实陈述均有来源，或已标注为假设。
• 在相关情况下，已考虑直接竞争者、替代方案和相邻选项。
• 被否决的方向及决策理由均已保留。
• Shrimp Verdict 坦诚明确，并包含下一项测试或停止推进的理由。
• 如果用户要求提供最终规格文档，即使读者无法查看原始对话，也能理解其内容。