昨天 Day 13，我把 ClarifyBuild v0.1 的 Low-fi Wireframe 整理出來。
到那一步為止，ClarifyBuild 已經不只是「我想做一個需求釐清工具」而已。
它已經有：
所以照理來說，今天應該終於可以開始寫畫面了。
也就是把 Wireframe 變成 HTML、CSS、JavaScript。
但真的打開專案準備開始做時，我發現第一件事不是馬上切畫面，而是先問一個更基本的問題：
這個產品的每一層，到底誰負責什麼？
我原本也很想直接從第一個畫面開始做。
例如先做：
What do you want to build?
[ Idea textarea ]
[ 開始釐清 ]
這看起來很合理。
但 ClarifyBuild 不是一般 landing page。
它真正麻煩的地方，不是畫面上有幾個 input 或 button，而是每個 button 背後都代表一個產品語意。
例如：
開始釐清
不只是切換畫面。
它代表：
保存 Original Idea
↓
執行 Candidate Detection
↓
初始化 Requirement State
↓
決定下一個 Clarification Goal
又例如：
沒錯
也不只是關掉一張卡片。
它代表：
Candidate
↓
user_confirmed
↓
Resolved Requirement
如果我直接把這些邏輯全部寫在 UI button handler 裡，短期內也許可以跑。
但很快就會變成：
UI 裡有一堆產品邏輯
State 裡有一堆畫面暫存
Spec Generator 又偷偷補需求
Prompt Assembler 又自己重新整理一次
這樣 ClarifyBuild 自己就會犯它原本想解決的錯誤：
需求、規格、Prompt 混在一起。
所以 Day 14 我先做的不是把畫面做漂亮，而是建立實作架構與責任邊界。
今天建立 MVP 骨架時，我先把程式分成幾層。
不是為了過度工程化，而是為了避免產品邏輯散落在各處。
目前 ClarifyBuild v0.1 的主要責任層大概是：
UI
↓
Builder State
↓
Clarification Engine
↓
Canonical Project Model
↓
Spec Generator
↓
Prompt Assembler
另外還有一個很重要的跨層規則：
Storage / Generated Output lifecycle
這些層各自負責不同事情。
UI 負責讓使用者操作。
Builder State 負責使用者目前在 Builder 裡走到哪一段。
Clarification Engine 負責判斷下一個要問什麼。
Canonical Project Model 保存使用者真正做出的產品決策。
Spec Generator 把 Canonical Model 轉成 Project Specification。
Prompt Assembler 再把 Project Specification 組成 AI Coding Prompt。
今天大部分時間，其實都花在確認這幾層不要互相越界。
UI 的工作是顯示畫面、收集使用者 action。
例如：
但 UI 不應該自己決定：
這個 Requirement 算不算 Resolved？
這個 Candidate 能不能直接進 Spec？
這個 Scope Change 要不要讓舊資料失效？
Prompt 能不能偷偷補一條需求？
這些都不是 UI 的責任。
因為 UI 如果開始自己做產品判斷，後面會很難追蹤：
到底是哪個 action 讓 Canonical Project Model 改變了？
所以我讓 UI 盡量只收集使用者動作。
真正的規則放到其他層處理。
今天實作時，我也重新確認了一個容易混淆的地方。
Builder State 負責的是使用者目前在 Builder 裡走到哪一段。
也就是：
Idea Entry
Clarification
Scope Review
Specification Setup
其中 Optional Details 比較像 Clarification 階段裡的一個子步驟，不是跟 Scope Review 同層級的新 State。
而 Spec Preview 和 Prompt Preview 也不是 Builder State。
它們是兩個獨立的主要 View。
這件事我一開始其實也差點混在一起。因為從使用者角度看，它們都在同一條流程裡：
Idea → Clarify → Scope → Specify → Spec → Prompt
但從實作角度看，Builder State 和 Preview View 的責任不同。
Builder 是使用者還在建立需求與規格。
Preview 則是顯示已經產生的 output。
這個邊界如果不先釐清，後面很容易發生一件事：
Preview 看起來像可以直接改，結果又變成第二份資料來源。
這正是 ClarifyBuild 要避免的。
Day 10 已經決定，ClarifyBuild 的 Requirement Wizard 不是固定問卷。
它不是：
Question 1
Question 2
Question 3
而是：
Current Requirement
↓
Inspect State
↓
Find Important Unknown
↓
Ask
↓
User Decision
↓
Update Requirement
所以今天實作時，我把這件事獨立成 Clarification Engine。
它目前負責：
needs_confirmation
這裡我一直提醒自己 Day 10 的核心規則：
Inference ≠ Resolved
例如使用者說：
我想做一個讓研究生整理論文的網站。
系統可以推測：
Target User candidate = 研究生
Platform candidate = Web
但這只是 Candidate。
使用者還沒有按下「沒錯」或「修改」之前，它不能進入正式 Requirement。
Day 11 最重要的決策之一，就是 ClarifyBuild 需要有 Canonical Project Model。
它保存的是使用者真正做出的產品決策。
例如：
今天實作時，我也盡量讓這件事保持清楚：
畫面可以顯示資料，但不能讓畫面暫存假裝是正式 Requirement。
例如 Current Draft 只顯示 resolved 的內容。
如果某個值只是 candidate，不能因為畫面上看起來很合理，就直接顯示成「已確認需求」。
這是 Day 10 原則在程式裡的延伸。
今天另一個我特別小心的地方，是 Project Specification 和 AI Coding Prompt 的生命週期。
Day 11 和 Day 12 已經決定：
Canonical Project Model
↓
Project Specification
↓
AI Coding Prompt
也就是：
所以今天我沒有把 generated Spec / Prompt 當成正式資料保存。
它們是需要時從 Canonical Project Model 產生的 output。
如果使用者從 Spec Preview 回去改 Scope，舊的 generated output 就退出 current flow。
之後必須重新 Generate。
這避免一個很危險的狀況：
Canonical Model 已經改了
但使用者還在用舊 Spec / 舊 Prompt
這也呼應昨天 Wireframe 定下來的原則：
修改來源，而不是修改產物。
Scope Review 也有一個很容易做錯的地方。
假設 baseline 已經建立，使用者回來調整 Scope。
如果每次 Select 改變就立刻讓 Feature Specification 失效，會有問題。
例如使用者只是試著把某個功能從 Must Have 改到 Future，又馬上改回 Must Have。
最後結果其實沒有變。
這時如果系統已經把後面的功能規格標成 needs review，就會製造假的負擔。
所以 Day 13 已經決定：
Scope Change 不在每次 Select 改動時立即 Evaluate，只在按「確認範圍並繼續」時，比較 current scope 與
scopeBaseline的淨差異。
今天我把這個邏輯也放進實作裡。
也就是：
使用者調整 Select
↓
只更新目前 draft
↓
按確認範圍並繼續
↓
比較 current scope vs scopeBaseline
↓
判斷是否真的有 Scope Change
這樣比較符合使用者實際操作，也避免太早把資料標成失效。
今天也實作了 Needs Review 的基本 lifecycle。
如果上游需求改變，例如：
Platform = Web
改成：
Platform = Mobile
那之前寫好的 Feature Specification 要不要刪掉？
答案是：不刪。
因為它可能還有參考價值。
但也不能讓它直接通過。
所以目前做法是：
保留原內容
↓
標記 needsReview
↓
使用者重新確認或修改
↓
才能再次 Generate Project Specification
這個設計讓 ClarifyBuild 不會浪費使用者已經做過的決定。
但也不會假裝舊資料在新需求下仍然一定正確。
Day 10 有一個規則：
baseline 建立之後，如果有新的 Must Have，或既有 Must Have 的功能定義改變，可能需要補一個 Feature-level clarification。
例如原本某個功能是 Future：
匯出論文清單
後來被拉進 Must Have。
這時不能直接進 Specification Setup，因為系統還不知道：
第一版最低需要讓使用者完成什麼？
所以現在 MVP 會先攔截：
Scope Review
↓
偵測到 Must Have upgrade
↓
回 Clarification 補問 Feature-level Decision
↓
回 Scope Review 再次確認
↓
進 Specification Setup
這仍然不是自動幫使用者補需求。
而是把重要的未知事項重新交給使用者決定。
目前 Day 14 的 MVP 骨架已經可以跑過這條主流程：
Idea Entry
↓
Idea Understanding / Candidate confirmation
↓
Clarification
↓
Optional Details
↓
Scope Review
↓
Feature-level Important Unknown interception
↓
Specification Setup
↓
Spec Preview
↓
Prompt Preview
Spec Preview 目前是 read-only rendered Markdown。
Prompt Preview 也是 read-only，顯示的是 raw prompt text，符合昨天定下來的：
What You See = What You Copy
Copy Prompt 和 Export Markdown 只是 output action。
它們成功或失敗，只會顯示 UI feedback，不會修改 Canonical Project Model。
今天沒有做完整設計，也沒有做高保真 UI。
我留下的是一個可以繼續長大的 MVP 骨架。
它包含幾個部分：
第一，是最小可執行的靜態前端。
目前可以用簡單的本機伺服器跑起來，不需要後端、不需要資料庫，也不需要 AI API。這對 Day 14 來說很重要，因為我現在要先確認產品流程跑得通，而不是一開始就把部署和基礎設施變複雜。
第二，是產品邏輯的幾個核心模組。
我把資料模型、Clarification、Scope、Spec Generator、Prompt Assembler 分開放。這樣之後如果某個規則要調整，比較不會牽一髮動全身。
第三，是一份簡單的狀態紀錄。
我另外寫了 Day 14 status，記錄目前完成了什麼、哪些還沒完成、Day 15 建議從哪裡開始。這份文件不是產品文件，而是開發紀錄，方便之後回頭看今天到底做了哪些取捨。
第四，是幾個保護核心規則的測試。
目前測試不追求完整覆蓋率，而是先保護幾條最容易壞掉的產品邏輯。
寫 Scope Change 那條測試時最有感覺。
因為它不是單純測一個 function 有沒有回傳 true 或 false，而是在測 Day 13 已經定下來的產品語意：
Scope Change 只在使用者按下「確認範圍並繼續」時，才比較 current scope 和
scopeBaseline的淨差異。
如果這裡寫錯，畫面也許看起來還是可以操作，但產品邏輯其實已經偏掉了。
其他像 Candidate 不能直接變 resolved、Needs Review 要保留舊資料、Feature-level Important Unknown 需要先補問，也都是同一種測試。
它們不是為了讓測試數字好看。
而是先幫 ClarifyBuild 守住前 13 天已經定下來的幾條底線。
Day 14 做完之後，我覺得今天最重要的成果是：
ClarifyBuild 的實作骨架開始知道每一層不能越界。
UI 不能偷偷做產品決策、Spec Generator 不能補不存在的需求、Prompt Assembler 不能重新解釋產品、Generated Output 不能變成第二份真相。
這幾件事，今天幾乎每一層都各自確認過一次。
它們看起來不像畫面功能。
但如果沒有先定清楚，後面越做越快時，整個產品很容易開始自我矛盾。
今天終於開始進入實作。
但我沒有先追求漂亮畫面，而是先讓 ClarifyBuild 有一個不容易把需求、規格和 Prompt 混在一起的骨架。
這件事其實很符合這個專案一開始的主題。
ClarifyBuild 想解決的是：
AI Coding 之前，需求要先釐清。
而今天我自己也遇到很像的問題：Coding 之前，架構責任也要先釐清。
如果沒有先想清楚哪一層是 Source of Truth、哪一層只是 Preview、哪一層可以改資料、哪一層只能產生輸出，那我只是把模糊需求，換成模糊程式碼而已。
所以 Day 14 對我來說，比起「開始寫畫面」，更像是把前 13 天的產品邏輯，變成不會互相打架的程式結構。
明天 Day 15，我會繼續往前，把目前還偏 MVP 的 Specification Setup，改得更像真的能給初學者使用的 Builder。
Day 14 完成。
明天見。
iThome鐵人賽
看影片追技術