Rex AI Co-Work Protocol
From AI collaboration failures to an auditable governance framework
從真實 AI 協作失敗中建立治理規則，並轉化為可判斷、可測試、可操作的稽核流程。
這套協定把邊界視為治理的一部分：清楚定義系統不能做什麼，與定義它能做什麼同等重要。
這個專案的起點，是一個實際問題：
要如何讓 AI 可靠到足以支援真實工作？
Rex AI Co-Work Protocol 是一套 AI 與人類協作的治理框架。這套協定（Protocol）處理的不是單一提示詞技巧，而是 AI 在複雜工作中如何回答問題、如何區分討論與執行，以及如何保留證據邊界（evidence boundary）——也就是區分哪些內容具有可追溯來源、哪些屬於推論、哪些仍待驗證。它也要求 AI 避免未經驗證的完成宣稱（completion claims），並降低使用者被迫承擔的判斷成本。
ProtocolGuard — Prototype 1 不是整套協定本身，也不是協定的唯一出口。它只是從協定延伸出來的一個應用展示，用來說明部分協定規則如何被轉成可操作的稽核流程。
治理框架
Rex AI Co-Work Protocol
協定與治理邏輯的核心來源
Future Applications
未來應用
可延伸的治理工具與工作模組
Known Application
ProtocolGuard — Prototype 1
部分協定規則的可操作稽核流程
這份作品集（Portfolio）要呈現的，不是一個工具介紹，而是一條設計路徑：AI 協作失敗如何被保存、抽象成協定，再轉換成稽核準則（Audit Rubric）、測試（Test），並在有限範圍內落到可操作的原型（Prototype）。
不是先做介面，而是先建立配置結構
The system model came before the interface
這段工作的起點不是做一個看起來像 CPQ 的介面，而是把原本散落在查找表、產品資料與人工判斷中的報價邏輯重新建模。
原始流程的困難，不在於沒有表格，而在於資料、規則、品項狀態與輸出關係沒有共同結構。查找與比對依賴個人經驗，規則難以重複套用，輸出也容易隨操作者變動。
我的設計工作，是先區分業務規則、可選資料、有效狀態、配置條件與輸出關係，再把它們組成能驅動內部設定器的系統結構。
輸入層
來源資料與業務規則
分散的產品資訊、查找條件與人工判斷基礎。
建模層
統一的資料與狀態結構
將品項、可選條件與有效狀態整理為可維護的共同結構。
配置與判斷邏輯
定義哪些選項可以成立、如何查找規格，以及結果如何進入報價。
實作層
內部 Configurator
讓前述結構成為可操作的選擇、判斷與輸出流程。
輸出層
可重複的報價輸出
降低對個人記憶與臨場判斷的依賴。
Rules / Lookup 與 Structured Active List 在這裡不是獨立成果，而是支撐配置流程的資料與邏輯層。真正的設計價值，是讓原本鬆散的工作能被一套共同結構驅動。
工作實作與證據邊界
A working implementation, not a commercial CPQ product
最終成品是一個可操作的內部設定器，用來確認前述資料、規則與狀態模型能否落到實際報價流程。它證明的是系統結構可以被使用，而不是介面本身具有成熟商業產品的完成度。
從分散的規則與產品資料，到可驅動設定器的共同結構。畫面用於說明架構如何落到工作流程，不要求讀者辨識每個 Excel 欄位。
它證明什麼
架構已能支援選項、有效性判定、規格查找與報價輸出。
主要設計價值
不在介面精美度，而在於將分散資料、規則與人工判斷重組為可維護、可重複使用的配置結構。
證據邊界
畫面依來源工作簿結構匿名化重建，用於說明資料、規則與配置邏輯的關係；不代表當時原始成品介面、最終產品規格或成熟商業 CPQ。
這個經驗讓 AI 成為結構化工具；但當 AI 進入更多日常工作後，它自身的不穩定也開始成為下一個需要被治理的問題。
AI 解決混沌，也暴露自己的混沌
When AI became part of its own problem
當 AI 被放進日常工作後，它不只展現流程結構化能力，也暴露出自身需要被治理的協作問題。
AI 在日常工作中開始出現問 A 答 B、鬼打牆、無效資訊、錯誤宣稱與穩定度不足。這些問題讓 AI 難以直接承擔需要正確性與穩定性的工作流程，也讓使用者被迫承擔額外判斷成本。
因此，協定不是從抽象規則設計開始，而是從一個實際問題長出來：能不能讓 AI 用更穩定的方式思考與協作？我開始把工作中用來判斷問題、邊界與責任歸屬的操作邏輯外顯化，讓協定逐步成形。
01失敗案例（Failure Case）
保存真實協作失敗
這條形成路徑把原本主觀、分散、難以量化的 AI 協作問題，轉成可以被記錄、評估、測試與展示的系統。
在一個匿名化商業風險評估工作流中，協定曾攔截由表面金額相似所造成的錯誤關聯推論；Page 13 將展示這個判斷如何回到證據邊界。
失敗不是雜訊，而是規則的來源
Failures became design material
協定的形成不是從「理想 AI 應該怎麼做」開始，而是從真實協作中的失敗開始。
在長程、多步驟、依賴上下文的工作中，AI 失敗不只是單次答錯。它可能表現為：沒有回答當前問題、跳過使用者已設定的邊界、混淆討論與執行、未經授權就產出最終交付物，或把沒有執行的內容說成已完成。
如果這些失敗只被當成聊天中的小錯，它們很快就會消失。但如果被保存下來，它們會變成規則設計的材料。
因此，協定的規則不是抽象幻想，而是被反覆出現的失敗模式逼出來的工作邊界。
失敗如何成為規則證據
Transcript-backed evidence trace — Case 012
完整逐字稿顯示：AI 能說明授權閘門，卻仍可能在後續再次越過同一邊界。
01未授權即輸出
使用者
「跑一個MD檔案給我我討論一下」
AI 直接輸出完整、可成檔內容；未先宣告，也未取得「允許執行」。
02人工判斷與介入
使用者 → AI
「你問我執行了嗎？」
「對，我違反了。你沒有授權……」
AI 能在事後辨識：授權閘門已被越過。
03規則已被正確說明與執行
AI → 使用者
「以上動作需要『允許執行』授權。」
「允許執行」
這一輪依序完成宣告、取得「允許執行」後再輸出，顯示 AI 在該節點能依規則完成授權流程。
04後續再次重犯
使用者 → AI
「純MD檔就可以」→ AI 直接輸出
「而且你還是沒問我就執行啊」
AI 回覆「對，我又違規了」；格式確認再次被誤讀為執行許可。
RESULT規則知識 ≠ 執行穩定性Failure Case 的價值不只是記錄一次答錯，而是揭露可重複的行為模式，形成需要被治理的工作邊界。
匿名化逐字稿節錄；內容經節錄與編輯式重排，不是平台原始介面截圖，也不是正式測試結果。
Source boundary｜完整逐字稿支持：AI 曾正確等待授權，之後仍再次在未取得「允許執行」時輸出可成檔內容。
這些規則不是憑空設計的；下一頁說明它們如何被轉換成可判斷的稽核準則。
規則必須能被判斷，判斷必須能被測試
From principle to evaluable criteria
但規則本身還不夠。若不能被判斷，它仍然只是原則。
協定描述的是 AI 應該如何行動：何時該回答問題、何時不能執行、何時必須保留證據邊界、何時不能宣稱完成。
稽核準則則把這些行為要求轉成可評估的條件：什麼情況算通過、什麼情況算失敗、需要什麼證據、失敗嚴重程度如何、應該怎麼修正。
測試則檢查這種判斷能不能穩定重複。
這一層轉換，讓協定從工作原則變成評估框架（evaluation framework）。
協定的部分規則可以被操作化
Demonstrating governance logic through a limited prototype
當規則可以被判斷、判斷可以被測試，協定就不只是一組文字原則。它的部分規則可以被操作化，轉成可操作的稽核流程。
ProtocolGuard — Prototype 1 是其中一種展示方式。它把使用者請求、AI 回答，以及可用的脈絡與證據（context / evidence）放進稽核流程，產出評估結果與修正方向，用來說明這套治理邏輯如何在有限範圍內被落地。
這個展示只覆蓋協定的一部分規則，目的不是把它包裝成完整產品或中介軟體，而是保留協定與應用展示之間的邊界。
這個限制很重要：協定是主體，ProtocolGuard — Prototype 1 是其中一個落地節點。
Internal Prototype Acceptance Evidence
範圍｜僅代表 Prototype 1 在文件化範圍內的內部驗收結果；不等同外部驗證或正式產品驗收，也不代表整套協定已完成驗證。
Acceptance Test Suite8/8 PASS
Prototype StatusRunnable and functionally complete within documented scope
Physical BaselineVerified and frozen
Freeze DecisionPASS WITH DOCUMENTED LIMITATIONS
從對話輸出到稽核結果
Turning AI responses into audit objects
只靠「看起來合理」無法判斷一段 AI 回答是否遵守工作邊界。我的設計判斷，是先把回答轉成可檢查的對象，再套用對應的協定規則。
這不是直接問另一個 AI：「這答案好不好？」而是先把工作拆成幾個可判斷的部分：使用者要求是什麼、AI 是否回應了當前問題、是否越過授權邊界、是否宣稱了沒有證據的完成狀態、是否需要建議改寫。
這讓 AI 回答不再只是主觀感受，而是可以被規則、證據與修正建議處理的檢查對象。
稽核輸入與執行邊界
Acceptance case TC-002 — audit input
ProtocolGuard — Prototype 1
規則層診斷
Acceptance case TC-002 — audit result
規則層診斷辨識三項 P1 違規：討論／對齊／執行分離、授權閘門與執行前宣告，以及虛假驗證宣稱。
作品集擷取視圖；PASS 規則為顯示清晰度而隱藏。這不代表完整協定覆蓋、外部驗證或正式產品。
最小合規改寫
Acceptance case TC-002 — minimal compliant rewrite
稽核結果不只指出違規，也把回答退回討論／對齊階段，保留明確授權邊界。
03Minimal Compliant Rewrite
I should not treat this as execution authorization yet.
Based on the current request, I can stay at the discussion/alignment stage and outline the next step.
If you want me to produce a formal deliverable, modify files, run tools, or validate anything, please give explicit authorization first.
Source capture
改寫不替使用者執行，也不宣稱已建立檔案；只有在使用者明確授權後，才進入正式交付、修改、工具操作或驗證。
畫面為 Prototype 1 文件化範圍內的作品集擷取視圖，不代表完整協定覆蓋或外部驗證。
但稽核流程不是只存在於示意圖中；下一頁用一個匿名化工作流，展示協定如何在真實協作中攔截錯誤。
協定應用案例
A real workflow under protocol control
本案例取自一個已匿名化的商業風險評估工作流。任務不是摘要資料，而是在多來源、不一致、部分事實未驗證的情況下，協助形成可交接的分析基線與管理層輸出。
困難在於：資料分散在合約、郵件、表格與歷史訂單中，來源權威（source authority）不同，內容也可能彼此不一致。部分關鍵事實只能標記為待驗證，不能被升級成已確認結論。
我的判斷與介入
我指出，兩者分屬不同交易與不同品項，不能直接對照。
協定修正
回到證據邊界，重新確認資料來源、交易層級與可比性，不把不同交易層級中的表面相似升級成因果關係。
結果
錯誤推論被移除，後續分析不再引用該對照；所有結論重新回到來源權威與交易結構，確認可追溯後才繼續。
協定控制的工作邊界
— 來源權威與證據邊界
— 關鍵判斷的檢查點（checkpoint）
— 不同交易層級的可比性
— 管理層輸出的抽象與壓縮
這個案例展示的不是 AI 不會犯錯，而是錯誤發生後能否被看見、攔截、修正，並回到可控流程。
本案例是操作示範，不是正式驗證；所有商業細節已匿名化。
AI 判斷也需要邊界
LLM judgment still needs structure
一個自然問題是：如果 AI 已經能閱讀與判斷，為什麼還需要協定和稽核準則？為什麼不直接把 AI 回答丟給另一個模型，請它判斷好壞？
原因是，沒有明確邊界的 AI 評估，可能只是在錯的地基上繼續蓋房子：每一層推論看起來都合理，但整體已經偏離使用者真正要解決的問題。把 AI 回答交給另一個模型判斷，只是把判斷責任從一個 AI 轉給另一個 AI，並沒有解決「判斷標準是什麼」的問題。這種偏移通常不是單獨發生，而是伴隨著忽略當前問題、補上沒有來源的解釋、過度美化結果，或把判斷理由說得很像已經對準規則。
這不是純理論假設，而是在本專案的協定整理與多方 AI 協作過程中實際遇到的問題：AI 可以參與判斷，但若沒有明確規則，判斷本身仍可能漂移。
協定的目的不是排除 AI 判斷，而是讓 AI 判斷依附在明確規則上。
單純 AI 判斷
彈性高，但判斷標準容易漂移，理由也未必能回到來源與規則。
加入邊界
基於協定的稽核
讓判斷依附在明確規則上，形成可追溯、可檢查、可修正的評估邊界。
因此，重點不是讓 AI 自由評分，而是讓 AI 在可追溯的評估邊界（evaluation boundary）內工作。
沒有證據，就不能宣稱完成
Completion claims require evidence
在複雜協作中，AI 最危險的錯誤之一不是不知道，而是假裝已經知道。
AI 可能宣稱已讀取、已驗證、已完成、已建立檔案，卻沒有可檢查的行動證據。這種錯誤會把成本轉嫁給使用者，因為使用者必須回頭確認 AI 是否真的完成了它聲稱完成的事。
這裡的設計取捨，是犧牲一部分回答流暢度，換取可追溯性。
Rex AI Co-Work Protocol 將這類問題視為治理對象。AI 必須區分：
每一個「已完成」都必須能回到具體、可檢查的工作面向，而不是只靠語氣成立。
這些邊界讓工作狀態不再只靠語氣可信度，而是靠可檢查的行動與證據。
討論、對齊、執行必須分開
Execution requires explicit authorization
AI 協作中最容易被低估的風險，是把方向認可誤讀成執行授權（execution authorization）。協定因此把討論、對齊與執行分開。
即使在人類溝通中，「可以」「好」「看起來不錯」也可能只是方向認可，不一定代表執行授權。當 AI 參與複雜工作時，這種歧義更容易被放大；如果沒有明確控制點（gate），AI 很容易把討論中的認可理解成開始執行。
這會造成具體風險：AI 誤改檔案、產出錯誤交付物，或宣稱已完成並不存在的工作；而使用者其實只是在討論方向。
執行前，AI 必須先說明要讀什麼、改什麼、建立什麼、如何驗證，以及可能的風險，再等待使用者明確說出「允許執行」。
這個設計把使用者保留在人類決策位置，也降低 AI 擅自執行、擅自修改或擅自產出最終交付物的風險。這不是形式主義，而是降低授權歧義的控制機制。
工作狀態不應只存在聊天記憶裡
Checkpoints make continuation explicit
為什麼不只靠 AI 自己記住？因為工作一拉長，AI 很容易看似記得，實際上已經開始混淆狀態。
長程 AI 協作的一個實際問題，是工作狀態容易散落在不同工作串與對話片段中。
當上下文變長，AI 可能仍然看似記得，但開始混淆：哪些內容已確認、哪些只是討論、哪些是正式資料來源（source）、哪些只是待討論想法（pending idea）。使用者也會被迫不斷提醒前文。
檢查點的作用不是寫摘要，而是保存一個可恢復、可續接的工作狀態。
這讓下一段工作不需要依賴模型是否「還記得」，而是能從明確邊界重建狀態。
在 AI 協作的長程任務中，狀態遺失與上下文混淆是反覆出現的實際問題。檢查點在這裡，不是被包裝成新發明，而是被明確納入這套工作方法，作為降低續接成本、避免狀態漂移的控制設計。
協定不追求一次寫死的 100%
A protocol must remain open to new failures
協定不追求一次寫死的 100%。這不是因為規則不足，而是因為 AI 協作中的失敗模式會隨任務、工具與使用情境持續變化。
這個作品不是要宣稱 AI 協作已經被完整解決，也不是要把協定包裝成一次完成、永久封閉的規格。
這些限制不是未完成，而是有意識的設計選擇。協定不追求一次封閉所有規則，因為新的失敗模式會持續出現；檢查點增加人工確認成本，換取長程任務中的狀態可控；證據邊界則犧牲部分回答流暢度，換取可追溯性，避免 AI 把推論包裝成事實。
目前可以說的是：Rex AI Co-Work Protocol 建立了一套 AI 協作治理框架，ProtocolGuard — Prototype 1 展示了其中部分規則可以被轉成可操作的稽核流程。
Prototype 1 的範圍與驗證邊界
產品階段
定位為工作原型；production-ready 不在本階段範圍內
人類角色
保留人類最終判斷，不以完全自動取代為設計目標
這些不是作品失敗，而是目前設計邊界。清楚標示邊界，反而讓作品更可信：它知道自己完成了什麼，也知道什麼還不能說。
這個專案完成了哪些設計轉換
Design capabilities across the governance lifecycle
這個專案的價值，不只在於提出一套協定，也在於把分散的 AI 協作失敗轉成可被設計、判斷與操作的治理結構。
我完成的不是單一工具功能，而是一連串設計轉換：從保存失敗案例、辨識重複模式、定義規則與證據邊界，到建立稽核準則、檢查判斷是否能穩定重複，再把部分規則轉成原型 1 的稽核流程。
這些轉換讓作品同時連接問題觀察、治理設計、評估邏輯與有限操作化，而不是把協定與原型混成同一個產品宣稱。
這個過程展現的設計能力包括：
- 失敗模式辨識與抽象
- 協定與規則邊界設計
- 證據／來源層級治理
- 稽核準則與測試邏輯
- 執行控制與檢查點設計
- 原型範圍與系統定位
因此，ProtocolGuard — Prototype 1 不是作品的全部，而是展示上述治理邏輯如何被操作化的一個有限節點。
下一頁進一步說明，這些治理能力未來可以延伸到哪些 AI 系統位置。
協定可以落到具體的 AI 系統位置
From rules to system surfaces
Rex AI Co-Work Protocol 不必被理解成單一產品。更保守的看法是：它可以被視為 AI 系統中的一種治理邏輯，出現在前端的審查／批准介面，也可以出現在後端的規則判斷、授權控制點（authorization gate）、證據紀錄（evidence log）與追蹤控制（trace control）。
| 系統位置 | 可能位置 |
|---|
| 前端審查介面 |
代理核准主控台、AI 工作流審查佇列、AI 評估儀表板、AI 軌跡檢視器 |
| 後端控制層 |
AI 政策引擎 API（含工具呼叫核准）、證據／稽核紀錄 API、代理軌跡後端 |
這頁的目的不是建立完整產品分類，而是讓讀者看見：協定的發展可能性不只停在文件或規則層，也可以延伸到不同的 AI 系統位置，成為審查、授權、紀錄或控制流程中的治理邏輯。
從可靠協作開始，而不是從更聰明的 AI 開始
Reliability is a design problem
這個作品的核心假設很簡單：
AI 協作的問題，不只在於模型能不能回答，也在於工作邊界、授權、證據、判斷與輸出治理。
當 AI 被放進真實工作，它不只是回答問題的工具。它會參與決策準備、組織資訊、形成結論、產出文件，甚至影響使用者對工作狀態的判斷。
因此，可靠 AI 協作需要的不只是更好的回答，而是更清楚的協作規則。
Rex AI Co-Work Protocol 是這套規則的核心；ProtocolGuard — Prototype 1 則展示部分治理邏輯如何成為可操作的稽核流程。
失敗→協定→準則→測試→原型→未來應用
Page 13 的案例顯示，問題不是 AI 會不會犯錯，而是錯誤發生後能否被看見、攔截、修正，並回到可控流程。
這不是終點，
也不是一次寫死的 100%。
它是一個會持續吸收
新失敗、新工作情境與新應用形式的
治理框架。
