AI写代码我踩坑无数，写需求文档却真香了

优易科技 | 优易BIM助手

我用AI写Revit插件也有一段时间了，说实话，踩过的坑能凑一本避雷指南。

Transaction报错，API参数传错，过滤器写反了，Transaction没有正确Commit……每次AI给出来的代码看着像那么回事，一跑起来全是问题。Revit二次开发这块的资料本来就少，AI能参考的样本也有限，它写出来的代码十次有八次要我自己回来改，改完还不一定对，有时候改着改着发现AI连底层逻辑都想错了，又要推倒重来。

说实话，那段时间我对AI写代码这件事是有点意见的。

结果最近我让AI帮我整理需求文档，发现情况完全不一样——AI干这个活，比写代码靠谱太多。

AI写代码，为什么总是差点意思

我先说清楚AI写代码的问题在哪，不是为了骂AI，是为了有个对比。

Revit二次开发有个特别讨厌的地方：文档少、社区小、示例代码质量参差不齐。AI训练用的语料里，真正能参考的Revit API代码少得可怜。这就导致一个问题：AI能给你一个看起来很标准的C#代码框架，但一到细节就抓瞎。

比如AI经常把FilteredElementCollector的用法写错，过滤条件的写法有时候对有时候错，全靠运气。有一次AI给我的代码里，用了Document.Create.NewFamilyInstance创建了一个族实例，但完全没考虑这个族是不是嵌套族、是不是在链接文件里——这两个情况处理方式完全不一样，AI就没想到。

还有一次，我让AI帮我写一个批量修改管道直径的逻辑，AI给出来的方案是遍历所有管道，逐一修改LookupParameter("直径").Set(newValue)。看起来没问题对吧？但Revit里管道直径这个参数名字不一定叫”直径”，不同管道系统可能叫”Diameter”、”公称直径”、”标称直径”，AI根本不知道你项目里的实际参数名是什么，它只能猜，猜错了整段代码就废了。

这种错误不是语法错误，编译能过，一跑起来才发现不对，而且往往要在特定条件下才会触发，调试起来特别费时间。

写需求文档，AI为什么突然靠谱了

然后我切换了一下场景，用AI整理需求文档。

情况完全变了。

我最近一次做族库系统的新功能，开了两轮需求沟通会议，会后把录音转成文字丢给AI，让它帮我整理成结构化的需求文档。我给AI的prompt大概是：”请将以下会议记录整理成功能需求清单，按优先级分类，区分『必须实现』和『nice to have』，并标注每个需求对应的原始发言段落。”

AI给我的输出，我只需要做两件事：第一，检查有没有遗漏；第二，把一些口语表达改成更书面的说法。

整个过程大概用了半小时，整理出来的文档比我之前自己写需求文档还完整。而且AI有个特别好的地方——它会帮我把客户原话和我的理解分开标注，这样我回头和客户确认的时候，能直接引用原话，而不是我消化过一遍之后的转述。

这比我之前手写需求文档省了太多时间。之前写需求文档最烦的不是内容本身，而是”先有个框架再往里填”这件事特别消耗意志力。框架搭好了往里填内容其实很快，但搭框架这个开头动作特别容易拖延，结果往往拖到deadline前才硬着头皮写，写出来的质量也不行。

AI帮我跳过这一步——它先把框架搭出来，哪怕粗糙一点，至少有个底。我在这个底上改，比从空白开始写轻松太多了。

具体好在哪，说个真实例子

举一个真实的例子。

上周我给一个客户做泵房出图模块的二期需求沟通，客户提了五六条，有些是当场追加的，有些是在说A的时候顺嘴提了B。我会后整理的时候，自己回忆漏了至少两条。

我把会议记录扔给AI之后，AI整理出来的清单里有一条是客户在说”法兰标注那块，之前一直没提，但这次如果能做就更好了”，我当时确实说了这句话，但自己会后完全没印象了。AI把我漏的那条找回来了。

这种场景下AI的价值特别明显：人脑在高压沟通中是会选择性记忆的，记住大的、忘记小的，但小的需求有时候才是真正影响体验的关键点。

还有一次，我让AI帮我把一段功能描述转成用户故事格式，就是”作为XX，我想要XX，以便XX”那种。AI一口气给我列了十几条，每条都符合格式要求，我只需要删掉不合理的、合并重复的，调整顺序。这活儿以前我要写半小时，现在十分钟搞定。

但AI不是万能的，它有边界

我也不想把AI吹上天。说清楚AI在哪不行，才是真的实用主义。

第一，隐性需求AI找不出来。

客户说”要自动出图”，你问他”自动出哪些视图”，他说”就是三视图啊”。但实际上三视图可能不够，他还需要平面图和系统图，设备大了可能还要单独出一张设备详图——这些他不会在需求会上主动说，因为他自己也没想清楚。这种”没说出来但实际需要”的东西，AI同样找不出来，因为它只能处理你说出来的内容。

第二，业务边界AI判断不了。

比如客户提了三个需求，其中两个其实是同一个问题的两种表现，解法是同一个；另外那个单独的需求如果要接进来，需要动到底层数据结构，改动量非常大，值不值做需要人来判断。AI能帮你整理，但它给不了”这个需求接进来会对现有架构造成什么影响”这种判断。这种判断需要经验、需要业务积累，AI目前做不到。

第三，关系人的立场AI感知不到。

有时候客户提一个需求，不是他自己真的想要，而是他上面有领导提过、或者同行竞争对手在做。知道这个背景之后，你对待这个需求的优先级判断就会不一样——但这个背景AI不知道，它只能处理文字表面。

所以我的用法是：AI做初筛、做整理，人来做判断、做决策。AI负责把活儿干到60分，最后的40分还是得自己来。

说回代码，我的结论是

AI写代码现阶段不靠谱，原因很直接：代码需要精确，AI擅长的是模糊匹配和概率输出。Revit API又是资料少、坑多、边界条件复杂的领域，AI踩坑的概率远高于它给你一个正确答案的概率。

但写需求文档不一样。这个活儿的本质是把模糊的东西变清楚、把散乱的东西变结构化、把口语变成书面语——这恰恰是语言模型最擅长的事情。

所以我现在对AI的定位很清楚：让它写代码，能省30%的起步时间，但后面要花70%的精力去debug；让它写文档，能省70%的时间，而且质量基本能到80分。

现阶段AI真正能提升效率的地方，可能不在你以为的那个地方。

欢迎转发。

优易科技 | 优易BIM助手