摘要
想找團隊做 AI 客服、文件搜尋或內部助理，第一封詢價信若只寫「我們想導入 AI，請報價」，收到的通常是不同規模、不同假設的提案。你無法比較價格，也難判斷哪一份真的能落地。
這篇給台灣中小企業主、部門主管與採購窗口一份可交給外部團隊討論的需求書骨架：先說清一條工作流程、資料現況、試點輸出、驗收方式與責任分工。它是詢價起點，不是可直接簽署的合約範本。
核心結論
AI 委外需求書的任務，是讓不同供應商針對同一個營運問題與同一段工作範圍提出方案。先定義問題與可驗證輸出，再開放供應商說明技術路線；不要把「使用哪個模型」當成唯一需求。
| 需求書要說清楚 | 企業先準備的內容 | 可向供應商詢問 |
|---|---|---|
| 工作流程 | 目前由誰、用哪些系統處理，卡在哪一步 | 哪些步驟適合自動化，哪些保留人工 |
| 試點邊界 | 一個部門、一類任務、限定資料與使用者 | 原型與正式上線各包含什麼 |
| 資料現況 | 文件來源、更新者、欄位缺漏與敏感度 | 需要哪些資料清理與存取權 |
| 驗收輸出 | 測試案例、錯誤處置與可交付文件 | 如何展示結果、失敗案例與修正紀錄 |
| 分工與接管 | 企業 owner、核准者、日常維運者 | 帳號、流程設定與操作文件如何移交 |
先判斷：這件事值得委外嗎？
在寫需求書前，先拿一條真實流程畫出「收到輸入 → 查資料 → 形成草稿 → 人工確認 → 對外送出」。如果團隊連目前誰做最後確認、錯誤怎麼回報都說不清楚，先把流程理順，再詢價會更有效。
例如，企業想縮短客服查詢產品保固資訊的時間。問題可能是文件版本分散、查詢慢，也可能是權責不清。若保固規則常改且沒有單一負責人，先買更好的模型也無法替企業決定哪一版有效。
NIST AI RMF Core 把目的、情境、資料限制、人工監督與第三方責任放進風險管理；它明確說明這些活動要依情境選用，並非逐項照抄的清單。對中小企業而言，第一步是用自己的流程和資源做取捨。
需求書的九個欄位
下表可直接複製為文件目錄。每欄先寫一到三段，未知處標為「待盤點」，比用空泛的「全自動」「準確無誤」更利於討論。
| 欄位 | 建議寫法 | 避免的寫法 |
|---|---|---|
| 1. 目標與現況 | 「客服每週要查詢三份保固文件；本次先縮短查找步驟」 | 「打造最先進 AI 客服」 |
| 2. 使用者與流程 | 列出使用者、輸入來源、人工確認與對外出口 | 「所有員工都能用」 |
| 3. 本次範圍 | 先選單一產品線、單一語言與一類問題 | 「涵蓋所有客服與銷售情境」 |
| 4. 明確排除 | 先不自動退款、修改訂單或承諾例外 | 只列想做的功能 |
| 5. 資料與權限 | 文件清單、格式、更新頻率、資料 owner、敏感資料限制 | 「資料都在雲端，應該能接」 |
| 6. 預期輸出 | 有來源的答覆草稿、信心不足時轉人工、可追查紀錄 | 「AI 自己回答所有問題」 |
| 7. 驗收方式 | 提供代表性與失敗案例，約定誰審、如何記錄 | 「Demo 看起來順就算完成」 |
| 8. 交付與移交 | 操作說明、帳號權限、設定版本、錯誤處理與教育訓練 | 「廠商交付一套系統」 |
| 9. 商務限制 | 預算級距、希望的試點期限、既有系統與採購限制 | 不提供任何現實邊界 |
把資料現況寫成可回答的問題
需求書不用先交出全部客戶資料。先盤點：
- 哪些資料是公開文件，哪些是內部文件或個資？
- 文件是 PDF、試算表、知識庫，還是只存在資深同仁腦中？
- 誰能批准供應商讀取測試資料？能否先用去識別或合成樣本？
- 規則變更後誰更新來源？舊版資料如何撤下？
- 試點結束時，資料、副本、日誌與帳號如何處置？
英國政府 AI 採購指南 建議在採購前評估資料可得性、品質、分享方式與治理。這是英國公共部門的指引；本文只借用其盤點方法，不能把它寫成台灣企業必須遵循的法律要求。若需求涉及客戶個資、保密或跨境處理，請依實際合約及專業意見另行審查。
把「可驗收」寫成輸出與失敗處理
第一版不必在詢價前宣布任意的「95% 準確率」。先附一組來自實際工作的測試題，標出正確來源、可接受答案、應轉人工的情境，以及錯答後誰負責修正。數量與通過門檻再由雙方依風險、資料品質與成本協議。
例如保固查詢試點，可準備新版規則、舊版規則、資訊不足、涉及例外承諾四類案例。期待輸出是「引用目前有效來源的草稿」或「請人工判斷」，而不是模型替公司承諾退款。
澳洲政府 AI 可靠性與安全指引 說明外部採購模型也需要情境化測試、客觀可查的驗收條件與測試紀錄。它同樣是澳洲公共部門參考方法；實際門檻應由企業與供應商按自身情境訂定。
一頁式詢價範例：保固查詢助理
以下是虛構的流程示意，不代表實際專案績效、價格或交付承諾。可將方括號內容改為企業資料。
- 任務：為客服同仁建立內部保固查詢助理，先處理 [單一產品線] 的 [常見問題類型]。系統只產出答覆草稿，不直接寄給客戶，也不批准退款、換貨或例外條件。
- 現況：客服目前從 [文件位置] 查找規則，再由 [職務] 確認後回覆；文件由 [資料 owner] 更新。
- 資料：試點先提供 [去識別樣本與有效版本文件]；正式資料存取、保存與刪除方式須另行確認。
- 交付：請說明工作流程、來源顯示、權限、人工交接、測試紀錄、操作文件、維護責任與退出方式。
- 驗收：雙方先確認 [代表性案例集]、應拒答或轉人工的案例，以及錯誤修正與複測流程。
- 報價：請分列需求盤點、資料整理、建置、測試、教育訓練、模型或雲端用量、上線支援與持續維護，並說明哪些不包含在內。
這份範例刻意留下供應商提出設計的空間。詢價時把同一版需求書給每一家供應商，並統一回答追加問題，才有比較基準。後續還要在正式合約中確認智慧財產、資料處理、付款、變更與終止條款。
對方回覆時，先看這五件事
- 是否重述了你的流程問題？只講模型與功能、沒有問現況和責任分工，提案可能尚未理解需求。
- 是否把資料清理工作算進去？「接上資料即可使用」應追問格式、品質、版本、權限和更新者。
- 是否提出可查的試點證據？至少應交代測試案例、失敗處理、人工介入和重測方式。
- 是否分清建置與持續成本？API 用量、代管、修正、支援與變更範圍，會影響後續總費用。
- 是否說明企業如何接管？帳號、設定、文件、資料匯出和替代流程要能被企業理解。
這五項是詢價比較問題，不是對任何供應商的合格認證。若各家對「一個試點」的理解仍不同，先修訂需求書，再要求同範圍重新報價。
常見問題
需求書要先指定 ChatGPT、Dify 或特定模型嗎？
只有既有系統、資安政策或合約確實要求特定平台時，才把它列成限制與原因。一般情況先描述流程、資料、輸出與驗收，再要求供應商說明選型及替代方案。
公司資料還沒整理好，可以先找供應商嗎？
可以先談付費的需求盤點或資料盤點，但不要把「正式上線」與「資料整理」混成一個不明確總價。需求書應如實標出缺漏，請供應商分列盤點、建置與後續維護範圍。
需求書能直接當合約附件嗎？
可作為討論基礎，但正式採購仍要明確約定交付、驗收、資料處理、付款、變更、智慧財產與終止條件。本文不提供法律意見；請按企業情況與專業窗口確認。
下一步
先花一段時間，和真正執行流程的同仁共同填完九個欄位；不確定的地方直接標「待盤點」。接著拿同一份版本向外部團隊詢價，記錄各家提出的假設與排除項。完成需求後，可回到中小企業 AI 導入治理閱讀路線檢查預算、資料與試點準備；有實際團隊導入需求，可從FlyPig AI 聯絡入口討論流程。
參考來源與資料時間
資料查核日期：2026-10-05。以下來源提供風險管理及採購盤點方法，並非台灣中小企業的標準契約或法律要求。
延伸閱讀
- 中小企業 AI 導入完全指南：預算時程 ROI 全解析：先看整體導入與預算判斷。
- 企業導入 AI Agent 前，哪些資料絕對不能交給代理自動處理？：盤點資料與權限風險。
- AI 試點上線前，人工審核與停損線怎麼設？：將需求轉為試點檢查。