[讀者回函]第三次 UI/UX 革命？權限減半，證據加倍

序言：Karpathy 說 Claude Tag 是 LLM UI/UX 的第三次改版。

我的反應比較無趣：共享 Channel、獨立身份、受限權限、操作留痕—這四件事我在審計介面這條線上反覆寫過，最後在一個聊天機器人的產品文件裡看見它們被交付。把同一組規格移到車隊 AI 教練，一線駕駛駁回的誤報才不會碎在個人對話裡，而能升級成會改變門檻的組織證據。

一句話：權限減半，證據加倍。

作者補充：PocketOS 的事後說明我讀了兩次。第一次看技術：staging 憑證不符，Cursor Agent 自己決定「修復」。第二次看權限：那枚 token 本來只管自訂網域，卻過度授權且未回收。九秒，生產庫和 volume 級備份一起消失。

我放下它去翻 GitGuardian State of Secrets Sprawl 2026，想確認這是意外還是常態—2025 年公開 GitHub 偵測到 1,275,105 筆 AI-service secrets。

是常態。

GitGuardian 報告與相關文章把 Agent 寫成受治理的非人類身份：獨立 identity、最小權限、指定擁有者、納入 IAM 審查。讀完我才更確定：Claude Tag 給獨立身份有治理理由；駕駛教練也不能借用主管帳號做事。

Karpathy 的評論句不夠用。可抄的是 Anthropic 公告與 Agent Identity 文件 已經交付的四件事：

1. 同一 Channel 共用一個 Claude；任何人都能接力，不必各自 copy-paste context。

2. 管理員用 Access Bundle 決定每個 Channel 能碰哪些工具與資料。記憶則依頻道類型不同：官方 memory 文件寫明，private channel 的記憶存在該頻道自己的 store；public channels 產生的記憶會在 workspace 層共享—#data-eng 學到的決策，可能在 #analytics 被讀到。

   

3. Channel 內的 Claude 用自己的 service account 行動：Slack 裡是 Claude App，GitHub 裡是 Claude GitHub App，其他系統則是管理員配置的 service account。

4. 管理員可查看 activity log：Claude 做了什麼、誰要求該任務。

Karpathy 描述「持續、非同步、帶組織工具與上下文的實體」—有用，但只是評論。規格在官方文件。邊界也寫清楚：Channel 用組織配置的 agent identity；DM 則回到個人帳號與個人 connectors。共享同事本來就不是全域無條件成立；連記憶也不等於「每個 Channel 各自密封」。

Agent 進組織時，我會問一件事：它能否用自己的身份行動，並讓每次操作回鏈到觸發者、權限與人類 owner。這套 harness 若只服務產出，會把 AI 嵌得更深；誰用同樣機制專門記錄它被駁回的時刻？

作者補充：我第一次意識到「有爭議的判定無處變成組織證據」，是在 AI 委員會當秘書長、處理 IP 原創審查的時候。我問法務：這些灰色地帶的案件要怎麼留下處置軌跡？答案是「目前生成 AI 著作人格還在灰色地帶，有判例再處理」。

現場幾乎沒有第二個人把反對說出口。我當時擔心的不是那個答案不夠快，而是它沒有留下任何可回看的軌跡：日後有人問「為什麼這個案子能過、那個案子不能」，組織只能再靠記憶和立場重演一次爭論。

那之後，「給每位主管一個更聰明的治理 chatbot」這類提案，我都先問同一題：被擱置、被豁免、被推翻的紀錄去哪了？個人助手把誤報、偏差、門檻修改，以及 Cheon 與 Erickson 所稱的 work games—工人能動地玩弄自己在系統中的參與—留在私人歷史；組織沒有共享稽核身份，也沒有把「誰提出、哪個身份執行、誰核准後果」拆開。

一線發現的錯誤進不了組織證據，只能變成各聊各的。

在開任何主動監測之前，Auditor Tag 先過四項最低規格：

這四項的順序就是權力順序：先決定誰看得見，才輪到決定 AI 能不能說話。缺任何一項，保持已觸及。不要先談「AI 會不會主動擋處分」。

作者補充：這不是只有新創會犯的錯。設計研究院管理職務階段，我審過本地化內容運營審查的配置：為了處理特殊對話場景與未成年虛假帳號，預設方案是「新產品同樣需要養帳號，不如讓假帳號苟活」。

我擋下的是把已被污染的 AI NPC 繼續推到用戶面前；我放行的是小範圍測試，並要求預留降版本回滾。

理由沒有那麼高尚：時間壓力，上游已簽。結果是可預見、也原本可以避免的社交與輿論壓力。那次讓我學到：有回滾，不等於有問責；能退回上一版，不代表組織知道誰批准了那條規則、為什麼批准、又是誰應該在問題出現時叫停。

主動程度必須等於權限升級—否則你只是把 ambient 監測裝進治理 Channel。Claude Tag 已有被標記、排程任務與可選 ambient 主動追蹤；下面三種模式是我對 Claude Tag 的轉譯，Anthropic 並未交付這套稽核配置。

攔截模式列出的禁區，不是理論裝飾；Amazon Flex 的案例已證明，評分、申訴與實質救濟一旦斷開，系統可以把風險判定變成無法抵抗的管理命令。

「有評分＋可申訴」不自動等於 contestability。Bloomberg 2021 報導至少兩個現場：Stephen Normandin 被自動系統停用，不可控因素包括鎖住的公寓大門與 Amazon locker 故障，進入仲裁還要自付約 USD 200；Neddra Lira（德州、42 歲校車司機）則是發現輪胎上有釘子才把包裹退回站點，評分從 Great 掉到 At Risk，約六週才恢復。

前員工證詞更直白：決定信任演算法，往往比付錢請人調查誤解僱更便宜—只要駕駛好替換；客服端是「數十名少受訓練的兼職季節工」。

對上數百萬駕駛，Amazon 發言人 Kate Kudrna 則回應稱已投資可見度與申訴調查，並否認這代表多數司機經驗。兩造打架本身就是設計訊號。我只取一條判準：異議入口若沒有人類覆核與可負擔救濟，就會變成假通道。

把「常駐協作介面＋獨立身份＋受限權限＋異議聚合」合起來，就是本篇唯一新詞：Org-level Audit Harness。

它長駐組織協作面，專門記錄與質疑 AI 決策；預設禁止再養一層同樣不可稽核的數位同事。

辦公室和駕駛環境看起來是兩個世界：一邊是在 Slack 裡 assign PR，一邊是在高速公路入口被鏡頭喊「跟車太近」。

對治理線來說，它們其實共用一條鏈：誰發出指令、誰執行、誰可以說「不」、誰最後要負責。

在辦公室，這個問題這樣表現：Claude GitHub App 建立 PR，可以留下完整身份鏈—哪個 Channel 的誰觸發、Claude 用哪個 service account 動手、哪個 reviewer 接球。最壞情況是 Claude 多開一個 PR，reviewer 可以一句「關掉」，錯誤就停在畫面上。

在駕駛座，它變成這個樣子：駕駛每天收到的不是 PR，而是語音警示、扣分與強制教練作業。如果 AI 錯判一次「未完全停車」，那一次扣分是直接寫進安全分數，還可能被拉進年度績效或保險保費。公開的產品頁與 Help Center 通常看不到「誰核准這條規則上線」。

前者錯一次，通常是 reviewer 多花五分鐘。

後者錯一次，可能是一筆扣分、一場約談，或一項日後很難從績效紀錄拿掉的註記。這就是序言那句在駕駛座的壓力測試：權限減半，證據加倍。

這裡的「說不」不是讓駕駛自行關掉即時安全提醒。它是指：事件能被標記為誤判或情境例外；這個標記有具名處理者與時限；在異議未結案前，事件不得自動流入獎金、績效或處分。

回想我有鄰居做 Uber 補貼家用，提供同一條鏈的現場感：平台要求額外作業，派單卻愈來愈遠，又幾乎不可拒單。

我沒有資格替平台下法律歧視裁決；它只說明拒單權一被抽走，警示與作業就會變成匿名命令。

車隊 AI 教練也卡在同一處：系統給你提示、分數、作業；你能否說「不」、誰決定後果，才是治理問題。

駕駛教練需要同一種身份鏈，但規格更嚴：每則決策收據/憑證 要顯示觸發者、資料範圍、規則版本與人類車主/駕駛；hold 只能暫停用途，維持／推翻／解除由具名主管雙簽；Auditor 只讀事件與異議，不得寫入 KPI、人事、獎金或處分。因為駕駛座的錯誤，停不住在畫面上。

品類現況也要寫準—功能不是沒有，缺的是買方可控的稽核層。

• Motive 已有 AI avatar 教練，但公開材料仍是行銷語言，未見 audit trail 表述。

• Netradyne 的 Driver Dispute，是品類裡最接近 HCI「可爭議性」的案例。駕駛在 Driver App 或入口網站發現被判定的警示後，可以主動提出爭議；安全管理者收到通知，再就該事件與駕駛討論。產品並把這項功能放進 DriverStars、Driver Streaks 等正向強化機制的同一次更新中。

  這件事的重要性，不在於系統會不會偶爾錯，而在於它承認：任何安全事件都不是單純的模型輸出；它可能成為對駕駛能力、信用、獎勵與職涯產生後果的管理主張。

  從 HCI 視角，它至少做對三件事：把駕駛從被動受評者變成可提交反證的參與者；讓申訴進入正式工作流，而不是要求駕駛私下找主管辯解；讓系統錯誤成為可被記錄的互動事件，而非「個別使用者抱怨」。
  

  但它還不是完整 auditing agent。

  成熟版本應自動彙整申訴後果：哪類事件最常被推翻、哪個車型／班次誤報最多、哪一版模型改動後異議率升高、主管是否在合理時間內處理異議。沒有這些聚合能力，Driver Dispute 只是客服管道；有了它，才會成為校準演算法管理的治理迴路。

• Lytx 證明人工驗證能在規模化影像系統中運作：低風險進 Self-Coaching，高風險／重複事件留給主管；疲勞偵測另保留 professional review。這可被稱作 auditing-as-a-service，但有一個關鍵限制：稽核權仍在供應商—誰要覆核、審查標準、證據門檻與分類字典，多半由供應商決定。

  客戶或駕駛通常看見結果與片段，不一定看得到判準、覆核者分歧或判定不確定性。Lytx 解的是「假陽性太多，主管無法工作」；它還沒完整解決「供應商定義的安全真相，如何被組織和被評估者挑戰」。

• Samsara 的分流最接近 agentic audit workflow：AI 檢視、分流與排序；低風險給駕駛 self-review；高風險或重複升級主管。

  但「異議」的權力主體要寫準。Driver App 的事件與分數說明寫的是：若管理員啟用（If enabled by your fleet administrator），駕駛可 request manager follow-up；同頁還要求「You must fully view every event before acknowledgment is available.」換句話說，駕駛端發得出申訴訊號，前提是管理端先開開關，而且得先看完事件。

  真正能把超速從分數拿掉的，是另一條後台路徑：Excuse or Unexcuse Driver Speeding—fleet Overview → Trip History → 速度圖上按 Excuse，操作者是管理員，不是駕駛。連號稱有異議入口的那家，推翻分數的權力仍在另一端。

  這套流程的重心仍是效率：減少人工看片 → 更快教練 → 降低風險。

  真正的 auditing agent 會再加一條治理流程：監測分級結果 → 發現異常／偏差 → 暫停或標記高影響用法 → 要求人類覆核 → 留下門檻與處置變更紀錄。

  差異在於第一條問「誰現在要被教練？」；第二條問「這套教練系統是否正在對某些人不公平、過度干預，或誤把代理指標當結果？」

同一家供應商的兩個官方案例，證明的還是兩種不同的東西。GardaWorld 官方明確歸因車內教練：超速 −74%、跟車過近 −67%、未完全停車 −25%—全是被鏡頭偵測的行為。TEAMS Transport 則給出保險理賠 −39%、年省 $1M+ 的成果數字，但歸因寫的是 Asset Gateway、photo-enabled DVIR 與派遣整合，全文未提 Driver Coaching。

教練功能能證明「被偵測的行為變少了」；能證明「理賠變少」的那個案例，歸因裡沒有教練。

儀表板上的 safety score，也分不清「真的變安全」與「學會不被鏡頭抓到」—後者正是 work games 的教科書場景。這不是主張教練無效；兩案規模、場域也不可硬比。它只證明：行銷頁主打的能力，與成果指標的官方歸因，不在同一個案例上。

反方先贏一句：車內 AI 教練處理的是高風險物理工作。

一位安全主管真正害怕的，不是少一張 dashboard；而是昨天被忽略的一次疲勞警示，明天可能變成一場可避免的事故。

因此問題從來不是「每一則警示要不要先同意」，而是「哪一種警示可即時介入，哪一種後果必須在證據與異議完成前暫停」。

即時提示、低風險自我教練與高風險主管升級，是必要的規模化手段；把每筆警示都送正式聽證，會延誤真風險。

Fonseca 與 Ferreira 在 Applied Sciences 2025 系統回顧（40 篇、2009–2024）整理的重點其實很白話：車載監控確實常能把「被鏡頭看到的危險動作」壓下去，但假警報一多，駕駛會先煩、再不信，最後乾脆關掉或忽略系統。

這篇是我目前手上最強的綜述之一；它自己也寫明：未做正式偏誤風險評估，證據地理集中在高收入地區。整篇我在說「證據不足就不能進處分」—連這篇最強文獻都自承證據品質有限。

另一篇更直接：Shao 等人的危化品卡車 ADAS 研究盯的是前向碰撞警示（FCW）。白話說就是：系統若先吵過一堆「沒必要的警報」—誤報、或技術上沒錯但讓人覺得煩的警示—下一次真的該踩煞車時，駕駛會反應得更慢。

公開摘要層能確認的方向是：先前的負面警示會拉長後續正確警示的反應時間；車速與駕駛年齡也會牽動警覺度—例如車速較低、年長駕駛，反應傾向更慢。

翻譯成採購語言：警報不是愈多愈安全；錯的、煩的警報，會把下一次正確警報變鈍。這支持「即時安全介入要準」，同時更不支持「把高爭議、證據不足的事件直接寫進績效」—因為你懲罰的，可能是一個已經被假警報訓練成反應變慢的人。

邊界寫死：低影響提醒可自動化；任何會影響績效、獎金、保險或處分的事件，必須有個案理由、人工覆核與可追蹤異議。

先別抄全域 Context。共享 Channel 上下文推到治理與勞資場景，風險立刻升高。Claude Tag 假設把選定 Channel 變成 Agent 可用上下文是好事；IM 裡卻可能有健康狀況、工會討論、對主管的抱怨。

任務期間可讀，仍須另核長期記憶與績效用途。更糟的是：若治理討論落在 public channel，依官方 memory 規則，筆記可能進 workspace 共享記憶，跨頻道被讀到。

可改成：

• 明確劃出合法 Channel 與 no-go 區域。

• 短期任務記憶與跨用例長期記憶分開核准。

• 對員工明說 Agent 在這個 Channel 能看到什麼、看不到什麼，並做抽查。

若部署落在北美如加拿大，會被先問P-39.1 的必要性（§5）、用途限制（§12）與 EFVP（§3.3）。

只有決定完全由自動化處理產生時，才直接進 §12.1 的告知與真人覆核義務。攝影機看臉也不自動等於身份生物辨識：狀態／行為推論仍是敏感個資問題；只有建立可持續確認身份的生物特徵模板，才進一步觸發生物辨識專門規則。未查明實際部署前，別寫成個案違法裁決。

第二件：別把「Agent 變團隊同事」當成治理藉口。

技術身份讓操作可歸因；它不讓 Agent 成為責任主體。「Claude 建議這樣做」不能取代「哪位主管決定把建議接上處分」。

事件紀錄裡的 responsible_owner 不能填 Auditor，必須填具名主管或正式治理角色。

企業通常在兩個壞選項之間搖擺。

每一步要人工批准：安全，但 Agent 退化成昂貴的表單生成器。

端到端自動化：有效率，但把不可預測的模型行為接上真實系統。

正確問題不是「要不要 human-in-the-loop」，而是：哪一種行動、在什麼情境、跨過哪個影響門檻後，必須由哪個人介入？

這張表跟前面的「說不」是同一條設計：即時安全提醒可以自動；高影響後果不能自動滑進去。NIST AI RMF Generative AI Profile 把人機配置、資料隱私、資安、偏誤與供應鏈放進完整生命週期；它提醒的重點是：人可能過度依賴 AI、把自信的輸出誤認為可靠證據。Agent 一旦握有工具權限，這個風險會放大。

企業常說「我們有 log」。實際上往往只有：使用者輸入、最後回答、成功或失敗的 API 呼叫。

要記的不是模型私密 chain-of-thought，而是可外部驗證的決策與執行證據：Agent ID、版本、擁有者與業務目的；發起人、委派鏈與當次授權範圍；資料來源、時間戳與敏感性標記；工具呼叫、參數、成功／失敗與副作用；政策檢查、例外與批准紀錄；結果是否被撤回、覆核或造成 incident。

這正是 auditing agent 的位置：它不替業務 agent 做決策；它觀察此 agent 是否越權、是否出現異常工具序列、是否反覆被人撤銷、是否把錯誤擴散至下游系統。

組織瓶頸通常比技術更難。最大的治理缺口往往是決策權不清，不是缺少 policy 文件。

IT 管模型平台；資安管權限；法務關心責任；資料團隊管來源；業務單位擁有工作流；真正承受錯誤後果的一線人員，常常最後才被納入。結果就是 everyone consulted, nobody accountable。

每個 agent 至少要有五種責任：

• Business owner：定義可接受的效益與風險。

• Technical owner：管理模型、工具、版本與變更。

• Data owner：批准資料範圍、品質與保留期限。

• Risk owner：定義 action threshold、例外與事故升級。

• Human escalation owner：在高風險或衝突時，真的有權叫停。

沒有這五種責任，AI 委員會很容易只是一個把事故轉寄到不同信箱的儀式。這也接回前面那則摩擦：有回滾，不等於有叫停的人。

我手上這套五個字母，其實換過問題。

最早寫 AIPET，問的是產品面：Agent 能做多大、互動怎麼接、隱私怎麼嵌進當下、體驗會不會斷、信任怎麼養—那時候的拆法比較像設計評分尺，也用在 Salient 那類現場幫人畫能力邊界。

後來不同產業的AI 轉型諮詢，進入組織診斷，我發現卡住的往往不是「介面好不好用」，而是：出事誰扛、哪些人被算進去、能不能解釋、能不能撤回。字母還叫 AIPET，但 A 從 Accountability 換成 Agency，E 從 Experience 換成 Explainability；中間多了 Inclusiveness—同一個分數，對不同班次、車型、族群是不是同一把尺。

這篇再往前走一步。

下面不是再畫一張雷達圖給你看分數高低。

是把那五維壓成每一筆事件都要填的欄位：代理範圍與自治層級、分組基線、用途邊界、個案理由、異議主人與回寫—填不出來就回退。誰可以把代理權降回去，必須寫進格子裡；只寫在原則文件上不夠。

這張卡可以直接丟進 RFP、Slack／Teams Agent 設定、試點驗收或產品 PRD。抽掉 Samsara／Claude 品牌名，欄位仍成立。

抽掉品牌名欄位仍成立—我查到的公開 Help Center 與產品頁，尚未見任何一家同時公開異議率、推翻率與門檻回寫版本。卡片成立，仍不代表 Agent 有資格主動攔截。必須從 mention-only 逐級證明。