昨天 Day 10 的最後，我留下了一個問題：
這些 Requirement 最後到底要怎麼變成一份 Build-ready Project Specification？
目前 ClarifyBuild 已經可以逐步得到：
Problem
Target User
Goal
Platform
Core Function
Decision Boundary
Scope
...
看起來資料已經不少。
所以我原本以為 Day 11 要做的事情很單純：
Input
↓
整理欄位
↓
Project Specification
也就是決定：
哪些 Input 最後要放進 Spec？
但真正開始整理之後，我發現問題比想像中大一點。
因為有些資料只是 ClarifyBuild 自己跑 Wizard 時需要知道的 State，有些才是使用者真的做出的產品決策。
更麻煩的是：
就算 Requirement 和 Scope 都已經有了，也還不一定足以安全產生 Functional Requirement 和 Acceptance Criteria。
所以今天原本只是想定一份 Project Spec Schema。
最後卻順便補上了 ClarifyBuild 流程裡一直少掉的一段。
假設 Platform 的狀態現在是：
value = Web
status = Resolved
resolutionMode = user_confirmed
candidate = null
Coding Agent 真正需要知道的是：
Platform = Web
它不需要知道：
這一題原本是不是 Candidate？
使用者是自己輸入還是按「沒錯」？
前面有沒有 Skip 過？
這些資料對 ClarifyBuild 很重要。
因為系統需要靠它們判斷：
下一題要問什麼？
這項 Requirement 已經解決了嗎？
這個 Optional Detail 以前出現過嗎？
但它們不是使用者產品本身的 Requirement。
所以今天我先把資料角色分開。
最後 ClarifyBuild v0.1 採四層：
Input / Interaction State
↓
Canonical Project Model
↓
Project Specification
↓
AI Coding Prompt
其中真正的 Source of Truth 只有：
Canonical Project Model
它存的是使用者真正做出的產品決策。
例如：
Problem
Target User
Goal
Platform
Scope
Feature
Decision Boundary
Target Project User Flow
Feature Specification
Project Constraints
Tech Stack
而：
Project Specification
只是把這些資料整理成人和 Coding Agent 比較容易閱讀的形式。
它不是另一份需要同步維護的 Requirement。
這也讓 Day 10 的：
Inference ≠ Resolved
今天又往下延伸了一層。
例如：
Candidate = Web
State = Needs Confirmation
這個東西不能因為「很可能是 Web」，就出現在 Project Specification 裡。
所以現在 Spec Generator 有一條很明確的邊界：
Candidate
→ 不進 Spec
Unknown
→ 不進 Spec
Needs Confirmation
→ 不進 Spec
Resolved Decision
→ 可以進 Spec
另外還有一種情況：
使用者明確說「這件事讓 AI 決定」
這也可以進 Spec。
但 Spec 要保留：
這是使用者明確授權 AI 決定。
而不是讓「沒有填」和「交給 AI」變成同一件事。
今天最後整理出的原則是：
任何 Project Specification 欄位，都必須能追溯到使用者已經做出的 Decision，或可以從那些 Decision 確定推導出的結果。
不能因為某個內容「通常都會這樣」，Generator 就偷偷補上。
原本比較直覺的 Data Model 可能會長這樣：
coreFeatures[]
mustHave[]
niceToHave[]
futureFeatures[]
outOfScope[]
但做到 Scope Change 之後，這個結構就會開始很麻煩。
例如：
登入
Future → Must Have
如果使用五份 Array，就變成把登入從一個 Array 刪掉，再塞進另一個。
而且還要追蹤：
這還是不是原本那個登入 Feature？
所以今天正式改成：
features[]
每個 Feature 自己帶 Scope：
feature-001
登入
scope = future
變成 Must Have 時，只需要：
scope = must_have
Feature 本身仍然是同一個 Feature。
這也讓 Day 10 的 Scope Change 比較容易追蹤。
假設 Clarification 和 Scope 都完成了。
現在有：
Target User：
研究生
Goal：
把重要論文集中整理，之後快速找到
Must Have：
收藏論文
搜尋論文
分類論文
是不是就能直接 Generate Project Specification？
一開始我以為可以。
但如果 Project Specification 裡要有：
Functional Requirements
Acceptance Criteria
Target Project User Flow
馬上就會遇到問題。
例如：
Feature：搜尋論文
光這五個字其實不知道：
搜尋什麼？
使用者怎麼觸發？
系統怎麼處理？
最後顯示什麼？
沒有結果怎麼辦？
如果 ClarifyBuild 直接看到「搜尋論文」，然後自己產生：
使用者輸入關鍵字
↓
即時搜尋標題、作者、Tag
↓
300ms Debounce
↓
沒有結果顯示 Empty State
那 ClarifyBuild 又回到原本一直想避免的事情：
使用者講一點
↓
系統自己補很多
↓
看起來很完整的 Spec
所以真正的問題不是：
Schema 裡要不要有 Functional Requirements？
而是：
產生 Functional Requirements 之前，那些行為到底是誰決定的？
回頭看 ClarifyBuild 一直在講的主流程：
Idea
↓
Clarify
↓
Scope
↓
Specify
↓
Generate
↓
Build
我才發現：
Specify 這一段其實一直沒有真正被做出來。
前面的 Usage Flow 幾乎是：
Scope Review
↓
Confirm Requirement
↓
Generate Project Specification
Scope 決定的是：
第一版做不做這個 Feature？
但它沒有完整回答：
既然要做，這個 Feature 到底怎麼運作？
所以 Day 11 我正式新增一個 Builder State：
Specification Setup
流程也因此更新成：
Clarification
↓
Scope Review
↓
Confirm Requirement
↓
Specification Setup
↓
Generate Project Specification
↓
Spec Preview
這也讓 ClarifyBuild Usage Flow 從 v0.1 更新成 v0.2。
不過 Confirm Requirement 也不是隨時都可以按。
目前必須先滿足：
所有 Feature 都已完成 Scope 分類
+
至少有 1 個 Must Have
如果還有 Feature 沒分類，或第一版連一個 Must Have 都沒有，就會留在 Scope Review。
另外，如果進到 Specification Setup 後才發現：
Scope 好像還要調整。
也可以再回到 Scope Review。
所以新的流程不是只能一路往前，而是允許在真正產生 Spec 之前，把 Scope 再修正一次。
這一段我不想又做成一份超大的 PRD Form。
所以第一版只深入：
Must Have
Nice to Have、Future、Out of Scope 不需要現在全部寫完整規格。
因為第一版真正要交給 Coding Agent 開發的是 Must Have。
目前 Specification Setup 只負責四件事：
Target Project User Flow
Must Have Feature Specifications
Project Constraints
Tech Stack
其中最重要的是 Feature Specification。
我不希望 ClarifyBuild 問使用者：
請輸入 FR-01
請輸入 FR-02
請輸入 Acceptance Criteria
這樣只是把 Requirement Engineering 的工作原封不動丟回給初學者。
所以我先用比較接近自然思考的方式保存每個 Must Have Feature。
例如：
Feature：
搜尋論文
Actor：
研究生
User Value：
快速找到之前整理過的論文
一個 Feature 可以有多個 Behavior：
Trigger：
使用者輸入搜尋關鍵字
System Behavior：
系統依論文名稱過濾
Result：
顯示符合條件的論文
Rule：
沒有符合結果時顯示 Empty State
如果還有另一個行為：
清除搜尋關鍵字
↓
取消搜尋條件
↓
重新顯示全部論文
就再新增一個 Behavior。
因此：
1 Feature
≠
1 Functional Requirement
這也延續 Day 7 已經整理過的概念。
有了前面的 Feature Specification 後，ClarifyBuild 才有足夠資料做比較安全的轉換。
例如：
Actor：
研究生
Feature：
搜尋論文
User Value：
快速找到之前整理過的論文
可以轉成 User Story：
As a graduate student,
I want to search my papers,
so that I can quickly find previously organized papers.
Behavior：
Trigger：
輸入搜尋關鍵字
System Behavior：
依論文名稱過濾
Result：
顯示符合條件的論文
可以轉成 Functional Requirement：
當使用者輸入搜尋關鍵字時，
系統應依論文名稱過濾，
並顯示符合條件的論文。
Acceptance Criteria 也是一樣。
如果使用者有提供 Precondition：
Precondition：
使用者已進入 Collection
可以產生：
Given 使用者位於 Collection
When 使用者輸入搜尋關鍵字
Then 系統顯示符合條件的論文
如果沒有 Precondition，就不要硬生一個 Given：
When 使用者輸入搜尋關鍵字
Then 系統顯示符合條件的論文
今天我很想保留的一個原則就是：
完整不代表可以亂補。
做到這裡，另一個原本看起來像「可以自動生成」的東西也被我重新分類：
Target Project User Flow
假設現在有：
搜尋論文
收藏論文
查看收藏
AI 當然很容易自己排成：
Home
↓
Search
↓
Paper Detail
↓
Save
↓
Collection
但「主要流程怎麼走」本身就是產品決策。
所以 Day 11 正式改成：
Target Project User Flow
= Canonical Data
要由使用者在 Specification Setup 定義。
反過來，Pages 就可以由 Flow 推導。
例如 Flow 裡有：
Home
Search Results
Paper Detail
Collection
那 Pages / Views 就可以整理出：
Home
Search Results
Paper Detail
Collection
這種轉換不需要再創造新的產品決策。
因此現在的邊界變成：
Target Project User Flow
→ Canonical
Pages / Views
→ Derived
User Stories
→ Derived
Functional Requirements
→ Derived
Acceptance Criteria
→ Derived
昨天最後我還留了一個很明顯的問題。
原本 Project Specification 和 AI Coding Prompt 裡都有：
Constraints
Tech Stack
但前面的 Clarification 根本沒有定義它們從哪裡來。
今天最後決定：
兩個都不新增成第九、第十個 Clarification Dimension。
它們改放在 Specification Setup。
例如：
不得使用付費 API
必須部署到 GitHub Pages
資料不得離開瀏覽器
內容可以沒有。
但使用者必須至少 Review 過，這樣系統才知道：
真的沒有額外限制
而不是：
使用者根本還沒看
則一定要做一個明確的 Decision：
指定技術
或：
明確授權 AI 決定
兩者差很多。
沒有填
≠
讓 AI 決定
如果交給 AI，就代表使用者明確授權 Coding Agent 在既有 Platform、Constraints 和 Decision Boundary 範圍內選擇。
今天在寫 Schema 時還遇到另一個很實際的問題。
假設原本有一個 Feature：
登入
revision = 2
而目前的 Feature Specification 也是根據這一版 Feature Definition 建立：
specification.basedOnRevision = 2
後來使用者回到 Scope Review 或 Clarification，把 Feature 定義改成：
Google 帳號登入
這代表 Feature Definition 已經改變：
revision = 3
原本的 Feature Specification：
basedOnRevision = 2
就不能直接假設仍然適用。
因為：
2 ≠ 3
系統就知道：
這份 Specification 需要重新 Review。
但如果只是回到 Specification Setup，修改這個 Feature 的 Trigger、System Behavior、Result 等規格內容，則不會增加 feature.revision。
因為那是在修改：
Feature Specification
而不是：
Feature Definition
另外，如果：
Target User
Problem
Goal
Platform
這類上游資料被修改，也可能讓既有 Specification 需要重新 Review。
第一版先採保守策略：
寧可多讓使用者 Review 一次，也不要把可能已經過期的 Spec 直接交給 Coding Agent。
整理完來源之後，Project Specification v0.1 目前正式收斂成 18 個 Section：
1. Project Overview
2. Problem
3. Target Users
4. Product Goal
5. Platform
6. Usage Context
7. MVP Scope
8. Deferred Features
9. Out of Scope
10. Target Project User Flow
11. Pages / Views
12. User Stories
13. Functional Requirements
14. Acceptance Criteria
15. Design Preferences
16. AI Decision Boundary
17. Project Constraints
18. Tech Stack
不是每一節都一定有內容。
例如：
Usage Context
Design Preferences
Deferred Features
沒有資料時可以省略。
但最重要的不是它有 18 節。
而是現在我可以回答：
每一節的資料到底從哪裡來？
如果回答不出來，就不應該讓 Generator 自己補。
這也順便確定了 ClarifyBuild 下一層的邊界。
正式關係是：
Canonical Project Model
↓
Project Specification
↓
AI Coding Prompt
而不是：
Canonical Project Model
↓
Project Specification
再讓 AI 發揮一下
↓
AI Coding Prompt
Prompt 可以多的是：
Development Instructions
例如：
只實作 Must Have。
不要實作 Nice to Have、Future、
Out of Scope。
遵守 AI Decision Boundary。
如果需要修改被保護的產品決策，
先停止並詢問使用者。
這些是在告訴 Coding Agent：
怎麼執行這份 Spec。
不是替產品新增 Requirement。
Day 9 畫的四個主要 View 沒有增加：
Landing
Builder
Spec Preview
Prompt Preview
Builder 則從三個 State：
Idea Entry
Clarification
Scope Review
增加成：
Idea Entry
Clarification
Scope Review
Specification Setup
新的主要流程：
Landing
↓
Builder / Idea Entry
↓
Builder / Clarification
↓
Builder / Scope Review
↓
Confirm Requirement
↓
Builder / Specification Setup
↓
Generate Project Specification
↓
Spec Preview
↓
Generate AI Coding Prompt
↓
Prompt Preview
另外 Spec Preview 現在也分成兩種修改：
Edit Requirement
→ 回 Scope Review
Edit Specification
→ 回 Specification Setup
一個是在改：
做什麼。
另一個是在改：
它怎麼運作。
這兩件事終於被分開了。
而 Specification Setup 本身也不是單向道路。
如果在這個階段才發現 Scope 有問題，仍然可以：
Specification Setup
↓
Back / Edit Scope
↓
Scope Review
修改後，再重新通過 Confirm Requirement 的前置條件，才回到 Specification Setup。
今天原本只是想回答：
Input 最後怎麼 Mapping 到 Project Specification？
但真的開始寫 Schema 後，我才發現：
Requirement Clarification 完成，不代表已經足以產生 Build-ready Spec。
Scope 只能回答：
第一版做什麼？
Specification Setup 還需要回答：
既然要做，它應該怎麼運作？
所以今天 ClarifyBuild 又往前完整了一塊：
Idea
↓
Clarify
↓
Scope
↓
Specify
↓
Project Specification
而我目前最想保留的原則仍然沒有改：
使用者沒有決定的事情，ClarifyBuild 不應該因為「看起來合理」就替他決定。
Day 10 是：
Inference ≠ Resolved
Day 11 則把同一個原則一路延伸到：
Spec Generator
現在 Project Specification 已經有正式的欄位、來源與邊界。
下一個問題就是：
如果 Spec 已經寫得這麼完整，AI Coding Prompt 到底還需要放什麼？
它應該只是把整份 Spec 貼進去嗎？
還是應該重新整理成 Coding Agent 比較容易執行的結構？
哪些內容一定要保留？
哪些 Development Instructions 可以加入？
最重要的是：
怎麼確保 Prompt 不會又重新解讀 Requirement，甚至加入 Spec 裡沒有的東西？
所以 Day 12，我會開始處理：
Project Specification → AI Coding Prompt
也就是正式定義 ClarifyBuild 的 Prompt Output。
Day 11 完成。
明天見。
iThome鐵人賽
看影片追技術