让 AI 写好前端，我现在会先把这些话说清楚
#博客更新
先说结论。
让 AI 写好前端，重点不是多给它一点“灵感”，而是先把它容易乱跑的边界收紧。
我这阵子在折腾一个 tmux 相关的 web 项目，页面和终端渲染被我和 AI 来回改了很久。改到最后我越来越确定一件事：
前端做不好，很多时候不是模型不会写代码，而是我们喂给它的要求太松了。
你如果只说一句“帮我做个好看的页面”，它大概率会回到最常见的网页套路：
● hero 很大
● card 很多
● badge 一排
● shadow 和 radius 也不缺
● 看起来很努力，但就是没有自己的味道
它能把东西做出来，但不一定能做成你想要的样子。
1. 先分清楚：你到底要它做什么
这个问题看起来简单，但其实最关键。
很多前端任务混着三件事：
● 页面结构：信息怎么排
● 视觉方向：看起来是什么气质
● 交互边界：哪些地方脆弱，不能乱碰
如果这三件事混在一起，AI 就会很容易把注意力放错。
比如我那个项目里，终端视口其实是最脆弱的部分。它不是普通卡片，也不是普通文本块，更不是一个可以随便加阴影、加浮层、加复杂布局的区域。
它更像一个设备边界。
所以我后来改法就变了：
● 产品骨架先稳定
● terminal 只负责 terminal
● 外层 chrome 只负责信息和操作
● 视觉装饰尽量收敛
这一步很重要。因为如果你不先告诉模型“哪个模块不能乱碰”，它就会自然而然把每个模块都当成可优化对象。
2. AI 最容易回退到模板味
这个我觉得是 AI 前端里最常见的问题。
只要 prompt 稍微模糊一点，它就会滑回训练数据里的高频网页模式。
结果通常长这样：
● 结构没错
● 组件也齐
● 配色也不丑
● 但一眼看上去就是“AI 做的”
为什么会这样？
因为模型默认会选最稳的解，而不是最有个性的解。
而所谓“稳”，对很多前端任务来说，恰好就是模板味。
所以如果你真的想让它写出有 taste 的页面，不能只让它“自由发挥”，而要给它更具体的偏好：
● 这个产品像什么
● 不是哪个风格都能用
● 哪些元素默认不要
● 哪些信息一定要先出现
● 哪些层级必须压住
这不是限制 creativity。
相反，这是在给 creativity 一个能落地的边界。
3. 第一屏不是信息仓库
我现在越来越不喜欢那种什么都往第一屏塞的做法。
很多 AI 页面看起来“内容很多”，实际上是没想清楚第一屏到底干什么。
第一屏最重要的不是堆信息，而是先把这几件事说清楚：
● 这是什么产品
● 它和别的东西有什么不同
● 用户为什么应该继续看下去
● 你这个页面的主情绪是什么
如果第一屏什么都想讲，最后通常什么都讲不清楚。
我现在比较认可的一种方法是：
● 第一屏只负责建立身份
● 第二屏再补场景
● 第三屏讲功能细节
● 最后再给操作入口
也就是每一段只做一件事。
这个原则看起来朴素，但很好用。因为 AI 很容易把 section 写成平铺直叙的内容清单，而不是有职责的页面段落。
4. 默认不要卡片，真的有用
这个判断很狠，但我发现它很好用。
很多 AI 页面的问题，本质上是太喜欢卡片了。
什么都要卡片：
● hero 里要卡片
● 特性区要卡片
● CTA 附近也要卡片
● 甚至一段说明文字也要 border + shadow + radius
最后页面就很“忙”，但没有重点。
我现在会先问自己一个问题：
这个判断能帮你砍掉很多不必要的视觉噪音。
而且它特别适合拿来约束 AI，因为模型很爱“补装饰”。你不给规则，它就一直补。
5. 先定设计系统，再让它写
AI 写前端最怕的不是不会写，而是写着写着风格漂了。
今天一套颜色，明天又一套按钮，后天再换一层背景逻辑，最后整个页面就散了。
所以我现在更倾向于先定这些东西：
● background / surface / text / muted / accent
● 主要字号层级
● 按钮风格
● 间距节奏
● 圆角和边框的使用规则
这套东西最好在 prompt 之外就先写成 token 或设计说明。
因为 AI 其实挺擅长遵守“明确的系统”，不太擅长自己现场发明一套又一套。
如果你一开始就把系统定住，它后面写页面会稳很多。
6. 视觉参考比“高级”这种词更重要
“高级”“极简”“有氛围”这些词，听起来很对，但其实很滑。
模型看到这种词，往往只能往自己最熟的方向靠。
所以我现在更愿意直接给它：
● 参考图
● mood board
● 颜色锚点
● 字号节奏
● 气质描述
因为这些东西比“高级一点”这种抽象词有用得多。
前端设计不是让模型猜，而是让它有一个明确的视觉方向可以靠。
尤其是有 taste 的项目，很多时候不是模块不够，而是审美方向不统一。
7. 给它页面叙事，不只是组件清单
这个点我觉得也很关键。
很多人让 AI 做页面的时候，给的是组件列表：
● header
● hero
● feature cards
● CTA
● footer
但页面不是部件拼装，它应该有自己的叙事。
比如：
● 先建立身份
● 再补场景
● 再讲差异点
● 最后落到动作
如果你只给模块，它就会把这些模块平均地摆出来。
如果你给的是叙事，它才知道每个 section 的职责。
我现在会直接在需求里写：
● 第一屏负责什么
● 第二屏负责什么
● 哪些内容要晚一点出现
● 哪些元素不能抢主视觉
这会比“做个漂亮页面”有效得多。
8. 验证链路要早点放进去
前端最烦的一种情况是：
代码看起来对，页面其实不对。
比如：
● 移动端溢出
● fixed 层遮住按钮
● 某个断点布局崩了
● 终端视口尺寸不对
● 页面 chrome 压到内容
这些东西只看代码经常看不出来，必须跑起来看。
所以我现在会尽量让 AI 带着验证去改，而不是只让它改完代码就算了。
最简单的方式就是：
● 跑测试
● 看截图
● 检查响应式
● 确认关键交互能点
如果能加 Playwright 这种自动化检查，会更稳。
它不是为了“显得工程化”，而是真的能减少很多肉眼不容易发现的问题。
9. 我现在让 AI 写前端的默认流程
我大概会这么做：
先写清楚边界
● 这个页面是给谁用的
● 它是管理台、控制台，还是展示页
● 哪个区域是脆弱区，不能乱改
● 哪些模块可以大胆做视觉
再给明确的 taste
● 深色还是浅色
● 克制还是热闹
● 偏产品感还是偏编辑感
● 更像工具，还是更像作品
然后给验证目标
● 桌面端要怎样
● 移动端要怎样
● 关键状态要怎样
● 不允许出现什么问题
最后再让它动手
这样出来的结果通常比“直接开始写”稳很多。
10. 说到底，前端不是堆组件
我越来越觉得，AI 前端最重要的不是“会不会生成页面”，而是你有没有把 art direction 这件事交代明白。
#博客更新
先说结论。
让 AI 写好前端，重点不是多给它一点“灵感”，而是先把它容易乱跑的边界收紧。
我这阵子在折腾一个 tmux 相关的 web 项目，页面和终端渲染被我和 AI 来回改了很久。改到最后我越来越确定一件事：
前端做不好，很多时候不是模型不会写代码，而是我们喂给它的要求太松了。
你如果只说一句“帮我做个好看的页面”，它大概率会回到最常见的网页套路：
● hero 很大
● card 很多
● badge 一排
● shadow 和 radius 也不缺
● 看起来很努力，但就是没有自己的味道
它能把东西做出来，但不一定能做成你想要的样子。
1. 先分清楚：你到底要它做什么
这个问题看起来简单，但其实最关键。
很多前端任务混着三件事：
● 页面结构：信息怎么排
● 视觉方向：看起来是什么气质
● 交互边界：哪些地方脆弱，不能乱碰
如果这三件事混在一起，AI 就会很容易把注意力放错。
比如我那个项目里，终端视口其实是最脆弱的部分。它不是普通卡片，也不是普通文本块，更不是一个可以随便加阴影、加浮层、加复杂布局的区域。
它更像一个设备边界。
所以我后来改法就变了：
● 产品骨架先稳定
● terminal 只负责 terminal
● 外层 chrome 只负责信息和操作
● 视觉装饰尽量收敛
这一步很重要。因为如果你不先告诉模型“哪个模块不能乱碰”，它就会自然而然把每个模块都当成可优化对象。
2. AI 最容易回退到模板味
这个我觉得是 AI 前端里最常见的问题。
只要 prompt 稍微模糊一点，它就会滑回训练数据里的高频网页模式。
结果通常长这样：
● 结构没错
● 组件也齐
● 配色也不丑
● 但一眼看上去就是“AI 做的”
为什么会这样？
因为模型默认会选最稳的解，而不是最有个性的解。
而所谓“稳”，对很多前端任务来说，恰好就是模板味。
所以如果你真的想让它写出有 taste 的页面，不能只让它“自由发挥”，而要给它更具体的偏好：
● 这个产品像什么
● 不是哪个风格都能用
● 哪些元素默认不要
● 哪些信息一定要先出现
● 哪些层级必须压住
这不是限制 creativity。
相反，这是在给 creativity 一个能落地的边界。
3. 第一屏不是信息仓库
我现在越来越不喜欢那种什么都往第一屏塞的做法。
很多 AI 页面看起来“内容很多”，实际上是没想清楚第一屏到底干什么。
第一屏最重要的不是堆信息，而是先把这几件事说清楚：
● 这是什么产品
● 它和别的东西有什么不同
● 用户为什么应该继续看下去
● 你这个页面的主情绪是什么
如果第一屏什么都想讲，最后通常什么都讲不清楚。
我现在比较认可的一种方法是：
● 第一屏只负责建立身份
● 第二屏再补场景
● 第三屏讲功能细节
● 最后再给操作入口
也就是每一段只做一件事。
这个原则看起来朴素，但很好用。因为 AI 很容易把 section 写成平铺直叙的内容清单，而不是有职责的页面段落。
4. 默认不要卡片，真的有用
这个判断很狠，但我发现它很好用。
很多 AI 页面的问题，本质上是太喜欢卡片了。
什么都要卡片：
● hero 里要卡片
● 特性区要卡片
● CTA 附近也要卡片
● 甚至一段说明文字也要 border + shadow + radius
最后页面就很“忙”，但没有重点。
我现在会先问自己一个问题：
如果去掉 border、shadow、background、radius，这块内容还成立吗？如果还成立，那它大概率就不该是卡片。
这个判断能帮你砍掉很多不必要的视觉噪音。
而且它特别适合拿来约束 AI，因为模型很爱“补装饰”。你不给规则，它就一直补。
5. 先定设计系统，再让它写
AI 写前端最怕的不是不会写，而是写着写着风格漂了。
今天一套颜色，明天又一套按钮，后天再换一层背景逻辑，最后整个页面就散了。
所以我现在更倾向于先定这些东西：
● background / surface / text / muted / accent
● 主要字号层级
● 按钮风格
● 间距节奏
● 圆角和边框的使用规则
这套东西最好在 prompt 之外就先写成 token 或设计说明。
因为 AI 其实挺擅长遵守“明确的系统”，不太擅长自己现场发明一套又一套。
如果你一开始就把系统定住，它后面写页面会稳很多。
6. 视觉参考比“高级”这种词更重要
“高级”“极简”“有氛围”这些词，听起来很对，但其实很滑。
模型看到这种词，往往只能往自己最熟的方向靠。
所以我现在更愿意直接给它：
● 参考图
● mood board
● 颜色锚点
● 字号节奏
● 气质描述
因为这些东西比“高级一点”这种抽象词有用得多。
前端设计不是让模型猜，而是让它有一个明确的视觉方向可以靠。
尤其是有 taste 的项目，很多时候不是模块不够，而是审美方向不统一。
7. 给它页面叙事，不只是组件清单
这个点我觉得也很关键。
很多人让 AI 做页面的时候，给的是组件列表：
● header
● hero
● feature cards
● CTA
● footer
但页面不是部件拼装，它应该有自己的叙事。
比如：
● 先建立身份
● 再补场景
● 再讲差异点
● 最后落到动作
如果你只给模块，它就会把这些模块平均地摆出来。
如果你给的是叙事，它才知道每个 section 的职责。
我现在会直接在需求里写：
● 第一屏负责什么
● 第二屏负责什么
● 哪些内容要晚一点出现
● 哪些元素不能抢主视觉
这会比“做个漂亮页面”有效得多。
8. 验证链路要早点放进去
前端最烦的一种情况是：
代码看起来对，页面其实不对。
比如：
● 移动端溢出
● fixed 层遮住按钮
● 某个断点布局崩了
● 终端视口尺寸不对
● 页面 chrome 压到内容
这些东西只看代码经常看不出来，必须跑起来看。
所以我现在会尽量让 AI 带着验证去改，而不是只让它改完代码就算了。
最简单的方式就是：
● 跑测试
● 看截图
● 检查响应式
● 确认关键交互能点
如果能加 Playwright 这种自动化检查，会更稳。
它不是为了“显得工程化”，而是真的能减少很多肉眼不容易发现的问题。
9. 我现在让 AI 写前端的默认流程
我大概会这么做：
先写清楚边界
● 这个页面是给谁用的
● 它是管理台、控制台，还是展示页
● 哪个区域是脆弱区，不能乱改
● 哪些模块可以大胆做视觉
再给明确的 taste
● 深色还是浅色
● 克制还是热闹
● 偏产品感还是偏编辑感
● 更像工具，还是更像作品
然后给验证目标
● 桌面端要怎样
● 移动端要怎样
● 关键状态要怎样
● 不允许出现什么问题
最后再让它动手
这样出来的结果通常比“直接开始写”稳很多。
10. 说到底，前端不是堆组件
我越来越觉得，AI 前端最重要的不是“会不会生成页面”，而是你有没有把 art direction 这件事交代明白。
