業務團隊送來一份與客戶成功談成的「v0．初版待釐清」需求文件，主旨是「資料工作區空間」。附件只有一段業務端原話：「客戶可透過自行爬文資料，或是將企業內部資料託管到本平台，選取關注資料後或是每日日報定時匯入等功能，將資料匯入到該工作區空間。」我把這句話讀了三遍，圈出四個名詞——自行爬文資料、企業內部資料託管、選取關注資料、每日日報定時匯入——每一個單獨拿出來都能開一個專案，卻用一句話交代完成，想想都不簡單。

業務端不是在刁難，是在轉述客戶的原話

首先確認一件事：這份文件不是業務端偷懶，而是如實轉述客戶會議記下的重點。客戶想要的，是把「不論資料從哪裡來，取得後都要自己另外整理才能用」這件事變輕鬆；業務端想要的，是把客戶留在產品裡，之後好加賣加值編輯、協作、匯出。兩邊的目標都合理，只是還沒有人把它翻成「可以估工時、可以驗收」的技術描述。需求書自己也承認這一點：「加值」具體包含哪些編輯能力，只寫了「讓客戶可以編輯」；「每日日報」是既有功能還是新功能也留白，真讓人頭大。

我在草稿上劃出四個問號，而不是四個任務

接到這種文件，最容易犯的錯是急著拆成開發工作單：先做爬文、再做託管、再做匯入、再做編輯。盡量不要這樣做，因為每一塊背後都藏著沒回答的問題和大量的自行假設。自行爬文是客戶自己爬完丟結果進來，還是要我們提供爬蟲服務？企業內部資料託管要接哪種格式、要不要專屬儲存空間？「選取關注資料」是單筆勾選、批次選取，還是條件式訂閱？「每日日報定時匯入」的排程能不能讓客戶自己調，失敗了要怎麼通知？這些問題只要有一題答案不同，底層的資料模型與匯入流程就會長得不一樣。先動工，等於是先賭一個答案。

把未知留在檯面上，好過假裝看懂

我把這四個問號整理成一張清單，先不寫技術方案，只寫「這裡還不知道什麼」。這並不是浪費時間，是把後續要做的追問排出順序：哪些空白會決定資料庫要不要拆表，哪些空白只影響資料介接規格，先後順序不一樣，追問的急迫程度也不一樣。需求書裡「權限模型」「資料保留與法規遵循」這類條目，一旦順序排錯，可能到快上線才發現整個儲存架構要重來。

這份 v0 需求書會陪著接下來這一週的文章。從明天開始，我會把這些問號一題一題丟給 ChatGPT，但不是求它替我拍板，而是借助它把散落在文件各處的矛盾攤開、把估不出工時的地方標記出來，最後收斂成一份工程團隊真的能動工的技術規格。今天先讓需求書自己攤開所有沒說清楚的地方，把「看起來合理」跟「已經可以驗收」分開，才是收斂的起點。

小結：先看懂問題的形狀，再談解法

今天沒有寫一行程式，也沒有問 ChatGPT 任何問題。先把業務端的原話、四個未定義名詞與九項待確認事項攤開，確認自己看懂的是「問題的形狀」，不是「答案的形狀」。Day 05 會把這份 v0 需求書實際丟給 ChatGPT，示範怎麼分輪追問，把模糊需求收斂成可以估工時、可以驗收的技術規格。

參考資料

• 資料工作區空間——需求書（v0．初版待釐清）