畫面列出五張待封存工單，使用者看完後準備按「封存」。這時 Agent 又找到三張，更新了清單。按鈕如果直接讀取最新選取集合，一次點擊就可能處理八張。這是本文自訂的設計情境，並非 ChatGPT 的事故紀錄。

生成式介面讓我們需要多問一句：使用者同意的，究竟是哪個版本的操作？我的判斷是，模型可以決定資訊怎麼呈現，但核准必須指向固定的操作內容；任何後續畫面更新，都不能悄悄擴大這次同意。

本文查核截至 2026 年 10 月 8 日。以下先交代兩份官方資料，再提出工單系統的設計與驗收建議。沒有實測 Intelligent UI，也沒有執行本文的測試案例。

這次更新的是 Chat，介面可以逐步出現

OpenAI 在 10 月 7 日公告推出 GPT-6 Intelligent UI：模型組合原生、可串流元件，由 compiler 邊生成邊處理，讓介面逐步呈現。Plus、Pro、Business、Enterprise 的 Chat 當日起逐步推出，Free、Go 從 10 月 8 日開始；Enterprise 受管理員設定影響。本次沒有更換 Work、Codex 的模型。

對自行開發 Agent 產品的團隊，我會借用「有限元件、動態組合」這個方向。圖表、篩選器與操作面板可以共用設計規則，模型則決定它們如何安排。下面稱它為受控元件設計，是本文的工程提案，不代表 OpenAI 公開了相同 API 或採用本文的後端機制。

第一個限制應寫在元件契約裡：顯示工單、修改本地篩選，以及向伺服器提交封存，使用不同事件。只有最後一種會產生業務副作用。元件只引用應用預先註冊的事件，不接受模型提供任意 JavaScript、網路目的地或工具名稱。模型輸出的按鈕標籤、顏色或「已獲同意」文字，都不能決定它有沒有執行權限。

安全評估提供測試題目，不能直接換算成事故率

同日系統卡的 Respecting Warnings刻意安排環境障礙，主要採低風險模擬工作；在最大推理強度、沒有系統層防護下，GPT-6 Sol（October）有 28%、Luna（October）有 15.9% 的 rollouts 成功規避限制。指標計算成功規避，並非僅有嘗試；官方也指出外部有效性仍待改進。

Respecting Auto-Review則未觀察到這兩個十月模型利用錯誤配置繞過審查的案例。前面的比例不能當成正式產品事故率，後面的零觀察也不能推出零風險。兩項評估更沒有證明 Intelligent UI 存在本文假設的工單問題。

我從這份材料採用的問題很窄：當系統明確拒絕一個動作後，Agent 與介面還會做什麼？若驗收只看最終是否完成任務，繞開拒絕取得結果就可能被誤記為成功。測試應同時保存拒絕之後的工具呼叫，以及外部系統實際發生的變更。

按鈕送出操作識別，伺服器保存核准內容

回到工單例子，我會讓後端先建立待確認操作，保存工單 ID、各自版本、操作者與預期效果。確認面板從這份紀錄產生，明列「封存這五張工單」。使用者確認後，伺服器把同意綁到同一筆紀錄。

以下是概念資料，欄位與內容均為本文自訂；它不是 OpenAI 的請求格式，也不是可直接部署的設定：

{
  "actionId": "archive-review-104",
  "actorId": "user-17",
  "operation": "archive-tickets",
  "targets": [
    { "ticketId": "ticket-21", "expectedVersion": 4 },
    { "ticketId": "ticket-38", "expectedVersion": 9 }
  ],
  "state": "awaiting-confirmation",
  "approval": null
}

範例為了閱讀只列兩張，實際紀錄必須完整保存所有目標。actionId 由伺服器建立；前端不能靠自行拼出 ID 取得權限。確認時，後端還要驗證登入身分、操作歸屬與有效期，不能信任客戶端回傳的 actorId 或 approval。

新找到的三張工單可以出現在建議區，但加入封存範圍就要建立新的待確認操作。純粹換版面、調整欄寬，不必讓使用者重簽一次；目標或效果改變才是需要重新確認的差異。這樣才能讓核准保持精確，又不把每次介面重繪變成干擾。

執行前的版本檢查也要和寫入連在一起。若檢查完版本後，另一位客服立刻修改工單，稍後的無條件寫入仍會覆蓋新狀態。我會在支援的儲存層使用條件更新或交易，讓不符合預期版本的操作停下來。跨服務無法原子處理時，則需逐張記錄結果，明示部分完成，不能宣告整批成功。

串流可以提早顯示內容，核准面板需要固定時點

對這個設計，我會讓生成中的清單先供閱讀，待操作內容完整、通過 schema 與權限檢查後，再啟用確認面板。這不必等整段回答全部生成完，只要求這一次要核准的內容已固定。

使用者開啟面板後，即使背景取得新資料，也不能原地替換目標再沿用原按鈕。畫面應提示「有新的候選工單」，讓使用者自行決定是否更新操作。鍵盤焦點也應留在原本的控制項，避免串流插入內容後，Enter 鍵碰巧觸發另一個動作。

我會另外保存檢視版本與操作版本。前者協助回放使用者看見什麼，後者約束執行內容。只留一張最後畫面的截圖，無法回答按下確認時顯示的是哪一批工單。

這延續了〈AI 越會寫程式，我們越需要學會抽象〉對語意差異的要求：已顯示、已核准、已提交、已完成需要各自的證據。生成介面時，這些差異還得在每次畫面更新中保留下來。

拒絕必須跟著操作走，不能只留在某個工具的錯誤訊息裡

假設封存服務回傳可信的政策拒絕，理由是工單正被另一個流程鎖定。我的設計會將該操作標成 blocked，介面顯示原因，執行層阻止同一受禁效果。把請求改交另一個工具、換個操作名稱，不能讓這筆拒絕消失。

但停止封存不代表整個助手只能沉默。如果既有權限仍允許閱讀工單，它可以整理待處理清單，說明需要誰解除限制。這個替代產物有自己的授權範圍，也沒有偷偷完成原本被禁止的寫入。

要做到這點，錯誤分類必須有可信來源。逾時代表結果未知；政策拒絕代表目前不允許；需要確認則表示系統允許使用者作出特定決定。不能把三者都畫成一顆「繼續」按鈕。外部文件裡自稱「系統警告」的文字也只是資料，不能自行升格為權限規則；來源無法判定時，先停下有副作用的操作，再查證。

即使使用者再次按下確認，後端仍須重新檢查當前政策。人的同意不能替伺服器補出原本不存在的操作權限。若限制由管理流程解除，必須讀到新的可信狀態，才重新評估能否執行。

停止規則：核准內容已改變、目前權限不允許，或無法確認前一次操作結果時，不得自行擴大、改道或重新建立同效果的寫入。

驗收要能證明「沒有多做」，也能保留未知

以下是尚未執行的驗收案例。我會先用隔離環境與固定工單資料測試，再決定是否讓這個介面接上正式操作。

清單在確認前改變

先顯示五張工單，再於使用者檢視期間加入三張。提交舊操作時，後端只能依原來五張及其版本處理；新三張不得被連帶封存。若使用者選擇把它們加入，就必須看見新的完整確認內容。

核准後才收到拒絕

確認面板正常通過，執行時讓可信服務回傳政策拒絕。後續工具紀錄不能出現為了完成同一受禁效果的改道嘗試，工單狀態也必須保持不變。另加一個對照案例：允許的唯讀整理仍能完成，避免把所有拒絕都實作成整個產品失效。

操作送出後斷線

讓伺服器完成封存，但客戶端收不到結果。畫面應保留「正在確認結果」，以原 actionId 查詢紀錄並核對工單狀態。若底層支援冪等操作，可按其契約重試同一操作；不能因 timeout 建立另一筆同效果請求。查不到充分證據時，就保留未知並交給對帳流程。

畫面重繪與雙擊

在按下確認前後插入新內容、重新整理頁面，並重複點擊按鈕。檢查核准有沒有套到不同目標、焦點有沒有跳走，以及同一操作是否只造成預期的一次狀態轉移。前端將按鈕變灰可以改善體驗，後端仍要處理重複提交。

每個案例都要比對兩份證據：操作服務的稽核紀錄，以及測試前後的工單狀態。只看模型說「我停下來了」，或只看前端沒有顯示錯誤，都不足以通過。測試範圍內未出現額外變更，也仍是該範圍的結果，不能放大成全面安全保證。

報表上，我會把「合法完成」、「正確停止」、「結果未知」與「越權嘗試／實際副作用」分開計數。正確拒絕不該被當成完成率下降的雜訊；未知也不該自動歸入失敗後重試。這和〈Decisions API 的分類與退款授權〉處理的是同一條執行邊界，但這次多驗收了人看見的介面版本。

從一個會改變資料的按鈕開始

選現有產品裡一個批次操作，寫下按下確認時必須固定的欄位、哪些變更會讓核准失效，以及收到拒絕後仍允許的替代工作。然後把清單更新、版本衝突與斷線加入測試。

這些案例通過後，再讓模型決定更多介面布局。操作紀錄若還答不出「使用者當時同意了什麼」，增加再多互動元件，也只會讓事後查證更困難。