AI写Revit插件实战复盘：从支吊架案例看人机协作的正确姿势

前天写了一篇《让大模型帮你写Revit插件，能走多远？》，昨天又实录了用AI开发支吊架插件的完整过程。

两篇文章下来，有一个问题比”AI能不能写”更值得讨论：

怎么系统化地用AI写Revit插件，而不是每次都靠运气？

支吊架案例里，我和AI来回改了五轮，踩了版本混用、API签名错误、参数名瞎猜等好几个坑。但复盘下来，这些问题里，有一半是可以通过改进协作方式避免的。

今天整理一套人机协作SOP——不是抽象的方法论，而是我踩完坑之后，总结出来的可执行步骤。

一、先搞清楚：AI在Revit开发里为什么会翻车

SOP之前，先理解根因。只有知道为什么会出错，才能在流程里针对性地预防。

根因1：训练数据的版本碎片化

Revit API 每年都有变化，但AI的训练数据没有明确标注”这是哪个版本的API”。

结果就是：AI给你的代码里，UnitTypeId.SquareMeters（2021+）和DisplayUnitType.DUT_SQUARE_METERS（2020）可能同时出现。编译直接报错，而且报错信息跟版本问题没有直接关联，新手很难定位。

SOP里的对应策略： 提示词里强制指定版本，并且人工审查所有涉及单位转换的代码。

根因2：族编辑器API极其小众

普通的FilteredElementCollector、Transaction，AI的训练数据里有很多示例，写得还行。

但一旦涉及族编辑器（FamilyDocument、FamilyManager、LoadFamily在族文档里的正确用法），AI就开始瞎猜。因为它见过的示例代码太少，只能根据”看起来像”的其他API来推理——结果就是生成了一坨看起来合理但根本跑不起来的代码。

SOP里的对应策略： 族相关代码，直接跳过AI，自己查文档写。或者在提示词里明确说”不要用FamilyManager，我用另一种方式实现”。

根因3：上下文缺失，AI只能猜测

Revit插件开发高度依赖当前文档状态：当前视图、当前选择集、文档单位、是否族文档……这些信息AI完全没有。

它给你的代码经常缺少必要的判空、状态检查、using语句。一跑就崩，崩的地方还不一定是AI改过的那行。

SOP里的对应策略： 提示词里主动喂上下文（”我用的是Revit 2020，单位系统是公制”），并且把BaseCommand基类（自动处理文档检查）的代码也给AI看。

二、人机协作SOP：六步法

下面这套流程，是支吊架案例复盘后整理出来的。按这个顺序来，AI的输出质量能从”看运气”变成”基本可用”。

第一步：需求结构化（5分钟）

不要直接把想法丢给AI。

先拿一张纸（或者Markdown），把需求拆成三部分：

【业务规则】——用自然语言写清楚
  - 输入是什么？（管道？墙？房间？）
  - 输出是什么？（放置族？修改参数？导出数据？）
  - 有什么边界条件？（未放置的房间、空引用、非系统管道）

【数据对照表】——如果涉及查表，直接做成表格
  | 条件 | 结果 |
  |------|------|
  | DN≤50 | 间距1.5m，吊架200×150 |

【已知的正确接口】——把你查好的参数名、方法名写下来
  - 管道外径：BuiltInParameter.RBS_PIPE_OUTER_DIAMETER
  - 管道中心线：LocationCurve + Curve.Evaluate

这一步最关键。支吊架案例里，我就是因为先做了这个表格，AI生成的规则代码一次就对，没再返工。

第二步：提示词四段式（每个提示词都按这个格式）

[场景]：Revit 2020，MEP插件开发，.NET Framework 4.8，C#

[需求]：（一句话描述要做什么，越具体越好）
  例：在管道上按间距自动放置支吊架族实例

[上下文]：（把你第一步整理的内容贴进来）
  - 管道外径参数：RBS_PIPE_OUTER_DIAMETER
  - 查表规则：（贴表格）
  - 单位：内部单位是英尺，换算用DisplayUnitType.DUT_MILLIMETERS

[约束]：
  - 只写（具体功能），不包含UI、不包含Transaction封装
  - 不写MEPHanger.Create，用FamilyInstance.Create代替
  - 所有单位转换代码用DisplayUnitType，不要用UnitTypeId

为什么这四段都有用：

• [场景]让AI切换到正确的知识域
• [需求]防止AI过度发挥
• [上下文]减少AI瞎猜的概率（这是最关键的一段）
• [约束]明确告诉AI”不要做什么”，比”要做什么”更重要

第三步：分治策略——把问题拆成Revit相关和无关两部分

这是最容易被忽视、但效果最明显的一步。

AI写纯C#逻辑（集合、字符串、文件IO、Excel导出）非常可靠，几乎不出错。 AI写Revit API相关代码，需要审查。

正确做法： 先让AI写纯C#部分（数据处理、查表逻辑、Excel导出），验证没问题后，再让AI写Revit API部分。

// 第一部分：让AI写（纯C#，很可靠）
public (string width, string height) GetHangerSpec(double diameterMm)
{
if (diameterMm <= 50)  return ("200", "150");
if (diameterMm <= 100) return ("250", "200");
return ("300", "250");
}

// 第二部分：让AI写（Revit API，需要审查）
// 提示词里明确说"只写放置逻辑，用FamilyInstance.Create"

支吊架案例里，查表逻辑AI一次写对，放置逻辑返工了两次——就是因为前者是纯C#，后者涉及Revit API。

第四步：AI生成后，人工审查三板斧

AI返回代码后，不要直接跑。按这个顺序快速过一遍：

① 单位转换代码搜索代码里的UnitUtils、UnitTypeId、DisplayUnitType，逐个核对版本。

• Revit 2020：用DisplayUnitType.DUT_*
• Revit 2021+：用UnitTypeId.*
• AI混用的概率：约70%

② 参数名搜索代码里的BuiltInParameter.，去Revit API文档里核对一遍。 AI瞎猜参数名的概率不低，尤其是冷僻参数（RBS_PIPE_BOTTOM_ELEVATION这种）。

③ 空引用和文档状态看代码里有没有对Location、get_Parameter()返回值做判空，有没有检查doc.IsFamilyDocument。 AI写的代码大约有30%缺少这些检查。

这三步加起来不超过10分钟，但能拦截80%的运行崩溃。

第五步：调试阶段——让AI当报错解释器

代码跑起来之后大概率会有报错。这时候AI的用法变了：

把完整的报错信息（包括堆栈）直接粘给AI，问”为什么”。

这类问题AI回答得很好，因为它不需要”生成”代码，只需要”解释”已有的错误信息。

支吊架案例里，我遇到过这个报错：

Autodesk.Revit.Exceptions.InvalidOperationException:
The document is not a project document.

把报错粘给AI，它立刻指出：LoadFamily是项目文档的方法，在族文档里要用别的方式。省了我至少半小时查文档的时间。

第六步：沉淀为提示词模板（为下次复用）

这一步大部分人都会跳过，但恰恰是最值得做的。

每次跟AI协作完一个功能，把”最终可用的提示词”保存到本地文件。下次做类似功能，直接基于上次的提示词改，而不是从头写。

我现在的提示词库大概是这样：

revit_ai_prompts/
├── 数据提取类.md  （房间/墙体/管道数据提取的提示词模板）
├── 族放置类.md    （在载体上放置族实例的提示词模板）
├── 参数修改类.md  （批量修改参数值的提示词模板）
└── 查表逻辑类.md  （纯C#查表逻辑的提示词模板）

三个月下来，新需求的提示词准备时间从15分钟降到3分钟。

三、效果对比：用SOP vs 不用SOP

用支吊架插件开发作为基准，对比两种协作方式：

结论： SOP不能让AI变成”一次就对”，但能把”碰运气”变成”可预期”——而这正是工程开发里最重要的东西。

四、给读者的行动清单

如果你明天就要用AI开发一个Revit插件功能，按这个顺序来：

• 动手前（5分钟）

• [ ] 把需求拆成「业务规则 + 数据对照表 + 已知接口」
• [ ] 确认你的Revit版本，记下来（决定单位写法）

• 写提示词（3分钟）

• [ ] 用四段式格式：[场景] + [需求] + [上下文] + [约束]
• [ ] [上下文]里贴你查好的参数名和方法名

• AI生成后（10分钟）

• [ ] 审查单位转换代码（核对版本）
• [ ] 审查参数名（去文档核对冷僻参数）
• [ ] 检查空引用处理

• 调试阶段

• [ ] 把报错信息完整粘给AI，让它解释
• [ ] 修正后，把最终提示词保存到本地

写在最后

到今天这篇文章，关于「AI × Revit插件开发」的三部曲就完整了：

• 0429：AI能走多远？（判断能力边界）
• 0430：支吊架案例全程实录（看真实过程）
• 0501：人机协作SOP（系统化方法）

从「试试看AI行不行」到「有方法地用AI提效」，中间差的不是AI的能力，而是你的协作方式。

工具永远是加速器，不是替代者。但用对了加速器，你能跑到的地方会远很多。

优易科技 专注BIM软件研发与数字化建造解决方案

优易BIM助手，懂技术，更懂落地。

欢迎转发