昨天 Day 14，我把 ClarifyBuild 寫成第一版可以跑的 MVP 骨架。
文章最後留下的下一步是：
把目前還偏 MVP 的 Specification Setup，改得更像真的能給初學者使用的 Builder。
所以今天 Day 15，我接著處理這件事。
Day 14 動的是我自己看得到的程式分層：UI、Builder State、Clarification Engine、Canonical Project Model、Spec Generator、Prompt Assembler 各自負責什麼。
Day 15 動的是使用者看得到、真的會操作的輸入畫面：
Builder 要怎麼讓人穩定地把規格填進去？
Day 14 結束時，ClarifyBuild 已經可以從 Idea 一路走到 AI Coding Prompt。
流程大概是：
Idea Entry
↓
Clarification
↓
Scope Review
↓
Specification Setup
↓
Project Specification
↓
AI Coding Prompt
這代表產品主流程已經串起來。
但「可以跑」和「好用」之間還有一段距離。
尤其是 Specification Setup。
這一步的任務，是把前面釐清出來的 Must Have 功能，整理成可以進入 Project Specification 的細節。
使用者需要回答：
這些內容會直接影響後面的 Project Specification 和 AI Coding Prompt。
但 Day 14 為了先讓流程跑起來，我用了最快的方式處理：
前提 | 當使用者 | 系統要 | 最後應該 | Important rules
也就是讓使用者在 textarea 裡用 | 分隔欄位。
這對開發者來說很快。
對真正的使用者來說，卻很容易出錯。
只要少打一個 |，或是順序搞錯，系統就可能讀不出正確的規格。
更重要的是，這不像一個「需求釐清工具」該提供的體驗。
如果 ClarifyBuild 的目標是幫助使用者把模糊想法變清楚，它不應該反過來要求使用者記住一套迷你語法。
Day 15 的實作原則很單純：
讓輸入方式變得更清楚，同時維持原本的資料來源。
這裡調整的是 Specification Setup 的輸入介面；Project Specification 本身仍然是產生後唯讀的結果。
這個邊界不能模糊。
因為前面幾天已經鎖定幾條核心規則：
features[] 裡所以今天不重新設計 Canonical Project Model。
我只是把原本需要記格式的輸入，換成使用者比較不容易填錯的表單。
最後儲存時，資料仍然回到同一份 Canonical Project Model。
這樣 ClarifyBuild 才不會長出兩份互相競爭的規格：一份藏在表單裡，一份出現在 Project Specification 裡。
Specification Setup 裡第一個改的是 Target Project User Flow。
Day 14 的做法，是讓使用者用每行文字描述流程，例如：
view | 搜尋頁 | 搜尋論文 | 輸入關鍵字並檢視結果
action | 輸入論文名稱 | 搜尋論文 | 縮小論文清單
這樣雖然可以存，但使用者要知道：
view 或 action
|
這其實是在要求使用者填一種簡化版資料格式。
所以今天我把它改成 row-based editor。
每一列都有明確欄位：
Purpose 主要是 View 這種 Step 的選填說明；如果是 Action，把動作本身描述清楚就好，不用勉強填 Purpose。
使用者可以新增步驟，也可以移除步驟。
這個改動看起來不大，但它代表一件事：
使用者不需要知道資料格式，也可以填出結構化資料。
這正是 ClarifyBuild 應該做的事。
解決 Target Project User Flow 之後，同樣的問題也出現在 Must Have feature 的 behavior list。
這一段比 Target Project User Flow 更關鍵。
因為它會直接影響 Project Specification 裡的 Functional Requirements。
Day 14 的格式是：
前提 | 當使用者 | 系統要 | 最後應該 | Important rules
例如：
| 輸入論文名稱 | 依名稱過濾論文清單 | 顯示符合的論文 | 不改變原始資料
這對我自己測試很方便。
但使用者真正需要思考的重點是：
所以 Day 15 我把它改成一列一個 behavior。
每一列都有：
前提和 important rules 可以留空。
但 trigger、system behavior、result 必須完整。
因為如果這三個欄位不清楚，Coding Agent 拿到的規格就還是不夠明確。
這裡延續了 Day 11 和 Day 12 的核心觀念：
Spec 不是把想法寫得更長，而是把可實作的行為講清楚。
今天改完後，畫面上的操作變多了。
使用者可以新增流程步驟、移除流程步驟、選擇 View / Action、指定相關功能。
也可以新增 feature behavior、移除 feature behavior，並分欄填寫 trigger、system behavior、result。
但這些操作最後仍然寫回原本的資料結構。
Target Project User Flow 仍然寫回 draft.targetProjectUserFlow.steps[]。
Feature behavior 仍然寫回 feature.specification.behaviors[]。
Spec Preview 也維持 read-only。
如果使用者想改規格，就回到 Specification Setup 修改來源資料，再重新產生 Project Specification。
這個流程比較保守，但資料流比較乾淨。
在 v0.1，我想先守住這件事。
今天除了改輸入方式，我也補了一條 MVP flow smoke test。
它還不到完整瀏覽器 UI 測試的程度，也沒有真的用工具去點畫面。
但它會直接走過 ClarifyBuild 的核心資料流程：
Idea
↓
Candidate detection / confirmation
↓
Blocking dimensions resolved
↓
Scope validation / baseline
↓
Specification Setup
↓
Project Specification
↓
AI Coding Prompt
這條測試要守住的是 Day 10 到 Day 14 已經鎖定的產品規則。
例如 Candidate 還是只會進入 needs_confirmation。
Scope 還是必須至少有一個 Must Have。
Specification Setup 還是必須完成主要流程、功能規格、專案限制與技術設定，才能產生 Project Specification。
Project Specification 和 AI Coding Prompt 也仍然是 deterministic generated output。
這條測試其實很小。
但它對現在的 ClarifyBuild 很有用。
因為接下來每一天都可能繼續加功能。
如果沒有一條基本 happy path，後面很容易某天改了 UI，卻沒有發現整條 Builder 流程已經斷掉。
Day 15 看起來不像一個很華麗的進度。
我沒有做漂亮的 dashboard。
沒有加動畫。
也沒有把整個產品重新設計一遍。
今天做的，是把兩個原本很容易填錯的地方，改成比較明確的表單互動。
但對 ClarifyBuild 來說，這一步很重要。
因為 ClarifyBuild 的價值不只在於產生一份看起來很像規格的文件。
它真正想解決的是：
使用者不知道該怎麼把模糊想法變成可實作規格。
如果 Builder 本身還要求使用者記住格式、手動對齊欄位、自己避免語法錯誤，那它就沒有真的幫上忙。
所以今天的重點不是讓畫面更漂亮。
而是讓規格輸入不容易壞掉。
今天我做了三件事。
第一，把 Target Project User Flow 從文字格式改成 row-based editor。
第二，把 Must Have feature behaviors 從 pipe-delimited textarea 改成可新增、可移除的行為列。
第三，補了一條 MVP happy path smoke test，確認從 Idea 到 AI Coding Prompt 的核心資料流仍然走得通。
目前所有測試都通過。
今天留下的下一個問題是：
當 Specification Setup 互動開始變多，UI 程式本身是不是也該拆小？
Day 14 我可以接受 UI 先集中在同一個 render file 裡。
Day 15 加完 row editor 後，這個檔案已經開始變得比較長。
所以 Day 16 很可能會先把 Scope Review 和 Specification Setup 的 UI rendering 拆開，再繼續往更多功能前進。
這樣後面要補完整 Project Specification、瀏覽器測試，或 draft import/export，才不會越改越卡。
但至少到今天為止，ClarifyBuild 已經從「可以跑的骨架」，往「比較不容易讓使用者填壞的 Builder」前進了一步。
Day 15 完成。
明天見。
iThome鐵人賽
看影片追技術