这两天刷技术社区，类似的标题看得挺多：AI 已经能写大部分代码了、Agent 开始接管工作流、甚至有人说 Markdown 都要被 HTML 重新替代。

说实话，第一次看到这些讨论，我的反应不是兴奋，而是有点慌。因为如果只从“能不能把页面写出来”这个角度看，AI 的确已经很强了。一个登录页、一个管理后台、一个活动页，只要需求别太绕，它很快就能给你搭出一个看起来像样的版本。

但多看几轮之后，我反而没那么焦虑了。

我现在更倾向于一个判断：AI 正在把“写第一版代码”的门槛压低，但它并没有替代真正理解用户、业务和工程边界的人。尤其是前端、交互、用户体验这些位置，真正值钱的部分，反而会变得更清楚。

AI 写页面最容易翻车的地方

很多人试 AI 写前端，第一眼觉得很惊艳，第二眼就开始改到头疼。原因通常不在语法，而在这些细节。

1. 它会把“能用”误认为“好用”

比如让 AI 做一个表单，它大概率能给你：

• 输入框
• 提交按钮
• 校验提示
• 成功弹窗

但真实用户不是按组件库文档来操作的。

用户会输错手机号，会网络断开，会重复点提交，会不知道哪个字段错了，会在手机上被键盘挡住按钮。一个页面有没有体验感，往往就差在这些“不优雅但真实”的场景里。

我现在写需求时，会先补一句：

请同时考虑 loading、empty、error、disabled、mobile keyboard、重复提交、接口超时这些状态。

这句话看起来不起眼，但生成结果会立刻靠谱很多。

2. 它喜欢做“看起来很满”的界面

AI 生成的页面经常有一个毛病：信息都对，但画面太满。

标题很大，卡片很多，按钮很多，渐变很多。乍一看像作品集，真正放到业务里就有点吵。尤其是后台、工具、内容管理类页面，用户不是来欣赏视觉稿的，而是来快速完成任务的。

所以我会在提示词里加一句：

这是一个高频使用的工作台界面，优先考虑扫描效率和重复操作效率，不要做营销式大卡片布局。

这类约束，比单纯说“做得高级一点”有效得多。

3. 它能补代码，但不一定知道为什么要这样补

AI 很擅长修局部问题，比如按钮没居中、接口字段改名、样式覆盖失败。但如果一开始的信息架构错了，它会沿着错误方向越补越复杂。

我踩过一个小坑：一开始只说“做一个内容发布页”，AI 很快给了标题、正文、标签、发布按钮。看上去没问题，但后来才发现少了草稿、预览、定时发布、封面图、摘要、可见范围这些关键流程。最后不是改样式，而是重做页面结构。

所以现在我会先写用户流程，再让 AI 写代码：

1. 用户进入编辑页
2. 输入标题和正文
3. 自动保存草稿
4. 手动补标签、摘要、封面
5. 预览
6. 发布或定时发布
7. 发布失败时保留内容并提示原因

流程写清楚之后，AI 就不容易只做一个“漂亮空壳”。

一个更靠谱的前端 AI 工作流

我现在觉得，比较适合普通开发者和设计师的方式不是“让 AI 一口气做完”，而是把它当成一个很快但需要你把关的搭档。

第一步：先写场景，不急着写代码

不要只说：

帮我做一个登录页。

可以改成：

帮我做一个面向企业后台的登录页。用户可能会输错密码、验证码可能过期、接口可能超时。页面需要支持手机和桌面端，重点是稳定、清楚、少打扰。

后者生成出来的东西通常会更接近真实产品。

第二步：提前列状态

我一般会先列这几类：

• 默认状态
• 输入中
• 校验失败
• 提交中
• 提交成功
• 提交失败
• 空数据
• 无权限
• 移动端窄屏

如果一个页面把这些状态都考虑到了，就算视觉不花，也已经比很多“炫酷 Demo”更像真实项目。

第三步：让 AI 先解释结构，再生成代码

我会要求它先回答：

• 页面分成哪些组件
• 每个组件接收什么数据
• 哪些状态需要提升到父组件
• 哪些逻辑应该放在 hook 或 service 里

这样做有点慢，但能避免后面出现一个几百行的大组件。AI 不是不能写好结构，而是你不要求，它就容易偷懒。

第四步：截图检查比“感觉还行”更重要

前端有个很现实的问题：代码看着对，不代表页面真的对。

我会重点看这些地方：

• 长标题会不会挤爆按钮
• 手机端会不会横向滚动
• loading 时布局会不会跳
• 弹窗会不会挡住关键操作
• 错误提示是否能让用户知道下一步怎么做

这些细节，才是前端和交互设计真正有价值的地方。

设计师还要不要学代码？

我的答案是：要，但不一定一上来就学到很深。

如果你偏交互、视觉、用户体验，我建议先补这几块：

• HTML 语义：知道页面结构怎么组织
• CSS 布局：重点是 flex、grid、响应式
• JavaScript 基础：知道数据和状态怎么变
• React 组件思维：理解一个页面怎么拆
• 接口数据：看得懂 JSON、loading、error
• Git 基础：至少能看 diff、提 issue、描述问题

学这些不是为了把自己变成全栈，而是为了和 AI、开发、产品沟通时不虚。你能看懂它生成了什么，也能指出哪里不对。

我反而觉得“真人感”会更稀缺

AI 生成内容越来越多之后，技术文章也会出现一个问题：很多文章都很完整，但读起来没有人味。

什么叫没有人味？

就是它什么都讲，但你看不出作者到底踩过什么坑、为什么这样选、哪里犹豫过、最后放弃了什么。

我现在更愿意看这种文章：

• 先讲背景：我为什么遇到这个问题
• 再讲过程：我试了哪几种办法
• 然后讲取舍：为什么最后选这个
• 最后讲边界：这个方案哪里不适用

这比单纯堆 API、堆定义更容易让人相信。

一个小结

AI 会继续变强，这件事不用怀疑。但我觉得它替代的不是“会思考的人”，而是那些只会机械搬代码、机械写页面、机械堆概念的部分。

前端和设计师真正要补的，不是和 AI 比谁敲得快，而是提高自己判断问题的能力：

• 用户到底要完成什么任务
• 页面状态有没有覆盖完整
• 交互是不是清楚
• 结构是不是能维护
• 内容是不是说人话

这些东西短期看不如“十秒生成一个页面”刺激，但长期看，才是真正能留下来的竞争力。

如果你也在用 AI 写前端或做产品原型，欢迎在评论区聊聊：你觉得 AI 最省时间的地方是什么？最让你崩溃的地方又是什么？

我后面又把这个坑往细了写了两篇：一篇专门看页面生成后的加载、空态、错误态，一篇专门写怎么把前端需求喂给 AI。

我也整理了一个小资源包，里面就是几张 Markdown 表：需求澄清、Prompt 模板、UI 状态走查和发布复盘。做页面前后打开对一下就行，别指望它包治百病，但能少漏几个很烦人的小坑。

资源入口：https://download.csdn.net/download/weixin_56088571/92877847