先把抱怨轉成可量測的業務目標

直接答案是：訪談的第一題應該是「哪一個決策或作業造成損失」，而不是「想用哪一種 AI」。例如業務說報價很慢，背後可能是品項成本找不到、折扣權限不明，或客戶規格需反覆確認；三種原因所需資料、系統整合與風險完全不同。訪談者應要求受訪者提出最近一次實際案件，而非只討論理想流程。

建議把每個痛點寫成「角色、觸發事件、目前作法、耗時、錯誤後果、預期改變」六欄。以貿易商為例，收到客戶詢價後，由業務從 Excel、ERP 與歷史信件找成本；若要三天才完成報價，便可將 KPI 設為縮短回應時間，而非籠統地要求 AI 自動化。

成功定義必須同時有商業與營運指標。若要建置企業知識庫聊天機器人，除了回答正確率，也要定義可回答的文件範圍、無法確認時的轉人工規則，以及使用者採用率。沒有基準值，就無法判斷 PoC 的改善是否值得投入正式開發。

• 以最近一次真實案件取代抽象需求
• 同時記錄作業時間、錯誤成本與決策責任人
• 把「想要 AI」改寫成可衡量的業務假設

利害關係人衝突要在訪談中攤開處理

直接答案是：需求衝突不能靠會後猜測，必須在訪談紀錄中標示決策權與待確認事項。出資者可能追求投資回收，現場人員在意少輸入資料，IT 重視可維運性，法務則關切個資與跨境傳輸。若只採納職級最高者的意見，系統很容易在上線後遭到第一線繞過。

實務上可建立 Decision Log，逐筆記錄「爭議、選項、決策人、決定日期、依據、影響範圍」。同時建立 Open Questions 清單，例如成本表是否允許模型存取、客戶合約能否作為檢索來源、折扣是否需主管覆核；未確認項目不應被假裝成已定需求。

訪談主持人需要把需求分成必須有、應該有、可延後與不做四類，並要求每項功能對應一個流程問題與衡量方式。這種優先順序管理比「功能清單愈長愈完整」更重要，也能避免 AI 系統廠商在估價時把未定義項目塞進模糊的追加條款。

• 為每項爭議指定最終決策人
• 以 Decision Log 留下決策依據
• 將未解問題列入範圍與風險，而非藏在會議紀錄裡

功能、非功能與限制條件必須一起問

直接答案是：能做什麼只是需求的一部分，AI需求訪談還要問資料、速度、權限、準確性與例外處理。例如客服知識庫不只需要「回答退換貨政策」，還需確認不同門市能否看到不同價格、回答是否要附文件出處、尖峰同時使用人數，以及回答錯誤由誰修正。

非功能需求建議至少包含登入與角色權限、資料保存位置、可用時間、回應延遲、稽核紀錄、備援方式與模型更換策略。對受監管或有商業機密的企業，還要確認錄音是否取得同意、逐字稿保存期限、是否去識別化，以及供應商是否將資料用於模型訓練。

限制條件要明確寫出「不可做什麼」。例如報價系統可協助擷取詢價內容與推薦品項，但高額、低毛利或合約特殊條款的案件，應強制人工核准。這種 Human-in-the-loop 設計可降低 AI 自行推論折扣、誤判單位或套用過期價格所造成的損失。

• 功能需求：使用者要完成的任務
• 非功能需求：安全、速度、權限與維運標準
• 限制條件：不可自動決策的高風險情境

訪談前用資料與問題清單縮小未知範圍

直接答案是：訪談前應先蒐集流程圖、表單、報表、樣本資料與既有規範，讓會議聚焦在決策而非回憶。業務單位可提供近期成功、失單與退單案例；IT 提供系統清單、介接限制與資料欄位；財務則提供成本計算與核准規則。資料不足本身就是需要列管的風險。

問卷適合做前置分流，但不能取代深度訪談。AI 能不能生成 20 題、50 題甚至 100 題問卷，取決於您提供的情境與目標；真正有用的是先用 10 題極簡的線上問卷辨識角色、痛點、常用系統與資料所有權，再對高影響流程安排追問。

訪談邀請應附上目的、使用方式、錄音告知與準備事項。若涉及客戶資料、報價單或人事資訊，應先完成 NDA 與存取控管。訪談者也要預先定義哪些主張需要附證據，例如「每月花很多時間」應補上實際筆數、作業分鐘數或錯誤案例。

• 蒐集真實表單、報價單與例外案件
• 先以短問卷辨識不同角色與議題
• 事先說明錄音、資料用途與保密方式

會中以情境追問，而不是只記錄功能願望

直接答案是：最有效的問題是請受訪者從觸發事件一路演示到完成，而非問「你想要哪些功能」。可從「客戶寄來一封規格不完整的詢價信時，你第一步做什麼？」開始，接著追問查哪些資料、誰能決定、多久要回覆、何時會退件，以及若資料衝突該如何處理。

AI 摘要與逐字稿能降低行政負擔，但不能直接當成需求事實。訪談結束後，主持人應逐條標示「受訪者原話、系統證據、訪談者推論、待確認事項」，避免模型把猜測寫成承諾。尤其在價格、法規、合約與精度門檻上，所有推論都必須由責任人確認。

可將提問分為探索、釐清、驗證三層：探索痛點與目標，釐清資料及例外，最後驗證可接受的結果。若現場主張「AI 自動報價」，就要追問最低毛利、可授權折扣、特殊成本、有效期限與覆核門檻，才能產出可開發的商業規則。

• 要求受訪者演示真實流程與例外案件
• 區分原話、證據、推論與待確認事項
• 從功能願望追問到可接受的輸出與錯誤邊界

會後轉成可測試的設計任務與驗收條件

直接答案是：會後交付物應是經確認的規格與待辦，不是一份沒有責任人的摘要。可將訪談結論整理為使用者故事，例如「身為業務，我要在 CRM 看到引用來源的報價建議，以便在寄出前確認成本依據」，並附上資料來源、權限、例外、驗收條件與優先順序。

一份可用的正式設計任務書 Design Brief 1.0，至少應包含問題陳述、目標 KPI、使用者旅程、資料範圍、整合系統、風險、假設、非目標與驗收方式。此文件要由業務、IT、資安與決策者共同確認，才能成為廠商提案、PoC 測試與後續變更管理的共同基準。

需求確認不是一次性的簽核。曾有需求訪談文章標示 Posted: 2026-10-27，提醒團隊用固定格式保存會議結論；企業更應在每次變更時記錄影響的功能、預算、時程與 KPI。這能避免口頭說「小改一下」最後演變成範圍失控。

• 以使用者故事連結資料、規則與驗收標準
• 用 Design Brief 管理目標、範圍與假設
• 任何變更都要標示對成本、時程與成效的影響

PoC 要驗證假設，不是縮小版正式系統

直接答案是：PoC 的目的在於用最小範圍判斷 Go／No-Go，而不是搶著完成所有功能。需求訪談完成後，團隊應挑一個高價值且資料可取得的流程，例如用歷史銷售與庫存資料驗證需求預測，或用已核准報價單測試文件擷取與品項匹配，而不是一次串接所有 ERP、CRM 與倉儲系統。

好的 PoC 會先寫清楚假設，例如「模型可從既有資料預測某類產品需求，且結果足以協助下單」。接著設定資料期間、樣本量、比較基準、負責人與停損條件。若資料缺漏、需求波動或流程例外過多，也應把「暫不開發」視為有價值的投資判斷。

以實際資料及貼近現場的環境驗證，才能看出模型是否受資料品質、操作步驟與權限限制影響。原型不必華麗，但必須能讓使用者完成一段真實任務，並留下量測紀錄。若只展示泛用模型回答漂亮範例，無法推估正式營運的風險與維護成本。

• 選擇高影響、可取得資料的單一流程
• 先定義假設、基準值與停損條件
• 使用真實資料與真實使用者驗證

成功指標要涵蓋精度、效率、採用與風險

直接答案是：AI PoC 成功不能只看模型準確率，還要看流程是否更快、更安全且真的被使用。以 AI 報價為例，可量測報價完成時間、人工修正率、引用過期資料比例、主管退件率、毛利偏差與業務採用率；以知識庫聊天機器人為例，則可量測有來源回答率、轉人工率與錯誤回答通報率。

公開市場資料曾指出，跨系統操作導致25%的錯漏率，B2B企業平均報價響應時長超24小時，並可能讓40%的詢價因流程冗長而流失。這些數字不能直接套用到每家企業，卻可作為訪談時設計基準量測的提醒：先測自己的現況，再設定具體改善目標。

模型漂移也應納入成功條件。成本表、產品規格、客戶合約與市場價格持續更新時，原本表現良好的流程可能逐漸失準。團隊需要規定監測頻率、重測樣本、資料更新責任人與降級機制，這些正是從 PoC 走向正式營運所需的 LLMOps 能力。

• 效率：處理時間、回覆速度與人工步驟
• 品質：正確率、修正率、毛利與來源可追溯性
• 治理：採用率、權限、異常通報與模型漂移監控

PoC 結束後用證據決定擴大、重做或停止

直接答案是：PoC 結案會議應比較事前 KPI 與實測結果，並明確做出擴大、再次驗證或停止的決策。若模型精度符合門檻但現場不願使用，問題可能是介面、流程責任或教育訓練，而非演算法；若使用者喜歡但資料無法穩定更新，則需先處理資料治理再談擴充。

決策報告應列出已驗證假設、未驗證風險、正式化所需整合、預估維運工作與預算範圍。對內部簽核而言，這比展示畫面更有說服力，因為它能回答「下一筆錢要花在哪裡、由誰負責、若失敗如何停損」。

小規模驗證留下的流程圖、資料字典、提示詞、測試案例與程式碼應可延續使用，避免 PoC 做完就丟棄。想進一步規劃資料、治理與分階段投資，可參考企業 AI 藍圖與 PoC 治理規劃，將單一驗證納入全公司導入路線。

• 以事前 KPI 對照實測結果
• 把未驗證風險列入正式化條件
• 保留設計、測試與資料資產供後續沿用

先看交付物與責任邊界，再看價格高低

直接答案是：AI 顧問 報價是否合理，取決於它是否清楚列出問題診斷、需求定義、PoC、開發與維運的交付物。只寫「導入 AI」「打造 Agent」卻未列資料盤點、訪談場次、原型範圍、教育訓練與驗收方式的提案，即使價格低，也難以比較總成本與責任歸屬。

市場上可見 AI顧問費用約為$3,000~$10,000/小時，這種區間只能當作初步參考，不能取代範圍確認。企業應要求顧問說明每個工作包的工時假設、參與角色、需要客戶提供的資料，以及哪些工作不包含在內，避免把內部配合成本誤認為外包費用。

有些上游工程服務採月費 20 萬日圓起，內容可包含每週定期會議、需求定義、設計文件與示範製作；也有外包開發以啟動費約 300 萬日圓起計價。不同模式沒有絕對優劣，關鍵是企業目前要買的是決策證據、可運作原型，還是可正式上線的完整系統。

• 檢查訪談、資料、原型、驗收與維運是否列入範圍
• 要求揭露工時、前提、排除項目與客戶責任
• 不要將顧問費與正式系統開發費混為一談

選 AI 系統廠商時要驗證訪談與治理能力

直接答案是：可靠的 AI 系統廠商不會只展示模型，而會追問流程、資料品質、例外規則與上線後責任。評選時可要求廠商拿一個匿名情境說明如何從訪談轉成使用者故事、驗收條件、資料欄位與測試案例，藉此辨別對方是否具備上游工程與跨部門溝通能力。

廠商也應說明資料如何進入模型、文件如何切分與更新、回答如何附來源、權限怎麼同步，以及錯誤回報由誰處理。若是企業知識庫聊天機器人，僅承諾「可串接 PDF」遠遠不夠；真正要問的是過期文件、重複版本、機密分級與跨部門權限如何治理。

對於尋找 AI 開發 台北 團隊的企業，地理位置可影響現場訪談與協作速度，但不應是唯一標準。更重要的是對方能否安排顧問、工程師與資料人員共同參與，並在需求變更時維持 Backlog、版本紀錄與可追溯的測試證據。

• 要求示範從需求到驗收的轉譯方法
• 確認資料更新、權限、錯誤處理與維運責任
• 以協作流程與交付品質評估，而非只看展示畫面

總持有成本要把維護與內部投入一起算

直接答案是：AI 報價不能只看初始開發費，還要估算模型用量、雲端、資料更新、資安、教育訓練與內部人力。若系統需要每日同步成本表、定期重建向量索引、監測回答品質與處理例外，這些都是正式營運不可忽略的持續成本。

請廠商在報價單中分開列示一次性費用、每月固定費、依用量變動費、第三方授權費與需求變更的計價規則。尤其模型 API 價格或使用量可能波動，合約應說明預算上限、超額通知與替代模型方案，避免上線後才發現費用無法控制。

採購評估可用三年總持有成本思維：加總建置、營運、維護與內部配合成本，再與節省工時、降低錯誤或提升轉單的預期效益比較。若效益尚未有證據，先以可停損 PoC 驗證，比直接簽下大型開發案更能保護預算與決策品質。

• 拆分一次性、固定、用量與變更費用
• 納入資料治理、資安、維運與內部人力
• 以總持有成本連結可驗證的業務效益

AI 報價的重點是規則可追溯，不是自動產生 PDF

直接答案是：AI 報價系統必須能追溯價格來源、計算版本、折扣權限與人工核准，才適合用於正式業務流程。系統可協助 OCR 擷取詢價、比對 SKU、推薦組合與產生報價草稿，但成本、運費、稅額、匯率與毛利規則應來自受控資料表，而非讓語言模型自行計算。

實務案例中，有一次業務改了數量卻忘了改小計，報價少算了三萬元；同一個案子改了四版，若缺乏版本控制與客戶確認紀錄，就很難判斷哪一版具有法律與商業效力。AI 的價值在於降低重複輸入與提醒異常，不是放大既有流程漏洞。

需求訪談應定義每一種例外：缺成本、特殊折扣、最低訂購量、客製加工、交期衝突與幣別轉換。系統需要在何種條件下阻擋寄送、要求主管核准或改由人工處理，都必須寫進驗收測試；這能防止高風險訂單被錯誤自動化。

• 價格與成本必須來自受控主資料
• 每個報價版本都要可追溯與可還原
• 高金額、低毛利與特殊條款案件應強制覆核

讓 AI業務保有判斷權，而非被黑箱建議取代

直接答案是：AI業務應把 AI 視為準備與檢查助手，最終商業判斷仍由理解客戶與合約的人負責。好的系統會顯示推薦品項、引用過的歷史案例、價格組成與信心不足原因，讓業務能快速確認；不好的系統只給一個總價，使使用者無法說明為何如此報價。

可將工作流設計為「AI 草稿、業務確認、主管核准、寄送追蹤、結果回饋」。例如報價後四十八小時內主動聯繫一次，可成為 CRM 提醒規則；但客戶是否適合追蹤、該談哪些替代方案，仍需由業務依關係與商機判斷。

回饋資料也要分層處理。成交與失單原因、客戶議價內容、最終折扣與毛利，不應未經清理就全部送入模型。企業應指定資料擁有者，並定期審查哪些欄位能用於推薦、哪些只能供稽核，避免機密價格或個資被不當擴散。

• 要求 AI 顯示建議依據與不確定性
• 保留業務確認與主管核准的關卡
• 將成交回饋納入治理，而非無限制餵給模型

正式營運需要監控、變更管理與可信來源

直接答案是：從 PoC 走向正式營運後，企業必須建立資料更新、品質監控、權限稽核與事件處理機制。每次更新提示詞、模型、成本表或檢索文件，都應留下版本、測試範圍、核准者與回復方式。這些紀錄可讓團隊在回答品質下降或報價異常時，快速找出變更來源。

建議每月抽樣檢查 AI 輸出是否引用正確版本、是否遺漏關鍵限制、是否出現未授權的價格建議；對高風險流程可提高抽查頻率。若發生異常，應能立即停用自動寄送、改回人工模式，並通知資料、業務與技術責任人共同處理。

建立制度時，可參考 NIST 的 AI Risk Management Framework、個人資料保護法主管機關指引與 OECD AI Principles 等公開資料，將可信、可解釋與可問責落實到流程。訪談、PoC 與上線營運並非三件分離的事，而是一條持續驗證商業價值與控制風險的管理鏈。

• 每次模型、提示詞與資料更新都要可追溯
• 設定抽樣檢查、異常通報與人工降級機制
• 以公開治理框架補強內控與責任分工

參考來源

NIST AI Risk Management Framework：https://www.nist.gov/itl/ai-risk-management-framework；全國法規資料庫個人資料保護法：https://law.moj.gov.tw/LawClass/LawAll.aspx?pcode=I0050021；OECD AI Principles：https://oecd.ai/en/ai-principles；ISO/IEC 42001 人工智慧管理系統：https://www.iso.org/standard/81230.html。