日常使用多个AI模型时常常需要在不同接口之间反复测试，leadhi.cn这类AI模型聚合平台可以把多个主流模型放在同一界面下直接对比，省去逐个配置环境的精力。

缘起：一个朋友的小需求

上周朋友让我帮忙做个Chrome插件——在任意网页上选中文字右键翻译成中文。以前写Chrome插件要查manifest.json配置规则、background script和content script通信机制、Chrome API调用方式。光查文档就要半天。

这次我试了用Gemini 3.5 Flash全程辅助。从零到插件跑通大致40分钟。AI生成代码占了10分钟，剩下30分钟在调试和微调。

今天把这个流程分享出来。Prompt怎么写、哪些环节AI做得好、哪些需要人工介入，全部说清楚。

第一步：生成manifest.json

Chrome插件的入口是manifest.json。v3和v2的配置差异不小，新手很容易搞混。

Prompt：

text

text请帮我生成一个Chrome插件的manifest.json。
要求Manifest V3，插件名QuickTranslate。
功能：选中网页文字右键出现"翻译成中文"菜单，
点击后调用翻译API，结果以浮窗显示。
需要权限：contextMenus、activeTab、storage。
包含background service worker和content script。

Gemini 3秒出结果。正确设置了manifest_version为3、注册了service_worker、配置了content_scripts。框架完整可用。

小问题：它把翻译API域名写成了某个具体服务的URL，需要手动改成自己的API地址。但配置结构是对的。

第二步：生成Background Service Worker

Manifest V3用service_worker替代了以前的background page。

Prompt：

text

text请编写background.js。
1. 插件安装时注册右键菜单项"翻译成中文"
2. 点击菜单获取选中文字
3. 调用翻译API
4. 结果通过消息发送给content script显示
5. 用Chrome Storage缓存最近100条翻译记录
加中文注释。

Gemini生成的代码包含了
chrome.contextMenus.create、
chrome.contextMenus.onClicked.addListener、chrome.tabs.sendMessage等核心API调用。逻辑清晰注释完整。

有个坑：Manifest V3的service_worker不支持XMLHttpRequest只能用fetch。Gemini第一次生成用了XMLHttpRequest。跟它说”这是V3的service_worker请用fetch”，立刻修正了。

这个教训说明Prompt里最好明确写上”Manifest V3，请使用fetch API”。

第三步：生成Content Script

Content script负责在网页上显示翻译结果的浮窗。

Prompt：

text

text请编写content.js。
1. 接收background发来的翻译结果消息
2. 在选中文字位置附近显示浮窗
3. 浮窗显示原文和译文
4. 白底圆角阴影宽度不超300px
5. 点击浮窗外任意位置关闭
6. 淡入动画效果
CSS样式通过JS动态注入不要单独CSS文件。

Gemini生成了完整实现。用getSelection().getRangeAt(0).getBoundingClientRect()定位选中文字、动态创建DOM注入样式、click事件处理关闭。

样式细节需要微调——默认阴影太重圆角太大。但功能是完整的。

第四步：两个调试问题

插件加载到Chrome后出了两个问题。

问题一：右键菜单点了没反应。

把background.js报错信息喂给Gemini：”控制台报错Cannot read property 'sendMessage' of undefined。”

它指出是tabs API需要在manifest中声明”tabs”权限。加上后解决了。

问题二：浮窗在掘金和知乎上样式错乱。

描述给Gemini：”浮窗在掘金和知乎上样式被页面reset覆盖了。”

它提议用shadow DOM隔离样式，给出了完整的attachShadow代码。的确 解决了。

调试场景中Gemini的价值在于快速定位方向。报错信息喂进去几秒就给排查思路。比自己Google翻Stack Overflow快。

第五步：功能迭代

基础功能跑通后做了三轮迭代。

翻译浮窗加复制按钮。 “浮窗加一个复制按钮，点击把译文复制到剪贴板。” Gemini给了
navigator.clipboard.writeText的实现。一次通过。

翻译历史面板。 “点击插件图标弹出最近50条翻译记录。” 涉及popup.html和chrome.storage.local。Gemini生成了完整代码但样式需要手动调。

设置页面。 “支持配置翻译源语言和目标语言。” Gemini给出了options.html实现并正确连接chrome.storage.sync做持久化。

三个迭代大致15分钟。AI出框架人工调细节。

五个实战技巧

明确声明Manifest版本。 Prompt里必定要写”Manifest V3″。不写的话Gemini有概率生成V2代码，background script和permission声明方式完全不同。

分文件生成。 manifest.json、background.js、content.js、popup.html分开生成。每个文件一个Prompt。出来的代码更干净。

报错信息直接喂。 Chrome DevTools报错直接复制给Gemini。权限缺失、API版本不对、DOM操作时机错误——这些常见问题基本秒定位。

用shadow DOM隔离样式。 Content script注入的UI组件必定要用shadow DOM。在掘金、知乎、CSDN这些有reset样式的网站上不隔离样式必崩。

多轮对话而不是一次性生成。 先让Gemini生成基础版本，再逐步加功能。每轮聚焦一个需求，出来的代码质量比一次性要求所有功能好许多。

跟其他模型的对比

Gemini在速度上优势明显。Claude在代码质量上最稳——Manifest V3 API调用几乎没有V2语法混用。GPT-5.5综合均衡。

务实做法：Gemini快速生成初稿，遇到API兼容性问题切Claude精调。改个字段就切模型。

趋势判断

Chrome插件开发超级适合AI辅助。缘由有三：文件结构规范清晰，API文档完善，单个文件代码量不大。这些特点让AI生成代码的准确率相对较高。

Gemini 3.5 Flash的速度优势在这个场景下被放大了。插件开发是快速迭代的过程——改一行代码刷新看效果。3秒出结果基本无感，10秒就会打断节奏。

提议从一个简单的Chrome插件需求开始试。选中文字翻译、网页截图标注、标签页管理——这些小工具用Gemini辅助半小时就能跑通。跑出自己的体感比看任何评测都靠谱。