一个工厂老兵，试图把老师傅的报价经验装进 AI
在 CNC 非标加工行业，一张图纸抵达工厂后，通常不会立刻变成一串价格。
报价员需要先判断材料和毛坯尺寸，再识别孔、槽、曲面、薄壁等几何特征，然后手动评估需要使用几轴机床、什么刀具、安排多少道工序。
公差、表面处理、装夹次数、材料利用率以及工厂当前的设备和人工成本，都会改变最终结果。
对于标准件，这套流程可以被固化在系统中，但非标零件这套流程就复杂多了，处理这类非标准件每一张图纸都可能意味着一次重新计算。
曹冬冬在工厂里做了 15 年工业产品。
过去，他看到的报价方式往往高度依赖人：老师傅打开图纸，凭经验判断加工难度，再结合材料、工时和损耗给出价格。一套复杂图纸，可能需要两三个小时才能完成报价。
经验丰富的人能够迅速发现薄壁变形、深孔加工或者多次装夹带来的额外成本，但这些判断通常存在于个人脑中，很少被完整记录下来。人员一旦离开，经验也很难留在工厂。
这是曹冬冬决定开发一套 AI 报价系统的起点。
他不是算法工程师，也没有专业软件开发经历。从零开始学习大模型、Python 和本地推理后，他完成了“Union·由你｜CNC 非标智造炼金术师报价系统”，并获得 AMD 锐龙 AI 智能体应用创新大赛专业组 OPC 一人公司赛道冠军。
不过，比比赛结果更值得讨论的是：一个缺乏传统 IT 背景的工业从业者，如何把分散在图纸、Excel 表格和老师傅经验里的知识，重新组织成一套可以执行的智能体系统。
报价不是让大模型“猜一个数字”
曹冬冬做出的第一个版本并不复杂。
系统先解析 STEP 格式的三维图纸，提取零件尺寸、孔、基本面和薄壁等几何特征，再由本地模型判断可能采用的工艺，最后调用 Python 公式计算材料、工时和表面处理成本。
整个流程最重要的三个步骤是：图纸解析、模型判断和公式计算。没有多智能体，也没有庞大的工业知识库。
这套设计从一开始就确立了一条边界：大模型不直接负责计算最终价格。
“把误差直接交给 LLM 去做心算，是算不准的。”曹冬冬说。
在他的理解中，大模型更适合进行工艺探索，例如判断一个零件可能采用什么加工路线、选择哪些刀具和材料；涉及材料用量、加工时间和成本加总时，则应交给确定性的程序完成。
因此，系统会先从图纸中取得结构化数据，再让模型选择或者生成计算逻辑，最后调用 Python 执行公式。大模型负责“选”，程序负责“算”。
这也是系统控制模型幻觉的主要方式。
如果让模型根据一张图纸直接生成报价，它给出的数字可能看起来合理，却很难回答尺寸从哪里获得、工时如何推导、损耗率为何这样设置。一旦报价偏低，工厂可能在接单后才发现亏损；报价过高，又可能直接失去订单。
曹冬冬因此将计算过程尽量“白盒化”：工程师能够看到系统识别了哪些特征、选择了什么工艺、调用了哪些公式，也可以在中间环节修改参数。
“你不能只告诉我一加一等于二，还要让我看到它为什么等于二。”他说。
这并非只有 AI 系统才需要面对的问题。成熟的工业报价软件同样强调成本结构的可追溯性。西门子的零件订单管理产品允许企业在不同报价模板中设置自定义成本要素，并将计算过程透明作为报价可靠性的基础之一。
多智能体被做成一条数字流水线
在最初的三步闭环跑通后，曹冬冬开始向系统中增加新的模块。
目前，这套系统已经被拆分为图纸解析、DFM 可制造性分析、工艺评估、质检、财务和风险控制等多个智能体。每个智能体只处理一项相对明确的任务，上一环节输出结构化结果，再交给下一环节处理。
这种架构看起来像大模型行业常见的多智能体协作，但曹冬冬更愿意把它理解为工厂报价流程的数字化重组。
工厂原本的报价流程就是串行的：先看懂图纸，再确定工艺和设备，随后估算工时、材料和利润。系统没有凭空创造一套新方法，只是把原有流程拆开，将其中一部分交给模型和程序。
但智能体数量增加后，问题也很快出现。
如果图纸分析、工艺判断、财务和风险控制等智能体同时运行，它们会争夺内存和计算资源；如果全部改为串行，又会拉长等待时间。上下文不断累积，还可能导致模型遗忘前面的信息，或者在长链路中调用错误的工具。
曹冬冬最初尝试让多个智能体并发，结果出现内存占用迅速升高、返回结果拥堵等情况。
后来，团队采用了折中方案：部分任务并行执行，但结果按照顺序返回；智能体之间尽量传递结构化字段，而不是大段自然语言，以减少上下文长度和 Token 消耗。
并不是每一步都需要大模型参与。
STEP 图纸解析、CAD 库调用和 Python 计算主要由 CPU 完成；规模较小的知识库检索也可以在 CPU 上运行；需要复杂工艺推理和工具调用时，系统再启用 GPU 上的本地模型。
系统由此变成了一条混合流水线：确定性的工作交给传统程序，存在多种可能路径的判断交给模型，最后再由程序完成精确计算。
为什么选择锐龙 AI Max+ 395？
系统架构基本确定后，曹冬冬需要回答另一个问题：它应该运行在哪里。
最直接的办法是调用云端大模型 API。云端模型参数规模更大，也不需要开发者自己处理驱动和硬件适配。但对这套系统来说，模型能力并不是唯一变量。
系统需要读取客户的三维图纸、工艺参数、历史报价以及工厂的设备和成本数据。图纸可能涉及尚未公开的产品结构，历史报价则能够反映一家工厂的材料渠道、设备效率和利润空间。部分客户还与大型企业或特殊行业客户签署了保密协议，不愿意把文件发送到外部服务器。
工厂的网络环境也是现实约束。生产现场可能存在弱网、内外网隔离甚至完全离线的情况。一套依赖云端 API 的报价系统，在办公室里可以运行，进入车间后却未必稳定。
曹冬冬因此希望把图纸解析、知识库检索、模型推理和公式计算尽可能留在本地。
但本地运行又带来一个问题：模型越大，需要的内存或显存越多。
普通消费级显卡的显存通常难以同时容纳数十亿参数模型、长上下文、向量数据库和多个智能体的运行状态；专业级 GPU 工作站又可能超出小型工厂的预算和运维能力。
曹冬冬最终使用了一台搭载 AMD 锐龙 AI Max+ 395 的设备。
锐龙 AI Max+ 395 并不是一块独立显卡，而是一套同时集成 CPU、GPU 和 NPU 的处理平台。
根据 AMD 公布的信息，它采用 16 核 32 线程 Zen 5 CPU，集成拥有 40 个计算单元的 Radeon 8060S GPU 和最高 50 TOPS 算力的 XDNA 2 NPU，最高可配置 128GB LPDDR5x 统一内存。
AMD 开发平台给出的内存带宽为 256GB/s。
对这套报价系统而言，影响方案选择的主要因素不是 NPU 的标称算力，而是 128GB 统一内存。
传统 CPU 加独立显卡的系统中，系统内存和显存彼此分离。模型权重一旦超过显存容量，就需要频繁搬运数据，或者通过量化缩小模型。锐龙 AI Max+ 395 采用统一内存架构，CPU 和集成 GPU 可以使用同一个内存池。
这意味着，一台相对紧凑的设备可以同时容纳本地模型、知识库、图纸解析程序和操作系统，而不需要再为每一部分准备独立服务器。
曹冬冬最终没有选择 7B 小模型，也没有继续追求参数规模更大的 70B 或 MoE 模型，而是把约 35B 的稠密模型作为主要推理模型。
他的判断标准不是单纯比较参数量，是在内存占用、生成速度、上下文长度和工具调用稳定性之间寻找平衡。
“不是把模型装进去就结束了，后面还有知识库、STEP 解析、系统开销和多个 Agent。”曹冬冬说。
统一内存也不意味着这类设备能够取代数据中心 GPU。
虽然它可以容纳更大的模型，但生成速度仍然受到内存带宽、模型结构、上下文长度和软件优化程度影响。面对高并发在线服务或者对响应时间要求很高的工作负载，数据中心 GPU 仍有明显优势。
曹冬冬选择这一平台，实际是在空间、成本、模型容量和部署方式之间做了一次取舍：它不需要处理大量用户并发，只需要在工厂现场完成一条持续数分钟、但包含多个步骤的报价流程。
所以综合起来，曹冬冬选择锐龙 AI Max+ 395 主要有以下四点原因：首先是 128GB 统一内存可在本地运行 27B 稠密模型，并为上下文和知识库留出空间；其次，ROCm 支持 PyTorch、llama.cpp 等工具，降低环境配置门槛；第三，集成 GPU 和 256GB/s 内存带宽能够改善本地推理延迟；第四，同时支持 STEP 图纸解析、CAD 处理与渲染，可接入现有工业设计流程。
硬件装得下，软件不一定跑得顺
模型能够被装进内存，并不意味着系统可以直接运行。
曹冬冬拿到设备后，最初按照过去使用 CUDA 的经验配置环境，很快发现两套软件生态并不相同。CUDA 是英伟达的 GPU 计算平台，无法直接用于 AMD 集成 GPU。要让 PyTorch、llama.cpp 等工具调用锐龙 AI Max+ 395 的 GPU，需要转向 ROCm 或者其他受支持的后端。
在 Linux 环境中，曹冬冬使用 ROCm 和 llama.cpp 运行本地模型，并通过 ROCm SMI 查看 GPU 利用率、内存占用和温度。他称，经过调试后，35B 模型在其项目中的生成速度约为每秒 20～30 个 Token。
这个速度不适合承担大量用户同时访问的在线服务，但报价也不是实时聊天。按照团队测试，一个简单零件可以在约 3 分钟内完成分析，而人工完成类似报价往往需要两三个小时。
更大的问题出现在系统进入工厂之后。
团队最初主要在 Linux 环境下开发，后来为了适应客户环境，将软件迁移到 Windows 专业版。直到现场部署时，他们才发现部分客户使用的是长期不升级的 Windows 企业版，同时安装了严格的安全软件。原本能够正常启动的组件可能被拦截，容器、驱动和依赖库也不一定符合工厂的 IT 策略。
“开发环境里跑通，不等于到了客户那里也能跑。”曹冬冬说。
图纸本身也可能出问题。部分 STEP 文件编码不规范，常规解析器可能报错甚至崩溃。团队不得不增加降级策略：标准解析失败后尝试容错读取，再处理缺失字段；无法确认的部分则交回人工检查。
这些问题让曹冬冬意识到，从 Demo 到产品之间，隔着的不只是模型能力，还有操作系统、驱动、文件兼容性和现场运维。
本地部署保护了图纸，也提供了离线能力，但代价是软件提供者必须承担更多适配工作。云端 API 隐藏掉的硬件和框架差异，在本地环境中都会重新出现。
本地不是唯一答案
虽然把本地运行作为产品的重要方向，曹冬冬并不认为所有任务都应该留在本地。
他设想的长期架构仍然是端云混合：涉及工厂商业机密且调用频率较高的任务放在本地，包括图纸解析、专属知识库、历史报价查询和基础工艺判断；对于本地模型难以完成的复杂工艺，或者需要更广泛行业知识的任务，再调用云端模型进行校验。
对一家工厂而言，选择本地还是云端，最终要取决于具体条件。
如果图纸允许上传、网络稳定、调用频率不高，云端 API 可能更加省事；如果任务需要高并发或更大的模型，一台本地设备也未必划算。只有在数据不能离场、系统需要离线运行，同时任务规模又能被单台设备承载的情况下，统一内存和本地推理才具有直接价值。
“没有云端 API 之后，产品究竟增加了什么？”这是曹冬冬认为开发者首先应该回答的问题，“如果只是为了本地而本地，那就没有必要。”
目前，这套系统已经迭代至第 12 个版本。
在最初的图纸解析、报价和数据库能力之外，曹冬冬又增加了 DFM 分析、可制造性判断、多路径工艺探索、白标网站和 Docker 部署等功能。对于标准轴套、法兰等零件，系统的完成度相对较高；面对复杂工件和成套产品设计时，仍然需要人工完成后续修改。
不同工厂的报价习惯也是产品复制过程中必须解决的问题。
一家工厂可能擅长加工不锈钢，另一家更熟悉铝合金；设备型号、刀具库存、工人工资和利润要求也不一样。即使输入同一张图纸，两家工厂给出的合理价格也可能不同。
曹冬冬称，团队已经根据不同设备和加工能力制作了 10 套初始模板，希望先覆盖一家工厂约 80%的基础情况，再结合其历史订单和实际反馈进行校准。
他在采访中提到，系统经过一段时间使用后，报价准确率目标是达到 95%以上。
但这一数字目前仍属于团队内部测试和规划，需要在更多零件类型、不同工厂和真实订单中进一步验证。
截至采访时，产品正在 3 家工厂进行种子测试，并与更多潜在客户洽谈。
下一步，曹冬冬计划先采用通用设备加预装软件的方式交付，再根据部署数量和客户反馈，判断是否有必要开发专用的一体机。
回顾整个开发过程，曹冬冬反复提到的并不是参数量，而是“最小闭环”。
“先跑通 STEP 解析、本地模型和 Python 计算，哪怕只是一个很简单的 Demo。知道问题在哪里以后，再增加知识库、多智能体和容错机制。”
从这个角度看，大模型并没有直接取代老师傅，也没有独自完成报价。它首先承担的，是把老师傅过去难以表达和传递的经验，拆成一条可以检查、修改和反复执行的流程。
而锐龙 AI Max+ 395 在其中扮演的角色，也不是替系统解决所有问题。它提供了一块能够在本地容纳模型、知识库和传统工业软件的计算底座；至于图纸能否读懂、工艺能否判断正确、系统能否进入真实工厂，仍然需要开发者一层一层补上。
