AI写前端的问题

发表于 分类于 Waline：
记录我用 AI 写前端时遇到的几个问题，包括页面太花、不读项目、只写静态效果和不做浏览器检查。

AI 写前端挺快，但不能完全让它自由发挥。

最近用 AI 写前端比较多。

一开始确实会觉得很爽。

你把需求丢给它，它很快就能写出页面结构、样式、交互，有时候还会顺手加一点动画。

但是用到真实项目里以后，就会发现一个问题：

它写出来的东西，经常是“看着还行”，但不一定真的好用。

尤其是后台系统。

后台页面不是做截图，也不是做官网首屏，更多时候是给人反复用的。
所以它要清楚，要稳定，要符合项目原来的写法，也要方便后面继续维护。

容易做得太花

AI 很喜欢把页面做得很热闹。

比如：

  1. 加很多卡片
  2. 加渐变背景
  3. 加大圆角
  4. 加阴影
  5. 加装饰图形
  6. 加一些说明文案

这些东西不是一定不能用。

但是后台页面里，最重要的不是热闹，而是信息要清楚。

比如一个表格页面，本来用户是想快速看数据、筛选数据、对比数据。
如果 AI 把它改成一堆大卡片，看起来是漂亮了一点，但是效率反而变低了。

再比如筛选区域。
它如果为了好看加很多背景、边框、提示文字，真正的查询和重置按钮反而不明显。

所以我现在让 AI 改后台页面时，都会先强调一句：

1
2
这是后台管理系统，不要做成官网风格。
优先保证清楚、稳定、信息密度和操作效率。

不读项目就容易乱

AI 如果只看到当前文件，就很容易按自己的习惯写。

比如项目里本来已经有统一的表格组件、弹窗组件、上传组件。

它可能看都没看，就重新写一套。

项目里本来接口都放在 apis.js，它可能直接把接口地址写在页面里。

项目里本来搜索区、按钮、分页都有固定写法，它可能又写成另一种风格。

这些代码有时候能跑，但是放在项目里就会很别扭。

所以我现在不会一上来就让它改。

一般会先让它看这些东西：

  1. 当前页面
  2. 相邻页面
  3. 公共组件
  4. 接口文件
  5. 路由和菜单配置
  6. 项目已有样式

先让它知道这个项目本来是怎么写的，再让它动手，结果会稳很多。

经常只写有数据的时候

AI 很容易把页面写成“正常情况下”的样子。

也就是有数据的时候、接口正常的时候、字段都很短的时候。

但是实际项目里不是这样。

常见情况很多：

  1. 数据加载中
  2. 列表为空
  3. 接口报错
  4. 表单校验失败
  5. 上传失败
  6. 权限不足
  7. 字段特别长
  8. 移动端屏幕很窄

比如列表为空的时候，页面中间如果什么都没有，用户就不知道是没数据，还是页面坏了。

比如弹窗字段很多，电脑上看着没问题，换到窄屏可能按钮已经被挤出去了。

所以我现在会把这些状态也一起说清楚。

不要只让 AI 写一个静态页面，要让它把真实场景也考虑进去。

最后还是要看浏览器

AI 写完代码以后，如果只看 diff，很容易漏问题。

前端最后还是要回到浏览器。

我遇到过一些很典型的问题：

  1. 文案在按钮里溢出
  2. 表格宽度导致横向滚动
  3. 弹窗高度超过屏幕
  4. 固定定位挡住内容
  5. 暗黑模式下颜色看不清
  6. 移动端布局挤在一起

这些问题不是只看代码就能发现的。

所以 AI 改完以后，我一般还会让它继续检查：

1
2
3
打开浏览器检查页面。
分别看桌面端和移动端。
重点检查文本溢出、按钮错位、弹窗遮挡、横向滚动和空状态。

如果页面比较重要，就再用截图看一下不同宽度。

我现在一般怎么用

我现在对 AI 写前端的感觉是：

它不是不会写代码。

它的问题是很容易不知道边界。

它不知道这个页面是给谁用的。
它不知道项目里原来有哪些组件。
它不知道哪些地方不能乱改。
它也不知道改完以后应该检查什么。

所以不能只说一句：

1
帮我写个页面。

我更习惯这样说：

  1. 先读项目
  2. 先分析问题
  3. 按已有组件和写法改
  4. 不要做无关重构
  5. 改完构建
  6. 最后看浏览器效果

这样它更像是在项目里协作，而不是单独生成一个页面。

小结

AI 写前端确实能提速。

但是快不代表稳。

如果不给规则，它很容易把页面写得太花、太散，或者不像原来的项目。

我现在觉得比较合适的流程是：

1
读项目 -> 理解需求 -> 按规范修改 -> 浏览器验收 -> 再调整

这样写出来的页面，才更接近真实项目里能用的状态。

-------------本文结束感谢您的阅读-------------