昨天 Day 12，我終於把 ClarifyBuild 最後要輸出的 AI Coding Prompt 定下來。
到這裡為止，前面的東西其實已經不少了。
我有：
照理來說，接下來應該終於可以做一件比較「像在做網站」的事情了。
也就是：
畫 Wireframe。
我原本真的覺得，到了這一步應該會輕鬆很多。
因為前面的資料結構、流程、規則都已經定得差不多了，Wireframe 應該只是把那些東西排到畫面上而已。
結果真的開始畫之後，我才發現：
規格寫清楚，不代表畫面就會自己長出來。
很多前面看起來可以「之後再決定」的事情，到了 Wireframe 階段就躲不掉了。
按鈕要放哪裡？
使用者現在到底在做什麼？
這個資訊要不要讓他看到？
某個欄位到底是單行輸入、Textarea，還是選項？
回去修改之後，要回哪一頁？
產生出來的 Spec 能不能直接編輯？
Prompt Preview 到底是漂亮地 Render，還是要讓使用者看到實際會 Copy 出去的文字？
這些都不是資料 Schema 能直接回答的。
所以今天做到後來，我開始覺得：
Wireframe 不是把規格畫出來，而是把產品邏輯翻譯成使用者真的能操作的介面。
前面已經把 ClarifyBuild 的主要流程整理成：
Idea
↓
Clarify
↓
Scope
↓
Specify
↓
Spec
↓
Prompt
今天我決定讓這六個階段直接成為整個產品的 Global Progress。
也就是：
Idea → Clarify → Scope → Specify → Spec → Prompt
這裡有一個很重要的差別。
它不是：
Question 1 / 10
Question 2 / 10
Question 3 / 10
因為 ClarifyBuild 的問題本來就不是固定題數。
有人一開始只輸入：
我想做一個旅遊網站。
可能很多東西都需要問。
但也有人一開始就已經說：
我想做一個給研究生使用的 Web 工具，讓他們可以收藏、搜尋和分類論文。
這時候有些資訊就已經存在，不應該再從頭問一次。
所以 Progress 顯示的不是：
「你回答到第幾題」
而是：
「你現在正在產品流程的哪個階段」。
這也變成我今天第一個比較明確的 Wireframe 原則。
第一個畫面是 Idea Entry。
一開始我有想過：
是不是要先讓使用者填：
但後來很快就放棄了。
因為如果一開始就要填這麼多東西，ClarifyBuild 本身就變成一張 Requirement Form。
這和我原本想解決的問題完全相反。
使用者就是因為：
還不知道需求要怎麼寫完整
才來用 ClarifyBuild。
結果第一個畫面卻要求他先填一份完整表單，這件事本身就很矛盾。
所以第一版我只留下：
你想做什麼？
[ 描述你現在的產品想法…… ]
例如：
我想做一個讓研究生整理論文的網站。
[ 開始釐清 ]
沒有 Project Name。
也不設定最低字數。
只要不是空白，就可以開始。
因為 ClarifyBuild 的工作，本來就不是要求使用者先把 Idea 寫完整。
而是：
從不完整的 Idea 開始。
接下來就比較麻煩了。
Clarification Engine 前面已經定義成 Dynamic Clarification。
也就是系統會根據目前 Requirement State，決定下一個最值得問的問題。
所以 Wireframe 不能長得像：
Step 1
Who is your target user?
Step 2
What problem do they have?
Step 3
What is your goal?
因為這又偷偷把它變回固定 Wizard。
最後我決定讓 Clarification 共用同一個 Question Shell。
大致像：
[ 主要使用者 ]
誰最主要會使用這個產品？
[ Answer ]
[ 我還不確定 ]
[ 下一步 ]
不同 Requirement，只替換問題與 Input Component。
例如：
Target User：
Short Text
Problem：
Compact Textarea
Platform：
Single Choice
Core Function：
Feature List Builder
這樣畫面骨架可以維持一致，但不同 Requirement 仍然可以使用適合它的輸入方式。
今天另一個我覺得很重要的 UI 決定，是：
我還不確定
這顆按鈕到底代表什麼？
如果把它設計成：
我還不確定
↓
跳過
那 Blocking Requirement 就失去意義了。
例如 Platform 還不知道，卻直接跳過，最後還是得讓 Coding Agent 自己猜。
所以現在的設計是：
我還不確定
↓
展開 Help
例如 Target User 可以顯示：
Example
正在寫碩士論文的研究生
換個方式想
如果第一版只能先服務一種人，
你最希望先幫助誰？
回答模板
正在 ______ 的 ______。
但看完提示後，還是要由使用者自己回答。
也就是：
Help 是降低 Decision 成本，不是替使用者做 Decision。
這件事其實一路呼應前面 Day 10 的核心原則：
Inference ≠ Resolved
系統可以協助理解。
但不能因為「看起來很合理」，就偷偷把某個答案當成使用者已經決定。
從 Clarification 開始，我在右側加入了一個 Current Draft。
大概像：
Current Draft
主要使用者
研究生
要解決的問題
論文散落在不同工具
使用者目標
可以快速整理與重新找到論文
第一版平台
Web
但這裡有一個限制：
只顯示真正 Resolved 的內容。
如果系統只是從 Idea 猜到：
使用者可能是研究生
但使用者還沒有確認，那它不能直接出現在 Current Draft 裡面。
不然視覺上就會讓人誤以為：
這已經是我的需求。
而且 Current Draft 第一版我也先做成 Read-only。
如果真的要修改前面的 Requirement，走正式的 Return Flow。
我暫時不想讓整個 Sidebar 到處都是可以直接點擊編輯的欄位，因為那樣很容易讓 Canonical Data 的修改路徑變得混亂。
Clarification 完成之後，就會進 Scope Review。
這裡要把目前想到的 Feature 分成：
我一開始很自然想到：
做成 Trello 一樣的四欄 Drag & Drop 好像很漂亮。
但真的開始想 Mobile、誤觸和操作方式之後，我最後沒有採用。
因為 ClarifyBuild 的重點不是做 Project Management Board。
真正重要的是：
使用者有沒有清楚做出 Scope Decision。
所以最後第一版採 Select：
搜尋論文
[ Must Have ▼ ]
每個 Scope 再附上白話說明。
例如：
Must Have
第一版沒有它就不能完成核心目標
Nice to Have
有會更完整，但第一版沒有也能使用
Future
現在先不做，但未來可能加入
Out of Scope
目前明確不納入
而且系統不會先替使用者預分類。
一開始全部都是：
scope = null
必須由使用者自己做決定。
Scope 決定完之後，下一步是 Specification Setup。
這裡其實差點又變成我最一開始不想做的東西：
超大型 PRD Form。
因為現在要補的內容很多：
如果全部直接攤在同一頁：
Actor
User Value
Trigger
System Behavior
Result
Rules
Precondition
Flow
Constraints
Tech Stack
...
我自己看到都不想填。
所以最後我把它拆成四個區塊：
主要流程
功能規格
專案限制
技術設定
右側則不再顯示 Current Draft，而是改成 Setup Status：
主要流程 ✓
功能規格 2 / 3
專案限制 ✓
技術設定 ○
四個區塊可以自由切換。
不是一定要填完第一個才能看第二個。
因為這裡已經不是 Clarification Question，而是一組已知的 Specification 工作。
Day 11 已經決定每個 Must Have Feature 都需要 Feature Specification。
資料裡會有：
actor
userValue
trigger
systemBehavior
result
rules
precondition
但 Wireframe 不應該把這些 Schema 名稱直接丟給使用者。
所以畫面會換成比較自然的問法。
例如「搜尋論文」：
誰會使用這個功能？
[ 研究生 ]
這個功能主要幫他完成什麼？
[ 快速重新找到收藏過的論文 ]
當使用者……
[ 輸入論文名稱 ]
系統要……
[ 搜尋符合的收藏內容 ]
最後應該……
[ 顯示搜尋結果 ]
這件事讓我更確定：
Schema 是給系統看的，不代表 UI 要長得像 Schema。
如果只是把資料欄位全部排成 Form，technically 也算有做畫面。
但那不代表真的有設計使用體驗。
Specification Setup 完成後，使用者會產生 Project Specification。
這裡我遇到另一個很容易做錯的地方。
假設畫面上看到：
Functional Requirement
FR-03：
使用者輸入關鍵字後，
系統依論文名稱過濾內容。
使用者覺得這條不對。
最直覺的做法可能是：
那就直接讓他點 FR-03 修改啊。
但這樣做之後會出現一個問題。
ClarifyBuild 的資料原本是：
Canonical Project Model
↓
Project Specification
如果可以直接改 Specification：
Canonical Project Model
↓
Project Specification
↑
手動修改
那到底哪一份才是真的？
所以最後 Spec Preview 我決定完全 Read-only。
如果使用者覺得：
做什麼不對。
就按：
調整需求與範圍
回 Scope Review。
如果覺得：
怎麼運作不對。
就按：
修改規格細節
回 Specification Setup。
也就是：
修改來源，而不是修改產物。
而且，就算兩個都是 Preview，它們服務的對象其實不完全一樣。
Spec Preview 的目的，是讓人閱讀。
所以我決定它用：
Rendered Markdown
搭配：
Sticky Table of Contents
+
Single Scroll Document
但 Prompt Preview 不一樣。
Prompt 最後是要 Copy 給 Coding Agent。
所以我反而希望使用者看到：
真正會被複製出去的完整文字。
也就是 Preformatted Text。
最後我替 Prompt Preview 定了一條原則：
What You See = What You Copy
畫面上看到什麼，Copy Prompt 就複製什麼。
不做：
畫面顯示精簡版
Copy 時偷偷塞完整版
也不做：
因為 Prompt 本來就是前面 Requirement 與 Specification 的 Consumer。
如果到了最後一頁又讓使用者直接把 Prompt 改成另一份需求，那前面的 Source of Truth 又會失去意義。
今天做到最後，我還碰到一個原本沒有打算在 Wireframe 階段處理這麼深的問題。
假設：
Platform = Web
原本所有 Feature Specification 都已經寫完。
後來使用者從 Spec Preview 回去，把 Platform 改成：
Mobile App
那之前的 Specification 要全部刪掉嗎？
最後的答案是：
不要刪。
保留原本內容，但標成：
需要重新檢查
例如：
搜尋論文
! 需要重新檢查
前面的需求已變更。
請確認目前的功能規格是否仍然適用。
[ 修改內容 ]
[ 確認目前內容 ]
如果原本內容其實還適用，使用者不一定要硬改。
可以直接：
確認目前內容。
這樣既不會浪費之前做過的決定，也不會讓舊 Specification 在上游 Requirement 已經改變後直接偷偷通過。
做到最後，ClarifyBuild v0.1 的主要 UI Flow 已經可以整理成：
Idea Entry
↓
Idea Understanding
↓
Clarification
↓
Optional Details
↓
Scope Review
↓
Specification Setup
↓
Spec Preview
↓
Prompt Preview
另外，也把主要畫面會遇到的幾種互動狀態一起補上：
Help State
Decision Boundary
Return States
Validation
Empty State
Needs Review
System Error
而且整條流程的核心原則開始變得一致：
使用者 Decision
↓
Canonical Project Model
↓
Project Specification
↓
AI Coding Prompt
畫面可以幫忙。
可以提醒。
可以提供 Example。
可以降低填寫成本。
但不應該偷偷替使用者補 Product Decision。
我以前想到 Wireframe，腦中比較容易浮現：
Header 放這裡
Sidebar 放這裡
Button 放右下角
但 ClarifyBuild 今天畫到後來，我覺得真正困難的部分其實不是：
這個按鈕放哪裡比較漂亮？
而是：
按下這顆按鈕，到底代表使用者做了什麼 Decision？
例如：
下一步
可能代表某個 Requirement 正式 Resolved。
使用建議設定
代表使用者明確確認 AI Decision Boundary。
確認範圍並繼續
可能建立 Scope baseline。
產生 Project Specification
代表目前所有 Specification Setup Exit Conditions 已經滿足。
複製 Prompt
則只是 Output Action，不應該再改變 Requirement。
一顆按鈕後面的產品語意如果沒有先想清楚，畫面就算看起來很完整，實作時還是會開始亂掉。
所以今天最後，我比較想把 Wireframe 理解成：
把資料、State、Decision 和 Transition，翻譯成使用者看得懂的互動。
目前我沒有繼續往下做完整 High-fidelity UI。
像是：
這些今天都先不鎖。
因為如果現在開始糾結按鈕是哪個藍色、圓角要 8px 還是 12px，反而會模糊今天真正完成的事情。
目前更重要的是：
ClarifyBuild 已經知道每個階段要讓使用者做什麼。
接下來才是把這份 Low-fi Wireframe，真正開始變成可以操作的網站。
今天原本只是想：
終於可以畫 Wireframe 了。
結果做到最後才發現，Wireframe 反而逼我把很多前面留白的產品決策真正做完。
今天 ClarifyBuild 比較明確地決定了：
這些看起來都像 UI 細節。
但做到後來我發現，它們其實都是：
產品規則。
或許這就是 Wireframe 真正有價值的地方。
它會把：
「規格上看起來已經講清楚」
的東西，逼著變成：
「使用者實際上到底怎麼操作」。
現在 ClarifyBuild 的 Low-fi Wireframe 已經有了。
接下來終於可以開始把畫面做出來。
但在真的開始 Coding 前，還有一件我想先確認：
我應該從哪個畫面開始做？
是先把整個網站 Layout 架好？
還是直接從最核心的 Builder 開始？
要不要一開始就處理 Responsive？
State 要先寫，還是畫面先做？
明天我就會正式開始把今天的 Wireframe，轉成 ClarifyBuild 的第一版介面。
Day 13 完成。
明天見。
iThome鐵人賽
看影片追技術