知行互動規範 Intent UI
把業務目標轉換為有依據的功能取捨、操作規則和可觀察的驗收條件。流程層決定「工作怎樣推進、產出哪些交付物」，方法層約束「AI 怎樣思考與自檢」，業務層決定「需要哪些能力」，元件層決定「這些能力怎樣被理解和操作」。預設用中文，面向產品、設計、前端和測試協作；不綁定框架或要求安裝任何參考專案的元件庫。
核心約束
- 先確定用戶任務，再決定頁面和元件。資料庫存在某張表，不代表用戶需要該表的增刪改查介面。
- 區分「所有相關頁面都必須滿足的互動底線」和「滿足業務條件後才必須提供的能力」。條件未知時標記待確認，不擅自歸為可省略。
- 操作取決於業務物件、當前狀態、使用者權限、關聯依賴和影響範圍。不能只寫一套靜態按鈕清單。
- 區分業務停用、控制項禁用、唯讀、刪除、歸檔、撤銷和回滾；名稱、結果和恢復方式保持一致。
- 既說明提供什麼，也說明為何省略、什麼變化會觸發重新評估。使用者要求精簡時仍保留已適用的錯誤恢復與狀態回饋。
- 參考 Cloudscape 的模式和選擇依據；業務能力矩陣、審批、任務恢復等屬於本 Skill 的後台擴展規則，不冒充 Cloudscape 官方要求。
- 元件層以原生語義及對應 APG 模式核對鍵盤與焦點，用 Carbon、Ant Design 的場景原則和 Radix、React Aria 的實現經驗補足互動。不把庫的預設值當成所有元件的規範，不宣稱這些專案共享一份統一標準。
- 不把某產品的按鈕排序、欄位數量、彈窗尺寸或時間閾值變成通用硬指標。尊重已有產品規範；發生衝突時說明取捨及使用者影響。
- 不因編寫或評審規範而執行真實刪除、停用、審批、匯出或權限變更。僅在使用者要求實現時修改相應程式碼，遵循其授權範圍。
按請求選擇工作方式
| 使用者意圖 | 做什麼 | 交付規模 |
|---|---|---|
| 制定通用規範 | 建立條件規則和場景範例，不虛構具體業務 | 規範、能力矩陣、驗收範本 |
| 設計具體模組 | 從已知流程和資料狀態推導必要能力 | 模組決策表、頁面互動契約、驗收場景 |
| 設計或審查後台元件行為 | 明確元件語義、狀態、輸入方式和組合邊界 | 元件選擇理由、行為契約、必要的互動驗收 |
| 審查現有後台 | 對照可見頁面、需求或原始碼識別缺口 | 有證據的問題、影響、最小修正及驗收 |
| 提煉或應用後台參考風格 | 對照頁面與原始碼，按任務選擇構圖、令牌角色和互動模式 | 可執行的風格約定、適配邊界、驗收點 |
| 實現或修復互動 | 在已有架構中實現已確定的範圍 | 程式碼變更、相應驗證、剩餘依賴 |
規範請求不自動擴展成程式碼改造；評審請求不自動重構整個後台。簡單頁面只輸出必要的決策與規則。
任何設計任務開始時，按 設計工作流程 確定流程深度、階段推進門檻與交付物鏈；由 AI 起草介面、驅動生成工具或多 agent 協作時，先執行 AI 設計思路 的生成前自校準與失敗模式防護。
建立業務上下文
優先讀取使用者提供的需求、流程、截圖、現有頁面和相關原始碼。只檢查與任務有關的材料。區分已觀察到的行為、文件要求和假設；單憑截圖不能斷言後端權限或非同步恢復已經實現。
提取影響決策的最少資訊：
- 誰在什麼範圍內完成什麼任務；主要入口和完成標誌是什麼。
- 資料來自使用者維護、外部同步還是系統生成；哪些欄位或記錄可變。
- 資料經歷哪些業務狀態，哪些狀態轉換有效，誰可以觸發。
- 操作影響誰、是否可逆、有何關聯依賴，是否存在長任務或多人同時修改。
- 資料規模、使用頻率、工作設備和已有規範對互動有何約束。
缺少背景時，先給「通用 Web 後台」的可裁剪方案並寫明假設。僅就會改變關鍵決策的缺口提問，繼續處理不受影響的部分；沒有證據時不預設提供永久刪除、越權操作或完整任務中心。
選擇能力
制定或評審功能範圍時讀取 能力判斷。為範圍內的模組建立能力矩陣，每項標為：
- 基礎必需：該類互動存在，就必須有的底線，例如載入資料時有可辨認的載入和錯誤狀態。
- 條件必需：明確業務條件成立時必須提供；寫出條件及證據。
- 可選增強：有收益但不妨礙核心任務，可以排期或省略。
- 不適用：與當前業務無關或不允許，說明原因。
- 待確認：證據不足；這是決策狀態，不是假裝已經可以省略。
實現成本高不等於不適用；缺少介面不等於不需要該能力。分別記錄業務必要性和實現前提。
選擇具體規則
按涉及範圍讀取，不預設載入全部參考檔案：
| 涉及內容 | 讀取 |
|---|---|
| 設計階段編排、發散收斂、交付物鏈、設計規格與交接 | 設計工作流程 |
| AI 生成介面、設計上下文降級、失敗模式防護、多 agent 分工 | AI 設計思路 |
| 導覽、工作台、列表、搜尋、篩選、詳情、圖表 | 導覽與資料瀏覽 |
| 新增、編輯、校驗、停用啟用、刪除歸檔、批次、匯入匯出 | 操作與表單 |
| 載入異常、權限、多租戶、並發、非同步任務、審批發布、通知、無障礙 | 狀態與業務流程 |
| 元件選型、狀態語言、鍵盤、焦點、浮層及元件組合 | 元件互動設計語言 |
| 啟發式評估、認知走查、無障礙驗收、體驗度量、設計 QA | 設計評估方法 |
| 設計系統治理、design token、元件文件範本、一致性稽核 | 設計系統與令牌規範 |
| 提煉或應用 NextLabs、LarkAgentX 等參考風格，高頻工作台、營運控制台及配套展示面 | 工具型介面風格 |
| 輸出規範、評審報告、驗收、場景演練 | 交付與檢查 |
| 引用 Cloudscape 業務模式 | Cloudscape 來源與適配邊界 |
| 引用 APG、Carbon、Ant Design、Radix 或 React Aria 的元件規則 | 元件來源與差異處理 |
| 引用流程模型、評估方法或設計系統來源 | 流程、評估與設計系統來源 |
| 引用 NextLabs、LarkAgentX 的案例證據與核驗邊界 | 工具型介面風格來源 |
每個實際提供的操作寫清：入口和作用物件 → 適用狀態與權限 → 輸入或確認 → 執行中 → 成功結果 → 失敗或結果未知 → 返回位置和恢復途徑。不適用環節可以省略並說明；不為瀏覽詳情強加確認框。
對於有生命週期的物件，給出「狀態 × 操作 × 角色」規則；對於跨步驟任務，說明儲存、離開、恢復、部分完成。流程有分支或狀態較多時用緊湊表格或 Mermaid，單步操作不強行畫圖。
當請求明確涉及具體元件的設計、評審或實現時，讀取元件互動設計語言的相關部分；只做業務功能取捨時不展開整套元件清單。元件外形相似不等於行為相同，特別檢查選單與選擇器、開關與核取方塊、提示與互動浮層、普通表格與資料網格。
交付前檢查
- 功能取捨能否追溯到任務或業務規則，是否出現無依據的全套 CRUD、儀表板或批次操作？
- 同一操作在列表、詳情、快捷入口和批次入口是否遵循一致條件？
- 是否區分空資料、無匹配、載入失敗、權限不足和資料過期？
- 是否把請求已受理誤寫為完成，或把逾時誤寫為確定失敗並允許重複提交？
- 刪除、停用、發布等操作是否明確影響範圍；提供的恢復能力是否真實存在？
- 主流程、失敗、權限或狀態變化、部分成功以及適用的鍵盤流程能否驗收？
- 元件語義、焦點、選中和執行中狀態是否一致；巢狀浮層、自訂包裝和不同輸入方式是否破壞既定行為？
- 輸出是否宣告所走流程路徑與跳過階段的理由；AI 生成的介面是否附狀態完備性核對結果？
輸出引用時連結到具體模式頁，並區分官方模式與自己的業務建議。無法線上核驗時使用內建摘要，說明參考日期和無法核驗的部分，不聲稱是最新版本。