昨天 Day 9 的最後，我留下了一個問題：

ClarifyBuild 到底怎麼知道「現在還缺什麼」，以及下一題應該問什麼？

Day 9 我把 ClarifyBuild 的 Usage Flow 畫得更完整，確認了 Landing、Builder、Spec Preview、Prompt Preview 之間怎麼移動，也補上 Builder 裡 Idea Entry、Clarification、Scope Review 之間的規則。

其中 Clarification 的流程大致是：

Identify Unknowns
↓
Find Relevant Clarification Dimension
↓
Ask Question
↓
User Decision
↓
Update Requirement
↓
Check Unknowns Again

流程看起來有了。

但仔細一看，其實最重要的地方還是一個黑盒子：

Identify Unknowns

到底怎麼 Identify？

下一題又是根據什麼決定？

如果這兩件事情沒有定義，ClarifyBuild 還是只有一張「看起來合理」的 Usage Flow，真正開發時仍然不知道 Clarification 要怎麼運作。

所以 Day 10，我沒有開始畫 Wireframe，也沒有開始寫 JavaScript。

今天先處理這個黑盒子。

從「有哪些題目？」改成「現在缺什麼？」

一開始在設計 Requirement Wizard 時，我很容易直覺想到：

Step 1：Problem
Step 2：Target User
Step 3：Goal
Step 4：Platform
Step 5：Core Function
...

這樣最好做。

每一題固定、順序固定，甚至進度條都很好算：

Question 3 / 8

可是從 Day 5 開始，我已經把 Clarification 改成 Dynamic Flow。

因為使用者一開始輸入的 Idea 不一樣，已經知道的資訊也不一樣。

例如：

我想做一個讓研究生整理論文的網站。

這句話裡至少已經出現兩個線索：

• 可能的 Target User：研究生
• 可能的 Platform：Web

如果系統接下來還固定問：

誰會使用這個產品？

你要做 Web、Mobile 還是 Desktop？

使用者很可能會想：

我剛剛不是已經說了嗎？

所以 ClarifyBuild 的核心不能只是：

準備 8 題
↓
從第一題問到第八題

而要變成：

看看現在知道什麼
↓
看看還缺什麼
↓
只問下一個真正需要回答的問題

問題是，這個「知道」到底怎麼定義？

系統推測得到的東西，能直接算數嗎？

這是今天我覺得最重要的一個原則：

Inference ≠ Resolved

假設使用者輸入：

我想做一個活動網站。

系統看到「網站」兩個字，可以合理推測：

Platform Candidate = Web

但這不代表 ClarifyBuild 可以直接偷偷寫進 Requirement：

Platform = Web

因為那只是系統的推測，使用者還沒有真正決定。

所以我把 Requirement 每個面向的狀態（例如 Problem、Target User、Platform，我稱它們為 Clarification Dimension）先收斂成三種：

前面的例子就會變成：

Idea：
我想做一個活動網站。

↓

Platform Candidate = Web
State = Needs Confirmation

接著 ClarifyBuild 顯示：

我理解第一版會以 Web 為主。

[沒錯] [修改]

只有使用者按下「沒錯」，它才會真正變成：

Platform = Web
State = Resolved

這個差別看起來很小，但其實跟 ClarifyBuild 一直想處理的問題很接近。

如果今天連 ClarifyBuild 自己都看到幾個字就直接幫使用者把需求補完，那最後只是：

使用者講一點
↓
AI 猜很多
↓
產生 Specification

跟原本 Vibe Coding 容易遇到的問題沒有差多少。

前幾天說的 Unknown，和今天的 Unknown State 不是同一層

做到這裡，我又發現另一個問題。

前幾天文章裡講的 Unknown，原本是：

如果現在直接開始 Build，有哪些地方 AI 必須自己猜？

例如一個活動報名功能可能還有：

額滿之後可以候補嗎？
取消之後名額會重新開放嗎？
第 51 個報名的人會看到什麼？

但今天做 Clarification Engine 時，我又會寫：

Target User = Unknown
Goal = Unknown
Platform = Unknown

這兩種 Unknown 其實不是完全同一層。

所以我最後把它拆開：

Clarification Dimension

就是前面說的 Requirement 分類面向，每個都有前面那三種 State，一共八個：

Problem
Target User
Goal
Usage Scenario
Platform
Core Function
Design Preference
Decision Boundary

Unknown Item

則是某個還需要做 Decision 的具體未決事項，例如前面那個活動報名功能的「額滿之後可以候補嗎？」。

這個區分也讓我比較清楚 ClarifyBuild v0.1 到底要做到哪裡。

第一版先把重點放在：

產品層級的 Clarification。

至於每個 Feature 背後所有細節，v0.1 不會假裝自己全部都能自動找出來。

像前面活動報名的額滿、取消規則，這些 Unknown 真實存在。

只是目前的 Rule-based Engine 不一定能辨識。

也就是：

實際存在的 Unknown
≠
v0.1 Engine 能辨識的 Unknown

這個限制我覺得應該直接寫清楚，不要為了讓產品看起來更聰明，偷偷假設第一版什麼都能理解。

那下一題到底怎麼決定？

有了 State 之後，下一步就是 Priority：同時有很多東西不知道時，先處理哪一個？

Day 9 那條流程裡的 Identify Unknowns，今天拆開之後長這樣：

Inspect Current State
↓
Find Important Unknown
↓
Choose Next Clarification Goal
↓
Ask
↓
User Decision
↓
Update Requirement
↓
Evaluate Again

對照 Day 9：Identify Unknowns 拆成前兩步，Find Relevant Clarification Dimension 變成 Choose Next Clarification Goal，Check Unknowns Again 變成 Evaluate Again。

每回答一次，Engine 都會重新走一遍。

哪些一定要回答？

八個 Dimension 的重要程度不一樣，我先分成兩類。

Blocking Dimension：沒有解決，就不能進 Scope Review。

Target User
Problem
Goal
Platform
Core Function
Decision Boundary

其中 Decision Boundary 就是 Day 6 提過的那個概念：決定要做之後，AI 可以自己決定多少。今天它正式放進 Clarification，成為進 Scope Review 前一定要回答的項目；怎麼問，這篇先不展開。

Non-blocking Dimension：第一版可以先不回答。

Usage Scenario
Design Preference

先處理哪一個？

如果先只看 Blocking Dimension，目前的優先順序很簡單：

Needs Confirmation
↓
Unknown

系統已經猜到、只差使用者回應的先處理，因為回應一個猜好的答案，比從零回答一題輕鬆。完全沒有答案的，再一題一題問。

Scope 調整後冒出來的新問題，還有選填的 Optional Details，也在這套順序裡，後面會遇到。

同時有很多個都不知道時

如果同時有多個 Blocking Dimension 都是 Unknown，再使用一組預設順序：

Target User
↓
Problem
↓
Goal
↓
Platform
↓
Core Function
↓
Decision Boundary

例如 Problem 的問題文字會引用 Target User 的答案（「這些研究生目前在整理論文時…」），所以 Target User 排在前面。

這組順序只是「現在同時有很多東西不知道時，先處理什麼」。已經 Resolved 的項目會直接跳過。

同一個 Engine，Idea 不同，問題也會不同

例如：

我想做一個讓研究生整理論文的網站。

第一版很保守，只做少量 Pattern Detection。

這句可以先找到：

Target User Candidate = 研究生
Platform Candidate = Web

所以第一個畫面可以先確認：

確認我對 Idea 的理解

主要使用者：研究生    [沒錯] [修改]
第一版平台：Web       [沒錯] [修改]

兩個都確認後，Target User 和 Platform 已經 Resolved。

接下來才可能走：

Problem
↓
Goal
↓
Core Function
↓
Decision Boundary

但換一個 Idea：

我想做一個 Web App，
從附近餐廳中快速選一家，
解決每天不知道吃什麼的問題。

目前規則只能明確抓到：

Platform Candidate = Web

Target User 還是 Unknown。

所以流程可能變成：

確認 Platform
↓
Target User
↓
Problem
↓
Goal
↓
Core Function
↓
Decision Boundary

同樣一套 Engine，兩個 Idea 的實際問題數量已經不一樣。

這就是我目前所說的 Dynamic Clarification：

下一題由目前的 Requirement State 決定，跟現在是第幾題沒有關係。

它不需要 AI 每次即時生成很聰明的問題。

到底什麼時候才能離開 Clarification？

這也是 Day 9 留下來的一個問題。

因為 Dynamic Flow 沒有固定題數，所以不能用：

Question 8 / 8

來判斷完成。

Day 9 只先確定：結束條件來自 Requirement 的狀態。今天補上具體的規則：

目前已不存在 ClarifyBuild v0.1 能識別、而且會阻礙 Scope Review 的重要 Unknown。

具體來說，至少這六個 Blocking Dimension 要全部 Resolved：

Target User
Problem
Goal
Platform
Core Function
Decision Boundary

其中 Core Function 這一題問的是：

你目前想到哪些核心功能？先列出來，下一步再決定哪些要放進第一版。

使用者列出來的功能會成為 Scope Review 的候選（Core Function List → Scope candidates → Scope Review），哪些放進第一版，到下一步才決定。

至於：

Usage Scenario
Design Preference

會在第一次進入 Scope Review 前提供一個 Optional Details 畫面。

使用者可以填，也可以先跳過。

也就是：

Blocking Dimension 全部 Resolved
↓
Optional Details
↓
Scope Review

Scope 改了，Clarification 也可能重新打開

Dynamic Flow 也不是只發生在第一次 Wizard。

Day 9 提過，Scope 調整之後可能又冒出新的重要 Unknown。今天把這個前提說清楚。

假設使用者第一次整理出來的 Scope 是：

Must Have：
收藏論文
分類論文
搜尋論文

Future：
登入

使用者第一次按下 Confirm Requirement 之前，這都還只是在整理第一版的 Scope。按下之後，這份 Scope 才成為 baseline，之後的調整才算 Scope Change。

之後在 Spec Preview 發現：

不行，登入第一版就需要。

使用者按下 Edit Requirement，回到 Scope Review：

登入
Future → Must Have

這時 ClarifyBuild 就可能重新產生一個重要 Unknown：

你剛剛把「登入」加入第一版。

第一版最低需要讓使用者完成什麼？

例如使用者回答：

使用者可以建立帳號並登入，
登入後才能保存自己的論文收藏。

Clarification 解決後，再回 Scope Review。

流程會變成：

Scope Review
↓
Scope Change
↓
新的重要 Unknown
↓
Clarification
↓
Decision
↓
Scope Review

Target User、Problem、Goal 這些已經 Resolved 的項目，不需要全部再問一次。

Requirement 改變之後，Clarification 只針對變動的地方局部重新開啟。

那為什麼第一版不用 AI API？

做到這裡，其實很容易出現另一個誘惑：

既然要理解 Idea、找 Unknown、決定下一題，那乾脆全部交給 LLM 不就好了？

這也是我前幾天一直沒有急著決定的地方。

Day 10 最後的答案仍然是：

第一版先不要。

目前先用：

Rule-based State Logic
+
Small Candidate Pattern Set
+
Explicit User Decision

例如：

• 「網站」可以建立 Platform = Web 的 Candidate
• 「手機 App」可以建立 Platform = Mobile 的 Candidate
• 某些非常明確的「給 X 使用」「讓 X …」可以建立 Target User Candidate

但它們都只能到：

Needs Confirmation

不能偷偷變成：

Resolved

我寧可第一版偶爾多問一次，也不希望 ClarifyBuild 為了看起來聰明，又開始替使用者猜 Requirement。

什麼時候才會改變主意？

我沒有把 AI 完全排除，先定好的是：什麼情況下才需要它。

如果之後真的發現：

• 使用者明明寫過，Wizard 卻一直重問
• Candidate 常常猜錯
• 規則越寫越多
• Spec 產生後還是一直需要回去改
• Claude Code 拿到 Spec 後還是問一堆需求問題

那時候再評估：

AI-assisted Idea Analysis
AI-assisted Dimension Extraction
AI-assisted Unknown Detection

會比第一天就把整個產品綁在 AI API 上更合理。

v0.1 刻意不做什麼？

今天把規則寫完整之後，我反而更確定第一版有哪些事情不要做。

• 不完整解析所有自由文字 Idea
• 不理解後續回答裡所有跨 Dimension 的語意
• 不自動找出每個 Feature 背後所有 Unknown
• 不建立一大套 Feature-specific Rule Library
• 不用字數判斷 Requirement 寫得好不好
• 不把 Wizard 做成自由聊天式 AI Chatbot

這不代表它們永遠不需要。只是目前沒有證據顯示，缺少這些東西，ClarifyBuild 就無法提供價值。

Day 10 小結

今天沒有寫任何正式 UI，也沒有開始做 Wizard 的 JavaScript。

但 Clarification 這個黑盒子，現在有了一套可以往程式邏輯轉換的規則：

系統推測到的內容，要使用者回應之後才算數
下一題由目前的 Requirement State 決定
完成條件看目前 Engine 能辨識出的重要 Unknown，而不是固定題數
第一版先用規則，不接 AI API

明天：這些 Requirement 最後要怎麼變成一份 Spec？

今天解決的是：

ClarifyBuild 怎麼知道現在還缺什麼，以及下一題該問什麼？

但新的問題也很快出現了。

現在手上會有：

Problem
Target User
Goal
Platform
Core Function
Decision Boundary
Scope
...

這些 Input 最後要整理成一份 Build-ready Project Specification，哪些資料要保存？哪些只是 Wizard 過程中的 State？

而且目前的 Project Specification 裡還有：

Constraints
Tech Stack

但前面的 Clarification Flow 甚至還沒有明確定義它們從哪裡來。

所以 Day 11，我會開始處理：

Input → Requirement → Spec Field Mapping

也就是正式定義 ClarifyBuild 的 Project Spec Schema。

Day 10 完成。

明天見。