这次我们看一个很值得聊的问题当 LLM 真的去规划一个真实 Web 应用时哪一类 devtools 最占优这个标题来自 Hacker News 上的一个 Show HN 项目帖但它本质上是 Agentic Development 时代绕不开的评测题。现在大家讨论的焦点经常是“哪个模型写代码更强”而实际工程里更关键的问题是给 LLM 配上一套可调用、可读、可反馈的开发工具链之后它能不能把“规划一个真实 Web 应用”这件事完整跑通并且跑得稳。很多人第一反应是比模型但真实跑过几轮之后会发现模型之间的差距往往没有工具链之间的差距大。同一个模型配上有浏览器 DevTools 自动读取控制台报错的能力和只能靠人工截图回传报错完成同一个修复任务的轮次和成功率差别很大。浏览器 DevTools、编辑器扩展、终端命令、接口调试工具、MCP 服务这些看似外围的工具实际决定了 LLM 在“理解现状、执行改动、验证结果”这个闭环里能走多远。所以 devtools 的选型正在变成 LLM 工程里的一个硬话题。这篇文章不打算直接给出“某某工具夺冠”的结论因为不同任务、不同模型、不同权限配置下结果会变化。更靠谱的做法是给出一套可以复用的评测方法先确定评测维度再搭一个 LLM devtools 的测试工作流然后用几个典型的 Web 应用开发任务做效果验证最后补齐资源占用观察和问题排查清单。文章里涉及的命令、配置和脚本都是通用模板你可以直接在自己的环境里改成实际路径后运行。1. 核心评测维度速览要回答“哪些 devtools 会赢”首先要明确我们在比什么。LLM 规划真实 Web 应用的链路通常包含几个阶段理解需求、读取现有代码、生成改动、执行命令验证、根据报错修复、最后确认效果。每个阶段依赖的工具不同因此评测不能只看单一工具而要看整套工具链在闭环里的表现。下面这张表是建议的评测维度框架也是后续所有测试场景的评分依据评测维度考察内容关键判断标准可调用性LLM 能否通过 API、MCP 或命令行自动调用该工具调用成功次数 / 总尝试次数信息结构化程度工具返回的内容是否便于 LLM 直接消费Console 文本、JSON、日志比截图更利于模型读取反馈闭环速度从执行动作到拿到验证结果需要多少轮轮次越少越好排错能力报错信息是否能定位到文件、行号、请求参数错误信息完整且可操作权限边界工具是否支持最小权限、人工确认、命令回滚防止误操作越权批量扩展性能否批量执行、批量记录、接入评测脚本可脚本化程度这张表的逻辑是不要用“哪个工具名气大”来判断而是用“LLM 能不能稳定调用它、它返回的信息能不能直接被模型消费”来判断。例如浏览器 DevTools 的 Console 报错是纯文本LLM 可以直接读Network 面板里的瀑布图是图形如果没有结构化导出模型拿到手只能“看个大概”。这种差异会在真实任务里被放大。1.1 为什么浏览器 DevTools 是核心变量在真实 Web 应用开发里前端报错、网络请求、DOM 状态、接口返回这些关键信息都集中在浏览器 DevTools 里。LLM 要修复一个页面问题前提是能拿到控制台报错、Network 请求状态和页面截图这三类信息。能通过 Chrome DevTools Protocol 直接操作 DevTools 的工具链可以把“改代码-刷新-读报错-再改”的循环压缩到几秒一轮做不到这点的工具链只能靠人工把报错内容复制回来信息延迟和丢失都会明显影响模型判断。所以从评测角度看浏览器 DevTools 的可自动化能力是最大的变量之一。1.2 为什么 MCP 成为关键拼图MCP 是当前把模型和 devtools 连接起来的主流协议。MCP server 可以把浏览器操作、文件读写、终端执行、接口请求统一封装成模型可调用的工具模型不再需要理解每个工具各自的私有协议只需要按照统一的函数调用格式发起请求。这个抽象层的好处是同样的浏览器自动化能力可以复用到不同的模型和不同的客户端上。因此是否支持 MCP已经成为一个 devtools 是否适合 LLM 工作流的重要判断标准评测时也建议把 MCP server 的配置成本、稳定性、社区生态一并纳入考量。2. 适用场景与使用边界2.1 这套评测适合谁如果你是 AI 应用工程师、前端团队的技术负责人或者正在做 LLM Agent 平台选型这套评测方法能直接用在工具链决策上。常见的使用场景包括在多个代码助手之间做横向对比、给团队内部 Agent 挑选浏览器自动化方案、确定 MCP server 的接入优先级以及评估“让 LLM 自动读 DevTools 报错并修复”这类能力能不能上生产。评测结果也可以作为团队引入 AI 编码流程前的风险清单避免上线以后才发现权限模型不合理。2.2 不适合什么场景这套方法不适合对确定性要求极高、不允许自动执行命令的环境。比如线上生产库的操作、涉及支付和用户隐私的数据变更不应该让 LLM 通过 devtools 或终端直接操作。另外如果团队完全没有引入 AI 编码的计划也没有 Agent 工具链那这套评测的投入产出比就很低不如先把基础的代码规范和人工 review 流程做好。同样如果评测任务本身涉及大量现有系统的历史遗留问题模型在有限上下文里很难完成这类任务也不建议纳入自动评测范围。2.3 安全与合规边界涉及 LLM 自动操作 devtools 和终端时必须注意几条线。第一不要在 devtools 控制台里粘贴不明来源的代码。社区里一直在提醒不要把自己不了解、未审阅的代码粘贴进控制台这可能导致账号或数据进行非预期操作。这个提醒同样适用于 LLM 生成的代码凡是模型建议在控制台执行的脚本都要先人工审阅。第二涉及个人项目、公司项目或者第三方接口的评测要使用脱敏数据和测试账号不要把生产环境的数据传给任何第三方模型 API。第三如果工具链包含人脸、声音、隐私信息相关的 Web 功能必须先确认授权再让模型去规划或调用。3. 环境准备与前置条件3.1 硬件与操作系统评测环境建议准备一台可以长时间运行的开发机因为批量任务通常要跑几个小时。操作系统用 Windows 10/11、macOS 或 Linux 都可以只要下面的软件能正常安装跑出来的结果没有本质差别。如果使用云端模型 API评测机的 CPU 和内存够跑浏览器和 Node 服务即可对显卡没有硬性要求如果要在本地跑开源模型则建议准备独立显卡显存大小取决于模型规格。同一家模型不同量化版本的显存占用差别可以很大建议以模型官方文档给出的显存要求为准再用 nvidia-smi 或系统任务管理器观察实际占用不要在评测中途随意切换模型。3.2 软件依赖先确认基础环境node -v npm -v python --version git --version建议安装的软件清单Chromium 系浏览器用于 DevTools 自动化和页面截图。VS Code 或其他支持 MCP 扩展的编辑器。Playwright 或 Puppeteer用于浏览器自动化控制。一个支持 OpenAI 兼容接口的模型服务可以是云端 API也可以是本地推理服务。3.3 模型接入方式选择第一次做评测建议用云端模型 API原因是稳定性和速度更容易控制方便把变量聚焦在 devtools 上。本地模型的好处是数据不出机器但推理速度和显存会引入额外变量。如果你本来就在用本地模型建议固定同一个模型跑完全部场景不要在评测途中切换模型否则结果无法横向对比。评测前最好先跑一次空任务确认模型服务、网络代理、API Key 这类基础配置都就绪再开始正式任务避免把环境问题误判成工具链能力问题。4. 搭建 LLM devtools 评测工作流4.1 用 MCP 打通模型与浏览器MCP 是目前连接 LLM 和外部工具的主流方式。以浏览器 MCP server 为例安装 Playwright MCP 后模型就可以通过工具调用打开页面、点击元素、读取控制台日志、截图。安装命令参考npm install -g playwright/mcp然后在 MCP 客户端配置文件中注册这个 server。常见的位置是项目根目录的 .mcp.json 或编辑器内的 MCP 配置具体以客户端文档为准{ mcpServers: { playwright: { command: npx, args: [playwright/mcplatest] } } }配置完成后在支持 MCP 的客户端里重连会话如果能看到 playwright 相关工具列表说明模型已经具备浏览器操作入口。4.2 配置浏览器自动化入口Playwright MCP 底层通过浏览器调试协议工作启动后默认会拉起一个带调试端口的浏览器实例。如果环境里有多个浏览器需要明确指定可执行文件路径避免自动化控制错了浏览器。首次运行建议用无痕模式避免模型访问到个人登录态的网站也避免评测过程受浏览器插件干扰。这里尤其要注意端口冲突问题如果本机已经有一些服务占用了调试端口需要显式指定一个空闲端口否则 MCP server 会启动失败。4.3 建立最小评测项目骨架建议准备一个独立的评测项目目录里面放三个子目录tasks 存放任务描述文件src 存放被测项目代码logs 存放每轮评测日志。这样一个任务跑完所有过程产物都有地方放方便后面统计成功率和定位失败原因eval-runner/ ├── tasks/ # 任务描述每个任务一个 md 文件 ├── src/ # 被测 Web 项目 ├── logs/ # 模型日志、控制台输出、截图 └── results/ # 评分表和指标汇总5. 功能测试场景与效果验证5.1 场景一从零规划并实现一个待办事项应用这是最基础的场景用来测试 LLM 在“规划 生成 启动 验证”完整闭环里的表现。任务描述建议写成下面这样包含明确的功能验收标准使用 HTML CSS JavaScript 实现一个待办事项应用。 功能要求 1. 可以新增待办事项。 2. 可以勾选完成。 3. 可以删除待办事项。 4. 页面刷新后数据不丢失。 验收标准应用能通过本地静态服务启动所有功能页面内可操作。观察重点有三个模型是否能规划出合理的文件结构是否能自动启动本地静态服务是否能通过浏览器自动化完成“新增-勾选-删除-刷新”的操作验证。如果模型只会生成代码但不知道怎么启动和验证说明 devtools 的“验证闭环”这一环没打通。这个场景最适合做第一轮冒烟测试环境没配置好的话很快就能暴露出来。5.2 场景二修复现有项目的前端报错这个场景最能体现浏览器 DevTools 的价值。准备一个故意引入报错的小项目比如在 React 或 Vue 项目里写一个 undefined 变量引用或者把接口地址写错。任务描述只给一句“页面打开后控制台报错请修复”。此时观察模型是否会自动打开 DevTools 读取 Console 报错、是否会在 Network 面板里检查请求状态、是否能把报错定位到具体文件和行号。如果工具链不支持读取控制台模型只能靠猜错误定位的轮次会明显增加。改完代码后还需要刷新页面重新验证人工操作对应 DevTools 里的 CtrlR 刷新自动化链路里则是让模型调用浏览器 reload 接口并重新读取 Console 日志。这个“改代码-刷新-读报错”的循环越短排错越快。对照组设计一组允许模型自动读取控制台另一组只给模型“页面截图回传”对比两组修复成功的轮次和耗时。这个对比结果往往比模型之间的参数对比更有说服力也是评测 devtools 价值最直观的证据。5.3 场景三接口联调与 Mock 数据真实 Web 应用绕不开接口联调。这个场景测试的是模型能否使用接口调试工具或命令行发起请求、比对返回结果、生成 Mock 数据。比如任务描述是“后端尚未就绪请基于接口文档生成 Mock 数据并让页面正常展示”。观察重点包括模型是否能读懂接口文档能否用 curl 或脚本请求测试接口能否把返回结果转换为页面需要的结构。接口调试工具如果能被模型直接调用并返回结构化 JSON这个场景的表现会明显更好。如果工具链只支持图形化接口调试而不提供命令行或脚本入口模型基本无法独立完成这个任务。5.4 场景四运行效果与响应式验证这个场景用来测试页面在真实浏览器里的表现。任务描述可以是“检查页面在 375px 和 1440px 两种宽度下是否正常并修复溢出问题”。模型需要通过浏览器自动化切换视口、截图并对比两张截图来发现问题。DevTools 的设备模拟模式在这里很关键。如果工具链支持直接设置视口尺寸并截图模型就可以自主完成验证如果只能靠人工截图这个场景基本无法自动化。判断成功的标准是两次视口切换下页面都没有横向滚动条关键按钮和卡片没有明显错位模型能基于截图给出修复方案。5.5 评分记录表每个场景跑完后按下面这张表记录结果方便后面做横向对比场景完成轮次成功率关键卡点使用的 devtools备注待办事项应用3成功启动服务终端 浏览器自动化共 12 次工具调用修复前端报错2成功读取 Console浏览器 DevTools对照组多了 6 轮接口 Mock4部分成功接口文档理解curl 脚本数据结构错误响应式验证2成功视口切换浏览器设备模拟无表格里的数值只是记录格式示例实际跑出来的数字以你自己环境为准。正式评测建议至少跑三轮取平均值并且把每轮的日志都归档避免只留一个最终结果导致后面无法复盘。6. 接口 API 与批量评测任务6.1 单任务 API 调用模板如果模型服务提供 OpenAI 兼容接口可以直接用脚本把任务描述发给模型再把模型回复里声明的工具调用记录下来。下面是一个最小调用模板需要替换成你自己的 API 地址和模型名import requests url http://127.0.0.1:8000/v1/chat/completions payload { model: your-model-name, messages: [ {role: system, content: 你是一个 Web 应用开发助手可以使用浏览器工具完成页面验证。}, {role: user, content: 请实现一个待办事项应用并验证新增和删除功能。} ], tools: [ { type: function, function: { name: browser_console_read, description: 读取浏览器控制台日志, parameters: {type: object, properties: {}} } } ] } response requests.post(url, jsonpayload, timeout300) print(response.json())6.2 批量评测与指标收集要比较“哪些 devtools 更占优”单跑一个场景不够建议把任务脚本化。准备一个任务列表文件每个任务包含任务描述、验收标准、预期指标[ { task_id: todo-app, description: 从零实现待办事项应用, acceptance: 新增、勾选、删除、刷新后数据保留, max_rounds: 10 }, { task_id: fix-console-error, description: 修复页面控制台报错, acceptance: 控制台无报错页面正常渲染, max_rounds: 10 } ]批量跑的时候每轮任务把模型输出、工具调用记录、浏览器截图都写到 logs 目录文件名带上 task_id 和时间戳。最后统计三个核心指标任务成功率、平均轮次、平均 token 消耗。如果需要跑多组对照组可以固定模型、只切换 devtools 配置这样差异来源就落在工具链上。6.3 结果判定与重试策略结果判定要尽量自动化。能写断言的任务用脚本断言页面状态不能自动判定的保留截图和日志人工复核。批量任务有一个常见问题某个工具调用偶发失败导致整个任务失败。建议对工具调用失败做一次重试对任务本身做三次以内的重试超过次数就标记为失败并保留失败现场不要无限重试浪费时间。最终写入结果表时把“重试后成功”和“一次成功”分开标记这样能看到工具链的稳定性差异。7. 资源占用与性能观察7.1 值得记录的指标LLM devtools 的评测不只是“能不能成功”还要关注成本。建议记录这些指标单任务总耗时从发出任务到验收完成的时间。工具调用次数模型为了完成一个任务调用了多少次浏览器、终端、接口工具。token 消耗模型推理的输入输出 token 总量。浏览器内存占用自动化浏览器实例通常比普通浏览器占更多内存。本地模型的显存占用如果跑本地模型用 nvidia-smi 观察。7.2 显存与推理延迟云端模型不存在显存问题但要关注接口延迟。本地模型需要关注显存和上下文长度。显存占用要以实际模型版本和推理参数为准不同量化格式、不同最大 token 设置都会影响占用。如果显存不足优先降低上下文长度、减小 batch、关闭并行请求再考虑换小一号的量化模型。评测过程中如果发现某一轮特别慢要区分是模型推理慢还是工具调用超时前者看模型服务日志后者看工具超时时间配置。7.3 降低资源占用的做法浏览器自动化实例尽量复用不要每个任务重新启动否则内存开销会成倍增加。批量评测时要限制并发数通常同时跑 1 到 3 个任务比较稳定并发太高容易把浏览器和控制端拖垮。日志文件要按任务拆分不要所有任务写进同一个文件否则后面排错很痛苦。如果评测机内存紧张可以限制浏览器页签数量关闭不用的后台选项卡只保留当前任务页面。8. 常见问题与排查方法问题现象可能原因排查方式解决方案MCP server 启动失败 LLM 规划 Web 应用谁最占优？DevTools 选型评测指南
这次我们看一个很值得聊的问题当 LLM 真的去规划一个真实 Web 应用时哪一类 devtools 最占优这个标题来自 Hacker News 上的一个 Show HN 项目帖但它本质上是 Agentic Development 时代绕不开的评测题。现在大家讨论的焦点经常是“哪个模型写代码更强”而实际工程里更关键的问题是给 LLM 配上一套可调用、可读、可反馈的开发工具链之后它能不能把“规划一个真实 Web 应用”这件事完整跑通并且跑得稳。很多人第一反应是比模型但真实跑过几轮之后会发现模型之间的差距往往没有工具链之间的差距大。同一个模型配上有浏览器 DevTools 自动读取控制台报错的能力和只能靠人工截图回传报错完成同一个修复任务的轮次和成功率差别很大。浏览器 DevTools、编辑器扩展、终端命令、接口调试工具、MCP 服务这些看似外围的工具实际决定了 LLM 在“理解现状、执行改动、验证结果”这个闭环里能走多远。所以 devtools 的选型正在变成 LLM 工程里的一个硬话题。这篇文章不打算直接给出“某某工具夺冠”的结论因为不同任务、不同模型、不同权限配置下结果会变化。更靠谱的做法是给出一套可以复用的评测方法先确定评测维度再搭一个 LLM devtools 的测试工作流然后用几个典型的 Web 应用开发任务做效果验证最后补齐资源占用观察和问题排查清单。文章里涉及的命令、配置和脚本都是通用模板你可以直接在自己的环境里改成实际路径后运行。1. 核心评测维度速览要回答“哪些 devtools 会赢”首先要明确我们在比什么。LLM 规划真实 Web 应用的链路通常包含几个阶段理解需求、读取现有代码、生成改动、执行命令验证、根据报错修复、最后确认效果。每个阶段依赖的工具不同因此评测不能只看单一工具而要看整套工具链在闭环里的表现。下面这张表是建议的评测维度框架也是后续所有测试场景的评分依据评测维度考察内容关键判断标准可调用性LLM 能否通过 API、MCP 或命令行自动调用该工具调用成功次数 / 总尝试次数信息结构化程度工具返回的内容是否便于 LLM 直接消费Console 文本、JSON、日志比截图更利于模型读取反馈闭环速度从执行动作到拿到验证结果需要多少轮轮次越少越好排错能力报错信息是否能定位到文件、行号、请求参数错误信息完整且可操作权限边界工具是否支持最小权限、人工确认、命令回滚防止误操作越权批量扩展性能否批量执行、批量记录、接入评测脚本可脚本化程度这张表的逻辑是不要用“哪个工具名气大”来判断而是用“LLM 能不能稳定调用它、它返回的信息能不能直接被模型消费”来判断。例如浏览器 DevTools 的 Console 报错是纯文本LLM 可以直接读Network 面板里的瀑布图是图形如果没有结构化导出模型拿到手只能“看个大概”。这种差异会在真实任务里被放大。1.1 为什么浏览器 DevTools 是核心变量在真实 Web 应用开发里前端报错、网络请求、DOM 状态、接口返回这些关键信息都集中在浏览器 DevTools 里。LLM 要修复一个页面问题前提是能拿到控制台报错、Network 请求状态和页面截图这三类信息。能通过 Chrome DevTools Protocol 直接操作 DevTools 的工具链可以把“改代码-刷新-读报错-再改”的循环压缩到几秒一轮做不到这点的工具链只能靠人工把报错内容复制回来信息延迟和丢失都会明显影响模型判断。所以从评测角度看浏览器 DevTools 的可自动化能力是最大的变量之一。1.2 为什么 MCP 成为关键拼图MCP 是当前把模型和 devtools 连接起来的主流协议。MCP server 可以把浏览器操作、文件读写、终端执行、接口请求统一封装成模型可调用的工具模型不再需要理解每个工具各自的私有协议只需要按照统一的函数调用格式发起请求。这个抽象层的好处是同样的浏览器自动化能力可以复用到不同的模型和不同的客户端上。因此是否支持 MCP已经成为一个 devtools 是否适合 LLM 工作流的重要判断标准评测时也建议把 MCP server 的配置成本、稳定性、社区生态一并纳入考量。2. 适用场景与使用边界2.1 这套评测适合谁如果你是 AI 应用工程师、前端团队的技术负责人或者正在做 LLM Agent 平台选型这套评测方法能直接用在工具链决策上。常见的使用场景包括在多个代码助手之间做横向对比、给团队内部 Agent 挑选浏览器自动化方案、确定 MCP server 的接入优先级以及评估“让 LLM 自动读 DevTools 报错并修复”这类能力能不能上生产。评测结果也可以作为团队引入 AI 编码流程前的风险清单避免上线以后才发现权限模型不合理。2.2 不适合什么场景这套方法不适合对确定性要求极高、不允许自动执行命令的环境。比如线上生产库的操作、涉及支付和用户隐私的数据变更不应该让 LLM 通过 devtools 或终端直接操作。另外如果团队完全没有引入 AI 编码的计划也没有 Agent 工具链那这套评测的投入产出比就很低不如先把基础的代码规范和人工 review 流程做好。同样如果评测任务本身涉及大量现有系统的历史遗留问题模型在有限上下文里很难完成这类任务也不建议纳入自动评测范围。2.3 安全与合规边界涉及 LLM 自动操作 devtools 和终端时必须注意几条线。第一不要在 devtools 控制台里粘贴不明来源的代码。社区里一直在提醒不要把自己不了解、未审阅的代码粘贴进控制台这可能导致账号或数据进行非预期操作。这个提醒同样适用于 LLM 生成的代码凡是模型建议在控制台执行的脚本都要先人工审阅。第二涉及个人项目、公司项目或者第三方接口的评测要使用脱敏数据和测试账号不要把生产环境的数据传给任何第三方模型 API。第三如果工具链包含人脸、声音、隐私信息相关的 Web 功能必须先确认授权再让模型去规划或调用。3. 环境准备与前置条件3.1 硬件与操作系统评测环境建议准备一台可以长时间运行的开发机因为批量任务通常要跑几个小时。操作系统用 Windows 10/11、macOS 或 Linux 都可以只要下面的软件能正常安装跑出来的结果没有本质差别。如果使用云端模型 API评测机的 CPU 和内存够跑浏览器和 Node 服务即可对显卡没有硬性要求如果要在本地跑开源模型则建议准备独立显卡显存大小取决于模型规格。同一家模型不同量化版本的显存占用差别可以很大建议以模型官方文档给出的显存要求为准再用 nvidia-smi 或系统任务管理器观察实际占用不要在评测中途随意切换模型。3.2 软件依赖先确认基础环境node -v npm -v python --version git --version建议安装的软件清单Chromium 系浏览器用于 DevTools 自动化和页面截图。VS Code 或其他支持 MCP 扩展的编辑器。Playwright 或 Puppeteer用于浏览器自动化控制。一个支持 OpenAI 兼容接口的模型服务可以是云端 API也可以是本地推理服务。3.3 模型接入方式选择第一次做评测建议用云端模型 API原因是稳定性和速度更容易控制方便把变量聚焦在 devtools 上。本地模型的好处是数据不出机器但推理速度和显存会引入额外变量。如果你本来就在用本地模型建议固定同一个模型跑完全部场景不要在评测途中切换模型否则结果无法横向对比。评测前最好先跑一次空任务确认模型服务、网络代理、API Key 这类基础配置都就绪再开始正式任务避免把环境问题误判成工具链能力问题。4. 搭建 LLM devtools 评测工作流4.1 用 MCP 打通模型与浏览器MCP 是目前连接 LLM 和外部工具的主流方式。以浏览器 MCP server 为例安装 Playwright MCP 后模型就可以通过工具调用打开页面、点击元素、读取控制台日志、截图。安装命令参考npm install -g playwright/mcp然后在 MCP 客户端配置文件中注册这个 server。常见的位置是项目根目录的 .mcp.json 或编辑器内的 MCP 配置具体以客户端文档为准{ mcpServers: { playwright: { command: npx, args: [playwright/mcplatest] } } }配置完成后在支持 MCP 的客户端里重连会话如果能看到 playwright 相关工具列表说明模型已经具备浏览器操作入口。4.2 配置浏览器自动化入口Playwright MCP 底层通过浏览器调试协议工作启动后默认会拉起一个带调试端口的浏览器实例。如果环境里有多个浏览器需要明确指定可执行文件路径避免自动化控制错了浏览器。首次运行建议用无痕模式避免模型访问到个人登录态的网站也避免评测过程受浏览器插件干扰。这里尤其要注意端口冲突问题如果本机已经有一些服务占用了调试端口需要显式指定一个空闲端口否则 MCP server 会启动失败。4.3 建立最小评测项目骨架建议准备一个独立的评测项目目录里面放三个子目录tasks 存放任务描述文件src 存放被测项目代码logs 存放每轮评测日志。这样一个任务跑完所有过程产物都有地方放方便后面统计成功率和定位失败原因eval-runner/ ├── tasks/ # 任务描述每个任务一个 md 文件 ├── src/ # 被测 Web 项目 ├── logs/ # 模型日志、控制台输出、截图 └── results/ # 评分表和指标汇总5. 功能测试场景与效果验证5.1 场景一从零规划并实现一个待办事项应用这是最基础的场景用来测试 LLM 在“规划 生成 启动 验证”完整闭环里的表现。任务描述建议写成下面这样包含明确的功能验收标准使用 HTML CSS JavaScript 实现一个待办事项应用。 功能要求 1. 可以新增待办事项。 2. 可以勾选完成。 3. 可以删除待办事项。 4. 页面刷新后数据不丢失。 验收标准应用能通过本地静态服务启动所有功能页面内可操作。观察重点有三个模型是否能规划出合理的文件结构是否能自动启动本地静态服务是否能通过浏览器自动化完成“新增-勾选-删除-刷新”的操作验证。如果模型只会生成代码但不知道怎么启动和验证说明 devtools 的“验证闭环”这一环没打通。这个场景最适合做第一轮冒烟测试环境没配置好的话很快就能暴露出来。5.2 场景二修复现有项目的前端报错这个场景最能体现浏览器 DevTools 的价值。准备一个故意引入报错的小项目比如在 React 或 Vue 项目里写一个 undefined 变量引用或者把接口地址写错。任务描述只给一句“页面打开后控制台报错请修复”。此时观察模型是否会自动打开 DevTools 读取 Console 报错、是否会在 Network 面板里检查请求状态、是否能把报错定位到具体文件和行号。如果工具链不支持读取控制台模型只能靠猜错误定位的轮次会明显增加。改完代码后还需要刷新页面重新验证人工操作对应 DevTools 里的 CtrlR 刷新自动化链路里则是让模型调用浏览器 reload 接口并重新读取 Console 日志。这个“改代码-刷新-读报错”的循环越短排错越快。对照组设计一组允许模型自动读取控制台另一组只给模型“页面截图回传”对比两组修复成功的轮次和耗时。这个对比结果往往比模型之间的参数对比更有说服力也是评测 devtools 价值最直观的证据。5.3 场景三接口联调与 Mock 数据真实 Web 应用绕不开接口联调。这个场景测试的是模型能否使用接口调试工具或命令行发起请求、比对返回结果、生成 Mock 数据。比如任务描述是“后端尚未就绪请基于接口文档生成 Mock 数据并让页面正常展示”。观察重点包括模型是否能读懂接口文档能否用 curl 或脚本请求测试接口能否把返回结果转换为页面需要的结构。接口调试工具如果能被模型直接调用并返回结构化 JSON这个场景的表现会明显更好。如果工具链只支持图形化接口调试而不提供命令行或脚本入口模型基本无法独立完成这个任务。5.4 场景四运行效果与响应式验证这个场景用来测试页面在真实浏览器里的表现。任务描述可以是“检查页面在 375px 和 1440px 两种宽度下是否正常并修复溢出问题”。模型需要通过浏览器自动化切换视口、截图并对比两张截图来发现问题。DevTools 的设备模拟模式在这里很关键。如果工具链支持直接设置视口尺寸并截图模型就可以自主完成验证如果只能靠人工截图这个场景基本无法自动化。判断成功的标准是两次视口切换下页面都没有横向滚动条关键按钮和卡片没有明显错位模型能基于截图给出修复方案。5.5 评分记录表每个场景跑完后按下面这张表记录结果方便后面做横向对比场景完成轮次成功率关键卡点使用的 devtools备注待办事项应用3成功启动服务终端 浏览器自动化共 12 次工具调用修复前端报错2成功读取 Console浏览器 DevTools对照组多了 6 轮接口 Mock4部分成功接口文档理解curl 脚本数据结构错误响应式验证2成功视口切换浏览器设备模拟无表格里的数值只是记录格式示例实际跑出来的数字以你自己环境为准。正式评测建议至少跑三轮取平均值并且把每轮的日志都归档避免只留一个最终结果导致后面无法复盘。6. 接口 API 与批量评测任务6.1 单任务 API 调用模板如果模型服务提供 OpenAI 兼容接口可以直接用脚本把任务描述发给模型再把模型回复里声明的工具调用记录下来。下面是一个最小调用模板需要替换成你自己的 API 地址和模型名import requests url http://127.0.0.1:8000/v1/chat/completions payload { model: your-model-name, messages: [ {role: system, content: 你是一个 Web 应用开发助手可以使用浏览器工具完成页面验证。}, {role: user, content: 请实现一个待办事项应用并验证新增和删除功能。} ], tools: [ { type: function, function: { name: browser_console_read, description: 读取浏览器控制台日志, parameters: {type: object, properties: {}} } } ] } response requests.post(url, jsonpayload, timeout300) print(response.json())6.2 批量评测与指标收集要比较“哪些 devtools 更占优”单跑一个场景不够建议把任务脚本化。准备一个任务列表文件每个任务包含任务描述、验收标准、预期指标[ { task_id: todo-app, description: 从零实现待办事项应用, acceptance: 新增、勾选、删除、刷新后数据保留, max_rounds: 10 }, { task_id: fix-console-error, description: 修复页面控制台报错, acceptance: 控制台无报错页面正常渲染, max_rounds: 10 } ]批量跑的时候每轮任务把模型输出、工具调用记录、浏览器截图都写到 logs 目录文件名带上 task_id 和时间戳。最后统计三个核心指标任务成功率、平均轮次、平均 token 消耗。如果需要跑多组对照组可以固定模型、只切换 devtools 配置这样差异来源就落在工具链上。6.3 结果判定与重试策略结果判定要尽量自动化。能写断言的任务用脚本断言页面状态不能自动判定的保留截图和日志人工复核。批量任务有一个常见问题某个工具调用偶发失败导致整个任务失败。建议对工具调用失败做一次重试对任务本身做三次以内的重试超过次数就标记为失败并保留失败现场不要无限重试浪费时间。最终写入结果表时把“重试后成功”和“一次成功”分开标记这样能看到工具链的稳定性差异。7. 资源占用与性能观察7.1 值得记录的指标LLM devtools 的评测不只是“能不能成功”还要关注成本。建议记录这些指标单任务总耗时从发出任务到验收完成的时间。工具调用次数模型为了完成一个任务调用了多少次浏览器、终端、接口工具。token 消耗模型推理的输入输出 token 总量。浏览器内存占用自动化浏览器实例通常比普通浏览器占更多内存。本地模型的显存占用如果跑本地模型用 nvidia-smi 观察。7.2 显存与推理延迟云端模型不存在显存问题但要关注接口延迟。本地模型需要关注显存和上下文长度。显存占用要以实际模型版本和推理参数为准不同量化格式、不同最大 token 设置都会影响占用。如果显存不足优先降低上下文长度、减小 batch、关闭并行请求再考虑换小一号的量化模型。评测过程中如果发现某一轮特别慢要区分是模型推理慢还是工具调用超时前者看模型服务日志后者看工具超时时间配置。7.3 降低资源占用的做法浏览器自动化实例尽量复用不要每个任务重新启动否则内存开销会成倍增加。批量评测时要限制并发数通常同时跑 1 到 3 个任务比较稳定并发太高容易把浏览器和控制端拖垮。日志文件要按任务拆分不要所有任务写进同一个文件否则后面排错很痛苦。如果评测机内存紧张可以限制浏览器页签数量关闭不用的后台选项卡只保留当前任务页面。8. 常见问题与排查方法问题现象可能原因排查方式解决方案MCP server 启动失败