1. 项目概述一个开源的AI代码编辑器如果你是一个深度依赖AI辅助编程的开发者对Cursor、GitHub Copilot这类工具爱不释手但又对它们的闭源、数据隐私、高昂订阅费或功能限制感到困扰那么Void的出现可能会让你眼前一亮。简单来说Void是一个开源、可自托管的AI代码编辑器它直接对标Cursor并试图在开放性、隐私控制和模型选择自由度上提供一个更“开发者友好”的替代方案。它的核心卖点非常清晰开源、隐私、模型自由。这意味着你可以完全掌控这个工具。你可以查看它的每一行代码知道它在后台做了什么你可以将它与任何你信任的AI模型API如OpenAI的ChatGPT、Anthropic的Claude甚至是本地部署的Ollama、LM Studio连接数据直接从你的客户端发送到提供商Void本身不保留你的任何代码或对话记录你还可以基于它的代码构建一个完全符合你个人或团队工作流的定制化IDE。我最初关注到Void正是因为它解决了我几个核心痛点。在使用商业AI编程工具时我常常担心敏感的公司代码片段被上传到云端进行分析尽管厂商声称会保护隐私但闭源的黑盒操作总让人心存疑虑。其次模型被绑定在单一提供商有时我想用Claude来审阅设计用GPT-4来生成代码切换起来非常麻烦。Void的出现理论上给了我们一个“鱼与熊掌兼得”的解决方案保留现代AI编辑器的流畅体验同时拿回控制权。不过需要特别注意的是根据项目README的说明Void IDE也就是这个主仓库的开发目前已经暂停。团队将精力转向了探索一些更前沿的编码创意而非仅仅追求与Cursor的功能对齐。这意味着当前版本的Void作为一个产品可能不会再有重大的功能更新或活跃维护一些现有功能随着依赖项的变化可能会逐渐失效。但这绝不意味着它的代码失去了价值。相反对于一个想要深入研究现代IDE架构尤其是想了解如何将AI深度集成到开发环境中的开发者或团队来说这个开源的代码库是一个极其宝贵的参考和起点。你可以基于它构建和维护一个属于你自己的、长期稳定的“Void”版本。2. 核心架构与设计思路拆解要理解Void的价值我们不能只把它看作一个“换了皮的VSCode”。它的核心设计思路是构建一个以AI智能体Agent为第一公民的、模块化且开放的可编程编辑器环境。让我们深入拆解一下它的几个关键设计理念。2.1 基于VSCode的深度定制化之路Void是一个从Microsoft Visual Studio CodeVSCode仓库直接分叉Fork而来的项目。这是一个非常聪明且务实的起点。VSCode本身就是一个优秀的、开源核心编辑器部分的现代化编辑器拥有强大的扩展架构Extension API、成熟的Monaco编辑器内核以及庞大的生态系统。从头构建一个同等水平的编辑器需要耗费巨量的工程资源而分叉VSCode让Void团队能够直接站在巨人的肩膀上。但这不仅仅是简单的分叉。Void的定制化是深度的其目标是将AI能力从“一个强大的扩展”提升为“编辑器的核心基础设施”。在传统的VSCode中Copilot或Cursor的替代品是以扩展的形式存在它们通过VSCode的API与编辑器交互。而在Void的设计中AI智能体的交互、代码变更的可视化与管理、多模型路由等能力被更紧密地集成到了编辑器的UI和工作流中。例如“检查点Checkpoint”和“变更可视化”这类功能可能不再是某个扩展提供的侧边栏视图而是编辑器原生工作区视图的一部分与文件树、源代码管理Git深度整合。这种深度集成带来了更好的用户体验和性能。原生集成的功能可以更直接地访问编辑器的内部状态实现更快的响应和更丰富的交互避免了扩展API可能带来的通信开销和功能限制。对于开发者而言这意味着AI辅助编程的体验会更加无缝和强大。2.2 “AI智能体工作区”的核心范式Void倡导的一个核心概念是“在代码库上使用AI智能体”。这听起来有点抽象我们可以把它理解为一种更结构化、更可追溯的AI协作模式。在普通的AI编程助手中我们的交互模式往往是线性的、对话式的我提出一个问题或指令AI返回一段代码或建议。这种交互的上下文通常局限于当前打开的文件或短暂的对话历史并且一旦对话滚动过去之前的思考和决策过程就难以追溯。Void试图引入的“智能体”范式则更接近于为你的项目配备一个或多个具有特定角色和记忆的AI协作者。你可以想象这样一个场景你为一个复杂的重构任务创建了一个“重构智能体”。这个智能体不仅能看到你当前的代码变更还能访问项目相关的文档、之前的提交历史、甚至特定的开发规范。你与它的所有交互、它提出的建议、你采纳或拒绝的修改都会被系统地记录和可视化。更重要的是Void提到的“检查点Checkpoint”功能允许你在智能体进行一系列代码修改之前和之后保存项目的状态快照。你可以随时回滚到任何一个检查点清晰地看到智能体引入了哪些变化就像使用Git一样管理AI的产出。这种范式将AI从临时的“代码建议器”提升为可管理的“项目协作者”。它使得与AI共同进行长期、复杂的编码任务成为可能并且整个过程是可审计、可控制的。这对于团队协作、代码审查以及确保AI生成的代码符合项目标准至关重要。2.3 隐私优先与模型无关的通信架构这是Void在技术设计上最值得称道的部分也是其区别于大多数商业产品的关键。它的架构严格遵循了“隐私优先”和“模型无关”的原则。隐私优先Void的客户端即你下载运行的编辑器在设计上就是一个“哑终端”。当你使用AI功能时你的代码、提示词Prompt等数据是由Void编辑器直接发送到你配置的AI模型提供商API端点例如api.openai.com或你本地部署的Ollama服务。Void的服务器不中转、不存储、不分析这些数据。整个通信流程可以简化为你的代码 - Void编辑器 - 你配置的API - AI模型 - 响应 - Void编辑器。这最大程度地减少了数据泄露的风险面对于处理敏感代码如商业机密、隐私算法的开发者来说这是一个巨大的安心保障。模型无关Void没有将自己绑定在任何单一的AI模型上。它通过一个抽象的、可配置的“模型提供商”层来工作。理论上只要一个模型服务提供了兼容的API通常是OpenAI API格式或类似的Chat Completion接口你就可以将其配置到Void中使用。这带来了无与伦比的灵活性成本控制你可以选择性价比更高的模型提供商。性能与能力你可以为不同的任务选择不同的模型例如用GPT-4处理复杂逻辑用更便宜的模型处理简单补全。离线与本地化你可以连接本地部署的开源模型如通过Ollama运行的CodeLlama、DeepSeek-Coder等实现完全离线的AI编程彻底杜绝数据外泄。避免供应商锁定你不会因为某个AI服务涨价、变更政策或停止服务而被迫迁移。这种架构要求用户在首次使用时进行一些配置填写API密钥和端点但换来的是完全的控制权和自由度。它代表了AI工具发展的一个健康方向工具本身是开源的、中立的而“智能”的来源可以由用户自主选择。3. 核心功能模块深度解析了解了设计思路我们再来具体看看Void试图实现的几个核心功能模块。虽然主版本开发暂停但这些功能点的设计本身为我们构建自己的AI编辑器提供了清晰的蓝图。3.1 AI智能体的集成与交互模式Void中的AI智能体不仅仅是聊天机器人。它们的集成体现在编辑器的多个交互层面嵌入式聊天与指令类似CursorVoid应该提供了侧边栏或内联的聊天界面。你可以选中代码通过右键菜单或快捷键唤出AI指令进行解释、重构、生成测试等操作。不同之处在于Void可能会允许你为不同的指令预设不同的“智能体角色”或连接不同的模型。例如“生成文档”指令调用配置了特定提示词的Claude“调试代码”指令调用GPT-4。智能体工作区视图这是对传统“聊天面板”的升级。它可能是一个独立的编辑器视图专门用于管理你当前会话中的智能体。在这里你可以看到智能体的“思考过程”如果模型支持查看它建议的代码变更列表并逐个接受、拒绝或修改这些建议。所有交互形成一棵可展开/折叠的对话树便于追溯决策逻辑。代码库范围的智能体这是“在代码库上使用AI智能体”的体现。你可以启动一个针对整个项目或特定目录的智能体会话。智能体可以分析项目结构、读取多个相关文件来理解上下文从而给出更精准的建议。例如你可以指令智能体“为src/utils/目录下的所有工具函数添加JSDoc注释”它会在理解整个工具模块的基础上进行批量操作。实操要点实现这类深度集成关键在于扩展VSCode的Webview API和TreeDataProvider来创建自定义UI视图并利用Language Server Protocol (LSP)或直接操作TextDocumentAPI来让智能体能够理解代码语义、提供代码补全和重构建议。难点在于状态管理——如何保持智能体对话历史、代码变更建议与编辑器实际文档状态的同步。3.2 检查点与变更可视化系统这是一个将“版本控制”思想应用于AI协作的巧妙设计。它解决了“AI改了太多东西出问题了都不知道怎么回退”的痛点。检查点Checkpoint你可以将其理解为项目的“存档点”。在让AI智能体执行一系列可能的大规模更改之前手动或自动创建一个检查点。这个检查点会保存当前工作区所有文件的状态可能通过内置的Git快照或文件系统快照实现。创建检查点的操作应该非常轻量且快速鼓励用户频繁使用。变更可视化当AI智能体运行并产生代码修改建议后Void的UI需要清晰地展示这些变更。这不仅仅是像Git diff那样显示行级别的增删改。更理想的是它能以更语义化的方式呈现结构化视图以文件树的形式展示哪些文件将被修改点击后可以展开查看具体的变更。变更分组将相关的变更例如重命名一个函数并更新所有对其的调用智能地分组在一起方便整体审查和接受。前后对比提供并排或叠加的代码对比视图高亮显示AI修改的部分。变更描述智能体应为每一组变更生成简短的描述解释其意图。回滚与选择式应用基于检查点你可以安全地探索。如果对AI的修改不满意可以一键将整个项目回滚到创建检查点时的状态。更精细的操作是你可以在变更可视化界面中像评审Git Pull Request一样逐个文件、甚至逐个代码块地选择接受或拒绝AI的修改。技术实现思考这个功能很可能深度依赖Git。创建检查点可能等价于执行一个git stash或创建一个临时的提交分支。变更可视化则需要对AI产生的编辑操作如TextEdit数组与当前代码进行diff计算并渲染成友好的GUI。实现难点在于高性能地处理大代码库的快照以及提供流畅的、可交互的diff浏览体验。3.3 多模型路由与本地化部署支持这是Void“模型无关”架构的具体体现。其核心是一个可配置的模型路由层。提供商配置管理Void需要提供一个用户友好的设置界面让用户可以添加多个AI模型提供商。每个提供商的配置包括提供商类型OpenAI、Anthropic、Ollama本地、LM Studio、或其他兼容API的自定义端点。API端点Endpoint如https://api.openai.com/v1或http://localhost:11434/v1。API密钥对于需要鉴权的云服务。默认模型如gpt-4-turbo-preview、claude-3-sonnet-20240229、codellama:7b。其他参数如请求超时时间、自定义请求头等。路由策略用户可以定义路由规则。例如基于指令的路由“/doc” 指令路由到Claude“/refactor” 路由到GPT-4。基于成本/性能的路由简单的代码补全请求路由到更便宜、更快的模型如GPT-3.5-Turbo复杂的架构问题路由到能力更强但更贵的模型如GPT-4。故障转移当主提供商不可用时自动切换到备用提供商。本地模型集成对本地部署模型如通过Ollama的支持至关重要。这通常意味着自动检测本地Ollama服务是否运行。动态拉取并列出本地可用的模型列表。处理与本地API通常是非HTTPS、本地主机的通信。提供性能提示如“本地模型响应可能较慢”。实操心得在实现这个系统时一个关键的设计是定义一个统一的、内部的“模型请求接口”。所有编辑器内的AI功能都向这个内部接口发送请求然后由一个“路由管理器”根据配置将请求转换为对应提供商API的实际格式OpenAI格式、Anthropic格式等并处理响应和错误。这样新增一个提供商只需要实现一个格式转换适配器而无需修改上层业务逻辑。同时必须做好API密钥等敏感信息的安全存储通常使用编辑器内置的密钥管理机制如VSCode的keytar。4. 从源码到可执行文件构建与部署实践虽然Void IDE的官方构建可能已暂停但其代码库和构建工具void-builder仍然为我们提供了完整的、可复现的构建流程。这对于想要自己维护一个版本或进行二次开发的开发者来说是必不可少的步骤。下面我将基于开源项目的通用实践和Void提供的线索拆解一个典型的构建与部署流程。4.1 开发环境准备与依赖安装构建一个像Void这样基于VSCode的大型桌面应用需要一个配置得当的开发环境。以下是核心步骤系统与工具链操作系统推荐使用Linux如Ubuntu 20.04或 macOS 进行开发。Windows也可行但可能在某些原生模块编译时遇到更多问题。Node.js与npm/yarn这是VSCode生态的核心。你需要安装指定版本的Node.js通常LTS版本如18.x或20.x。Void的package.json或构建文档中会明确要求。同时安装yarn包管理器VSCode项目通常使用yarn而非npm。Git用于克隆代码和版本管理。Python某些Node.js原生模块的构建可能需要Python 2.x或3.x。通常需要安装python3和pip。C构建工具在Linux上需要build-essential在macOS上需要Xcode Command Line Tools在Windows上需要Visual Studio Build Tools或类似环境。这是为了编译node-gyp相关的原生依赖。获取源代码git clone https://github.com/voideditor/void.git cd void克隆后仔细阅读项目根目录下的README.md、CONTRIBUTING.md如果有以及项目特别指出的VOID_CODEBASE_GUIDE.md和HOW_TO_CONTRIBUTE.md。这些文件包含了项目结构、代码指南和最重要的构建说明。安装项目依赖yarn install这个过程可能会花费较长时间因为它需要下载数百个JavaScript依赖并可能编译一些原生模块如keytar、spdlog等。确保网络通畅并注意终端是否有错误输出。常见的错误是缺少上述的系统级构建工具。注意事项如果遇到与特定原生模块相关的构建失败首先检查错误日志通常它会提示缺少哪个库如libsecret。在Ubuntu上你可以用apt-get install libsecret-1-dev来安装在macOS上可能需要brew install相应的库。永远优先参考项目自身的issue或文档来解决依赖问题。4.2 利用void-builder进行编译与打包Void项目提到了一个独立的仓库void-builder。这很可能是一个封装了复杂构建逻辑的工具用于将源代码编译成各个平台Windows、macOS、Linux的可执行文件。使用专门的builder是大型桌面应用的常见做法它可以处理代码签名、打包优化、生成安装程序等繁琐任务。理解构建流程 典型的VSCode派生项目的构建分为两步编译Compile将TypeScript/JavaScript源代码转译、打包并处理资源文件。这通常通过项目内的gulp或webpack脚本完成。打包Package将编译后的产物与Electron运行时一起打包成对应平台的格式如macOS的.appWindows的.exe安装包Linux的.deb/.rpm/AppImage。void-builder很可能自动化了这两步。你需要查阅void-builder仓库的README来获取具体的命令。执行构建 假设在void-builder目录下常见的命令模式可能是# 安装builder的依赖 npm install # 构建特定平台的版本 npm run build -- --platformwin32-x64 # 或 npm run build -- --platformdarwin-x64 # 或 npm run build -- --platformlinux-x64构建过程会从Void主仓库拉取代码或使用本地路径执行编译然后调用electron-builder或类似工具进行打包。输出结果通常在dist或release目录下。开发模式运行 在深入修改代码时你不需要每次都进行完整打包。可以使用开发模式快速启动应用进行测试# 在Void主目录下 yarn run watch # 启动TypeScript编译的监听模式 # 另开一个终端 yarn run electron . # 使用Electron运行当前开发中的代码这会将你修改的代码实时编译并加载到Electron窗口中极大提升开发效率。实操心得构建大型Electron应用最耗时的部分往往是下载Electron二进制文件和编译原生模块。建议在首次构建时保持耐心并确保有稳定的网络连接。如果是为了长期开发可以考虑配置本地的npm镜像如淘宝镜像来加速依赖下载。另外仔细阅读void-builder的配置脚本如electron-builder.yml你可以在那里自定义应用名称、图标、版权信息、打包的架构x64/arm64等。4.3 自定义配置与功能裁剪开源的最大优势在于你可以按需定制。基于Void的代码你可以进行多种个性化改造修改品牌与外观应用名称与图标在product.json和构建配置文件中修改name、displayName等字段。替换resources目录下的图标文件各种尺寸的.ico,.icns,.png。主题与UIVSCode/Void的UI由CSS和HTML定义。你可以修改src/vs/workbench下的相关CSS文件或者创建自定义的颜色主题、文件图标主题扩展来改变外观。集成自定义AI模型/服务 这是Void的核心扩展点。假设你想集成一个公司内部的AI编码服务。第一步研究现有提供商实现。查看src/vs/workbench/contrib/chat/或类似目录下的代码找到模型提供商如OpenAIProvider的实现类。它会有一个sendRequest方法负责将内部请求格式转换为特定的API调用。第二步创建新的Provider类。仿照现有实现创建一个YourCompanyAIProvider。你需要实现模型列表获取、请求格式组装、响应解析、错误处理等逻辑。第三步注册Provider。在相应的注册点可能是extension.ts或一个提供商注册表将你的新Provider添加进去并赋予一个唯一的ID如your-company。第四步更新配置界面。修改设置UI的代码让用户可以在下拉菜单中看到并选择“YourCompany AI”并填写对应的端点URL和API密钥字段。功能启用/禁用 你可能不需要Void的所有功能。可以通过修改代码来禁用某些模块。在product.json中有一个extensionEnabledProposedApi或disabledExtensions的配置可以控制内置扩展的加载。直接注释掉或移除某些功能模块的入口点代码。例如如果你不需要内置的某种代码可视化工具可以找到其对应的Contribution类通常以*Contribution命名并移除其注册。注意功能裁剪需要你对代码结构有一定了解盲目删除可能导致应用无法启动。最好的方法是先通过配置禁用确认无误后再考虑代码级移除。重要提示在进行任何自定义之前务必确保你理解所修改部分在整体架构中的位置。建议从一个小的、独立的修改开始比如改个欢迎文本逐步熟悉整个项目的构建、运行和调试流程。充分利用VSCode/Void自带的强大的TypeScript和JavaScript调试能力。5. 开源协作与社区维护指南参与或主导一个像Void这样的开源项目尤其是在其官方开发“暂停”但代码开源的阶段需要一种不同的心态和策略。这更像是一次“代码考古”和“社区驱动复兴”的实践。5.1 理解项目状态与可持续性策略首先我们必须清醒地认识到项目README中声明的状态“已暂停工作”。这意味着没有主动的功能开发不会有新特性从官方团队加入。有限的维护严重的、阻碍构建或运行的Bug可能会被处理通过邮件但小问题、改进建议可能不会得到响应。依赖过时风险随着时间推移项目的依赖Node.js版本、npm包、Electron版本会变得陈旧可能导致安全漏洞或与新系统不兼容。这是最大的长期风险。因此如果你打算长期使用或基于Void进行开发你需要制定一个可持续性策略分叉Fork与独立维护最直接的方式是在GitHub上Forkvoideditor/void仓库到你的个人或组织名下。这样你就有了一个完全由你控制的代码副本。你可以为其建立新的问题追踪Issues、拉取请求Pull Requests和项目看板。定期依赖更新将依赖更新作为一项定期任务。使用yarn upgrade-interactive或npm outdated配合npm update来更新依赖。但务必谨慎一次更新所有依赖是危险的容易引入不兼容的变更。建议逐个或按组更新每次更新后都运行完整的测试套件如果有和构建流程确保核心功能正常。关注上游VSCode更新Void基于特定版本的VSCode。Microsoft的VSCode团队会持续修复Bug和安全问题。虽然直接合并VSCode上游的变更非常复杂因为Void有自己的大量修改但你可以定期查看VSCode的更新日志Changelog对于关键的安全修复可以尝试手动将相关代码变更移植到你的Void分支中。这是一个高难度的操作需要深厚的代码理解能力。建立社区如果你希望你的分叉版本能吸引其他贡献者就需要主动建设社区。维护清晰的文档、对新手友好的Issue模板、积极审查PR。项目原Discord服务器可能仍有活跃用户可以在那里宣传你的维护分支并吸引志同道合者。5.2 问题排查与调试实战记录在构建、运行或修改Void的过程中你一定会遇到各种问题。以下是一些常见场景的排查思路问题一构建失败错误信息指向某个原生模块如keytar,native-watchdog。排查思路检查系统构建工具这是最常见的原因。确保已安装完整的C编译环境如前文所述。在Linux上错误信息常会提示缺少libxxx-dev包。检查Python版本某些原生模块需要特定版本的Python。尝试设置npm_config_python环境变量指向正确的Python解释器如export npm_config_pythonpython3。清理并重试删除node_modules文件夹和yarn.lock文件然后重新运行yarn install。有时旧的缓存会导致问题。查看具体模块的构建日志构建输出通常很长找到失败的那个模块的具体错误。将其复制到搜索引擎中大概率能在Stack Overflow或该模块的GitHub issue中找到解决方案。问题二开发模式运行后编辑器界面空白或功能异常。排查思路检查开发者工具在Electron窗口中按CtrlShiftI(或CmdOptIon Mac) 打开开发者工具。查看“控制台(Console)”和“网络(Network)”标签页是否有红色的错误信息。JavaScript错误会直接打印在控制台是定位问题的第一手资料。检查主进程日志Electron应用分为主进程和渲染进程。一些启动阶段的错误可能只在主进程的控制台输出。你需要查看启动yarn run electron .的那个终端窗口的输出。确认编译是否成功确保yarn run watch进程正在运行且没有编译错误。TypeScript编译错误会阻止新代码被正确加载。检查扩展加载Void/VSCode的许多功能由内置扩展提供。在开发者工具的“源代码(Sources)”中查看是否成功加载了file://协议下的各种.js文件。如果某些关键文件404说明编译或资源路径有问题。问题三配置了AI模型API但聊天或补全功能无响应。排查思路网络与端点检查首先确认你的网络可以访问你配置的API端点。对于本地模型如Ollama确认服务是否在运行curl http://localhost:11434/api/tags。查看开发者工具网络请求在AI功能触发时打开开发者工具的“网络(Network)”标签页过滤XHR/Fetch请求。你应该能看到向配置的API端点发起的请求。查看请求的URL、头部和载荷是否正确以及响应是什么。401错误代表API密钥错误404代表端点路径不对502代表服务内部错误。检查编辑器日志Void可能会将AI相关的错误日志输出到特定的日志通道。在VSCode/Void中可以通过“命令面板(CtrlShiftP)”输入“Toggle Developer Tools”或者查看输出面板Output中名为“Log (Extension Host)”或“AI Provider”的日志。验证API格式确保你配置的端点返回的响应格式符合Void的预期通常是OpenAI的ChatCompletion格式。对于非标准API你可能需要自己编写或调整Provider的响应解析逻辑。5.3 贡献代码与社区互动建议即使官方不活跃向开源项目贡献代码依然是一种有价值的学习和分享方式。如果你的修改具有通用性甚至可以尝试向原仓库提交PR万一被接受了呢贡献流程Fork CloneFork原仓库克隆到你本地。创建特性分支永远不要在main分支上直接修改。为每个新功能或Bug修复创建一个清晰命名的分支如feat/add-azure-openai-support或fix/build-error-on-node-20。遵循代码规范仔细阅读项目的VOID_CODEBASE_GUIDE.md。观察现有代码的缩进、命名、注释风格并保持一致。VSCode系的代码通常有严格的编码规范。提交与推送进行小的、逻辑清晰的提交并编写有意义的提交信息。推送你的分支到你的Fork。创建Pull Request (PR)在你的Fork的GitHub页面上发起向原voideditor/void仓库main分支的PR。在PR描述中清晰地说明你修改了什么、为什么修改、以及如何测试。提高PR被接受的概率范围要小一个PR只解决一个问题或添加一个功能。巨大的、包含多项不相关修改的PR很难被评审。描述要清晰使用“做了什么”、“为什么做”、“影响的模块”等结构。如果修复Bug最好附上复现步骤和修复后的验证方法。关联Issue如果存在相关的GitHub Issue在PR描述中通过#123的方式关联它。管理好期望鉴于项目状态你的PR可能长时间得不到回复。不要气馁你的主要收获在于这个过程本身——你深入理解了代码并创造了一个可被他人复用的修改。即使PR未被合并你也可以在自己的Fork中享受这个改进。社区互动Discord加入项目Discord在合适的频道提问或分享你的进展。这里可能聚集着同样在使用或研究Void的开发者。GitHub Issues在提出问题前先搜索是否已有类似问题。提Issue时提供尽可能多的信息环境、复现步骤、错误日志、期望行为等。邮件如项目所述对于构建和维护自己版本的问题可以发送邮件到hellovoideditor.com。这是一种更直接但异步的沟通方式。维护一个“暂停”状态的开源项目分支更像是一场马拉松而非冲刺。它考验的是你的耐心、自主学习能力和系统工程能力。但回报也是丰厚的你将获得一个完全按你心意打造的、隐私安全的、功能强大的AI编程环境并对现代IDE的构造有前所未有的深刻理解。这本身就是一项值得投入的、极有成就感的技术实践。