如何设计一个AI原生IDE

AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

我们的IDE已经变得聪明多了。它们已经从仅仅是代码编辑器变成了更像一个结对编程伙伴。像GitHub Copilot、Cursor和Windsurf这样的工具能理解我们的代码、建议修复方案并回答问题。

但它们实际上是如何工作的？你如何构建一个能读取巨大的私有代码库并在不到一秒内给你答案的系统？

这是一个非常困难的系统设计问题。它也是我新书 System Design for LLM Era中的一个案例研究，在书中我更详细地讨论了这个以及其他AI系统。

让我们来分解这个设计。

1、我们需要构建什么（需求）

首先，我们需要明确IDE要做什么，以及需要做到什么程度。

它做什么（功能需求）：

• 了解整个代码库： 它必须理解所有代码，而不仅仅是你打开的文件。
• 代码补全： 它需要在你输入时建议代码。
• 聊天模式： 你应该能用普通英语问它问题。
• 编辑代码： AI应该能建议编辑，甚至跨多个文件。

做得怎么样（非功能需求）：

• 必须快速： 代码补全必须感觉是即时的。我们将目标定为P99 200毫秒以内。聊天可以稍慢一些，3秒以内。
• 必须准确： 建议需要正确且有帮助。我们希望减少错误或幻觉。
• 必须私密： 这是最重要的一点。用户代码是敏感的。我们绝不能在服务器上存储用户代码。我们需要一个零保留策略。

2、有多少流量？（规模估算）

假设我们的工具很受欢迎。

• 日活跃用户（DAU）： 500,000
• 峰值用户： 假设高峰时20%的人同时在线。那就是100,000用户。
• 峰值速率： 一个快速编码的开发者每小时可能触发30次补全请求。

让我们为最繁忙的任务——代码补全——算一下：

(100,000 用户 × 30 请求/小时) / 3,600 秒/小时 = 约833请求/秒

加上安全缓冲，我们需要设计一个能处理约1,666 RPS的系统。而且它必须在200毫秒内响应每一个请求。

3、全局概览（高层设计）

我们的系统将有两个主要部分：

1. 客户端上下文引擎： 这是一个智能组件，位于用户的IDE内部。它监控用户的操作，弄清楚服务器需要什么上下文（什么代码），并在发送之前加密所有数据。
2. 编排引擎： 这是服务器上的主要大脑。它接收请求，与向量数据库对话以查找相关代码，构建提示词，然后调用LLM获取答案。4、

4、深入探讨：三个最困难的问题

这个设计有几个我们必须解决的真正困难的问题。

问题1：隐私悖论

如果不允许存储代码，AI怎么能了解整个代码库？

解决方案： 我们在客户端做所有繁重的工作，只在服务器上存储抽象（基于数字的摘要）。

1. 客户端分块： 用户机器上的IDE扫描代码，使用抽象语法树（AST）将其分解为智能块，如函数或类。
2. 客户端加密： IDE加密每个块并隐藏文件名。
3. 无状态嵌入： 服务器接收这些加密块。它在内存中解密，使用AI模型将代码块转换为一组数字（称为嵌入），然后立即删除代码。
4. 索引： 服务器只在向量数据库中存储数字嵌入和一个隐藏ID（如X9Y4Z1）。

服务器现在拥有代码含义的可搜索索引，但它从不存储实际的代码本身。

问题2：保持代码同步

当开发者输入时，服务器的嵌入会变得过时。我们不能每次有人按键时都重新索引整个代码库。

解决方案： 使用Merkle树。

Merkle树是一种使用哈希在大量数据中找到微小变化的方法。

• 客户端和服务器都从代码块构建一个Merkle树。
• 当用户更改文件时，客户端为树的那部分创建新的哈希。
• 客户端和服务器只需比较它们的单个根哈希（树的顶部）。如果哈希不匹配，就知道有东西变了。
• 然后它们可以沿树向下比较哈希，找到被编辑的确切块，我们只重新索引那一个小片段。这非常快。

问题3：达到200毫秒以下的延迟

这是我们最大的挑战。LLM调用很慢，但用户期望即时代码补全。

解决方案1：分离路径（异步vs同步） 我们为进入系统的请求创建两条路径：

• 同步路径： 用于代码补全。这些是紧急的，必须立即处理。
• 异步路径： 用于聊天问题或大型代理任务（如重构这个文件）。这些不那么紧急。我们把它们放入消息队列（如SQS）。工作机器会在后台接手处理。这让我们的主编排器可以自由处理快速的同步请求。

解决方案2：竞速响应 即使在同步路径上，我们最好的AI模型可能也太慢。所以我们让模型竞速。

1. 当代码补全请求进来时，编排器将它同时发送给两个LLM。
2. 最优模型： 这是我们最好、最聪明（也是最慢）的模型。
3. 备用模型： 这是一个较小、更快的模型，准确度较低但非常快。
4. 我们给最优模型很短的时间，比如100毫秒来响应。
5. 如果最优模型及时回复，我们使用它的（更好的）答案。
6. 如果它没有在100毫秒内回复，我们不等。我们直接使用备用模型的（更快的）答案并发送给用户。

这样，用户总是能及时收到响应，即使有时来自稍不准确的模型。

5、结束语

如你所见，构建一个现代AI工具不仅仅是调用LLM。它是客户端逻辑、隐私模式和速度优化的复杂系统。真正的挑战是将所有这些部分融合在一起，使其感觉简单而快速。

原文链接：How to Design an AI-Native IDE

汇智网翻译整理，转载请标明出处