模糊的 AI 需求最怕的不是功能太少，而是團隊太快進入開發。這次專案真正有價值的第一步，是撤回一次過早的 Build 決定，再把需求收斂成一條能操作、能失敗，也能重新驗證的完整工作流。
這是「AI 內容工作流平台專案拆解」的上篇。這一篇只回答一個問題：怎麼決定什麼值得 Build？ 我把這個判斷拆成三層：先證明問題，再定義完整工作流，最後把「可以用」寫成驗收契約。
Content Workflow Platform 一開始就犯過這個錯誤。題目已經選定，手上也有不少既有文件，看起來似乎只差把功能列出來。可是文件能證明某些流程存在，不能證明使用者真的卡在那裡；選定一個方向，也不代表問題與解法都已經成立。
我後來把三個決策重新拆開：
選定題目 ≠ 問題已驗證 ≠ Build 已獲得批准
如果這三件事混在一起，越快開發，只會越快替未驗證的假設增加成本。
第一層：先證明問題，不讓文件替使用者回答
專案重啟後，我先建立 Evidence Register，把資料分成四類：使用者確認的事實、文件支持的內容、仍待驗證的假設，以及已被使用者修正的方向。
這不是為了增加文件，而是避免證據被混用。例如「現有系統有這個流程」只能描述現況；「未來可能會用到」也只能留在候選範圍。兩者都不能直接變成現在的需求。
重新做 Discovery 後，問題才變得具體：來源散落在不同地方；同一份來源不一定要產生所有輸出；每個輸出需要自己的用途與狀態；使用者真正缺少的是下一個決策與阻塞原因，而不是另一段 AI 生成文字。
產品因此從模糊的「內容工具」，改成一條從來源開始的工作流：
Source
→ Editorial Plan
→ 選擇需要的 Deliverables
→ 分別處理內容與素材
→ Human Review
→ 下一步或等待原因
這個轉換很關鍵。後面要設計的主體不再是生成按鈕，而是資料如何前進、狀態如何改變，以及哪些地方必須停下來等人決定。
第二層：用一條能走完的工作流定義 MVP
當時可以列出的功能很多：來源管理、編輯計畫、不同輸出、素材、審核、日曆、AI、發布與成效追蹤。若每個模組都做一點，最後會得到一組看似完整的畫面，卻沒有任何工作能從頭走到尾。
我最後只保留一條路徑：讓一份真實來源進入系統，形成計畫與獨立輸出，處理必要素材，再走到人工 Review。這才是第一個可驗收的 MVP。
第一版 Lean PRD 因此定義了七組需求。重點不是數量，而是每一組都支撐這條路徑：Source 必須能保存；不同 Deliverable 要獨立前進；缺少素材時要顯示阻塞；Review 要保留版本；Today 則從真實狀態推導下一步。
同時，第一版明確不做：
- 公開帳號系統與多人協作
- 社群 OAuth 與自動發布
- 自動排程與成效 API
- 大型媒體檔案管理
- 尚未被核心流程需要的 dashboard
Non-goals 不是附註，而是用來保護這條工作流。沒有這些界線，任何看似合理的延伸都能把 MVP 拉回功能清單。
第三層：把「可以用」寫成驗收契約
「可以新增來源」不是驗收條件。更完整的寫法是：保存來源不會自動建立 Deliverable；重新載入後仍能開啟；缺少必要欄位時要顯示原因，也不能留下半套資料。
「有審核功能」也不夠。Review 必須對應特定 revision；approve、revise、hold 都要留下紀錄；新的 revision 不能覆蓋舊決定。
這樣寫規格，工程端不必在完成後再猜 PM 說的「可以用」是什麼。自動化測試、瀏覽器操作與 UAT 也能對回同一套條件。
排優先順序還不夠，還要先決定何時停止
這次的實作順序不是按照畫面，而是按照風險：先確認 domain rules 和資料保存，再做獨立 Deliverables，最後才接 Review、Today 與復原流程。
計畫裡也先寫好停止條件。如果 Source／Plan 無法在重新載入後保留，就停止擴張 UI；如果媒體檔案處理超出 metadata scope，就延期，不臨時擴建儲存架構。
停止條件把 scope control 從臨場意志力變成事前規則。壓力出現時，不必重新辯論什麼可以犧牲，也不會用資料安全換功能進度。
Build 通過，不代表產品已經能交付
這次以三日 timebox 完成核心切片，但三天只是專案條件，不是文章的結論。後續仍經過私人模型 live integration、Job lifecycle 修復、題材庫與按鈕問題修正、UX 複驗，以及 Windows exe 封裝。
Build 回答的是設計能否實作；UAT 與 Release 回答的是使用者能否重新啟動產品，並可靠完成工作。兩者混在一起，就會出現「測試都過了，為什麼還不能交付」的落差。
從上篇到下篇：工作流確定後，AI 仍然不是規格
這三層合起來，才回答了「要 Build 什麼」：問題有證據，MVP 有完整路徑，PRD 也能驗收。但只要下一步涉及 AI，還有另一組問題沒有回答：模型讀哪一版資料？一次工作有哪些狀態？失敗後保留什麼？模型結果何時才算人的成果？
這些不是 Discovery 的延伸，而是 AI 系統本身的產品規格。下篇會沿著這個缺口，從資料、執行與責任三個面向，把「串接 AI」改寫成真正能交付的功能。
在進入下篇前，可以先用五個問題檢查上篇的 Build Ready 是否成立：
- 問題是否來自已確認的使用情境，而不是文件或功能想像？
- 最短的端到端工作流是什麼？
- 哪些資料、狀態與人工決策不能省略？
- 每一段如何被測試、重新載入與復原？
- 哪些情況發生時必須停止擴張範圍？
如果這五題還答不清楚，功能排得再完整，也只是比較精緻的猜測。先把「做什麼」定義清楚，才有資格進入下篇，討論「AI 應該怎麼運作」。
下一篇：AI 內容工作流平台專案拆解（下）：PM 如何把模型串接寫成系統規格