AI 产品的设计系统：把生成、等待、风险与接管写进组件契约

生成中、正在引用、等待工具、需要确认、结果不确定，这些状态会出现在聊天、表格、工作流和详情页。每个业务页面各自发明一套说法，用户会快速失去判断依据。

设计系统应提供可复用的状态标签、进度结构、证据入口和恢复动作，让不同页面的含义一致。

不要用一个百分比假装精确。根据任务风险选择表达：来源列表、覆盖范围、待验证提示或人工审核状态。

信息层级上，先让用户看到能做什么，再让用户查看为什么可信。把所有细节默认展开只会制造噪声。

当 AI 无法继续、成本过高或风险上升时，用户应该能无损地修改目标、接管步骤或转人工。不要把接管藏在错误弹窗最底部。

这类能力一旦被写成组件契约，产品新增功能时就不会重新发明失败体验。

传统 Design System 关注 Button、Input 和 Modal，AI 产品还需要 Text Part、Reasoning Summary、Tool Call、Citation、Artifact、Approval、Interrupt 与 Error Recovery。它们不是页面私有卡片，而是跨 Agent 场景复用的语义组件。

每个 Part 定义数据契约、流式行为、状态、可见性与交互权限。例如 Tool Call 需要 args status、result、approval、error、cancel 和 retry；Citation 需要来源类型、可访问性、失效状态和打开方式。

消息组件只负责排列 Part，不应理解每个业务工具。业务 Tool UI 通过 registry 注册，未知工具回退到安全的 Tool Fallback，避免新工具上线时整个消息树失效。

A2UI 或 JSON Generative UI 允许 Agent 组合组件后，Catalog 就成为新的公共 API。每个组件需要名称、schema、版本、允许的 action、数据敏感级别、可访问性要求和渲染成本。

不要把通用 React 组件原封不动暴露给模型。为 Agent 设计更窄、更语义化的组件，例如 ApprovalSummary、SourcePicker、MetricComparison，而不是允许任意 className、URL 和事件处理器。

Catalog 变更要做兼容性测试。Agent 可能重放旧对话或远程 Agent 仍发送旧版本 spec，客户端需要拒绝未知组件、迁移旧 props 或明确展示无法渲染，而不是静默生成错误界面。

AI 状态组合很难靠手工点出来。为 text streaming、partial tool args、approval、interrupt、partial result、error、cancel 和 resume 保存标准事件 fixture，组件库直接消费这些 fixture。

每个 fixture 同时用于 Story、视觉回归和协议测试。设计师能看到状态矩阵，前端能验证增量更新，后端能确认 event schema，三方不再各自维护一套示例。

最终检查不仅是截图一致，还要验证事件乱序、重复、断线重连和版本升级。AI Design System 的质量，取决于不确定输入下仍能保持清晰与安全，而不是默认状态有多漂亮。