摘要： AWS Machine Learning Blog在2026年9月10日的教學示範,用Amazon Quick Automate搭配Amazon S3把多分頁RFI活頁簿抽成結構化CSV。流程會以編號與縮排辨識主問題和子問題,將上層脈絡併入子問題後輸出;AWS說常見情境不需要自訂程式碼。但教學未提供解析準確率、耗時或成本試算,合併儲存格與其他非標準格式仍需自行驗證。
企業一年要消化的 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。
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 的教學文沒給判準，只能靠你自己的資料驗證。