让 AI 写一个页面，功能往往很快就能跑起来：导航、按钮、卡片、表格，一个不少。可打开浏览器，又总觉得哪里不对——换了项目名称，页面仿佛还是上一套；颜色很热闹，真正重要的内容却不突出；电脑上看着整齐，缩到手机宽度就开始拥挤。

于是，一个很自然的想法出现了：能不能给 AI 大量漂亮网页和 CSS，让它“学会设计”？还有一个常见判断：Claude 的前端更有设计感，GPT 更容易写成模板。

这篇文章从一个具体案例出发：做一个用于查看任务、跟踪执行步骤的 Agent 工作台。我们把同一套数据做成四个可运行版本，直接观察页面发生了哪些变化，再讨论参考素材、设计规范、Skill 和截图迭代分别解决什么问题。

案例说明：本文 A/B/C/D 是在同一开发过程中逐步构造的教学版本，使用固定的虚构任务数据。截图来自浏览器实际渲染，并非图像模型生成的页面效果图。它们用于解释设计决策，不是四次独立模型实验，也不构成 GPT 与 Claude 的能力排名。封面为 AI 生成的概念插画。

一、“模板味”首先是设计决策的重复

所谓模板味，并不等于“用了紫色”“用了卡片”或者“用了某种字体”。这些元素本身都可以被很好地使用。问题在于：无论做的是产品官网、管理后台还是 Agent 工作台，总是出现类似的首屏结构、相同的视觉强调和重复的内容组织。

例如，用户打开 Agent 工作台，是为了回答三个问题：哪个任务需要我处理？当前执行到哪里？出现问题后能看到什么依据？如果页面最醒目的部分却是一句很大的宣传口号，任务被挤到下方，视觉重心就与实际使用任务错位了。

OpenAI 的前端设计文章提到，约束不明确时，模型可能回到训练数据中常见的设计模式；Anthropic 也专门讨论过 Claude 缺少指导时容易生成相似风格的问题。这说明“默认输出趋同”并非某一家模型独有的现象。OpenAI 前端设计说明 · Anthropic 前端设计说明

落实到项目里，可以先检查这些现象：

页面现象	可能的问题	值得尝试的调整
每个区域都被装进相似卡片	所有内容获得相近的视觉权重	根据任务关系组织列表、详情和辅助信息
页面顶部很漂亮，实际内容需要向下找	首屏优先级偏向展示	把高频任务和关键状态前移
大量留白，但扫描信息仍然费劲	留白没有帮助分组	让相关内容靠近，让不同层级拉开距离
强调色到处都是	重要操作失去辨识度	明确主操作、选中状态与异常状态的用色
换一组长标题就变形	设计只适配了占位内容	用真实长度、不同状态的数据验收
桌面截图漂亮，手机上无法操作	只有静态构图，没有响应式策略	明确窄屏下的信息顺序与布局变化

与 AI 协作时，“高级、精致、有科技感”只能表达愿望。把愿望转换为可观察的页面行为，才更容易得到稳定结果。

二、给 AI 喂 CSS，有用，但需要分清“学习”的含义

在一次对话中提供网页代码，模型通常是在利用当前上下文完成任务。把参考文件放进项目、每次开发时再读取，也属于上下文复用。它不意味着模型读过一个文件，基础模型参数就被永久更新了。

真正的模型训练或微调，需要独立的数据准备、训练与评估流程。对于改善一个产品的前端，通常可以先把参考选择、设计规范和页面验收做好。提示中提供示例与模型训练，应当作为不同机制理解。OpenAI 模型优化说明

提供给 AI 的材料	更擅长传达什么	单独使用时缺少什么
一段 CSS	具体样式规则、颜色、尺寸、布局实现	对应的结构、内容和整体视觉目标
HTML 与 CSS	结构和样式之间的关系	真实渲染结果、交互状态与设计取舍
网页截图	构图、留白、层级、密度、视觉氛围	响应式规则、语义、行为和准确尺寸
设计规范	团队已经确认的规则和边界	规则在具体页面中的实际效果
组件示例	已完成组件的结构、状态和调用方式	当前业务是否适用这些组件
Skill	可以按任务加载的指导与资源	仍需确认规则适配当前项目并实际验收

只给 CSS 的一个困难是，它并不能完整表达页面。一个样式类叫 .card，究竟是商品卡片、统计卡片还是任务卡片？同一组间距规则，放进长标题和短标题中，呈现出来的密度也会不同。CSS 里还有大量与视觉目标无关的细节：兼容代码、第三方组件覆盖、历史遗留规则、构建后的类名。

因此，我更建议准备“截图＋对应局部结构＋借鉴说明”。例如：借鉴某个工作台的列表密度，借鉴另一个页面的详情分组，但保留自己的业务字段和状态含义。这样 AI 得到的是可以执行的设计意图。

材料也不宜越堆越多。如果同时塞进电商活动页、极简作品集和企业后台，却不说明取舍，模型可能把彼此冲突的元素混合起来。参考的数量应服务于当前问题，而不是成为一种“资料越多越专业”的仪式。

三、先固定案例，才知道自己究竟改了什么

本文的示例叫“序列”，是一个本地 Agent 任务工作台。任务数据固定为四条：整理设计参考、生成研究报告、检查移动端布局、核对文档更新。四条任务分别处于运行中、待确认、失败和已完成状态。

所有版本都能进行任务选择、状态筛选、关键词搜索和结果预览；这些交互仅操作页面内的固定数据，没有调用模型、工具服务或真实业务接口。页面里的耗时也是预设内容，不是性能测试结果。

四个版本的改造范围如下：

版本	改造范围	有意保留的观察点
A：默认布局	大标题、统计卡片、任务卡片、下方详情	页面看似完整，但使用重心偏后
B：调整样式	保持 A 的结构和内容顺序，修改配色、圆角与阴影	外观改善，信息位置保持不变
C：重组信息	改为导航、任务列表和执行详情，压缩概览	桌面布局改善，暂时保留固定最小宽度
D：适配与验收	在 C 的桌面方案上补窄屏重排、可读性和交互检查	关注长标题、错误、空态和键盘焦点

这里特意保留了 C 的窄屏缺陷，便于观察“桌面方案成立”与“页面交付完成”的区别。它不是一次偶然生成失败的统计样本。

同时，C 一次改变了布局、文案和信息层级，所以不能据此声称某一句提示词带来了多少提升，更不能把页面效果归因到某个单一技巧。我们能直接核实的，是具体代码和实际页面的变化。

四、A 到 B：换一套皮肤，为什么还是原来的感觉

先看 A 版。它拥有大面积渐变首屏、四个数字统计区域和四张任务卡片。所有功能元素都能找到，整体也谈不上“不能看”，但用户要先经过口号和统计区域，才能进入任务内容。

图 1：A 版实际浏览器截图。顶部版本条用于标识教学样例，不属于正式产品设计。

接着只改样式：把紫色换为绿色，把大圆角改小，去掉大部分阴影，背景换成暖白色。B 看起来更加克制，但它仍然使用同一套页面结构。

图 2：B 版与 A 版共享结构和数据，主要变化来自样式覆盖。

在本次浏览器环境、页面回到顶部、视口设置为 1440×1000 的条件下，读取元素的布局位置得到：A、B 第一排任务的顶部均为 675 CSS px；详情区域顶部均为 998 CSS px。具体数值会随字体和环境变化，但本次两版完全相同的结果说明：只改颜色、圆角与阴影，没有改变信息的进入顺序。

这也是“让 AI 再美化一下”容易反复绕圈的原因。模型可能非常认真地修改视觉属性，可你的真实不满是“操作区域太晚出现”“主次关系不清楚”。双方处理的是不同的问题。

更可执行的反馈可以这样写：

当前页面首先展示了宣传口号和重复统计卡片。
目标用户需要频繁查看 Agent 任务，而不是了解产品卖点。

本轮请调整信息结构：
1. 将任务列表和当前任务的执行详情放到首屏。
2. 将四块统计卡片合并为紧凑状态概览。
3. 保留搜索、状态筛选与结果预览。
4. 先说明区域如何重新分配，再修改实现。
5. 完成后打开页面检查，不以代码编译通过作为视觉验收。

五、B 到 C：真正改变观感的是信息层级

C 版开始重新回答这个页面的使用任务：左侧导航用于稳定定位，中间列表用于比较任务，右侧详情用于解释当前任务正在做什么。

图 3：C 版桌面实际截图。任务、状态、步骤与耗时按固定列组织，执行详情进入首屏。

这里有几项具体变化。

第一，标题从抽象宣传语改为“任务工作台”，让页面身份与内容保持一致。辅助说明只解释当前可以完成的事，不再抢占主视觉。

第二，统计数字从四个独立大卡片变成一条状态概览。数字仍然存在，但不再与任务详情争夺空间。总数、运行中、待确认、失败等信息，应该以适合扫描的方式出现。

第三，任务从并排卡片变成行。卡片适合展示相对独立、需要图片或描述的对象；当用户需要在多条记录之间比较状态、步骤和耗时，按列对齐通常更方便。这个选择来自任务性质，不是“卡片一定不好看”的规则。

第四，选中的任务与右侧详情建立对应关系。选中行使用背景和侧边线提示，详情保留任务名称与编号，减少读者判断“现在看的是哪一项”的负担。

在同一桌面检查条件下，C 的任务列表首行顶部为 487 CSS px，详情区域顶部为 346 CSS px。这个记录能说明内容进入首屏的位置变化，不能直接证明用户操作快了多少；后者需要真实用户任务测试。

设计工作中的一些“高级感”，实际来自这些不起眼的安排：对齐关系明确、视觉权重合理、信息位置稳定、状态含义一致。装饰可以锦上添花，但不能替这些安排做决定。

六、参考网页应该怎么给：先讲借鉴点，再讲边界

参考素材最有价值的作用，是减少“你脑中的页面”和“AI 猜测的页面”之间的差距。OpenAI 的前端指导建议提供视觉参考，并提前明确设计约束；它同时强调利用浏览器检查实际渲染与交互。OpenAI 前端设计指南

我建议从两个层面组织参考。

第一层是页面用途匹配。 工作台优先看工作台，文档站优先看文档站。一个精美的品牌官网可能适合传达品牌气质，但不能直接提供任务筛选、批量操作和长文本阅读的解决方案。

第二层是局部职责匹配。 一张参考图负责说明信息密度，另一张负责说明状态和详情关系。让 AI 知道每份材料解决哪一个问题，比让它“综合所有优秀网页”更容易执行。

可以给每份参考配这样一段说明：

参考 A：借鉴列表的密度、列对齐方式和筛选区位置。
参考 B：借鉴详情面板的标题层级、步骤分组和留白。

不照搬：品牌标识、原站文案、业务字段和专有素材。
产品约束：这是每天反复使用的 Agent 工作台。
主任务：定位待处理任务，查看步骤与结果。

先输出：
- 参考中适合本项目的三条规则；
- 不适合直接使用的两处设计；
- 桌面与窄屏的信息优先级。
再根据这些规则实现页面。

如果只有 CSS，也可以先让 AI 做一次归纳：哪些变量代表颜色、字号和间距？哪些选择器实现主要布局？哪些只是特定页面的覆盖规则？提炼之后再决定复用范围。

对于已有产品，现有组件和设计规范应该优先进入上下文。否则，你可能得到一个单看很漂亮的新页面，但它和其他页面的按钮、导航、表单都不一致，维护成本反而增加了。

七、设计规范要能落到代码，而不是一串形容词

“现代、专业、简洁”不容易检查。把这些词进一步落实为字体层级、间距、区域关系与状态规则，才便于实施。

下面是一份适合本案例的规范摘录。它只是这个工作台的起点，不是适用于所有网站的通用标准。

设计维度	本案例约束	检查方式
信息优先级	任务列表与当前执行详情优先	首屏截图是否能直接找到二者
配色	暖白背景、深色正文、绿色主强调	主操作与辅助信息是否容易区分
状态	运行、等待、失败、完成使用文字配合颜色	去掉颜色后是否仍能理解状态
字体	中文正文优先可读，编号使用等宽字体	长标题、中英文混排是否稳定
间距	使用有限的间距档位，区域分组保持一致	同层级元素是否出现无理由的差异
容器	列表、详情各有职责，避免重复包裹	去掉某层边框后信息是否反而更清楚
窄屏	列表在前，详情在后，标题允许换行	是否出现整页横向溢出
交互	筛选、搜索、选择和预览都有实际反馈	点击后状态与内容是否同步

代码层面可以用 CSS 自定义属性集中管理设计值。下面是一个独立的布局骨架，便于在自己的页面中实践；它不是本文完整工作台的全部代码。

<div class="agent-layout">
  <nav class="agent-nav" aria-label="工作区导航">任务工作台</nav>
  <main class="agent-main">
    <h1>任务工作台</h1>
    <div class="agent-columns">
      <section aria-label="任务列表">
        <h2>全部任务</h2>
        <button class="agent-task" type="button">
          <strong>分析移动端任务列表的异常布局与长标题换行问题</strong>
          <span>失败 · 第 2 / 5 步</span>
        </button>
      </section>
      <aside class="agent-detail" aria-label="任务详情">
        <h2>执行详情</h2>
        <p>截图资源读取失败，请检查资源后重试。</p>
      </aside>
    </div>
  </main>
</div>

:root {
  --page: #f7f7f1;
  --surface: #fffefa;
  --ink: #24392c;
  --muted: #586650;
  --line: #dce3d2;
  --accent: #245d3f;
  --space: 24px;
}
* { box-sizing: border-box; }
body {
  margin: 0;
  color: var(--ink);
  background: var(--page);
  font-family: "Segoe UI", "Microsoft YaHei", sans-serif;
  line-height: 1.6;
}
.agent-layout {
  display: grid;
  grid-template-columns: 200px minmax(0, 1fr);
}
.agent-nav, .agent-main { padding: var(--space); }
.agent-columns {
  display: grid;
  grid-template-columns: minmax(0, 1fr) 310px;
  gap: var(--space);
  align-items: start;
}
.agent-columns > * { min-width: 0; }
.agent-task {
  display: grid;
  gap: 8px;
  width: 100%;
  padding: 16px;
  text-align: left;
  font: inherit;
  color: inherit;
  background: var(--surface);
  border: 1px solid var(--line);
  overflow-wrap: anywhere;
}
.agent-task span { color: var(--muted); }
.agent-detail { padding: 20px; background: var(--surface); }
.agent-task:focus-visible {
  outline: 3px solid var(--accent);
  outline-offset: 3px;
}
@media (max-width: 1000px) {
  .agent-columns { grid-template-columns: minmax(0, 1fr); }
}
@media (max-width: 700px) {
  .agent-layout { grid-template-columns: minmax(0, 1fr); }
  .agent-nav, .agent-main { padding: 16px; }
}

这里值得留意的不是绿色色值，而是 minmax(0, 1fr)、子项的 min-width: 0、长文本换行和断点布局。它们帮助内容在可用宽度内重新组织。CSS 自定义属性则让已经确定的设计值集中复用。MDN：CSS 自定义属性

中文项目还需要单独观察字体。英文设计教程中的特殊字体，可能没有完整中文字形，最终由另一套字体回退显示。字体名字很“设计”，不代表实际中文字距、字重和行高就合适。应当用中文长标题和中英文混排检查真实渲染。

八、C 到 D：截图会暴露代码审查没发现的问题

把 C 的页面缩到窄屏，可以看到一个直接问题：工作台保留了 1200px 的最小宽度。代码可以正常执行，浏览器也没有报错，但用户只能看到页面左侧的一部分。

D 的处理不是把整个桌面界面按比例缩小，而是重新安排布局：导航压缩为顶部区域，任务列表保留主要字段，详情移动到列表下方；长标题自然换行，次要耗时信息可以在详情里读取。

图 4：两张截图均来自设置为 390×844 的浏览器视口。由于浏览器滚动条，可用内容宽度为 375px；C 的整页内容宽度为 1200px，D 为 375px。

这个对比也说明，“页面没有报错”与“用户可以顺畅使用”之间还有距离。一个按钮可能真实存在，却被挤到屏幕之外；一个标题可能完整保存在 DOM 里，却在视觉上与状态标签重叠。单看代码无法替代实际渲染检查。

本次对 D 进行的检查包括：

检查项	具体操作或条件	本次结果
状态筛选	选择“失败”	列表剩余 1 项，详情同步切换
任务详情	选择另一条任务	标题、编号与状态随之更新
结果预览	从步骤切换到结果	展示对应任务的预设结果
搜索空态	输入不存在的关键词	显示无匹配提示，详情取消旧任务内容
清除搜索	点击清除按钮	恢复 4 条记录
键盘操作	使用 Tab 移动到结果预览	焦点可见，没有只依赖鼠标悬停
窄屏与桌面	设置宽度 320、768、1440px	三种宽度下均未出现整页横向溢出

上表是本地演示的功能与布局检查，不是完整的可访问性认证，也没有证明真实后端状态同步正确。接入真实 Agent 后，还需要检查延迟、取消、重连和执行失败等状态。

文字可读性同样值得单独验收。WCAG 2.2 对普通文字最低对比度的常见要求为 4.5:1，大号文字为 3:1，另有例外条件；重排要求也有适用范围与二维内容例外。不能只凭一张漂亮截图宣称符合全部标准。W3C 文字对比度说明 · W3C 内容重排说明

在本案例里，我们实际抽查了标题、任务名称、辅助文字、详情标题和错误提示五组前景／背景颜色，对比度最低为 5.69:1。这仅代表这五组抽样颜色通过普通文字阈值检查，不能外推到每个组件和所有交互状态。

图 5：D 版选择失败任务后的实际状态。失败不只是换一个红色标签，还需要给出具体发生了什么。

九、把“再好看一点”改写为可执行的修改单

当生成结果不满意时，最容易失控的方式是要求 AI 整体重做。一次重做同时更换布局、字体、配色和交互，下一轮就很难判断哪项变化有效，也可能丢掉之前已经修好的细节。

我更建议每次记录“位置、现象、影响、目标”，并为修改排优先级：先解决遮挡、溢出与无法操作的问题，再整理信息层级，最后做视觉细节。

模糊反馈	可以执行的反馈
这个页面太普通了	首屏主要展示口号，请将任务列表与当前执行详情前移
卡片太多	统计改为一条概览，任务改为按列对齐的列表，保留详情容器
颜色再高级一点	减少非状态信息的强调色，主操作保持一致，异常使用独立语义色
手机适配一下	在 390px 视口下改为单列，详情位于列表后，长标题完整换行
字体不好看	检查中文字体回退、正文行高与标题字重，使用真实长标题验证
点击感觉不对	筛选后同步更新详情，空结果时清空旧详情，并保留可见焦点

还要给 AI 一个清晰的停止条件。比如，这轮只解决窄屏溢出与长标题，桌面的信息结构保持当前方案；检查通过后再处理颜色和间距。这样修改过程更可控，也更容易回退。

对于前端开发 Agent，最好让流程明确包含“打开页面—观察—修改—再次观察”。如果执行环境不能打开浏览器，应当如实说明视觉检查没有完成，而不是用构建成功替代验收结果。

图 6：本文建议的工作流程。箭头表示可重复的迭代过程，不代表每次都要推翻整个页面。

十、把有效经验写进 Skill，但别制造另一套固定模板

当你反复开发同一个产品时，把稳定规则保存下来很有价值：下次新增页面，不必重新解释配色、字段展示、错误状态和移动端顺序。

Anthropic 对 Skills 的说明强调按需加载指导和上下文资源。它更接近可复用的任务知识，而不是让模型永久获得一套新的参数。Anthropic：Skills 与前端设计

一个适合项目的设计资料目录可以很简单：

design/
  principles.md       # 用户、主任务、信息优先级
  tokens.css          # 已确认的颜色、字号和间距
  components.md       # 组件状态、使用范围与调用示例
  references/         # 少量匹配当前产品的参考
  review-checklist.md # 桌面、窄屏、空态、失败、键盘检查
  decisions.md        # 哪些方案被接受或拒绝，原因是什么

如果整理为 Skill，可以规定：开始开发前读取当前项目规范；先说明页面类型和主任务；实现后检查真实页面；把稳定的新规则补充到项目文档。具体文件如何自动加载，仍取决于使用的开发工具，不是创建一个文件名就必然生效。

也要防止规则变成新的审美模板。例如“所有页面必须深色”“禁止使用任何卡片”“必须出现巨大标题”都过于绝对。工作台、品牌官网、编辑器和文档页有不同的任务，应该允许不同的信息密度和视觉表达。

真正值得复用的是决策方法：为什么这里需要详情面板？为什么这里需要行式列表？为什么这个状态要让用户停下来确认？保留这些理由，后续页面才能保持一致，又不会机械重复。

十一、GPT 和 Claude 怎么比较，才不会只是在比截图

模型之间可能存在能力和默认风格差异，个人偏好也是真实的。但“我更喜欢这一张页面”与“这个模型总体更擅长前端”之间，还缺少一套一致的比较条件。

如果想做更严谨的对照，至少应记录具体模型版本、运行日期、工具环境、完整需求、参考材料、已有组件、可用时间和修改次数。不能让一方只生成一次代码，另一方经过多轮浏览器调整，再把结果都叫“一次生成”。

建议把观察维度分开：视觉层级是否清楚，是否符合给定风格，交互是否完整，窄屏是否稳定，代码是否便于维护。页面多动效不必然更适合后台，代码更短也不必然更容易扩展。

还可以先隐藏模型名称，请评审者完成相同任务，再记录他们找到失败任务、理解当前步骤、读取结果时遇到的问题。多次生成保留所有结果，说明挑选规则，避免只展示各自最漂亮的一张。

本文没有进行这种跨模型对照，因此不给 GPT 或 Claude 打分。四个教学版本只能说明：在这个工作台中，单纯换样式、重组信息、补充适配，分别会让页面发生什么变化。

十二、下一次让 AI 写页面，可以从这份任务说明开始

下面这段可以根据自己的产品调整。关键是把用户、内容、参考和验收连起来。

请为我的 Agent 应用实现任务工作台。

用户与任务：
用户每天查看多条任务，需要定位待确认或失败的任务，
查看执行步骤，并阅读对应结果。

内容：
使用有长短差异的中文任务名。
覆盖运行中、待确认、失败、已完成和无搜索结果。
演示数据必须标注，不伪装成真实执行记录。

设计：
先读取项目现有设计规范和组件。
根据参考截图说明借鉴点，不照搬品牌与业务内容。
让任务列表和当前详情形成清晰对应关系。
窄屏按使用顺序重排，状态同时使用文字与颜色。

实现与验收：
先说明信息结构，再实现一个完整关键页面。
检查搜索、筛选、任务选择与结果预览。
在桌面和窄屏下打开浏览器截图，检查溢出和长标题。
记录发现的问题，逐项修改，并说明尚未验证的部分。
最后保留已经确认的设计规则，供后续页面复用。

这份说明不会保证每次都生成满意的设计，但它让协作有了明确的方向和可检查的结果。参考图帮助表达视觉目标，设计规范帮助保持一致，真实内容暴露布局问题，浏览器验收让改进有依据。

下次看到一个充满模板味的页面，可以先问：用户要完成的事有没有被放在正确位置？关键内容有没有清晰层级？AI 有没有真正看过自己生成的页面？这些问题，往往比继续增加一批 CSS 文件更接近问题所在。

---

参考资料与复现说明

1. OpenAI：Designing delightful frontends with GPT-5.4。特定版本的指导文章，本文引用其参考素材与浏览器验收方法，不据此推断所有模型的相对表现。
2. Anthropic：Improving frontend design through Skills。用于理解默认风格趋同与可复用指导。
3. OpenAI：Model optimization。用于区分提示中的上下文与模型训练。
4. MDN：Using CSS custom properties。用于查阅 CSS 自定义属性。
5. W3C：WCAG 2.2 Contrast (Minimum)。文字对比度的适用条件与例外。
6. W3C：WCAG 2.2 Reflow。内容重排的要求与例外。

本文示例采用本地 HTML、CSS 与 JavaScript，页面截图在同一浏览器环境获取。桌面对照使用 1440×1000，窄屏对照使用 390×844；可用宽度会受到滚动条影响。A/B/C/D 为教学构造，未进行模型盲测、真实用户研究或生产负载测试。部分内容与示例实现由 AI 辅助完成，封面使用 AI 图像生成，正文页面配图为实际浏览器截图。