让 AI 写出好看的网页，不是多写几个高级形容词
最近我把 晨笙阅读 的界面又迭代了一轮，自己还挺满意。满意的点不只是“AI 帮我把页面写出来了”。更准确地说，旧版虽然能用，但视觉上还像半成品：颜色、图标和组件各说各话，阅读产品的气质没有立住。新版出来之后，它终于从“功能可用的页面”变成了“可以拿出去给人用的产品”：有统一的方向，有阅读场景的温度，也有一点精致感。
这次最大的体感是：让 AI 写出好看的网页，关键不在 prompt 里塞多少个 premium、modern、sleek。那些词当然有用，但它们太软了。真正有用的是把“好看”拆成一组 AI 能讨论、能执行、能反复检查的约束。
左边是旧版，右边是现在的移动端首页。旧版也不是不能用：有继续阅读，有搜索，有最新上架和分类列表。但它更像一套功能模块的顺序堆叠，视觉语言还停留在“把能力摆出来”。新版把阅读场景往前推了一步：继续阅读卡片变成首屏锚点，搜索和随机一本的操作距离更短，最新上架和分类都变成横向书架，底部导航让“首页 / 书库 / 设置”这些高频位置稳定下来。纸张质感只是表层，真正变化的是信息优先级和操作路径。
这件事不是一次 prompt 搞定的。我主要用了三个 skill：brainstorming、frontend-design、ui-ux-pro-max。
先别急着写 CSS
很多人让 AI 改 UI 的方式是这样的：
帮我把这个页面做得更高级一点，要有设计感，移动端也优化一下。
AI 很可能真的会开始改：加渐变、加阴影、加毛玻璃、调大圆角、塞一点动画。你会得到一个“更像 AI 写的页面”的页面。
问题不在模型不会写 CSS，而是这个请求没有设计判断。什么叫高级？这个产品是工具、杂志、仪表盘，还是阅读应用？用户打开首页是为了搜索一本书，继续上次阅读，还是随便逛逛？移动端底部该放导航，还是该把搜索固定住？
这些问题不回答，AI 只能调用它训练里最常见的视觉套路。
brainstorming 的作用就是先把这些问题逼出来。superpowers 里的 brainstorming 不是让 agent 马上开工，而是要求它先看项目、问问题、给出 2-3 个方案、讲 trade-off，再形成设计。这个步骤听起来慢，但它解决的是最容易被跳过的部分：你到底想要什么。
我在这轮迭代里会先让它讨论原型和交互，而不是直接动代码。比如移动端首页到底应该强调“书库索引”，还是强调“最近可读的新内容”；阅读页的返回路径应该回到哪里；底部导航放什么才不会变成摆设。
这也是 skill 和普通 prompt 的差别。普通 prompt 往往只是一句愿望：“做得高级一点”。skill 更像一份可复用的工作说明：先问哪些问题，必须给几个方案，什么情况下不能开工，交付物是什么。它把一次性的灵感请求，变成了每次都能复用的角色边界和检查步骤。
这个过程有点像和一个产品设计师反复争论。它不一定每次都对，但它会把隐含假设摊开：信息层级、使用路径、屏幕空间、默认状态、空状态、返回路径。只要这些东西被说清楚，后面的代码修改就不再是“凭感觉美化”。
frontend-design 负责审美，不负责玄学
我用的第二个 skill 是 frontend-design。它的价值不是提供某个固定模板，而是把视觉质量拆成几个可执行维度：
- 字体是不是有性格，而不是默认系统字体一路糊到底
- 配色是不是有主次，而不是一整页同一个色相的浅浅深深
- 空间是不是有节奏，而不是每个卡片都等距铺开
- 动效是不是服务状态变化，而不是哪里都晃一下
- 页面有没有一个明确气质，而不是“通用 SaaS 风”
这和“让页面高级一点”完全不是一回事。后者是形容词，前者是检查表。
晨笙阅读这个站点本质上是一个阅读和知识索引工具，所以我不希望它像企业后台，也不希望它像营销落地页。新版的方向更接近“安静的书房”：米白底、纸张颗粒、偏暖的品牌色、书卡横滑、分类索引。这个气质也反过来影响信息架构：首页不做巨大 hero，不写一屏自我介绍，而是把继续阅读、搜索、随机一本和可浏览书架提前。它不是最酷炫的方案，但更贴合“打开来找书、继续读、随便翻”的场景。
这里有一个很重要的经验：不要让 AI 自由发挥审美，要让它沿着一个明确方向发挥。
如果你只说“高级”，它可能给你紫色渐变、玻璃卡片、巨大的 hero、发光按钮。如果你说“这是一个移动端阅读索引，我希望它像安静的书房，信息密度适中，重点是让人愿意继续读”，它就有了更具体的判断空间。
ui-ux-pro-max 负责把页面磨到能用
好看的截图不等于好用的页面。
我把 ui-ux-pro-max 放在更靠后的环节用。它更像一个挑剔的产品设计师，盯的不是配色，而是路径、状态、可访问性和移动端交互：
- 移动端底部导航点进去之后，返回会不会乱
- 首页有没有明确的下一步
- 搜索和随机一本这种高频动作够不够近
- 书卡在小屏幕上会不会挤
- 侧边栏在移动端是不是应该消失
- 当前页面状态有没有被导航正确表达
- 触摸目标、间距、字体大小、可访问性和响应式有没有踩基础红线
这类问题很容易被工程师忽略，因为功能已经能跑了。但页面的质感经常就坏在这些小地方：按钮看得到但不好点，返回路径违背直觉，桌面端顺手但移动端像缩小版网页。
ui-ux-pro-max 的价值在这里很明显。它不是只给“好看一点”的建议，而是会盯住一些基础红线：触摸目标够不够大，导航项是不是过载，返回行为是不是可预测，页面会不会在移动端横向滚动，核心内容有没有优先出现。这些规则听起来朴素，但移动端体验经常就是在这些地方翻车。
晨笙阅读后续的几次提交其实都在磨这些问题。比如移动端底部导航不是为了“看起来像 app”才加的，而是因为首页、书库、设置这几个位置会被反复访问，藏在侧边栏里会让路径变长。再比如 book header mode，是为了让阅读页在小屏幕上保留书名、返回和目录这些必要动作，同时避免桌面端那套 header 直接压到内容上。它们单独看都不是“大 redesign”，但加在一起会改变产品的手感。
这也是我现在更喜欢的 AI 前端工作流：
- 用
brainstorming把目标和方案说清楚，产物是方案取舍。 - 用
frontend-design定视觉方向和审美约束，产物是可执行的设计语言。 - 用
ui-ux-pro-max检查交互路径、状态和移动端体验，产物是体验问题清单。 - 用截图做前后对比，产物是肉眼可验收的证据。
这套方法的核心不是“某个神奇 skill”。核心是让 agent 在不同阶段扮演不同角色。一个角色负责问问题，一个角色负责视觉，一个角色负责体验。不要指望一个“帮我优化 UI”的请求同时完成产品、视觉、交互、实现和验收。
业界还有另一条路线：先设计，再写代码
我的路径偏工程师：在代码库里迭代，用 skill 让 coding agent 补上设计讨论和审美约束。
另一条越来越明显的路线，是先在 AI 设计平台里把高保真原型做出来，再把设计系统和组件约束带回代码。这些工具不完全同类：Figma/Make 更偏设计工作流和原型，Stitch 更偏 UI 生成画布，Lovable 更偏应用生成，Webflow 更偏站点构建与设计系统落地。它们的共同点，是把设计判断前置到画布、组件和 tokens 里，而不是等 coding agent 写完页面再补救。
Figma 在 Config 2025 发布了 Figma Make 和 Figma Sites，把 prompt-to-code、网站发布和设计工作流放到同一个平台里。Google Labs 的 Stitch 也把自己定位成 AI-native software design canvas，可以从自然语言、业务目标、用户感受和参考灵感开始生成 UI。Lovable 文档里关于规划、组件拆分和真实内容的建议，指向的是同一个原则：输入越具体，结果越可控。
这条路线的优势是明显的：设计平台天然有画布、组件、tokens、团队协作和视觉评审。Figma Make 支持导入现有 Figma library 来保持颜色、排版和核心样式一致；Webflow 的 AI Site Builder 也会生成 style guide，并围绕 design tokens、utility classes、component patterns 组织页面。
但它也不是银弹。设计到代码仍然不是无损闭环。Figma Make 的 functional version 不能直接进入 Figma Design，Design 里的图层改动也不会自动回写 Make。更现实的问题是：如果你的设计系统本身平庸，AI 只会稳定地产出统一但平庸的页面。
Figma 的 2025 AI Report 里有一个很有意思的数字：78% 的受访者认同 AI 提升效率，但只有 32% 认为可以依赖 AI 输出。这个比例挺诚实。它支持的是“AI 加速产出”，不是“AI 替代质量判断”。
我现在会怎么做
如果下次我从零做一个页面，我大概率会这样开始：
先写清楚这个页面的使用场景，而不是先写 UI prompt。谁打开它？打开时想完成什么？首屏最应该让他看到什么？哪些信息只是辅助？
接着让 agent 给 2-3 个方向，不要只给一个。一个偏工具，一个偏内容，一个偏品牌。方案之间必须有取舍，否则就不是方案，只是换皮。
然后才进入视觉约束：字体、色彩、空间、动效、组件密度、移动端优先级。这里要尽量具体，不要只写“高级”。你可以说“像一个安静的阅读工具，不要营销页，不要大 hero，不要紫色渐变，不要玻璃拟态，首屏要露出可读内容”。
实现之后一定截图。最好是移动端截图。桌面端空间太宽，很多问题会被藏起来；移动端会逼你面对真实的信息优先级。按钮挤不挤，卡片有没有意义，导航是不是顺手，一眼就露出来。
收尾时再让另一个角色审一遍交互。不要让同一个 agent 刚写完就宣布自己做得很好。换一个审校角色，只看截图和交互路径，不看实现过程。它太容易爱上自己的实现。
我现在对 AI 写前端的判断是：它已经很会写代码了，但它还不天然拥有你的品味。你要做的不是把品味压缩成几个形容词，而是把品味拆成可以讨论、可以约束、可以验收的工作流。
页面的品味和取舍，终究还是人来负责。AI 能做的是把这些判断拆开、落地，并不断帮你验收。