ChatGPT+Chrome扩展实测：AI操作网页的链路、提示词与排查指南

之前做月底报销整理时，每天要在网页端核对一批发票信息，同时还要横向对比几个平台的活动方案。这种重复性网页操作手动做非常耗时，恰好最近在琢磨 ChatGPT 和 Chrome 扩展结合的场景，干脆把“让 AI 接手网页操作”这件事完整跑了一遍实测。本文就是这次实测的记录，重点拆解发票信息整理、跨网站行程规划两个典型场景，包括场景设计、提示词写法、执行过程、效果观察、常见报错排查和工程落地建议。

不管你是用 ChatGPT 生态工具做自动化的普通用户，还是对浏览器智能体、Chrome 插件开发感兴趣的开发者，这篇文章都可以作为一个从现象到原理的参考读本。读完你能搞清楚三件事：第一，浏览器里运行 AI 操作网页的基本链路是什么；第二，发票整理、跨网站规划这类任务怎么设计提示词和验证流程最稳；第三，遇到识别失败、页面元素抓不到、权限报错时，应该按什么思路排查。

1. 从“读内容”到“动手做”：浏览器里的 AI 发生了什么变化

早期浏览器里的 AI 工具，基本都是“读页面”类型。用户打开一篇文章，点开侧边栏插件，AI 把页面正文压缩成摘要，或者翻译成另外一种语言。这个阶段有一个很明显的特点：AI 与网页之间是单向的，它只能看到静态内容，不能点击按钮，不能切页，也不能替你填写表单。

最近这一两年，“智能体”这个概念出现在浏览器端之后，情况发生了变化。带操作能力的 AI 扩展不只是读数据，而是像人一样，把页面当成交互界面：移动鼠标焦点、点击链接、填写输入框、翻页、提取表格，一步一步完成目标。用一句话概括，就是 AI 从“建议你做”变成了“替你做”。

这种能力在工程上通常叫浏览智能体（browser agent）。它本质上是一个循环：

1. 浏览器把当前页面状态发出来，包括可见文本、可点击元素、输入框内容；
2. AI 根据用户需求决定下一步动作；
3. 浏览器执行动作，比如点击某个按钮、填某个字段；
4. 页面变化后，再抓取新状态，进入下一轮推理。

所以真正支撑“AI 操作网页”的，不只是大模型的对话能力，更有赖于浏览器扩展暴露出来的页面控制能力。这两部分缺一不可。

这里需要区分一个容易混淆的概念。用户经常把“ChatGPT Chrome 扩展”理解成一个能自动操作网页的工具，但实际中它有几个不同形态：

• 助手型扩展：核心是侧边栏对话、页面总结、划词解释，不对页面做深层操作；
• 智能体型扩展：能识别页面元素并点击、输入、跳转，完成多步任务；
• 定制开发型：自己通过 Chrome 扩展架构调用 ChatGPT API，把页面操作封装成工具函数，自由控制流程。

本文实测的场景，主要是以后两类为主。特别是在发票整理和跨网站规划时，智能体需要同时完成“理解页面结构”“提取目标字段”“跨页面导航”这几件事，单纯给一个对话窗口是远远不够的。

另外一个需要理解的点是，AI 操作网页并不等于“看见像素然后模拟鼠标”。大部分工程实现更喜欢走结构化路线：扩展脚本负责把页面里的链接、按钮、表格行、输入框提取为结构化文本，交给大模型做判断，再把判断结果映射回页面元素执行。这样做的好处是稳定，不需要复杂的目标检测模型，也更容易调试。

2. 环境准备与版本说明

2.1 基础环境要求

这次实测基于 Chrome 浏览器的稳定版本，扩展采用 Manifest V3 规范。其实 Chrome 社区从 2023 年开始全面推广 Manifest V3，新的权限模型更严格，对远程代码、跨域请求也有更多限制，所以如果读者要自建扩展，建议优先按 V3 来做，而不是沿用 V2 的老思路。

其他准备项如下：

大多数普通用户不需要写代码，安装现成扩展即可；但如果你要做可控的发票自动处理，还是建议掌握一点扩展开发的基础，这样遇到页面结构变化时能自己调整脚本。

2.2 工具链选型

我在实测中采用的组合是：Chrome 浏览器作为运行载体，自建或使用第三方扩展作为页面控制层，通过 API 调用大模型获得决策能力。之所以不依赖某一个官方入口，是因为发票整理过程中需要精确控制页面表结构的解析，而通用对话框很难满足这种定制需求。

这里给出一张工具对比表，方便读者定位自己适合哪条路线：

如果你只是想快速体验网页操作，第三方插件最省事。但像我这样要落地到具体业务，或者对输出格式有严格要求的场景，自建或半自建方案更合适。

2.3 最小项目结构

后面涉及代码的部分，我按一个最小可运行的扩展项目来介绍。目录结构大致如下：

chrome-chatgpt-agent/ ├── manifest.json ├── background.js ├── content.js ├── popup.html └── popup.js

• manifest.json：声明扩展权限、脚本注入规则；
• background.js：后台服务工作线程，负责调用 API 和标签页操作；
• content.js：注入页面内部，读取 DOM 数据；
• popup.html / popup.js：弹出操作面板，输入任务提示词。

这个结构不复杂，后续会逐步解开它的工作机制。

3. 核心原理：Chrome 扩展如何把“手”交给 AI

3.1 整体链路

“AI 操作网页”听起来像是黑科技，但拆开以后链路很清晰。以自建扩展为例，一次完整操作包含下面几个环节：

1. 用户在 popup 中输入指令，比如“提取本页所有发票，整理成表格”；
2. background 接收指令，并通过 chrome.scripting 在当前标签页注入 content script；
3. content script 抓取页面中的可见文本、表格、按钮等结构化数据，返回给 background；
4. background 把这些数据拼进提示词，请求大模型接口；
5. 大模型返回可执行的动作序列，例如“提取第一张表格”“点击下一页”；
6. background 根据动作序列调用 chrome.scripting 或 chrome.tabs 执行页面操作；
7. 页面变化后重复第 3 步，直到目标完成。

这个过程不复杂，难就难在每一步都可能出错：页面结构不规则、权限受限、模型返回格式不稳定、网络超时。工程上要做的就是把每一步做成可观测、可回退的模块。

3.2 权限声明：Manifest V3 的最小配置

Manifest V3 的权限模型是扩展开发的第一个坑。不是所有 API 都能随便调用，必须先在 manifest.json 里声明。

下面是一个最小可用的权限配置：

{ "manifest_version": 3, "name": "chatgpt-browser-agent-demo", "version": "0.1.0", "permissions": ["tabs", "scripting", "storage"], "host_permissions": ["<all_urls>"], "background": { "service_worker": "background.js" }, "action": { "default_popup": "popup.html" }, "content_scripts": [ { "matches": ["<all_urls>"], "js": ["content.js"] } ] }

解释几个关键字段：

• permissions中的tabs用于获取标签页 URL 和标题；scripting用于在页面上注入脚本；storage用来保存扩展配置和临时结果；
• host_permissions声明扩展可以加载到哪些域，<all_urls>最方便，但也会带来安全审查压力；
• content_scripts声明的是自动注入的脚本，但要注意，如果页面是动态渲染内容，需要等 DOM 变化后再抓取；
• background.service_worker是 V3 后台脚本的新写法，替代了旧的background页面。

这里需要特别提醒：<all_urls>权限不是越全越好。如果只是处理特定站点，建议将 host_permissions 缩小到实际域名范围，既符合最小权限原则，也减少商店审核风险。

3.3 页面信息采集与操作执行

接下来是扩展里最容易出问题的地方：怎么读取页面，又怎么执行操作。

读取页面通常使用 chrome.scripting.executeScript。看一个简化的 background 示例：

// background.js（核心片段） chrome.runtime.onMessage.addListener(async (msg, sender, sendResponse) => { if (msg.type === 'EXTRACT_TABLE') { const [tab] = await chrome.tabs.query({ active: true, currentWindow: true }); const results = await chrome.scripting.executeScript({ target: { tabId: tab.id }, func: extractTableData, args: [msg.selector] }); sendResponse({ ok: true, data: results[0]?.result }); } return true; }); function extractTableData(selector) { const table = document.querySelector(selector); if (!table) return []; const rows = table.querySelectorAll('tr'); return Array.from(rows).map(row => { const cells = row.querySelectorAll('th, td'); return Array.from(cells).map(cell => cell.innerText.trim()); }); }

这段代码做了三件事：接收消息、查找活动标签页、注入函数到页面并抓取表格数据。需要注意，executeScript 里的函数会先被序列化，再在目标页面执行，所以它拿不到 background 作用域里的变量，只能通过 args 传递参数。

执行操作也是类似的思路，只是把抓取改成点击或输入。例如：

async function clickBySelector(tabId, selector) { await chrome.scripting.executeScript({ target: { tabId }, func: (sel) => { const el = document.querySelector(sel); if (el) el.click(); }, args: [selector] }); }

这种写法非常适合“AI 决定执行动作，扩展负责动作落地”的架构。模型输出一个 JSON，比如{"action": "click", "selector": "button.next-page"}，扩展解析后调用对应的执行函数。

3.4 AI 决策层：从页面文本到动作指令

AI 不可能直接看到浏览器里面的 DOM 树，它只能接收到文本描述。所以我们需要把页面“翻译”给模型。通常是这样构造上下文的：

当前页面是发票管理后台。 页面主要包含一个表格，字段是：发票号、日期、金额、销售方。 表格前三条数据如下： 1. 发票号 12345678，日期 2025-03-01，金额 899.00，销售方 某科技公司 2. 发票号 12345679，日期 2025-03-02，金额 1200.00，销售方 某服务商 3. 发票号 12345680，日期 2025-03-03，金额 56.50，销售方 某通讯公司 你的任务是提取所有发票，输出 Markdown 表格，并统计总额。

这样的上下文让模型理解起来很轻松。它不需要猜测页面结构，直接把精力放在数据整理和格式输出上。反过来，如果直接把原始 HTML 丢给模型，不仅 token 消耗大，还容易被标签噪声干扰提取结果。

当目标不是“提取单页”，而是“跨多站点操作”时，AI 决策层还会输出操作序列。常见做法是让模型返回带action、target、value的 JSON，扩展循环执行。下面是一段示意代码：

const actions = await queryModel(systemPrompt, pageContext); for (const action of actions) { if (action.type === 'navigate') { await chrome.tabs.create({ url: action.url }); } else if (action.type === 'click') { await clickBySelector(activeTabId, action.selector); } else if (action.type === 'input') { await inputBySelector(activeTabId, action.selector, action.value); } }

这段代码并非完整生产实现，因为真实场景里还要处理标签页切换、页面加载等待、结果校验等，但核心模式就是“模型决策 + 浏览器执行”的循环。

4. 实测一：发票整理

4.1 场景与目标

发票整理是典型的半结构化数据处理任务。平时面对的不外乎两种情况：一种是从发票管理后台复制表格，另一种是从邮箱里的订单邮件中提取信息。手动操作的问题是容易漏行、看错金额、统计出错。用 AI 过一遍，理想状态是：打开页面，说出需求，拿到干净的表格和总额。

我在实测中搭了一个发票后台模拟页面，包含约 30 行发票，字段包括发票号、开票日期、金额、销售方，其中混入了几张重复发票和一条格式异常的数据，用来测试 AI 的纠错能力。

测试前的准备建议是：所有操作在测试环境完成，不要直接在正式报销系统中跑无人值守任务。第一次使用“只读提取 + 人工确认”的模式最稳妥。

4.2 提示词设计

提示词决定了 AI 的行为边界。我的提示词如下：

请从当前页面提取发票信息，要求如下： 1. 只提取发票号、开票日期、金额、销售方四项字段； 2. 去掉重复发票号，保留最新一条； 3. 金额统一为元，保留两位小数； 4. 跳过明显异常的残缺数据，并在结果下方说明跳过原因； 5. 输出为 Markdown 表格，最后一行给出合计金额； 6. 在这个过程中只做数据提取，不修改页面内容，不做删除操作。

这个提示词有几个设计细节：

• 限定字段，防止模型把页面上的其他文本误认为发票信息；
• 明确定义去重规则，避免模型自己发挥；
• 要求说明异常处理原因，既方便校验，也方便审计；
• 强调“只读”，因为发票数据通常涉及财务，任何写操作都有风险；
• 输出固定为 Markdown 表格，便于后续复制到 Excel 或导入其他工具。

4.3 执行过程与结果观察

实际执行时，我给扩展发出了指令。整体流程是这样的：

1. 扩展抓取页面表格，转成文本上下文；
2. AI 识别表格结构，把 30 行数据逐行分类；
3. 发现两条发票号重复，根据规则保留开票日期更新的一条；
4. 发现一行金额为空，标记为“异常数据”，没有强行统计；
5. 输出了包含有效记录和合计金额的表格。

从效果上说，AI 对标准表格的提取准确率很高。只要表格字段稳定，基本不需要人工干预。但我也遇到了一个可能让新手困惑的情况：当页面包含多个表格时，模型会误把其他表格也当作发票来源，导致输出字段混杂。这个问题可以通过在提示词中增加一句“只处理 id 为 invoice-table 的表格”来解决，或者扩展脚本在抓取阶段就限定选择器。

另外要提醒的是，AI 提取的“合计金额”并非真实财务计算，它依赖于模型推理，存在算错的可能。在涉及钱款的场景里，正确的做法是让脚本自己用 Number 累加金额，模型只负责判断字段归属。这样既保留 AI 的语义能力，又用程序保证计算精度。

4.4 这个场景的优劣势

发票整理这类任务，AI 操作网页的优势非常明显：

• 非固定格式页面也能处理，只要表格结构差别不大；
• 能理解“发票号”和“订单编号”这类语义差异；
• 一次性可以输出可读性很高的汇总表，适合人工复核。

劣势也一样存在：

• 高度依赖页面结构，结构变化后需要调整选择器或提示词；
• 涉及财务数据时，必须有复核机制；
• 自动点击、翻页等操作存在执行风险，建议先用只读模式。

5. 实测二：跨网站规划

5.1 场景与目标

第二个场景更有“智能体”的感觉：多站点规划。模拟需求是“规划一次周末出行，需要从票务网站查一班高铁或者机票，再找附近酒店，最后汇总成可行性方案”。

这个任务的难点在于，不同网站的结构差异很大，有的需要输入日期才能触发加载，有的页面是异步渲染，滚动后才出现数据。纯靠一段固定的抓取脚本很难覆盖所有情况，必须让 AI 根据页面反馈动态决策下一步。

我在测试中设定了两个网站：一个票务比价站，一个酒店预订站。要求 AI 分别完成搜索、提取价格和时间、记录酒店距离与评分，最后输出一个对比表。

5.2 提示词设计

跨网站规划的提示词要比发票场景更强调操作限制：

你现在是一个网页操作助手，需要完成跨网站规划任务： 1. 在票务网站搜索指定日期、出发地到目的地的车次或航班； 2. 提取候选方案的时间、价格、到达时间； 3. 在酒店网站搜索目的地附近的酒店，提取价格、评分、到市中心的距离； 4. 把结果整理成对比表，按总性价比推荐 3 组组合； 5. 在操作过程中： - 不做任何支付、下单操作； - 遇到需要登录的页面，直接暂停并说明； - 遇到验证码等安全拦截，不要尝试绕过，直接报告； - 每一步操作前先说明准备做什么。

这个提示词把安全边界写得很清楚：不支付、不绕过安全验证、碰到异常就停止。这种“可回退”的设计在真实使用中非常重要，因为 AI 自动操作一旦失控，代价会很大。

5.3 执行过程与结果观察

执行时智能体按下面的路径走：

1. 在票务网站输入日期和线路；
2. 搜索结果渲染后，尝试提取车次列表；
3. 发现页面有异步加载延迟，第一次抓取结果为空，于是等待后重新抓取；
4. 将票务结果保存为临时结构；
5. 切换到酒店网站，重复搜索动作；
6. 把两个站点的信息按目的地关联，生成对比表。

这次测试中有一个细节非常有意思：AI 在票务网站第一次没抓到数据时，它没有直接报错，而是选择刷新页面或重新读取，这种自动重试行为像是“理解”了页面异步渲染的逻辑。但与此同时，它也出现了判断不准确的情况，比如把筛选按钮和搜索按钮混淆，导致重复提交了两次搜索。这种情况下，人工介入的成本并不低。

最终输出结果基本符合预期，只是数据完整度和格式还需要调优。更重要的是，这个实测说明 AI 已经具备“跨站操作 + 信息整合”的基础能力，但没有工程兜底的情况下，不能完全放权。

5.4 这个场景的优劣势

跨网站规划场景的优点在于：

• 信息聚合能力强，能在几分钟内完成人工半小时的对比工作量；
• 能根据用户意图调整条件，语义理解比固定脚本强很多；
• 具备一定容错能力，遇到空数据会自动重试。

缺点是：

• 操作链路越长，越容易出错，特别是页面内部按钮定位不稳定；
• 多个标签页之间切换时，AI 容易丢失当前上下文；
• 对登录态、安全拦截的处理能力还比较初级；
• 真正的“规划”能力更多依赖模型本身的推理，而不是页面知识，因此信息时效性需要人工核验。

6. 常见问题与排查思路

实测过程中最耗时间的不是“AI 不会做”，而是“AI 做一半卡住”。下面把常见问题、原因和解决思路整理成表，也给自建扩展的读者参考。

排查时建议按这个顺序走：先看扩展权限，再看页面加载时机，然后看模型返回，最后看执行动作。大多数问题出在前半段，尤其是页面元素抓取阶段。

7. 最佳实践与工程建议

7.1 最小权限与安全边界

浏览器自动操作天然涉及账号与隐私，安全边界从一开始就要定好。自建扩展时，尽量将 host_permissions 限制在具体域名；在提示词里明确禁止支付、删除、修改密码等高风险动作；所有写操作必须经过使用者确认。

更重要的一条原则：不要在正式环境里做无人值守自动化，尤其是在财务、账号管理等敏感场景。哪怕 AI 的准确率是 99%，剩下 1% 的错误也可能造成比手动操作更大的损失。推荐采用“AI 准备动作 → 人工确认 → 脚本执行”的半自动模式。

7.2 页面结构变化的应对

页面结构调整是这类自动化项目最头疼的维护问题。一种可行的做法是把页面解析规则从代码中抽出来，配置化。比如把表格的 selector、字段映射放在独立的配置文件中，页面改版时只改配置，不碰主逻辑。同时在抓取结果中记录页面结构指纹，一旦指纹变化就触发告警，提示运维人员检查。

7.3 日志与追踪

AI 操作网页的调试依赖完整日志。建议每次操作记录以下信息：

• 当前标签页 URL；
• 操作类型和参数；
• 页面抓取结果摘要；
• 模型返回内容；
• 执行结果；
• 耗时和 token 消耗。

这些日志不仅用于排错，也能帮助分析模型在哪些步骤上容易偏离预期，为后续优化提示词提供数据支撑。

7.4 输出校验与结果复核

对结果一定要做程序层面校验。发票场景中，金额合计用脚本计算；跨网站规划中，推荐结果的选项日期和价格要跟原始页面比对。模型输出的格式问题可以用 JSON Schema 或正则校验，无法通过校验的数据直接标记为“待人工处理”，而不是强行修正。

7.5 关于接口调用的成本控制

API 调用成本容易被忽视。抓取一个大型页面并转成上下文时，token 消耗可能非常大。建议在发送给模型前做数据裁剪，只保留表格关键字段和可见文本，把样式、脚本、广告全部过滤掉。另外增加全局 Token 上限，防止任务死循环导致消耗失控。

8. 总结与后续学习路线

回到这次实测的核心结论：让 AI 接手网页操作已经不是停留在演示阶段，发票整理和跨网站规划这两个真实场景都能跑通，但它更像是“一个需要人类监督的实习生”，而不是“一个可以完全放手的高级员工”。

如果你是从使用者的角度出发，下一步可以重点学习提示词工程，尤其是“操作安全边界”和“输出格式约束”的写法。这两个能力能直接把 AI 工具的可用性提升一大截。

如果你是开发者，建议按这个路线深入：Chrome 扩展开发基础（Manifest V3、content script、scripting API）→ 大模型接口调用与工具调用（function calling）→ 浏览器自动化运维（页面结构变化监控、错误恢复、日志审计）。每一步都有对应的官方文档和开源项目可以参考，关键是先把最小链路跑通，再逐步增加容错机制。

最后给一个马上就能实践的建议：下次再做浏览器里重复性任务时，不要急着写完整自动化脚本，先试着用一个带操作能力的 AI 扩展完成一次“只读信息整理”，看它在真实页面上能走多远。这个过程会帮你快速理解哪些步骤模型擅长、哪些步骤必须人工把关，也更容易建立对 AI 智能体的准确预期。