发生了什么
A2UI 让代理描述一个界面，再由应用使用已注册的组件将其渲染出来。模型可以用获准使用的组件组合页面，而应用仍然保留自己的控件和视觉风格。当对话需要在文字之外提供选项、表单或结构化结果时，这种方式就有用武之地。
Google 在 11 月 11 日的公告中介绍了首个稳定协议版本，其中包括双向函数调用和无障碍元数据。应把这次发布视为一份需要评估的接口约定。协议达到稳定版本，本身不能证明某项集成在你的应用中足够快、无障碍体验良好或足够安全；这些结果需要应用层面的证据。
核对完整的支持链路
从你实际交付的客户端开始。项目列出了 React、Angular、Lit、Flutter 和 SwiftUI 渲染器。公告说明，Jetpack Compose 和 Gemini 的已注册代理集成仍使用 0.9.1，升级尚待推出；Lynx 支持的是 0.9。请记录这些区别，不要因为介绍页列出了某个框架名称，就认定它已兼容 1.0。
为每个已部署客户端建立一条清单记录，列出宿主、渲染器包、协议、组件目录和代理 SDK，并锁定测试所用的版本。如果现有宿主仍使用旧协议，就保留与它兼容的路径，按受支持的版本明确分流。新旧版本并存的部署环境需要的是升级方案，而不是一个要求所有端同时切换的发布日期。
把组件目录当作 API 管理
迁移指南记录了组件目录中的破坏性变更。在修改所有界面之前，先用一个具有代表性的小型组件目录逐条核对迁移规则。尤其不能把所有 path 全局替换为 @path：指南区分了动态绑定和其他路径字段。先检查每个字段的含义，再为应用实际使用的消息保留迁移前后的测试样例。
注册某个组件或函数是一道边界，获准执行业务操作则是另一道边界。例如，界面上显示的确认控件，仍应调用一个会检查当前登录用户、请求操作和资源当前状态的服务端。在实现审查中明确检查这层授权，不要因为界面成功渲染，就推断业务授权也已正确完成。
开展小规模、可观测的试用
选择一个可撤销的工作流程，在接入模型前写清它应当呈现的各种状态。首次试用可以先收集一项偏好并展示预览，将可能产生重要影响的操作保留在应用现有的确认流程之后。将组件范围控制得足够小，让审查者能逐一检查所有可用交互。
Codorc 建议检查以下项目。这些是拟议的验收标准，并非我们已经对 A2UI 执行过的测试：
- 重放一组固定的有效消息，检查渲染后的状态，而不只是确认解析是否成功。
- 分别发送未知组件、未注册函数和不被允许的调用方请求，确认它们都会失败，且不会触发业务操作。
- 在表单接收流式更新的中途断开连接，再重新连接，检查已填入的值和待执行操作是否仍然清楚易懂。
- 用键盘遍历每个控件。检查界面更新后的焦点位置，并配合屏幕阅读器核对无障碍名称和播报。
- 在每种受支持语言及窄屏手机上比较同一项任务，检查标签裁切、含义顺序变化和难以使用的校验错误提示。
- 以现有流程为基线，记录界面达到可用状态所需的时间、任务完成情况、重试次数和审查工作量。在邀请更多用户前，先确定触发回退的条件。
根据所需交互决定是否采用
官方快速入门是学习示例，而不是生产环境模板。可以用它理解代理、组件目录、传输层和渲染器如何衔接，再检查你自己的应用还需要补齐哪些部分。
当代理需要在你的设计系统内，把熟悉的控件组合成不同布局时，A2UI 值得评估。对于固定且需求清晰的任务，普通表单可能仍然更容易测试和维护。根据实际交互和受支持的部署路径作决定，并在试用提供了证据之后，再扩大应用范围。
事件日期指原始公告日期，发布日期指本文首次刊登于 Codorc 的日期。
