企业官网建设流程全解析

简介：Automa v1.28.27 是面向 Chrome 浏览器的扩展打包文件，定位为面向运营、测试和低代码人群的 Web 自动化工具，可帮助不熟悉编程的用户处理重复性网页操作。通过可视化拖拽，可将打开网页、填写表单、点击按钮、截取屏幕、读取数据等操作串联成工作流，替代日常重复性浏览器操作。压缩包共69个文件，主体为44个 JavaScript 逻辑脚本、6个 CSS 样式、5个 HTML 界面，还包含图标、字体和多语言 JSON 语言包，整体仅2.1MB，既可拖拽到 Chrome 扩展页直接启用，也可用于分析扩展打包结构。已有2618人学习下载。包内包含后台脚本、弹出面板、内容脚本与全套本地化文件，支持中文等多语言；相比商店在线安装，离线 zip 包在隔离网络或内网环境更易部署，也方便前端开发者学习扩展的模块划分、事件交互与本地化组织方式。

1. 从浏览器里的一串流程开始：不需要写代码的 webUI 自动化

拿到 automa-chrome-v1.28.27.zip 这个包的时候，我第一反应是“又一个包装过的 Selenium”。实际用下来发现完全不是一回事：这是一个以浏览器插件形式存在的 webUI 自动化工具，把点击、填表、抓数据、循环、条件判断全部做成可视化节点，核心卖点是“不用写测试代码，也能把浏览器里的重复操作跑起来”。我之所以愿意把它拆开写一篇完整笔记，是因为在真实项目里它确实接替了不少原本要交给自动化测试框架的活儿——尤其是那些没有接口、只能靠页面操作的内部系统，用它的上手成本比写一套 WebDriver 脚本低得多。这篇笔记适合两类人：一类是刚接触 chrome 插件做自动化、不想从零啃框架的新手；另一类是已经写过 Selenium 脚本、想找一个轻量方案处理临时任务的工程师。文章会从选择理由、具体配置、参数坑一路讲到进阶玩法，全部按可复现的标准来写。

2. 为什么在 automa 和 Selenium 之间我会选插件方案：核心建模与选型边界

2.1 和传统自动化框架的对比：谁在什么场景下更省力

先给结论：automa 和 Selenium 这类 WebDriver 方案不是替代关系，而是互补关系。Selenium 的强项是复杂断言、持续集成、多浏览器矩阵，但这些强项在“临时抓个数据、批量填个表单、定期点几个页面”的场景里反而成了负担。你需要维护 driver、处理等待策略、写一堆样板代码，跑完一次就不用了，成本收不回来。

automa 的思路是把浏览器操作拆成一张流程图，每个节点只做一件小事，节点之间通过“数据”和“变量”传递信息。比如“打开网页”是一个节点，“点击按钮”是一个节点，“提取文本”是一个节点，你把它们按顺序连起来，就完成了一个任务。整个过程不需要编译、不需要测试框架、不需要懂断言怎么写。

从实际选型的角度，我会这样判断：如果任务是“每周把后台系统的订单导出成表格”，automa 是首选；如果任务是“每次发版前要在三个浏览器里跑完两百个回归用例”，那还是回去用 Selenium。我见过有人非要拿 automa 做并发压测，那属于工具选型出了偏差——它是操作浏览器，不是模拟协议请求，并发能力天然不如脚本方案。

2.2 工作流的基本组成：触发器、节点、数据与分支

automa 把一个任务叫做“工作流”。工作流里最小的单位是节点，节点之间有连线，表示执行顺序。需要理解的核心概念只有四个：

第一个是“触发器”。工作流怎么被启动，是手动点击播放、设置定时、还是监听快捷键，都由触发器决定。日常用到最多的是“手动触发”和“定时触发”。定时任务在版本 1.28.x 里可以直接在触发条件里配置 cron 表达式，比想象中方便。

第二个是“节点”。节点分为几大类：浏览器操作（打开页面、点击元素、填写表单、切换标签页）、数据操作（获取文本、获取属性、存储变量、表格数据）、逻辑控制（条件判断、循环、延迟）、系统集成（发送 HTTP 请求、读写剪贴板、导出文件）。每个节点右上角有一个输出，可以连接到下一个节点。双击节点就能看到它的配置面板，这是所有操作的主战场。

第三个是“数据”。数据在节点之间流动，主要形式是“当前页面的结果数据”和“全局变量”。抓取到的文本、元素的数量、HTTP 请求的返回值，都会挂到当前工作流的输出里，后续节点可以用“{{变量名}}”的方式引用。

第四个是“分支”。不是所有流程都是线性的。“条件判断”节点可以检查某个变量的值，然后决定走哪条分支；“循环”节点可以遍历一组数据，把每条数据分别交给后续节点处理。这两个节点是让工作流具备“处理真实业务”能力的关键，后面第 3 章会具体举例。

2.3 环境准备：解压、加载扩展、第一次完成触发

拿到 automa-chrome-v1.28.27.zip 后，第一步不是安装，而是确认浏览器版本。这个包要求 Chromium 内核的浏览器，Chrome 和 Edge 都行。我在本机 Chrome 上加载没问题，Edge 上同样能用。操作很简单：把 zip 包解压到一个固定目录，不要放在会被系统清理的临时文件夹里，否则下次开机插件可能被浏览器自动停用。

接着打开浏览器的扩展管理页面，开启右上角的“开发者模式”，然后点击“加载已解压的扩展程序”，选择刚才的解压目录。加载成功后，浏览器右上角会出现 automa 的图标，点击图标就可以进入工作流列表页。第一次使用时建议先跑一个最简单的“打开百度”工作流验证环境：新建工作流、添加“打开网页”节点、输入网址，点执行，看到浏览器自动打开页面就算成功。

提示：扩展程序目录不要删除或改名，加载后浏览器会持续读取里面的文件。路径一变，插件就会失效，必须重新加载一次。

2.4 录制模式：别手搭，先让工具自己走一遍

很多新手习惯手动去拖节点搭建工作流，我建议反着来：先点图标打开面板，找到“录制”功能，自己手动在页面上操作一遍，automa 会把操作步骤自动生成节点。录制完成后停止，打开工作流编辑页，你会看到刚才的操作已经变成一串节点。

录制生成的内容通常不够完美——比如会出现多余的空节点、选择器不够精确、没有等待逻辑——但这是一个很好的起点。我一般的做法是录完后进入编辑页，把不需要的节点删掉，给关键节点加上“延迟”或“等待元素出现”。这样可以省掉从零搭流程的绝大部分时间，尤其是在面对复杂表单时，录制能准确捕捉到输入框的 name 或 id，比自己猜选择器要靠谱得多。

这里有一个容易被忽略的细节：录制模式下，automa 不会记录“页面等待”行为。如果页面加载慢，录出来的流程会在下一步节点执行时找不到元素，导致任务中断。所以录制结束后第一件事，就是在需要的地方插入等待节点，频率大约每两到三个操作加一次。

3. 把一条真实流程跑通：选择器、变量和循环的具体配置

3.1 元素定位是第一步：用 XPath 和 CSS 选择器给浏览器指路

automa 里几乎所有的页面操作节点都需要配置“选择器”。选择器就是告诉浏览器“你要操作的到底是页面上的哪个元素”。支持两种写法：CSS 选择器和 XPath。

CSS 选择器适合有稳定 class 或 id 的页面，写法和我们平时写样式用的选择器一样，比如#login-btn或.form-item input[name="username"]。XPath 则更强大，可以按文本内容找元素，也可以找某个元素相对结构里的兄弟节点。比如页面上有一个“提交”按钮，但它的 class 是动态生成的，用 XPath 写//button[contains(text(),'提交')]就能稳定命中。

在 automa 的“点击元素”节点里，选择器配置要注意几个细节：

• 尽量用唯一的、语义明确的属性，不要用div > div > div > button这种层级链，页面一改就崩。
• 如果页面有 iframe，automa 需要先加入“切换到 iframe”节点，否则选择器拿不到跨 iframe 的元素。这是新手最容易翻车的地方。
• 选择器填完后，可以先点击节点配置面板里的“校验”按钮，工具会高亮匹配到的元素，预览效果满意再继续。

我在处理实际项目时，一般会先用开发者工具 F12 定位到目标元素，看它的 id 和 name 属性有没有规律，再决定用哪种选择器。比如下面这段表单，就用 name 属性定位更稳：

<form id="queryForm"> <input name="startDate" placeholder="开始日期" /> <input name="endDate" placeholder="结束日期" /> <button type="submit">查询</button> </form>

对应的选择器可以分别写成#queryForm input[name="startDate"]和#queryForm input[name="endDate"]。id 在整页唯一，name 又比 placeholder 更不容易变化，整条链路的稳定性会好很多。不要用 placeholder 或者标签文字去定位输入框，那些在业务系统里经常被改。

3.2 页面加载完成不等于元素可以点击：等待与重试策略

webUI 自动化里最玄学的问题就是“元素找不到”。常见表现是：手动操作页面一切正常，但自动化跑的时候，按钮就是点不到。原因基本都是时机问题——页面还在异步加载，目标元素还没渲染出来，节点就尝试点击了。

automa 对此提供了几个节点：“延迟”“等待元素出现”“等待元素消失”。“延迟”就是固定等多少毫秒，简单但粗暴；如果网络慢，等待时间不够还是会失败；如果网络快，等待时间设置太长又会拖慢整体任务。我更推荐用“等待元素出现”节点来处理。

配置“等待元素出现”时，需要填入两个参数：目标元素的选择器、等待的超时时间。工具会每隔一小段时间去检测元素是否存在，一旦检测到就直接往下走。这样无论页面是 1 秒加载完还是 10 秒加载完，任务都能在元素就绪的第一时间继续执行，而不是傻等一个固定时间。

除了等待，还可以在“点击元素”节点的设置里勾选“重试”。这个选项的意思是：如果第一次点击失败，会重新定位元素再次尝试。配合最大重试次数参数，能解决大约八成以上因为元素闪烁导致的操作失败。

注意：合理设置等待和重试的参数不是增加成功率，而是避免“假成功”。如果页面元素一直没出现，重试到超时后任务会报错，至少你能明确知道哪里断了；如果靠固定延迟蒙混过关，很可能是“界面显示了但数据还没加载完”，后续节点抓到的就是一串空值，这种错误最难排查。

3.3 抓取数据与变量传递：让结果在节点之间流动

做自动化永远绕不开“把页面数据拿出来”。automa 的“提取数据”节点支持从当前页面提取文本、链接、图片地址等信息，提取结果会存到该节点的输出里，命名为“数据”。后续节点想使用这个数据，需要用变量引用的方式，比如{{outputData["data"]}}。

举一个我实际做过的场景：抓取某后台管理系统的表格数据，页面上有一个列表，每一行有订单号、金额、状态三个字段。用 automa 的“提取数据”节点，选择“表格”模式，它会自动识别页面里的 table 元素，把整张表提取成一个二维数组。提取结果可以直接导出为 JSON，也可以存到变量里等待后续处理。

提取配置里有一个“匹配元素”的选项，这个字段非常关键。如果你只想提取某几列，可以在节点配置里勾选列过滤；如果不设置，它会把整个可见表格都抓出来，里面可能混着操作按钮的文字、空单元格之类的噪音。我的习惯是先抓一次原始数据，跑完工作流后查看输出日志，确认数据结构没问题，再倒回去把列过滤加上。

变量在 automa 里有两种作用域：当前工作流和全局。前者只在当前任务内有效，每次执行开始时都是空白的；后者存储在浏览器本地，可以跨工作流读写。对于需要多次复用的登录状态、接口地址、用户信息这类数据，建议存到全局变量里。配置方式是在变量管理界面点击“新增”，填入变量名和默认值，工作流里用{{global.变量名}}来引用。

3.4 循环与条件判断：批量处理数据的核心武器

如果你要处理的不只是页面上的一两个元素，而是整个列表里的几十条数据，循环节点就是必需的了。automa 有三种循环：固定次数循环、遍历数据列表循环、遍历页面上找到的元素循环。

以“遍历页面上找到的元素”为例，这个循环节点的配置里要填一个选择器，工具会找出页面上所有匹配该选择器的元素，然后针对每一个元素执行循环体里的操作。比如页面上有十个按钮，选择器填.action-btn，循环体会执行十次，每一次的“当前元素”都指向其中那个按钮，循环体内可以对该元素做点击、提取文本等操作。

条件判断节点和循环配合使用，就是完整的自动化逻辑。典型场景：循环遍历表格每一行，检查“状态”这一列的值，如果是“待审核”，就点击该行的“通过”按钮；如果是“已驳回”，就跳过。条件节点里可以选择比较方式：等于、包含、正则匹配等等。这个组合能辐射掉业务系统里大量“重复审批、重复处理”的工作。

需要提醒的是，循环体内部的节点顺序要仔细。我一开始做循环时，经常把“等待元素出现”放在循环体外面，导致循环第二次执行时直接报错。正确做法是：等待节点放在循环体内部，让每一次循环都重新等待当前元素出现。

4. 避坑指南：五个让工作流中途崩掉的老问题

4.1 现象：点击元素时提示“找不到元素”，但手动操作明明能点

原因有三个高频来源：第一是元素在 iframe 内，automa 当前没有切换到对应框架，所以看不到；第二是页面有多个相同文本的按钮，选择器匹配到了多个元素，工具不知道该点哪一个；第三是前端框架的虚拟列表，元素在视口外需要滚动才能加载。

解决的顺序是：先在配置面板里点击“校验”看匹配情况，如果是多个元素，改用nth-child或增加父级限定；如果完全不匹配，打开 F12 看目标元素是否在 iframe 里，在的话就加一个“切换到 iframe”节点；如果是滚动加载列表，先加“滚动到元素”节点再操作。从那次以后，我每处理一个新的目标页面，第一件事就是检查 iframe 和多个匹配，这两个因素至少占排查工作量的七成。

4.2 现象：表单填了值，点提交后却发现页面没有收到

这是 Vue 和 React 项目里特别典型的问题。页面框架的输入框控件在 automa 填入值后，输入框本身显示内容了，但框架内部的响应式数据没有更新，提交时拿到的是空值。本质原因是 automa 的“填写表单”节点直接修改了 DOM 的 value 属性，但没有触发框架监听器。

解决方法是：不用“填写表单”节点，改用“执行脚本”节点，手动派发一个 input 事件。脚本写法大致是这样：

const input = document.querySelector('input[name="username"]'); const setter = Object.getOwnPropertyDescriptor(window.HTMLInputElement.prototype, 'value').set; setter.call(input, '需要填入的内容'); input.dispatchEvent(new Event('input', { bubbles: true }));

这段脚本先通过原生 setter 修改输入框的值，再手动派发一个冒泡状态下的 input 事件，让框架的监听器能够感知到变化。这样填完后的值才会正式进入表单的状态管理体系。在 automa 里，把这个脚本放到“执行脚本”节点中，组件类型选“页面”，目标框架保持默认，执行时机选“立即执行”，节点运行之后表单就写入成功了。从那以后遇到任何填写后提交无效的问题，我的第一反应都是改成执行脚本派发事件。

4.3 现象：工作流执行到一半，浏览器弹出了新标签页，后续节点全部失效

有很多登录流程是点击后跳到新标签页完成的，或者点击的目标元素是target="_blank"的链接。automa 的默认行为是在当前页面继续操作，新标签页里的元素它不会自动接管。

解决方式是启用“激活标签页”节点，工作流执行到那一步时，工具会切换到刚才新建的标签页，后续节点会在新页面里继续操作。还有一种做法是直接配置元素点击的行为为“新标签页打开”，然后在下一个节点处立即切换到新标签页。如果切换后会丢失上下文，还可以先用“获取标签页信息”节点拿到所有标签页的列表，再按标题匹配并激活目标页面。

4.4 现象：任务放在后台定时跑，有时候跑着跑着就不动了，也不报错

这种情况多数是插件的“效率模式”或浏览器的“睡眠模式”在起作用。浏览器为了省电，会隔一段时间暂停后台标签页的计时器和异步任务，automa 的定时工作流也会受影响。表面看是任务没执行完，实际上是被浏览器挂起了。

处理方式有两步：一是确认执行环境不进入睡眠状态，把运行任务的那个标签页固定在浏览器窗口前端；二是如果任务时间较长，把一个大工作流拆成多个子任务，用“执行子工作流”节点串联，降低单次任务的执行时长，也方便定位具体是哪一步卡住的。

4.5 现象：抓取列表数据时，输出的数据只有第一行，剩余行全是空

原因是循环和定向提取之间的配合出了问题。很多人会把“提取数据”节点放在循环外，希望能一次性抓取全部数据；但循环体没有绑定到当前元素，后续行自然提取不到。正确方式是：循环节点开启“遍历元素”模式，并在提取节点的配置中勾选“相对于当前循环元素提取”，这样每一次循环都会只在当前循环到的元素范围内做提取。

判断方法很简单：跑一次任务，查看日志里循环节点的执行次数。如果循环次数只有一次，说明选择器只匹配到了一个元素——大概率是循环节点里填的选择器和实际列表行的选择器不一致。

5. 进阶用法：定时抓取、接口推送和多个子工作流的组合任务

5.1 用 HTTP 请求节点把抓取数据推送到业务接口

automa 的“发送 HTTP 请求”节点，能把抓下来的数据直接推给业务系统，这意味着“页面抓数据”和“接口写数据”可以在同一条工作流里完成，不需要中间人手工搬运。

节点配置时选择请求方法，多数场景是 POST，填写接口地址、请求头、请求体。请求体的数据可以从上一个节点引用：在请求体编辑区直接写变量模板，比如{"orderId": "{{outputData['data'][0]}}"}，每次执行时工具会自动替换为实际值。

这个节点在配置上有一个容易忽略的参数：内容是“自动检测”还是手动指定。如果推给后端的接口要求 JSON，一定要显式把内容类型设为 application/json，否则工具默认发的是表单格式，后端接不到。我当初刚用的时候就吃过这个亏，前端一直报 200，后端说没收到字段，最后排查才发现是 Content-Type 不对。

5.2 组合一个完整任务：定时抓取 → 数据清洗 → 推送告警

以“每天上午九点自动抓取库存数据，有异常时推送通知”为例，这条工作流可以拆成四个子流程，用“执行子工作流”节点串联：

整个流程结构中，“数据检查”子流程是最有变数的，可以根据业务规则扩展出多层条件判断。异常条件写在“条件判断”节点里的表达式如下：

{{outputData['库存数量']}} < 10

满足条件就进入“消息通知”分支，不满足就跳到下一个数据行继续判断。这样一整条链路跑下来，每天都能自动完成一个值班人员需要花半小时的人工检查工作。我后来给几个内部系统做过类似的组合任务，只要页面结构不频繁改动，连续跑半个月都很稳定，不需要人干预。

5.3 调试技巧：用日志节点定位工作流断点，别再用 alert

调试 automa 工作流时，最常见的需求就是“看看当前变量到底是什么值”。很多人喜欢在“执行脚本”节点里写 alert 弹窗，但弹窗会中断自动化执行，非常影响调试节奏，也更低效。

automa 自带的“日志”节点能以一种更轻量的方式完成这件事。把它插到需要检查的节点后面，配置里选择输出变量名，执行任务时，工具的控制台会打印详细信息，包含变量类型、结构和实际值。查看路径是点击右上角的插件图标 → 打开控制台 → 切到运行日志标签页。这比 alert 那种粗暴的方式好很多：不会打断流程，还可以保留历史记录。

5.4 从一版跑通的方案，到一份可以交给别人的流程

最后一个建议，也是我切身体会最深的部分：automa 工作流和代码一样，是需要持续维护的。我刚开始用它时，把所有节点堆在一个大工作流里，一遇到页面改动就花大力气一个个排查；后来拆成子工作流，每个子流程只做一件事，哪个环节报错直接就定位到对应模块。现在已经形成习惯，任何新搭建的任务都会先写上“打开页面”和最后的“日志输出”节点，确保流程的起点和终点都是可观测的，从那以后我每次交付工作流都强制走一遍“录制 → 重跑 → 加日志 → 再重跑”的完整校验流程，会顺手很多，希望帮到你。

本文还有配套的精品资源，点击获取