AI 知識

先把問題講清楚，再讓 AI 幫你整理需求

AI 知識｜SaaS 需求規劃｜2026-09-08

先說結論：不要一開始就叫 AI「幫我寫一份完整需求書」。

比較有用的做法，是先把你已經知道的業務問題、使用者、流程與限制交給 GPT 或 Claude，要求它先找缺口，再把已確認的決策整理成能驗收的條件。最後交給外包團隊的，不該是一百頁看似完整、其實到處由 AI 補猜的文件，而是一份清楚區分「已確認、待確認、第一版不做什麼」的需求草稿。

一份需求書寫得長，不等於可以直接固定報價。真正會改變範圍的，往往是權限、例外流程、資料來源、第三方服務與驗收方式。

先決定：這份文件要幫你做哪個決定？

準備發包時，需求書最重要的任務不是展示你用了多少工具，而是讓所有人回答同一組問題：

  • 第一版要替哪一種使用者解決什麼問題？
  • 這個人從開始到完成，會走過哪些步驟？
  • 哪些事情一定要完成，哪些可以延後？
  • 哪些情境算成功，哪些情境必須被拒絕、提示或交給人工？
  • 還有哪些規則尚未決定，由誰決定？

AI 很適合協助把散亂想法整理成這些問題，但不能代替你決定答案。舉例來說，你沒有說過「免費試用七天」，模型就不該把七天寫成需求；你還沒決定退款規則，它應該留下未決項，而不是幫你發明一套制度。

先準備八項最小輸入

在開啟對話前，先用自己的話寫下以下資料。空白也沒關係，直接標記「未知」比讓模型自行補完好。

  1. 要解決的問題：目前哪一段工作最卡？
  2. 第一個使用者：誰會用？他在什麼情境下使用？
  3. 一條完整流程：從開始、輸入、確認到完成，現在怎麼做？
  4. 成功的樣子：什麼變化可以證明第一版有用？
  5. 現有資產：Excel、Figma、既有網站、API、資料或第三方帳號有哪些？
  6. 限制：預算範圍、時間、平台、不能碰的資料或明確不做的功能。
  7. 資料與權限：哪些人可以看、改、匯出或核准什麼？
  8. 未知項：還沒決定的商業規則、外部依賴與風險。

不要貼入密碼、金鑰、完整正式資料庫、客戶個資或受保密約束的文件。需求整理需要的是資料種類、流程與規則，不是把敏感內容全部交出去。

用五輪對話把想法變成可討論的草稿

第一輪：先叫 AI 問，不要先叫它寫

先限制模型一次只問一個最影響範圍的問題，並說明這個問題會影響什麼決定。這會把「做一個會員系統」變成可討論的細節，例如：會員是個人還是企業帳號？每家公司的人可不可以互相看到訂單？

答不出來時，保留未知，不要逼 AI 猜答案。

第二輪：把答案分成三欄

每輪確認後，請 AI 更新三個區塊：

  • 已確認：發案方已經決定的事實或規則。
  • 待確認：會影響功能、風險或報價，但尚未決定的項目。
  • 候選方案：模型提出、必須由發案方選擇或否決的選項。

這個分類很重要。候選方案不能悄悄長成正式需求。

第三輪：把需求寫成可驗收的行為

需求不要只寫「安全、快速、權限完善」。改成角色、動作、資料邊界與可觀察結果。

以下是虛構教學情境：企業 A 與企業 B 各有管理員，分別管理自己的訂單。

不夠清楚的寫法：

系統要有完善會員權限與資料安全。

可討論的寫法：

R-01：企業 A 的管理員只能讀取、建立與修改企業 A 的訂單。當他以企業 B 的訂單識別碼查詢、匯出或修改時，系統必須拒絕，且不得回傳企業 B 的訂單內容。

驗收可以再寫成：準備 A、B 兩組測試帳號與訂單；A 可以操作 A 的資料，卻無法透過列表、直接網址、API 或匯出取得 B 的資料。至於客服是否需要跨企業協助，仍然標為待確認，而不是讓 AI 自行加上一個全權管理員。

第四輪：專門找失敗與例外

成功畫面通常最好想，也最容易讓需求書失真。請模型為每條核心流程找出至少一個：

  • 正常完成情境。
  • 失敗、取消、重複提交或資料不完整情境。
  • 權限不足或資料不該被看見的情境。

例如「付款成功後可使用」還不夠。付款失敗、重複扣款通知、取消訂閱、退款以及權限何時失效，都可能改變系統範圍。這不表示第一版必須做完所有功能，而是要知道哪些規則尚未被決定。

第五輪：輸出交給廠商討論的版本

最後才請 AI 整理草稿。每一筆需求至少應包含：

  • 需求 ID 與來源。
  • 使用者角色與目標。
  • 前置條件與正常流程。
  • 例外情境。
  • 資料與權限邊界。
  • 驗收條件。
  • 優先順序。
  • 未決事項及確認人。

把「第一版不做什麼」一起交出去。這通常比再加十項功能更能讓討論有效率。

可直接使用的 prompt 框架

以下是奧微整理的教學 prompt，不是任何平台的官方範本。請把方括號換成你的情況；未知項就寫未知。

你是協助發案方整理需求的訪談助手。請用繁體中文。

目標：把以下想法整理成可與開發團隊討論的 SaaS 需求書草稿。

已知資料：
[業務目標、使用者、目前流程、既有系統與資料]

限制：
[預算／時程範圍、平台、明確不做、資料限制；未知請保留未知]

來源標記：
[為每一段已知資料加上 U1、U2……]

工作規則：
1. 先分成「已確認事實」、「待確認問題」與「候選方案」；不得把推測寫成需求。
2. 現在只做需求訪談。每次只問一個最影響範圍的問題，並說明它影響哪個決定；等我回答再繼續。
3. 不替我指定費用、使用人數、效能指標、法規結論或技術架構。
4. 我說「整理草稿」後，才輸出需求表。每筆需包含 ID、來源、角色、目標、前置條件、正常流程、例外、資料／權限、驗收條件、優先序與未決項。
5. 我說「檢查草稿」時，只列矛盾、缺口、沒有來源的假設、不能驗收的句子與最小修正建議；不要偷偷加功能。
6. 所有輸出標示「待人工確認」。資料不足時寫未知，並指出要向誰確認。

接著可以用三個短指令延續同一份文件：

整理草稿：只採用已確認的決策，列出第一版範圍、明確不做項與未決項。
檢查草稿：為每個核心流程找出一個正常、一個失敗與一個權限不足情境；指出哪些句子還不能驗收。
比較修訂：只列出這一版相對上一版的需求增刪、驗收改變、依賴與仍待決策事項；不要估工時。

OpenAI 的文件建議把角色、明確指令、例子與相關 context 分開組織；Anthropic 的文件也建議明確說出輸出格式、順序步驟與貼近實際情境的結構化範例。這正是上面 prompt 把「已確認、待確認、候選方案」分開的原因，而不是要把更多文字塞給模型。

什麼時候還不能請人報固定價？

即使你已經有一份漂亮草稿，遇到下列情況仍應先保留估價邊界：

  • 核心使用者或流程還沒確認。
  • 企業、帳號、角色與資料歸屬還混在一起。
  • 現有資料能否使用、誰有權提供，尚未釐清。
  • 付款、取消、退款、通知或其他第三方流程尚未決定。
  • 驗收只剩「好用、快速、安全」等形容詞，沒有可測情境。
  • 上線、資料移轉、帳號控制權與後續維護責任未被寫出來。

這些不是「文件不夠漂亮」的問題，而是範圍本來還沒決定。AI 可以讓你更早看見缺口，不能把缺口消失。

哪些情況不適合照這套流程做？

如果你連第一個使用者或要解決的問題都還不清楚，先訪談或觀察實際流程，通常比先生成規格書更有價值。

如果需求涉及法規、醫療、金融、資安或重大個資風險，AI 草稿也不能取代適當的專業審查。若你只需要一個現成工具已能處理的穩定流程，也不必為了「做 SaaS」硬做客製開發。

帶著這些資料，才值得開始談外包

第一次和開發團隊討論時，帶上五樣東西就夠了：需求書草稿、第一版不做項、未決問題、現有資產清單，以及你希望如何驗收的例子。這會比「想做一個像某某平台的系統」更容易談出範圍、預算與時程。

如果你已經用 AI 整理出草稿，可以帶著目前確認的流程與未決問題，和奧微討論第一版範圍、現有資產與接下來需要確認的項目。先把問題講清楚，再決定要做什麼。

來源與核對

回文章列表