Cursor也会犯错？Milvus如何用MCP+RAG解决AI Coding生成问题
前言
先说结论，Vibe Coding离完美还差最后一公里。
这几年，大模型+IDE的“气氛编程”（Vibe Coding）体验越来越顺滑。Cursor、Windsurf 等产品也火的一塌糊涂，甚至会给很多人一种错觉，是不是代码不需要人写了。
但写多了开发者们就会发现，问题常常出现在最后一步：模型写完，自己还得一个个改回来。
因为大模型生成的代码中，经常因为知识更新滞后，而出现一些去年或更早的代码写法，并不适配当前快速迭代的技术框架与最新开发规范。
举个例子，我最近在 Cursor 里让它写一段调用 OpenAI 的代码，
它给出的代码参考里，使用的还是gpt-3.5-turbo这个模型：
严格来说，这不算错，gpt-3.5-turbo甚至还是当初帮助 ChatGPT 横空出世的“功臣”模型。问题在于，大模型不知道gpt-3.5-turbo早就被官方标记为 Legacy(老旧，遗产）。这个老旧，不只是知识老旧，价格更是现在代替者gpt-4o-mini的3倍以上。
另外，检查生成的代码，我们，可以发现，openai.ChatCompleteion也不再是被官方推荐的 API 使用方法，早在2025年3月12日，OpenAI 官方就建议使用 Response API 来代替 Chat Completions API。
当然，不仅是 OpenAI 相关的代码会有这样的问题，Milvus SDK 的使用也类似。
比如，在链接Milvus 服务时，大模型会生成
connections.connect("default", host="localhost", port="19530")
这种代码，而最新的 pymilvus SDK也已经统一建议使用MilvusClient来进行链接和处理各种操作。
大模型只是从它训练时“看到过最多”的东西里，给了一个看起来“靠谱”的答案。这就导致，我们使用所谓 Vibe Coding后，还必须要花费足够的时间来反复校对兜底，来弥补代码落地的“最后一公里”。
这其实是一个很典型的“训练-现实错位”问题：
1）模型的训练数据是老的，里面全是 GitHub 上很多年前的陈年代码；而且，往往越是陈旧代码，其累积的stars有时候就越高，这就会影响对其的权重判断。
2）大模型训练周期太长，最好的模型厂商至少也需要数月才能重新训练一个最新的模型，根本赶不上 SDK 和 API 的变化。
虽然这一问题可以通过使用一些 IDE 的技巧来缓解，比如在 Cursor 对话框里，使用@符号，可以附带上最新的网页或文档，给大模型“纠偏”，但这一方案也需要人类在编码前先查阅资料，才能知道哪里可能有“坑”，本质上和后续校对没有太大区别。
01
最新实践：Milvus Code Helper MCP
那有没有一套方案，既能使用 Cursor 等 IDE 强大的 Vibe Coding 能力，又能准确地使用最新的代码文档信息，帮助我们高效且准确地编码吗？
答案很简单，把“现在的知识”喂给它。
最近，我们结合 MCP + RAG，在企业内部实现了一套 Vibe Coding 增强版方案 -- Milvus Code Helper MCP，帮助用户在使用 Milvus SDK 开发应用时，能够自动获取最新的 Milvus 文档内容，从而让 IDE 生成更加准确的代码。
我们正在考虑把这个服务在未来正式推出，来帮助大家更好地搭建基于Milvus 的上层应用代码，下面为其技术架构抢先版预览。
架构上看，这既是一个 MCP 架构，又是一个 RAG 架构。
- 从 MCP 角度看，主要从整体上看图中左右两个架构，左侧为 MCP Client（客户端），右侧是 MCP Server（服务端）。在 MCP 客户端，用户通过 Cursor、Windsurf 等 IDE 对话框里触发 MCP tools（工具） 调用，这些请求被发送到 MCP 服务端。MCP 服务端预设好有几个不同功能的 tools，每个 tool 对应一个常见的代码生成或修改需求，这些 tool 会从 Milvus 数据库里读取预先索引好的 Milvus SDK 文档信息。
- 从 RAG 角度看，主要看图中右侧 MCP Server 部分，服务端事先将文档信息向量化，并在 Milvus 数据库进行离线索引（Offline Indexing）。当 MCP tool 进行 Milvus 向量查询时，通过向量语义检索，获取相关的文档和代码片段。检索到的片段返回给 MCP 客户端，结合 LLM 大模型进行准确的代码生成。
我们知道 MCP 有两种服务提供方式，stdio 和 SSE：
- Standard Input/Output (stdio)
标准输入输出（stdio）传输功能支持通过标准输入和输出流进行通信。这对于本地集成和命令行工具来说特别有用。
- Server-Sent Events (SSE)
服务器发送事件（SSE）传输允许通过 HTTP POST 请求实现从服务器到客户端的流式传输，以进行客户端到服务器的通信。
由于 stdio 传输机制依赖本地传输模式，用户需要在本地环境中自行承担服务器端离线数据的导入工作。在本场景中，我们优先考虑 Server-Sent Events（SSE）更为适宜。
因为借助 SSE，用户无需手动进行文档导入操作，相关数据处理流程均由服务端预先完成。此外，服务端可配置自动化任务，以固定周期（如每日一次）重新导入并更新文档数据，从而确保知识库始终保持最新状态。
而用户唯一要做的，就是在 MCP 配置里，填入以下 JSON 设置：
{
"mcpServers": {
"milvus-code-generate-helper": {
"url": "http://<SERVER_ADDRESS>:23333/milvus-code-helper/sse"
}
}
}
效果展示
在我们的预设 tools 里，有三个常用的 tools，以实现常见的使用 Milvus 进行应用开发的需求：
- pymilvus-code-generator：使用 pymilvus SDK 进行常见的代码开发。此 tool 适合各类基于pymilvus SDK的应用场景开发，也是最为常用。
- orm-client-code-convertor：将Python SDK里老旧的 ORM(Object Relational Mapping，对象关系映射)代码写法，转换为 MilvusClient 的调用方式。
- language-translator：在不同程序语言之间的 Milvus SDK 的调用代码转换，例如将 Python SDK的调用代码转成 TypeScript SDK 的调用代码。
在这个展示中，用户要求 Cursor 写出使用 pymilvus 进行 full-text search 的代码，可以看到，Cursor准确地调用了相应的 MCP 和 tool，写出了符合规范的代码。正常情况下，大多数的基于 pymilvus 开发应用的场景，都能正确调用此tool。
另外，如果不使用我们这个 MCP 工具，写出来的代码是老旧的 ORM SDK 的写法，目前已经不推荐。以下是使用和不使用 Code Helper MCP 的代码截图对比：
使用MCP code helper | 不使用 MCP code helper |
 |  |
使用官方最新推荐的MilvusClient接口来创建Collection | 使用老旧的ORM接口创建Collection，不推荐 |
模型不会实时学新东西，Vibe Coding 有“最后一公里”知识幻觉，这点大家应该已经有共识了。但这并不代表模型不能变得“新”。
业内主流的途径包括：RAG、MCP、本地插件，这些机制的核心思路很简单：不是让模型更聪明，而是让它睁开眼看世界。
而关于怎么让模型看世界，除了我们提供的 Milvus Code Helper MCP 服务外，开发者还可以选择如 Context7、DeepWiki 等新兴工具来解决这类问题。这些工具或服务通常基于 MCP 或 RAG 等技术框架，通过不同的方式向AI模型注入最新的项目文档和代码示例，以提升生成代码的准确性和相关性。
以下是几个代表性工具的简单介绍：
工具一：Context7
Context7 旨在为大型语言模型（LLMs）和 AI 代码编辑器提供实时、版本特定的最新文档和代码示例。它通过直接从官方文档源获取数据，并将其注入到 AI 提示的上下文窗口中，从而解决 LLMs 依赖过时训练数据或生成“幻觉”代码的问题。
Context7支持自定义导入github仓库，或llms.txt文件。导入各种格式的文档文件.md, .mdx, .txt, .rst, .ipynb，但不导入代码文件。
当前，用户有两种手段使用Context7，
- 通过Context7官方网页，提出问题，把网页中检索到的上下文，复制回代码编辑软件，进行提问。
- 使用Context7 MCP，自动判断需要去哪个代码仓库检索上下文，自动结合上下文生成回答。
工具二：DeepWiki
DeepWiki 是它能够自动解析 GitHub 上的开源项目并生成详细的、易于理解的技术文档。这些文档不仅包括项目的功能描述和技术栈分析，还提供了交互式架构图和流程图，帮助开发者快速掌握项目的核心结构与逻辑。此外，DeepWiki 配备了对话式AI助手，支持用户通过自然语言提问来获取针对代码库的具体解答，极大地提高了代码理解和学习效率。
DeepWiki支持自定义导入github仓库，他更关注代码文件，也因此容易忽略项目文档里的信息。
当前，用户可以在DeepWiki官网里查看github项目的总结wiki信息，也可以在网页上提问进行深度搜索。官方目前没有提供MCP，用户需要先从官网复制总结的信息，作为上下文，复制到自己的代码编辑软件，再进行提问。
工具三：Cursor Agent Mode
即在Cursor的chat对话框里打开agent模式。它实际上是代表当前Vibe Coding这一大类的 IDEs的核心功能（同类型的比如Windsurf Cascade功能）。该模式支持网页搜索、MCP调用等功能，也支持自定义勾选所需的功能。但也正是因为功能太多，有时想要调用网络搜索时不一定有效，搜索的网页也不一定准确。
可以通过@＋文档/网页的形式准确放入相关上下文，但这样又需要用户自己提前找到相关文档。
工具四：llms.txt
llms.txt 并不是一种工具或产品，而是一种提议的标准，旨在为大型语言模型（LLMs）提供网站内容的结构化信息。它是一种文本文件，通常位于网站的根目录下，使用Markdown格式编写，以帮助AI系统更好地理解和处理网站的信息。与 sitemap.xml 不同，后者列出所有可索引的页面但不提供内容理解的帮助。因此一般可以使用llms.txt 文件配合其他工具或产品使用。
llms.txt 文件通常包含网站的标题、描述、文档目录、API参考链接、教程链接以及其他重要资源的链接。它可能还包括一个扩展版本 llms-full.txt，这个文件会包含更加详细的内容，如完整的文档页或代码示例。
客观来说，以上这些工具的通用性更强，可以应用于更多不同类型的项目和需求中。但Milvus Code Helper MCP 针对的是特定的应用开发场景，尤其是围绕 Milvus 数据库的开发工作，可以提供更为精准和优化的服务。它不仅能够自动从官方来源获取最新的文档信息，还能够无缝集成到现有的开发环境当中，为用户提供了一个高效、准确的知识助手。
每种工具都有价值，只是切入点不同，我们更推荐同时使用以上两者，发挥各工具所长，从而更灵活地应对复杂多变的开发任务与场景需求。
03
尾声
毫无疑问，今天的大模型还远远不够“聪明”。它知道的东西，大多来自互联网上已经存在的信息，而这些信息里包含了大量老旧、不准确甚至误导性的代码。
但AI落地，我们真正需要解决的，并不是怎么让它更聪明，或者“模型写不出代码”的问题，而是——模型写出的代码，我们敢不敢用。
Milvus Code Helper MCP，是我们做出的一小步尝试：希望大家在用大模型写 Milvus 相关代码时，能参考到“最新、准确”的信息。
这对很多开发团队来说，意义重大。
- 它可以帮助团队减少大量重复性的代码校对工作。
- 它能显著提升在 Milvus 上构建上层 AI 应用的开发效率。
- 它也为今后构建更多企业内的“专属知识助手”提供了可复制的思路。
这个项目对我们自己很有价值，也希望对更多在用 Milvus 搭建RAG系统的团队有价值。
目前我们已完成基本架构实现，并在内部几个业务线中使用稳定，并考虑把这个服务在未来正式推出。接下来，我们会重点关注以下几件事：
- 将其以 MCP 的形式集成进更多主流 IDE；
- 与更多文档管理平台联动，实现企业内私有知识库的动态接入；
- 开源部分能力，邀请社区共同完善工具链。
它的能力，还在持续演进中，如果您有更好的工具链设计思路，也欢迎你加入我们，一起把这个工具打磨得更好。
