Day 04 我把「資料工作區空間」這份初版需求的未知攤開，圈出「資料」「選取」「定時匯入」與「編輯」四個名詞，卻找不到能估算工時或驗收的邊界。若直接拆成開發工作單，疑問只會延到串接時處理，今天我實際打開 ChatGPT，把這些問號一題一題丟過去。

ChatGPT 先當探照燈，不當決策者

我不會一開始就請 ChatGPT「產生完整技術規格」。資料不足時，完整往往只是外表。我先分成四類，標出每句需求的狀態，決策仍由負責人處理。

這也呼應 OpenAI 官方提示建議：交代任務邊界與背景，檢查回覆後再補條件。我的做法是每輪只處理一種不確定性。

第一輪：只找缺口，不急著想解法

我先上傳 v0（初版）需求書，限定 ChatGPT 只能依文件內容判讀。Day 05 需求分析提示詞 是三輪完成後使用的完整範本；第一輪只取限制段，不要求決策選項與驗收格式：

找出模糊、缺漏、矛盾及無法估算工時或驗收之處。
不得用常識補寫文件未提供的事實。
所有結論標示狀態並附文件位置；無依據就寫「文件未提供」。

輸出只做訪談清單：資料格式、帳號與工作區共用方式、匯入規模、排程、錯誤處理、編輯能力及法令遵循責任。我逐項回看需求書，刪掉已回答的問題，再把會阻擋估算或造成不同客戶資料混寫的項目排在前面。ChatGPT 擴大檢查範圍，順序仍由團隊判斷。

第二輪：補入證據，也標出新矛盾

第二輪加入示範條件：第一版只處理企業內部資料託管；採多租戶架構，不同客戶的資料必須隔離；每日約 1 TB，資料來源速率約 12 MB/s；欄位包含 title、description、tags、create_time、update_time、create_at、update_at。這些都不是 v0 原有事實。

若 12 MB/s 是可持續的端到端有效速率，且資料串行傳送，以十進位換算，純傳輸也超過 23 小時，幾乎沒有重試空間。兩組建立、更新時間欄位也可能重複。我必須確認速率限制在哪一端，以及兩組時間代表來源或平台時間，不能讓 ChatGPT 自行刪欄位。

第三輪：把候選規則改寫成驗收草案

資訊收斂後，我才請 ChatGPT 用「前提／操作／預期結果」（Given／When／Then）整理驗收條件。v0 尚未定義匯入權限，以下候選規則仍須需求提出單位、技術與品質保證人員確認：

Given 候選規則允許租戶 A 的使用者匯入工作區 W
When 使用者將一筆含有本輪暫定欄位的企業內部資料匯入 W
Then 租戶 A 可以在 W 看見該筆資料
And 租戶 B 無法存取該筆資料
And 原使用者可以重新開啟並編輯該筆資料

我還會追問無權限時的回應、批次部分錯誤的處理，以及重送是否去重。答不出的項目保留「待決策」，不把猜測藏進驗收條件。

小結：好的需求整理，是讓未知有名字

ChatGPT 整理問題，人確認商業規則。資料量、欄位語意與權限沒拍板前，我不會把規格交給開發。Day 06 會沿用企業內部資料匯入需求，讓 ChatGPT 協助畫架構草圖並比較技術方案。

參考資料

• OpenAI：Prompt engineering best practices for ChatGPT
• 資料工作區空間——需求書（v0．初版待釐清）