LLM 规划真实 Web 应用已经从“演示级”走进了不少团队的日常开发流程。GitHub 上类似 Show HN 的帖子越来越多评论区最常见的反馈不是“效果惊艳”而是“生成第一版很快修到能上线很慢”。模型的差距在逐渐缩小真正决定开发效率的变成了工具链能不能兜住 LLM 生成的代码。这篇不聊模型参数也不展开 Agent 理论直接分析一个更实际的问题当 LLM 真的开始规划、生成、迭代一个 Web 应用时哪些 devtools 能在关键环节胜出。答案是不是某一个全家桶工具而是能帮 LLM 看到真实运行时反馈的那一套工具链——浏览器 DevTools、前端框架调试工具、API 调试工具、数据库可视化工具以及 Playwright 这类端到端自动化方案。它们共同解决的问题只有一个让 LLM 的“我以为”变成“实际跑出来的结果”。这篇文章会先给出一张核心能力速览表然后按生成、验证、调试、回归这条主线拆解工具选型最后给出一套可以直接复制的 LLM devtools 最小验证闭环。适合正在用 Cursor、Copilot、Cline 辅助写前端或全栈项目的人也适合打算把 LLM Agent 引入日常开发流程的团队参考。1. 核心能力速览当 LLM 规划真实 Web 应用时开发工具链的角色不再是“敲代码的编辑器”而是“验证器和反馈通道”。下面这张表把 LLM 全栈开发中最常卡住的环节以及对应能胜出的工具列出来。开发环节推荐工具/方案解决的核心问题适用阶段代码生成Cursor、Copilot、Cline、Claude/GPT 类模型从需求描述生成基础代码骨架需求拆解与原型搭建浏览器运行时验证Chrome DevTools / Edge DevTools白屏、报错、样式错乱、接口不返回第一轮功能启动前端状态调试React DevTools / Vue DevTools组件 state、props、pinia/vuex 数据流异常交互逻辑联调接口调试curl、Postman、Apifox请求参数错误、返回值结构不符合预期前后端联调数据库检查SQLite Browser、DBeaver、Adminer数据没写入、字段类型不对、外键缺失持久化功能验证回归测试Playwright、PuppeteerLLM 频繁迭代后旧功能被改崩功能迭代与发布前错误收集Chrome DevTools ProtocolCDP自动抓取 console 报错和网络失败多人协作或批量调试版本管理GitLLM 改动失控时快速回退整个开发过程从实际体验来看真正决定“LLM 开发能不能落地”的往往不是模型生成代码的质量而是你能否在 5 分钟内拿到一条可读的报错信息并原样回传给 LLM 让它自己修复。这一条反馈回路跑通了后续迭代效率会提升好几倍。2. 适用场景与使用边界这套工具链并不是万能的。先明确它能帮到什么程度以及边界在哪里。适合的场景内部工具、管理后台、原型验证这类应用业务逻辑简单没有复杂的高并发和强一致要求LLM 生成代码的容错空间大。前端组件快速落地让 LLM 生成组件再在浏览器 DevTools 里确认样式和交互比手写快很多。API 联调与数据展示LLM 生成调用代码后用 Network 面板和接口调试工具核对真实返回结构比人肉读文档高效。教学和技术验证用 LLM devtools 搭建可运行示例验证某个框架或库的用法是否可行。不太适合的场景高并发、强一致、安全敏感的生产系统LLM 生成的代码缺少对边界条件的系统思考数据库索引、事务、限流、鉴权这些环节需要大量人工审查。超大单体仓库LLM 上下文有限生成的代码可能破坏既有模块边界工具链只能发现问题不能让代码自动变整洁。对某个框架有严格架构规范的团队LLM 不了解内部规范时生成代码与现有架构风格不匹配审查成本反而更高。合规与安全边界LLM 生成的代码可能来自训练数据中的开源项目存在许可证兼容风险。商用前需要做代码来源审查。不要把包含密钥、内部 API 地址、用户隐私数据的代码粘贴给外部 LLM 服务。浏览器 DevTools 控制台里有一个常见的警告提示不要将代码粘贴到不了解或尚未审阅的 DevTools 控制台中这可能导致攻击。这个警告同样适用于 LLM Agent 生成的代码。LLM 可能推荐你执行一段它认为“没问题”的脚本但脚本会对页面 DOM、存储、Cookie 做什么必须自己看清楚了再执行。使用 Playwright 或 Puppeteer 做端到端测试时只在自己可控的测试环境运行不要在未授权的网站上做自动化操作。3. 环境准备与前置条件LLM 开发 Web 应用的工具链比较重但每一项都不复杂。按下面的清单检查一次。操作系统与运行时Windows / macOS / Linux 都可以没有严格限制。Node.js 18 以上用于运行前端项目、Playwright 脚本、CDP 调试脚本。Python 3.9 以上如果后端使用 FastAPI / Flask或者需要写批量分析脚本。浏览器Chrome 或 Edge 最新版。DevTools 面板齐全CDP 兼容性最好。如果使用 React 技术栈安装 React DevTools 扩展。如果使用 Vue 技术栈安装 Vue DevTools 扩展。模型与编辑器工具云端模型Claude、GPT 系列或国内可访问的大模型 API按团队合规要求选择。编辑器辅助Cursor、VS Code Copilot、Cline 都行。Cline 这类 Agent 工具会自动改文件、执行命令审查权限建议收紧。依赖安装前的检查如果 LLM 生成的代码里有package.json先看依赖数量是否合理。上千个依赖的 package.json即使能跑也说明依赖管理混乱建议让 LLM 重写精简版本。后端如果是 Python检查requirements.txt或pyproject.toml中是否有来源不明的包名防止依赖混淆攻击。磁盘空间LLM 生成的项目通常不大前端项目 node_modules 可能较大预留 5-10 GB 足够。Playwright 下载浏览器内核会增加 500 MB 左右。4. 安装部署与启动方式这里给出一套通用启动流程覆盖前端项目和后端服务。具体命令需要按实际生成的项目结构调整。4.1 前端项目启动LLM 生成一个 React / Vue / Next.js 项目后第一步是安装依赖并启动开发服务器。# 进入项目目录 cd your-llm-app # 安装依赖 npm install # 启动开发服务 npm run dev启动后控制台会输出一个本地地址比如http://localhost:5173或http://localhost:3000。如果启动失败把完整报错复制回 LLM 会话让它修复package.json、配置文件或入口文件。4.2 后端服务启动如果 LLM 生成了 FastAPI 后端启动方式如下。# 进入后端目录 cd your-llm-backend # 创建虚拟环境 python -m venv venv # Windows 激活 venv\Scripts\activate # macOS / Linux 激活 source venv/bin/activate # 安装依赖 pip install -r requirements.txt # 启动服务 uvicorn main:app --reload --port 8000常见的失败点是requirements.txt里锁定了不存在的版本号。如果pip install报错找不到指定版本不要硬装让 LLM 根据当前 Python 版本重新生成一份依赖清单。4.3 用浏览器 DevTools 打开页面启动前端服务后用 Chrome 打开页面按 F12 打开 DevTools。重点看四个面板Console所有 JS 报错、未捕获异常、资源加载失败都会在这里显示。Network接口请求是否有 4xx / 5xx请求参数和返回结构是否正常。ElementsDOM 结构是否正确元素是否存在但被 CSS 遮挡。Sources断点调试点开报错堆栈定位到具体行。4.4 用 CDP 自动接入现有 Chrome如果你希望自动收集页面报错而不只是手动看面板可以用 Node.js 写一个简短的 CDP 脚本连接已开启远程调试端口的 Chrome。# 安装依赖 npm install chrome-remote-interfaceconst CDP require(chrome-remote-interface); async function main() { const client await CDP({ host: 127.0.0.1, port: 9222 }); const { Runtime, Log, Page } client; await Promise.all([Runtime.enable(), Log.enable(), Page.enable()]); Runtime.consoleAPICalled(({ type, args }) { console.log([console], type, args.map(a a.value).join( )); }); Runtime.exceptionThrown(({ exceptionDetails }) { console.log([exception], exceptionDetails.text); }); await Page.navigate({ url: http://localhost:5173 }); await Page.loadEventFired(); setTimeout(async () { console.log(收集完成关闭连接); await client.close(); }, 8000); } main().catch(console.error);启动 Chrome 时加上远程调试参数再运行脚本就能自动抓取 LLM 生成的页面在运行时的所有报错。# Windows chrome.exe --remote-debugging-port9222 # macOS /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port9222这一套流程跑通后LLM 修代码的速度会明显提升因为你不再需要手动复制报错文本脚本会自动输出完整错误信息。5. 功能测试与效果验证LLM 生成的 Web 应用功能验证不能只看页面能不能打开。下面按环节给出测试重点和判断成功的方式。5.1 白屏与路由验证测试目的确认页面能正确加载路由能跳到对应页面。操作步骤打开首页点击页面上的所有导航链接观察每个路由是否渲染出内容。预期结果浏览器地址栏和页面内容一致。路由切换时 Network 面板有对应的请求。没有 JavaScript 语法错误或模块加载失败。判断是否成功所有页面能渲染Console 面板没有红色报错。常见失败原因react-router-dom版本与项目代码不匹配路由写法错误。配置文件里base路径不对静态资源 404。组件里调用了document或window在 SSR 环节报错。5.2 接口返回结构验证测试目的确认前端拿到后端数据后能正确渲染而不是界面空着、接口单独调通。操作步骤在页面上触发数据加载打开 Network 面板点击对应的 XHR / Fetch 请求查看 Response 和 Preview。预期结果接口返回 200。JSON 字段结构与前端代码里访问的字段一致。页面能渲染出真实数据而不是空白和占位符。判断是否成功数据展示正常字段名不报undefined。常见失败原因LLM 生成的接口字段名与后端实际返回不一致比如后端返回user_name前端却读username。后端返回{ data: [...] }前端却直接遍历数组。跨域问题浏览器拦截了请求。5.3 表单提交与数据库写入验证测试目的确认用户提交的数据能写入数据库并且刷新页面后数据还在。操作步骤填写表单提交然后打开数据库可视化工具查看表数据。如果后端是 SQLite直接用 SQLite Browser 打开数据库文件。预期结果提交后接口返回成功状态。数据库表中多出对应记录。刷新页面后数据重新加载。判断是否成功数据库里有数据页面刷新后不丢数据。常见失败原因后端模型字段设置了非空约束但前端提交时缺少必要字段。数据库连接路径写错程序连接到了另一个文件或内存数据库。LLM 生成的 ORM 代码没有执行commit导致事务没提交。5.4 状态管理与组件交互验证测试目的确认按钮点击、表单输入、弹窗开关这些交互不崩数据在组件之间能正确传递。操作步骤在 React DevTools 或 Vue DevTools 里选中组件观察 state / props 变化。点击交互元素看状态值是否按预期更新。预期结果交互后状态值变化与代码逻辑一致。父组件和子组件之间的 props 传递正常。没有重复渲染导致的性能抖动。判断是否成功状态数据正确页面没有意外跳转或刷新。常见失败原因组件内部修改了 propsVue 会告警React 会直接运行异常。状态提升不到位兄弟组件之间数据不同步。列表渲染时 key 使用索引导致组件复用错乱。6. 接口 API 与批量任务LLM 开发过程中的接口调试和批量回归是工具链效率提升最明显的地方。6.1 接口调试示例假设 LLM 生成的前端调用一个待办事项接口你可以先手动确认接口返回结构再让前端对齐字段。# 假设本地后端服务在 8000 端口 curl -X GET http://127.0.0.1:8000/api/todos返回示例[ { id: 1, title: 测试待办, completed: false } ]对照这个返回结构检查 LLM 生成的前端代码里是否按id、title、completed三个字段展示。如果字段对不上直接把报错和返回 JSON 一起回传给 LLM让它改前端的数据映射。6.2 批量检查静态资源LLM 生成项目时经常出现图片路径、CSS 路径错误。可以用一个简单的 Python 脚本扫描页面中所有静态资源是否 404。import requests from bs4 import BeautifulSoup base_url http://localhost:5173 response requests.get(base_url, timeout10) soup BeautifulSoup(response.text, html.parser) assets [] for tag in soup.find_all([script, link, img]): src tag.get(src) or tag.get(href) if src and src.startswith((http, /)): assets.append(src) for asset in assets: url asset if asset.startswith(http) else base_url asset try: status requests.get(url, timeout10).status_code print(f{status} {url}) except Exception as e: print(fFAIL {url} {e})这个脚本适合在页面较少、资源路径规律的项目里快速排查 404。6.3 用 Playwright 做端到端回归当 LLM 迭代多个功能后最怕的是修了 A 功能、崩了 B 功能。Playwright 可以把核心流程固化成自动化回归脚本。const { test, expect } require(playwright/test); test(用户注册并创建待办, async ({ page }) { await page.goto(http://localhost:5173); // 验证首页渲染 await expect(page.locator(text待办事项)).toBeVisible(); // 添加一条待办 await page.fill(input[placeholder请输入待办], 测试任务); await page.click(button:has-text(添加)); // 验证列表更新 await expect(page.locator(text测试任务)).toBeVisible(); });运行方式npx playwright install npx playwright test真实项目里建议把登录、列表加载、搜索、详情页、提交表单这五条主链路各写一个用例。LLM 每完成一次改动就完整跑一遍。跑完把失败的用例输出回传 LLM让它在不破坏其他用例的前提下修复。6.4 批量代码审查工作流如果团队使用 LLM Agent 自动写代码可以设计一条批量审查流水线LLM 生成代码后由另一个“审查型”LLM或人工审查规则检查代码中的 API 密钥、危险函数、不规范的错误处理。import requests # 通用示例实际接口地址和参数以自己使用的 LLM 服务为准 code open(generated_api.py, encodingutf-8).read() prompt f 请审查以下代码重点检查 1. 是否存在硬编码密钥 2. 是否有不安全的 SQL 拼接 3. 异常处理是否合理 4. 是否有明显的性能问题 代码 {code} payload { model: your-model-name, messages: [{role: user, content: prompt}], temperature: 0.2, } response requests.post( https://your-llm-api.example.com/v1/chat/completions, jsonpayload, timeout300, ) print(response.json()[choices][0][message][content])这里的核心思路是生成和审查分离。让生成模型发挥创造力让审查模型或人工负责把关。所有涉及密钥、权限、支付、用户数据的代码必须有人工复核环节。7. 资源占用与性能观察LLM 生成的 Web 应用功能跑通只是及格性能问题和资源占用同样需要观察。尤其是多次迭代后LLM 可能会无意识地增加不必要的 bundle 体积或重复渲染。浏览器 DevTools 的 Performance 面板是主要观察入口。打开 Performance 面板点击录制操作页面停止录制。查看主线程耗时。如果某个任务长时间占用主线程说明有重循环或高频状态更新。查看 Layout / Rendering 时间。如果布局时间占比高说明 DOM 层级过深或样式频繁触发重排。Lighthouse 可以给出一个整体评分。在 DevTools 的 Lighthouse 面板选择页面类型点击生成报告。重点看 Performance 和 Accessibility 两项。LLM 生成的页面通常 Accessibility 分数偏低原因是缺乏 aria 标签、表单没有 label、对比度过低。Network 面板的瀑布图可以观察资源加载顺序。如果某个大体积 JS 文件阻塞了首屏渲染考虑让 LLM 拆分代码或按路由懒加载。内存方面用 Performance 面板检查页面长时间操作后的内存曲线。如果曲线持续上升且不回落可能是组件未正确卸载、定时器未清理、事件监听器泄漏。这类问题 LLM 生成的代码里很常见因为它不会主动考虑组件销毁逻辑。定位方法是在 Sources 面板监听unmount或beforeUnmount生命周期检查清理逻辑是否完整。CPU 占用和浏览器内存占用没有固定标准以实际项目规模为准。如果项目只有几个页面但开发者工具里 JavaScript 堆内存已经超过 100 MB大概率存在泄漏。可以先让 LLM 自查所有addEventListener、setInterval、setTimeout是否在组件销毁时被移除。8. 常见问题与排查LLM devtools 开发过程中的问题很多都有固定规律。下面的表格整理了高频问题的排查路径。问题现象可能原因排查方式解决方案页面白屏控制台无报错入口文件未挂载路由配置错误Console 面板输入document.getElementById(root)检查是否为空检查main.jsx/main.ts是否调用了createRoot().render()控制台报模块找不到依赖缺失或依赖版本不兼容查看完整报错路径检查package.json删除 node_modules 后重新 install或让 LLM 调整版本接口跨域报错后端未开启 CORSNetwork 面板查看响应头是否有Access-Control-Allow-Origin后端添加 CORS 中间件或在开发环境配置代理刷新页面 404前端路由是 history 模式服务器未做 fallback访问子路由刷新观察报错在 Nginx / 后端配置 history fallback 到 index.html表单提交成功但数据库没数据事务未提交或连错数据库在数据库可视化工具里刷新表查看连接配置检查 ORM 代码是否调用了 commit检查数据库路径页面运行一段时间后变卡定时器或事件监听器未释放Performance 录制中查看长任务Memory 面板看堆曲线在组件卸载时清理定时器和监听器自动化测试不稳定元素定位依赖文本或 CSS 类名Playwright 运行失败后查看 trace 报告改用稳定的> LLM 开发 Web 应用：DevTools 与 Playwright 构建高效调试闭环
LLM 规划真实 Web 应用已经从“演示级”走进了不少团队的日常开发流程。GitHub 上类似 Show HN 的帖子越来越多评论区最常见的反馈不是“效果惊艳”而是“生成第一版很快修到能上线很慢”。模型的差距在逐渐缩小真正决定开发效率的变成了工具链能不能兜住 LLM 生成的代码。这篇不聊模型参数也不展开 Agent 理论直接分析一个更实际的问题当 LLM 真的开始规划、生成、迭代一个 Web 应用时哪些 devtools 能在关键环节胜出。答案是不是某一个全家桶工具而是能帮 LLM 看到真实运行时反馈的那一套工具链——浏览器 DevTools、前端框架调试工具、API 调试工具、数据库可视化工具以及 Playwright 这类端到端自动化方案。它们共同解决的问题只有一个让 LLM 的“我以为”变成“实际跑出来的结果”。这篇文章会先给出一张核心能力速览表然后按生成、验证、调试、回归这条主线拆解工具选型最后给出一套可以直接复制的 LLM devtools 最小验证闭环。适合正在用 Cursor、Copilot、Cline 辅助写前端或全栈项目的人也适合打算把 LLM Agent 引入日常开发流程的团队参考。1. 核心能力速览当 LLM 规划真实 Web 应用时开发工具链的角色不再是“敲代码的编辑器”而是“验证器和反馈通道”。下面这张表把 LLM 全栈开发中最常卡住的环节以及对应能胜出的工具列出来。开发环节推荐工具/方案解决的核心问题适用阶段代码生成Cursor、Copilot、Cline、Claude/GPT 类模型从需求描述生成基础代码骨架需求拆解与原型搭建浏览器运行时验证Chrome DevTools / Edge DevTools白屏、报错、样式错乱、接口不返回第一轮功能启动前端状态调试React DevTools / Vue DevTools组件 state、props、pinia/vuex 数据流异常交互逻辑联调接口调试curl、Postman、Apifox请求参数错误、返回值结构不符合预期前后端联调数据库检查SQLite Browser、DBeaver、Adminer数据没写入、字段类型不对、外键缺失持久化功能验证回归测试Playwright、PuppeteerLLM 频繁迭代后旧功能被改崩功能迭代与发布前错误收集Chrome DevTools ProtocolCDP自动抓取 console 报错和网络失败多人协作或批量调试版本管理GitLLM 改动失控时快速回退整个开发过程从实际体验来看真正决定“LLM 开发能不能落地”的往往不是模型生成代码的质量而是你能否在 5 分钟内拿到一条可读的报错信息并原样回传给 LLM 让它自己修复。这一条反馈回路跑通了后续迭代效率会提升好几倍。2. 适用场景与使用边界这套工具链并不是万能的。先明确它能帮到什么程度以及边界在哪里。适合的场景内部工具、管理后台、原型验证这类应用业务逻辑简单没有复杂的高并发和强一致要求LLM 生成代码的容错空间大。前端组件快速落地让 LLM 生成组件再在浏览器 DevTools 里确认样式和交互比手写快很多。API 联调与数据展示LLM 生成调用代码后用 Network 面板和接口调试工具核对真实返回结构比人肉读文档高效。教学和技术验证用 LLM devtools 搭建可运行示例验证某个框架或库的用法是否可行。不太适合的场景高并发、强一致、安全敏感的生产系统LLM 生成的代码缺少对边界条件的系统思考数据库索引、事务、限流、鉴权这些环节需要大量人工审查。超大单体仓库LLM 上下文有限生成的代码可能破坏既有模块边界工具链只能发现问题不能让代码自动变整洁。对某个框架有严格架构规范的团队LLM 不了解内部规范时生成代码与现有架构风格不匹配审查成本反而更高。合规与安全边界LLM 生成的代码可能来自训练数据中的开源项目存在许可证兼容风险。商用前需要做代码来源审查。不要把包含密钥、内部 API 地址、用户隐私数据的代码粘贴给外部 LLM 服务。浏览器 DevTools 控制台里有一个常见的警告提示不要将代码粘贴到不了解或尚未审阅的 DevTools 控制台中这可能导致攻击。这个警告同样适用于 LLM Agent 生成的代码。LLM 可能推荐你执行一段它认为“没问题”的脚本但脚本会对页面 DOM、存储、Cookie 做什么必须自己看清楚了再执行。使用 Playwright 或 Puppeteer 做端到端测试时只在自己可控的测试环境运行不要在未授权的网站上做自动化操作。3. 环境准备与前置条件LLM 开发 Web 应用的工具链比较重但每一项都不复杂。按下面的清单检查一次。操作系统与运行时Windows / macOS / Linux 都可以没有严格限制。Node.js 18 以上用于运行前端项目、Playwright 脚本、CDP 调试脚本。Python 3.9 以上如果后端使用 FastAPI / Flask或者需要写批量分析脚本。浏览器Chrome 或 Edge 最新版。DevTools 面板齐全CDP 兼容性最好。如果使用 React 技术栈安装 React DevTools 扩展。如果使用 Vue 技术栈安装 Vue DevTools 扩展。模型与编辑器工具云端模型Claude、GPT 系列或国内可访问的大模型 API按团队合规要求选择。编辑器辅助Cursor、VS Code Copilot、Cline 都行。Cline 这类 Agent 工具会自动改文件、执行命令审查权限建议收紧。依赖安装前的检查如果 LLM 生成的代码里有package.json先看依赖数量是否合理。上千个依赖的 package.json即使能跑也说明依赖管理混乱建议让 LLM 重写精简版本。后端如果是 Python检查requirements.txt或pyproject.toml中是否有来源不明的包名防止依赖混淆攻击。磁盘空间LLM 生成的项目通常不大前端项目 node_modules 可能较大预留 5-10 GB 足够。Playwright 下载浏览器内核会增加 500 MB 左右。4. 安装部署与启动方式这里给出一套通用启动流程覆盖前端项目和后端服务。具体命令需要按实际生成的项目结构调整。4.1 前端项目启动LLM 生成一个 React / Vue / Next.js 项目后第一步是安装依赖并启动开发服务器。# 进入项目目录 cd your-llm-app # 安装依赖 npm install # 启动开发服务 npm run dev启动后控制台会输出一个本地地址比如http://localhost:5173或http://localhost:3000。如果启动失败把完整报错复制回 LLM 会话让它修复package.json、配置文件或入口文件。4.2 后端服务启动如果 LLM 生成了 FastAPI 后端启动方式如下。# 进入后端目录 cd your-llm-backend # 创建虚拟环境 python -m venv venv # Windows 激活 venv\Scripts\activate # macOS / Linux 激活 source venv/bin/activate # 安装依赖 pip install -r requirements.txt # 启动服务 uvicorn main:app --reload --port 8000常见的失败点是requirements.txt里锁定了不存在的版本号。如果pip install报错找不到指定版本不要硬装让 LLM 根据当前 Python 版本重新生成一份依赖清单。4.3 用浏览器 DevTools 打开页面启动前端服务后用 Chrome 打开页面按 F12 打开 DevTools。重点看四个面板Console所有 JS 报错、未捕获异常、资源加载失败都会在这里显示。Network接口请求是否有 4xx / 5xx请求参数和返回结构是否正常。ElementsDOM 结构是否正确元素是否存在但被 CSS 遮挡。Sources断点调试点开报错堆栈定位到具体行。4.4 用 CDP 自动接入现有 Chrome如果你希望自动收集页面报错而不只是手动看面板可以用 Node.js 写一个简短的 CDP 脚本连接已开启远程调试端口的 Chrome。# 安装依赖 npm install chrome-remote-interfaceconst CDP require(chrome-remote-interface); async function main() { const client await CDP({ host: 127.0.0.1, port: 9222 }); const { Runtime, Log, Page } client; await Promise.all([Runtime.enable(), Log.enable(), Page.enable()]); Runtime.consoleAPICalled(({ type, args }) { console.log([console], type, args.map(a a.value).join( )); }); Runtime.exceptionThrown(({ exceptionDetails }) { console.log([exception], exceptionDetails.text); }); await Page.navigate({ url: http://localhost:5173 }); await Page.loadEventFired(); setTimeout(async () { console.log(收集完成关闭连接); await client.close(); }, 8000); } main().catch(console.error);启动 Chrome 时加上远程调试参数再运行脚本就能自动抓取 LLM 生成的页面在运行时的所有报错。# Windows chrome.exe --remote-debugging-port9222 # macOS /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port9222这一套流程跑通后LLM 修代码的速度会明显提升因为你不再需要手动复制报错文本脚本会自动输出完整错误信息。5. 功能测试与效果验证LLM 生成的 Web 应用功能验证不能只看页面能不能打开。下面按环节给出测试重点和判断成功的方式。5.1 白屏与路由验证测试目的确认页面能正确加载路由能跳到对应页面。操作步骤打开首页点击页面上的所有导航链接观察每个路由是否渲染出内容。预期结果浏览器地址栏和页面内容一致。路由切换时 Network 面板有对应的请求。没有 JavaScript 语法错误或模块加载失败。判断是否成功所有页面能渲染Console 面板没有红色报错。常见失败原因react-router-dom版本与项目代码不匹配路由写法错误。配置文件里base路径不对静态资源 404。组件里调用了document或window在 SSR 环节报错。5.2 接口返回结构验证测试目的确认前端拿到后端数据后能正确渲染而不是界面空着、接口单独调通。操作步骤在页面上触发数据加载打开 Network 面板点击对应的 XHR / Fetch 请求查看 Response 和 Preview。预期结果接口返回 200。JSON 字段结构与前端代码里访问的字段一致。页面能渲染出真实数据而不是空白和占位符。判断是否成功数据展示正常字段名不报undefined。常见失败原因LLM 生成的接口字段名与后端实际返回不一致比如后端返回user_name前端却读username。后端返回{ data: [...] }前端却直接遍历数组。跨域问题浏览器拦截了请求。5.3 表单提交与数据库写入验证测试目的确认用户提交的数据能写入数据库并且刷新页面后数据还在。操作步骤填写表单提交然后打开数据库可视化工具查看表数据。如果后端是 SQLite直接用 SQLite Browser 打开数据库文件。预期结果提交后接口返回成功状态。数据库表中多出对应记录。刷新页面后数据重新加载。判断是否成功数据库里有数据页面刷新后不丢数据。常见失败原因后端模型字段设置了非空约束但前端提交时缺少必要字段。数据库连接路径写错程序连接到了另一个文件或内存数据库。LLM 生成的 ORM 代码没有执行commit导致事务没提交。5.4 状态管理与组件交互验证测试目的确认按钮点击、表单输入、弹窗开关这些交互不崩数据在组件之间能正确传递。操作步骤在 React DevTools 或 Vue DevTools 里选中组件观察 state / props 变化。点击交互元素看状态值是否按预期更新。预期结果交互后状态值变化与代码逻辑一致。父组件和子组件之间的 props 传递正常。没有重复渲染导致的性能抖动。判断是否成功状态数据正确页面没有意外跳转或刷新。常见失败原因组件内部修改了 propsVue 会告警React 会直接运行异常。状态提升不到位兄弟组件之间数据不同步。列表渲染时 key 使用索引导致组件复用错乱。6. 接口 API 与批量任务LLM 开发过程中的接口调试和批量回归是工具链效率提升最明显的地方。6.1 接口调试示例假设 LLM 生成的前端调用一个待办事项接口你可以先手动确认接口返回结构再让前端对齐字段。# 假设本地后端服务在 8000 端口 curl -X GET http://127.0.0.1:8000/api/todos返回示例[ { id: 1, title: 测试待办, completed: false } ]对照这个返回结构检查 LLM 生成的前端代码里是否按id、title、completed三个字段展示。如果字段对不上直接把报错和返回 JSON 一起回传给 LLM让它改前端的数据映射。6.2 批量检查静态资源LLM 生成项目时经常出现图片路径、CSS 路径错误。可以用一个简单的 Python 脚本扫描页面中所有静态资源是否 404。import requests from bs4 import BeautifulSoup base_url http://localhost:5173 response requests.get(base_url, timeout10) soup BeautifulSoup(response.text, html.parser) assets [] for tag in soup.find_all([script, link, img]): src tag.get(src) or tag.get(href) if src and src.startswith((http, /)): assets.append(src) for asset in assets: url asset if asset.startswith(http) else base_url asset try: status requests.get(url, timeout10).status_code print(f{status} {url}) except Exception as e: print(fFAIL {url} {e})这个脚本适合在页面较少、资源路径规律的项目里快速排查 404。6.3 用 Playwright 做端到端回归当 LLM 迭代多个功能后最怕的是修了 A 功能、崩了 B 功能。Playwright 可以把核心流程固化成自动化回归脚本。const { test, expect } require(playwright/test); test(用户注册并创建待办, async ({ page }) { await page.goto(http://localhost:5173); // 验证首页渲染 await expect(page.locator(text待办事项)).toBeVisible(); // 添加一条待办 await page.fill(input[placeholder请输入待办], 测试任务); await page.click(button:has-text(添加)); // 验证列表更新 await expect(page.locator(text测试任务)).toBeVisible(); });运行方式npx playwright install npx playwright test真实项目里建议把登录、列表加载、搜索、详情页、提交表单这五条主链路各写一个用例。LLM 每完成一次改动就完整跑一遍。跑完把失败的用例输出回传 LLM让它在不破坏其他用例的前提下修复。6.4 批量代码审查工作流如果团队使用 LLM Agent 自动写代码可以设计一条批量审查流水线LLM 生成代码后由另一个“审查型”LLM或人工审查规则检查代码中的 API 密钥、危险函数、不规范的错误处理。import requests # 通用示例实际接口地址和参数以自己使用的 LLM 服务为准 code open(generated_api.py, encodingutf-8).read() prompt f 请审查以下代码重点检查 1. 是否存在硬编码密钥 2. 是否有不安全的 SQL 拼接 3. 异常处理是否合理 4. 是否有明显的性能问题 代码 {code} payload { model: your-model-name, messages: [{role: user, content: prompt}], temperature: 0.2, } response requests.post( https://your-llm-api.example.com/v1/chat/completions, jsonpayload, timeout300, ) print(response.json()[choices][0][message][content])这里的核心思路是生成和审查分离。让生成模型发挥创造力让审查模型或人工负责把关。所有涉及密钥、权限、支付、用户数据的代码必须有人工复核环节。7. 资源占用与性能观察LLM 生成的 Web 应用功能跑通只是及格性能问题和资源占用同样需要观察。尤其是多次迭代后LLM 可能会无意识地增加不必要的 bundle 体积或重复渲染。浏览器 DevTools 的 Performance 面板是主要观察入口。打开 Performance 面板点击录制操作页面停止录制。查看主线程耗时。如果某个任务长时间占用主线程说明有重循环或高频状态更新。查看 Layout / Rendering 时间。如果布局时间占比高说明 DOM 层级过深或样式频繁触发重排。Lighthouse 可以给出一个整体评分。在 DevTools 的 Lighthouse 面板选择页面类型点击生成报告。重点看 Performance 和 Accessibility 两项。LLM 生成的页面通常 Accessibility 分数偏低原因是缺乏 aria 标签、表单没有 label、对比度过低。Network 面板的瀑布图可以观察资源加载顺序。如果某个大体积 JS 文件阻塞了首屏渲染考虑让 LLM 拆分代码或按路由懒加载。内存方面用 Performance 面板检查页面长时间操作后的内存曲线。如果曲线持续上升且不回落可能是组件未正确卸载、定时器未清理、事件监听器泄漏。这类问题 LLM 生成的代码里很常见因为它不会主动考虑组件销毁逻辑。定位方法是在 Sources 面板监听unmount或beforeUnmount生命周期检查清理逻辑是否完整。CPU 占用和浏览器内存占用没有固定标准以实际项目规模为准。如果项目只有几个页面但开发者工具里 JavaScript 堆内存已经超过 100 MB大概率存在泄漏。可以先让 LLM 自查所有addEventListener、setInterval、setTimeout是否在组件销毁时被移除。8. 常见问题与排查LLM devtools 开发过程中的问题很多都有固定规律。下面的表格整理了高频问题的排查路径。问题现象可能原因排查方式解决方案页面白屏控制台无报错入口文件未挂载路由配置错误Console 面板输入document.getElementById(root)检查是否为空检查main.jsx/main.ts是否调用了createRoot().render()控制台报模块找不到依赖缺失或依赖版本不兼容查看完整报错路径检查package.json删除 node_modules 后重新 install或让 LLM 调整版本接口跨域报错后端未开启 CORSNetwork 面板查看响应头是否有Access-Control-Allow-Origin后端添加 CORS 中间件或在开发环境配置代理刷新页面 404前端路由是 history 模式服务器未做 fallback访问子路由刷新观察报错在 Nginx / 后端配置 history fallback 到 index.html表单提交成功但数据库没数据事务未提交或连错数据库在数据库可视化工具里刷新表查看连接配置检查 ORM 代码是否调用了 commit检查数据库路径页面运行一段时间后变卡定时器或事件监听器未释放Performance 录制中查看长任务Memory 面板看堆曲线在组件卸载时清理定时器和监听器自动化测试不稳定元素定位依赖文本或 CSS 类名Playwright 运行失败后查看 trace 报告改用稳定的>