營運與維護 · 實作指南
檔案已上傳，不等於可以交給 AI 處理
一份設計備忘錄，把接收、檢查和擷取佇列分開。
AAHouse 原創解說影片，採用 AI 輔助概念畫面、合成旁白及原創音樂。
簡體中文普通話逐字稿 · 英文逐字稿 · 台灣華語逐字稿 · 香港粵語逐字稿 · 澳門粵語逐字稿
評審結論：先接收，不等於立即處理
這份設計備忘錄面向一個虛構的美國服務商：客戶提交資料，AI 隨後擷取服務需求。建議把「已收到」與「可以處理」分開，先檢查檔案再排入擷取佇列。重點是上傳入口如何給解析器放行，不是下載連結權限，也不是判斷文件中的指令。本文沒有上傳危險檔案或完成產品安全測試。
原方案：選得到，就送進去
原型常把檔案選擇器當成第一道保證。MDN 明確說明，`accept` 屬性只是幫助使用者選擇類型的提示，不能替代伺服器驗證。[1] 因此，介面上的 PDF 篩選並不能證明收到的內容是可處理的 PDF。業務人員看到「上傳完成」時，也不應誤以為系統已理解檔案。
修改條件：檢查結論必須有範圍
OWASP 建議只接收業務所需類型、限制大小，不信任上傳者提供的內容類型，並採用多層檢查。[2] 這些是基礎依據，不是一個萬能的「安全」標籤。我們建議把結果寫成具體狀態，例如類型檢查通過、解析待執行或檢查失敗，並儲存使用的規則版本。
執行預算：不只看下載大小
即使檔案大小合規，也要給解析步驟明確預算。建議按業務需要限定頁數、影像尺寸、執行時間與重試次數；具體門檻值由樣本和容量測試決定，而不是照抄本文。超限應轉為可解釋的例外狀態，不要讓 AI 反覆嘗試直到佇列被堵住。本文未測出任何通用的最佳門檻值。
客戶體驗：保留下一步，而非死路
客戶提交失敗時，需要知道能做什麼。可提示格式不支援、檔案過大或處理暫時失敗，並提供可行的重新提交方式。不要暴露內部路徑或把所有錯誤寫成「檔案有問題」。對暫時性失敗與確定不支援的檔案分別處理，避免客戶重複提交同一內容卻得到相同的模糊答覆。
複核邊界：人工放行也留證據
人工複核不是把所有檢查關閉。建議顯示失敗原因、允許的補救辦法與複核人員的決定；任何例外只適用於指定檔案和處理目的。保留原檔案識別資訊與後續擷取結果的關聯，避免修訂檔案後仍顯示上一版檢查結論。是否允許例外，應該由當前業務與安全規則決定。
驗收材料：無害樣本與預期結果
驗收包可包含正常文件、錯誤副檔名、空檔案、受密碼保護檔案以及超出約定限制的無害樣本。每項先寫清應接收、拒絕還是轉人工，再核對佇列和介面狀態。不需要惡意酬載來檢查這些狀態轉換；擷取成功率也不能代替入口規則的驗證。
上線條件：讓責任與狀態一致
建議先覆蓋一種常用格式，把支援範圍、預算、例外負責人和測試紀錄寫在同一份交接單。只有約定檢查完成，任務才進入擷取佇列；未解決的狀態應明確可見。以後增加格式或更換解析器，再重跑相同樣本。目標是減少誤解和無效重試，不是宣稱從此沒有檔案風險。
