基于Electron构建多模型AI聚合工具:LLM-God桌面应用开发解析
1. 项目概述一个桌面端的多模型AI聚合工具如果你和我一样每天的工作流里充斥着和不同大语言模型LLM的对话——写代码时问问ChatGPT查资料时切到Gemini需要深度分析时又得打开Claude的网页——那么你肯定也受够了在无数个浏览器标签页之间反复横跳、复制粘贴的繁琐操作。这种割裂的体验不仅效率低下还常常打断思考的连续性。LLM-God这个开源项目正是为了解决这个痛点而生。它是一个基于 Electron 构建的 Windows 桌面应用核心功能是让你在一个统一的界面里同时向多个主流LLM如ChatGPT、Claude、Gemini、Grok、DeepSeek、Copilot等发起提问并并排查看它们的回答。简单来说它就像一个为你专属定制的“AI浏览器”或“指令中心”。你不再需要为每个模型单独打开一个网页登录不同的账号然后在不同窗口间切换。所有操作都集中在一个应用内完成输入问题一键发送给所有选中的模型然后在一个屏幕上横向对比它们的回答。这对于需要多角度验证信息、对比模型能力差异或者单纯想“货比三家”找到最佳答案的场景来说效率提升是颠覆性的。无论是程序员调试代码、文案工作者构思内容还是学生研究课题都能从中受益。这个项目的核心价值在于“聚合”与“对比”。它没有尝试去训练或微调任何一个模型而是巧妙地利用Web技术将各大AI厂商的官方网页界面“嵌入”到自己的应用中并通过JavaScript注入的方式模拟用户操作如点击“发送”按钮、清空对话实现了跨平台的统一控制。这种做法既避免了复杂的API集成和费用问题对于免费用户你依然受各平台自身的额度限制又保证了你能用到每个模型最新、最官方的界面功能包括它们最新的多模态能力如上传图片分析。2. 核心设计思路与技术选型解析2.1 为什么选择Electron架构开发者选择Electron作为技术栈是一个非常务实且高效的决定。Electron允许使用前端技术HTML, CSS, JavaScript/TypeScript来构建跨平台的桌面应用。对于LLM-God这样一个本质上重度依赖Web界面和浏览器交互的应用来说Electron几乎是“天作之合”。核心优势在于BrowserView或WebView组件。Electron可以创建多个独立的、隔离的浏览器实例来加载不同的网页。LLM-God正是为每个LLM如chat.openai.com, claude.ai创建了一个这样的浏览器视图并将它们并排布局在应用窗口中。这意味着每个模型都在其原生的、官方的网页环境中运行保证了功能的完整性和稳定性包括Cookie、LocalStorage等状态的保持这也是你需要提前登录的原因。如果换用其他技术方案比如纯原生开发C/C#需要为每个平台Windows, macOS, Linux分别实现复杂的浏览器嵌入和控件开发成本极高。Tauri等新兴框架虽然更轻量但在处理多个复杂Web视图的同步控制、JavaScript注入的灵活性上成熟度和社区支持可能暂时不如Electron。直接调用官方API这固然是另一种思路但会带来几个问题1) 需要处理每个平台的API密钥和计费2) 无法使用官方网页提供的丰富交互功能如代码解释器、文件上传、实时预览等3) 对于免费用户来说API通常不是免费选项。因此Electron的“用网页做应用”的思路完美契合了LLM-God“聚合网页应用”的核心需求。2.2 实现多模型同步控制的关键JavaScript注入这是整个项目的技术核心。仅仅把网页装进“盒子”里是不够的还需要能让我们的桌面应用去“操作”这些网页。例如当你在底部的统一输入框打字并按下CtrlEnter时应用需要自动将这段文本填入每个模型网页的输入框并触发其发送按钮。这通过“内容脚本Content Script注入”实现。Electron 允许主进程或渲染进程向加载的网页中注入并执行JavaScript代码。LLM-God需要为每个支持的模型编写特定的注入脚本。这些脚本需要完成以下任务监听外部指令通常通过window.addEventListener监听来自Electron主进程的特定消息如‘send-prompt’。定位DOM元素使用document.querySelector或document.getElementById等API精确找到目标网页的输入框和发送按钮。这是最脆弱的一环因为任何一家厂商的网页前端改版都可能导致选择器失效这也是为什么项目需要持续维护的原因。模拟用户操作将接收到的文本赋值给输入框的value属性然后触发发送按钮的click事件或者模拟一个键盘回车事件。注意这种基于DOM操作的方式虽然强大但高度依赖于目标网页的HTML结构。开发者提到在代码中加入了“更多上下文的JavaScript注入逻辑”这很可能是指更智能的选择器策略例如不依赖固定的ID可能变化而是结合CSS类名、元素属性、甚至相对位置来定位元素以提高健壮性。2.3 应用层架构主进程与渲染进程的协作一个典型的Electron应用包含一个主进程和多个渲染进程。在LLM-God中主进程Main Process负责创建应用窗口、管理各个BrowserView的生命周期、处理系统事件如关闭应用CtrlW。它也是所有渲染进程之间通信的枢纽。渲染进程Renderer Process可以理解为每个BrowserView背后的“浏览器标签页”。但更重要的是项目本身还有一个用于显示UI控件如模型选择下拉框、统一输入框、发送按钮的渲染进程。这个UI进程负责收集用户的输入和设置然后通过Electron的IPC进程间通信机制将“发送指令”广播给所有承载LLM网页的BrowserView进程。这种架构实现了控制与显示的分离用户在一个统一的UI上进行操作指令被分发给多个后台运行的Web视图最后再将各个视图的显示结果呈现在同一个窗口的不同区域。3. 详细使用指南与核心功能实操3.1 从零开始安装与首次运行虽然项目提供了打包好的Setup.exe但作为开发者或喜欢折腾的用户了解其安装和运行机制大有裨益。对于普通用户使用Release版本前往项目的GitHub Releases页面下载最新的Setup.exe文件。运行时Windows SmartScreen可能会弹出警告提示“未识别的应用发布者”。这是因为开发者尚未购买昂贵的代码签名证书对应用进行数字签名。这是开源小项目的常见情况。你可以点击“更多信息”然后选择“仍要运行”。如果你对安全性有疑虑最好的方式就是像开发者建议的那样仔细阅读其开源代码。整个逻辑是透明的你可以确认没有恶意行为。对于开发者从源码运行这是理解项目的最佳途径。按照README的步骤# 1. 克隆仓库 git clone https://github.com/czhou578/llm-god.git cd llm-god # 2. 安装依赖 (这步可能会花点时间因为要拉取Electron等大型包) npm install # 3. 启动开发模式 npm run start执行npm run start后Electron会启动并加载应用。同时这个命令可能还会在桌面创建快捷方式。在开发模式下你可能会看到开发者工具窗口自动打开方便调试。3.2 核心工作流一次提问多方回答应用的主界面通常分为上下两部分上半部分被分割成多个窗格Tile每个窗格承载一个LLM的网页界面如ChatGPT、Claude。下半部分是一个统一的控制区域包含一个大文本输入框支持粘贴文字和图片和一个模型选择下拉菜单。标准操作流程如下确保登录在应用内每个模型的窗格都需要你手动登录一次。因为应用只是嵌入网页所以你的登录状态Cookie会像在普通浏览器中一样被记住。这是应用正常工作的前提。选择模型通过右下角的下拉菜单你可以动态添加或移除想要提问的模型。默认可能固定有ChatGPT、Gemini等但你可以增加Grok或DeepSeek。输入问题在底部的文本框中输入你的问题。这里有一个超级实用的技巧你可以直接从资源管理器拖拽图片文件或者从剪贴板粘贴截图CtrlV到这个文本框。应用会自动处理图片上传这对于需要视觉分析的模型如GPT-4V, Claude 3, Gemini Pro Vision来说极其方便。一键发送按下Ctrl Enter。此时你的问题和图片如果有会被同时发送到所有已选中且已登录的模型窗格中。对比分析稍等片刻各个窗格内就会开始流式输出各自的回答。你可以并排滚动阅读快速比较不同模型在准确性、详细程度、创造性或代码能力上的差异。3.3 高级功能与细节把控“新聊天”按钮开发者特别强调了语言设置问题。某些LLM网页的“New Chat”按钮文本可能是本地化的如中文的“新对话”。如果注入脚本只查找英文的“New Chat”按钮在其他语言界面下就会失效。因此将你的AI聊天网页界面语言设置为英语是保证所有自动化功能特别是重置对话正常工作的关键。这是一个非常实际的开发经验细节。自定义提示词模板根据更新日志项目加入了保存自定义提示词的功能。这非常适合那些你经常使用的、结构化的提问模板比如“请以表格形式总结以下内容”、“请用Python实现以下算法并添加详细注释”。你可以保存它们随时调用免去重复输入。暗黑模式对于深夜工作者来说暗黑模式是必备功能。项目的更新显示已加入此特性提升了长时间使用的舒适度。4. 开发者指南参与贡献与深度调试4.1 搭建高效的开发环境如果你想修复bug或添加新功能以下开发流程比简单的npm run start更高效打开两个终端窗口。在第一个终端运行 TypeScript 编译器监听模式npx tsc --watch。这样每当你修改.ts源文件并保存它会自动编译成.js文件。在第二个终端运行 Electron 并监控编译后的主文件npx electronmon dist/main.js。electronmon类似于nodemon它会在检测到dist/main.js文件变化时自动重启Electron应用。这种“双终端”模式实现了热重载让你在修改代码后几乎能立刻看到效果无需手动停止和重启。4.2 如何为项目添加一个新的LLM支持这是最常见的贡献类型。假设你想添加对“通义千问”网页版的支持你需要深入src/目录通常需要修改以下部分模型配置文件找到一个可能叫models.ts或config.ts的文件在其中添加新模型的配置项。包括显示名称、唯一标识符、主页URL如https://tongyi.aliyun.com/、以及其JavaScript注入脚本的路径或内容。编写注入脚本这是最关键也最繁琐的一步。你需要创建一个新的.js或.ts文件编写针对目标网页的DOM操作逻辑。首先手动分析用浏览器打开目标网站打开开发者工具F12仔细研究其聊天页面的HTML结构。定位输入框找到文本输入区域的textarea或div[contenteditabletrue]元素。定位发送按钮找到发送按钮注意它可能是一个button也可能是一个div甚至是通过回车键触发。编写模拟代码编写函数接收文本参数将其填入输入框并触发发送事件。必须考虑网页是单页应用SPA的情况元素可能动态加载。// 示例一个非常基础的注入脚本模板 window.addEventListener(message-from-electron, (event) { if (event.data.type inject-prompt) { const promptText event.data.payload; // 1. 找到输入框 - 这里的选择器需要你根据实际网页确定 const inputEl document.querySelector(textarea[placeholder*输入]); if (inputEl) { inputEl.value promptText; inputEl.dispatchEvent(new Event(input, { bubbles: true })); // 触发输入事件 // 2. 找到发送按钮并点击或者模拟回车键 const sendButton document.querySelector(button.send-btn); if (sendButton) { sendButton.click(); } else { // 如果没有按钮尝试模拟回车 const enterEvent new KeyboardEvent(keydown, { key: Enter, code: Enter, keyCode: 13 }); inputEl.dispatchEvent(enterEvent); } } } });更新UI逻辑修改前端UI代码将新模型加入到右下角的下拉选择列表中。测试与提交在开发模式下反复测试确保注入脚本稳定工作。然后按照项目要求撰写清晰的Pull Request描述附上修改点列表和功能正常的截图。4.3 调试技巧与常见问题排查在开发过程中你一定会遇到各种问题。以下是一些实用的调试技巧打开开发者工具在src/main.ts中确保有mainWindow.webContents.openDevTools({ mode: detach });这行代码开发环境下。这样每个BrowserView和主UI窗口的开发者工具都能被打开。你可以在这里查看Console日志、检查网络请求、审查DOM元素这对于调试注入脚本至关重要。处理跨域与上下文隔离Electron默认启用了上下文隔离Context Isolation和沙箱这可能会阻止你的预加载脚本Preload Script或主进程直接访问网页的window对象。你需要正确配置webPreferences并通过contextBridge安全地暴露API给渲染进程。如果发现注入的脚本无法执行或无法通信首先检查这里的配置。处理动态加载的内容很多现代网页是动态加载的如React, Vue构建的单页应用。你的注入脚本可能在页面初始HTML加载时就执行了但那时聊天输入框可能还没被渲染出来。解决方案是使用MutationObserver监听DOM变化或者将你的脚本逻辑包装在setInterval或requestIdleCallback中定期检查目标元素是否存在。单元测试项目已经引入了单元测试根据更新日志。在修改核心逻辑如模型配置、工具函数后运行npm test或相应的测试命令确保没有破坏现有功能。为新增的模型注入脚本编写测试虽然困难但可以为关键的工具函数编写测试。5. 项目演进、生态对比与未来展望5.1 与同类项目的差异化生存开发者在免责声明中提到了GodMode项目这引出了一个有趣的讨论开源世界里的同类工具如何找到自己的定位GodMode是一个更宏大、更激进的想法它试图聚合成百上千个开源和闭源模型甚至集成本地模型。这带来了两个问题1)维护成本极高每个模型的接口变动都需要跟进工作量巨大导致项目可能陷入维护停滞。2)体验稀释对于绝大多数用户来说常用的、性能顶尖的模型就那么几个。过多的选择反而增加了认知负担。LLM-God则采取了“少即是多”和“聚焦主流”的策略。它只集成那些经过市场验证、拥有广泛用户基础、且能力最强的几个头部模型OpenAI, Anthropic, Google, xAI等。这使得维护更可持续需要跟进的网站数量有限开发者或社区能够更及时地响应变化。体验更精致可以针对每个主流模型进行深度适配和优化比如更好地支持其独有的功能如文件上传、特定按钮。满足核心需求覆盖了90%以上用户90%以上的使用场景。用户不需要在庞杂的模型列表中迷失。这个选择体现了优秀的工程思维在有限资源下解决最普遍、最痛点的问题并把它做到极致。5.2 从更新日志看项目发展项目的更新日志是一部微型的迭代史揭示了维护一个此类项目的真实挑战技术栈升级从纯JavaScript迁移到TypeScript提升了代码的可维护性和开发体验。功能增删添加了LMArena一个模型竞技场后又移除添加了Copilot支持。这反映了在探索功能边界并根据兼容性和用户价值做加减法。移除功能有时比添加功能更需要勇气和判断。健壮性提升增加了“更多上下文的JavaScript注入逻辑”为Grok修复bug增加单元测试。这说明项目在从“能用”向“稳定”迈进。体验优化添加暗黑模式、支持粘贴图片。这些细节虽小但对用户体验的提升是巨大的。生态扩展开始支持macOS和Linux的多平台构建工作流虽然目前以Windows为主但展现了开源项目的包容性。5.3 潜在挑战与可扩展方向使用LLM-God或参与其开发需要意识到一些固有的挑战和未来的可能性挑战网页改版风险这是最大的“阿喀琉斯之踵”。任何一家厂商的前端更新都可能导致注入脚本失效需要及时修复。社区众包式的维护是应对此问题的关键。免费额度限制应用本身不解决各平台的免费额度问题。你仍然需要管理好每个账号的用量。性能与资源占用同时运行多个功能完整的浏览器实例对内存RAM的消耗是显著的。在配置较低的机器上可能感到压力。可扩展方向对话管理目前似乎侧重于单次提问的对比。未来可以增强对话历史管理例如保存某一次多模型对比的完整会话方便回溯。回答聚合分析引入简单的文本分析功能比如自动高亮显示各模型回答中的关键差异点或生成一个对比摘要。本地模型集成虽然与初衷略有偏离但可以作为一个高级插件功能通过调用ollama或lmstudio的本地API将本地运行的模型也加入对比行列。工作流自动化与Zapier、n8n或本地脚本结合将多模型咨询作为自动化流程中的一个环节。LLM-God代表了一种务实而强大的工具哲学不重复造轮子而是用巧妙的“胶水”将最好的轮子组合起来创造一种全新的、高效的体验。它降低了同时利用多个顶级AI模型的门槛将曾经繁琐的操作变得优雅而简单。对于任何重度依赖AI进行工作和创作的人来说它都值得被放入工具箱。而作为一个开源项目它的结构清晰、技术栈主流也为开发者提供了一个学习Electron实战、理解浏览器自动化、以及参与一个有用工具建设的绝佳机会。