AI 写网页最大的问题不是功能跑不通而是“能用但不好看”。这句话我最近在 GitHub 快报第 374 期的 Agent Skills 讨论里反复看到自己实测时也踩过同样的坑给 Agent 一句话它能生成一个能点击、能跳转、逻辑还算完整的页面但配色、间距、字体层级总透着一股模板味。真正把 AI 网页设计从“能跑”推到“能看”关键往往不在换更大的模型而在于把设计经验整理成 Agent Skills让模型在生成代码之前先理解视觉规范。下面按实际落地顺序拆一遍先说清楚 AI 网页为什么丑再讲 Agent Skills 怎么用最后给出一套可以照着执行的流程和排查清单。适合正在用 AI 编程工具做网页、又对界面效果不太满意的开发者看。1. “能用不好看”到底卡在哪AI 网页设计的老问题1.1 AI 生成的页面为什么普遍缺乏设计感先说结论AI 生成的网页“能用不好看”不是模型不会写 CSS而是模型缺少一套可执行的视觉决策规则。大模型训练时见过大量代码能拼出结构完整的页面但“好看”这件事依赖的不是单个标签写对而是间距、颜色、字号、圆角、阴影之间的系统性关系。模型在缺少明确标准的情况下会倾向于输出最安全、最常见的样式组合于是你看到的结果往往是一个居中的标题、三个并排卡片、一个蓝色渐变按钮。功能没问题视觉上却没有任何记忆点。除此之外还有几个非常具体的原因没有设计栅格。AI 生成的布局常用固定像素宽度换到不同屏幕尺寸就散架或者干脆变成一行行堆叠。没有字号比例。标题、正文、注释的字体大小拉不开差距页面显得“平”。没有间距节奏。卡片内外边距随意组件之间缺乏呼吸感。状态设计缺失。鼠标悬停、输入聚焦、加载失败这些状态AI 常常直接跳过页面只在默认状态下好看。内容与样式脱节。用真实数据填充后超长文本、长英文单词、图片缺失都会让布局崩掉。这里要插一句这些问题的根源不是“AI 不行”而是提示词和工程流程里没有给 AI 提供足够的设计上下文。把大段审美要求写进提示词不是不行但每次都要重复而且上下文一长模型就容易忽略。Agent Skills 就是针对这个痛点出现的。1.2 判断“不好看”的标准先于修改很多人改 AI 生成页面时全凭感觉改完一版觉得“好像还是不对”又说不上来哪里不对。我的建议是先建立一套可检查的判断标准再动手改。下面列几个我实测时一定会看的维度检查维度具体观察点常见失败表现间距节奏页面是否使用统一间距尺度卡片内边距 16px、24px、32px 混用字体层级标题、正文、辅助信息是否有明确反差所有文字都 14px 或 16px分不出主次配色系统是否只用了主色、背景色、灰度色三个层次按钮用了 8 种颜色互相冲突对齐规则文本、组件、栅格是否对齐卡片左右边距不齐导航和内容错位状态完整度hover、focus、active、disabled 是否齐全按钮点击没有反馈输入框聚焦无边框变化响应式表现375px、768px、1440px 下是否正常手机上表格溢出图片被拉伸内容鲁棒性真实数据替换后是否依然好看标题过长换行错乱空数据时页面空白先有标准再谈审美。这样你给 Agent 提要求时说的不是“改好看一点”而是“间距统一为 4 的倍数标题和正文字号拉开两级补充 hover 和 focus 状态”。前者 Agent 能执行后者它只能继续猜。2. Agent Skills 是什么把设计经验变成 Agent 的能力2.1 Skills 和普通提示词的区别Agent Skills 这个概念最近在 GitHub 开源项目、Codex、Cursor 一类的 AI 编程工具里出现频率很高。简单说Skills 就是把某一类专业能力封装成 Agent 可以按需加载的模块。常见的实现方式是一个目录目录里包含一个说明文件和若干资源文件Agent 遇到相关任务时会去读取这些资料。它和普通提示词最大的区别在于提示词是一次性的每次生成都要重新写而且上下文一长模型就容易忽略掉Skills 是结构化的可以长期保存在项目里同一套设计规范可以反复使用。下面给一个常见结构示例my-website/ skills/ web-design/ SKILL.md references/ spacing-scale.md color-system.md typography.md examples/ good-card.html bad-card.htmlSKILL.md 里写清楚这个技能适用什么场景、Agent 需要遵循什么规则。references 里放具体的设计规范examples 里放好和不好的示例让 Agent 有对比参考。不一定是这个结构不同开源项目的 Skills 组织方式会有差异但整体思路是一致的把可复用的专家经验从“提示词里的几句话”变成“Agent 能阅读的参考资料包”。2.2 开源 Agent Skills 能覆盖哪些设计场景GitHub 快报第 374 期里提到的 Agent Skills核心价值就是让 AI 在“生成”之外具备“判断”能力。针对网页设计开源社区里出现的 Skills 大致可以分几类设计规范类封装色彩、间距、字体、栅格等规则生成页面时直接引用。组件评审类Agent 生成完页面后自动按可用性、视觉层级做一轮检查。转换类把设计变量、Tailwind 配置、CSS 变量互转减少手工同步。项目记忆类记录当前项目的设计决策避免 Agent 每次生成都从头开始。这些 Skills 的成熟度不一样使用时最好先看仓库的 README、示例数量和最近提交时间。不过对多数想改善网页设计的人来说不一定要等到某个 Skill 很成熟才用。你可以自己维护一个极简的 web-design Skill把团队的设计规范放进去让 Agent 每次生成前先读。效果通常比找一堆通用 Skill 更好因为设计本身是很主观的东西你的审美偏好和团队规范只有你自己能写清楚。3. 本地先把环境理清楚编码工具、模型和项目目录3.1 推荐的工具组合如果你的目标只是验证“Agent Skills 能不能改善 AI 网页设计”不需要很重的环境。我实测时使用的组合是一个支持 Agent Skills 的编程工具比如 Cursor、Codex CLI 或者其他开源 Agent 框架一个支持代码补全的大模型普通配置即可不一定要用参数最大的Node.js 环境用来启动本地静态服务器看页面效果Git用来管理前后版本方便对比修改。为什么这样组合因为网页设计是个高频迭代过程。你需要快速生成、快速预览、快速回退。如果不装本地预览环境每次都要把代码贴到在线编辑器里效率很低如果不做版本管理改了几轮之后想回到上一版会很痛苦。安装依赖时请注意一点不同 Agent 框架对 Skills 的识别方式不一样。有的直接读项目里的 skills 目录有的需要在配置里声明路径。如果你发现加了 Skill 后 Agent 没有反应先检查是不是没有把目录路径告诉框架而不是一上来怀疑 Skill 内容写错了。3.2 最小目录结构我建议从一开始就按“功能代码和技能资料分离”的方式安排目录my-website/ skills/ web-design/ SKILL.md references/ spacing-scale.md color-system.md typography.md src/ index.html styles/ main.css assets/ images/ output/ preview/src 放页面源码skills 放 Agent 使用的设计技能output 放生成后的预览结果。这么分开的好处是Skills 是长期资产页面是一次性产出两者混在一起的话项目一多技能文件很容易被误删或者被覆盖。建议先把 skills 当作文档资产来管理不要把它当成某个页面的附属文件。页面可以删掉重来技能资料要长期保留。4. 从“能跑”到“能看”一套实际可复用的网页生成流程4.1 先让页面功能闭环我的建议是分两轮生成第一轮只求功能跑通。给 Agent 的初始需求里把页面结构和交互行为写清楚但先不聊视觉。比如做一个体育运动的资讯页第一轮只需要明确页面包含导航、赛事列表、图文卡片、页脚卡片点击后能展开详情数据先用本地模拟数据方便测试。这一轮的最小成功标准是页面在浏览器里能打开交互能完成控制台没有明显报错。先不纠结好不好看因为你一旦把视觉和功能混在一个 Prompt 里Agent 很容易顾此失彼功能做完样式乱样式调好功能又缺事件。第一轮跑通之后进入第二轮视觉优化之前最好把页面用真实内容灌一遍。用模拟数据没问题但模拟数据的长度、数量和真实数据要接近。很多 AI 生成页面“看起来还行”一换成真实业务数据就崩原因就是测试数据和实际数据差异太大。4.2 再用 Agent Skills 做视觉规范功能跑通后再让 Agent 加载 web-design 这个 Skill进行视觉优化。这时候你给 Agent 的指令不是“美化一下”而是带明确约束的任务先读取 skills/web-design 下的规范文件检查当前页面在间距、字体层级、配色、对齐、状态、响应式六个维度上的问题按规范输出一份修改清单改完后再预览确认没有引入新的布局问题。要让这个流程走得顺SKILL.md 里的规则越具体越好。比如下面这段就是一个间距规则的示例# 间距规则 1. 所有间距使用 4px 基准即 4、8、12、16、24、32、48、64。 2. 组件内部间距优先用 16px组件之间用 24px区块之间用 48px。 3. 不要使用 13px、18px、22px 这类非基准值除非有明确理由。这里补充一下为什么规则要写这么细。模型生成长文本时注意力会被后面内容分散如果规则是“间距要协调”模型很难转化为具体像素值写成“4px 基准 具体场景取值”它就能直接执行。Agent Skills 的本质就是把人类专家才能判断的模糊标准变成模型可以套用的明确规则。4.3 验证页面好看不好看的检查清单改完之后不要只看一眼“好像顺眼了”就结束。我一般会按下面这个清单过一遍在 1440px、768px、375px 三个宽度下分别打开页面截三张图对比布局是否一致。用浏览器开发者工具的对比度检查确认正文和背景的对比度达到可读标准。逐一点击所有可交互元素检查 hover、focus、active 三种状态是否有视觉反馈。把一段超长标题和一段空数据分别塞进页面看布局是否还能保持稳定。检查控制台有没有 CSS 变量未定义、字体加载失败、图片资源 404 之类的报错。如果一个页面能同时通过这五项视觉质量基本就不算“能用不好看”了。如果只通过两三项别急着继续让 Agent 改先把没通过的那项对应的规则写进 Skill 里让下一次生成直接遵守。5. 批量生成和多页面项目时怎么守住一致性5.1 设计令牌和组件命名单个页面好看和整个网站好看是两件事。单个页面只要局部协调就能过关多个页面放在一起还要考虑跨页面的一致性。这时候最容易出问题的就是“每个页面各写各的样式”。我建议在项目里引入设计令牌也就是用一组 CSS 变量统一管理颜色、间距、字体、圆角:root { --color-primary: #1a6bff; --color-bg: #f7f8fa; --color-text: #1f2329; --color-text-secondary: #646a73; --space-sm: 8px; --space-md: 16px; --space-lg: 24px; --space-xl: 48px; --radius-sm: 4px; --radius-md: 8px; --radius-lg: 16px; --font-display: PingFang SC, Microsoft YaHei, sans-serif; --font-body: Inter, PingFang SC, sans-serif; }有了这套变量Agent 生成新页面时样式值不再凭空发挥而是从变量里取。这样不同页面之间的间距、颜色、圆角才能保持统一。你可以在 Skill 的 references 里放一份完整的令牌表并在 SKILL.md 里写明所有新页面组件都必须引用这些变量不允许出现硬编码的颜色和间距。组件命名同样重要。命名规则要稳定比如卡片类组件统一用 card 前缀按钮用 button 前缀类名禁止缩写混乱。否则项目一大Agent 在修改一个页面时很可能忽略另一个页面已经存在的同名组件导致样式互相覆盖。5.2 批量刷新时的回归检查多页面项目的第二道坎是“批量刷新”。当设计规则变化后比如主色从蓝色改成绿色你可能需要让 Agent 一次性更新十几个页面。很多人在这一步翻车因为 Agent 批量修改时很容易出现有的页面改了有的页面没改有的页面顺带把布局弄坏了。我实测比较稳的顺序是先只让 Agent 修改一个页面确认改动方式符合预期把这个页面的 diff 打开人工看一眼改动的范围确保没有“顺手”改动无关内容确认没问题后再让 Agent 批量处理其他页面批量完成后用 Git 查看所有改动文件重点检查是否有页面出现大面积无关变化对每个页面做一次响应式截图对比而不是只看代码。批量任务不能只看“能不能跑”还要看结果的可回退性。如果 Agent 在批量改的过程中把某个页面改坏了Git 就是你最后的保险。这也是我前面强调一定要用版本管理的原因。6. 排查顺序和经验边界6.1 页面变乱时先查什么用 Agent Skills 做网页设计问题不一定出在模型本身。我见过很多次“页面突然变丑”排查到最后发现是环境和输入材料的问题。给你一个固定排查顺序先看现象。是样式完全丢失、部分组件错位还是整体配色变乱样式完全丢失通常不是模型问题而是 CSS 文件路径、构建环节或者缓存问题。再看 Skill 是否被正确加载。给 Agent 的指令里确认它真的去读了 skills/web-design 目录。有的框架需要显式指定 Skill 路径漏掉这一步Agent 用的就还是默认审美。再看变量和依赖。改动 CSS 变量后哪些页面没有同步是不是有旧类名还在引用旧的硬编码值接着看数据。是不是新数据里混入了特殊字符、超长文本、缺失图片如果换回测试数据就正常问题在数据不在样式。最后看规则冲突。Skill 里新增的规则和项目原有的组件规范冲突时Agent 会不知道该听谁的表现就是“一会儿按新规则、一会儿按旧规则”。这个顺序不要跳。很多人一看到页面变丑就急着改提示词结果问题出在构建缓存白折腾半小时。6.2 哪些场景不适合完全交给 AgentAgent Skills 能解决很多问题但它不是设计团队。下面这些场景我建议不要把希望全押在 AI 上强品牌项目。品牌设计往往依赖非常主观的审美判断Agent 可以执行规范但很难帮你做品牌气质层面的决策。复杂交互动效。需要大量状态管理、动画编排、手势交互的页面Agent 生成基础结构可以但细节需要人逐帧调。高要求的无障碍场景。虽然 Skill 里可以写可访问性规则但真实效果还需要人带着读屏器、键盘导航实际测试。视觉方向探索。如果你自己都不知道想要什么风格Agent 更不知道。先由人定方向再让 Agent 按方向展开。这不算 Agent 的缺点而是工具边界。Skill 适合把已经明确的规则低成本地复制到每次生成里它不适合替代人做“从无到有”的审美决策。6.3 生产化之前要补的几件事最后说几句生产化。如果你不是只做一个 Demo而是要把 AI 生成的网页放到线上那在部署之前还要补这几件事把页面里的示例数据全部替换成真实接口数据并处理加载中、加载失败、空数据三种状态检查图片资源的体积做压缩和懒加载避免首屏加载过慢补上 Meta 标签、页面标题、描述、favicon 等基础信息清理代码里 Agent 生成的多余注释、无用样式和重复类名做一轮真实浏览器兼容性测试不要只看开发环境。这些事不一定要 Agent 来做但 Skill 里可以放一份“上线前检查清单”让 Agent 在提交代码前自动过一遍。这也是 Agent Skills 的一个很实际的使用方式不一定要它生成得多惊艳而是让它帮你守住那些容易忘记的工程底线。我个人更建议先把单个页面的视觉规范跑稳再考虑批量和组件库。这个流程的好处是每一次踩坑都能沉淀成 Skill 里的一条规则规则越多后续生成越稳定。等到你什么时候觉得“让 Agent 做出来的页面基本符合我会动手改之前的水准”那这套方法才算真正跑通了。
