在自己 IDE 里接一个最小 AI 助手：一条可行链路

这一篇试着把“给自己的 IDE/编辑器接一个 AI 助手”这件事，拆成几步可以落地的工程工作，从最小可行版本开始，一步步往上叠功能。

如果一上来就想做“像 Cursor/Claude 那么全能”的助手，几乎一定会陷入无休止的工程泥潭。
一个更现实的起点是先定义一个 MVP（最小可用版本），比如：

  • 能在侧边栏里选中一段代码，请求“解释这段代码在干什么”；
  • 能输入一句自然语言指令，让助手在当前函数附近打一段草稿代码；
  • 不直接改文件，只以建议形式展示。

这样一来，第一版只需要解决：

  • 怎么从 IDE 里拿到当前文件/选中代码；
  • 怎么把这些东西发到一个 LLM API；
  • 怎么把结果渲染回 IDE。

补全、自动重构、批量改文件、项目级索引，都可以先放在后面迭代。

无论你用的是 VS Code、Theia 还是其它 UI 框架，第一步通常是：

  • 注册一个命令，比如 “Open AI Assistant”；
  • 在侧边栏或面板里放一个简单的 UI：
    • 一个多行输入框；
    • 一个“发送”按钮；
    • 一个展示历史消息的区域。

初版可以只做两类请求：

  • 纯自然语言问题：当成普通聊天/问答；
  • 选中代码 + 问题：侧边栏自动带上当前 selection。

这一步不需要任何模型相关复杂逻辑，只需要：

  • 能拿到当前选中代码（或者光标所在行附近若干行）；
  • 能把这些内容和用户问题组装成一个 JSON 请求发到后端。

后端可以是一个很小的服务，负责：

  • 接收来自 IDE 插件的请求；
  • 把请求转发给真实的 LLM 提供方（云端 API / 本地推理服务）；
  • 把结果原样（或稍作包装）返回。

为什么要多这一层，而不是 IDE 直接调模型 API：

  • 方便以后替换模型提供方，而不改前端插件；
  • 可以在这里统一做权限、配额、日志、缓存等；
  • 对企业/团队内部署来说，更容易加认证和审计。

在这一层，你可以开始约定一些简单的“任务类型”，例如：

  • type: "explain"：解释代码；
  • type: "edit_suggestion"：给出修改建议；
  • type: "chat"：普通对话。

后面要加新的能力，只要在这个协议上扩展即可。

当“选中一段代码 → 解释/建议”这条路跑通之后，可以逐渐往“自动改代码”靠：

  • 先让模型只输出“建议后的代码版本”，但不直接改文件；
  • 在侧边栏把“原始片段”和“建议版本”并排展示，支持一键替换选中区域；
  • 再往后，可以让模型输出更明确的 patch，按 diff 视图展示。

在这个阶段，最好保持几个约束：

  • 所有改动都要用户确认，不做“静默修改”；
  • 每次操作尽量只作用在一小段代码上；
  • 应用修改后立刻触发 LSP/编译器检查，把明显错误暴露出来。

等这条链路稳定了，再考虑项目级重构、批量操作等更激进的功能。

有了最小闭环之后，可以开始让助手的“视野”稍微大一点。
不一定一上来就做完整的向量索引，先从简单的开始：

  • 基于文件路径/依赖关系：

    • 当前文件 import/require 了哪些模块；
    • 这些模块的关键函数/类型定义。

  • 基于最近编辑历史：

    • 最近改过哪些文件；
    • 这些文件的顶部注释/导出接口。

在后端，根据这些信息选出少量额外上下文片段，拼进 prompt 里。
这一步的目标不是“看全项目”，而是“避免只盯当前函数一两行”。

等到这部分稳定了，再考虑引入：

  • 按函数/类粒度的代码切块；
  • 简单的 embedding 索引（比如用一个轻量嵌入模型）；
  • 基于相似度的召回。

在很多 IDE 助手里，你能看到它会：

  • 主动建议“跑一下测试”；
  • 帮你执行某个命令（例如 lint、format）；
  • 根据测试输出再做一次修复建议。

这些其实是把“IDE 原本就有的能力”挂成模型可调用的工具：

  • 工具的实现仍然在 IDE 或后端服务里；
  • 模型只负责“决定什么时候调用哪个工具，以及如何解读结果”；
  • 工具调用的输入输出格式要尽量结构化。

在自己的 IDE 里，要做到这一点可以先从两类工具开始：

  • 只读工具：读文件、列目录、查看 git diff、查看测试/构建结果；
  • 只读 + 提示工具：比如根据测试失败栈信息，提取关键信息给模型。

真正“执行有副作用的工具”（写文件、发请求）时，最好始终保留一层人工确认。

如果把“做一个像 Cursor 一样的 IDE 助手”这件事拆开，可以是一条相对温和的路线：

  • 先在 IDE 里放一个简单的对话面板，只做解释/建议；
  • 再逐步引入自动修改、项目级上下文、工具调用；
  • 同时在后端通过一层代理，统一管理模型调用和日志。

对于已经熟悉 Theia/LSP/Monaco 这些基础设施的人来说，这条路最大的工作量不在“AI 算法”，而在于：

  • 把 IDE 的状态、LSP 的能力和模型调用用一个干净的协议串起来；
  • 在每一层设计好边界和兜底策略，让这个助手足够“聪明”，但不会失控。