夜雨聆风规划一个 Revit 插件知识库，让 AI coding 别再瞎编
用过 AI 写 Revit 插件的人，基本都踩过同一个坑：让它生成代码，它信心满满给你一段 Document.GetElement 再强转 FamilySymbol 的逻辑——语法对，但 API 版本用错了，或者根本不知道你项目里早有封装好的扩展方法。
AI 不是蠢，是它不懂你的项目。Revit API 几千个类，2020 到 2024 差异一堆，再加上你自己的架构约定、命名规范、踩过的坑——这些全在 AI 训练数据之外。
解法不是换个更强的模型，是给它喂一个知识库。
一、为什么 Revit 插件开发特别吃知识库
三个原因：
API 庞大且版本分裂。 Revit API 从 2014 到 2024，大量方法签名变了、废弃了、新增了。AI 训练数据混着各版本，经常给你一个当前版本根本不存在的方法。 项目私有约定。 你的项目有扩展方法、有基类、有约定的取参方式、有族加载的封装。AI 不知道这些，就给你写原生 API 调用，跟你现有代码风格格格不入。 踩坑记录不通用。 "这条 Curve 太短会崩溃""这个事务里不能开子事务"——这些是血泪经验，AI 没见过，会重蹈覆辙。
通用大模型解决不了这三点，知识库能。
二、知识库该装什么（四层）
| L1 API 基础 | ||
| L2 项目约定 | ||
| L3 踩坑实录 | ||
| L4 代码片段与模板 |
L1 是地基，L2/L3 是你的私有壁垒，L4 是效率加速器。光有 L1，AI 还是写不出"你的代码"；四层齐了，AI 才像一个跟你共事过的人。
三、知识库怎么建
两条路，按场景选：
轻量路：文件 + 项目内联。 把 L2/L3/L4 写成 markdown（架构说明、踩坑清单、代码模板），放进项目仓库的 .docs/ 或 KNOWLEDGE.md，让 AI coding 工具直接读项目文件。适合小团队、单项目。
结构化路：RAG 知识库。 L1 官方文档量大，用 RAG：文档切分 → 向量化 → 检索相关片段 → 拼进 AI 上下文。工具上可以用 ima 知识库，或本地 RAG 方案。适合多项目、要复用 API 文档的场景。
实操建议：L2/L3/L4 走轻量路放仓库（AI 直接读，零延迟、零检索误差），L1 走 RAG（量大才值得向量化）。 别把所有东西都塞进 RAG——项目约定这种小而关键的，直接给文件比检索更准。
四、AI coding 怎么接知识库
接法取决于你用的工具，但核心逻辑一样：让 AI 在写代码前，先看到你的知识库。
4.1 项目上下文自动读取
WorkBuddy、Cursor 这类工具打开项目后会自动扫描项目文件结构，L2/L3/L4 放在仓库里就能被读到。你要做的只有一件事：把约定写进文件，放在 AI 能看到的地方。
推荐结构：
项目根目录/├── .docs/│ ├── architecture.md ← L2 架构说明、基类、扩展方法│ ├── conventions.md ← L2 命名规范、取参封装│ ├── pitfalls.md ← L3 踩坑实录│ └── templates/ ← L4 代码模板│ ├── CommandTemplate.md│ └── TransactionPattern.md├── CLAUDE.md ← 项目记忆文件（见 4.3）└── src/4.2 @ 引用：精准投喂
有时候你不想让 AI 读整个项目，只想让它看某个文件。用 @ 引用：
参考 @.docs/pitfalls.md 里记录的 Curve 崩溃问题，帮我写一个安全的 Curve 创建方法，参考 @src/Commands/CreateOpeningCommand.cs 的写法AI 会先读这两个文件，再生成代码。比泛泛说"帮我写个创建 Curve 的方法"靠谱得多——它知道你的坑、知道你的风格。
4.3 CLAUDE.md：项目记忆文件
WorkBuddy / Claude Code 都支持项目记忆文件（CLAUDE.md），放在项目根目录，每次对话自动加载。这个文件适合放最高优先级的约定，比如：
# 项目约定- 目标框架：.NET Framework 4.7.2，Revit 2020 API- 所有 Command 继承 BaseCommand，不要直接实现 IExternalCommand- 取参数统一用 ParameterEx.GetAsString() 扩展方法，不要用原生 AsString()- 事务里禁止开子事务- Curve 创建前必须校验 length > RevitShortCurveTolerance这样每次 AI 写代码，都自动带着这些红线，不需要你每次重复叮嘱。
4.4 RAG 知识库：喂 API 文档
L1 官方文档量大，不适合放仓库（太大了 AI 上下文扛不住），走 RAG：
用 ima 知识库或本地 RAG 方案，把 Revit API 官方文档、版本差异说明导入，检索时自动拼进 AI 上下文。你问"Revit 2020 怎么创建 DetailCurve"，它先检索 API 文档片段，再生成代码，版本错位的概率大幅下降。
4.5 最关键的动作：参考现有代码
不管用什么工具，有一个动作效果最好：写代码前，先让 AI 读你的约定文件和相似代码。
参考项目里现有的 CreateOpeningCommand 写法，生成一个新的 CreateWallOpeningCommand，处理墙上的开洞AI 最擅长的不是从零创造，是照着你给的范例复刻风格。它读过你的 BaseCommand、你的取参方式、你的事务写法——生成的代码天然贴合现有架构，改两行就能用。
五、边界：知识库解决"懂你的项目"，不解决"懂业务"
说点清醒的。
知识库能让 AI 不瞎编 API、不违背你的架构、不重踩旧坑。但它替代不了业务判断——这个功能该不该加、这个参数公式对不对、这个交互合不合理，还是得你定。
而且知识库是活的：每次踩新坑、加新封装、改约定，都要回填。不维护的知识库，三个月就过期，比没有更坑——AI 会一本正经地按过期约定写代码，你查都查不出来。
所以知识库不是一次性工程，是开发流程的一部分：踩坑即记录，约定即入库。
六、收个尾
AI 写 Revit 插件，瓶颈不在模型能力，在上下文。你喂给它多少"你的项目"的知识，它就能写出多"你的"代码。
展示一下内容
规划知识库这件事，短期看是给 AI 铺路，长期看是把你团队的 Revit 开发经验沉淀下来——哪怕哪天换工具、换模型，知识库还在，那才是你真正的资产。
优易科技 | 优易BIM助手
欢迎转发
