浏览器扩展开发：用途、权限与上架

浏览器扩展是直接运行在 Chrome、Edge、Firefox 或 Safari 中的小程序：它可以添加按钮、读取页面上需要的数据、自动填写表单，或把员工正在打开的网站与您的 CRM 和服务连接起来。只有一个场景的简单扩展通常需要一到两周开发，另需几天用于扩展商店审核。

扩展能解决哪些任务

当工作本来就在浏览器中进行、而网站上缺少需要的操作时，扩展就很有用。员工或客户无需另装应用，直接在当前页面点一下按钮即可。

• 数据采集：商品卡片、联系人或信息一键保存到 CRM 或表格，无需手动复制。
• 页面提示：在相应字段旁显示来自您系统的状态、价格或客户历史。
• 表单填写：后台和管理面板中重复的字段由您的数据自动填写。
• 对接 AI 智能体：选中的文字或当前页面发送给智能体，答案返回到侧边栏——详见《企业 AI 智能体》。
• 面向客户的产品：独立的扩展产品，或作为您网页服务的配套工具。

如果任务不止页面上的一个操作，网页服务或 Telegram 机器人可能更合适。我们会在分析任务时一起判断：有时扩展是最短路径，有时则是多余的一层。

现代扩展的结构

Chrome、Edge 等基于 Chromium 的浏览器接受 Manifest V3 格式的扩展；Firefox 支持同一格式，仅有少量差异；Safari 则需通过 Xcode 将扩展打包为应用。因此一套代码通常可以覆盖四种浏览器，差异由少量构建配置处理。

• 后台 service worker 处理事件并与您的服务器通信。
• 内容脚本只在指定网站上读取和修改需要的内容。
• 弹出窗口或侧边栏是扩展的界面。
• 设置页面负责登录、模式和语言选择。

Manifest V3 禁止远程代码：扩展的全部逻辑随扩展一起通过商店审核，数据和规则则来自您的服务器。

权限与安全

对用户和商店审核来说，最关键的问题是扩展请求哪些权限。访问范围越广（例如访问所有网站），审核越严格，用户安装时也越谨慎。

• 只请求扩展实际工作的网站的访问权限。
• 不在扩展中保存密码和密钥——登录通过您的服务器完成。
• 在隐私政策中说明收集哪些数据以及用途。
• 在服务器端校验每个输入字段，不直接信任页面数据。

我们在自己的产品中也遵循这些规则：安全是每次修改的要求，而不是交付前的单独阶段。

在扩展商店上架

扩展可发布到 Chrome Web Store、Microsoft Edge Add-ons、Firefox Add-ons 以及 App Store（Safari）。每个商店都需要说明、截图、图标、隐私政策，并解释每项所请求的权限。审核通常需要几小时到几天，权限较广时会更久。

公司内部工具不必公开发布：可以通过私有链接或公司的浏览器管理来安装。

工期与费用

只有一个场景的扩展——按钮、读取页面并发送到您的服务——通常需要一到两周。对接多个系统、账号登录、带 AI 智能体的侧边栏以及 Safari 支持都会延长工期。我们在分析任务后给出准确评估，评估的构成详见《软件开发费用》。

最好先为一个浏览器实现一个场景，其余在后续版本中添加：这样价值更早出现，决策也能在真实用户身上验证。详见《MVP 开发》。

扩展、Web 服务还是机器人：如何选择

扩展并不是为日常工作补上缺失操作的唯一方式。Web 服务和即时通讯机器人也能解决类似的任务，选择取决于用户需要帮助的那一刻身在何处。

很多时候正确答案是组合使用：Web 服务保存数据和规则，扩展在需要的页面上提供按钮，机器人负责发送通知。Web 部分详见Web 应用开发页面，机器人详见企业 Telegram 机器人一文。

扩展开发的阶段

工作按短周期推进，每一步结束时都有可以亲手验证的成果。

1. 需求梳理。确定一个核心场景：扩展在哪些网站上工作、读取什么、发送到哪里、用户看到什么。同时决定真正需要哪些权限。
2. 原型。在一个网站和一个浏览器中做出可用的按钮或侧边栏，确认页面数据能够稳定读取。
3. 服务端。配置账号登录、数据接收、字段校验，以及写入 CRM、表格或其他系统。
4. 界面与文案。弹出窗口、设置页、清晰的错误提示以及界面语言。
5. 测试。在真实页面、不同浏览器版本和慢速网络下测试，并单独检查网站改版后扩展的表现。
6. 发布。准备说明、截图、隐私政策和权限说明，提交商店审核，或通过私有链接分发。

每个阶段验收时需要检查什么，详见如何验收软件项目一文。

发布后的更新

扩展运行在别人的页面上，因此它能否正常工作并不只取决于您的代码。扩展读取数据的网站可能改版，浏览器可能调整扩展规则，商店也可能更新对说明和权限的要求。

• 页面读取规则（例如要找哪些字段、在哪里找）最好作为数据保存在服务器上：网站改版时，部分修复无需重新经过商店审核即可上线。
• 扩展的错误应收集到服务器日志中——不含个人数据，但记录扩展版本、浏览器版本和页面地址。
• 每次更新都要重新经过商店审核，因此较大的改动适合合并到计划版本中发布，紧急修复则单独发布。
• 浏览器会自动更新，因此应提前在新版本上检查扩展，而不是等用户投诉之后再处理。

我们从一开始就把上线后的维护纳入计划：浏览器更新后的快速检查和根据错误日志进行的修复，成本远低于紧急抢修。

常见错误

扩展的大多数问题并非出在代码上，而是出在项目起步时做出的决定上。

• “以防万一”申请过宽的权限。访问所有网站的权限会让商店审核更难通过，也会让用户在安装时望而却步。
• 把密钥和密码放在扩展里。扩展代码可以被打开和读取，因此所有机密信息只能保存在服务器上。
• 逻辑依赖偶然的页面结构。如果扩展按自动生成的类名查找按钮，网站第一次更新时它就会失效。
• 一开始就同时支持四个浏览器、十项功能。第一个版本上线更晚，而核心场景的价值始终没有得到验证。
• 没有隐私政策。如果没有清楚说明收集哪些数据以及用途，商店会拒绝上架扩展。
• 没有更新计划。缺乏维护的扩展会悄无声息地失效，而您是从用户那里才得知这一点。

我们的工作方式

我们在软件定制开发服务中开发浏览器扩展：先梳理需求，确定第一个版本的工期和范围，再分短阶段交付。代码、扩展商店账号和服务端都归客户所有。

我们依托的经验来自自有产品 Wallet、Legal 和内容工厂：服务端、账号登录、AI 功能、在应用商店上架以及上线后的维护。同样的原则——最小权限、密钥只放在服务器、错误日志和计划版本——我们也用在扩展上。

如果扩展是更大产品的一部分，例如 Web 服务或 AI 智能体的配套工具，我们会把所有部分放在一起讨论：这样更容易避免逻辑重复，并把数据集中在一处。