1. 项目缘起为什么要让 AI 自己去社区发稿先说结论这个项目的本质是把内容发布这条重复度极高、但又充满细节坑的链路交给一个能自己看页面、自己点按钮、自己填表单的 AI Agent 去跑。标题里那句227 次操作、4.3 小时、9 个坑不是营销话术是我盯着日志一条条数出来的真实数据。我做这件事的动机很朴素。手上有一批技术复盘稿需要陆续发到腾讯云社区这类开发者内容平台。手动发一篇的流程大概是登录、进创作中心、选专栏、填标题、填摘要、贴正文、调格式、传封面、选标签、预览、提交、等审核。单篇十分钟起步遇到格式错乱、图片上传失败、标签选不上二十分钟也打不住。发十篇就是两三个小时纯体力活而且越到后面越容易手滑。于是我想能不能让 AI 自己去做这件事。注意这里说的不是让 AI 写一篇文章然后我复制粘贴而是让 AI 真正接管浏览器——它自己打开页面、自己识别输入框、自己敲字、自己点提交。这就引出了两个核心技术选型浏览器自动化和AI Agent 的决策能力。浏览器自动化这块我最终选了Playwright。原因后面细讲简单说就是它对现代前端框架的兼容性、等待机制、多浏览器支持都比老一代方案省心。AI 决策这块用的是 WorkBuddy 这类能调用工具、能看截图、能根据页面反馈调整下一步动作的 Agent 框架。这篇文章适合谁看三类人。第一类是想把重复性网页操作自动化、但不知道从哪下手的开发者第二类是在用 Playwright 做自动化测试、想扩展到真实业务操作场景的测试工程师第三类是单纯好奇AI Agent 到底能不能干成一件完整的脏活累活的技术爱好者。我会把 227 次操作拆开讲把 9 个坑一个个摆出来包括每个坑的报错、排查思路和最终解法。提示本文所有操作均针对公开的、允许用户正常发布内容的平台属于个人账号的常规内容发布行为。请勿将相关技术用于任何违反平台规则或法律法规的场景。2. 整体方案设计为什么是 Playwright 加 AI Agent2.1 传统脚本自动化的死穴在哪在动手之前我先评估了纯脚本方案也就是用 Playwright 写死每一步的定位器和操作。这条路我走过结论是对付稳定页面可以对付经常改版的富文本编辑器就是灾难。问题出在三个地方。第一富文本编辑器比如各种基于 contenteditable 或 ProseMirror 的编辑器的 DOM 结构极其复杂一个输入正文的动作背后可能是几十个嵌套 div定位器稍微写死一点页面一更新就全废。第二登录环节有验证码、有滑块、有短信验证纯脚本很难优雅处理。第三也是最要命的——页面状态是动态的弹窗什么时候出现、加载动画什么时候消失、按钮什么时候从 disabled 变可点纯脚本只能靠waitForTimeout硬等等短了报错等长了浪费时间。我统计过纯脚本方案在第一次跑通后平均每两周就会因为页面微调而失效一次维护成本高得离谱。2.2 AI Agent 接管决策层的思路所以我把方案改成了Playwright 负责执行AI 负责决策的分层结构。具体来说Playwright 提供的是手和眼它能截图、能获取页面可交互元素列表、能执行点击和输入。AI Agent 提供的是脑子它看截图和元素列表判断现在页面处于什么状态下一步该点哪里这个输入框是不是我要找的标题框。这个分层的好处非常明显。页面改版了没关系AI 看的是语义不是写死的 CSS 选择器。它看到一个带 placeholder 写着请输入标题的输入框就知道这是标题框哪怕这个框的 class 名从title-input改成了editor-title__field。弹窗出现了AI 从截图里能看出来会先处理弹窗再继续。代价是速度慢。每一次决策都要截图、上传、推理、返回动作单步耗时从纯脚本的几十毫秒涨到几秒。这也是为什么最终跑了 4.3 小时——227 次操作平均每次操作加上决策和等待接近 70 秒。这个数字后面还会细算。2.3 关键选型对比为什么不是别的方案我把当时考虑过的几个方案列了个表方便你对照自己的场景做选择。方案决策方式页面改版适应性单步速度适合场景纯 Playwright 脚本写死定位器差易失效毫秒级稳定页面、批量数据抓取Playwright 录制回放录制操作序列较差毫秒级一次性任务Playwright AI AgentAI 实时决策好秒级复杂交互、频繁改版纯 API 调用直接调接口不涉及页面最快有开放接口的平台这里有个重要判断如果目标平台有开放的内容发布 API优先用 API别碰浏览器自动化。浏览器自动化永远是最后的选择因为它最脆弱、最慢。我之所以走浏览器这条路是因为目标平台的发布链路涉及富文本编辑、图片上传、标签选择等交互没有现成的发布接口可用。注意选型时先花半小时确认有没有 API。很多人一上来就写自动化脚本结果发现平台早就提供了接口白白浪费几天。2.4 整体架构拆解最终跑起来的架构分四层任务层定义发一篇稿这个目标包含标题、正文、标签、封面图等素材。决策层AI Agent负责看页面状态、规划下一步动作。执行层Playwright负责截图、定位元素、点击、输入、滚动。观测层日志和截图存档记录每一次操作的输入输出方便复盘。这四层里观测层是我强烈建议所有人都加上的一层。227 次操作如果没有完整日志出了问题根本没法定位。我每步都存了截图和动作记录最后才能把 9 个坑一个个还原出来。3. 核心细节解析227 次操作都花在哪了3.1 操作次数的构成拆解很多人看到227 次操作会觉得夸张发一篇文章哪需要这么多步。我把日志按阶段统计了一下数据如下。阶段操作次数占比说明启动与登录3816.7%含等待登录态、处理登录弹窗进入创作中心219.3%多次导航与页面确认填写标题与摘要198.4%含输入校验与重试正文粘贴与格式化6428.2%最耗时富文本处理图片上传3314.5%含等待上传完成标签与分类选择2711.9%下拉框交互复杂预览与提交2511.0%含多次确认与错误处理可以看到正文处理占了将近三成这是整个流程里最麻烦的部分。原因在于富文本编辑器对粘贴这件事的处理方式千奇百怪有的支持直接粘贴 Markdown有的会把 Markdown 当纯文本有的会保留一堆内联样式。3.2 单步耗时的真实分布227 次操作跑 4.3 小时平均每步 68 秒。但这个平均值有误导性因为耗时分布极不均匀。AI 决策步每次截图加推理平均 4 到 8 秒。页面等待步等加载、等上传、等弹窗消失平均 10 到 30 秒。纯执行步点击、输入平均 1 到 2 秒。异常重试步一旦触发重试单步可能 60 秒以上。真正拖时间的是等待和重试。我算过如果去掉所有重试和异常处理理想情况下这个流程大概 40 分钟能跑完。多出来的三个多小时全是跟页面斗智斗勇。3.3 富文本正文处理的三种策略正文处理是重头戏我试了三种策略最后选了第三种。策略一模拟键盘逐字输入。用 Playwright 的type方法一个字一个字敲。优点是兼容性最好几乎所有编辑器都认。缺点是慢到无法接受一篇三千字的稿子要敲十几分钟而且遇到中文输入法相关的兼容问题容易乱码。策略二直接设置 innerHTML。用evaluate直接往编辑器里塞 HTML。优点是快。缺点是很多编辑器有内部状态管理你直接改 DOM它的数据模型没同步一提交就发现内容丢了或者格式全乱。策略三剪贴板粘贴。先把内容写进剪贴板然后模拟CtrlV。这是最接近真人操作的方式编辑器会走它正常的粘贴处理逻辑。最终我用的就是这个。// 把 Markdown 内容写入剪贴板再粘贴的核心思路 await page.evaluate(async (text) { await navigator.clipboard.writeText(text); }, markdownContent); // 聚焦编辑器后触发粘贴 await editorElement.focus(); await page.keyboard.press(ControlV);提示剪贴板方案在无头模式下可能失效建议用有头模式跑或者用 Playwright 的权限授予机制显式允许剪贴板访问。3.4 元素定位的语义化改造AI Agent 决策依赖的是页面可交互元素列表。我一开始直接把所有 DOM 元素丢给 AI结果 AI 被几千个元素淹没了决策质量极差。后来我做了语义化过滤只保留真正可交互的元素并且给每个元素生成一段人类可读的描述元素类型输入框、按钮、链接、下拉框可见文本或 placeholder是否可见、是否可点击在页面中的大致位置这样 AI 拿到的是一份几十条的精简清单决策准确率大幅提升。这个改造是项目能跑通的关键之一很多人做 AI 浏览器自动化失败就是败在喂给 AI 的信息太脏。4. 实操过程从零跑通一次完整发布4.1 环境准备与依赖安装环境这块没什么玄学Node.js 加 Playwright 是标配。我用的版本组合是 Node 18 加 Playwright 最新稳定版。# 初始化项目 npm init -y # 安装 Playwright npm install -D playwright/test # 安装浏览器内核 npx playwright install chromium这里有个经验优先用 Chromium。不是因为它最好而是因为它在自动化场景下最稳定社区资料最多遇到问题最好搜。Firefox 和 WebKit 在富文本编辑器上的表现经常有意外。AI Agent 那侧我用的是支持工具调用的框架把 Playwright 的截图、点击、输入封装成工具函数暴露给 Agent。工具函数的描述要写得非常清楚比如click_element(elementId)点击指定 id 的元素elementId 来自最近一次页面元素列表。4.2 登录态的处理与复用登录是第一个大坑。我的做法是首次手动登录之后复用登录态。Playwright 支持把浏览器的 storageState 保存下来下次启动直接加载就跳过了登录流程。// 首次手动登录后保存状态 const context await browser.newContext(); // ... 手动完成登录 ... await context.storageState({ path: auth.json }); // 后续加载已保存的登录态 const context await browser.newContext({ storageState: auth.json });这个方案能省掉大量重复登录操作。但要注意登录态会过期一般几天到几周不等。我在流程里加了一个检测进入创作中心后如果发现被重定向到登录页就暂停任务并提示人工介入而不是傻乎乎地继续跑。4.3 正文粘贴的完整实现正文这块我把完整流程拆成了五步每一步都有讲究。第一步先把 Markdown 转成平台能识别的格式。有的平台支持直接粘贴 Markdown 自动渲染有的需要先转 HTML。我做了个判断先尝试粘贴 Markdown如果预览发现格式没渲染再走 HTML 转换。第二步定位编辑器。这里不能写死选择器而是让 AI 从元素列表里找看起来像正文编辑区的元素判断依据是它面积大、可编辑、位置在标题下方。第三步聚焦并清空。粘贴前先确保编辑器是空的否则会追加到旧内容后面。第四步执行粘贴。用前面说的剪贴板方案。第五步校验。粘贴后截图让 AI 确认内容是否完整、格式是否正确。这一步很关键因为粘贴失败是静默的不校验的话你根本不知道内容丢了。4.4 图片上传的等待策略图片上传是第二个大坑。上传按钮点了之后图片要经历选择文件、上传、服务器处理、返回 URL、插入编辑器几个阶段每个阶段耗时不定。我一开始用固定等待等 5 秒就继续结果大图经常没传完就往下走导致图片丢失。后来改成状态轮询每隔 2 秒截图一次让 AI 判断上传进度条是否消失图片是否已出现在编辑器里直到确认完成或超时。async function waitForUploadComplete(page, maxWaitMs 60000) { const start Date.now(); while (Date.now() - start maxWaitMs) { const done await checkUploadStatus(page); // AI 判断 if (done) return true; await page.waitForTimeout(2000); } throw new Error(图片上传超时); }这个轮询策略把图片丢失率从最初的 30% 降到了接近零。4.5 标签选择的交互细节标签选择看着简单其实坑不少。很多平台的标签是一个输入框加下拉建议你输入关键词后要等建议列表出现再点选。如果输入太快建议列表还没出来你就点了就会选空。我的处理是输入关键词后等建议列表出现同样用截图加 AI 判断再点第一个匹配项。选完还要确认标签真的加上了因为有些平台点选后标签会以 chip 形式显示有些则只是填进输入框需要再按回车。4.6 提交前的最终校验清单提交是不可逆的所以我在提交前加了一道校验。让 AI 对照截图逐项确认标题是否非空且与预期一致正文是否有内容且格式正常封面图是否已上传标签是否至少选了一个分类是否正确任何一项不通过就暂停不自动提交。这道校验帮我拦下了好几次正文粘贴失败但流程还在继续的情况。5. 九个坑的完整复盘与排查技巧5.1 坑一到坑三登录与导航相关坑一登录态静默失效。表现是流程跑到一半突然所有元素都找不到。排查发现是登录态过期页面被重定向到登录页但脚本还在按原页面找元素。解法是加一个页面身份校验每次关键操作前先确认当前页面是不是预期页面。坑二多标签页干扰。点击某些链接会打开新标签页Playwright 默认还在旧标签页操作导致找不到元素。解法是监听page事件及时切换上下文或者干脆拦截新标签页打开。坑三导航等待不准确。用waitForLoadState(networkidle)有时候会一直等不到因为页面有长轮询请求。解法是改用domcontentloaded加自定义的元素出现等待。5.2 坑四到坑六内容填写相关坑四富文本粘贴丢格式。前面讲过最终用剪贴板方案解决。坑五输入框有字数限制。摘要框限制 100 字我一开始没截断超出的部分被静默丢弃导致摘要不完整。解法是提交前校验字数超长就自动截断并加省略号。坑六特殊字符导致输入异常。正文里有代码块包含反引号和花括号某些编辑器会把这些当特殊语法处理。解法是粘贴前对内容做转义预处理。5.3 坑七到坑九提交与异常相关坑七提交按钮有防重复点击。快速点两次第二次会触发风控提示。解法是点击后禁用按钮等状态变化再继续。坑八提交后跳转不确定。有时跳转到成功页有时弹 toast 提示有时直接留在原页。解法是不依赖跳转判断成功而是综合多种信号URL 变化、toast 文本、页面元素变化。坑九网络抖动导致请求失败。偶发的网络问题会让某个操作失败。解法是给关键操作加重试机制但重试要有上限避免死循环。5.4 常见问题速查表现象可能原因排查方向解决手段元素找不到页面未加载完/登录失效看当前截图和 URL加页面身份校验内容丢失粘贴失败/编辑器未聚焦对比粘贴前后截图剪贴板方案加校验图片不显示上传未完成查上传状态状态轮询等待提交无反应按钮 disabled/风控看按钮状态点击后等待状态变化流程卡死等待条件永不满足看日志最后一步加超时和兜底提示这张表建议打印出来贴在显示器边上。浏览器自动化的坑八成都能在这张表里找到对应。6. 经验总结与后续优化方向跑完这一趟我最大的体会是AI 浏览器自动化的瓶颈不在 AI 智商而在信息质量和异常处理。AI 足够聪明但你喂给它的页面信息如果又脏又乱它照样抓瞎流程里的异常如果没兜住它就会卡在那里干等。几个我认为最有价值的经验。第一观测层必须做扎实每步截图加日志这是复盘的前提。第二等待要用状态判断不要用固定时间这是稳定性的关键。第三提交类操作一定要加前置校验宁可暂停等人工也不要错误提交。后续我打算优化的方向有三个。一是把常见页面的元素语义化提取做成可复用的模块减少重复开发。二是引入更细粒度的重试策略区分可重试错误和需人工介入错误。三是把整个流程的耗时数据做成看板持续监控哪一步在变慢提前发现页面改版。最后分享一个小技巧如果你也想做类似的事先用有头模式跑通全流程再考虑无头。有头模式下你能亲眼看到 AI 在干什么出问题一眼就能定位。我前三个坑都是在有头模式下几分钟就找到原因的如果一上来就无头估计得排查一整天。
