自动化网页操作脚本生成：国产大模型没有一个顶用的

是我没用好还是路还长——一个老博主对大模型自动化的学习笔记写在前面的话本文是我近期折腾大模型与网页自动化的一些真实记录。不是评测不是吐槽更不是指点江山。我只是个还在路上的学习者把踩过的坑、冒出的疑问写下来希望能和同样在探索的朋友们交流。如果有理解偏差恳请指正。一、一次不太顺利的尝试最近我尝试用国产大模型配合QClaw做网页自动化操作(但后面大模型都幻觉为OpenClaw我就不修改了QClaw有免费不知名大模型4000万每天的token可以测试这是openclaw不具备的但这个模型不强所以只能是玩具会让很多热情用户失望而卸载)。OpenClaw 是一款开源的 AI Agent 工具通过 Chrome DevTools ProtocolCDP协议直接控制浏览器支持快照识别、元素点击、表单填写等功能理论上可以让大模型看懂网页并自动操作[[11]]。我的预期很简单让大模型生成操作脚本OpenClaw 执行完成一些重复性的网页任务。结果却让我有些困惑。用了几款国产模型包括一些在代码能力榜单上表现不错的生成的脚本总是卡壳——要么元素定位不准要么操作顺序错乱要么遇到动态加载就迷路。我第一反应是是不是我不会用二、先做功课国产大模型的代码能力到底如何带着疑问我去查了查最新的资料。根据 2026 年初的多份评测国产大模型在代码生成方面进步很快但与海外顶尖模型仍有差距。有分析指出国内头部模型大约落后海外最强模型3-6 个月的时间智谱 GLM-4.7、DeepSeek V3.2、MiniMax M2.1 等大概相当于 Claude Sonnet 4.5 上下的水平[[4]]。2026 年 3 月DeepSeek 发布了针对代码生成和数学推理的专项优化版本在多项基准测试中表现亮眼[[2]]。智谱也在 2 月正式发布了 GLM-5754B 参数在 Code Arena 等榜单上位居前列[[7]]。与此同时Claude Opus 4.6 在代码、文本、专家三大竞技场全部登顶尤其在 agentic coding智能体编程方面表现出色擅长处理需要规划和工具调用的复杂任务[[32]][[38]]。看到这里我意识到国产模型在进步但差距确实存在尤其在需要多步规划、工具调用的复杂场景中。我的自动化任务恰好属于这类场景卡壳或许不是偶然。三、OpenClaw 的视觉能力强大但也有边界我继续研究 OpenClaw 本身。OpenClaw 的浏览器控制基于 CDP 协议提供 Snapshot 快照系统自动扫描页面并为可交互元素分配引用编号AI 可以直接使用这些编号操作元素无需手写 CSS 选择器[[11]]。这种设计比传统自动化框架更AI 友好。但官方文档也坦诚地指出OpenClaw 不完美——比 API 调用慢单次操作 15-30 秒、比脚本脆弱界面一变就迷路、Token 消耗大[[13]]。我回想自己的测试过程确实遇到了这些问题元素引用失效页面导航后之前的元素编号就失效了需要重新获取快照。如果大模型没有意识到这一点后续操作就会失败。动态加载现代网页大量使用异步加载元素可能延迟出现。大模型如果没有等待意识很容易点空。截图成本每次截图分析都消耗大量 Token长链条任务成本累积很快。这些不是 OpenClaw 的缺陷而是GUI 自动化本身的技术难点。OpenClaw 已经在尽力降低门槛但大模型需要足够聪明才能用好它。四、一个更早的教训Gemini 与 HTML 代码我想起更早的一次经历。当时 Gemini 3 Pro 可以通过某个平台免费使用我让它帮我开发一个 HTML 前端页面不超过 1500 行。结果它不断要求截图检查代码是它自己写的却还要反复截图验证最终磕磕巴巴写完截图占用的硬盘空间有好几个 GB现在想来这反映了一个更深层的问题大模型在 GUI 场景中缺乏自我验证的能力。它写出的代码自己无法直接运行验证只能依赖外部反馈截图。这种写-看-改的循环效率很低且容易陷入死循环。五、GUI vs CLI大模型更适合哪种交互这让我思考一个更大的问题大模型是否天生更适合 CLI命令行而非 GUI图形界面有技术文章指出CLI 比 MCPModel Context Protocol更适合 LLM因为 CLI 具有推理即执行的低熵特性能避免复杂映射导致的高错误率[[22]]。CLI 的输出是结构化的文本大模型更容易理解和处理而 GUI 是像素级的视觉信息需要额外的视觉理解模块且界面变化会导致操作失效。从实践角度看维度CLIGUI输入形式结构化文本像素/截图输出形式结构化文本坐标/动作稳定性高命令不变低界面易变Token 消耗低高截图占 Token执行速度快慢需截图分析适用场景脚本化、批处理遗留系统、无接口应用大模型在 CLI 场景中表现更好或许不是偶然。六、未来怎么走三个可能的方向作为学习者我试着提出一些思考抛砖引玉1更智能的大模型模型能力持续提升是必然趋势。2025-2026 年国产模型在代码生成、Agent 规划方面快速追赶[[2]][[5]]。未来如果模型能更好地理解 GUI 元素语义不仅是看到还能理解进行多步规划并自我验证处理动态加载和异常情况那么 GUI 自动化的体验会大幅改善。但这需要时间也需要算力成本的支持。2应用 CLI 化另一个思路是让应用本身更适合 AI 操作。如果每个 Web是我没用好还是路还长——一个老博主对大模型自动化的学习笔记写在前面的话本文是我近期折腾大模型与网页自动化的一些真实记录。不是评测不是吐槽更不是指点江山。我只是个还在路上的学习者把踩过的坑、冒出的疑问写下来希望能和同样在探索的朋友们交流。如果有理解偏差恳请指正。一、一次不太顺利的尝试最近我尝试用国产大模型配合OpenClaw做网页自动化操作。OpenClaw 是一款开源的 AI Agent 工具通过 Chrome DevTools ProtocolCDP协议直接控制浏览器支持快照识别、元素点击、表单填写等功能理论上可以让大模型看懂网页并自动操作[[11]]。我的预期很简单让大模型生成操作脚本OpenClaw 执行完成一些重复性的网页任务。结果却让我有些困惑。用了几款国产模型包括一些在代码能力榜单上表现不错的生成的脚本总是卡壳——要么元素定位不准要么操作顺序错乱要么遇到动态加载就迷路。我第一反应是是不是我不会用二、先做功课国产大模型的代码能力到底如何带着疑问我去查了查最新的资料。根据 2026 年初的多份评测国产大模型在代码生成方面进步很快但与海外顶尖模型仍有差距。有分析指出国内头部模型大约落后海外最强模型3-6 个月的时间智谱 GLM-4.7、DeepSeek V3.2、MiniMax M2.1 等大概相当于 Claude Sonnet 4.5 上下的水平[[4]]。2026 年 3 月DeepSeek 发布了针对代码生成和数学推理的专项优化版本在多项基准测试中表现亮眼[[2]]。智谱也在 2 月正式发布了 GLM-5754B 参数在 Code Arena 等榜单上位居前列[[7]]。与此同时Claude Opus 4.6 在代码、文本、专家三大竞技场全部登顶尤其在 agentic coding智能体编程方面表现出色擅长处理需要规划和工具调用的复杂任务[[32]][[38]]。看到这里我意识到国产模型在进步但差距确实存在尤其在需要多步规划、工具调用的复杂场景中。我的自动化任务恰好属于这类场景卡壳或许不是偶然。而Claude因为自己要开发自己的所以其它第三方应用类似openclaw的费用会暴增20美元7x24hd的优惠已经不复存在。三、OpenClaw 的视觉能力强大但也有边界我继续研究 OpenClaw 本身。OpenClaw 的浏览器控制基于 CDP 协议提供 Snapshot 快照系统自动扫描页面并为可交互元素分配引用编号AI 可以直接使用这些编号操作元素无需手写 CSS 选择器[[11]]。这种设计比传统自动化框架更AI 友好。但官方文档也坦诚地指出OpenClaw 不完美——比 API 调用慢单次操作 15-30 秒、比脚本脆弱界面一变就迷路、Token 消耗大[[13]]。我回想自己的测试过程确实遇到了这些问题元素引用失效页面导航后之前的元素编号就失效了需要重新获取快照。如果大模型没有意识到这一点后续操作就会失败。动态加载现代网页大量使用异步加载元素可能延迟出现。大模型如果没有等待意识很容易点空。截图成本每次截图分析都消耗大量 Token长链条任务成本累积很快。这些不是 OpenClaw 的缺陷而是GUI 自动化本身的技术难点。OpenClaw 已经在尽力降低门槛但大模型需要足够聪明才能用好它。四、一个更早的教训Gemini 与 HTML 代码我想起更早的一次经历。当时 Gemini 3 Pro 可以通过antigravity免费使用、而且额度足够我让它帮我开发一个 HTML 前端页面不超过 1500 行。结果antigravity不断截图检查代码是它自己写的却还要反复截图验证最终磕磕巴巴写完截图占用的硬盘空间有好几个 GB现在想来这反映了一个更深层的问题大模型在 GUI 场景中缺乏自我验证的能力。它写出的代码自己无法直接运行验证只能依赖外部反馈截图。这种写-看-改的循环效率很低且容易陷入死循环。五、GUI vs CLI大模型更适合哪种交互这让我思考一个更大的问题大模型是否天生更适合 CLI命令行而非 GUI图形界面有技术文章指出CLI 比 MCPModel Context Protocol更适合 LLM因为 CLI 具有推理即执行的低熵特性能避免复杂映射导致的高错误率[[22]]。CLI 的输出是结构化的文本大模型更容易理解和处理而 GUI 是像素级的视觉信息需要额外的视觉理解模块且界面变化会导致操作失效。从实践角度看维度CLIGUI输入形式结构化文本像素/截图输出形式结构化文本坐标/动作稳定性高命令不变低界面易变Token 消耗低高截图占 Token执行速度快慢需截图分析适用场景脚本化、批处理遗留系统、无接口应用大模型在 CLI 场景中表现更好或许不是偶然。六、未来怎么走三个可能的方向作为学习者我试着提出一些思考抛砖引玉1家家都要更智能的大模型模型能力持续提升是必然趋势。2025-2026 年国产模型在代码生成、Agent 规划方面快速追赶[[2]][[5]]。未来如果模型能更好地理解 GUI 元素语义不仅是看到还能理解进行多步规划并自我验证处理动态加载和异常情况那么 GUI 自动化的体验会大幅改善。但这需要时间也需要算力成本的支持。我个人非常讨厌anthropic这家公司a中国IP大量被封杀b)对开源openclaw发过多次律师函改名为openclaw也跟这家公司有关c)最新消息显示openclaw用户再用claude大模型成本会大大增加基于4月4日以后的新的限制。——他可能还会继续作。2应用 CLI 化另一个思路是让应用本身更适合 AI 操作。如果每个 Web 应用都同时提供 CLI 接口或结构化 API大模型可以直接调用无需看图操作。这类似于无障碍访问的理念但面向的是 AI Agent。当然现实中有阻力有些网站不希望被脚本操作反爬、安全考虑老旧系统改造成本高商业模式可能依赖人工操作但长远看AI 友好可能成为应用设计的新标准。3混合模式GUI CLI 人工兜底也许最务实的方案是混合模式优先使用 CLI/API结构化、高效、稳定GUI 作为 fallback处理无接口的遗留系统人工兜底复杂异常时交由人类处理OpenClaw 本身也支持这种思路它提供 CDP 直接控制类似 CLI也支持视觉截图分析GUI可以根据场景灵活选择[[11]]。七、我的学习清单折腾一圈我给自己列了一个学习清单其实并没有这是大模型幻觉深入理解 OpenClaw 的 Snapshot 机制学会在脚本中正确处理元素引用失效问题。尝试 Claude Opus 4.6 或 GPT-5 系列对比不同模型在自动化任务中的表现。学习 Puppeteer/Playwright MCP了解更底层的浏览器自动化原理。关注国产模型的进展尤其是 DeepSeek、GLM 在代码和 Agent 方向的优化。思考AI 友好的应用设计也许未来的开发者需要同时考虑人类用户和 AI Agent。八、写在最后写这篇博客不是为了否定什么而是记录一个学习者的真实困惑和思考。大模型技术日新月异国产模型也在快速追赶。OpenClaw 这样的工具让 AI 操作网页成为可能虽然还不完美但已经打开了新的可能性。我可能确实没用好但这正是学习的意义。保持谦虚保持好奇继续折腾。欢迎在评论区交流你的经验和建议。如果你也在用大模型做自动化或者对 GUI vs CLI 有独到见解期待听到你的声音。参考资料OpenClaw Browser 官方文档及 CSDN 实战文章2025-2026 年国产大模型代码能力评测报告Claude Opus 4.6 技术评测与 GitHub Copilot 集成公告CLI vs MCP 技术分析文章本文写于 2026 年 4 月 5 日技术和认知都在快速变化如有疏漏欢迎指正。是不是我不会用用国产大模型包括号称写代码能力很强的能够跟opus打分不相上下的——没有一个操作起来不卡壳。大模型这种水平的情况下跟OpenClaw结合当然要大失所望了。你让openclaw操作一个网页结果用国产便宜大模型生成的脚本显然不行啊我没有自己试用GPT5.4 codex , claude code opus 4.6 thinking之类的我估计都有缺陷但这么差这不是我期待中的大模型。我记得gemini 3 pro在antigravity可以畅享的时候我曾经让antigravity开发一个html前端代码不超过1500行结果不断截图检查——html代码都是它自己写的居然还要反复截图——结果磕磕巴巴写完截图占用的硬盘空间有好几个GB这个问题是GUI转CLI似乎也难以接近的吧也是大模型适合cli不适合GUI的重要难点。如何解决未来行业和市场要尽早决断1更加智能的大模型2所有应用都cli化、至少cli和GUI同样的功能同步提供方便脚本自动操作可是有些网站未必欢迎脚本操作3其它请展开