昨天最後，我替自己留下了一個問題：
ClarifyBuild 的第一版，到底要做到哪裡？
Clarification Flow 可以幫我找出還沒決定的事情，但需求越問越清楚之後，另一個問題也跟著出現。
如果每一個合理的需求最後都被放進第一版，ClarifyBuild 很快就會從一個需求釐清工具，長成另一個做不完的 Side Project。
所以今天我要做的事情，和昨天最後預告的一樣：
替 ClarifyBuild 畫出第一版的範圍：MVP 與 Scope。
但真正開始列功能之後，我才發現，Vibe Coding 有一個很容易讓人失控的地方。
AI 太容易說「可以做」。
以前自己寫程式時，新增一個功能通常意味著：
我要先想自己會不會做。
但 Vibe Coding 很容易出現另一種心態：
反正 AI 可以寫，那就順便加一下好了。
例如昨天文章裡的「活動報名網站」。
一開始可能只是：
我想做一個活動報名網站。
Clarify 之後，我可能知道：
這時其實已經可以形成一條最基本的流程。
但接下來很容易開始出現：
既然可以報名，
那要不要順便做會員登入？
有會員了，
那是不是可以做個人 Dashboard？
主辦方也需要管理吧？
那再做一個 Admin 後台。
活動現場可能要報到，
那就再做 QR Code。
是不是也應該寄 Email？
之後如果要收費，
付款功能也可以先做。
對了，
再加個 Dark Mode 好像也不錯。
每一個需求單獨看，好像都很合理。
而且現在只要跟 AI 說一句：
幫我加上這個功能。
它真的有可能很快就開始做。
問題是，一個 Side Project 也可能因此從：
活動報名網站
慢慢變成：
會員系統
+
活動管理平台
+
Email 系統
+
QR Code 報到
+
付款
+
Analytics
+
Admin Dashboard
+
Dark Mode
最後已經不是原本的第一版了。
這也是我今天才更清楚區分的一件事。
昨天 Clarification Flow 在做的是：
找出哪些重要事情還沒有決定。
但是當這些事情逐漸被釐清之後，還需要再做另一層判斷：
這個需求要不要放進目前這一版？
也就是說：
Clarification
↓
知道有哪些需求與決定
Scope
↓
決定哪些屬於這一版
這兩件事不能混在一起。
因為：
需求被釐清之後，還需要再判斷它是不是屬於這一版。
例如，我可能已經確認：
未來使用者確實可能需要會員登入。
但如果目前的核心目標只是驗證：
使用者能不能完成活動瀏覽 → 填寫資料 → 報名成功
那登入系統仍然可以先不進第一版。
這個需求確實存在。
只是它不一定屬於現在的 Scope。
MVP 常常會讓我直覺想到：
功能越少越好。
但我現在比較想用另一種方式理解它。
對 ClarifyBuild 這個專案而言，我目前把 MVP 當成：
能夠完整跑通核心價值，並且讓我開始驗證這個想法的最小版本。
我現在更在意的是：功能精簡之後，核心流程還能不能成立？
如果把一個功能拿掉之後，使用者仍然可以完成產品最重要的目標，那它就未必需要現在做。
但如果拿掉它之後，整個核心流程直接斷掉，那它就很可能是 Must Have。
這裡我覺得有一個很容易混淆的地方。
覺得這功能很酷、覺得之後應該會用到、或是「既然 AI 做得出來，就一起做」——這些都還不是 Must Have 的判斷標準。
我現在會先問：
沒有這個功能，使用者還能不能完成產品的核心目標？
例如活動報名網站。
如果核心目標是：
讓使用者完成活動報名。
那麼：
查看活動
→
輸入報名資料
→
送出
→
確認成功
很可能就是 Must Have。
但是：
Dark Mode
會員頭像
報名紀錄圖表
推薦活動
社群分享
即使它們可能都有價值，也不代表第一版一定需要。
既然 ClarifyBuild 想幫別人管理 Scope，那我覺得第一個應該被管理的，就是 ClarifyBuild 自己。
目前它的核心價值仍然是：
Turn vague ideas into build-ready specs.
也就是把一個模糊 Idea：
Idea
↓
Clarify
↓
Scope
↓
Specification
↓
Prompt
↓
Export
完整跑通。
因此我先把目前想到的功能重新分類。
第一版一定要能做到：
如果拿掉其中太多東西，ClarifyBuild 就無法完成：
Vague Idea
→
Build-ready Spec
這個最核心的轉換。
這些東西能讓體驗更好，但即使第一版比較簡單，核心價值仍然可以成立。
例如：
這些不是沒有價值。
只是目前不應該比 Clarification 本身更重要。
有些功能我確實想過，而且未來可能很有價值，例如：
但是如果現在就開始做，我可能會把大量時間花在 Backend、帳號、資料庫與架構上。
反而還沒有驗證：
Clarification Flow 本身到底有沒有用。
所以先放到 Future。
還有一些功能，我會直接在第一版標成：
現在不做。
例如：
這個分類對我來說很重要。
因為「沒有寫進 Todo」和「明確寫成 Out of Scope」其實是不一樣的。
前者可能只是忘了。
後者才是一個真正的產品決定。
這是我今天另一個很重要的發現。
以前講 Requirement，我很容易只想到：
系統要做什麼。
但對 AI Coding 來說，「不要做什麼」可能同樣重要。
假設我只告訴 AI：
做一個活動報名網站。
它可能會根據自己熟悉的產品模式，開始補：
登入、會員、管理後台、資料庫……
這些東西不一定錯。
甚至可能很合理。
問題只是：
我沒有要它現在做。
因此一份 Specification 如果只有：
Features
可能還不夠。
它還需要：
Out of Scope
讓 AI 知道：
哪些東西現在不要碰。
寫到這裡，我發現 Scope 還有另一個作用。
Scope 同時也在告訴 AI：
你的工作範圍到哪裡為止。
例如：
In Scope:
活動列表
活動詳細頁
報名表單
成功頁面
Out of Scope:
登入
付款
Admin Dashboard
QR Code 報到
這時 AI 面對的就不再只是：
幫我做活動報名網站。
而是一個範圍更清楚的任務。
不過這裡還有另一個問題。
即使一個功能已經確定 In Scope，AI 在實作這個功能時，到底又可以自己決定多少？
例如：
「要不要做登入」是 Scope。
但如果已經決定要做某個表單：
按鈕放左邊還是右邊，AI 可以自己決定嗎？
資料要永久保存還是重新整理後消失，AI 可以自己決定嗎？
這個問題已經超出了 Scope 處理的範圍，我目前把它稱為：
AI Decision Boundary。
簡單來說：
Scope
＝
這一版做不做
Decision Boundary
＝
決定要做之後，AI 可以自己決定多少
Acceptance Criteria
＝
最後怎樣才算做對
這三件事情看起來很接近，但其實解決的是不同問題。
後面我會再把這條 Decision Boundary 拆開來處理。
昨天的 Clarification Flow 比較像是在展開。
從一句模糊 Idea 裡面，不斷找到：
Unknown
↓
Question
↓
Decision
↓
Requirement
但如果只有展開，需求只會越來越多。
所以今天補上的 Scope，負責的是另一個方向：
Clarification
＝
把需要想清楚的東西展開
Scope
＝
把現在真正要做的東西收回來
這樣 ClarifyBuild 才不會變成：
幫使用者把所有可能想到的功能全部整理出來。
而應該是：
幫使用者想清楚之後，再決定第一版真正需要什麼。
今天我沒有開始寫更多功能。
反而先刪掉很多「看起來可以做」的東西。
但我覺得這可能正是 Vibe Coding 很重要的一個能力。
因為當 Coding 的成本下降之後，最大的誘惑可能不再是：
這個功能太難，我做不出來。
而變成：
這個 AI 好像做得出來，那就全部做吧。
可是：
能做，不代表現在應該做。
所以今天 ClarifyBuild 的流程又更完整了一點：
Idea
↓
Clarify
↓
Requirement
↓
Scope
↓
Specification
↓
Build
昨天，我在想：
怎麼知道還有哪些事情沒有問清楚？
今天，我多問了一個問題：
就算都問清楚了，哪些事情真的應該進第一版？
下一步，我要繼續把留下來的 Requirement 往「AI 真正可以執行的規格」推進。
因為把功能放進 MVP，仍然不代表 AI 已經知道：
這個功能到底要怎麼運作？
Day 6 完成。
明天見。
iThome鐵人賽
看影片追技術