企業每年可能要處理數百份 RFI（Request for Information）問卷，每一份都是多分頁的 Excel 活頁簿，裡面混著階層式題組、類別中介資料，以及各種不同的作答型態。AWS Machine Learning Blog 在 2026 年 9 月 10 日發布的教學文，把這個痛點拆得很清楚：格式一改，人工抽取、整理、對照的流程就要重跑一次，回應變慢，錯誤也跟著進來。
這篇文章的主體是 Build an end-to-end RFI questionnaire workflow using Amazon Quick Automate，示範如何用 Amazon Quick Automate 加上 Amazon S3，做出一條從讀取到輸出的自動化流程。
這條流程實際上做了什麼
依照 AWS 的說明，整體架構不複雜：把 Amazon Quick Automate 接到存放 RFI 活頁簿的 S3 bucket，建立 automation project，然後用自然語言描述「要讀什麼、怎麼結構化、輸出寫到哪裡」。產出的結果是一份乾淨的 CSV。
AWS 在文中給的 prompt 範例，指定了 connector 名稱、來源檔名與 prefix、要開哪個 sheet、要依編號與縮排辨識主問題與子問題，以及輸出欄位（Serial Number、Category、Question、Response Type）。產生的 workflow 大致分成讀取資料、抽取與轉換、結構化輸出三段，其中子問題會被合併上層脈絡，變成獨立記錄。
這裡有個對產品開發者比較實際的訊號：AWS 明確說這條路徑「常見情境下不需要自訂程式碼」。也就是說，當問卷格式改變時，調整的是自然語言指示，而不是重寫解析邏輯。
部署與權限才是真正的門檻
教學文列出的前置條件包括 Amazon Quick Enterprise 訂閱、與 Quick 應用程式同一個 AWS Region 的 S3 bucket、以及對 IAM role 與 policy 的基本理解。IAM 部分需要一個信任 quicksight.amazonaws.com 的 role，並附上對目標 bucket 的 s3:GetObject、s3:PutObject、s3:ListBucket 權限。
流程本身則走 connector 設定、automation group、project 建立這幾步。值得注意的是驗證與上線的分離：先在 pre-production（development）帳號跑過、確認輸出，再用 Import/Export 匯出驗證過的版本，匯入正式帳號或目標 Region。這種「先驗證再搬移」的做法，比直接在正式環境改流程安全得多。
如果你正在評估這類自動化要落在哪一層，挑選 AI 語音代理平台：先拆解成本與部署層級，再談功能 裡那套「先看部署層級、再看功能」的順序，套用在問卷自動化上同樣成立——connector 與 IAM 邊界沒想清楚，後面的 prompt 再漂亮都跑不動。
幾個還沒被回答的問題
AWS 這篇是操作教學，不是效能報告。文中沒有給出解析準確率、處理一份活頁簿的耗時，也沒有說明當問卷出現合併儲存格、隱藏工作表或非結構化段落時，產生的 workflow 會怎麼反應。這些在真實採購流程裡很常見。
成本方面，文章只指向 Amazon Quick 與 Amazon S3 的定價頁，沒有提供試算。Region 可用性則要另外查 AWS Regions 文件。
實務上的下一步
如果你的團隊每年要回覆大量 RFI，這條流程值得先當成一個小範圍實驗：挑一份格式最亂的活頁簿，照 AWS 的步驟接上 S3，看產出的 CSV 能不能直接被下游團隊使用。真正的驗收標準不是「流程跑起來了」，而是「格式改版時，你只需要改幾句指示」。
反過來說，如果問卷的變異程度高到每次都要重新描述一次邏輯，那省下的可能只是打字時間，而不是協調成本。這一點，AWS 的教學文並沒有給出判準，得靠你自己的資料來驗。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。