AI for CAD 公司与技术讨论摘录

编者按

本页整理 AI 与 CAD 相关的技术讨论，文字已按研究主题编辑。后续各篇围绕其中的公司、论文、开源项目与工程问题展开。建议先看首页的导航，再按需查阅本页的技术线索。

Date: June 15, 2026 at 12:51 PM Turns: 6 来源：技术资料讨论，经编辑整理。

---

Turn 1

👤 User

我希望系统整理中国范围内 AI for CAD 相关的公司、实验室和技术资料，为后续研究与工程实践建立资料基础。

🤖 Assistant

本次讨论聚焦行业资料整理与技术储备，重点观察传统几何内核与神经网络之间的连接方式。 研究重点包括 AI 驱动的设计生成、基于特征的智能辅助，以及如何把模型输出与底层几何约束结合。 以下是目前国内 AI for CAD 赛道的核心版图与研判，分为三大阵营：

一、 AI原生与三维生成创业公司（高成长、重资本）

这个阵营没有传统CAD的历史包袱，直接从“生成式”切入，是技术迭代最激进、资本最关注的地方。

• 卡伦特科技 (CurrentCAD)
  • 行业研判： 云原生CAD起家，近期发布了业内首个生成式CAD平台“创模AI”。他们打通了“文生CAD图”、“图生CAD图”的全流程，并支持对生成的模型进行特征编辑。
  • 技术看点： 核心难点在于解决从多模态输入到参数化特征的精确映射，这背后需要强大的后台几何引擎支撑云端的高并发运算与实时渲染。
• 魔芯科技
  • 行业研判： 由浙江大学 CAD&CG 实验室孵化的明星企业，近期完成亿元级别的新一轮融资。公司的战略重心已从早期的单个3D内容生成，全面转向“3D场景建模和世界模型”。
  • 技术看点： 核心逻辑在于将海量三维数据转化为“视觉知识”，打破单个物体的边界，探索物理规则、几何约束与大模型的深度融合。

二、 核心工业软件巨头（底层内核 + AI赋能）

这一类项目侧重复杂装配、曲面引擎、底层数学库与 AI 方法的工程结合。

• 新迪数字
  • 行业研判： 国内极少数掌握全栈式CAD核心技术的企业。目前主推“原生AI+CAD”，其主打的天工CAD引入了自然语言建模、基于几何特征签名的AI智能装配，以及基于3D模型矢量化的以图搜图功能。
  • 技术看点： 拒绝“外挂式”AI，而是将大模型与底层几何约束求解器深度绑定。这需要极强的底层架构能力和对边界表示法（B-Rep）拓扑结构的透彻理解。
• 中望软件 / 浩辰软件
  • 行业研判： 作为国产CAD的老牌主力，正在通过自研稳固3D内核能力（特别是在对标 Parasolid 等国际主流内核方面），同时大力向云端和智能化延伸。浩辰的“CAD看图王”已在云端形成庞大的数据和流量基本盘。
  • 技术看点： 聚焦于传统算法与AI的结合，例如AI驱动的拓扑优化、加工特征的自动识别等，研发工作高度偏向工程化稳定性和底层算法性能调优。

三、 顶尖学术机构与实验室（技术发源地）

在关注商业项目的同时，也需要跟踪学术机构的研究路线、论文与开源成果。

• 浙江大学 AI4SE Lab（隶属 CAD&CG 全国重点实验室）
  • 行业研判： 国内智能设计领域的绝对高地。聚焦基于模型的系统工程（MBSE）和 AI4CAD，与华为、十大军工企业及华望系统有极深的产业绑定，科研成果直接面向工业软件专项落地。
  • 研究方向： CAD生成与重建、CAD表示学习、CAD图纸分析与生成。这里产出的顶级会议论文和开源项目，直接反映了国内的最高技术水位。
• 上海人工智能实验室
  • 行业研判： 聚焦“AI for Science”，虽然更多侧重于量子、生化环材领域，但在几何深度学习、物理仿真降阶模型（Surrogate Models）等交叉领域有着强大的算力和生态生态号召力。 为了更直观地理解目前主流企业在技术路线上如何将传统工具与AI进行结合，可以通过下面的交互模块探索两种范式的底层差异：

技术学习与实践建议

可以从以下方向组织学习与实验：

1. 打通两套语言体系： 理解几何内核开发（C++、openNURBS、CGAL）与深度学习（Python、PyTorch）之间的数据与术语差异，用清晰的接口和文档连接底层数学库与张量运算。
2. 死磕“表示学习”（Representation Learning）： AI究竟如何理解3D几何？目前将严格的 B-Rep、网格（Mesh）转化为神经网络可高效计算的特征表示，是最大的技术瓶颈。深入理解这些数据结构在底层引擎和AI训练中的优劣，有助于理解不同表示在几何引擎与模型训练中的适用边界。
3. 深耕高质量技术社区： 继续保持对高质量独立技术博客和开源论坛的敏锐度。只看官方白皮书是不够的，很多前沿算法的“坑”和工程闭环经验，只有在技术社区的深度讨论（甚至是 issue 区）中才能捕捉到真实脉络。

Turn 2

👤 User

围绕 AI 与 CAD 的工程实践，应该如何规划技术栈补充与项目经验积累？

🤖 Assistant

开展 AI 与 CAD 结合的工程实践时，应保留已有的几何技术基础，同时补齐深度学习和系统集成方法。 重点是把 C++ 几何算法与 Python 深度学习连接起来，形成可以验证和复用的工程接口。 下面按四个阶段组织学习与项目实践，周期可以根据实际进展调整：

阶段一：建立认知与语言转换（第 1 - 3 个月）

核心目标是将扎实的几何与线性代数基础，转化为神经网络能够理解的“张量语言”。

• 打通数据流转链路： 不要抛弃原有的技术栈。深入研究如何将 Open CASCADE、CGAL 或 openNURBS 中提取的复杂 B-Rep 数据、网格拓扑，以及依赖 Eigen 处理的底层矩阵运算，高效且无损地转化为 PyTorch 可以直接参与训练和求导的张量（Tensors）。
• 深潜高质量野生社区： AI 与 CAD 的交叉领域迭代极快，官方文档往往严重滞后于工程实践。把精力投入到高质量的独立技术博客、GitHub 的 Issue 区以及硬核的开发者论坛中。在这些社区里讨论的关于“非流形几何在神经网络中的梯度消失”等真实踩坑经验，比泛泛的学术综述有价值得多。

阶段二：打通全链路工程原型（第 4 - 7 个月）

到了这一步，你需要一个能够拿得出手的工程闭环，证明你不仅懂算法概念，还能搞定落地。

• 构建混合架构： 尝试在本地搭建一个小型的端到端流水线。例如，设计一个基于图神经网络（GNN）的轻量级拓扑预测模型，并将其预测结果重新塞回底层几何引擎，生成规范的参数化实体。
• 文档与规范： 在项目中维护代码注释、接口约定和使用示例，使用 Doxygen 与 Doxygen-Awesome-CSS 生成便于查阅的 API 文档，帮助协作者理解和复用工程。

阶段三：跨领域协作与任务拆解（第 8 - 10 个月）

不同技术方向的协作需要对齐实验方法、几何鲁棒性要求和验收标准。

• 项目拆解： 将“基于 AI 的倒角特征识别”分解为数据解析、模型训练、算子接入和边界用例测试等任务，为每项任务明确输入、输出和验证方法。
• 建立工程化评估指标： 抛弃纯学术视角的评估方式。不仅要看模型的 Loss 值，更要评估生成的几何体是否符合工业加工约束、在主流平台中的加载性能如何、以及与现有装配体的匹配精度。

阶段四：结果复盘与技术交流（最后 2 个月）

• 对照公开实践： 结合前文的公司与技术研究，阅读相关开源项目和技术分享，对照自己的实验结果记录差异。
• 整理工程成果： 在项目文档与技术交流中说明几何内核、模型推理和验证工具如何配合，并记录适用范围与未解决的问题。

Turn 3

👤 User

我想基于已有的几何工程经验开发 AI/CAD 调试 Agent，可以从哪些具体项目切入？相关项目见 https://github.com/liyongzheng666 。

🤖 Assistant

可以先梳理已有项目、技术栈和可复现问题，再选择“改善几何代码调试体验”这一具体实践方向。 目前市场上绝大多数的“AI for CAD”都在卷“文本生成3D模型”（Text-to-3D），但工业界真正的痛点在于几何代码的编写与调试。现有的代码大模型（如 GitHub Copilot）在写普通业务逻辑时很强，但在写 CAD 几何代码（如 OpenCASCADE、CADQuery）时表现极差，因为它们“看不见”自己生成的几何体，经常写出语法正确但在拓扑上完全自交、无流形（Non-manifold）的废代码。 一个针对三维几何代码的 AI 调试 Agent，可以把已有工程经验落实到可验证的原型中。 以下是为您梳理的 3 个具体的项目原型切入点（由浅入深）：

切入点一：几何异常诊断与修复 Agent (Topology Error Doctor)

传统代码的 Bug 是报空指针，而 CAD 代码的 Bug 通常是“布尔运算失败”或“面片未闭合”。这对于开发者来说是黑盒。

• 项目构想： 开发一个 Agent，当用户的几何脚本（如 PythonOCC 或 CADQuery 代码）运行报错时，接管报错日志。
• Agent 工作流：
  1. 捕获引擎底层抛出的拓扑错误（如 BRepAlgoAPI_BooleanOperation: failure）。
  2. Agent 自动读取当前堆栈中的 B-Rep 数据，将其转化为简化的点云或网格特征。
  3. 结合错误日志和代码上下文，用大语言模型（LLM）向开发者输出人类可读的诊断：“第 42 行的圆角半径（5mm）大于了该边相邻面的最小宽度（4mm），导致拓扑面被吞噬。”
  4. 自动生成修复后的代码片段。
• 技术栈靶向： LangChain / LlamaIndex + PythonOCC/CADQuery + LLM API。

切入点二：可视化的“沙盒运行与自纠错” Agent (Self-Correcting Visual Coder)

这个方向最符合“Agent”的定义：具备工具调用（Tool Use）和环境反馈能力。

• 项目构想： 做一个基于 Web 的简易 CAD 代码生成环境。人类只输入自然语言（例如“画一个带有四个安装孔的法兰盘”），Agent 负责写代码并自我调试。
• Agent 工作流：
  1. Agent 编写第一版代码。
  2. Agent 在后台沙盒中运行代码，生成 .step 或 .stl 文件。
  3. Agent 调用几何检查工具（如检查体积是否大于 0，是否有自交面）。
  4. 如果检查失败，Agent 将“几何检测报告”作为反馈，再次修改自己的代码（Self-Reflection），直到生成符合要求的实体。
• 技术展现亮点： 这种“带环境反馈的强化生成”，能完美展现您对 AI Agent 架构（Actor-Critic 模式或 ReAct 模式）的理解。

切入点三：IDE 插件级的 AI 几何断点 (Visual Debugger Extension)

如果您有传统软件开发或插件开发的经验，这个方向落地性最强，可以直接作为开源工具发布。

• 项目构想： 为 VS Code 写一个插件。传统的调试器（Debugger）只能看变量的值（比如看到一个矩阵或者一个指针地址），这在调 CAD 代码时毫无用处。
• Agent 工作流：
  1. 当代码在某一行暂停时，开发者可以向 Agent 提问：“这个面现在的法向量对吗？”
  2. Agent 自动读取内存中的几何对象，生成一小段前端渲染代码（如 Three.js 或 pyvista），在 IDE 侧边栏直接把当前的 3D 中间态“画”出来，并把法向量高亮显示。
• 技术展现亮点： 打通了从“底层几何引擎”到“前端可视化”再到“大模型交互”的全链路。 核心策略建议： 作为 Agent 工程师，您的核心壁垒不是训练基础大模型，而是设计精巧的 Prompt 链、打通工具调用（Function Calling）、以及构建可靠的沙盒反馈机制。在 CAD 领域，谁能让 LLM 获得“几何空间感”，谁就能占领这个生态位。为了帮您更精确地制定接下来的技术栈补充计划，您可以补充一下：您目前在 GitHub 上的主攻语言是什么（Python, C++, 还是前端 TS）？您是否有过 OpenCASCADE 或三维渲染引擎的使用经验？

Turn 4

👤 User

我目前是C++，想从第三个方向出发，我想通过freecad调试occ出发，我的终极目标是一个开发系统的harness

🤖 Assistant

直接切入 C++ 底层，并以构建系统级的 Harness（测试评估台）为终极目标，这个战略眼光非常毒辣。 在模型调用之外，底层工具、评价标准和可复现的几何测试，是工程中需要持续维护的基础设施。 通过 FreeCAD 调试 OCC，进而演进为一个完整的 Agent Harness，这是一条极具工程美感的挑战之路。以下是为你拆解的架构演进路线与落地抓手：

阶段一：打破黑盒，让 OCC 在 FreeCAD 中“活”起来（可视化断点）

OCC 是无头（Headless）的纯数学引擎，调试时最大的痛苦是只能看着内存里一堆 TopoDS_Shape 的指针发呆。你的第一步是建立几何探针。

• 核心逻辑： 不要直接去改 FreeCAD 的庞大源码。可以利用 FreeCAD 的 C++ 插件机制（Workbench）或者直接通过 IPC（进程间通信），将你独立的 C++ OCC 程序的内存状态“推”给 FreeCAD 进行渲染。
• 工程抓手：
  • 开发一个轻量级的 C++ 调试宏或类（例如 OCC_DUMP(shape)）。
  • 当 C++ 代码执行到断点时，将当前的 TopoDS_Shape 序列化（例如转为 .brep 字符串或轻量级网格）。
  • 通过 Socket 或共享内存，将数据推送到运行中的 FreeCAD 实例，利用 FreeCAD 的 Python API 实时在视口中绘制出来。
• 里程碑： 实现“代码单步执行，FreeCAD 视口同步更新模型状态”。这是后续让 AI “看见”几何体的前提。

阶段二：打通跨语言桥梁，构建 Agent 操作接口（API Hooking）

AI Agent 通常运行在 Python 环境中（LangChain / LlamaIndex 等生态），而你的测试底座和被调试的源码是 C++。

• 核心逻辑： 必须构建一个坚固的跨语言通信层，让 Python 端的 Agent 能够“暂停” C++ 程序的执行，并“读取” C++ 内存中的几何特征。
• 工程抓手（推荐两条路线）：
  • 路线 A (轻量/紧耦合 - pybind11)： 用 pybind11 将你阶段一写的 C++ 调试工具封装成 Python 库。Agent 在 Python 中执行脚本时，直接调用底层的 OCC 接口，并在发生异常时提取 B-Rep 拓扑图。
  • 路线 B (企业级/松耦合 - gRPC)： 将 C++ 的几何内核包装成一个 gRPC 服务端。Python Agent 作为客户端，通过 RPC 调用发送“生成倒角”指令；服务端执行 C++ 代码，若捕获到 Standard_Failure，则将错误类型和导致失败的面片法向量打包成 Protobuf 发回给 Agent。这正是企业级 Harness 的标准雏形。

阶段三：打造终极形态——AI CAD Test Harness (系统级评估台)

当你能够让 AI 稳定地读写几何状态后，真正的“护城河”在于评估（Evaluation）。目前的 LLM 评估框架（如 RAGAS）只能评估文本，无法评估三维模型。你构建的 Harness 将定义 AI 生成几何代码的“好坏标准”。

• 核心逻辑： Harness 需要接管 Agent 生成的 C++ 或 PythonOCC 代码，在沙盒中编译运行，并通过底层的几何算法对生成结果进行多维度的强规则打分。
• 工程抓手（评估指标设计）：
  • 有效性校验： 使用 BRepCheck_Analyzer 检查生成的实体是否是流形（Manifold），是否存在自交或未闭合的缝隙。
  • 物理属性比对： 使用 GProp_GProps 计算生成实体的体积、质心、惯性张量，与给定的目标参数进行容差范围内的比对。
  • 拓扑一致性： 检查最终模型的面（Faces）、边（Edges）、顶点（Vertices）数量是否符合设计预期。 为了更清晰地呈现这个系统的骨架，我们可以用可视化的方式拆解它的架构：

把 Harness 建成可复用的工程工具和知识库基础设施，比单纯拼接模型调用脚本更便于验证和持续维护。 在阶段二的跨语言桥梁建设上，你是倾向于使用 pybind11 做直接的内存映射，还是倾向于使用 gRPC 构建分布式的客户端-服务端架构？这决定了你下一步技术栈补齐的具体方向。

Turn 5

👤 User

我还是想成为一名此方向的专业架构师，我希望我在6月份之前，能够在某一个具体功能上，列如圆角功能上搞出一个雏形。

🤖 Assistant

选择“圆角（Fillet）”作为单点突破口，这个技术嗅觉非常敏锐，可以说是直击了 B-Rep 建模引擎的心脏。 在三维几何内核中，圆角和倒角操作极其容易引发拓扑崩溃（例如：圆角半径过大导致相邻面被完全吞噬、多边交汇处的退化点处理、自交等）。目前的通用大模型在生成 CAD 代码时，最容易在圆角操作上“翻车”，因为它们缺乏对局部几何拓扑边界的感知（比如不知道当前边的极限半径 $R_{max}$ 是多少）。 跑通“AI 自动生成、测试并纠错圆角操作”的流程后，可以将其作为继续扩展的工程原型。 可以把这一目标拆成系统级工程步骤，把精力集中在核心链路设计和验证上。

第一阶段：底层几何探针与异常捕获（第 1 - 2 个月）

架构师的第一步，是让 C++ 端拥有“说话”的能力，也就是把底层黑盒翻出来。 在 OpenCASCADE 中执行 BRepFilletAPI_MakeFillet 时，如果操作失败，默认只会返回一个笼统的失败状态。你需要构建一层 C++ 的 Wrapper（包装器）：

1. 细粒度错误拦截： 当圆角构建失败（builder.IsDone() == false）时，不要直接抛出异常，而是向下深挖。提取出导致失败的具体拓扑实体（是哪条 TopoDS_Edge 引起的？相邻的 TopoDS_Face 的法向是什么？）。
2. 几何特征序列化： 将这些出错的局部拓扑信息、以及计算出的相邻边最短长度 $L_{min}$，序列化为 JSON 或 Protobuf 格式。这就像是给 AI 准备的“验尸报告”。
3. 合理分配精力： 既然你手头有实习生资源，不要自己去死磕琐碎的接口封装。你可以负责设计这套 C++ 异常结构的类继承关系，然后安排实习生在一个月内完成具体的代码实现，并要求他们用 Doxygen 配合 Doxygen-Awesome-CSS 搭建好这套 C++ 探针的内部技术知识库，为你后续的跨语言调用扫清文档障碍。

第二阶段：跨语言桥梁与沙盒构建（第 3 - 4 个月）

AI 无法直接运行 C++ 代码，你需要一个中间层。

1. RPC 通信基础设施： 强烈建议使用 gRPC 构建客户端-服务端架构。C++ 端作为 Server，常驻内存并加载基础模型（例如一个方块）。Python 端作为 Client（即你的 Agent），通过 RPC 发送带有圆角参数的指令。
2. 沙盒状态回滚： 圆角操作一旦失败，可能会破坏原始的 TopoDS_Shape。你需要设计一种高效的内存快照或 Undo 机制，确保 Python Agent 在不断试错（Try-Error-Try）的过程中，始终基于正确的初始几何状态。

第三阶段：Agent 纠错闭环与评测台（第 5 - 6 个月）

这是最出彩的部分，也就是构建真正的 Harness 闭环。

1. Prompt 链设计： Python 端的 Agent 接收到 C++ 传回的“验尸报告”。你需要设计一套优秀的 Prompt，让 LLM 理解几何约束。

• 失败提示词示例： “你在 Edge ID 5 上尝试了 10mm 的圆角，但发生拓扑错误。相邻面 Face ID 2 的最小宽度仅为 8mm。请调整你的参数或策略并重新生成代码。”

2. 成功判定： 当 Agent 最终给出一个不报错的圆角方案后，Harness 还要进行“质量评估”。利用 OCC 的底层算法检查生成的实体是否有非流形边、体积是否骤降等。 下面用系统状态流转图说明“圆角自动纠错 Harness”的设计与模块配合方式：

把这样一个专注解决“圆角”痛点的闭环系统做透，比泛泛地做一个“文本生成 3D 方块”的玩具要有价值得多，它能完美证明你驾驭复杂几何引擎和 AI Agent 编排的架构能力。 在第一阶段的底层异常捕获中，你觉得目前最大的难点是 C++ 端复杂拓扑特征（如面片、边）的序列化表示，还是 BRep 算法底层的错误码解析？我们可以针对难点做进一步的方案拆解。

Turn 6

👤 User

我觉着两者都有吧，我需要齐头并进，并把两个方向上的学习路线展示一下

🤖 Assistant

成年人的技术突围，往往就是需要这种“既要又要”的贪婪和魄力。 拓扑序列化是“数据视野”（让 AI 看得见），错误码解析是“逻辑神经”（让 AI 听得懂）。两者齐头并进，才能真正拼凑出一份完整的底层几何“验尸报告”。 以“圆角功能纠错”为切入点，可以把两条技术线按阶段组织为并行的学习与工程路线。

双线并行学习与工程路线图（前 4 个月攻坚）

路线 A：数据视野线 —— 拓扑特征的序列化 (Topology Serialization)

核心目标： 将 C++ 内存中复杂的 B-Rep 数据结构，无损且轻量地提取出来，变成大模型和前端能消化的格式（如 JSON + Mesh）。

• 第 1 个月：攻克拓扑遍历与降维提取
  • 学习重点： 彻底吃透 OCC 的拓扑数据结构（Vertex, Edge, Wire, Face, Shell, Solid）。
  • 实战任务： 熟练使用 TopExp_Explorer。写一个 C++ 脚本，输入一个有圆角的长方体，能够遍历打印出它所有的面（Faces）和边（Edges）的 ID 及类型（如平面、柱面、NURBS 面）。
• 第 2 个月：掌握几何探针与离散化（网格化）
  • 学习重点： AI 很难直接理解高阶解析几何方程，离散化的点云或网格更友好。学习 BRepMesh_IncrementalMesh。
  • 实战任务： 使用 BRep_Tool::Triangulation 将 Face 提取为三角网格（Nodes 和 Triangles）。使用 BRepLProp_SLProps 获取特定面上的法向量（Normal）和主曲率（Curvature）——这对 AI 判断圆角失败至关重要。
• 第 3 个月：定义序列化协议 (JSON Schema)
  • 学习重点： 跨语言数据绑定。引入轻量级的 C++ JSON 库（如 nlohmann/json）。
  • 实战任务： 确立你的第一版“几何切片协议”。把第 2 个月提取的节点、三角面片、法向、曲率数据，打包成结构化的 JSON 字符串输出。

路线 B：逻辑神经线 —— 底层错误状态解析 (Error Parsing)

核心目标： 打破 OCC 祖传的 IsDone() == false 黑盒，深挖算法底层，精准定位导致布尔或圆角失败的“罪魁祸首”。

• 第 1 个月：重构 OCC 异常捕获机制
  • 学习重点： OCC 的异常处理极其古老。了解 Standard_Failure 体系，以及 try-catch (Standard_Failure& e) 的正确捕获姿势。
  • 实战任务： 故意写一个必错的圆角代码（例如，在一个宽度只有 5mm 的边上打 10mm 的圆角）。捕获这个崩溃，并阻止 C++ 进程闪退，这是 Harness 稳定性的基石。
• 第 2 个月：拆解 BRepFilletAPI 的中间状态
  • 学习重点： 不要只看 API 接口，要看源码。深挖 BRepFilletAPI_MakeFillet 背后依赖的 ChFi3d 倒角引擎逻辑。
  • 实战任务： 当 IsDone() 为假时，调用 FaultyShapes() 或 Generated()、Modified() 方法，提取出究竟是哪一条特定的 Edge 导致了构建失败。
• 第 3 个月：构建“故障上下文”解析器
  • 学习重点： 结合几何数学，建立错误原因的分类树。
  • 实战任务： 编写一套逻辑判断：当捕获到错误 Edge 时，自动计算该 Edge 相邻两个 Face 的夹角、以及 Face 的最小宽度。将这些判定结果格式化为：“Error: Fillet Radius (10) > Adjacent Face Min Width (5) on Edge_ID_12”。

第 4 个月：双线汇合 —— 生成“智能验尸报告”

到了第 4 个月，你需要将 A、B 两条线通过一个 C++ 的核心 Controller 组合起来。

1. 当 BRepFilletAPI 抛出异常（路线 B 触发）。
2. 通过路线 B 定位到出错的局部几何体（如 Edge_12 及其相邻的面）。
3. 调用路线 A 的序列化工具，仅对这部分出错的局部几何体进行网格化和法向提取。
4. 组合生成最终的 JSON 投喂给 Python 端的 LLM。 架构级提示： 你在这个阶段面临的最大工程决策，是设计这套跨语言的数据结构。AI 懂 JSON，但 JSON 处理海量三维顶点数据非常臃肿；二进制（如 Protobuf 或直接传 .brep 字符串）很快，但解析起来麻烦。 如果是你来主导这个基础架构，你会选择先在 C++ 端把 B-Rep 转化为人类和 LLM 都极其易读的 冗长 JSON 来跑通第一版原型，还是直接上 Protobuf + 极简标识符 追求企业级性能？

---

Exported from Voyager
Generated on June 15, 2026 at 12:51 PM