s-blog

用 AI 从 0 到 1 构建一个 Electron 研发工作台

从三进程边界到自动审查、MCP 与复杂系统适配

ssssmy · 2026-07-24 · 6 min · Electron

用 AI 从 0 到 1 构建一个 Electron 研发工作台

这个项目最初只是一个“把代码 diff 交给大模型审查”的想法，后来逐步扩展为包含代码审查、合并请求、多项目构建、企业机器人、缺陷协作、OA 报工和团队统计的桌面应用。

技术栈以 Electron、Vue 3 和 TypeScript strict mode 为核心。本文复盘其中最关键的架构选择与工程化细节；产品名称、内网地址、凭据、组织名称、项目数据和人员信息均已脱敏。

1. 用三进程边界控制桌面能力

Vue Renderer
    ↓ window.api
Preload / contextBridge
    ↓ ipcRenderer.invoke
Main Process
    ├─ REST / OA / Metrics
    ├─ AI CLI / MCP
    ├─ Build CLI / SFTP
    └─ WebSocket / Local Server

Renderer 只负责交互和响应式状态。文件系统、网络凭据、子进程和系统 API 全部留在主进程；Preload 是唯一桥梁，并保持 contextIsolation: true、nodeIntegration: false。

项目有一百余个 IPC handler。新增通道时必须同步修改主进程 handler、Preload 暴露和 Renderer API 类型。Vue reactive proxy 不能直接跨 IPC，所以复杂表单发送前要转换为普通对象。主进程统一返回 { success, data, error }，页面无需理解不同后端模块的异常形态。

2. AI 审查是一条流水线

一次审查包含以下步骤：

  1. 获取 Commit 或分支比较结果。
  2. 按文件拆分 unified diff，过滤空 diff 和删除文件。
  3. 根据扩展名识别语言，构造要求严格 JSON 输出的提示词。
  4. 通过队列限制并发，避免同时启动过多 CLI 进程。
  5. 将模型输出解析为严重程度、类别、文件、行号和修改建议。
  6. 单个文件失败时保留其他成功结果。
  7. 通过 IPC 推送进度，最终保存历史或回写代码托管平台。

多个 AI 引擎共用统一的 ReviewEngine 抽象。Prompt 通过 stdin 输入，避免 Windows 命令行长度限制；代理通过子进程环境变量传递。JSON 语法解析失败时会重试一次，取消操作则停止队列中尚未开始的任务。

3. 从手动审查到自动 MR 闭环

后台轮询发现新 MR 后，会刷新页面并触发一条独立的自动化链路：

发现新 MR
  ├─ 文件级 AI 审查
  ├─ 提交信息与 diff 匹配检查
  └─ 汇合结果
       → 回写 MR 评论
       → 保存审查历史
       → 按标签通知会话
       → 可选创建严重缺陷

提交检查与代码审查并行执行，避免串行增加等待时间。自动审查使用独立队列和互斥状态，防止多个轮询周期重复启动。对于模型暂时不可用的语义评分，采用 fail-open；提交格式仍可单独展示，避免外部工具抖动影响正常协作。

4. 复查不是重新跑一遍 diff

审查历史保存了问题、文件和代码引用。当开发者修复后，复查流程会重新获取目标分支上的最新完整文件，再把原问题与当前代码一起交给模型，输出：

  • fixed：已修复
  • not_fixed：未修复
  • partial：部分修复
  • unknown：无法确定

批量复查使用可配置并发数，并独立记录每条问题的结果。全部问题确认修复后，历史记录可自动归档；复查结论也可以再次推送给协作群组。

5. 构建系统复用 CLI

桌面端没有重写已有构建能力，而是生成临时配置和分支配置，然后调用构建 CLI。用户可以选择工作区、环境、版本、分支配置档、CPU 数量和子项目。

主进程把 stdout/stderr 转换为 Git 同步、依赖安装、编译、复制、打包和上传等实时阶段。Windows 输出按本地编码解码，ANSI 控制字符会被清理。高频日志先缓冲，再按约 200 ms 批量推送，避免 IPC 风暴。

构建支持超时、取消和进程树清理；结束后仅保存必要的日志片段，并触发历史记录与通知。CLI 本身也有可用性检查和版本更新入口。

6. 多机器人 WebSocket 如何管理

企业机器人不是一次性 Webhook，而是 WebSocket 长连接。每个机器人实例独立维护连接、订阅状态、已知会话和事件监听器，管理层再提供统一的发送与标签路由能力。

协议请求使用唯一请求 ID 关联响应，并设置超时；连接包含心跳、断线清理和重连。收到消息后，系统识别私聊与群聊、更新会话信息，再转发给页面和局域网客户端。模板卡片事件可以驱动查看详情、确认操作等交互，而不只是发送文本通知。

7. MCP 隔离缺陷系统协议

应用本身作为 stdio MCP 客户端启动和管理外部服务，通过标准工具调用查询项目、获取缺陷、评论和创建缺陷。客户端处理初始化、工具发现、错误归一、进程重启与退出清理。

这种设计让桌面端专注于业务编排，而不是再维护一套缺陷系统协议。同时，设置页还可以检查、安装、移除和测试 AI CLI 使用的 MCP 服务。

8. 复杂 OA 表单的动态适配

OA 报工并不是普通 REST CRUD。客户端需要维持 Cookie 会话，并依次处理列表数据、表单元信息、明细数据和提交操作。

创建草稿前必须重新加载表单，取得当前流程、节点、表单 ID、防重 Token 和一次性签名。流程升级后，旧入口可能重定向到新的工作流，因此提交时不能写死流程信息；明细字段也要从实际表单结构中识别。多天报工会被展开成多条明细，再根据真实内容计算必填字段和非空数量。

日历侧将 OA 记录与工作日、节假日和调休日合并，帮助用户发现缺报日期，而不是只展示已有数据。

9. 外部系统都放在适配层

  • 代码托管客户端处理分页、分组过滤、旧版本兼容、超时和统一错误。
  • 统计模块先发现时序数据源，再并行执行查询并按用户聚合。
  • 本地服务提供健康状态、通知接收和 WebSocket 消息转发。
  • Excel 导出读取标准模板，回拉代码上下文，并计算审查行数、文件数和缺陷指标。
  • 版本化 JSON 备份允许按配置、会话、审查历史和构建历史分类恢复。

这些差异都停留在主进程模块内部，页面只调用稳定的业务接口。

10. 状态、持久化与生命周期

配置和历史保存在 Electron userData 目录。部分核心凭据优先使用 safeStorage 加密；旧格式通过兼容逻辑迁移。审查历史和构建历史设置数量上限，避免桌面应用长期运行后无限增长。

应用使用 keep-alive 保留页面状态，因此页面刷新放在 onActivated，事件解绑放在 onDeactivated。启动时依次恢复连接并启动用户已启用的轮询、报告和局域网服务；退出时停止定时任务，并等待 MCP 子进程清理，避免留下孤儿进程。

11. AI 真正适合做什么

AI 很适合加速样板代码、类型定义、界面组合、错误定位和文档整理，但它不知道真实业务，也容易猜测接口。我的协作流程逐渐固定为：

  1. 先搜索现有接口、类型和调用链。
  2. 由人确认业务含义、失败策略和安全边界。
  3. 在现有架构内完成最小改动。
  4. 检查 IPC、类型、持久化和界面是否同步。
  5. 运行完整构建，用真实错误继续收敛。
  6. 把踩坑记录成下一轮开发约束。

最大的经验是：AI 可以快速写出代码，但项目能够持续演进，依赖的是清晰边界、统一约定、主动验证和人的判断。AI 不是工程方法的替代品，而是工程能力的放大器。

原文链接：https://www.ssssmy.com/blog/ai-build-electron-rd-workbench