技术点
AI 生成 UI 的前端验收的重点不是把模型接口接进页面，而是让 AI 能力在真实前端工程里稳定工作。让 AI 生成页面很快，但页面是否能用要靠验收。视觉、数据、交互、异常和可维护性都要检查。
先画出输入、请求、模型输出、状态更新和用户反馈这条链路，避免只从组件外观出发。 这一步决定了后续代码会不会可维护。很多 AI 页面刚上线看起来没问题，真正被用户频繁使用后，问题往往出现在取消、重试、权限、成本、引用和状态同步这些细节里。
架构拆解
把需求转成可执行验收清单，让 AI 生成后逐项对照。对于复杂页面，先让 AI 输出组件结构和数据流，再写代码。 我通常会把这一类功能拆成四层：交互层负责输入和反馈，请求层负责协议和取消，任务层维护状态机，审计层记录必要事件。这样组件不会知道太多模型细节，请求层也不会夹杂业务文案。
前端尤其要避免两个极端：一种是把 AI 功能写成一个孤立弹窗，无法和业务流程结合；另一种是让 AI 直接改业务数据，用户没有确认和回退空间。更稳的方式是让 AI 先生成建议，再由用户采纳，采纳动作进入正常业务链路。
实现步骤
- 先定义用户目标和不可接受的结果，例如不能静默覆盖数据、不能暴露敏感内容、不能让用户误以为模型输出一定正确。
- 再把请求生命周期拆成创建任务、发送输入、接收中间状态、完成或失败、用户确认这几段，每一段都要能在界面上表达。
- 最后补上工程化能力，包括取消、重试、埋点、灰度、降级和回滚。AI 功能越靠近业务核心，越不能只靠一个接口调用支撑。
- 给每个关键状态准备 UI：等待、生成中、部分完成、失败、已取消、等待确认、已采纳。
- 在真实数据下压测长文本、慢网络和连续点击，确认页面不会卡住，也不会重复提交。
关键代码或提示词
验收：桌面端、移动端、空状态、错误状态、长文本、权限不足、接口慢响应。这段结构不一定要原样照抄，真正重要的是把状态、输入和输出关系显式化。只要这些关系清楚，后面无论换模型、换协议还是换 UI 组件，改动范围都会小很多。
业务场景
如果这是一个面向团队协作的系统，我会把模型输出和人的决策分开记录，方便后续复盘为什么采纳或拒绝。 对用户来说，AI 的价值不是“看起来很智能”，而是让他少做重复劳动，并且在关键步骤仍然有判断权。
边界与风险
- 不要把模型输出当成事实，涉及金额、权限、法律、医疗、账号操作时必须有人确认。
- 不要在前端日志里记录完整 prompt、用户隐私、上传文件内容或接口密钥。
- 不要让一次 AI 请求绑定太多隐式状态，重试时必须知道使用的是哪份输入和哪版配置。
- 不要忽略移动端和低性能设备，流式渲染、大文本 diff 和文件预处理都可能压垮主线程。
验收方式
验收时不要只看正常生成一条答案。至少要检查慢响应、用户中途取消、连续重试、模型返回空内容、引用材料缺失、权限不足、移动端窄屏和刷新恢复。还要确认埋点里能看到 taskId、模型版本、耗时、结果状态和用户是否采纳。做到这些，这个功能才算从演示走向可用。