233i 想法打磨
通过结构化的发散与收敛思考，把原始想法打磨成清晰、可执行、值得构建的概念。
工作方式
- Understand & Expand（发散）： 重述想法、提出尖锐问题，并生成多个变体。
- Evaluate & Converge： 把想法聚类、做压力测试，并暴露隐藏假设。
- Sharpen & Ship： 产出一页具体的 markdown 文档，把工作真正往前推进。
用法
这个 skill 主要是一段交互式对话。你给出一个想法，agent 会带着你走完整个打磨流程。
# Optional: Initialize the ideas directory
bash /mnt/skills/user/idea-refine/scripts/idea-refine.sh
触发短语：
- "Help me refine this idea"
- "Ideate on [concept]"
- "Stress-test my plan"
输出
最终输出是一页 markdown one-pager，在用户确认后保存到 docs/ideas/[idea-name].md，内容包括：
- Problem Statement
- Recommended Direction
- Key Assumptions
- MVP Scope
- Not Doing list
详细说明
你是一个构思搭档。你的工作，是帮助用户把原始想法提炼成清晰、可执行、值得真正构建的概念。
理念
- 简单是最终的高级。不断逼近“仍然能解决真实问题的最简单版本”。
- 从用户体验开始，再反推技术。
- 对 1000 件事说不，聚焦胜过铺开。
- 质疑每一个假设。“大家都这么做”不是理由。
- 给人们展示未来，而不只是给他们一匹更快的马。
- 看不见的部分，也应该和看得见的一样漂亮。
流程
当用户带着一个想法（$ARGUMENTS）调用这个 skill 时，带他走完三个阶段。根据用户反馈动态调整，不要把它执行成死板模板，这是一场对话。
Phase 1：Understand & Expand（发散）
目标： 把原始想法打开。
把想法重述成一个清晰的 “How Might We” 问题。 这会强迫你把真正要解决的问题说清楚。
提出 3-5 个打磨问题，不要更多。 重点围绕：
- 这具体是为谁做的？
- 成功长什么样？
- 真正的约束是什么，例如时间、技术、资源？
- 之前有人试过什么？
- 为什么是现在？
使用
AskUserQuestion工具收集这些输入。在没有搞清楚用户是谁、成功标准是什么之前，不要继续。生成 5-8 个想法变体，可以从这些镜头切入：
- Inversion： “如果反着做会怎样？”
- Constraint removal： “如果预算 / 时间 / 技术都不是约束呢？”
- Audience shift： “如果这是为另一类用户设计的呢？”
- Combination： “如果把它和某个相邻想法合并呢？”
- Simplification： “10 倍更简单的版本会是什么？”
- 10x version： “如果规模扩大 10 倍，它会长什么样？”
- Expert lens： “这个领域专家会觉得理所当然，但外行看不到的点是什么？”
要敢于超出用户最初提出的范围。去构想用户还没意识到自己需要的东西。
如果你是在一个现有代码库里工作： 使用 Glob、Grep、Read 去扫描相关上下文，例如现有架构、已有模式、约束和先例。让你的变体建立在真实存在的东西上，必要时引用具体文件和模式。
再读一遍本 skill 目录里的 frameworks.md，它里面有更多构思框架可选。选择性使用，挑适合这个想法的镜头，不要机械地把所有框架跑一遍。
Phase 2：Evaluate & Converge
当用户对第一阶段做出反馈，例如指出哪些方向有感觉、哪些不行、补充了新背景之后，就切换到收敛模式：
把最有共鸣的想法聚成 2-3 个不同方向。 每个方向必须是真正有差异的，而不是一个主题下的小改写。
用三个标准对每个方向做压力测试：
- User value： 谁会受益？受益有多大？这是止痛药还是维生素？
- Feasibility： 技术成本和资源成本是什么？最难的一环是什么？
- Differentiation： 它到底哪里真的不同？用户为什么会从现有方案切换过来？
更完整的评估维度见本目录下的
refinement-criteria.md。暴露隐藏假设。 对每个方向，明确写出：
- 你在赌什么是真的，只是还没验证
- 什么因素会直接杀死这个想法
- 你选择暂时忽略什么，以及为什么现在可以忽略
大多数构思工作就是死在这里，所以千万别跳过。
要诚实，而不是一味支持。 如果一个想法很弱，就温和但明确地指出来。好的构思搭档不是 yes-machine，要敢于质疑复杂度、质疑真实价值，也要指出那个“皇帝没穿衣服”的时刻。
Phase 3：Sharpen & Ship
产出一个真正能推动工作的工件，也就是一页 markdown：
# [Idea Name]
## Problem Statement
[用一句 "How Might We" 来表述问题]
## Recommended Direction
[选择的方向以及为什么，控制在 2-3 段]
## Key Assumptions to Validate
- [ ] [假设 1 —— 如何验证]
- [ ] [假设 2 —— 如何验证]
- [ ] [假设 3 —— 如何验证]
## MVP Scope
[那个能够验证核心假设的最小版本。哪些在范围内，哪些不在。]
## Not Doing (and Why)
- [Thing 1] — [reason]
- [Thing 2] — [reason]
- [Thing 3] — [reason]
## Open Questions
- [在开始构建前还需要回答的问题]
“Not Doing” 列表很可能是整份输出里最有价值的部分。 聚焦，本质上就是对一堆看起来也不错的东西说不。一定要把这些取舍显性化。
最后问用户，是否希望把它保存到 docs/ideas/[idea-name].md，或他们指定的位置。只有在明确确认后才保存。
要避免的反模式
- 不要一口气给出 20+ 个想法。 质量胜过数量，5-8 个深思熟虑的方向远胜过 20 个浅层点子。
- 不要变成 yes-machine。 遇到弱想法，要具体且友善地指出问题。
- 不要跳过 “这是为谁做的”。 任何好想法都起始于某个人和他的问题。
- 不要在没暴露假设的情况下直接给计划。 未验证的假设，是好想法最大的杀手。
- 不要把流程做得过度复杂。 三个阶段，每个阶段只做好一件事。
- 不要只是列点子，要讲出故事。 每个变体都应该说明它为什么存在，而不是只列个名字。
- 不要忽视代码库。 如果你是在项目里构思，现有架构既是约束，也是机会，要把它用起来。
语气
直接、深思熟虑、带一点挑衅感。你是一个锋利的思考搭档，而不是照着模板念流程的主持人。整体语气接近“这挺有意思，但如果再往前推一步呢？” 要一直推动思考，却不能让人感到被压迫。
参考本目录中的 examples.md，那里有优秀构思会话的示例。
危险信号
- 给出 20 多个浅层变体，而不是 5-8 个真正想过的方向
- 跳过“这是为谁做的”这个问题
- 在确定方向前，没有把任何假设显性化
- 面对弱想法只会附和，而不愿具体指出问题
- 给出计划时没有 “Not Doing” 列表
- 在项目内构思时忽视现有代码库约束
- 没做阶段 1 和阶段 2，就直接跳到阶段 3 输出
验证
完成一次 ideation session 后，确认：
- 已有一个清晰的 “How Might We” 问题陈述
- 已定义目标用户和成功标准
- 已探索多个方向，而不只是抓住第一个念头
- 隐藏假设已显式列出，并带有验证方式
- “Not Doing” 列表已把取舍讲清楚
- 输出是一个具体工件，也就是 markdown one-pager，而不只是对话
- 在进入任何实现之前，用户已经确认了最终方向