企业官网建设流程全解析

WebDev-Skills-Bench 这类评测套件，最核心的目的不是给 Agent 打个分，而是回答一个很实际的问题：给 Agent 加的网页开发技能，到底有没有真的提升结果。我连续跑了几组对照之后，感觉这个判断比很多人想的更依赖任务类型、评测基线和观察指标。如果你准备给 Agent 配技能，或者正在做网页生成、前端辅助、小游戏开发这一类自动化流程，这篇能帮你少走弯路。

先说明一点：早期我用 Agent 做网页开发，经常是“看起来很强，一换任务就翻车”。后来把技能加进去，效果有变化，但很难说清楚到底是模型变强了，还是技能真的起作用了。WebDev-Skills-Bench 这类方式，就是把“技能有没有用”从感觉变成可比较的评测结果。下面按我自己的实测顺序拆开讲。

1. 先搞清楚 WebDev-Skills-Bench 到底在测什么

1.1 它不是普通跑分工具，而是一个“技能筛选器”

很多人一看 Bench 就以为是在测模型智商，实际不是。WebDev-Skills-Bench 更关心的是 Agent 在做具体网页开发任务时，额外注入的技能包是否带来了可量化的提升。

我理解它的评测逻辑是：同一组网页开发任务，分别让“无技能基线 Agent”和“带技能 Agent”去完成，然后对比结果。任务通常是一段需求描述加一个目标 HTML/CSS/JS 文件，Agent 需要在浏览器环境里操作、修改、运行，最后输出一个可访问的页面。关键不是“跑通一个 Demo”，而是“在相同条件下对比两次结果”。

所以，它给出的结论应该是：“技能 A 在任务类型 B 上提升了首轮通过率，但在任务类型 C 上没有明显变化。”有了这种信息，你才能决定哪些技能值得保留、哪些只是浪费 token。

1.2 评测时最该盯住三个点：完成度、稳定性和复用性

常见评测指标很多，但我实际使用中只盯三个：

• 完成度：任务要求的功能是否全部出现，是否有缺失的按钮、事件、样式或交互。
• 稳定性：同一任务跑多遍，成功路径是不是一致，是否会出现“上次能跑，这次报错”的随机失败。
• 复用性：新任务和评测任务越接近，迁移越顺畅；如果只是针对一个任务过拟合，替换成本会很高。

如果你只比对一次的成功率，很多问题会被掩盖。比如技能本身没问题，但 Agent 有时候会漏掉某个关键步骤，这时单次运行结果波动会很大。所以评测时至少同一个任务跑三到五遍，再下结论。

1.3 评测结果比“功能列表”更值得看

我见过不少团队把 Agent 包装成“拥有十个技能”，但一到真实项目就卡在路径、权限、依赖版本和输入格式上。WebDev-Skills-Bench 的价值，就是把这些干扰因素压缩到可控范围里，尽可能只暴露“技能带来的差异”。

所以拿到评测结果时，不要只看某张表上高分，而是看任务失败点集中在哪里。如果失败集中在环境相关环节，比如页面资源加载不出来、脚本执行超时，那多半不是技能问题，而是评测环境没配好。

2. 评测前必须准备好的环境与基线

2.1 浏览器环境和执行环境先固定住

网页开发类评测离不开真实浏览器行为。一般会用 headless 浏览器或浏览器自动化框架，让 Agent 能打开页面、执行 JS、检查 DOM，再截图或读取控制台日志。这一步很关键，因为很多网页任务不是“生成代码”就结束，还要确认代码真的能在浏览器里运行。

我建议在跑评测前，把以下内容写清楚：

• 浏览器版本和自动化驱动版本。
• 页面运行的基础模板，比如空 HTML、单页应用，还是带固定样式的骨架。
• 超时时间设置，尤其是页面加载和脚本执行超时。
• 输出目录和日志目录，避免多任务互相覆盖。

这些看起来是基础工作，但直接影响评测结果是否可复现。比如同一个任务，在 Chrome 126 和 Chrome 120 上的表现可能不同，尤其涉及 Canvas、WebGL、CSS 新特性的时候。

2.2 基线必须和被测 Agent 使用同一个模型

评测技能有没有用，最容易犯的错是：基线用一个模型，带技能用另一个更强的模型。这样比较出来的提升，根本不是技能带来的。

正确方式是只改变一个变量：

基线 Agent： - 模型：Model-XX - Prompt：单条任务指令 - 技能库：空 - 参数：temperature=0.2 带技能 Agent： - 模型：Model-XX（同一个） - Prompt：单条任务指令 + 对应技能描述 - 技能库：待测技能 - 参数：temperature=0.2

温度、最大 token 数、重试次数也要保持一致。很多 Agent 在低温下表现稳定，但如果你把温差跳过，可能把稳定性差异误判为技能效果。

2.3 先跑通一个最小样例，再上全量任务

我不建议一上来就跑完整评测集。第一步先选一个最简单的页面任务，比如“生成一个包含标题和按钮的静态页面”，让无技能基线和带技能 Agent 各跑一次。

这样做的原因很简单：小任务能快速暴露链路问题，比如技能没有真正加载、Agent 调不到文件、浏览器环境启动失败、输出路径写错。等这些前置问题都解决后，再逐步切换到复杂任务，比如表单交互、多页面跳转、Canvas 绘图和小游戏开发。

注意：评测过程中，尽量保留每轮运行的完整日志、截图和最终输出文件。这些材料比分数更有说服力，尤其是排查“为什么技能没触发”的时候。

3. 开发游戏给 Agent 时，到底要加哪些技能

最近常有人问：开发游戏给 Agent 需要添加哪些技能。这类问题放到 WebDev-Skills-Bench 里，其实可以拆成可验证的评测任务。游戏和普通网页开发最大的区别在于：普通页面偏静态展示，游戏偏交互循环、状态更新和实时绘制。

3.1 游戏任务和普通网页任务的差异

普通网页任务，比如“做一个产品介绍页”，Agent 只要把内容、布局、图片放好，基本就有很高完成度。游戏任务不同，它有明显的运行时特征：

• 需要一个主循环，持续更新画面。
• 玩家输入会改变对象状态，比如移动、跳跃、发射子弹。
• 不同对象需要碰撞检测。
• 分数、生命值、关卡等状态需要持久化。
• Canvas 或 DOM 动画需要的性能开销不同。

这些差异意味着，一个给普通网页任务设计的技能包，用在游戏任务上可能作用不大。评测时需要单独设计游戏类任务组，比如“实现一个接苹果小游戏”“实现角色移动和障碍物检测”“实现点击方块计分游戏”。

3.2 游戏场景下通常值得验证的技能清单

下面这份清单不是标准答案，而是我评测时会优先考虑加入的技能类型：

技能不是越多越好。一个技能如果描述太长，反而会占用上下文，让 Agent 更晚进入实际操作。评测结果里如果发现带技能后首轮 token 消耗明显增加，但成功率没有提升，那这个技能就要考虑精简。

3.3 用 Bench 验证“游戏技能”是否真的有用

我自己的做法是给每一个候选技能建一个独立任务组，比如：

taskgame-basic: 需求：实现一个 400x400 的画布，点击后出现一个红色方块。 校验：画布存在、颜色正确、点击后方块数量发生变化。 taskgame-collision: 需求：实现一个方块从上方落下，接住则得分，落到底部则生命值减一。 校验：分数更新、生命值更新、重新开始后状态复位。

跑完无技能基线和带技能 Agent 后，重点看首轮成功率、平均尝试次数和最终输出代码是否简洁。如果带技能后，任务从 5 轮尝试降到 1 轮，那这个技能就有明确价值；如果只是输出变长，成功率没变化，那就该删。

4. 单条任务跑通：最少要盯住哪几个环节

进入正式评测后，不建议急着调大并发。先把单条任务从输入到输出完整跑通，确认每个环节都符合预期，再批量执行。

4.1 任务输入格式和技能触发条件

很多任务失败，不是因为 Agent 能力不够，而是输入格式没有对齐。比如任务要求给出“具体游戏类型”，Agent 默认理解成“一个简单页面模板”；任务要求“包含音频按钮”，但技能描述里只写了“Canvas 绘制”，Agent 就不会去加载音频。

所以我会在任务描述里写清三个要素：

• 用户最终想看到什么。
• 技术边界，比如是否允许新建文件、是否只能用纯前端。
• 验收方式，比如能否通过点击按钮触发某个动作。

技能触发条件也要明确。比如“当任务中包含 Canvas、游戏、动画关键词时，加载 Canvas 绘制技能”，而不是让 Agent 自己猜测。

4.2 执行日志和错误堆栈

单条任务跑的时候，日志是判断问题的最直接依据。重点看：

• Agent 是否按预期调用技能。
• 浏览器控制台是否有 JS 报错。
• 页面最终是否停留在可交互状态。
• 是否有超时导致的半成品输出。

如果日志显示 Agent 生成了完整代码，但浏览器无反应，通常不是技能问题，而是脚本没有注入或者 DOM 更新没有触发。这时不要急着改技能，先看执行环境。

4.3 输出校验标准要提前写死

评测输出不能只看“页面能打开”，要有明确的校验规则。比如：

页面存在一个 id 为 game-canvas 的 canvas 元素。 点击按钮后，画布中出现一个 40x40 的绿色方块。 方块移动后，分数区域数值从 0 变为 1。

校验分为三个层级：DOM 结构校验、交互行为校验、视觉截图校验。DOM 和交互最好用脚本自动完成，视觉截图可以人工或模型二次判断。自动校验能减少主观误差。

4.4 失败重试有几个原则

即使评测集比较小，也要在单条任务跑通后，规划失败重试策略。我的建议是：

1. 第一次失败，保留原始输出。
2. 第二次重试可以换一次模型采样，但不能无限重试。
3. 重试超过 3 次仍未成功，标记为失败，记录失败原因。
4. 不要在同一任务里反复改参数，否则结果不可比。

重试的意义不是提高成绩，而是确认任务是否存在随机性。如果同一技能同一任务，第一次 30 秒跑完，第二次卡住，那说明技能本身或运行环境不稳定，需要先排查。

4.5 结果归因：分数提升不等于技能有效

就算带技能 Agent 的通过率提升了，也不一定说明技能有效。常见干扰因素包括：这次随机运气好、基线 Prompt 写得太简陋、技能里把任务步骤写得太具体。

判断方法：把同一个技能用在另一个相近但不完全相同的任务上，看是否还有提升。比如“接苹果游戏”技能用在“射击气球游戏”上，如果仍然有效，说明技能具备通用能力；如果完全失效，那可能它只是针对评测任务的模板。

5. 批量评测时怎么判断“技能有用”

单条任务跑通后，再上批量评测。批量评测的意义，不是把任务数堆起来，而是让结论更可信。

5.1 看成功率，更要看失败模式

批量后你会得到一张结果表，我最常用这样的对比：

光看通过率显然不够。如果带技能后通过率提升了，但失败集中在“状态管理缺失”这类任务上，说明技能覆盖范围不全。如果失败模式从“完全跑不动”变成“跑起来了但逻辑有误”，这反而是技能有效的信号。

5.2 看技能路径调用次数和 token 消耗

批量评测时，日志里通常能查到每个技能被调用的次数。如果一个技能被加入后，Agent 在绝大多数任务里都用到了它，说明技能描述和任务关联度高。如果 Agent 经常忽略技能，或者只在极少任务里触发，那可能是任务描述和技能描述之间存在语义鸿沟。

token 消耗也要看。技能本质上是把额外指令塞进上下文，每跑一次任务都会多占 token。如果一个技能让任务成功率从 40% 提升到 90%，但 token 消耗涨了一倍，那在真实生产环境里，你要权衡的是“多花一倍成本换稳定性值不值”。

5.3 看输出差异性和可维护性

另一个容易被忽略的指标是输出差异性。同一任务不带技能跑三次，输出三份风格完全不同的代码；带技能后，代码结构趋于一致，说明技能确实起到了约束作用。但要注意：一致性不等于正确性。如果 Agent 只是老老实实照技能模板写，但没理解游戏需求里的特殊逻辑，那输出虽然统一，却仍然不对。

我还会人工抽查几份代码，看注释、命名、函数拆分是否清晰。技能效果好的时候，代码通常更接近工程习惯，而不是一坨临时拼凑的脚本。

5.4 榜单数据要结合自己的任务重新验证

网上可能会有别人跑好的 WebDev-Skills-Bench 结果，但最好不要直接照搬结论。因为不同项目对“技能”的定义、任务难度和校验逻辑可能不同。我的建议是：把别人的评测结果当作线索，然后用自己最关心的任务类型去复测。

比如别人说“Canvas 技能对游戏开发无效”，但你的任务集中在粒子效果和动画，那可能要单独验证。评测的价值在比较逻辑，不在最终分数。

6. 实际踩坑与排查顺序

最后这部分，是我在评测 Agent 技能时经常遇到的问题和排查顺序。

6.1 先看是环境问题还是技能问题

遇到任务失败，第一反应不要是“技能没用”。先按这个顺序查：

1. 页面有没有被浏览器成功打开。
2. 资源文件、脚本文件路径是否正确。
3. 浏览器控制台有没有报错。
4. Agent 是否真的加载了目标技能。
5. 技能描述和任务输入是否对齐。

环境问题如果不排除，技能评测的噪声会非常大。比如浏览器下载失败、静态资源被拦截、脚本执行权限不足，都会让 Agent 输出看起来像“能力不足”。

6.2 技能加载了但没触发，常见原因

如果日志显示 Agent 拥有技能，但实际没调用，常见原因有三个：

• 任务描述太笼统，Agent 没有意识到该用技能。
• 技能列表太长，Agent 在上下文里漏掉了关键技能。
• 技能描述和任务语言不一致，比如技能里全是英文术语，任务描述是中文口语。

解决办法：把技能命名改得更贴近任务关键词，或者在任务描述里显式提示“如果任务涉及 Canvas 动画，参考 Canvas 绘制技能”。但要小心，提示语本身也可能变成一种“隐式技能”，让评测不公平。所以基线和带技能 Agent 的任务描述最好保持一致，只在技能库上做区别。

6.3 输出不稳定的排查链路

同一任务多次运行，结果时好时坏，我一般按这么查：

• 先看模型参数是否一致，尤其温度和随机种子。
• 再看浏览器是否每次都干净启动，缓存和 Cookie 是否残留。
• 再看任务输入是否可变，比如随机生成的初始状态。
• 最后看技能内部是否有随机逻辑或外部请求。

如果多跑几轮后，失败任务集中在某一个特定关卡或交互点，那很可能不是技能问题，而是任务本身存在歧义。需要在任务描述里补清规则。

6.4 低配环境也能跑评测，但要降规模

如果你的机器显存或内存不大，跑完整评测集会很吃力。我建议把评测集拆小，先选 5 到 10 个代表性任务，跑完一轮拿到稳定结论，再决定是否扩大规模。

低配环境下还要注意：

• 关闭浏览器多余动画效果，降低截图分辨率。
• 减少并发任务数，避免内存不足导致浏览器崩溃。
• 增加单任务超时时间，但不要无限等待。
• 优先用任务描述简单、输出校验明确的任务，减少模型不确定性。

评测本身是一个资源消耗型工作，但它的收益在于：让你下一次给 Agent 加技能时，不用靠猜。

最后我个人最大的感受是：Agent 技能有没有用，不能听功能列表，也不能看单个成功案例。真正该做的是把它放进类似于 WebDev-Skills-Bench 这样的可控评测里，用无技能基线去对照，用不同任务去验证泛化能力。如果你的目标只是做一两个游戏 Demo，不装技能可能也能跑；如果要反复做不同的小游戏，技能库带来的稳定性收益就是可以被量化出来的。先跑单条，再跑批量，再把失败模式拆开看，结论自然会清晰。