RevitDocs.Mcp：让AI写Revit代码不再编造API

AI写Revit插件代码时最常见的翻车场景，不是逻辑写错，而是凭空捏造了一个根本不存在的API函数名——或者用了一个属于旧版本的API，在新版Revit里早已废弃。越南YouTube频道Kỹ Sư Giấy（Paper Engineer）近日展示了一个名为RevitDocs.Mcp的MCP服务器项目，专门用来解决这个痛点。

问题根源：Revit API逐年变化，AI训练数据跟不上

Revit API并非一成不变。Autodesk每年随新版本Revit发布API更新，函数可能被重命名、废弃或替换。AI模型在训练时混合了多个版本的文档和社区代码，导致生成代码时经常"记混版本"——写出来的代码看着合理，实际编译就报错。

更麻烦的是，Revit API的官方文档和代码示例分散在多个来源中，质量参差不齐。开发者手动查文档已经够费时，指望AI自己"记住"正确版本更是奢望。

为什么大模型会"记混"API版本

大语言模型的知识来自训练语料，而语料是某个时间点的快照。Revit从2005年至今已发布20多个主要版本，每个版本的API都有增删改。训练数据中混杂了Revit 2018、2020、2023等不同年代的博客、Stack Overflow问答、GitHub仓库，模型无法区分哪段代码对应哪个版本。

更关键的是，模型并不"知道"自己引用的是哪个版本——它只是在做概率性的token预测。当用户说"用Revit API创建一个墙"时，模型会输出一个在训练语料中出现频率最高的函数名，而这个函数可能属于早已废弃的旧版本。这类错误被称为"API幻觉"（API hallucination），在SolidWorks、AutoCAD、Unity、Unreal等频繁迭代的SDK中同样普遍。

检索增强生成（RAG）是应对这一问题的通用方案：让模型在生成前先从权威数据源检索相关内容。RevitDocs.Mcp本质上是把RAG做成了MCP服务器，将"查文档"这一步显式化、工具化，而不是埋在模型内部。

RevitDocs.Mcp是什么

RevitDocs.Mcp是一个基于MCP（Model Context Protocol）协议的服务器，由Kỹ Sư Giấy团队开发。它的核心思路很直接：在AI写代码之前，先让它去查文档。

MCP是Anthropic推出的开放协议，允许AI Agent连接外部工具和数据源。任何支持MCP的AI客户端都可以接入这个服务器，而且它不需要任何AI供应商的API密钥——服务器本身只负责检索文档，不调用大模型。

服务器运行在Revit外部，通过STDIO与本地的AI客户端通信，与Revit进程完全解耦。

关于MCP协议的更多背景

MCP（Model Context Protocol）是Anthropic在2024年底发布的开放标准，目标是统一AI模型与外部工具、数据源之间的交互方式。在MCP出现之前，每接入一个新的数据源（数据库、文件系统、API），开发者往往需要为每个AI客户端单独写适配代码。MCP把这层抽象标准化：服务器端只需实现一次协议，任何支持MCP的客户端（如Claude Desktop、Cursor、Cline等）都能直接调用。

MCP的通信方式主要有两种：STDIO（标准输入输出，适合本地进程）和SSE/HTTP（适合远程服务）。RevitDocs.Mcp选择STDIO，意味着它作为本地子进程被AI客户端启动，通过stdin/stdout交换JSON-RPC消息。这种模式延迟低、无需网络端口，也不需要任何云端服务，特别适合Revit这种桌面端开发场景。

MCP服务器通常暴露三类能力：Tools（可调用函数）、Resources（可读取数据）、Prompts（预置提示模板）。RevitDocs.Mcp的四个工具属于Tools类别，且全部设计为只读，避免AI误操作本地环境。

四个只读工具，覆盖查文档到找代码

RevitDocs.Mcp提供四个工具，全部为只读操作：

Revit Docs search — 根据用户指定的Revit版本搜索API文档。版本是显式参数，AI必须明确声明目标版本，避免跨版本混淆。

Revit Docs read — 读取搜索结果中的具体文档页面内容，提供完整的函数签名、参数说明和用法。

Revit Codes search — 在已审核的代码来源中搜索示例代码。这些来源经过筛选，比AI从训练数据中"回忆"的代码可靠得多。

Revit Docs sources — 列出当前可用的文档来源及其状态，让开发者清楚知道检索覆盖了哪些范围。

为什么"版本"要作为显式参数

在Revit API开发中，同一个操作在不同版本里的写法可能完全不同。例如FilteredElementCollector的某些重载、Document.Create方法的参数、以及各类Element的子类归属，都随版本演变。如果AI不声明目标Revit版本，检索层就只能返回多个版本的混合结果，反而加剧混淆。

把版本作为必填参数，相当于强制Agent先做一次"版本决策"——它必须知道用户在用哪个Revit，才能发起检索。这是一种"约束即提示"的设计思路：通过接口签名约束AI的行为，比在提示词里反复叮嘱"注意版本"更可靠。同理，"Revit Docs sources"工具让Agent了解检索覆盖了哪些来源，避免它对未覆盖的领域过度自信。

这种将领域约束编码进工具设计的做法，值得其他CAD/BIM类MCP服务器借鉴。

安装部署：目前需自行构建

RevitDocs.Mcp当前尚未发布正式版本，用户需要自行从源码构建。项目基于.NET 10，克隆仓库后运行发布脚本即可。

部署流程分三步：克隆项目并执行发布脚本、在MCP客户端中配置可执行文件路径、确保Agent在写代码前先调用RevitDocs search查询函数名。

据视频介绍，该项目在30天内产生了27次提交，开发节奏相当活跃。

多源信息交叉验证

你可能没注意到，上述信息来自Kỹ Sư Giấy单一来源的视频介绍。目前该项目在开发者社区中的独立验证和第三方评测尚未出现。项目版本号、具体API覆盖范围、文档来源的完整列表等细节，需要开发者自行查阅仓库确认。

这类工具的意义

RevitDocs.Mcp代表了一个更广泛的趋势：用MCP协议给AI Agent"接上"领域知识，而不是指望模型在训练阶段就记住所有细节。对于API频繁变化的专业软件（Revit、AutoCAD、Blender等），这种按需检索的模式比微调模型更灵活、更可靠。

对于Revit开发者来说，核心问题很简单：你让AI写代码之前，有没有先让它查文档？

（本文基于YouTube频道Kỹ Sư Giấy的视频内容整理，项目细节请以官方仓库为准。）