第九篇：AI 一句话能搭页面，为什么还需要产品与前端工程？

现在让 AI 搭一个页面，真的很快。

你说“做一个 SaaS 仪表盘”，它给你侧边栏、卡片、图表、筛选器。

你说“做一个电商详情页”，它给你大图、价格、规格、购物车按钮。

你说“做一个招聘管理系统”，它甚至会给你候选人列表、状态标签和面试日历。

第一眼往往不错。

问题是，真实产品不是第一眼。

真实产品有空状态、错误状态、加载状态、权限状态、移动端断点、键盘操作、屏幕阅读器、数据延迟、脏数据、国际化、埋点、回滚和维护成本。

CS146S 第八周主题是 Automated UI and App Building，课程公开页面把重点放在 design and frontend for everyone，以及 rapid UI/UX prototyping and iteration。这个主题很容易被误解成“前端工程不重要了”。

我更愿意反过来理解：

AI 降低了原型成本，但提高了产品验收的重要性。

第一级：能看见，不等于能使用

AI 最擅长的是第一级：生成一个能看的界面。

它能快速帮你探索信息架构、页面布局和视觉方向。

这很有价值。

过去一个想法要先画线框、找模板、写样式；现在可以十分钟做出三个方向，让产品、设计、工程坐在一起讨论。

但“能看见”不等于“能使用”。

你至少要问：

• • 没有数据时界面长什么样？
• • 加载超过 3 秒时用户看见什么？
• • API 失败时能否重试？
• • 权限不足时是隐藏入口，还是显示不可用原因？
• • 表单输错后，错误信息是否靠近字段？
• • 手机屏幕上按钮是否仍然可点？

如果这些问题没有答案，它只是视觉草稿。

不要因为它漂亮，就把它当产品。

第二级：能演示，不等于能交付

第二级是可演示原型。

它可以有假数据、假登录、假支付、假通知。

只要目标是验证流程和沟通需求，这完全合理。

但演示原型必须贴标签。

## 原型边界

- 数据：静态 mock，不连接真实后端。
- 权限：只演示 UI 状态，不包含后端鉴权。
- 性能：未做大列表、慢网络和移动端测试。
- 可访问性：未完成键盘导航和语义标签检查。
- 安全：未处理真实用户输入和敏感数据。

AI 生成 UI 最危险的时刻，是 Demo 获得掌声之后。

大家会自然地说：“那就把这个上线吧。”

这时产品和前端工程的价值，就是把掌声变成验收标准。

第三级：可维护，才开始像产品

可维护 UI 不是“组件拆得多”。

它是状态、数据和边界能被持续修改。

你需要检查：

## UI 可维护性检查

| 维度 | 问题 |
|---|---|
| 状态 | loading / empty / error / disabled 是否都有明确设计 |
| 数据 | mock 数据是否已替换为真实 API 契约 |
| 权限 | 前端展示与后端鉴权是否一致 |
| 组件 | 组件边界是否符合业务概念，而不是按截图硬切 |
| 样式 | 是否复用设计 token，而不是到处写一次性颜色 |
| 测试 | 关键交互是否有组件测试或 E2E 测试 |

很多 AI 页面的问题，不是“写得丑”。

是它把一次性截图写成了应用。

比如同一个状态标签在三个页面用了三套颜色；同一个按钮在移动端宽度溢出；筛选条件只存在前端 state，刷新后全部丢失；表格排序和后端分页互相打架。

这些都不是模型“不会写前端”。

这是上下文里缺了产品规则和工程约束。

第四级：可上线，需要跨角色验收

可上线 UI 至少需要三类验收：

第一类是产品验收。

用户能不能完成目标？异常路径是否说人话？关键动作有没有确认和撤销？

第二类是前端工程验收。

组件是否可维护？状态是否完整？响应式是否稳定？错误边界是否合理？

第三类是质量与合规验收。

可访问性、性能、安全、隐私、埋点和国际化，哪些是本次必须，哪些可以延期？

W3C 的 WCAG 2.2 仍然把 Web 内容可访问性组织为可感知、可操作、可理解和健壮四组原则。哪怕你的产品暂时不做完整合规，也不应该把键盘可用性、文本对比度和错误提示当作上线后再说的小事。[^wcag]

给 AI 的正确上下文：不是“做得好看点”

如果你只说“做得现代一点”，AI 会给你视觉套路。

更好的提示是把产品约束写进去：

## UI 生成上下文

目标用户：
- 每天处理 50-100 条工单的一线运营人员。

核心任务：
- 快速筛选高优先级工单。
- 批量分配负责人。
- 查看失败原因并重试。

必须状态：
- loading, empty, error, permission denied, stale data。

数据约束：
- 列表最多 1000 条，服务端分页。
- 优先级、状态、负责人来自后端枚举。

交互约束：
- 批量操作必须二次确认。
- 错误信息不能只用颜色表达。
- 移动端只保留查看和备注，不做批量分配。

验收：
- 关键按钮在 375px 宽度不溢出。
- 表单错误靠近对应字段。
- 主要流程支持键盘操作。

你看，这已经不是单纯的前端提示词。

这是产品说明、设计约束和工程验收的组合包。

反模式：把 UI 当作一张图片验收

AI 生成 UI 最常见的反模式是截图验收。

只看一张 1440px 桌面截图，就说“可以”。

真实验收应该至少包括：

## UI 验收最小集

- 桌面、平板、手机三个断点。
- 正常、空、加载、错误、权限不足五种状态。
- 鼠标、键盘、触摸三种输入方式。
- 慢网络、接口失败、重复提交三种异常。
- 真实长度文本、极端数字、缺失字段三类脏数据。

如果一个 AI 生成页面过不了这些检查，它不是失败。

它只是还停在原型阶段。

30 分钟练习：把一个漂亮 Demo 拉到可维护

找一个 AI 生成的页面，做三件事：

1. 1. 写出它目前属于四级成熟度的哪一级。
2. 2. 列出至少 8 个缺失状态或验收条件。
3. 3. 补一份“UI 生成上下文”，再让 AI 重构一次。

你会发现，第二次生成通常会明显更像产品。

不是因为模型突然变聪明了。

而是你把产品与工程的判断交给了它。

下一篇，我们进入上线后 Agent：当 Agent 接入生产系统，真正的问题不是它会不会回答，而是它能看什么、能做什么、谁批准。

\

               1.                 参考 Stanford CS146S 公开课程页面 Week 8 信息，核验日期：2026-07-21。课程链接：https://themodernsoftware.dev/。                    ↩︎                

\

               1.                 参考 W3C Web Content Accessibility Guidelines 2.2，核验日期：2026-07-21。链接：https://www.w3.org/TR/WCAG22/。                    ↩︎