Vercel 跑了 200 多次，终于摸清了怎么把经验教给 Agent

Vercel 发了一篇挺有意思的文章。

讲的是他们怎么让 Agent 帮忙做网页，而且做出来还得像 Vercel。

我一开始以为，这大概又是一篇教你怎么写 design.md 的文章。

看完发现，文件只是最后摆在台面上的结果。前面那 200 多次试错才有意思：他们怎么把设计师一次次说的“这里不对”，慢慢变成 Agent 下次会自动遵守的规则。

我们现在用 Agent，经常觉得自己已经说得很清楚了。结果同一句话交给不同模型，做出来还是完全不一样。

Vercel 也遇到了这个问题。

规范都写了，为什么做出来还是不一样

Vercel 原来已经有一个 product-design skill，放在各个代码仓库里。

Agent 在仓库里干活时，不只是读几段设计原则。它还能看到真实组件、产品规则，以及已经上线的页面。

所以你告诉它“做得像 Vercel”，这句话背后其实有一大堆东西在帮它理解。

但 Vercel 还有很多报告、续约方案、Benchmark 和一次性页面，并不是在这些仓库里做的。外面的工具读不到内部组件，也看不到那些现成案例。

那怎么办？

最自然的想法就是，把 product-design 里的东西全整理出来，做成一份公开 Prompt。任何 Agent 都能通过一个 URL 读取。

Vercel 真这么做了。

结果还是不行。

因为很多我们觉得已经说得很清楚的话，对模型来说其实还是模糊的。

比如“保持布局干净”。

人看到这句话，大概知道什么意思。但模型还得自己决定：留多少白？标题多大？表格多宽？结论和证据谁先出现？

在代码仓库里，现成组件和上线页面会替它回答这些问题。变成一份公开 Prompt 后，只剩下一堆文字，不同模型自然会各自理解、各自发挥。

Vercel 后来干脆把第一次搬运的版本放弃了，重新从零写 design.md。

但这次他们加了一个条件：每写进去一条新规则，都要拿真实页面跑一遍，看结果到底有没有变好。

他们先拿一份续约方案试了试

Vercel 选了一份续约方案，做了最简单的一次对比。

模型一样，Prompt 一样，数据一样，页面尺寸也一样。唯一的区别，是一边加载 design.md，另一边不加载。

而且两边都只生成一次，不重新抽卡。

没有 design.md 的那一版，很像我们常见的 SaaS Dashboard：几张指标卡、两套方案、一个推荐结论，再放一张信息表。

东西都有，但你第一眼不知道自己应该先看什么。

加载 design.md 以后，页面先告诉读者推荐哪套续约方案，再解释这个建议成立的条件。两套金额放在同一个尺度上比较，支撑细节还在，但不会和结论抢注意力。

左边更像一张通用 Dashboard，右边直接围绕“该不该续约”组织信息。来源：Vercel 官方文章。

我觉得这张图很能说明问题。

design.md 改变的不只是字体和颜色，它还在告诉 Agent：这个页面是给谁看的，他打开页面是为了干什么，什么信息应该先出现。

所以，同样是 Vercel 的字体、颜色和间距，不同页面也不会都长成一个模板。

交互式规划页会把操作控件放在前面，因为人家进来就是为了改数字；续约方案先讲推荐，因为读者是来做决策的。

design.md 其实只做了一部分工作

我看到这里时，以为答案就是“把 design.md 写得更细”。

但 Vercel 后来做的，恰恰不是继续把 Prompt 写长，而是把不同问题分开处理。

需要 Agent 判断的东西，留在 design.md 里。

比如读者想完成什么、证据怎么组织、页面怎么兼顾快速浏览和详细审计、文案怎么表达具体结论和诚实边界。

他们还会直接给常见的 AI 设计毛病起名字：滥用渐变和光效、卡片里面继续套卡片、所有页面都是居中大标题加卡片网格、明明没有比较关系却不停地堆指标框。

Vercel 直接把不想再看到的“AI 默认设计”列进 design.md。问题有了名字，Agent 才更容易识别。来源：Vercel 官方文章。

但字体、间距、表格和图表样式这些已经确定的东西，他们不再让 Agent 每次重新设计，而是直接放进一个公共 stylesheet。

Agent 只需要在 HTML 里调用规定好的 class 和 token。CSS 等浏览器渲染时再加载，也不用占模型的上下文。

读者是谁、信息怎么排，Agent 还得判断，这些放在 design.md。至于表格有没有白白浪费页面宽度，代码一跑就知道，那就交给检查。构图到底顺不顺眼，最后还是人来看。

有个表格的例子特别具体

Vercel 一共准备了 7 个固定场景，里面有性能报告、续约方案、Benchmark、交互式规划页、安全治理简报和演示文稿。

每个场景的 Prompt、模拟数据和渲染条件都固定下来。完整跑一轮时，Claude Opus 4.8 和使用 GPT-5.5 的 Codex 都要把这些场景跑一遍。

他们还做了一个本地评测工具。每次运行用的 Prompt、输入、模型版本、design.md 版本、页面截图和人工反馈都会留下来，还能做盲测 A/B。

原文里有个表格的例子，我觉得特别容易理解。

一份方案里的商业条款表，明明旁边还有很多空间，Agent 却把它挤在和正文一样窄的区域里。

设计师 Review 时提了一句：证据表格应该使用完整可用宽度。

如果只是普通改稿，把表格拉宽，这次就结束了。

Vercel 多做了一步。他们回头看之前的页面，发现这个问题不是第一次出现。

于是，这句话被放进了两个地方：design.md 里增加一条规则，代码里再加一个检查。以后 Agent 再生成页面，前面有规则提醒，后面还有程序兜底。

左边的表格被压在正文窄栏，右边改成使用完整可用宽度。来源：Vercel 官方文章。

这就是他们反复做的事情：生成，Review，发现问题，判断问题应该进入哪一层，然后再生成一次。

一条规则如果只救了当前页面，却把另一个场景搞坏了，就要继续改，甚至撤回。

如果只是某个模型偶尔抽风，也不会马上写成全局规则。等它重复出现，再决定要不要沉淀。

这套东西，他们真跑了 200 多次

前前后后，Vercel 跑了 200 多次。

这里面有完整的评测轮次，也有只针对某一个问题的测试，还有很多没有走通的尝试。

同一类续约方案在不同轮次中的输出。图里只放了部分结果，但每一轮都有反馈。来源：Vercel 官方文章。

最后，他们挑了 3 个桌面场景，让 Codex 使用 GPT-5.5 分别在加载和不加载 design.md 的情况下各生成一次，一共 6 个页面，全部保留第一次结果。

程序检查出来的已知错误，加载 design.md 的页面有 39 个，没有加载的有 91 个。少了 57%。

这个数字挺好看，但不能理解成“页面质量提升了 57%”。

因为程序只能抓住团队已经见过、命名过、写进检查里的错误。6 个页面也远远证明不了稳定性。事实上，这 6 个页面全都有至少一个问题严重到不能直接上线。

这组结果能说明的，是他们写进去的那些纠错确实更少复发了。

上线以后，他们还在继续收集“吐槽”

固定场景可以帮 design.md 上线。上线以后，这套东西能不能继续进步，还得看每天的真实使用。

Vercel 员工可以在 Slack 里直接 @design-agent，让它做设计诊断、改文案、推荐图标，或者把一组数据做成报告网站。

Agent 会加载最新的 design.md 和 stylesheet，然后把页面截图和部署链接发回讨论串。后面的反馈和修改也都留在同一个地方。

每周，Slack 里的反馈、GitHub Review 和 Figma 评论会被汇总。自动化先把重复出现的意见归到一起，再由人判断，这个问题到底该改 design-agent、仓库里的 skill、design.md、stylesheet，还是代码检查。

如果大家开始做一种以前没有测试过的页面，它就会变成一个新的 eval 场景。

所以他们上线以后也没把 design.md 当成定稿，每周还在继续改。

如果我们想照着做，不用先跑 200 次

我觉得可以从一份周报开始。

先用现在的 Prompt 跑一次，把输入、模型版本和结果都留下来。哪怕做得很难看，也别重新抽卡，这一版就是后面对比的基线。

再翻一翻最近十次自己改过的周报。你总在改什么？是把结论往前挪，删掉没用的背景，还是给每个数字补来源？

“做得更专业一点”这种话没法留下来。“结论必须出现在第一页”“每个数字都要带来源”，才是下次还能继续用的要求。

这些要求也别全塞回 design.md。每次都一样的做成模板；程序一眼就能判断对错的，直接加检查；只把确实需要 Agent 判断的部分留在 guidance 里。

做完以后，用同样的输入、模型和输出条件再跑一次。最好把前后两版打乱再看，免得自己偏心。

这一小轮真有用，再考虑隐藏测试集、多模型评审和自动化工具。现在就建平台，还太早。

我最后记住的是两句话

我从这篇文章里记住的是：同一个错误如果还会再出现，这次修改就不该只留在这一张页面里。

写 Prompt 想的是：我该怎么告诉 AI，把这一次任务做好？

Agent Engineering 想的是：我该怎么设计一个环境，让 AI 即使没那么聪明，也很难把这件事做错？

Vercel 前面那 200 多次运行，都在一点点回答第二个问题。

来源与说明

• Vercel 官方文章：How our agents build on-brand pages with design.md，John Phamous，2026-08-31。