用 AI 做 Chrome 扩展：浏览器插件实战指南

最后更新 2026-06-25

你将学到

搞清楚浏览器插件的四个核心文件各自干什么，不再被"不知道从哪下手"卡住
学会用 AI 工具从零搭一个真实能跑的小插件，含完整的对 AI 提需求示例
掌握本地加载、调试、打包、发布到 Chrome 商店的完整流程
知道插件开发最容易踩的坑（manifest 版本/权限/注入时机/跨域），以及低成本变现思路

你有没有遇到过这种情况：某个网站每次打开都要手动点几步才到你想去的地方，或者某个页面的信息你需要复制整理后才能用，但就是没有任何工具帮你做这件事。

做一个 Chrome 插件，三个文件，一个下午，这件事就解决了。

浏览器插件是独立开发者练手变现的小甜区——比做 SaaS 轻，比做 App 门槛低，能直接改造你每天用的任何网页，Chrome 商店的上架门槛也比 App Store 友好得多。这篇把插件开发的完整流程拆开说，从结构到调试到发布，每步给真实的"怎么跟 AI 说"示例。

浏览器插件能干什么，为什么适合练手变现

先说几个实际可以做的东西，帮你建立直觉：

信息提取：一键把当前页面的标题、正文、链接整理成 Markdown 复制到剪贴板
页面改造：把某个你嫌弃的网站的字体换大、把广告区域折叠掉
自动化：打开特定网站后自动填表、自动点击某个按钮
效率工具：在任意网页上唤出一个小浮层，快速记笔记或查词

这些东西有人愿意为它付钱。Chrome 商店里不少装机量 10 万以上的插件，功能其实就是这种程度的"小改造"。变现路径也很清晰：免费基础功能 + 付费高级功能（订阅），或者直接一次性买断，开发者自己跑个 Stripe 收款就行。

和 SaaS 相比，插件的好处是不需要服务器，逻辑跑在用户浏览器本地，前期成本几乎为零。从零做 SaaS 的完整路径那篇要维护一套后端，而做插件的最小版本只是几个 JS 文件。

插件的基本结构：四个核心部分各干什么

搞清楚结构是第一步。一个 Chrome 扩展，最核心的是这四个东西：

my-extension/
├── manifest.json        ← 插件的"身份证"，告诉浏览器这个插件是什么
├── content_script.js    ← 直接在网页里跑的代码，能读写页面 DOM
├── background.js        ← 后台常驻进程，处理事件、跨标签通信
└── popup/
    ├── popup.html       ← 点击插件图标弹出的小窗口
    └── popup.js         ← 控制弹窗的逻辑

逐一说清楚：

manifest.json：整个插件的配置文件，没有它什么都跑不了。它声明插件叫什么名字、需要哪些权限、哪个 JS 在什么时候跑。目前主流版本是 Manifest V3（MV3），Chrome 商店已经不接受 MV2 的新扩展，这个版本不能搞错。

content_script.js：这段代码会被注入到你指定的网页里，和那个网页共享 DOM，可以直接用 document.querySelector 读元素、修改页面。它是插件和网页"对话"的主要手段。但注意：content script 访问不了 Chrome 扩展 API 的大部分功能（比如 chrome.storage），也访问不了后台服务的网络请求，需要通过消息传递和 background 通信。

background.js（Service Worker）：MV3 里 background 是一个 Service Worker，不是持久化运行的进程，它响应事件（比如标签页更新、消息收到），做完事就休眠。全局状态不要存在 background 的变量里——重启就丢了，用 chrome.storage 持久化。

popup：用户点图标弹出的界面，就是普通 HTML+JS，体积小、功能简单。它和 content script 之间通信也要走消息机制。

四者的关系：

用户点击插件图标
    → popup.js 显示界面，用户触发操作
        → popup.js 发消息给 content_script
            → content_script 操作页面 DOM
        → 或者 popup.js 发消息给 background
            → background 处理后返回结果

用 AI 搭一个真实小插件

目标：做一个"一键提取网页信息"的插件——用户点图标，弹窗显示当前页面的标题和 URL，再点一下复制成 Markdown 格式（[标题](URL)）。

功能虽小，但结构完整：有 manifest、有 popup、有 content script 通信、有剪贴板操作。搭通这个，其他功能往上加就顺了。

用 Cursor 或 Claude Code 开一个空目录来做。

第一步：让 AI 生成基础结构

真实提法示例：

帮我做一个 Chrome 扩展，功能是"一键提取网页信息"：

1. 用户点击插件图标，弹出一个小窗口
2. 窗口里显示当前标签页的标题和 URL
3. 有一个"复制 Markdown"按钮，点击后把 [标题](URL) 格式的文本写入剪贴板
4. 复制成功后按钮文字变成"已复制 ✓"，2 秒后还原

用 Manifest V3，文件结构要有：
- manifest.json（需要 activeTab 权限和 clipboardWrite 权限）
- popup/popup.html
- popup/popup.js
- 不需要 content script（从 popup 直接用 chrome.tabs.query 获取当前标签信息就够了）

不要加 TypeScript，不要加构建工具，直接写原生 JS，能在 Chrome 扩展里跑通就行。

几个说明：

这个功能不需要 content script，因为页面的标题和 URL 可以直接从 chrome.tabs.query 拿到，不需要注入代码进去读 DOM。提需求时明确说"不需要 content script"，不然 AI 可能默认给你加一个。

"不要 TypeScript、不要构建工具"——Chrome 扩展的目录是直接加载的，没有编译步骤。初期能跑通的最小结构比加工程化更重要，MVP 阶段最容易翻车的地方就是过早引入复杂工具链。

第二步：给插件加 content script（如果需要操作页面）

如果要做更复杂的事——比如提取页面正文、给特定元素高亮、在页面里注入浮层——就需要 content script 了。

真实提法示例：

在上面的基础上，增加一个功能：提取当前页面 <article> 或 <main> 标签内的纯文本内容。

要求：
- 在 content_scripts/extractor.js 里写提取逻辑，用 innerText 取文本，限制 5000 字符
- popup 里加一个"提取正文"按钮
- popup.js 用 chrome.tabs.sendMessage 发消息给 content script，content script 返回文本
- popup 里用 <textarea> 展示提取结果，可以手动复制

manifest.json 里 content_scripts 配置 matches 设为 "<all_urls>"，
run_at 设为 "document_idle"（等页面加载完）

这里说清楚消息通信的方向（popup → content script），以及 run_at 的值，否则 AI 可能给你用 document_start，那时候 DOM 还没加载完，提取到的是空的。

本地加载与调试

写完代码，怎么在浏览器里跑起来：

打开 Chrome，地址栏输入 chrome://extensions/
右上角打开"开发者模式"
点"加载已解压的扩展程序"，选你的项目目录
插件出现在列表里，去浏览器右上角找到图标点一下

你应该看到什么： 弹窗正常弹出，标题和 URL 显示正确，点复制按钮后去其他地方粘贴能看到 [标题](URL) 格式的文本。

改完代码怎么重新加载： chrome://extensions/ 页面找到你的插件，点刷新按钮（圆形箭头图标）。不需要重启浏览器，但需要刷新目标网页再试。

怎么看报错：

popup 的报错：右键点插件图标 → "审查弹出内容" → 打开一个 DevTools，看 Console
content script 的报错：正常打开网页 DevTools（F12），看 Console，插件注入的代码报错会出现在这里
background 的报错：chrome://extensions/ 里点"Service Worker"旁边的链接，打开 background 的 DevTools

打包发布要点

插件写完想上架 Chrome 应用商店，流程如下：

打包文件：在 chrome://extensions/ 页面，点"打包扩展程序"，选你的目录，生成 .crx 文件和 .pem 私钥文件（私钥要保存好，以后更新版本用）。商店上传其实不需要 crx，直接上传目录的 zip 包就行——把整个项目目录压缩成 zip，排除掉 .git、node_modules 这些。

发布到 Chrome 应用商店：需要注册 Chrome Web Store 开发者账号，一次性费用以官方为准，见 Google 开发者文档。提交后审核时间从几小时到几天不等，以官方当前政策为准。

必须准备的：插件名称、简短描述、详细描述、至少一张截图（1280×800 或 640×400）、隐私政策页（如果插件收集任何数据）。

发布策略：先设为"未列出"（Unlisted）内测，给自己和朋友用，确认没问题再设为公开。

插件特有的坑：故障排查表

症状	可能原因	排查方向
弹窗空白或报错 "Cannot read properties of null"	popup.js 里 `document.getElementById` 拿到了 null，HTML 元素 id 写错了	检查 popup.html 里的 id 和 popup.js 里的选择器是否一致
content script 的消息发出去没反应	content script 还没加载进那个页面，或者 `manifest.json` 里 `matches` 没有匹配当前 URL	检查 manifest 的 `content_scripts.matches`；在 DevTools Console 里确认 content script 有没有报注入错误
`chrome.tabs.query` 返回空数组	popup 里没有 `activeTab` 权限，或者当前标签是 `chrome://` 这类内部页面（扩展没有权限访问）	manifest 加 `"activeTab"` 权限；内部页面测不了，换普通网页
剪贴板写入无效	manifest 里缺 `"clipboardWrite"` 权限，或者在非用户手势触发的情况下调用了 Clipboard API	补权限；确认写入剪贴板的代码在用户点击事件里同步调用，不能在 `setTimeout` 或 `Promise.then` 里
图片或外部资源加载不了	MV3 的 Content Security Policy 限制了外部资源；或者 `web_accessible_resources` 没配置	把需要在网页里使用的扩展内部资源在 manifest 的 `web_accessible_resources` 字段里声明
跨域请求报错	content script 和目标网页同源，ajax 请求受同源策略限制	把跨域请求挪到 background service worker 里做，content script 发消息给 background 触发请求，再把结果传回来

插件特有的坑（文字版补充）

除了上面的故障表，有几个坑值得单独说：

Manifest V3 是强制的，不要用 V2 的写法。两者差别主要在 background——V2 是持久化的 background page，V3 是 service worker，随时可能被浏览器终止。AI 训练数据里有大量 MV2 的代码，让它写的时候明确说"用 MV3"，否则很可能给你生成过时的写法。

权限最小化是审核要求。商店审核会检查你声明了哪些权限，如果你声明了 <all_urls> 却只需要在一个网站工作，审核会质疑。只申请你实际用到的权限，没用到的删掉。

content script 注入时机。run_at 有三个值：document_start（DOM 还没加载）、document_end（DOM 加载完但图片等资源还没）、document_idle（页面基本加载完）。大多数操作 DOM 的场景用 document_idle 就对了，用 document_start 容易取到空节点。

跨域限制。content script 在网页上下文里跑，受同源策略约束，不能直接请求第三方 API。需要调外部接口的逻辑，放到 background service worker 里，content script 通过 chrome.runtime.sendMessage 触发。

低成本变现思路

插件本身是免费的壳，变现方式有几种路径：

订阅/买断：在 popup 里加一个功能锁，核心功能免费，高级功能（比如批量处理、云同步）需要付费。鉴权可以用 Stripe + 一个极简后端（甚至 Cloudflare Worker）验证 license key。

直接卖给特定用户群：做一个只针对某个平台的效率工具（比如"GitHub 代码一键复制+格式化"、"小红书评论批量导出"），在那个平台的社群里推，精准度很高。

免费插件导流：插件本身完全免费，在 popup 里放一个 CTA 导流到你的付费课程或 SaaS 产品。装机量是很好的社群证明。

关于更复杂的后端接入变现方式，可以参考用 AI 做表单机器人与自动化工具里的 webhook 思路，逻辑是互通的。

常见问题

Q：用 AI 生成的插件代码，能直接提交商店吗？

可以提交，但要自己测清楚。商店审核的重点是：权限声明是否过度、是否有恶意行为、隐私政策是否完整。AI 生成的代码功能上可以跑，但权限声明和隐私政策要你自己确认和补充。

Q：插件能访问 HTTPS 网站里的内容吗？

能。content script 可以注入到 HTTPS 页面，只要你在 matches 里声明了对应域名（或 <all_urls>）。只有 chrome://、edge:// 这类浏览器内置页面和 Chrome 应用商店自身的页面，插件访问不了。

Q：我的插件逻辑需要调 AI 接口，怎么安全处理 API Key？

不能把 API Key 硬编码在插件代码里——插件代码对用户是可见的，打包的 zip 解压后就能看到。正确做法是搭一个极简后端（一个 Cloudflare Worker 就够），插件发请求到这个后端，后端拿着 API Key 去调 AI 接口，再返回结果给插件。AI Key 只存在服务端。

Q：AI 生成的代码用了 chrome.tabs.executeScript，但报错说没有这个方法。

chrome.tabs.executeScript 是 MV2 的 API，MV3 里改成了 chrome.scripting.executeScript，而且需要在 manifest 里声明 scripting 权限。告诉 AI "用 MV3 的写法，用 chrome.scripting.executeScript"，让它重新生成。

下一步

搭通一个插件之后，你的选择很多：给它加更复杂的 content script（用 AI 做表单机器人与自动化工具里的 DOM 操作思路完全适用）、接一个 AI API 做智能分析、或者直接把它发布上去找第一批用户。

插件是一个极好的"学会了立刻能见到结果"的场景——比做一个需要登录、有数据库的 SaaS 快得多，反馈也即时得多。