企业官网建设流程全解析

1. 从侧边栏困局说起：工业智能体到底该长什么样

CAD 和 CAE 这两个词，干过制造业的人都不陌生。CAD 负责画图建模，CAE 负责仿真验证，一个管“长什么样”，一个管“扛不扛得住”。过去三十年，这两类软件的核心交互方式几乎没变过——人坐在电脑前，打开软件，点菜单，敲命令，一步步把脑子里的东西搬到屏幕上。软件是工具，人是操作者，边界清晰得很。

但这两年 AI 大模型一进来，事情开始起变化。最早的一批尝试，几乎清一色是把 AI 塞进软件的侧边栏，做成一个聊天框。你问它“这个倒角怎么画”，它给你一段操作说明；你让它“帮我写个宏”，它吐出一段脚本。用起来不能说没用，但总感觉隔了一层——AI 在软件旁边，不在软件里面。它看得见你，但摸不着你的模型，更动不了你的参数。

行云创新马洪喜提的那个观点，戳的就是这个痛点：CAD/CAE 工业智能体，不会只停留在软件侧边栏。这句话背后其实藏着一个判断——真正的工业智能体，得能钻进软件的骨架里，能读得懂几何拓扑，能调得动求解器，能替人做决策，而不是在边上当个“问答客服”。

我自己的理解是，工业智能体和通用聊天机器人的根本区别，在于它必须对“物理世界”负责。你问 ChatGPT“这个零件强度够不够”，它只能给你讲一堆材料力学原理；但工业智能体应该能直接读你的网格模型，跑一遍静力学分析，然后告诉你“第三阶模态下这个筋板会共振，建议加厚 2mm”。前者是知识问答，后者是工程决策。这两者之间的鸿沟，就是侧边栏和智能体的距离。

这篇文章我想把这件事拆开聊透。从 CAD/CAE 智能体的核心能力拆解，到它为什么不能只做侧边栏，再到实际落地时该怎么设计架构、怎么选技术路线、怎么避开那些我踩过的坑。不管你是做工业软件开发的，还是制造业里搞数字化转型的，或者只是对 AI 落地工业场景感兴趣，应该都能从里面找到能直接抄作业的东西。

2. 工业智能体的核心能力拆解：它到底该会什么

2.1 从“能聊”到“能算”：工业智能体的能力分层

通用大模型的能力边界很清楚：它能理解自然语言，能生成文本，能做一些逻辑推理。但工业场景要的东西完全不一样。我把它拆成四层，从下往上说。

最底层是语义理解层。这一层跟通用大模型重叠度最高，就是把工程师的自然语言指令翻译成机器能懂的结构化意图。比如“把这个法兰的螺栓孔从 8 个改成 12 个”，智能体得能识别出“法兰”“螺栓孔”“8 个”“12 个”这些实体，还得知道“改成”是一个修改操作。这一层现在做得相对成熟，但工业术语的歧义性是个大坑——“倒角”在不同行业里可能指完全不同的工艺，没有领域微调根本搞不定。

往上一层是几何认知层。这是工业智能体区别于通用 AI 的核心。它得能读懂 CAD 模型里的几何信息：这个面是平面还是曲面，这条边是直线还是样条曲线，这个特征跟那个特征之间是什么拓扑关系。传统 CAD 的 API 能提供这些信息，但问题是 API 是给人用的，参数一大堆，调用逻辑复杂。智能体要做的，是把这些底层 API 封装成更高层的“几何操作原语”，比如“识别所有圆角半径小于 1mm 的特征”“找出所有壁厚小于 2mm 的区域”。

再往上是物理推理层。这一层对应 CAE 的能力。智能体得知道材料属性、边界条件、载荷工况这些物理概念，还得能判断“这个结构在 200N 的力下会不会屈服”“这个流道在 5m/s 的流速下压降是多少”。这一层不能靠大模型瞎猜，必须跟真实的求解器打通。我的做法是让智能体负责“设置问题”，求解器负责“计算结果”，中间用一套标准化的参数接口连接。

最顶层是决策执行层。智能体得能根据分析结果做判断，然后直接操作软件执行修改。比如“检测到应力集中系数超过 3，自动在圆角处增加过渡曲面”，这个动作要能闭环完成，不需要人再点一遍菜单。

这四层能力，侧边栏聊天框只能碰到第一层，后面三层它根本够不着。这就是为什么我说侧边栏模式注定是过渡形态。

2.2 为什么侧边栏模式走不远：三个硬伤

侧边栏模式的问题不是技术不够好，而是架构上就有天花板。我总结了三个绕不过去的硬伤。

第一个硬伤是上下文断裂。侧边栏里的 AI 只能看到你粘贴给它的文字，看不到你当前打开的模型，不知道你选中的是哪个面，更不知道你上一步做了什么操作。这就好比一个工程师站在你旁边，但你得把所有信息口述给他，他才能给建议。效率低不说，还容易出错。真正的智能体应该像坐在你工位上一样，屏幕上的东西它全看得见。

第二个硬伤是操作断层。侧边栏 AI 能告诉你“应该把圆角改成 R5”，但它改不了。你还得自己找到那个圆角，双击，输入 5，回车。这个过程中间只要有一个环节你理解错了，结果就偏了。智能体应该能直接执行，或者至少生成一个可回滚的操作序列让你确认。

第三个硬伤是数据孤岛。侧边栏 AI 通常是一个独立的服务，跟 CAD/CAE 软件之间只有很窄的接口。它拿不到完整的模型数据，也拿不到求解器的中间结果。这就导致它只能做“表面文章”，没法做深度分析。比如你想让它优化一个零件的拓扑结构，它需要反复调用求解器、读取应力场、修改几何，这个循环在侧边栏架构下根本跑不起来。

我见过不少团队一开始都从侧边栏切入，觉得门槛低、见效快。但做到后面都会遇到同一个问题：用户用了几次就不用了，因为“它说的我都知道，它做的我做不了”。这个反馈很致命。

2.3 真正的工业智能体该长在哪：三个嵌入层级

那智能体应该长在哪？我的判断是三个层级，由浅入深。

第一层是命令级嵌入。智能体以插件形式挂在软件里，能调用软件的 API，能读写模型数据，但交互还是通过对话框。用户说“帮我检查一下这个装配体有没有干涉”，智能体调用干涉检查 API，把结果用自然语言返回。这一层比侧边栏深，因为它能真正操作软件了。

第二层是工作流级嵌入。智能体不再是一个独立的对话框，而是渗透到软件的各个操作环节里。你画一条线，它实时提示“这条线与基准面夹角 87 度，是否要调整为 90 度”；你设置一个载荷，它自动推荐“根据历史案例，类似结构通常用 500N”。这一层的特点是主动服务，不需要你每次都去问它。

第三层是内核级嵌入。这是最彻底的形态。智能体直接跑在软件的几何内核和求解器内核之上，能实时读取内存中的模型数据，能在求解迭代过程中动态调整参数。比如在拓扑优化时，智能体根据每一步的应力分布实时调整材料分布策略，而不是等整个优化跑完再看结果。这一层对软件架构的要求最高，但效果也最颠覆。

马洪喜说的“不会只停留在侧边栏”，我理解就是指要往第二层和第三层走。侧边栏是入口，但不是终点。

3. 技术架构怎么搭：从 API 封装到内核级集成

3.1 整体架构设计：四层解耦

真要动手做，架构上我建议分四层，层与层之间用标准接口解耦。这样后面换大模型、换求解器、换 CAD 平台，都不用推倒重来。

最底层是软件适配层。这一层负责跟具体的 CAD/CAE 软件打交道。不同软件的 API 差异巨大，有的用 COM，有的用 Python，有的用 C++ 插件。适配层的作用是把这些差异屏蔽掉，对上提供统一的“几何操作接口”“求解调用接口”“数据读写接口”。我一般会定义一套抽象基类，每个软件写一个适配器实现。

第二层是能力封装层。这一层把底层的原子操作封装成更高层的“能力”。比如“识别特征”这个能力，底层可能调用了十几个 API，但上层只需要传一个模型 ID 和一个特征类型，就能拿到结果。这一层的设计原则是面向工程语义，而不是面向 API。

第三层是智能体编排层。这是核心。它负责接收用户指令，拆解成任务序列，调用能力封装层的接口，处理中间结果，最后生成响应。这一层通常用 LangChain 或者类似的框架来做，但工业场景下需要做大量定制。比如任务拆解不能只靠大模型，得有一套领域规则来约束，否则它可能给你拆出一个物理上不可能执行的任务序列。

第四层是交互层。这一层决定用户怎么跟智能体交互。可以是对话框，可以是右键菜单，可以是实时提示，也可以是自动化脚本。交互层要灵活，因为不同场景下用户想要的交互方式完全不同。

3.2 大模型选型：通用还是垂直

大模型选型是绕不过去的问题。我的经验是通用大模型打底，垂直微调补差。

通用大模型（比如 GPT-4、Claude 3.5 这个级别）在语义理解和任务规划上已经够用了。你不需要自己从头训一个，成本太高，效果还不一定好。但通用模型在工业术语和几何推理上会犯低级错误。比如它可能分不清“拔模角”和“倒角”，可能把“过盈配合”理解成“间隙配合”。

解决办法是用领域数据做微调。微调数据从哪来？三个来源：一是软件的操作日志，把用户的操作序列和对应的自然语言描述配对；二是工程手册和标准，把材料参数、工艺规范这些结构化知识喂进去；三是历史项目数据，把“问题-分析-方案-结果”这个链条整理成训练样本。

微调的方式我推荐 LoRA，成本低，效果好，而且可以针对不同模块训不同的 LoRA 适配器。比如一个适配器专门管几何特征识别，一个专门管求解参数设置，一个专门管工艺决策。推理时根据任务类型动态加载对应的适配器。

有个坑要注意：微调数据里的几何信息不能只用文字描述，得把几何特征向量化。比如一个圆角，不能只说“R5 圆角”，得把它的曲率、位置、相邻面信息都编码进去。否则模型学不到几何之间的空间关系。

3.3 几何内核的对接方式：三种路线对比

智能体要操作几何，必须跟几何内核对接。目前有三条路线，各有优劣。

API 调用是最简单的，直接用软件提供的 Python 或 COM 接口。优点是开发快，不用碰 C++。缺点是能力受限，很多底层操作 API 不暴露，而且性能有损耗。适合做原型验证。

插件嵌入是主流方案。写一个软件插件，在插件进程里跑智能体逻辑。这样能拿到更完整的数据，性能也更好。缺点是每个软件都得单独开发插件，工作量不小。

内核级集成是最彻底的，直接把智能体逻辑编译进几何内核。这需要拿到内核源码，一般只有软件原厂或者深度合作伙伴才能做。但效果最颠覆，能做到真正的实时交互。

我的建议是：先用 API 调用跑通流程，验证价值；然后针对核心软件做插件嵌入，提升体验；最后如果有条件，跟原厂合作做内核级集成。

3.4 求解器调用：怎么让 AI 等得起

CAE 求解动辄几分钟到几小时，智能体如果傻等，用户体验会很差。我的做法是异步调用 + 进度回调 + 中间结果利用。

异步调用就是智能体发起求解任务后不阻塞，继续处理其他事情，等求解完成再回调。进度回调是让求解器定期上报进度，智能体可以据此给用户反馈“已完成 60%，预计还需 3 分钟”。中间结果利用是更高级的玩法——不等求解完全收敛，智能体就根据当前的残差和场变量做初步判断，如果明显不对就提前终止，节省时间。

还有一个技巧是代理模型。对于频繁调用的分析类型，可以训一个神经网络代理模型，输入几何参数和边界条件，直接输出应力、变形这些结果。代理模型精度不如真实求解器，但速度快几个数量级。智能体可以先用代理模型做快速筛选，只对候选方案跑真实求解。

4. 实操落地：从零搭一个 CAD 智能体原型

4.1 环境准备与工具链选型

假设你要从零搭一个 CAD 智能体原型，我把我用过的工具链列一下。

CAD 平台选 FreeCAD 或者 Onshape。FreeCAD 开源免费，Python API 完善，适合练手。Onshape 是云原生，API 设计得很干净，适合做产品化。商业软件里 SolidWorks 的 API 最成熟，但需要正版授权。

大模型用 OpenAI 的 API 或者本地部署 Qwen2.5-72B。前者效果好但贵，后者便宜但需要显卡。原型阶段建议用 API，快速验证。

编排框架用 LangChain 或者 LlamaIndex。LangChain 生态更全，但抽象层太厚，调试麻烦。LlamaIndex 更轻量，适合工业场景。我最近在用 LangGraph，做多步骤任务编排很顺手。

几何处理用 OpenCASCADE 或者 trimesh。OpenCASCADE 功能全但学习曲线陡，trimesh 轻量但只能处理网格。如果要做精确几何操作，还是得上 OpenCASCADE。

开发环境用 Python 3.10+，配 PyCharm 或者 VS Code。AI 插件我试过 Fitten Code，补全速度不错，对 Python 支持很好。

4.2 第一个智能体：自动识别并修改圆角

拿一个具体任务练手：用户说“把所有小于 R2 的圆角改成 R3”，智能体自动完成。

第一步，解析指令。用大模型把自然语言拆成结构化任务：

task = { "action": "modify_fillet", "condition": {"radius": {"operator": "<", "value": 2}}, "target": {"radius": 3} }

这一步的关键是给大模型一个清晰的 schema，让它按格式输出。我一般用 function calling 或者 JSON mode，比纯 prompt 稳定得多。

第二步，识别目标特征。调用 CAD 的 API 遍历所有圆角特征：

import FreeCAD import Part def find_small_fillets(doc, threshold): small_fillets = [] for obj in doc.Objects: if obj.TypeId == "Part::Fillet": for edge in obj.Shape.Edges: if edge.Curve.TypeId == "Part::GeomCircle": radius = edge.Curve.Radius if radius < threshold: small_fillets.append((obj.Name, edge.Index, radius)) return small_fillets

这段代码遍历文档里所有 Fillet 对象，检查每条边的曲率半径。实际工程中圆角可能不是标准圆弧，得用曲率分析来识别，但原型阶段这样够用了。

第三步，执行修改。对每个识别出的圆角，修改其半径参数：

def modify_fillet_radius(doc, obj_name, edge_index, new_radius): obj = doc.getObject(obj_name) # FreeCAD 的 Fillet 修改需要重建特征 # 实际实现会更复杂，这里简化示意 obj.Radius = new_radius doc.recompute()

第四步，验证结果。修改后重新检查，确认所有目标圆角都改到位了。如果有没有改成功的，记录下来反馈给用户。

这个流程跑通，你就有了一个能真正操作 CAD 的智能体雏形。虽然简单，但架构是完整的。

4.3 多智能体协作：让专业的人干专业的事

单一智能体处理复杂任务会力不从心。比如“优化这个支架的结构，减重 20% 同时保证强度”，这涉及几何修改、仿真分析、结果评估多个环节。我的做法是拆成多个专业智能体，用编排器协调。

几何智能体负责读模型、改特征、生成变体。仿真智能体负责设边界条件、调求解器、读结果。评估智能体负责判断方案是否满足要求、给出下一步建议。编排智能体负责拆解任务、分配工作、汇总结果。

智能体之间通过消息队列通信，每个智能体有自己的工具集和知识库。编排智能体用状态机来管理流程，比如“几何修改 → 仿真验证 → 评估 → 如果不满足则回到几何修改”。

这种架构的好处是每个智能体可以独立优化，而且可以并行执行。比如几何智能体生成 10 个变体的同时，仿真智能体可以开始分析已经生成的变体。

多智能体协作的坑在于通信开销和状态同步。我建议初期用简单的共享内存或者 Redis 做状态存储，别一上来就搞复杂的消息中间件。等规模上来了再考虑分布式。

4.4 参数计算实例：怎么让 AI 算得准

工业场景里很多决策需要精确计算，不能靠大模型拍脑袋。举个例子：用户说“这个悬臂梁在 500N 载荷下变形不能超过 2mm，帮我选个合适的截面尺寸”。

智能体得先算。悬臂梁端部挠度公式是：

$$\delta = \frac{FL^3}{3EI}$$

其中 F 是载荷，L 是长度，E 是弹性模量，I 是截面惯性矩。假设材料是钢，E=200GPa，L=300mm，F=500N，要求 δ≤2mm。

代入得：

$$I \geq \frac{FL^3}{3E\delta} = \frac{500 \times 300^3}{3 \times 200000 \times 2} = 11250 \text{ mm}^4$$

如果是矩形截面，宽度 b，高度 h，I = bh³/12。假设 b=20mm，则：

$$h \geq \sqrt[3]{\frac{12 \times 11250}{20}} = \sqrt[3]{6750} \approx 18.9 \text{ mm}$$

所以选 20×20 的方钢就够了。智能体把这个计算过程跑一遍，然后自动在 CAD 里把截面改成 20×20，再调求解器验证。这个闭环跑通，用户就真的省事了。

关键是公式和参数不能靠大模型记，得放在知识库里，智能体调用计算工具来算。大模型只负责理解问题、选择公式、解释结果。

5. 常见问题与排查技巧实录

5.1 智能体“听不懂”工业术语怎么办

这是最高频的问题。用户说“把这个件的拔模角加大一点”，智能体回“拔模角是什么”。原因是大模型的训练语料里工业术语占比太低。

解决办法分三步。第一步，建术语表。把行业里的标准术语、企业内部的习惯叫法、甚至老师傅的口头禅都整理出来，每个术语对应标准定义和同义词。第二步，做实体链接。用户输入里出现术语时，先用术语表做匹配和消歧，把自然语言映射到标准术语。第三步，微调模型。用术语表构造训练样本，让模型学会在工业语境下理解这些词。

我实测下来，术语表加实体链接能解决 80% 的“听不懂”问题，剩下的 20% 靠微调补。

5.2 几何操作失败怎么排查

智能体调用 CAD API 时经常失败，原因五花八门。我整理了一个排查表：

最常见的坑是坐标系。CAD 里全局坐标系和局部坐标系混用是常态，智能体如果搞混了，改出来的东西位置全错。我的做法是在适配层统一转成全局坐标，上层只用全局坐标。

另一个坑是特征依赖。你改了一个基础特征，后面依赖它的特征可能全部失效。智能体得能识别依赖关系，按正确顺序操作。这个用拓扑排序就能解决，但前提是得先把依赖图建出来。

5.3 求解器不收敛怎么让 AI 处理

CAE 求解不收敛是家常便饭。传统做法是工程师凭经验调参数，智能体要做的就是把这种经验固化下来。

我总结的排查顺序是：先看网格，再看边界条件，最后看材料参数。网格质量差是最常见的原因，智能体可以自动检查雅可比比、长宽比这些指标，超标就自动加密。边界条件冲突是第二常见，比如过约束导致刚体位移被锁死，智能体可以检查约束方程的数量和秩。材料参数不合理是第三常见，比如泊松比设成 0.5 导致体积不可压，智能体可以检查参数范围。

如果自动排查搞不定，智能体应该把诊断信息整理好推给人工，而不是瞎试。我见过有的智能体不收敛就疯狂调参数，跑了几十次还是失败，浪费时间。

5.4 怎么评估智能体的效果

不能只看“能不能跑通”，得有一套量化指标。我用的是四个维度：

任务完成率：用户下达的任务有多少比例被正确完成。这个最重要，低于 80% 就没法用。平均交互轮次：完成一个任务平均需要几轮对话。越少越好，理想是 1-2 轮。操作准确率：智能体执行的操作有多少是正确的。这个要跟人工操作对比。用户采纳率：智能体给出的建议有多少被用户接受。这个反映信任度。

我一般会建一个测试集，包含 100-200 个典型任务，定期跑一遍看指标变化。新版本上线前必须跑通测试集，否则很容易引入回归。

有个经验：别追求 100% 准确率。工业场景里有些任务就是模糊的，智能体做到 85% 准确、剩下 15% 能给出有用的中间结果让用户接手，比追求 100% 但经常卡死要好得多。

6. 工业智能体的边界与我的实操体会

做了一段时间下来，我对工业智能体的能力边界有了更清楚的认识。它能做的是有明确规则的重复性工作和有历史数据支撑的决策，做不了的是需要创造性突破的设计和没有先例的异常处理。

比如参数化建模、标准件选型、常规仿真设置，这些智能体做得比人快得多。但全新的结构方案、颠覆性的工艺路线，还是得靠人。智能体的价值不是替代工程师，而是把工程师从重复劳动里解放出来，让他们专注在真正需要创造力的地方。

我在实际项目里踩过最大的坑是过度承诺。一开始跟用户说“什么都能干”，结果用户拿一堆模糊需求来试，智能体频频翻车，信任度直接归零。后来学乖了，明确告诉用户“这几类任务我能干，那几类我干不了”，反而口碑更好。

还有一个体会是数据比模型重要。同样的模型架构，喂了高质量领域数据的版本，效果比通用版本好一个数量级。所以别急着换更大的模型，先把数据整理好。

最后分享一个小技巧：让智能体学会说“我不确定”。工业场景里，一个错误的确定答案比一个正确的“我不确定”危害大得多。我在智能体的输出里加了一个置信度字段，低于阈值就自动转人工。这个机制上线后，用户投诉率降了一半。

这个方向后续还能往实时协同走——多个工程师和多个智能体在同一个模型上协作，智能体之间互相协商，工程师随时介入。这个场景的技术挑战还很大，但我觉得是工业软件的下一个形态。