點子到開發計畫｜發散 × 收斂 × MVP 規格

把一個粗略的想法一路帶到「可以動手做」的開發計畫：先發散出多個方向、再用評分收斂挑出最值得做的、 最後產出可執行的 MVP / 原型開發規格。通用不限領域（軟體 App、產品、服務、內容、活動皆可）。 只要使用者丟出一個點子、靈感、想做的東西，或說「我想做…」「有什麼好點子」「這個想法怎麼落地」 「幫我把這個點子變成可以開發的東西」「幫我規劃 MVP」，就使用這個 skill，即使他沒明講要「開發規格」。 不要只回一段感想——帶他走完發散→收斂→開發計畫這條龍。

Idea to Build（點子 → 開發一條龍）
這個 skill 在做什麼

使用者常常只有一個模糊的想法（「我想做一個幫人記帳的 App」「想辦一個社群活動」）， 然後就卡住——不知道該往哪個方向走、也不知道怎麼開始做。這個 skill 的工作，是把那個 粗略的想法，用一條清楚的路徑帶到「明天就能動手」的狀態：

釐清 Frame — 把想法講清楚，鎖定領域、對象、要解決的核心問題。
發散 Diverge — 從多個角度長出一批方向與變體，不要太早收斂。
收斂 Converge — 用簡單的評分把方向排序，挑出最值得做的 1–2 個並說明理由。
開發計畫 Build Plan — 把選中的方向變成可執行的 MVP / 原型開發規格。

核心精神：發散要夠寬，收斂要有依據，落地要能動手。不要停在「這是個好點子」， 要一路做到「這是怎麼做出來的第一步」。

開場：先判斷資訊夠不夠

拿到想法後，先用一句話把它重述出來，確認你理解對了。然後看缺不缺關鍵資訊：

領域 / 型態：是軟體、實體產品、服務、內容、活動……？（決定「開發計畫」長什麼樣）
對象：主要使用者 / 受眾是誰？
目的與限制：想達成什麼？有沒有預算、時間、能力上的硬限制？

如果這些從對話裡已能合理推斷，就直接往下做，把假設寫清楚讓使用者修正即可—— 不要為了問而問。只有在資訊真的不足、問了才不會做錯方向時，才最多問 1–2 個關鍵問題。 使用者要的是進度，不是問卷。

階段一：發散 Diverge

目標是攤開可能性，讓使用者看到「原來可以這樣想」。產出 6–10 個方向， 刻意用不同的鏡頭去長，避免全部長得一樣：

不同對象：換一種使用者 / 受眾，需求就不同。
不同機制：達成同一個目的的不同做法（自動化 vs 人工、平台 vs 工具、訂閱 vs 一次性…）。
不同價值角度：省時間、省錢、更好玩、更有面子、降低風險……主打點不同。
不同規模：極簡版（一個週末做得完）到理想版（完整願景）。
1–2 個大膽變體：故意跳出框架的 wildcard，就算最後不選也能刺激思考。

每個方向用一兩句講清楚「給誰、解決什麼、怎麼運作、有何不同」，不要只給一個名字。

階段二：收斂 Converge

把上面的方向放進一個簡單的評分表，讓「選哪個」有依據而不是憑感覺。 用 1–5 分（5 最好）評這四個維度，可依情境微調權重：

維度 問的是
需求強度 使用者真的痛 / 想要嗎？有多急？
影響力 做成了，價值 / 回報有多大？
可行性 以現有資源、時間、能力做得出來嗎？
差異化 和現有選項比，有沒有明顯的不一樣？

用表格列出每個方向的分數與總分，然後挑出 1–2 個最值得做的，並用幾句話說明 為什麼是它們（不要只給分數，要給判斷）。同時點出這個選擇最大的風險或假設是什麼—— 這會直接餵給下一階段的驗證實驗。

如果使用者已經心裡有數想做哪個，尊重他的選擇，但仍快速用這個框架幫他壓力測試一下。

階段三：開發計畫 Build Plan

把選中的方向，變成一份可以照著動手的開發計畫。這是整個 skill 的重點交付物。 依領域調整深淺，但盡量涵蓋以下骨架：

一句話定位 — 「為了［對象］，做一個［東西］，讓他們能夠［結果］。」
問題與對象 — 核心要解決的問題、目標使用者、他們現在怎麼將就（現有替代方案）。
MVP 範圍 — 明確切出「這次一定要做的（must-have）」與「先不做、之後再說（later）」。 MVP 的原則是：用最小的東西驗證最關鍵的假設，能砍就砍。
核心功能 / 使用流程 — 使用者從頭到尾會經歷的主要步驟或功能，列重點即可。
實作方向 — 依領域給具體建議：
軟體：建議的技術路線 / 工具、大致架構、資料怎麼存、有沒有現成套件或服務可省力。
非軟體：怎麼做出第一個版本（手作、外包、既有平台）、需要的資源與人。
最小驗證實驗 — 針對階段二點出的最大假設，設計一個最便宜、最快能驗證的實驗 （落地頁測需求、找 5 個人訪談、手動跑一次流程…）。目的是花最少成本知道值不值得繼續。
里程碑與時程 — 切成幾個看得到的階段，給粗略時間感（第 1 週 / 第 1 個月…）。
成功指標 — 怎麼判斷這步成功了？給 1–3 個具體、可觀察的指標。
輸出格式

預設用結構清楚的 Markdown，依上面三個階段分段呈現：發散清單 → 收斂評分表 → 開發計畫。標題分明、重點好掃讀。

篇幅隨請求調整：使用者只想「聊聊點子」時可以輕量一點、把重心放在發散與收斂； 說「幫我規劃到能開發」時，就把開發計畫這段寫紮實。

若使用者想要一份可帶走的文件（PRD、企劃、規格書），再考慮輸出成 .md / .docx 檔。 一般對話情境下，直接在回覆裡呈現即可。

心法
不要跳過發散直接給答案。 第一個想到的方向通常不是最好的；先攤開再收斂，價值就在這。
收斂要敢做判斷。 評分是輔助思考，不是逃避決定；一定要明確推薦。
落地要能動手。 開發計畫若使用者看完還是不知道明天做什麼，就是還不夠具體。
依領域伸縮。 軟體、活動、內容、實體產品的「開發」長得不一樣，別硬套軟體術語。