知行交互规范 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 生成的界面是否附状态完备性核对结果？
输出引用时链接到具体模式页，并区分官方模式与自己的业务建议。无法在线核验时使用内置摘要，说明参考日期和无法核验的部分，不声称是最新版本。