AI 不是终点,工具设计才是

最近和一些朋友聊起 AS.Tools 插件，大家总是会把话题绕到AI上。"这个用了什么模型？""大模型理解能力怎么样？""是不是以后能自动建模了？"

这些问题都很好，但它们问的是终点，而不是过程。在最近的开发过程中，我逐渐意识到：AI 不是终点，工具设计才是。

01为什么是工具，而不是 AI 直接干？

让我们从一个真实场景说起。在施工单位做 BIM 翻模时，最常见的工作之一就是管综调整——调整管道和结构梁之间的碰撞。看起来很简单，但实际操作起来涉及一连串判断：

• 碰撞位置在哪里？

• 碰撞的是什么系统？

• 哪个系统需要避让？

• 往哪边翻弯？

• 翻弯半径多少？

• 翻弯后会不会产生新的碰撞？

如果让 AI 直接"解决碰撞"，它大概率会像初学者一样：看到了就动，动了就撞，撞了再动，反复拉锯。为什么？因为它缺少一个关键能力——对建筑规范和工程经验的结构化表达。

所以真正的问题不是"AI 能不能做"，而是"我们要把什么能力交给工具"。

02工具设计的第一性原理

在 AS.Tools 的开发中，我遵循了一个简单的原则：先给 AI 眼睛，再给它手。

这句话听起来很抽象，但实际上就是工具设计的顺序：

▶ 工具演进顺序

⚡ 工具设计的本质

将复杂的领域知识，封装成简单、可组合的原子操作。

03AI 只是翻译官

在这个过程中，AI 扮演的角色其实很有限——它是一个翻译官。

用户说："把这面墙移到 3 米远的地方。"

AI 的思考过程大概是：

整个过程中，AI 并不"知道"什么是墙，什么是米，什么是移动。它只是按照工具定义的接口，把自然语言翻译成 JSON，再调用工具执行。

这就是为什么我说 AI 不是终点。真正的价值在于：

▸工具接口设计得好不好？ 参数是否清晰？错误处理是否完善？

▸工具组合能力强不强？ 能不能通过简单工具的组合，完成复杂任务？

▸领域知识沉淀得够不够？ 行业规范、最佳实践，有没有固化到工具逻辑里？

04一个设计案例：标注工具

我常常举一个例子来说明工具设计的重要性。

假设我们要设计一个"自动标注"功能。有两种思路：

工具定义示例

工具：create_dimension_by_elements输入：要标注的构件列表输出：自动按照规范放置的标注

这样，AI 的任务就简单了：它只需要识别用户的意图（"标注这些墙"），然后调用工具，工具会按照专业规范完成剩余工作。

05工具设计的哲学

在开发 AS.Tools 的过程中，我逐渐形成了一些工具设计的哲学：

1. 原子化

每个工具只做一件事，但做到极致。不要做"创建整个房间系统"的工具，而是做"创建墙""创建门""标注尺寸"这些原子工具。组合价值大于单体价值。

2. 可验证

工具的输出应该是可验证的。"创建墙"工具执行后，要么成功（返回墙的 ID），要么失败（返回错误原因）。不要有"可能成功了"这种模糊状态。

3. 可组合

工具的输入输出应该能无缝衔接。查询工具的输出，应该是修改工具的输入。这样才能形成工作流。

4. 领域知识封装

工具不是简单的 API 包装，而是要封装领域知识。比如"避让管道"工具，不是简单的"移动管道到某个坐标"，而是要计算合理的翻弯路径、考虑最小弯曲半径、避开其他系统。

5. 容错性

AI 会犯错，所以工具要有容错能力。参数不对时，不要直接崩溃，而是返回友好的错误信息，让 AI 能够理解并重试。

06未来：工具进化之路

写到这里，你可能会问：那 AI 到底有什么用？

AI 的价值在于它降低了工具的使用门槛。以前你需要记住几百个按钮的位置、几百个参数的含义，现在你只需要用自然语言表达意图。

但这就要求我们持续优化工具：

✔更丰富的工具库目前 97 个工具，覆盖基础操作，但专业领域工作流仍需封装

✔更智能的组合能力从单工具调用，到多工具协同，再到复杂工作流

✔更深的领域知识把建筑规范、构造做法、施工经验固化到工具逻辑中

✔更好的错误处理AI 调用失败时，工具给出有意义的反馈，帮助 AI 理解问题

07最后的想法

开发 AS.Tools 的这段时间，我最大的收获不是学会了如何让AI调用API ，而是对“工具”这件事有了更深的理解。

好的工具是透明的。你用的时候，感觉不到它的存在，只是在流畅地完成工作。当工具设计得足够好时，AI 也会像人一样，自然地使用它们来完成复杂任务。

所以，AI不是终点，它只是一个放大器。它放大了工具设计的价值，好的工具会被更多人更方便地使用，而糟糕的工具则会暴露出所有的问题。

工具设计才是终点。这是一条没有尽头的路，但值得一直走下去。

相关阅读

AS.Tools：深度集成 AI 的 Revit 插件

【AS.Tools】 Revit AI 功能介绍