Univer AI Agent 整合上線前驗收清單：2026 Mac 瀏覽器回歸

W3C 無障礙指引的焦點順序準則 2.4.3 要求互動元件的焦點順序能保留操作意義；這提醒團隊，畫面看似完成並不代表操作流程已驗收。Univer AI Agent 上線前，應分別驗證文件狀態、Agent 操作邊界、Mac 瀏覽器互動、異常復原與回歸證據；不要只憑演示成功判定可上線。Mac 回歸範圍則應依實際支援的瀏覽器與目標使用者環境界定。W3C 焦點順序準則

這篇適合基於 Univer 開發線上辦公產品、負責 AI Agent 整合驗收的工程師，以及需要覆核 macOS 瀏覽器回歸的 QA 與產品技術負責人。
如果目前只需要 Univer 的安裝或整合教學，這份內容不取代實作指南；它聚焦的是上線前如何證明功能在指定環境中可預期、可追查。

先界定使用情境與驗收邊界

先選出真實使用者會完成的表格、文件或簡報工作，而不是先列一長串抽象功能。每個情境至少要寫明：使用者做了什麼、Agent 被要求做什麼、哪些動作必須由使用者確認，以及完成後要看到什麼結果。

例如，表格情境可以是使用者選取一段資料後，要求 Agent 調整指定儲存格內容或格式；文件情境可以是使用者指定段落，要求 Agent 修改文字。這些只是驗收案例的設計方式，不表示所有此類 Agent 操作都是 Univer 的預設能力。

Univer 官方倉庫及文件可用來確認編輯器提供的功能與擴充方式；表格快速入門和核心功能說明則可協助界定編輯器本身的能力。Univer 官方專案資料、表格快速入門文件、表格核心功能說明。若產品以自訂命令連接外部 Agent，應另外核對團隊的實際實作與命令註冊方式；自訂命令文件說明擴充機制，但不能單獨證明特定 Agent 已具備預期行為。自訂命令擴充文件

注意： 文件能證明產品文件記載的能力與介面，不等於你的 Agent 整合已通過驗收。支援範圍、權限控制和錯誤處理，仍須以實際程式、設定與測試結果為準。

先確認 Agent 操作前後的文件狀態

AI Agent 操作線上表格，如何確認結果正確？

先建立可重現的前置狀態，並保存操作前的儲存格內容、格式、選取範圍與文件儲存狀態。接著執行成功、取消和重複執行等案例；每次都要核對預期結果與實際差異，而不是只看 Agent 回覆「已完成」。

• [ ] 記錄文件識別資訊、目前工作表或區段，以及操作前的可見內容。
• [ ] 對照 Agent 指令，確認實際變更僅落在指定範圍；若涉及格式，也分開檢查值與格式。
• [ ] 使用者取消後，確認尚未執行的變更沒有被套用，並記下畫面與日誌中的取消結果。
• [ ] 重複提交相同要求，檢查是否產生額外列、重複文字或第二次格式變更。
• [ ] 核對畫面狀態與儲存狀態；若產品另有儲存提示或儲存機制，記錄其實際結果，不以畫面更新推定資料已保存。

把操作前後證據放在同一筆測試紀錄中，才能分辨 Agent 回應成功、編輯器畫面更新和資料實際保存是否一致。官方功能文件可協助確認編輯器支援哪些操作，但具體結果仍須由團隊對照整合實作驗證。

再驗證權限、確認與停止行為

AI Agent 整合常見的風險，不只在於結果錯誤，也包括超出授權範圍的操作、危險動作沒有確認機制，以及失敗後仍繼續執行。驗收時要把「產品已實作的防護」和「建議採用的防護設計」分開記錄，避免把設計要求誤寫成既有功能。

• [ ] 用僅允許讀取的身分執行修改要求，確認實際行為符合已設定的權限。
• [ ] 對未授權工作表、文件區段或命令發出操作要求，確認拒絕方式清晰，且不留下部分變更。
• [ ] 對刪除、覆寫等高影響操作，依產品既定流程檢查是否有確認或撤銷機制；若尚未實作，列為風險或缺陷，不要視為通過。
• [ ] 模擬操作中途失敗，確認後續命令是否停止，以及已完成的部分如何呈現。
• [ ] 保存拒絕、確認、停止與失敗的可追查紀錄；對敏感資料，也要依產品的資料處理規則覆核記錄內容。

若整合透過自訂命令執行，應檢查每個命令的可操作範圍與失敗處理，而非只測試 Agent 能否成功呼叫。

Mac 瀏覽器回歸應檢查哪些互動？

在團隊承諾支援的 macOS 瀏覽器與實際部署環境中，逐項核對焦點、鍵盤操作、捲動、彈層和版面。測試記錄要包含實際系統與瀏覽器版本；未測過的版本組合，不應延伸宣稱為相容。

• [ ] 從工具列、編輯區和彈層往返移動焦點，確認焦點位置可見且順序符合操作意圖。W3C 焦點順序準則 2.4.3 可作為檢查焦點流向的參考，而非代替產品自己的驗收標準。
• [ ] 測試產品預期支援的快捷鍵，確認焦點在輸入框、儲存格或彈層時，按鍵不會觸發錯誤區域的動作。
• [ ] 在長文件、長表格與不同視窗尺寸下測試捲動，確認選取內容、工具列和彈層不會因頁面位置變化而失去關聯。
• [ ] 檢查彈層開啟、關閉及重新開啟後的焦點返回位置，並觀察頁面縮放或視窗改變時的版面。
• [ ] 使用實際目標瀏覽器檢查開發者工具回報的錯誤與網頁狀態；Safari 的 Web Inspector 說明可作為檢查網頁的參考。Web Inspector 文件

若使用自動化測試，測試工具文件列出 Chromium、Firefox 與 WebKit 等瀏覽器專案；這些自動化專案的結果不能直接代替實際目標 macOS 瀏覽器的人工或端到端驗證。瀏覽器專案說明 此外，頁面進入背景或恢復顯示時，可檢查 visibilitychange 與 document.hidden 等狀態是否影響任務流程。Page Visibility API 說明

模擬中斷，確認任務可以安全收尾

Univer 整合上線前，怎樣檢查異常復原？

網路中斷、頁面重新整理、重複提交或切換頁面，都可能讓使用者無法判斷 Agent 是否已執行。驗收應逐項模擬這些狀況，並以操作日誌、畫面狀態和文件前後差異作為證據。

• [ ] 在送出前、執行中及完成後分別中斷連線，記錄各階段的提示與文件狀態。
• [ ] 在任務執行期間重新整理頁面，確認重新載入後是否能辨識已完成、未完成或結果不明的操作。
• [ ] 對同一要求連續提交，檢查是否有重複寫入；若系統不能判定安全重試，應呈現明確的待確認狀態。
• [ ] 切換頁面可見性或離開工作區後返回，核對任務是否繼續、停止或需要人工恢復。
• [ ] 在測試紀錄中標明重試是測試框架再次執行案例，還是產品本身重新提交任務，兩者不可混為一談。測試重試機制說明

若使用隔離的測試情境，應確認每個案例的頁面狀態、登入狀態和測試資料不會互相污染；測試上下文文件說明了隔離情境的用途，可用來設計可重複執行的回歸案例。測試上下文隔離說明

用同一組維度判斷演示、腳本與真實回歸

以下比較用於選擇驗收方式，不是宣稱某一種方式足以覆蓋所有產品。對正式上線判斷而言，演示可用於確認流程方向，腳本適合重複檢查明確結果，而目標 Mac 瀏覽器回歸則用來核實實際互動；三者的證據效力應分開記錄。

驗收方式	適合確認的內容	主要盲點	適用判斷
人工演示	流程是否可理解、操作是否符合預期	難以穩定重現中斷、重複提交與細節差異	用於探索情境，不單獨作為上線證據
自動化案例	固定輸入下的狀態、結果與重複回歸	不一定反映實際 Mac 瀏覽器的所有焦點和版面問題	用於可重複執行的功能檢查
目標 Mac 瀏覽器回歸	指定系統、瀏覽器與部署環境中的真實互動	結論只適用於已記錄的環境組合	用於核對正式支援範圍

建立可追溯紀錄，再由團隊訂定通過標準

每個案例都應有唯一識別碼，並保留足夠資訊讓另一位工程師可以重跑。建議記錄：用例編號、目標環境、前置狀態、操作步驟、預期結果、實際結果、證據位置、缺陷連結，以及執行者與執行時間。

• [ ] 記下 macOS、瀏覽器與版本、部署環境及測試帳號權限。
• [ ] 保存操作前後的畫面或文件差異，敏感內容依團隊規範遮蔽。
• [ ] 把預期與實際結果分欄記錄；「Agent 回覆成功」不可代替資料狀態核對。
• [ ] 對每項失敗建立缺陷紀錄，描述重現條件、影響範圍及是否造成資料變更。
• [ ] 編輯器或瀏覽器更新後，重新執行受影響的用例，並在紀錄中註明重新測試範圍。

團隊應按產品風險與支援承諾自行訂定通過標準；在沒有產品要求或風險依據時，不要編造統一的成功率、測試數量或相容性門檻。需要釐清環境或服務範圍時，可先參閱使用與支援資訊，並依專案實際用例安排回歸。

如果目前只靠本機開發環境或短暫演示驗收，可能缺少目標 Mac 瀏覽器中的實際焦點與版面證據、難以重現中斷後的狀態，也不容易讓團隊共用一致的回歸環境。若需要臨時執行真實 Mac 瀏覽器測試，可評估租用 nuvcloud 的 Mac 環境，按支援範圍逐項留下版本與測試結果；若測試將長期、高頻且固定佔用設備，或需要特定實體周邊，則應比較自購 Mac 與租用方式，再透過nuvcloud 服務頁面確認合適的安排。