笑技做类似 VS Code 的 AI 编辑器，看起来是个挺火的选题，尤其最近 Claude Code、Codex 这类工具接连出现，大家开始重新思考“编辑器”这个东西到底应该长什么样。我最近带着团队完整走了一遍这个方向的技术预研和原型搭建，踩了不少坑，也理清了一些关键取舍。这篇文章把我们的技术方案、选型理由和踩坑记录整理出来，希望能给正在做类似产品的朋友一些参考。
先交代一下我这个项目背景：不是要魔改 VS Code，而是从技术层面低成本构建一个“长得像 VS Code、用起来像 VS Code、但 AI 能力是原生核心”的编辑器。目标用户是开发者，核心场景是代码编写、重构、AI 对话补全、批量代码修改。所以整个技术方案必须解决三件事：编辑器内核怎么选、AI 能力怎么接、插件生态要不要做。
1. 整体设计思路：到底在什么基础上做
1.1 三条路线：fork、套壳、自研内核
做类似 VS Code 的编辑器，第一个要拍板的问题就是“从哪里开始”。市面上常见路线有三条，各有利弊。
第一条是直接 fork VS Code 开源仓库。这条路最“重”，VS Code 的代码量非常大，而且微软的源码迭代节奏很快，长期维护成本极高。但如果你的产品需要深度兼容 VS Code 插件生态，fork 可能是唯一选择——毕竟 VS Code 的插件 API 只有和源码绑定才最好用。Coder 家做的 code-server 就是这条路。
第二条是套壳。这里分两层意思：一层是用 Electron/Tauri 包一层，里面直接嵌入 VS Code 的 Web 版（Monaco Editor + VS Code 的 Web extension host）；另一层是把开源编辑器内核（比如 Monaco Editor、CodeMirror 6）嵌到自己的壳里，再自己实现文件管理、终端、Git 等功能。对大多数创业团队来说，第二条的后者更实际，因为不需要维护整棵 VS Code 源码树，又能保留编辑器核心体验。
第三条是自研内核，比如用 Zed 那套 Rust + GPUI 的做法。这条路性能和体验上限最高，但工程量巨大，没有大团队和长时间的打磨基本做不出来。Zed 从 2022 年做到 2024 年才有比较可用的版本，普通人最好别碰。
我最终选的是“Monaco Editor + 自研壳 + 原生 AI 能力层”的组合。理由很简单：Monaco 就是 VS Code 的编辑器组件，它的代码高亮、智能提示、多光标、Diff 视图、断点调试 UI 全是现成的，等于把 VS Code 最核心的交互底座搬过来了。而且 Monaco 不依赖 Node 环境，可以跑在浏览器里，这对未来做 Web IDE、远程开发都留了后路。
1.2 核心需求拆解：你的 AI 编辑器要解决什么
动手之前，必须把 AI 编辑器的“AI”到底体现在哪些功能上定义清楚。我们把需求拆成了四层：
第一层是代码补全。这已经是最常规的能力，比如在光标处自动续写代码。技术实现上通常用 FIM（Fill-In-Middle）模型或标准对话模型加后缀约束，关键是延迟要低，通常要求首字延迟在 200ms 以内，否则体验直接崩。
第二层是对话式修改。也就是用户选中一段代码，在侧边栏或者浮窗里跟 AI 对话，AI 给出一段修改后的代码，用户点一下应用。这一层技术上不复杂，核心是要做安全的 Diff 合并，以及处理代码行号变化、未保存修改、多个文件交叉修改等边界情况。
第三层是 Agent 式编辑。用户说一句“把登录接口的错误处理逻辑统一”，AI 自动读文件、改代码、跑搜索、做多文件批量修改。这层最复杂，需要扩展系统、上下文管理、工具调用能力和代码操作 API 完整打通。Claude Code、Codex 做的事就是这个方向。
第四层是项目级理解。跳转定义、查找引用、全局重命名等传统 IDE 功能要做，同时还要建立代码索引和语义向量库，让 AI 能回答“这个项目的登录流程是怎样的”这类问题。
这四个层次对应到架构设计上，就决定了你的 AI 能力层不能是“加一个按钮调一下 API”的简单集成，而是要从底层数据结构开始支持代码语义和增量更新。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 编辑器内核与 UI 框架选型
2.1 Monaco Editor 还是 CodeMirror 6
Monaco 和 CodeMirror 6 是当前最主流的两个开源编辑器内核，选择直接影响后续开发效率。
Monaco 是 VS Code 的编辑器组件，最大的优势是“功能开箱即用”：代码高亮支持的语言多、缩进引导线、小地图、多光标、查找替换、Diff 编辑器、代码折叠、括号匹配全都有。而且它和 VS Code 的交互习惯完全一致，用户上手成本极低。缺点是包体积大（gzip 后约 3MB 起）、性能上限一般、对 React/Vue 的深度集成需要额外封装。
CodeMirror 6 是极简主义的新内核，模块化做得非常好，按需加载后体积可以控制在几百 KB。它的性能非常强，对大文件的支持比 Monaco 优秀，而且对自定义行为的扩展性更好——如果你想做类似 AI 流式渲染这种特殊交互，CodeMirror 6 的 decoration 机制更灵活。但问题是，你需要自己实现的东西很多，语言支持、智能提示、折叠等功能都要自己拼。
我之前做过一个对比评测，用同一个 5 万行的 JS 文件做滚动和编辑测试，CodeMirror 6 的流畅度明显好于 Monaco。如果你做的是“轻量级 AI 编辑器”，且目标不是跟 VS Code 的体验完全对齐，CodeMirror 6 是更好的选择。但我们最终选了 Monaco，因为我们的目标用户是 VS Code 迁移者，UI 交互习惯的一致性是第一位的，而且我们的技术团队对于 Monaco 的熟悉度更高，后续修改成本更可控。
2.2 桌面壳：Electron 还是 Tauri
做桌面版就绕不开 Electron 和 Tauri 的选择。
Electron 是 VS Code 同款方案，生态极其成熟。Chromium + Node.js 的组合让前端技术栈无缝迁移，JavaScript 可以直接访问文件系统、启动子进程、调用系统 API。缺点众所周知：包体积 100MB 起步、内存占用高、启动慢。但对编辑器这个场景来说，这些缺点不致命，因为用户已经习惯了 VS Code 的体量，没有人会要求编辑器像记事本一样瞬间启动。
Tauri 是 Rust 做的轻量壳，用系统 WebView 渲染，包体积能压到 10MB 以内，内存表现也好很多。但 Tauri 有它的坑：系统 WebView 在不同平台的行为不一致（Windows 的 WebView2、macOS 的 WKWebView、Linux 的 WebKitGTK），这就导致很多前端功能要做平台适配。而且 Tauri 的前端和后端通信走的是 IPC，涉及大文件读写、频繁缓冲区传递时性能损耗比较大，对编辑器这种高频 IO 场景不友好。
我们最终选了 Electron，核心原因有两个：一是 Monaco 在 Electron 里跑是验证过的组合，VS Code 已经证明这条路靠谱；二是插件系统如果要支持 Node 生态，Electron 的 Node 集成是天然的，不需要额外做桥接层。后期如果性能有硬指标，再考虑用 Tauri 重写壳层，编辑器核心和通信协议都提前做了抽象，替换成本可控。
2.3 富文本编辑器的场景需要吗
有一个点容易被忽视——AI 编辑器不只是写代码，很多场景下还需要写 Markdown、写 API 文档、做代码评审注释。这里就涉及到富文本编辑器的集成问题。热搜里有个词是“wangeditor 集成 AI”，这个确实是很多团队做内部工具时踩过的坑。
wangeditor 是一款国内常用的富文本编辑器，因为它开箱即用、中文文档友好，很多团队会优先考虑它。但你要清楚，富文本编辑器和代码编辑器完全不是一个技术生态。wangeditor 的底层是 contenteditable，它内部维护的是一棵 DOM 树，而 Monaco 维护的是基于行的文本模型。这两个东西本质上是两套世界，集成时不能用“一个页面里嵌两个编辑器”的思路，而要做一个“统一文档模型层”，把代码块、Markdown 文本、富文本内容统一映射成一种结构化的文档格式。
我们的方案是在文档模型层定义了 note 类型，内部用 ProseMirror 管理富文本内容，代码块则内嵌 Monaco 实例。AI 对话可以基于整个文档上下文进行，用户选中普通文本或代码块都能发起 AI 操作。这个设计一开始就把 wangeditor 排除掉了，因为它的生态系统比较封闭，做深度定制很难，特别是 AI 生成内容需要以流式方式持续更新编辑器内容时，wangeditor 的性能和 API 都撑不住。
3. 核心架构设计：让 AI 能力从底层就位
3.1 进程与线程模型
我们参考 VS Code 做了四层进程模型：主进程（Main Process）、渲染进程（Renderer Process）、插件进程（Extension Host Process）、以及语言服务器/终端等附属子进程。
主进程负责窗口管理、菜单、系统对话框、全局快捷键，同时持有文件系统访问句柄。渲染进程跑 Monaco 实例和整个 UI。插件进程负责执行第三方插件代码，避免插件崩溃导致整个界面卡死。AI 服务层单独跑一个子进程，负责模型调用、上下文管理、流式响应解析和代码补全后处理。
这个分离很重要。如果你把 AI 调用放在渲染进程里，模型请求的耗时很容易把 UI 线程拖住，输出流式 token 时界面会一直卡顿。我们实测过，在渲染进程直接 fetch 流式接口，UI 的输入响应延迟会从 30ms 飙升到 300ms 以上，完全不可接受。放到独立进程后，UI 卡顿问题彻底消失。
进程间通信我们统一走 JSON-RPC 协议，数据格式和接口定义完全和后端无关。这意味着未来可以把插件进程和 AI 服务层迁移到远程主机上，实现类似 VS Code Remote 的远程开发模式。
3.2 文档模型与同步机制
编辑器的核心数据结构是文档模型。VS Code 的文档模型是“单文件文本缓冲 + 行级索引 + undo 栈”，所有光标、选择、编辑操作都基于模型进行。我们的设计基本沿用这个思路，但针对 AI 场景增加了几个扩展：
第一个是增量 token 流写入。AI 生成代码是流式的，你不能等整段代码生成完再一次性写入编辑器，而是要把流式 token 直接拼接到文档模型上。这要求文档模型支持 hight-frequency 的 append 操作，并且每次更新后要通知渲染层更新视图。Monaco 的这个能力很强，它的 buffer 更新和 view 更新是异步批处理的，实测写入 500 tokens 时界面依然流畅。
第二个是并发修改冲突检测。用户可能在 AI 生成代码的同时手动编辑同一段内容，或者多个 AI 请求同时改同一个文件。我们为每个编辑操作生成一个基于版本的增量补丁，统一走一个“操作合并器”，冲突时拒绝后到的修改并抛出冲突提示。
第三个是文件级快照。AI 做批量修改前，我们会为涉及的文件创建内存快照，修改完成后允许用户一键对比、撤销或应用全部。这一步不能省，我们见过太多用户因为 AI 改错代码，又没法批量回滚，最后只能痛苦地手动恢复。
3.3 代码语义数据层
AI 编辑器要理解代码，不能只把源码当一个文本串喂给模型，还得有结构化的语义数据。我们搭建了一个索引层，用 Tree-sitter 解析各种语言的 AST，提取函数、类、变量、调用关系、引用关系，同时增量更新到本地 SQLite 数据库。此外，对每个代码片段计算语义向量，用本地向量库存储，用于相似度检索和“这个功能在别的文件里怎么写的”这类查询。
这个数据层作用很大。第一，它可以实现“代码库问答”能力。第二，它能为 AI 上下文选择提供依据——当用户让 AI 修改一个函数时，系统能自动找到这个函数被哪些地方调用、依赖哪些模块，然后把相关信息附加到 prompt 里，大幅提升生成质量。
这里要注意的是增量更新的时效性。我们用文件监听 + 防抖策略，文件变更后 500ms 内更新语法树和向量索引，确保 AI 感知到的代码状态始终和文件实际内容一致。如果用了旧索引，AI 生成的代码极容易引用不存在的函数，体验非常糟糕。
3.4 扩展系统与 AI 工具调用
做 VS Code 类似的编辑器，插件生态不能完全放弃。因为你的早期用户大概率是从 VS Code 迁移过来的，如果他们的语言插件、主题、快捷键预设全不能用，迁移率会很惨。
完全兼容 VS Code 插件 API 是大工程，我们评估之后决定做一个“轻量兼容层”：先实现 VS Code 插件 API 的子集，覆盖大多数常用插件的核心能力——比如语言配置、快捷键绑定、命令注册、状态栏、诊断信息。具体做法是在 Extension Host 进程里实现一套 TypeScript 接口，然后做一层适配，把 VS Code 的 API 调用映射到我们自己的编辑器核心。
AI 工具这边我们做的是“插件注册工具 + Agent 调用工具”的模式。任何插件（包括我们内置的 AI 插件）都可以向系统注册 custom tool，比如“读取文件”“搜索代码库”“运行测试”“打开浏览器预览”。AI Agent 在生成回复时，会先产出一段结构化工具调用指令，由扩展系统执行，并把执行结果作为上下文继续生成。这套机制和 Claude 的 function calling / tool use 模式很像，好处是 AI 能力可以通过插件无限扩展。
4. 实操过程：从零搭一个最小可用的 AI 编辑器原型
4.1 环境搭建与工程初始化
先说结论：整个过程可以用 VS Code 本身来开发我们的 AI 编辑器，这是个挺有意思的“自举”体验。
工程使用 pnpm + monorepo 结构，分 packages/core（编辑器核心）、packages/shell（Electron 壳）、packages/ext-host（扩展宿主）、packages/ai（AI 服务）。技术栈选 TypeScript + React + Vite，UI 组件基本手写，因为编辑器需要的是高度自定义的布局，用现成组件库包出来的效果一眼假。
初始化步骤：
bash复制# 创建 monorepo 根目录
mkdir ai-editor && cd ai-editor
pnpm init
# 安装核心依赖
pnpm add monaco-editor react react-dom electron typescript
# 安装 Monaco 的 TypeScript 语言支持
pnpm add @monaco-editor/react monaco-editor-textmate onigasm
# 初始化 Vite 工程
pnpm create vite@latest renderer --template react-ts
这里要提醒一个坑：monaco-editor 的 worker 加载方式。默认情况下 Monaco 需要通过 MonacoEnvironment.getWorker 注册 Web Worker，否则智能提示和语法高亮都会失效。如果你用 Vite，需要同时配置 monaco-editor 的 worker 路径和 vite-plugin-monaco-editor 这个插件，否则打包后会报找不到 worker 的错误。
4.2 实现一个带语法高亮的最小编辑器
核心逻辑是创建一个 React 组件，挂载 Monaco 编辑器实例，然后监听内容变更。
tsx复制import Editor, { OnMount } from '@monaco-editor/react';
export default function CodeEditor() {
const handleMount: OnMount = (editor, monaco) => {
// 语言配置：注册一个简单的自定义语言
monaco.languages.register({ id: 'mylang', extensions: ['.foo'] });
monaco.languages.setMonarchTokensProvider('mylang', {
tokenizer: {
root: [
[/[a-zA-Z_]\w*/, 'identifier'],
[/\d+/, 'number'],
[/\/\/.*$/, 'comment'],
],
},
});
};
return (
<Editor
height="90vh"
defaultLanguage="typescript"
theme="vs-dark"
onMount={handleMount}
/>
);
}
这一步跑通后，你就有了一个长得非常接近 VS Code 的编辑界面。注册自定义语言是为了验证 Monaco 的扩展机制能玩通，后续接真实语言时，直接装语法文件或引 monaco-editor 的语言包就行。
4.3 接入大模型实现行内补全
行内补全是 AI 编辑器的招牌功能，实现思路是：监听光标位置，当用户输入暂停 300ms 时，把光标附近的代码上下文发给 AI 服务，AI 返回补全的 token，然后以“幽灵文本”的形式展示在光标后面。用户按 Tab 接受，按 Esc 取消。
Monaco 没有内置的行内补全 API，但我们可以通过 inline suggestion 的机制来实现。核心代码参考如下：
ts复制editor.onDidChangeCursorPosition((e) => {
const line = editor.getPosition()?.lineNumber;
const content = editor.getModel()?.getLineContent(line!);
// 防抖：停止输入 300ms 后触发
if (debounceTimer) clearTimeout(debounceTimer);
debounceTimer = setTimeout(async () => {
const suggestion = await getAICompletion(content);
// 使用幽灵文本注册一个 view zone
inlineSuggestionWidget.showAtPosition(suggestion, position);
}, 300);
});
这里有几个容易踩的坑：
第一个是上下文长度限制。你不能把整个文件都塞给模型，一要控制 token 数，二要给模型“重点看哪些内容”。我们的做法是取光标位置所在函数体，加上函数签名和最近引用的几个函数定义，再附带当前文件路径和项目语言类型。
第二个是补全结果的合法性校验。模型生成的补全有时是残句，比如在 JS 里补全后出现未闭合的括号。我们在应用前会先用 ESLint 的 parser 做语法检查，语法错误超过阈值就丢弃这次补全。实测下来，这个校验能把补全的可接受率从 60% 提升到 85% 左右。
第三个是上下文膨胀问题。如果用户频繁移动光标，每次移动都会触发补全请求，模型 API 的调用成本会非常高。我们做了按文件路径 + 光标位置的缓存，200ms 内对同一文件同一位置的补全直接命中缓存，不重复请求。
4.4 实现 AI 对话侧边栏与代码应用
行内补全只是第一步，用户还需要“选中代码 → 和 AI 对话 → 把修改后的代码应用回去”的完整闭环。
组件上我们做了一个右侧侧边栏，用 React 渲染对话列表，每个消息支持 Markdown 渲染，代码块用 Monaco Diff 编辑器展示。用户在编辑器里选段代码后，点击“发送给 AI”，系统会把选中代码和用户输入作为上下文发到 AI 服务。AI 回复的代码通过统一的 applyCode 函数应用到文档模型。
applyCode 的实现关键在这里：不能用“替换选中文本”这种粗暴方式，因为 AI 生成的修改可能是跨多块的。我们用 diff-match-patch 这个库来计算原代码和新代码的差异，然后生成一系列文本编辑操作，逐个应用到文档模型。同时，我们维护一个“应用前快照”，用户可以在对话记录里随时回退到之前的任意版本。
ts复制import { diff_match_patch } from 'diff-match-patch';
function applyDiff(oldText: string, newText: string) {
const dmp = new diff_match_patch();
const patches = dmp.patch_make(oldText, newText);
// 把 patches 转换成 Monaco 的 ITextOperation
const ops = convertToMonacoOperations(patches);
editor.executeEdits('ai-apply', ops);
}
这个闭环打通后，你的编辑器已经算得上一个“准 AI 编辑器”了。接下来要做的就是接入真实的大模型 API，加上项目级索引能力，再打磨各种边缘 case。
5. 常见问题与排查技巧实录
5.1 Monaco worker 加载失败
症状：编辑器启动后，语法高亮消失，智能提示不弹出，控制台报 Error: Unexpected token '<' 或者 worker 加载失败。
原因：Vite 默认的打包策略没有把 Monaco worker 作为独立 chunk 处理，入口 HTML 里没有正确注册 worker 的 URL。Monaco 里 worker 的加载方式和普通脚本不一样，它需要 new Worker(new URL(...)) 这种格式才能被正确识别。如果打包配置不对，worker 请求回来的内容其实是 HTML，自然解析失败。
解决：在 vite.config.ts 里加一行配置，把 worker 格式改成 es 模式，或者用 vite-plugin-monaco-editor。
ts复制import monacoEditorPlugin from 'vite-plugin-monaco-editor';
export default defineConfig({
plugins: [
monacoEditorPlugin({
languageWorkers: ['editorWorkerService', 'json', 'css', 'html', 'typescript'],
}),
],
});
5.2 远程主机连不上节点或者闪断
远程开发是 AI 编辑器的重要场景，但这里的坑非常多。热搜词里有“未能下载 VS Code 服务器（failed to fetch）”“远程主机可能不符合 glibc 和 libstdc++ 先决条件”，我都踩过。
“failed to fetch”通常不是网络问题，而是安装脚本因为目标主机的 CPU 架构判断错了，下载了不兼容的二进制包。比如远程主机是 arm64，脚本却下载了 x64 版本，解压后跑不起来。
glibc 的报错更直白：“远程主机可能不符合 glibc 和 libstdc++ VS Code 服务器的先决条件”。本质原因是远程服务器的操作系统太老，自带的 glibc 版本低于 VS Code Server 要求的 GLIBC_2.28。解决思路是在远程主机上装一个新版 glibc，或者干脆升级操作系统，再或者换用容器化方案，把开发环境整体打包到 Docker 里。我们在实践里最推荐的是最后一个方案，因为远程开发最重要的是环境可迁移，容器能顺带解决权限、依赖冲突一大堆问题。
5.3 大文件卡顿和流式渲染性能
AI 编辑器处理大文件时的表现，直接决定用户第一印象。Monaco 在 2 万行以下的文件里表现不错，但一旦到了 5 万行以上，滚动和输入就开始有明显卡顿。
优化手段有几个。第一是开启 experimentalScreenReader 和 smoothScrolling，这两个配置对渲染性能影响不大，但能减少光标追踪时的重绘频率。第二是降低 renderWhitespace 和 minimap.enabled 这类视觉功能的负载。第三，也是最重要的，对超大文件做“行数裁剪”，只把视口附近的行渲染出来，其他行用虚拟化占位——Monaco 底层有这个机制，但默认阈值设得比较高，你可以调低 largeFileOptimizations 的触发线。
流式渲染这里有个独家技巧：AI 生成代码时，不要让每个 token 都触发编辑器更新，而要用 buffer 先攒 50ms 的数据，再一次性写入文档。Monaco 的增量更新虽然高效，但频繁的小批量更新仍然有开销，攒批后的稳定性会好很多。我们实测过，同样的模型输出，攒批后 UI 的帧率从 30fps 提升到了 55fps 以上。
5.4 自定义语言的语法高亮配置错误
给 Monaco 加一门新语言，很多人会直接用 Monarch 的 tokenizer 配置，但配置完后发现高亮只有一种颜色，或者数字、字符串全都不生效。问题通常出在主题上——Monaco 默认主题只映射了 identifier、keyword 等几个 token，自定义语言的 token 需要显式映射到主题的 tmLanguage scopes 上。
解决方法是同时注册语言 tokenizer 和主题的 token 规则：
ts复制monaco.editor.defineTheme('my-theme', {
base: 'vs-dark',
inherit: true,
rules: [
{ token: 'identifier', foreground: 'D4D4D4' },
{ token: 'number', foreground: 'B5CEA8' },
{ token: 'comment', foreground: '6A9955', fontStyle: 'italic' },
],
});
如果还是不行，在浏览器的开发者工具里查看 Monaco 生成的 token class，看是否落到了正确的 scope 上。这里卡住的人很多，主要是对 “token 规则 → 主题规则 → CSS class” 这个三级映射不够熟悉。
5.5 Electron 包体积和启动速度优化
用 Electron 打包，不优化的话体积轻轻松松到 200MB。我们的目标是把安装包压到 80MB 以下，做了几件事：去掉用不到的 Chromium 组件（比如 PDF viewer、打印服务）、用 terser 深度压缩 JS、图片资源全部用 webp 格式。这些做完，包体积从 180MB 降到了 90MB 左右。
启动速度优化方面，一个重要技巧是让 Electron 不等待渲染进程加载完成就显示窗口，先把空白窗口弹出来，内容用异步渲染。用户感知上“启动快”了很多。再用 v8-compile-cache 缓存编译结果，二次启动速度能提升 20% 到 30%。
6. 几个方向性的总结和经验心得
技术方案聊到最后，我想说几点踩过坑之后深有体会的东西。
第一，AI 编辑器的核心竞争力不在“能调大模型”，而在“能管好上下文”。同样一个补全需求，有的编辑器给的代码能用，有的给的是一堆似是而非的垃圾，差距就在上下文的质量。上下文不是简单的把代码塞给模型就行，而是要有结构性：项目类型、文件关系、函数调用链、最近的修改历史，这些都要整理成模型能高效理解的形式。这块和传统的 RAG 不太一样，代码语义和自然语言语义差别很大，需要单独设计索引策略。
第二，产品上建议先做“单文件 Agent”再做“多文件 Agent”。我们一开始就奔着“一句话改整个项目”的方向去做，结果上下文管理、跨文件索引、项目导航这些工程问题堆在一起，连一个稳定可用的闭环都搭不出来。后来调整策略，先把“选中一个函数的代码，让 AI 改这个函数，应用 diff，跑测试验证”这个方向做扎实，再往多文件扩散。这一步是产品节奏的问题，但从长期看也是技术积累的必经台阶。
第三，编辑器内核的“开箱即用”和“可扩展性”是永远的矛盾。Monaco 开箱体验好，但做深度定制时你会发现它的内部架构非常复杂，改一个默认行为要翻很久文档和源码。CodeMirror 6 刚好相反，很开放，但什么都要自己拼。如果你不是要做下一个 VS Code 级别的东西，我建议还是用 Monaco，把精力放在 AI 能力层的差异化上。我们的产品真正的护城河不是编辑器体验，而是 AI 模型、上下文工程和产品体验的整合。
最后再分享一个小技巧：开发这类工具时，一定要给 Monaco 的编辑器实例设置 typedef 级别的 TypeScript 检查，编辑器底层偶尔会因为 model 未释放导致内存泄漏。我们线上版本有个 bug，用户长时间使用后内存占用不断上涨，排查很久才发现是切换文件时没有调用 monaco.editor.getModels()[].dispose()，导致旧的文件模型一直挂在内存里。这个问题最好在代码评审时卡住，非常隐蔽。
如果你正在做类似的方向，欢迎交流细节。编辑器这个领域做起来确实不容易，但一旦把“AI 能力原生集成”这件事打磨透了，产品价值会非常明显。