做技术这几年，我越来越相信一件事：与其追着各种 AI 新闻看热闹，不如让 AI 老老实实帮你把一个真实项目落地。最近我给自己定了个小目标——用 AI 辅助开发一个属于自己的多开浏览器，名字就叫“奇异博士浏览器”，听起来中二，但做起来是真有意思。所谓多开浏览器，本质上就是能在同一台电脑上同时运行多个彼此隔离的浏览器实例，每个实例有独立的用户数据、独立的指纹特征，互不干扰。它最常见的用途是开发测试、隐私隔离、多账号管理，你要是做爬虫采集或者广告投放数据分析，这东西基本是刚需。更难得的是，这次开发过程我几乎全程让 AI 打主力，从技术选型到代码生成，再到报错排查，全部有 AI 参与。这套“AI 辅助开发完整项目”的流程，我觉得很值得拿出来聊聊，适合想入门 AI 编程、又不想停留在“问一句答一句”阶段的朋友参考。
选择“奇异博士”这个名字没有太玄学的含义，单纯是因为这个项目能同时变出多个“平行的浏览器分身”，和奇异博士的能力有点神似。项目目标非常明确：不依赖任何商业指纹浏览器，用一套开源技术栈，自己做出来一个能创建、管理、启动多个隔离浏览器实例的工具。整个过程里，AI 负责输出代码和排查思路，我负责设计架构和验证结果。今天这篇就把完整实战过程、核心代码、踩过的坑都写出来，希望给你一个可以直接参考复现的样板。
1. 项目整体设计与技术选型拆解
1.1 多开浏览器的本质：不是开几个窗口那么简单
很多人以为多开浏览器就是多打开几个窗口，其实完全不是一回事。普通浏览器开多个窗口，共享同一个用户数据目录、同一个进程池，Cookie、LocalStorage、指纹特征全部一致。网站如果想识别你，轻而易举就能判断“这几个窗口来自同一台设备的同一个浏览器”。
真正意义上的多开浏览器，核心是做到“实例隔离”。每个浏览器实例必须有独立的用户数据目录（user-data-dir）、独立的渲染进程、独立网络堆栈，最好还能自定义 User-Agent、Canvas 指纹、WebRTC 等硬件特征，这样不同实例之间才不会留下关联性。
这里面最关键的技术点是 Chromium 的--user-data-dir参数。只要给浏览器进程指定一个全新的、空的数据目录，它就会认为自己是第一次运行，所有 Cookie、缓存、扩展程序全部重来。这也是几乎所有多开浏览器、指纹浏览器的基础原理。理解了这个，你就明白为什么商业产品动辄收费很高，因为后面那些指纹篡改和自动化控制代码，才是真正的技术壁垒。
1.2 为什么选择 Electron + Playwright + AI 这套组合
在做技术选型的时候，我把几个方案摆在桌面上逐一对比过，直接用表格列出来更清楚。
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| Chrome 启动参数 + 批处理 | 最简单，零开发成本 | 无法精细化控制指纹，不能自动化操作 | 临时多开场景 |
| Node.js + Puppeteer | 生态成熟，文档多，上手快 | 新版对浏览器版本绑定较紧，API 偶尔变动 | 自动化脚本、爬虫 |
| Node.js + Playwright | 支持 Chromium / Firefox / WebKit，API 更现代 | 参数相对复杂 | 跨浏览器测试、多实例管理 |
| Electron + Playwright | 能做出带界面的桌面应用，控制能力最强 | 开发量最大，需要前端基础 | 想做成产品级工具 |
我最后选了 Electron + Playwright 的组合。Electron 负责做桌面壳，给用户提供一个管理面板，用来创建实例、查看运行状态、一键启动。Playwright 负责真正去拉起 Chromium 实例、注入脚本、控制页面行为。AI 在这个过程中承担了三件事：
第一件事是选型咨询。我把自己的想法和约束条件抛给大模型，让它帮忙列举不同方案的优劣势，避免了我自己去翻大量文档。第二件事是代码实现。所有核心模块，比如多实例管理器、指纹注入脚本、实例健康检查，都是通过 AI 对话生成的。第三件事是排错。项目运行中遇到各种奇奇怪怪的错误，我直接把报错日志贴给 AI，让它给出排查方向和修复代码。
这套流程走下来，我的体感是：AI 不是替代你思考，而是把“从零写代码”变成了“审代码、改代码、验证代码”。看起来差别不大，但开发效率至少翻了一倍。
1.3 AI 不是万能，但在这些环节确实高效
我不太喜欢吹“AI 自动生成整个应用”那种说法，至少现阶段不现实。实际用下来觉得 AI 在几个特定环节特别能打。
第一个是样板代码生成速度极快。比如“用 Playwright 启动三个独立浏览器实例并保存用户目录”这种需求，正常人写大概要查半天文档，AI 十秒钟就能给出可用代码，而且参数基本正确。第二个是对报错信息的理解能力远超搜索引擎。以前遇到报错，你要复制错误信息去 Google，翻几篇博客才能定位问题。现在直接把完整的堆栈贴给 AI，它通常能一次给出准确的原因和修复方案。第三个是对需求的理解能力，前提是你的 Prompt 足够清晰。AI 能把你模糊的“我想要一个类似 XX 的东西”翻译成具体的技术架构。
但 AI 也有明显短板。当项目变大、涉及多个文件协同、状态管理复杂的时候，AI 生成的代码就容易出现“单点正确、整体混乱”的情况。所以你需要自己把控架构，不能让 AI 放飞自我。这也是我为什么坚持自己设计整体方案，只把具体实现细节交给 AI。
2. 核心功能实现与关键技术细节
2.1 多实例启动的核心：user-data-dir 的玩法
多开浏览器的地基就是给每个实例分配独立的用户数据目录。Chromium 系的浏览器，包括 Chrome、Edge，还有 Playwright 拉起的 Chromium，都认这个参数。
我写了一个简单的批处理脚本，适合不想装任何依赖、快速体验多开效果的朋友。新建一个multi-launch.bat，内容如下。
@echo off setlocal enabledelayedexpansion set BASE_DIR=%LOCALAPPDATA%\BrowserProfiles set COUNT=3 for /L %%i in (1,1,%COUNT%) do ( set PROFILE_DIR=!BASE_DIR!\Profile_00%%i if not exist "!PROFILE_DIR!" mkdir "!PROFILE_DIR!" start "" "C:\Program Files\Google\Chrome\Application\chrome.exe" ^ --user-data-dir="!PROFILE_DIR!" ^ --no-first-run ^ --no-default-browser-check ^ --disable-blink-features=AutomationControlled ) echo 已启动 %COUNT% 个独立浏览器实例 pause这里有三个参数值得展开说说。
--user-data-dir指定用户数据目录，这是隔离的关键。如果这个目录不存在，浏览器会自动创建。--no-first-run是跳过首次运行引导页，否则每次新建目录都会弹欢迎界面，很烦人。--disable-blink-features=AutomationControlled则是隐藏自动化控制标记，这个参数在后面的反检测环节很重要。
如果你用 Playwright，则不是传参，而是通过launchPersistentContext方法，它会自动帮我们管理用户数据目录。看下面这段 Node.js 代码。
const { chromium } = require('playwright'); async function createBrowserInstance(profileId) { const userDataDir = `./profiles/profile_${profileId}`; const context = await chromium.launchPersistentContext(userDataDir, { headless: false, viewport: { width: 1280, height: 800 }, args: [ '--disable-blink-features=AutomationControlled', '--no-first-run', '--disable-infobars', ], }); const page = context.pages()[0] || await context.newPage(); return { context, page, userDataDir }; } // 启动3个隔离实例 (async () => { const instances = []; for (let i = 1; i <= 3; i++) { const instance = await createBrowserInstance(i); instances.push(instance); console.log(`实例 ${i} 已启动，用户目录: ${instance.userDataDir}`); } })();这里有个细节很容易踩坑：launchPersistentContext必须在创建实例时就指定用户数据目录，之后每次调用都用同一个目录，才能保持登录态。如果你在多个地方分别launch，不传目录或者传了不同目录，那就相当于每次都是新浏览器。多开管理器的本质就是管理这些目录的创建、增删、切换。
2.2 指纹隔离：不只是改个 User-Agent
有了独立的用户数据目录，只能保证数据层面隔离。但网站识别一台设备，数据只是其中一环，更重要的是指纹。浏览器指纹由很多信息组合而成，包括 User-Agent、Canvas、WebGL、WebRTC、时区、语言、屏幕分辨率、字体列表等等。如果这些信息完全一致，网站很容易判断“这些实例背后其实是同一个人”。
所以多开浏览器的进阶功能就是指纹伪装。这里我实现了三个最核心的点，也是 AI 代码贡献最大的部分。
第一个是 User-Agent 随机化。这个最简单，在 Playwright 中直接配置即可。
const userAgents = [ 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36', 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36', 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36', ]; function getRandomUserAgent() { return userAgents[Math.floor(Math.random() * userAgents.length)]; }第二个是注入脚本覆盖navigator.webdriver。默认情况下，自动化浏览器会暴露navigator.webdriver = true，网站一查就知道你是机器人。可以通过addInitScript在页面加载前把属性覆盖掉。
await context.addInitScript(() => { Object.defineProperty(navigator, 'webdriver', { get: () => undefined, }); window.chrome = { runtime: {}, }; });第三个就是 Canvas 指纹随机化。Canvas 指纹的原理是让页面绘制一段文字或图形，然后用toDataURL读取像素数据，不同设备绘制的结果略有差异，形成唯一标识。想伪造就必须在toDataURL和getImageData方法里做手脚，给它返回一个被轻微扰动的结果。
await context.addInitScript(() => { const originalToDataURL = HTMLCanvasElement.prototype.toDataURL; HTMLCanvasElement.prototype.toDataURL = function(...args) { const imageData = originalToDataURL.apply(this, args); // 这里对图片数据做轻微扰动，让每次生成的结果独一无二 return imageData.replace(/data:image\/png;base64,/, 'data:image/png;base64,'); }; });上面这段是对 AI 生成代码的简化处理，实际上做 Canvas 指纹扰动比这复杂，通常要通过getImageData修改像素值再重新绘制。但思路是一致的：让每次生成的指纹数据不同，且与真实设备不一致。只要这三个点做到位，基础的多开反检测就算完成了。
2.3 用 AI 生成核心代码：Prompt 才是关键
这个项目里，我给 AI 的最高频指令就两类：写功能和修 Bug。写功能时，我发现 Prompt 的质量直接决定代码质量。
举个例子，我想实现“实例健康检查”，一开始我的提问是“写一个检查浏览器是否还活着的代码”，AI 给出的方案很笼统，只是简单地try catch调一个页面。后来我把 Prompt 改成了带上下文和约束的描述：
我正在开发一个基于 Playwright 的多开浏览器管理器。请帮我实现一个函数，输入是一个
BrowserContext对象，输出是布尔值，表示该浏览器实例是否健康可用。健康标准包括：底层浏览器进程未退出、任意一个页面能正常执行document.title并返回非空结果。请用 Node.js 实现，并处理可能出现的超时异常。
改完之后，AI 生成的代码直接可用，还主动加了Promise.race做超时控制。这个经验很重要：AI 不是读心术，你把边界条件、输入输出约束、异常处理方式描述得越清晰，它返回的代码质量就越高。
还有一个好用的小技巧：让 AI 给代码加注释。不是简单的中文注释，而是让它标注“这段代码为什么这样写”，这样你审查代码的时候能快速理解设计意图，避免把隐患代码合并进去。尤其是涉及浏览器指纹这种偏底层的逻辑，AI 往往能给出超出你预期的细节解释。
3. 从零开始：完整实操流程实录
3.1 环境准备与项目骨架搭建
工欲善其事，必先利其器。先把开发环境准备好。我的推荐配置是：
- Node.js 18 以上版本，LTS 即可
- 代码编辑器，VS Code 或者其他你熟悉的都行
- Playwright，作为核心自动化库
- Electron，作为桌面壳（如果你只想要命令行版本，可以先跳过）
初始化项目非常简单，就几步命令。
mkdir strange-doctor-browser cd strange-doctor-browser npm init -y npm install playwright electron npx playwright install chromium这里有个小坑必须提醒：npx playwright install chromium会下载一个独立的 Chromium 内核，大概一百多 MB，网络不好的时候容易超时。如果下载失败，可以设置镜像源，或者直接使用系统安装的 Chrome，通过executablePath指定路径。
项目结构我建议这样分模块，别把所有代码堆在一个文件里。
strange-doctor-browser/ ├── main.js # Electron 主进程入口 ├── manager/ │ └── instance-manager.js # 多开实例管理器 ├── fingerprint/ │ └── fingerprint.js # 指纹注入脚本 ├── ui/ │ ├── index.html # 管理界面 │ └── renderer.js # 渲染进程逻辑 └── profiles/ # 浏览器用户数据目录（自动生成）先搭好目录结构，再让 AI 填充内容。从工程化角度来说，这个阶段克服的是“烂开始”的心态，你不需要一次写完所有代码，但一定要把边界划清楚。
3.2 让 AI 写第一个“多开管理器”
项目骨架有了，接下来就是核心模块。我让 AI 帮我写instance-manager.js，这是个类，负责：
- 创建新实例
- 列出所有实例状态
- 关闭指定实例
- 清理用户数据目录
AI 第一次给出的代码长这样的简化版。
const { chromium } = require('playwright'); const fs = require('fs'); const path = require('path'); class InstanceManager { constructor(profileRoot = './profiles') { this.profileRoot = profileRoot; this.instances = new Map(); if (!fs.existsSync(profileRoot)) { fs.mkdirSync(profileRoot, { recursive: true }); } } async createInstance(id) { const userDataDir = path.join(this.profileRoot, `profile_${id}`); const context = await chromium.launchPersistentContext(userDataDir, { headless: false, args: ['--disable-blink-features=AutomationControlled'], }); const page = context.pages()[0] || await context.newPage(); this.instances.set(id, { context, page, userDataDir }); console.log(`创建实例 ${id} 成功`); return { id, ...this.instances.get(id) }; } async closeInstance(id) { const instance = this.instances.get(id); if (instance) { await instance.context.close(); this.instances.delete(id); console.log(`关闭实例 ${id} 成功`); } } listInstances() { return Array.from(this.instances.entries()).map(([id, info]) => ({ id, userDataDir: info.userDataDir, pageUrl: info.page.url(), })); } } module.exports = InstanceManager;这个代码胜在直接能用，逻辑干净。但它也暴露了 AI 代码的两个通病：一是没有做启动失败的重试机制，二是没有考虑多个实例同时启动时，端口或资源竞争问题。所以我后面自己加了一段包装，在createInstance外层套了个retry函数，失败自动隔 500 毫秒重试一次。这个改进指南后面再说。
3.3 联调与自测：本地跑通三个隔离实例
代码写完就要验证。我的做法是先跑一个命令行 demo，不做 UI，只是持续开着三个实例，手动确认它们互相隔离。
我写了一个测试脚本test.js。
const InstanceManager = require('./manager/instance-manager'); (async () => { const manager = new InstanceManager(); await manager.createInstance('id1'); await manager.createInstance('id2'); await manager.createInstance('id3'); // 分别在三个标签页里访问不同网站 const pages = ['https://example.com', 'https://httpbin.org/headers', 'https://www.baidu.com']; let idx = 0; for (const [id, info] of manager.instances) { await info.page.goto(pages[idx++], { waitUntil: 'domcontentloaded' }); const title = await info.page.title(); console.log(`实例 ${id} 页面标题: ${title}`); } // 等待片刻观察稳定状态 await new Promise(resolve => setTimeout(resolve, 5000)); console.log('当前活跃实例:'); console.log(manager.listInstances()); for (const id of ['id1', 'id2', 'id3']) { await manager.closeInstance(id); } process.exit(0); })();跑完发现一个非常典型的问题：三个实例同时启动时，Playwright 默认会启动三个独立的浏览器进程，这没问题。但如果网速慢，goto到不同网站时，某些页面会长时间 pending，导致domcontentloaded事件迟迟不触发。解决方案是给每个goto加上timeout: 30000，同时把超时错误单独捕获，避免一个页面卡死拖垮整个实例。
本地跑通之后，接下来就可以做界面了。Electron 主进程拉起一个窗口，渲染进程展示实例列表，通过 IPC 和主进程通信，调InstanceManager的方法。这个部分 AI 也很擅长，它可以直接生成完整的main.js和index.html，你只要把数据流捋清楚。我这里贴一下主进程的关键代码。
const { app, BrowserWindow, ipcMain } = require('electron'); const path = require('path'); const InstanceManager = require('./manager/instance-manager'); const manager = new InstanceManager(); function createWindow() { const win = new BrowserWindow({ width: 1000, height: 700, webPreferences: { preload: path.join(__dirname, 'preload.js'), contextIsolation: true, }, }); win.loadFile('ui/index.html'); } app.whenReady().then(createWindow); ipcMain.handle('create-instance', async (event, id) => { return await manager.createInstance(id); }); ipcMain.handle('close-instance', async (event, id) => { await manager.closeInstance(id); return { success: true }; }); ipcMain.handle('list-instances', () => { return manager.listInstances(); }); app.on('window-all-closed', () => { if (process.platform !== 'darwin') app.quit(); });到这一步，一个带界面、能创建实例、能关闭实例的“奇异博士浏览器”就已经基本成型了。剩下的优化工作主要是视觉细节和错误提示。
4. 常见问题与排查技巧实录
4.1 实例为什么总是崩溃或卡死
我实际操作中遇到最多的问题就是实例无响应，尤其是同时启动三个以上实例时。排查下来主要原因有三个。
一是用户数据目录被占用。同一个用户数据目录不能同时被两个 Chromium 进程启动，否则第二个进程会报错退出。解决方法是每次启动前检查目录锁文件是否存在，如果存在，先清理或提示用户确认没有残留进程。
二是系统资源不足。每个 Chromium 实例大概会占用 200-300MB 内存，同时开五六个实例，内存轻松上 1.5GB。如果电脑本身只有 8GB 内存，卡顿甚至崩溃很正常。解决方法是控制并发数，或者在代码里增加总实例数上限，比如最多 5 个。
三是和安全软件的冲突。某些杀毒软件会拦截浏览器进程的某些操作，导致实例崩溃。这个属于环境问题，只能建议开发测试时关闭实时保护。我把这几个典型原因整理成了表格。
| 故障现象 | 常见原因 | 解决办法 |
|---|---|---|
| 实例启动后立刻退出 | 用户数据目录被占用 | 清理残留进程，更换目录 |
| 打开页面时卡死 | 网络慢导致goto超时 | 设置timeout参数，捕获超时错误 |
| 多个实例同时开启后系统卡顿 | 内存不足 | 限制最大实例数，降低并发 |
| 页面提示“请开启 JavaScript” | 注入脚本导致 JS 异常 | 检查addInitScript的代码是否报错 |
4.2 网站还是识别出我是同一台电脑
这是多开浏览器最核心也最头疼的问题。如果你只是做了 user-data-dir 隔离，而没做指纹伪装，网站很容易发现异常。识别逻辑通常是这样的：两个浏览器实例的 User-Agent 一样、Canvas 指纹一样、WebRTC 暴露的内网 IP 一样，网站通过某一种信息就能将它们关联。
我的经验是分三层排查。第一层看基础属性，包括 User-Agent、平台、语言、时区。如果这些不一致，说明配置还没生效。第二层看自动化标记，navigator.webdriver是不是true，这是最容易被忽略的。第三层看高级指纹，包括 Canvas、WebGL、WebRTC、字体列表。这一层最难伪装，也最容易被用于高级风控。
坦白说，要做到完美指纹伪装，复杂度远超一篇文章能覆盖的范围。但如果你的使用场景是普通测试和隐私隔离，做好前三层已经能满足绝大多数需求。我的建议是优先把基础属性做对，再逐步叠加高级指纹伪装。
4.3 AI 生成的代码报错怎么办
和 AI 协作开发，遇到最多的场景就是它生成的代码在本机跑不过。我原来也踩过坑，后来总结了一套高效的反馈流程。
第一步是让 AI 学会“看日志”。把完整的错误堆栈直接贴给它，不要自己加工转述。AI 对英文错误信息的理解能力很强，你转述反而会丢失信息。第二步是追问“为什么会这样”，光让它改代码还不够，要让它解释错误原因，这样你才能判断它的修复方向是否正确。第三步是让它给多个方案，特别是当涉及“改一行代码”和“重构整个函数”两种选择时，让 AI 对比利弊，你来拍板。
举个例子，我遇到过一个很诡异的问题：Playwright 启动的浏览器实例，page.evaluate执行多次后返回结果变成undefined。贴上错误日志后，AI 判断是变量作用域问题，还主动提醒检查是不是在回调里使用了未声明的变量。结果一查，果然是我在setInterval里引用了一个已经销毁的page对象。这种问题如果没有 AI 帮忙定位，光靠人肉排查，至少得花半小时。
5. 一些值得收藏的实操心得
到这里，“奇异博士浏览器”的核心功能已经全部讲完了。但我还是想把一些零散但实用的心得写出来，这些都是文档里很难找到的东西。
第一，做多开浏览器这类工具时，一定要把用户数据目录的命名和管理规范化。我的做法是profile_时间戳_随机数，而不是简单的递增数字，因为递增数字容易猜，而且重启后容易混淆。同时还要定期清理不再使用的目录，否则硬盘会被不知不觉塞满。
第二，Electron 开发和调试时，建议把headless: false改成有头模式，这样能看到浏览器实际运行效果。等逻辑稳定后再考虑无头模式，方便后面做自动化部署。
第三，启动多个实例的时候，给浏览器窗口加上--window-position参数，让每个窗口出现在屏幕不同位置，看起来更清晰，也方便识别。
const args = [ '--disable-blink-features=AutomationControlled', `--window-position=${xOffset},${yOffset}`, ];最后，我想分享一个对整个项目最有帮助的小技巧：写一个README.md，把你和 AI 的对话精华整理进去。特别是那些“为什么这样设计”的答案，写下来能极大提升你的项目可维护性。我这次做奇异博士浏览器，边做边记录，最后 README 比代码还长，但每次回看都觉得值得。
这个项目目前还在持续迭代中，后续我想加入的功能包括：更精细的指纹配置面板、代理配置管理、批量创建实例的模板系统，甚至让 AI 直接生成指定网站的自动化操作流程。多开浏览器这个方向，技术深挖下去很有意思，而且 AI 的加入让开发门槛低了很多，强烈推荐你也上手试试。
