企业官网建设流程全解析

浏览器里的 AI 助手，过去三年基本停在“聊天框”里。遇到“帮我把这些发票信息整理成表格”这种需求，它只能甩给你一段通用模板；遇到“帮我规划三天差旅”，它给的建议往往落不到具体的航班和酒店。但近一年，ChatGPT 的浏览器扩展形态正在改变这件事的走向：AI 不再只是“读”网页并回答，而是可以“接管”网页，完成点击、填写、跨站收集信息这一类连续操作。

这篇文章用偏实操的视角来拆解这个方向：先说清楚 AI 凭什么能操作浏览器（原理部分），然后针对“发票整理”和“跨网站规划”两个典型场景，给出可执行的任务设计、Prompt 模板和验证方法，最后补上常见坑和工程建议。读完你会得到一个明确判断：ChatGPT Chrome 扩展适合把你的哪些工作自动化，哪些环节仍然必须由人来兜底。

先给出核心判断：这类扩展真正改变的不是“模型能力”，而是“模型与浏览器的交互边界”。发票识别、规划生成，大模型早就做得到；真正的难点在于让模型可靠地读到网页结构、稳定地执行页面动作，并在出错时不产生破坏性后果。所以这篇文章不吹“全自动”，而是重点讲“怎么设计任务才能让它跑得更稳”。

1. 这类扩展解决了什么问题：从“能聊天”到“会干活”

先说一个具体场景。一家中小公司的行政人员，每个月要处理几十张电子发票：把发票代码、金额、购买方、销售方逐个录入 Excel，再按月份归档。这个过程看起来简单，但长时间重复之后非常消耗精力。又比如一个运营在做竞品调研，需要同时打开十几个网站，比较价格、参数、用户评价，最后整理成一份对比文档。这两类工作有一个共性：大部分时间花在页面跳转、复制粘贴和人工对齐格式上，而不是花在思考上。

ChatGPT Chrome 扩展的价值，就是把这些“低价值、高重复”的网页操作，从人手里转移到模型手里。它不是在聊天侧边栏里多说几句话，而是获得了一个可以读取页面、执行操作、返回结果的行为入口。具体来说，它可以做三件事：

1. 读取当前页面的正文、表格和关键字段；
2. 根据指令对信息进行提取、清洗和格式化；
3. 在页面权限允许的范围内执行点击、输入、切换标签等操作。

从目前的公开资料和常见使用反馈来看，这个方向真正适合的人群主要有三类。第一类是财务、行政、运营等有批量网页信息整理需求的人，发票录入、报表汇总、资料归档都是典型任务。第二类是需要在多个网站之间对比信息、做决策规划的人，比如差旅安排、设备采购、课程选择。第三类是开发者，他们不只是使用现成扩展，更想理解机制，把这类能力接进自己的自动化脚本里。

这里有一个容易误判的点：很多人以为“AI 接手网页操作”意味着完全无人值守。实际上，目前更接近的做法是“人制定目标、AI 执行初稿、人做最终确认”。发票整理可以让 AI 完成字段提取，但最后财务复核和提交依然要人来做；跨网站规划可以让 AI 收集航班、酒店和攻略信息，但最终下单通常还是要登录原网站确认。理解了“人机协同”这个边界，你才不会在使用时产生不切实际的预期。

2. 核心原理：AI 是怎么“看”网页、理解网页、操作网页的

要搞清楚这类扩展能不能用在你的任务里，先要理解它内部的三层结构：读取层、理解层、操作层。这三个环节任何一个出问题，整个流程都会失败。

2.1 读取层：DOM、截图与无障碍树

浏览器扩展想要“读取”网页，并不是像人一样用眼睛看，而是通过技术手段把网页内容变成模型能消费的数据。常见方式有三种。

第一种是抓取 DOM 文本。浏览器扩展的 content script 可以访问当前页面的 DOM 结构，把document.body.innerText、表格节点、输入框占位符等内容提取出来，转成纯文本或结构化 JSON 后发给模型。这种方式对静态页面和结构清晰的表格非常有效，但遇到大量 JavaScript 动态渲染的内容时，可能需要等待页面加载完成才能拿到完整数据。

第二种是整页截图加视觉模型。把当前页面的可视区域截成一张图片，交给支持视觉理解的多模态模型（例如 OpenAI 的 GPT-4o 系列）去识别。这种方式更接近人“看到什么理解什么”，很适合处理图多、排版复杂的页面。缺点是对网络带宽和模型上下文消耗更大，而且截图里如果包含无关广告，会影响识别精度。

第三种是借助无障碍树。Chrome 的 Accessibility Tree 里包含了对按钮、链接、表单控件的结构化描述，比直接读渲染后的文本更干净，也更适合辅助大模型理解“这个页面有哪些可操作元素”。实际实现中，很多成熟的浏览器 Agent 方案都会优先取无障碍树，因为它的信息质量比 DOM 文本更适合大模型。

2.2 理解层：Prompt 与结构化输出

读取到网页内容之后，第二步是让大模型生成用户想要的结果。这里的关键不是模型能不能“看懂”，而是你有没有把任务描述清楚。最稳妥的做法是一开始就要求模型输出结构化内容，而不是自由文本。

以发票整理为例，你可以在 Prompt 里明确要求：“请从以下页面文本中提取发票号码、开票日期、购买方名称、销售方名称、价税合计金额，并输出 JSON 格式。”这种约束极大降低了后续解析的难度。至于发票 OCR 识别、多字段对齐、大小写金额转换，这些能力都是大模型通过训练获得的通用技能，Prompt 里给出清晰的字段定义和示例即可。

这一步的常见误区是 Prompt 写得像聊天：“帮我整理一下这个页面。”模型拿到这种指令，输出的格式千奇百怪。正确的做法是：字段名、输出格式、边界情况、示例都写在指令里。AI 操作网页类的任务，本质上是一个“结构化函数调用”，而不是闲聊。

2.3 操作层：脚本注入与 DevTools Protocol

理解完内容之后，“操作网页”这一步最复杂，也是最容易失败的地方。浏览器扩展有两类常见手段来执行操作。

第一类是在页面里注入脚本。扩展的 content script 可以直接操作 DOM，比如通过document.querySelector('button').click()触发点击，或者给输入框赋值并派发事件。这个方法轻量，但依赖页面结构稳定，一旦按钮的 class 或 id 变化，脚本就会失效。

第二类是通过 Chrome DevTools Protocol（CDP）模拟真实用户操作。CDP 可以控制浏览器的调试端口，模拟鼠标移动、点击、键盘输入、滚动等行为，粒度比 DOM 操作更接近真人。很多 Python 自动化框架（如 Playwright、Puppeteer）都是基于类似的协议实现的。扩展形态里，通常由扩展的后台脚本发出指令，再通过chrome.scripting或调试通道执行。

理解操作层的关键结论是：AI 能“看到”不需要它能点击。登录墙、验证码、弹窗、需要悬停才出现的菜单，都是操作层的拦路虎。因此，在选场景时，优先选那些“页面结构稳定、操作路径短、无强验证”的网站。

3. 环境准备：三条路线从零跑通

如果你是一个开发者也想尝试，可以从三条路线中选一条。前两条适合普通用户快速体验，第三条适合需要批量处理或集成到业务系统的人。

3.1 路线 A：直接安装现成扩展

最省事的方式，是从 Chrome 网上应用店搜索 ChatGPT 相关的浏览器扩展，安装后在插件弹窗里登录你的账号。不同扩展的功能差异较大，有的偏向“选中文本后唤起 AI”，有的支持“读取整个页面并回答”，有的则能在页面内直接执行预设动作。选择时可以重点关注三个能力：是否支持整页内容读取、是否支持自定义 Prompt 模板、是否能返回结构化输出。请确保本地网络环境能正常访问对应服务，并遵守相关法律法规与平台使用条款。

需要说明的是，这类扩展的更新速度非常快，官方与第三方功能边界经常变化。本文不过度依赖某个具体扩展的品牌功能，而是把重点放在通用实现方法和验收思路上，这样即使你换一个扩展，判断标准依然适用。

3.2 路线 B：本地加载一个自定义扩展

如果你想让某个任务真正贴合自己的工作流，自己写一个最小 Chrome 扩展会更可控。下面是一个最基础的 manifest 示例，仅申请当前标签页读取权限，并注册一个 content script。

{ "manifest_version": 3, "name": "ChatGPT Page Assistant Demo", "version": "1.0.0", "description": "演示读取当前页面文本并交给 ChatGPT 整理", "permissions": ["activeTab", "scripting"], "host_permissions": ["<all_urls>"], "action": { "default_title": "读取页面" }, "background": { "service_worker": "background.js" } }

// 文件路径：content.js // 这个脚本注入到当前页面，负责把页面文本提取成可用于分析的结构。 (function () { const data = { title: document.title, url: location.href, text: document.body.innerText.slice(0, 20000) }; return data; })();

在 Chrome 的扩展管理页面打开“开发者模式”，点击“加载已解压的扩展程序”，选择一个包含manifest.json的目录，就能把这个扩展暂时加载到浏览器。这种自建方式的优势是权限边界完全由你控制，不会有多余的数据收集。

3.3 路线 C：用 Python 加 API 做后端自动化

如果你不需要浏览器插件形态，而是想在自己电脑或服务器上跑批量任务，Python + Playwright 是一个更实用的组合。Playwright 负责控制浏览器打开页面，OpenAI 的 SDK 负责把页面文本转换为结构化数据。下面给一个最简骨架。

pip install playwright openai playwright install chromium

# 文件路径：invoice_extract_demo.py # 功能：打开本地保存的发票页面文本，调用模型提取字段。 # 注意：此脚本只处理静态 HTML 文件，不涉及登录态和验证码。 import json from openai import OpenAI client = OpenAI() # 通过环境变量 OPENAI_API_KEY 读取密钥 def extract_invoice(html_path: str) -> dict: with open(html_path, "r", encoding="utf-8") as f: page_text = f.read() prompt = """ 你是一个发票信息提取助手。请从下面的网页文本中提取： 发票号码、开票日期、购买方名称、销售方名称、价税合计金额。 按照 JSON 格式输出，字段名为： invoice_no, invoice_date, buyer_name, seller_name, total_amount。 如果某个字段不存在，填写空字符串。 """ response = client.chat.completions.create( model="gpt-4o-mini", # 具体模型请以实际可用为准 messages=[ {"role": "system", "content": "你是一个严谨的信息提取工具，只输出 JSON。"}, {"role": "user", "content": prompt + "\n\n页面内容如下：\n" + page_text} ], temperature=0 ) return json.loads(response.choices[0].message.content) if __name__ == "__main__": result = extract_invoice("sample_invoice.html") print(result)

这段代码没有直接展示浏览器操作，但它把“模型提取信息”的流程跑通，后续如果配合 Playwright 的page.goto()、page.click()逐页遍历，就能构建批量发票整理工具。

4. 场景一：发票整理的实现路径

4.1 先定义要提取的字段

发票整理看起来简单，真正做起来容易混乱。原因在于一张发票上有非常多字段：发票代码、发票号码、校验码、开票日期、购买方信息、销售方信息、货物或应税劳务名称、金额、税率、税额、价税合计，还有备注。如果 Prompt 不明确，模型很可能把“发票号码”和“校验码”搞混，或者把含税金额和不含税金额混为一谈。

所以，第一步是把字段表写死。根据团队或财务的实际要求，挑出必填字段。例如：发票号码、开票日期、购买方名称、销售方名称、价税合计金额、税额。字段越少，准确率越高。不要贪心一次提取十几个字段，尤其是那些页面本身没有明确展示的字段。

4.2 Prompt 模板与结构化输出

给模型设计 Prompt 时，推荐“角色 + 任务 + 字段定义 + 输出约束 + 页面内容”的结构。下面是一个可直接复制的模板。

你是一个网页发票信息提取助手。用户会提供一张发票页面的文本。 请提取以下字段： - invoice_no：发票号码 - invoice_date：开票日期 - buyer_name：购买方名称 - seller_name：销售方名称 - total_amount：价税合计金额（大写转为小写数字） 要求： 1. 只输出一个 JSON 对象，不要输出任何解释文字。 2. 如果字段缺失，填空字符串，不要猜测。 3. 金额必须保留两位小数。 4. 如果页面文本包含多张发票，只提取当前页面的第一张。 页面内容：

把这段 Prompt 和document.body.innerText拼在一起，发给模型。收到结果后，用JSON.parse校验，然后打印或写入 Excel。

4.3 批量与校验思路

如果只是在某个网页上整理几张发票，手动执行 Prompt 就够了。但如果是批量任务，比如一个文件夹里有几十个发票页面，建议走第 3.3 节提到的“Playwright + API”方案，或者参考以下简化流程：

1. 用脚本打开发票列表页，收集每一张发票的详情链接；
2. 逐个进入详情页，提取页面文本；
3. 调用模型生成结构化 JSON；
4. 对 JSON 做二次校验，检查必填字段是否为空、金额是否符合基本格式；
5. 经过校验的数据写入 CSV 或数据库。

这里要特别强调校验。模型偶尔会把“购买方”和“销售方”对调，这是最危险的错误，因为对调之后发票入库就没有任何意义。建议在展示结果时同时把原页面的标题、关键字段所在片段返回，让人工或规则逻辑对照检查。发票整理场景的小结论是：AI 负责把非结构化文本变成结构化数据，但准确性验证仍然是任务设计里不可省略的一环。

5. 场景二：跨网站规划的实现路径

5.1 为什么这个场景最能体现“接管”价值

发票整理是“单页提取”，跨网站规划则是“多页联动”，难度和代表性都完全不同。假设你要规划一次三天两夜的商务差旅，需要在出行网站查机票、在酒店平台比较住宿、在地图网站确认会议地点周边交通、在美食或攻略网站找就餐方案。每一项都有独立网站、独立账户和独立交互。这时候 AI 的价值不只是“识别字段”，而是“记住上一个网站的结果，带着上下文到下一个网站继续比对”。

这也是“AI 接手网页操作”这个标题中最吸引人的部分。但注意，跨网站规划也是最容易出现“做一半就没下文”的场景。

5.2 实现流程拆解

一次比较稳健的跨网站规划任务，建议按下面五步设计：

1. 确定信息清单：出发日期、到达城市、预算上限、会议地点、偏好条件，写成结构化参数。
2. 逐站完成子任务：让 AI 先打开航班查询网站，提取符合条件的航班和价格；再打开酒店网站，提取评分和价格。
3. 统一数据格式：每访问一个页面，让模型输出统一字段，比如“来源网站、项目名称、关键参数、价格、备注”，这样后续汇总不会乱。
4. 生成对比与草案：拿到各站结果后，让模型生成一个 Markdown 文档，包含航班候选、酒店候选、行程计划、预算估算。
5. 人工确认关键动作：价格以原页面实时显示为准，预订操作建议由人完成，避免模型误点或提交错误信息。

这种设计背后的原因是：跨站任务里最大的变数不是模型理解，而是网站登录态、页面跳转和实时价格更新。所以要让模型做“信息收集 + 比较 + 草案生成”，而不是直接替人决策付款。

5.3 Prompt 模板与汇总结构

下面这个 Prompt 适用于“让 AI 汇总多个网站信息”的最后一步。假设它已经拿到了航班和酒店的结构化数据，你可以让它生成规划文档。

你是差旅规划助手。你现在拿到了以下站点的查询结果： 航班信息：{flight_info} 酒店信息：{hotel_info} 当地交通和餐饮信息：{local_info} 请根据这些信息生成一份差旅规划草案，要求： 1. 包含行程时间线：第1天、第2天、第3天。 2. 每个时间段标注交通方式、酒店、餐饮建议。 3. 给出预算估算，用表格展示。 4. 对每个候选方案给出“优点”和“风险”。 5. 最后用一段话说明还需要人工确认哪些信息。 输出格式：Markdown。

这个任务的输出不是最终方案，而是一份“待人工确认”的草案。你要做的是拿走草案，去原网站核对价格和剩余库存，再决定是否下单。跨网站规划场景的小结论是：AI 适合做信息收集与比较的第一轮，适合做需要登录、支付和账户操作的最后一公里。

6. 实测验证：如何科学判断“能不能用”

标题里的“实测”，很多人误以为是看一个演示视频就下结论。更科学的做法是自己在目标网站上跑一份验收清单。下面给出六个观测指标，建议至少在 20 条样本上验证，不要拿一两次成功就匆忙上线。

从公开反馈来看，影响成功率的关键变量有三个。第一个是登录与验证码。只要任务涉及登录墙或人机验证，成功率会明显下降，因为验证码本身就是为了区分人和机器而设计的。第二个是页面的动态加载机制。无限滚动、按需加载的页面，如果脚本没有等到底部数据渲染完就提取，内容必然不完整。第三个是上下文长度。跨网站规划会累积大量文本，如果模型上下文窗口不够，早期信息会被“忘记”，导致后续汇总缺项。

如果你准备验证，可以从一个低风险任务开始：先不做跨网站规划，而是先拿三五个公开的商品详情页或发票页面做字段提取。把成功率稳定在 95% 以上，再逐步增加操作和跳转。这样能避免一开始就陷入“AI 操作网页失败”的挫败感。

7. 常见问题与排查思路

这里想特别提醒一个问题：如果你遇到“AI 能读页但不能点击”，大概率不是模型笨，而是页面结构变化导致选择器失效。此时优先检查页面的 DOM 在点击目标前后是否发生了重新渲染，因为很多现代前端框架会在状态变化后重建节点。

8. 最佳实践与工程建议

基于这类“AI + 浏览器扩展”任务的工作特点，有六条工程经验值得沉淀下来。

第一，权限最小化。扩展的permissions只申请需要的权限，不要为了省事把host_permissions设成<all_urls>。如果只在发票网站用，就限定该网站的域名。权限越小，数据泄露面越小，未来上架审核也更容易通过。

第二，密钥永远不要写在扩展前端里。调用 OpenAI API 时，如果你是自建扩展，建议把 API 请求发到自己的服务端，由服务端持有密钥并做鉴权。Chrome 扩展的代码在用户浏览器里是可见的，把密钥写进去等于把账密贴在大门上。

第三，所有 AI 输出都要经过结构化校验。模型返回的 JSON 不一定合法，金额可能为负数，日期可能不符合格式。写一个validate()函数，对必填字段、类型、范围做二次确认，校验不通过就不入库。

第四，敏感页面不要整页截图发送。电子发票、订单详情、企业合同都属于敏感信息，如果必须上传页面内容，尽量先剥离无关区块，只提取必要字段。能走 DOM 文本提取，就不要用截图，减少隐私风险。

第五，人工兜底设计要明确。涉及付款、取消订单、删除数据等危险操作，流程设计上应当默认“AI 不自动执行”，而是生成一个人工确认步骤。必要的话，在扩展里加一个“操作预览”面板，让用户看到 AI 即将执行的每一步。

第六，关注模型协议与浏览器自动化生态的发展。例如 MCP（Model Context Protocol）这类标准化接口，正在试图把模型调外部工具的协议统一起来。虽然现在还处在早期，但值得保持关注，因为它很可能直接影响未来“浏览器 Agent”的实现方式。

9. 总结与下一步实践

把 AI 塞进浏览器扩展，让模型读取网页、提取信息、跨站规划，这套玩法最核心的收益是释放了大量重复劳动。但从落地效果来看，它仍然是一个“任务设计为王”的方向：页面结构稳定、字段定义清楚、校验逻辑完整，成功率就高；任务模糊、页面复杂、缺少人工兜底，就会频繁失败。

如果你想动手实践，我建议按下面的路径推进。第一步，在当前浏览器里安装一个能读取整页内容的 ChatGPT 扩展，拿三张发票页面测试字段提取。第二步，把提取结果和原页面做对照，找出模型容易错的地方。第三步，尝试一个小范围的跨网站规划任务，先手动帮它登录一次，观察它是否能把上下文带到下一个网站。第四步，确认基本流程可用后，再考虑自建扩展或用 Playwright 写批量脚本，把成功率、耗时、异常三个指标纳入日常验收。

最终要记住的是：这类工具的价值不完全取决于大模型本身，而取决于你对任务的拆解和对错误的容忍度。把目标定在“AI 辅助完成 80% 的工作，人来接管 20% 的决策与校验”，你会比追求“100% 全自动”的人更快看到实际效果。