業務流程 · 實作指南
報價助手可以整理需求，但不能自行決定售價
把產品需求解讀、價格查詢和商業批准分開，再考慮報價自動化。
拆開三種不同工作
假設一家分銷商收到採購查詢，客戶只提供舊款產品名稱。理解需求、找出有效價格，以及批准折扣，其實是三種不同決定。若全部塞進同一段提示，出錯時很難知道是型號配對錯誤，還是商業判斷越權。設計報價助手前，先畫出每項決定的依據、負責人與可接受的例外。
價格只取自有效來源
產品代碼、單位、生效日期和幣別應來自受控目錄。模型可以附上文字依據，提出候選產品，但價格由應用程式向已批准系統查詢。找不到價格或價格過期時，直接標記缺口。看似合理的數字反而更危險，因為它可能在沒有人注意下變成對客戶的承諾，之後很難追回。
流程一覽
輸入整理審核執行
批准的是整份商業版本
草稿應列出數量、交付假設、待確認稅務處理及有效條件，交由員工審核。保存批准者與版本；客戶更改數量時，相關批准應重新確認，而不是靜默改總額。審批工具只能協助交接，誰有折扣權、何時需要主管覆核，仍須由企業明訂，不能交給模型臨場推斷。
刻意測試模糊需求
試點資料要包括停產型號、衝突單位、不同幣別及缺少送貨地點等情況，不能只用最整齊的訂單。比較錯誤產品建議與核對工時，而不只是草稿速度。先採用只產生草稿的模式。助手的價值是讓不確定之處更容易被看見，不是把未確認的內容包裝成漂亮而完整的報價單。
可以立即進行的練習
準備三種草稿：單位缺失、價格過期，以及批准後改數量，請商業負責人指出各應在哪裡停下。通過測試未必是完成報價，也可以是清楚列出未解問題。把它們保留為回歸案例，避免日後改提示時悄悄擴大價格權限。每份草稿都應能說明哪些數字直接取自批准系統、哪些條件仍需確認；若助手自行補單位或沿用失效批准，即使總額看似合理，也不可當作成功輸出。
來源與延伸閱讀
- Building effective agentsBuilding effective agentsAnthropic · 官方文件 ·
- Create and test an approval workflow with Power AutomateCreate and test an approval workflow with Power AutomateMicrosoft Learn · 官方文件 ·
編輯原則
本系列以 AI 輔助原創撰寫，並對照連結的公開來源。實作建議與假設情境屬編輯分析，並非客戶實績。來源發布日期及產品細節可能與本系列整理日期不同。