上一篇整理完 User Flow 後，我原本預計今天接著談 User Story：

誰需要這個功能？為什麼？

但在準備往下做 ClarifyBuild 時，我回頭看了一次昨天畫出的 ClarifyBuild Usage Flow，發現有一個更直接影響開發的問題還沒處理完。

昨天的流程已經可以回答：

使用者大致會怎麼走完 ClarifyBuild？

可是如果現在要直接拿這張圖去畫 Builder，很多互動細節還是只能靠我或 AI 自己猜。

例如：

• Clarification 什麼時候結束？
• Scope 調整後如果又出現新的 Unknown，要往哪裡走？
• Specification 產生後還能不能修改？
• AI Coding Prompt 什麼時候才要產生？

所以 User Story 先往後移。

今天先把 ClarifyBuild Usage Flow 再往下拆一層，讓它從「看得懂的產品流程」逐漸變成之後能拿去畫 Wireframe、寫 State Logic 的規格。

Usage Flow 有了，還不代表可以直接開始畫畫面

昨天已經把 ClarifyBuild MVP 收斂成四個主要 View：

Landing
Builder
Spec Preview
Prompt Preview

其中 Builder 負責三個主要 State：

Idea Entry
Clarification
Scope Review

這些決策今天不重新討論。

今天要補的是它們之間的規則：

什麼事件會讓 State 改變？
什麼條件成立才能往下一步？
什麼情況需要回到前面的 State？
哪些操作只執行 Action，不需要切換 View？

這就是我今天所說的 Transition。

如果只知道有 Builder，卻沒有定義這些 Transition，那之後即使畫出 Wireframe，實際開始 Vibe Coding 時，AI 還是得自行補完大量產品決策。

先把 View、State、Action 與 Transition 分開

今天整理流程時，我先把幾種東西分開理解。

View

使用者目前看到的主要畫面，也就是前面那四個。

State

同一個 View 裡，目前處於哪一段工作，例如 Builder 裡的 Idea Entry、Clarification、Scope Review。

所以未來真正實作 Builder 時，我需要處理的會比較接近：

builderState = idea
builderState = clarification
builderState = scope

這只是目前用來理解產品邏輯的示意，還不是最終 JavaScript Data Model。

我要做的不是很多頁，而是一個會隨需求狀態改變內容的 Builder。

Action

使用者做了一件事，但不一定離開目前的 View。

例如：

Export Markdown
Copy Prompt

Transition

某個事件發生後，系統進入另一個 State 或 View。

例如：

Start Clarifying
→ Landing 進入 Builder / Idea Entry

或：

Confirm Requirement
→ Generate Project Specification
→ Spec Preview

把這幾個角色拆開後，Usage Flow 就比較不容易把「按一下按鈕」與「進入新的產品階段」全部畫成同一層。

第一段：從 Landing 進入 Builder

Landing 的工作維持單純。

它負責讓第一次進來的人知道 ClarifyBuild 在做什麼，並提供主要 CTA：

Start Clarifying

按下後才進入 Builder。

因此第一段流程確定為：

Landing
│
│ Start Clarifying
▼
Builder / Idea Entry
│
│ Enter Project Idea
│ Submit
▼
Builder / Clarification

Idea Entry 也不需要先要求填完整 PRD。

使用者只需要先告訴 ClarifyBuild：

我想做什麼？

接下來才交給 Clarification 找出真正還不知道的部分。

Clarification 的完成條件不能靠題數

ClarifyBuild 前幾天已經決定採 Dynamic Clarification。

所以流程不會長成：

Question 1
↓
Question 2
↓
Question 3
↓
Question 4
↓
Finish

系統應該從目前已有的 Requirement 中找出 Unknown，再針對相關的 Clarification Dimension 提問。

目前的核心迴圈是：

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

如果還有需要優先釐清的重要 Unknown，就繼續 Clarification。

如果已經沒有，就可以進入 Scope Review。

因此今天補上的第一個 Transition Rule 是：

仍有需要優先釐清的重要 Unknown
→ Continue Clarification

沒有需要優先釐清的重要 Unknown
→ Scope Review

這裡我暫時不定義「什麼條件才算重要 Unknown」。

因為那已經進入 Clarification Engine 的判斷規則。

今天只先確定：

Clarification 的結束條件來自 Requirement 的狀態，而不是「已經回答第幾題」。

Scope Review 是進入 Specification 前的收斂點

Clarification 完成後會進入：

Builder / Scope Review

使用者可以在這裡重新檢查第一版到底要做哪些功能：

Must Have
Nice to Have
Future
Out of Scope

但把 Scope 放進完整 Usage Flow 後，我發現這裡還需要處理一種情況。

假設使用者想做的是一個活動報名網站，一開始把 Authentication 放在 Future。

到了 Scope Review，使用者又決定把它改成 Must Have。

這個變更可能立刻產生新的問題：

使用哪種登入方式？
資料是否需要跟帳號同步？
忘記密碼要不要做？

此時 Requirement 又出現需要優先釐清的重要 Unknown。

所以 Scope Review 不保證一定直接往 Specification 前進。

它可能回到 Clarification：

Builder / Scope Review
│
│ Review / Adjust Scope
│
├─ Scope 調整產生新的重要 Unknown
│      ↓
│   Builder / Clarification
│
└─ 沒有新的重要 Unknown
       ↓
   Confirm Requirement

另外還有第二條返回路徑。

即使系統沒有發現新的 Unknown，使用者也可能自己察覺：

我前面對 Target User 的設定想改。

這種情況同樣可以從 Scope Review 回到 Clarification，修改前面的 Requirement。

所以目前 Scope Review 會有兩種回到 Clarification 的原因：

系統發現新的重要 Unknown

或

使用者主動修改前段 Requirement

這兩條路徑在意義上不同，但最後都回到同一個 Builder State。

Confirm Requirement 之後才產生 Project Specification

當 Scope 已經確認，而且目前沒有仍需優先釐清的重要 Unknown，就可以進入下一步：

Confirm Requirement
↓
Generate Project Specification
↓
Spec Preview

Spec Preview 要能回頭修改 Requirement

產生 Project Specification 不代表內容從此不能動。

使用者看到 Spec 後，很可能才發現：

這個功能不是我真正想要的。

或是：

我好像漏掉一個限制。

因此 Spec Preview 需要一條：

Edit Requirement

目前我先決定：

Spec Preview
↓ Edit Requirement
Builder / Scope Review

預設先回 Scope Review，而不是直接跳回 Clarification。

因為這裡可以先讓使用者重新查看目前完整的需求與 Scope。

如果真正需要修改前段 Requirement，再從 Scope Review 回 Clarification。

這樣可以維持比較單純的 State 路徑：

Spec Preview
↓
Scope Review
↓
必要時再回 Clarification

同時，回去修改時前面已經建立的 Requirement 內容都必須保留。

至於實際 State Schema 與 localStorage 要怎麼存，之後再處理。

AI Coding Prompt 由使用者明確觸發

Spec Preview 還有另一條真正會前進的操作：

Generate AI Coding Prompt

我決定第一版不要在 Project Specification 產生時，同時偷偷把 Prompt 也一起生成。

流程會是：

Generate Project Specification
↓
Spec Preview
↓
使用者查看 Specification
↓
Generate AI Coding Prompt
↓
Prompt Preview

這中間保留了一次 Review 的機會。

如果 Specification 本身就不正確，使用者應該先修改 Requirement，而不是拿著錯誤的 Spec 繼續產生 Prompt。

這也符合 ClarifyBuild 原本的核心流程：

Idea
↓
Clarify
↓
Scope
↓
Specification
↓
AI Coding Prompt

Prompt 放在最後，前面的 Requirement 才是它的來源。

Export Markdown 與 Copy Prompt 都維持 Action

昨天已經決定：

Export Markdown
Copy Prompt

都不需要額外建立獨立頁面。

今天把它們放回完整 Usage Flow 後，可以更清楚區分：

Spec Preview
│
│  └─ Action：Export Markdown
│
├─ Edit Requirement
│      ↓
│   Builder / Scope Review
│
└─ Generate AI Coding Prompt
       ↓
    Prompt Preview

Export Markdown 執行完成後，使用者仍然留在 Spec Preview。

Prompt Preview 也是一樣：

Prompt Preview
│
│  └─ Action：Copy Prompt
│
└─ Back to Spec Preview

Copy Prompt 只是把目前內容複製到 Clipboard，不需要因此產生新的 Destination。

ClarifyBuild Usage Flow v0.1

整理完今天的 State 與 Transition，目前第一版完整流程可以寫成：

Landing
│
│ Start Clarifying
▼
Builder / Idea Entry
│
│ Enter Project Idea
│ Submit
▼
Builder / Clarification
│
│ Identify Unknowns
│ ↓
│ Find Relevant Clarification Dimension
│ ↓
│ Ask Question
│ ↓
│ User Decision
│ ↓
│ Update Requirement
│ ↓
│ Check Unknowns Again
│
├─ 仍有需要優先釐清的重要 Unknown
│      └──→ Continue Clarification
│
└─ 沒有需要優先釐清的重要 Unknown
       ↓
Builder / Scope Review
│
│ Review / Adjust Scope
│
├─ Scope 調整產生新的重要 Unknown
│      └──→ Builder / Clarification
│
├─ 使用者要修改前段 Requirement
│      └──→ Builder / Clarification
│
└─ Confirm Requirement
       ↓
   Generate Project Specification
       ↓
Spec Preview
│
│  └─ Action：Export Markdown
│
├─ Edit Requirement
│      └──→ Builder / Scope Review
│
└─ Generate AI Coding Prompt
       ↓
Prompt Preview
│
│  └─ Action：Copy Prompt
│
└─ Back to Spec Preview

跟昨天相比，頁面數量完全沒有增加。

真正增加的是每個階段之間的規則。

現在開始可以回答：

什麼時候前進？
什麼時候繼續問？
什麼時候需要回頭？
哪一個操作會換 State？
哪一個操作只執行 Action？

這些規則才會真正影響後面的 Wireframe 與 JavaScript State Logic。

Dynamic Clarification 也影響了進度的定義

另一個從 Usage Flow 延伸出來的問題，是 Progress。

如果題目固定，很容易顯示：

Question 3 / 7

但 ClarifyBuild 不知道每一個 Idea 最後需要問幾題。

所以第一版的進度規則先確定為：

以產品階段呈現進度，不依賴固定題數。

例如概念上會是：

Idea
→ Clarify
→ Scope
→ Spec
→ Prompt

至於畫面最後要使用 Stepper、文字標籤，還是其他方式呈現，今天不決定。

那屬於後面的 Wireframe 與 UI 設計。

今天只留下 Interaction Rule，避免未來實作時又做出：

Step 3 / 7

這種與 Dynamic Clarification 衝突的介面。

今天真正補上的，是 Flow 的規則

昨天完成 Usage Flow 之後，我已經知道 ClarifyBuild 大致會怎麼走。

今天則開始補上：

View
State
Action
Transition

尤其幾個會直接影響實作的決策現在已經比較明確：

Landing 透過 Start Clarifying 進 Builder

Clarification 沒有固定題數

Clarification 是否結束，取決於是否還有需要優先釐清的重要 Unknown

Scope 改變可能重新開啟 Clarification

Spec Preview 可以回頭修改 Requirement

AI Coding Prompt 必須由使用者明確觸發

Export Markdown 與 Copy Prompt 都只是 Action

Progress 採階段概念，不依賴固定總題數

這些內容還沒有決定畫面長什麼樣。

但它們已經足以開始限制下一階段的產品設計。

還沒決定的東西繼續留白

Usage Flow 細化後，也更清楚看見下一個真正的黑盒子：

Identify Unknowns
↓
Find Relevant Clarification Dimension
↓
Ask Question

目前我還沒有決定：

怎麼判斷一個 Dimension 已經足夠明確？
哪些 Unknown 需要優先釐清？
問題要怎麼選？
同一個 Dimension 是否可能問超過一次？
Decision Boundary 要在什麼情況下出現？
規則式 JavaScript 是否足夠？
什麼情況才真的需要 AI API？

這些問題暫時不在 Day 9 提前回答。

因為它們屬於下一層的 Requirement Wizard 與 Clarification Engine。

今天只先讓 ClarifyBuild Usage Flow 從概念流程，往可以支撐實作的 Interaction Flow 再前進一步。

原本預計接著談的 User Story 也沒有消失，只是這次實際往產品開發走時，Usage Flow 的缺口先浮了出來，文章順序也就跟著真正的開發問題調整。

下一步，我想先打開這個黑盒子：

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

Day 9 完成。

明天見。