昨天 Day 11 的最後，我留下了一個問題：
如果 Spec 已經寫得這麼完整，AI Coding Prompt 到底還需要放什麼？
而且還有一個更重要的問題：
怎麼確保 Prompt 不會又重新解讀 Requirement，甚至加入 Spec 裡沒有的東西？
這就是今天真正要處理的事情。
Day 11 完成 Project Spec Schema 之後，ClarifyBuild 已經可以把使用者做出的產品決策，以及由這些決策推導出的 User Stories、Functional Requirements、Acceptance Criteria 等內容，整理成 Project Specification。
下一步看起來很直接：
Project Specification
↓
AI Coding Prompt
但真的開始設計 Prompt Output 後，我才發現：
如果這一步又讓 AI 自由發揮，前面辛苦釐清好的 Requirement，還是可能在最後一刻被改掉。
我一開始想到的方式很直覺。
把 Project Specification 丟給另一個 AI，然後說：
「請幫我整理成一份完整、專業、適合 Claude Code 或 Codex 使用的 Coding Prompt。」
聽起來滿合理的。
但假設 Specification 裡只有：
Must Have：搜尋論文
Functional Requirement：
使用者輸入關鍵字後，
系統依論文名稱過濾資料。
如果再讓 AI 自由整理，它可能覺得搜尋功能還可以更完整，於是補上作者搜尋、Tag、Debounce、Search History 或進階篩選。
這些功能也許都很合理。
問題是：
使用者沒有決定要做。
Day 11 已經確定，產品內容要來自使用者已經做出的 Decision，或由那些 Decision 確定推導出的結果；Spec Generator 只負責依規則把資料轉成可讀的 Specification。
所以到了 Prompt 階段，我不希望再加一個「重新理解產品」的步驟。
ClarifyBuild v0.1 最後採用的是：
Project Specification
↓
Deterministic Prompt Assembly
↓
AI Coding Prompt
這裡的 deterministic，指的是按照固定規則組裝，而不是再請另一個 AI 自由改寫。
Prompt 由兩個部分組成：
Development Instructions / Execution Contract
↓
Complete Rendered Project Specification
Project Specification 本身完整保留。
不重新摘要、不重新分類，也不另外做第二套 Prompt Schema。
如果某個 Optional Section 原本因為沒有資料而沒有出現在 Spec，Prompt Generator 也不會自行補回來。
它的任務就是把已經產生好的 Specification，連同必要的執行規則交給 Coding Agent。
Project Specification 主要回答：
「這個產品要做什麼？」
但 Coding Agent 還需要知道：
「這份 Specification 要怎麼執行？」
所以我把 Development Instructions 定位成 Execution Contract。
目前固定 Prompt 裡會處理九個部分：
這些內容可以規範 Coding Agent 的工作方式，但不能突然替產品增加新的 Requirement。
例如：
「Implement only the Must Have scope.」
是在限制執行範圍。
但如果固定 Prompt 自己寫：
「Add authentication for security.」
那就已經替使用者新增 Feature 了。
我現在會用一個問題檢查每條 Instruction：
如果把 Project Specification 拿掉，只剩這句話，它是在告訴 Agent「怎麼做事」，還是在替產品做新的決定？
後者就不應該進固定 Prompt。
ClarifyBuild 前面已經把 Feature 分成：
到了 Coding Prompt，這四種 Scope 還需要轉成實際的執行規則。
Must Have 是這次要完成的內容。
Nice to Have 可以提供產品背景，但這次不實作。
Future 同樣不實作，而且不能只是為了未來功能，提前增加目前 Must Have 根本不需要的專屬 infrastructure 或 dependency。
Out of Scope 則是明確排除，不能先做一個 Placeholder、Stub 或 Scaffold 放著。
這也讓我重新理解「完成」的意思。
AI 多做三個功能，不一定比較完整。
該做的有做到，而且沒有順手把這次不該做的功能塞進來，才是目前 ClarifyBuild 想要的結果。
這是今天花最多時間整理的問題。
Specification 不可能列出 Coding 過程中的每個技術細節。
像是變數名稱、function 怎麼拆、helper 放在哪裡，通常不需要每件事都回來問使用者。
但下面這些就不一樣：
不同答案會直接改變產品行為。
所以我把 Day 10 的 Inference ≠ Resolved 再往後延伸：
Spec 沒寫，不代表使用者已經授權 AI 決定。
目前 Coding Agent 遇到決策時，會依這個順序判斷：
AI May Decide 表示這類事項可以自行決定；AI Must Ask Before Changing 則保護需要先詢問的產品決策。如果實作時必須補出同類型、但 Spec 還沒有決定的事項，也要先問。如果同一件事同時碰到 delegation 和更嚴格的規則，就採較嚴格的規則。
除了 AI Decision Boundary，目前 v0.1 還有一條更高優先順序的固定規則，就是 Persistence Hard Rule。
今天在檢查規格時，我也發現這一點很容易混在一起。
ClarifyBuild 的資料目前分成不同責任層。
例如：
Input / Interaction State 會保存 ClarifyBuild 自己運作需要的資訊，像是某個 Dimension 的狀態、使用者怎麼完成這個 Decision、Optional Detail 是否曾經跳過，以及哪些內容需要重新 Review。
Canonical Project Model 才保存真正的產品決策，例如 Scope、Feature Specification、Target Project User Flow、Project Constraints、Tech Stack。
目前四層的關係是：
Input / Interaction State
↓
Canonical Project Model
↓
Project Specification
↓
AI Coding Prompt
真正的 Source of Truth 是 Canonical Project Model。
但 Coding Agent 拿到 Prompt 時，不會看到裡面的 Interaction State，也不會直接看到 Canonical Feature Specification。
它看到的是已經 render 完成的 Project Specification，例如：
所以 Prompt 裡的規則也只能要求 Agent 遵守它真的看得到的內容。
不能叫它去查一個根本沒有被放進 Prompt 的內部欄位。
資料保存是今天最典型的案例。
假設某個 Must Have 在實作時確實需要 Persistence，但 Project Specification 沒有決定保存策略。
Coding Agent 很容易選一個自己熟悉的方案：
localStorage、IndexedDB、Supabase……
但資料放在哪裡，可能會影響重新整理後是否保留、資料是否離開瀏覽器，甚至後續是不是需要 Cloud Service。
因此最後我保留一條固定規則：
If persistence is required but no persistence strategy is specified,
stop and ask the user before choosing one.
也就是，只要「確實需要 Persistence，但保存策略還不存在」，一定先問。
這條規則不會因為 Tech Stack 已經交給 AI，或使用者調整一般的 AI Decision Boundary，就跟著消失。
如果 Persistence Decision 已經存在，之後要不要改變它，才回到一般的 AI Decision Boundary 處理。
ClarifyBuild 內部對 Tech Stack 記錄兩種狀態：
specified
ai_delegated
前者代表使用者指定技術，後者代表使用者明確授權 AI 選擇技術。
這些是內部的資料表示。
真正輸出 Project Specification 時，會 render 成 Coding Agent 看得懂的內容，例如：
「使用者指定 React、Vite。」
或：
「使用者明確授權 Coding Agent 在既有限制內選擇合適的技術。」
如果是使用者指定技術，Coding Agent 就不能因為自己比較熟 Vue，直接替換 Framework。
如果使用者明確授權 AI 決定，Agent 則可以直接選，不需要再問一次。
我把後者定義成 Bounded Tech Delegation。
它授權 AI 在既有 Requirement、Scope、Project Constraints、AI Decision Boundary 與 Persistence Hard Rule 之內，替已經確定要做的產品選擇適合的實作技術。
這份授權不會延伸到新增 Authentication、修改 Target Project User Flow，或自行創造新的 Persistence Requirement。
Design Preference 是 Optional Detail，使用者可以不提供。
但沒有 Design Preference，不代表使用者已經授權 AI 任意決定風格。
另一方面，如果 Coding Agent 一看到沒寫風格就停止工作，重新詢問使用者，那 Optional 也失去意義。
所以最後加入了 Baseline Presentation Fallback。
如果 rendered Project Specification 裡有 Design Preferences section，就照裡面的內容執行。
如果沒有，就只使用完成目前 Must Have 所需要的基本呈現，不自行套用任何具名 Design Style，也不額外增加 branding、Dark Mode、特殊 layout 或 animation。
這裡也特別把 Minimal 和 Baseline Presentation 分開。
Minimal 是使用者真的可以選擇的一種 Design Preference。
Baseline Presentation 則只是沒有 Design Preference 時，用來限制 Coding Agent 不要自行發揮過頭的執行方式。
既然 Coding Agent 有時候必須詢問使用者，下一個問題就是：
到底一次要問多少？
如果缺的只是一個 Persistence Decision，Agent 卻一次展開 localStorage、Firebase、Supabase、Cloud Sync、Multi-user、Authentication……
那到了 Coding 階段，又變成重新跑一輪 Requirement Clarification。
所以目前採用 Minimum Necessary Clarification。
只詢問安全繼續實作所需要的最小 Decision。
例如現在真正需要知道的只有：
「重新整理頁面後，資料需不需要保留？」
那就先處理這件事，不提前展開整個未來架構。
ClarifyBuild 一開始就在處理一個問題：
AI 不知道什麼叫完成。
因此 Prompt Output 也需要 Definition of Done。
目前完成代表：
至於 production-ready、SEO、Accessibility、Scalability、Performance、Responsive 等品質要求，只有原本 Project Specification 已經要求時，才會進入完成標準。
這可以避免 Prompt Generator 在最後一刻替專案增加一批新的 Non-functional Requirements。
如果遇到無法安全自行決定的 Product Decision，就使用：
Clarification Needed
內容說明現在需要哪個 Decision、為什麼需要，以及它影響哪個既有 Requirement。
不能先把受影響的部分做完、事後才問；在使用者回答之前，也不能完成依賴這個 Decision 的部分。
如果實作完成，就使用：
Implementation Summary
回報已完成的 Must Have、重要 Technical Decisions、Validation、Scope Check，以及真正存在的 Known Implementation Issues / Deviations。
最後這一項也不能變成新的產品建議區。
不能做到最後又開始推薦：
「之後可以順便加入 Dark Mode。」
完整 Template 雖然不短，但最上層只有兩塊：
AI Coding Prompt
├─ Execution Contract
└─ Authoritative Project Specification
Execution Contract 規範 Coding Agent 怎麼工作。
Authoritative Project Specification 則保存真正的產品內容。
把 Project Specification 組成 Prompt 的 Deterministic Prompt Assembly 只是組裝步驟，不是新的資料層；Coding Agent 則是拿到 Prompt 後才開始工作的 downstream executor。
Prompt Output 定下來後，我把 Day 10 的 Clarification Engine、Day 11 的 Project Spec Schema 和今天的 Prompt Output 放在一起對照。
這個過程找到幾個原本責任不夠清楚的地方：Persistence 在保存策略不存在時應由 Hard Rule 強制詢問；Design Preference 沒有輸出時，應使用 Baseline Presentation Fallback，而不是誤認成 AI delegation；另外 Coding Agent 看不到 Canonical Feature Specification，所以 Prompt 只能引用 rendered Project Specification 裡真的存在的 User Stories、FR、AC 等內容。
這些調整沒有增加新的 Feature，但讓三個階段的責任更清楚，也讓正式開始 Coding 前少留幾個容易被 AI 自行補掉的空白。
今天一開始，我原本把 Prompt Generator 想成：
「把 Spec 改寫成一份更好的 Coding Prompt。」
做到最後，我比較想留下的結論是：
Prompt Generator 最重要的工作，是忠實地把已經釐清好的 Requirement 交給 Coding Agent，再補上最低必要的執行規則。
ClarifyBuild v0.1 因此選擇固定組裝，而不再讓另一個 AI 自由重寫 Specification。
至少在目前這個階段，Prompt Generator 越 deterministic，越能保住前面 Requirement Clarification 的成果。
到目前為止，我花了不少時間在 Clarification、Scope、ClarifyBuild Usage Flow、Specification 與 Prompt Output。
但 ClarifyBuild 自己真正的畫面還沒有開始設計。
接下來要處理的問題會開始變成：
Landing 要放什麼？
Builder 的 Idea Entry、Clarification、Scope Review、Specification Setup 四個 State，要怎麼放在同一個 View？
Dynamic Clarification 一次呈現多少資訊才不會有壓力？
Specification Setup 又要怎麼避免變成另一張巨大的 PRD Form？
Spec Preview 和 Prompt Preview 應該怎麼讓使用者閱讀與操作？
接下來，我要開始把前面這些規格真正變成 Wireframe。
Day 12 完成。
明天見。
iThome鐵人賽
看影片追技術