机械研发人员如何使用 Claude？

写在前面：我的主业是量化和金融工程，写了十几年代码，跟策略、回测、风控系统打交道。这两年因为给几家制造业客户做数据平台，陆陆续续跟不少机械研发的朋友聊过------从做非标自动化的，到做减速机、注塑模具、医疗器械结构件的。

让我意外的是：AI 在机械行业的渗透，比在金融行业慢了至少一年半，但天花板并不比金融低。

慢的原因不是机械人不聪明。恰恰相反，是这个行业的容错率太低------策略算错了亏钱，零件算错了出人命。所以工程师对"一本正经胡说八道"的东西天然警惕，这是对的。

但警惕不等于不用。金融行业踩过的坑，机械行业没必要再踩一遍。这篇文章我尽量把话说透：Claude 在机械研发里哪些环节能放手用、哪些必须逐项复核、哪些压根别信，以及怎么从"随手问两句"走到"接进自己的工具链"。

一、先把边界划清楚：它不是"更聪明的百度"

我见过太多人第一次用大模型的方式是这样的：

"45 钢的许用应力是多少？"

然后得到一个看起来很像那么回事的数字，然后......就直接用了。

这是最危险的用法。原因很简单：大模型的输出本质上是"最可能的下一句话"，不是"从数据库里查出来的记录"。 它对"这句话听起来对不对"极度敏感，对"这个数字是不是真的"没有内建的校验机制。牌号、标准号、条文编号、材料参数------这几类恰恰是它最容易出错、而你最难一眼看出错的地方。

在量化行业我们有一个说法：永远不要相信一个你无法验证的数字。 这条规矩原封不动搬到机械研发，一样成立。

所以判断"这个任务能不能交给 Claude"，我建议只看两个维度：

输出可验证的程度------我能不能便宜地知道它错没错？（脚本能跑起来、公式能手算复核、CAD 里能重建一遍 → 可验证性高）
出错的代价------错了是浪费半小时，还是把一批模具报废？

把机械研发日常的十来类任务放进这个二维图，长这样：

（图 1：经验示意，非实测数据。气泡大小约等于日常发生频次。）

读图的方式很直白：

右下角（绿色）------放手用。 试验数据处理、技术文档、CAD 二次开发脚本。这些东西的共同点是：产出立刻能验证（图画出来了/宏跑通了），错了成本极低（重跑一次）。这一块你几乎可以闭着眼睛用，而且它占据了你日常时间的很大一块。
右上角（蓝色）------用，但每一项都要复核。 解析法校核、有限元脚本、DFMEA。它能帮你把框架和过程搭出来，但每个系数、每个边界条件你必须自己过一遍。
左上角（红色）------只当检索线索，绝不当结论。 标准条文、材料牌号参数、专利。它可以告诉你"你大概该去查 GB/T XXXX 和 ISO XXXX 这两个方向"，但具体条文内容、具体数值，必须回到原始标准文本去核对。
左下角（黄色）------半自动。 让它给结构、给清单、给对比维度，数字你自己填。

这张图我建议你打印出来贴在工位上。它比任何"AI 提示词大全"都有用。

二、四种使用形态：大多数人卡在第一格

很多人说"Claude 也就那样"，问下来发现，他用了三个月，全程只在网页对话框里一问一答。这就像买了台五轴加工中心，只拿来当台钳用。

Claude 现在实际上有四种截然不同的使用形态，能力差异极大：

（图 2：五维打分为主观经验评估，用于说明差异量级。）

第一形态：网页/App 对话。 上手成本为零，适合临时问题、思路发散、翻译。缺点是每开一个新会话，它对你项目的一切都一无所知，你得反复交代背景。

第二形态：Projects（项目）+ Skills（技能）。 这是分水岭。你可以建一个项目，把这些东西一次性放进去：

你们公司的设计准则、命名规范、图纸标注习惯
常用材料的实测数据表（你自己验证过的）
项目的技术协议、验收标准
你希望它输出的报告模板

之后在这个项目里的每一次对话，它都自带这些上下文。从"通用助手"变成"熟悉你们项目的新同事"，就是这一步的价值。

而 Skills 更进一步------它是一组"做某类事情的标准作业指导书"。比如你可以写一个"试验报告生成"技能，把报告结构、图表样式、单位规范、公司抬头全部固化进去，之后只要说"用试验报告技能处理这批数据"，出来的东西格式就是对的。

第三形态：Cowork / 桌面端直接操作文件。 这个形态对机械研发特别关键，因为你们的工作产出物是文件：Excel 数据、Word 报告、PPT 评审材料、CSV 测试记录。让它直接读一个文件夹、处理里面几十个文件、生成结果，比你复制粘贴到对话框里高效一个数量级。

第四形态：Claude Code + MCP。 这是天花板，也是上手成本最高的一档。Claude Code 是跑在命令行/编辑器里的智能体，能读写你本地的整个代码库和文件；MCP（Model Context Protocol）则是一套标准接口，让它去连接外部系统------数据库、PDM/PLM、内部 API。

对机械研发来说，第四形态意味着：它可以直接改你的仿真脚本、直接调用 CAD 的 API、直接读你们试验台的数据库。 后面第六节展开讲。

我的建议是：别一步跳到第四格，但也别在第一格待超过一个月。 第二、第三形态的性价比最高。

三、七个具体场景，带提示词模板

理论说完了，上干货。以下场景按"从易到难"排列。

场景 1：把技术协议拆成可执行的设计输入

拿到一份客户的技术协议或招标文件，最费神的不是读，是把散落在三十页里的约束条件抽出来，变成一张设计边界清单。

提示词模板：

markdown 复制代码

角色：你是机械结构设计工程师。

任务：阅读我附上的技术协议，输出一张"设计输入清单"表格。

  


表格列：

| 序号 | 条款出处（页码/条号）| 原文要求（摘录）| 转化为设计参数 | 类型（硬约束/软目标/待澄清）| 影响的子系统 |

  


要求：

1. 只提取真正构成设计约束的内容，不要复述背景描述。

2. 凡是原文表述含糊、存在多种解释的，一律标"待澄清"，并写出你的疑问。

3. 不要替我做假设。缺的信息就标缺失，不要编。

4. 最后单独列出"我认为客户可能没意识到的冲突项"。

最后那句是关键。大模型最有价值的地方之一，是它不会疲劳，能一致地把所有条款两两对照一遍------比如"要求整机重量 ≤ 80kg"和"要求防护等级 IP67 且外壳材料为不锈钢"这种潜在打架，人读到第 25 页时容易漏，它不会。

场景 2：方案对比与选型决策矩阵

选型这件事，难的从来不是找方案，是把评价维度想全。

css 复制代码

背景：[简述工况、载荷、环境、成本/交期约束]

候选方案：A. [...] B. [...] C. [...]

  


请做三件事：

1. 先不评分。先列出你认为这个决策应该考虑的全部评价维度，

并说明每个维度为什么重要。特别注意列出我可能忽略的维度

（维护性、备件供应、产线适配、认证难度、失效模式后果等）。

2. 给出一个加权决策矩阵的空表，权重先留空由我填。

3. 针对每个方案，列出"最可能让它翻车的三个风险点"。

注意我让它先别评分 。如果你一上来就问"哪个方案好"，它会给你一个看起来很笃定的答案，而那个答案的权重是它拍脑袋定的。决策权必须留在你手里，AI 只负责保证你的选项集和评价维度是完整的。

场景 3：标准与法规------最危险的场景，也是最容易翻车的场景

我把丑话说在前面：不要问 Claude "GB/T 3480 里齿面接触疲劳的计算公式是什么"，然后直接抄。

它有很大概率给你一个形式正确、系数错误的公式。更糟的是，它可能给你一个看起来很像但已经废止了的版本的内容。标准会改版，模型的知识有截止日期。

正确用法是把它当作导航员 ，而不是图书馆：

markdown 复制代码

我在做 [XX 设备] 的 [XX 部件] 设计，出口欧盟。

请帮我梳理：

1. 我大概需要符合哪些方向的标准/指令？按体系分类列出（安全、EMC、材料、环保等）。

2. 每个方向，列出最可能适用的标准编号和名称，并标注你的把握程度（高/中/低）。

3. 明确告诉我：哪些是我必须去官方渠道核对现行版本的。

4. 不确定的地方直接说不确定，不要给我编一个标准号。

然后拿着这份清单，去标准全文数据库逐个核对。

这套流程能把"从零开始查标准"的两天工作量压到半天，同时不引入任何错误------因为最终依据的仍然是原始文本。 如果你的 Claude 配置了联网搜索，让它带上出处链接，核对会更快，但"回原始文本"这一步永远不能省。

场景 4：计算校核------让它写脚本，而不是让它算数

这是我最想强调的一点，也是从量化行业带过来的经验。

永远不要让大模型直接给你算数结果，要让它给你一段可执行的计算脚本。

区别在哪？

让它算：你得到一个数字，没法验证过程，它可能在第三步算错了小数点。
让它写脚本：你得到一段代码，公式是显式写出来的，你能逐行看懂、能改参数、能跑边界工况、能跟手算对照、能存档复用。

举个轴的强度校核的例子，提示词：

markdown 复制代码

请用 Python 写一个阶梯轴的强度校核脚本，要求：

  


工况：[转速、功率、支承跨距、齿轮/带轮位置与受力、材料牌号]

  


脚本要求：

1. 所有输入参数集中在文件顶部的字典里，带单位注释。

2. 每一个公式，在代码注释里写明：公式名称、依据的教材/标准来源、

以及各符号含义。我要能逐行核对。

3. 分步输出：支反力 → 弯矩图数据 → 扭矩 → 当量弯矩 → 各危险截面应力

→ 安全系数。中间量全部打印，不要只给最终结果。

4. 用 matplotlib 画弯矩图和扭矩图。

5. 单独写一个函数做量纲检查。

6. 最后列出这个脚本没有考虑的因素（应力集中、疲劳、临界转速等），

提醒我哪些需要另行校核。

第 3 条"中间量全部打印"和第 6 条"列出没考虑的因素"，是这个模板里最值钱的两句。前者让你能在任意一步截断验证，后者防止你被一个"安全系数 2.3，通过"的结论麻痹。

交叉验证的小技巧：同一个校核，让它用两种独立方法各写一遍（比如解析法 + 简单有限元/数值积分），两个结果对不上，说明至少有一个错了。这在量化里叫"双实现校验"，成本很低，抓错率很高。

场景 5：仿真------脚本、参数化扫描、后处理

有限元的痛点从来不是软件不会用，是重复劳动太多：改一个尺寸重跑一遍、几十个工况手动提数据、后处理表格贴到报告里。

Claude 在这里能干三件事：

（1）写 APDL / Python 脚本（Abaqus、ANSYS Mechanical、OpenFOAM 等）。 它对这些脚本语言的掌握程度，说实话比大多数偶尔用一次的工程师熟。

（2）参数化扫描。 让它写一个循环，把设计变量的组合全跑一遍，输出成 CSV。这个活儿本身不难，但手写要一小时，它三分钟给你。

（3）后处理与结果解读。 把结果 CSV 丢给它，让它画图、找极值、做敏感性排序、生成对比表。

一个非常重要的安全习惯：让它生成的脚本，第一版必须是"只读"的。 就是说先只做提取和计算，不做任何修改模型、覆盖文件的操作。等你看懂了、跑通了，再放开写权限。这跟量化里"新策略先跑纸面交易"是同一个道理。

场景 6：CAD 二次开发------被严重低估的一块

SolidWorks、Creo、NX、CATIA 都有 API。绝大多数机械工程师知道有这东西，但没时间学 VBA/C#/Python 去写。

这恰恰是大模型最擅长的领域------它写代码比写别的靠谱得多，而且 CAD 宏的验证成本极低：跑一下，看模型对不对，一眼就知道。

能立刻省时间的场景：

批量修改属性（材料、代号、图号、自定义属性）
批量导出（工程图转 PDF/DXF、模型转 STEP）
批量出图（按模板生成工程图、自动标注视图）
参数化建模（输入一组尺寸生成一个系列型号）
BOM 提取与格式转换（把装配树导成公司要求的 Excel 格式）

提示词的要点：说清楚软件版本、API 语言、以及"先在测试文件上跑"。

markdown 复制代码

请用 [C# / VBA / pywin32] 为 SolidWorks [版本] 写一个宏：

功能：遍历指定文件夹下的所有 .SLDDRW，另存为同名 PDF 到子文件夹 output。

要求：

1. 完整可运行，包含所有必要的引用和错误处理。

2. 处理失败的文件写入日志，不要中断整个批处理。

3. 只读原文件，不做任何修改和保存。

4. 在代码开头加一行明显的注释，提示我先在测试副本上验证。

场景 7：试验数据、报告与评审材料

这是"放手用"区域里最肥的一块肉。

典型流程：试验台导出一堆 CSV → 清洗（去掉预热段、剔除异常值）→ 计算（效率、温升速率、频谱）→ 画图 → 塞进 Word 报告 → 再做一版 PPT 给评审会。

这整条流水线现在可以基本自动化。你把原始数据丢过去，说清楚要什么，它能直接产出格式规范的 Excel、Word、PPT 文件。配合前面说的 Skills，格式一次固化，之后每次都一致。

这里省下的时间是纯赚的，因为报告格式再漂亮也不产生工程价值，它本来就该被自动化掉。

四、时间到底省在哪？省的是"写"，不是"判断"

我把上面几个场景做了一次粗略的时间账。注意看红色那一段：

（图 3：经验示意数据，用于说明结构，不代表你的实际情况。）

关键结论有两条：

第一，人工复核这段（红色）永远不会消失，而且不应该消失。 任何声称"AI 全自动完成结构设计"的说法，要么是在骗你，要么是在骗自己。你的签字是要负法律责任的，而模型不负任何责任。

第二，越是"输出可验证"的任务，净节省越高。 试验数据处理能省八成以上，因为图画出来对不对你一眼能看出来；而 DFMEA 只能省六成左右，因为每一条失效模式你都得凭经验判断合不合理。

所以真实的效率提升，来自把大量"写字、画图、敲代码、排版"的机械劳动挤掉，把你的时间集中到"判断"上。对研发来说这是好事------判断本来就是工程师价值的所在，而不是排版。

五、提示词工程：机械行业的三条特殊纪律

通用的提示词技巧网上一堆，我不重复。只说三条针对机械研发的：

纪律一：单位、坐标系、符号约定，必须在提示词里明确写死。

这是血泪教训。"轴向力 5000"------牛顿还是千克力？"温度 200"------摄氏还是华氏？模型会自己猜一个，而且猜得很自信。

标准做法是在每个技术类项目里预置一段"约定"：

diff 复制代码

【全局约定，本项目所有对话适用】

- 单位制：SI。长度 mm，力 N，应力 MPa，扭矩 N·m，温度 ℃。

- 坐标系：右手系，Z 轴竖直向上。

- 涉及任何数值时必须带单位，禁止裸数字。

- 如果我给的数据缺单位，先问我，不要假设。

纪律二：给它"拒绝回答"的权利，而且明确要求它区分把握程度。

大模型有强烈的"有问必答"倾向，这是它的缺陷。你需要主动给它台阶下：

css 复制代码

对每一条结论，标注置信度：

[已知确定] ------ 基础原理/数学推导，我可以负责

[需要核对] ------ 我有印象但可能记错版本或数值

[不确定] ------ 我在猜，请勿采用

加了这一句之后，输出质量的可用性会明显提升。不是因为它变聪明了，而是因为它把不确定的地方标出来了，你知道该重点核对哪里。

纪律三：要求它先复述任务，再动手。

复制代码

在开始之前，先用你自己的话复述一遍：

我要解决的工程问题是什么、约束是什么、你打算怎么做。

等我确认后再开始。

复杂任务上，这一步能避免它跑偏两千字之后你才发现理解错了。这在机械领域尤其重要，因为工况描述本身就复杂，一个"简支"还是"固支"的误解，后面全白干。

六、进阶：把它接进你的工具链

到这一步就跟软件工程接轨了。核心是两个东西：

Claude Code------跑在终端或编辑器里的智能体，能直接读写本地文件、执行命令。对机械人的意义：你的仿真脚本、后处理程序、CAD 宏、数据处理工具，全都可以让它直接改、直接跑、直接调试，不用来回复制粘贴。

MCP（Model Context Protocol）------一套让模型连接外部系统的开放标准。有了它，可以把 Claude 接到：

内部试验数据库（自然语言查历史试验记录）
PDM/PLM 系统（查图号、查版本、查变更记录）
供应商价格表、库存系统
内部标准文档库（这个尤其香------用你们自己审核过的标准文本做检索，就绕开了模型瞎编标准的问题）

最后那条我要单独强调：解决"模型编造标准"最彻底的办法，不是反复叮嘱它别编，而是把真实文档接给它。 让它基于你提供的文本回答，并要求标出处。这在业内叫 RAG（检索增强生成），是把大模型用在专业领域的标准解法。

上手路径不用一步到位，我画了一张 12 周的路线图：

（图 4：建议节奏，可按团队情况伸缩。）

这张图的逻辑是先建立信任，再谈自动化 。前三周你什么都不改，就是每天拿三个真实问题去问它，同时验证它的答案对不对。这个阶段的目的不是省时间，是建立你对它能力边界的直觉------哪类问题它靠谱，哪类不靠谱，这个直觉只能靠自己试出来，别人告诉你没用。

七、风险清单：五条不能碰的红线

作为在强监管行业待久了的人，这部分我必须写。

1. 保密。 未经批准，不要把涉密图纸、核心工艺参数、客户技术协议、未公开专利内容传给任何外部 AI 服务。这是最常见也最致命的合规事故。 正确做法是：先搞清楚公司政策，走企业版/私有部署，或者把数据脱敏（把真实尺寸替换成量级相同的假数据，逻辑照样能验证）。

2. 责任边界。 出图的是你，签字的是你，出事担责的是你。AI 的输出在法律上等同于"网上搜到的资料"------参考价值有，责任承担为零。别在评审会上说"这是 AI 算的"。

3. 标准与牌号。 前面说过，再说一遍。具体条文、具体数值，必须回原始文本。

4. 版本管理。 AI 生成的脚本一定要进 Git（或者至少有规范的版本文件夹）。我见过工程师用 AI 改仿真脚本改到自己都不知道哪版是对的，这比不用还糟。这是软件行业二十年前就解决的问题，直接抄作业就行。

5. 能力退化。 这条最少人提，但我认为最重要。如果你从来没自己推过一遍轴系校核，就直接用 AI 生成的脚本，那你永远不具备判断它对不对的能力------而判断力恰恰是这个职业最后的护城河。

AI 应该是放大你判断力的杠杆，不是替代它的拐杖。 杠杆的前提是你本来就有力量。

八、写在最后

我在量化行业观察到一个规律，我觉得它对机械行业同样成立：

AI 不会淘汰工程师，但会极大地拉开工程师之间的差距。

原因在于杠杆效应。同样一个 AI 工具，判断力强的人用它能一天干完一周的活，因为他能快速识别哪些输出可信、哪些要推翻；判断力弱的人用它反而更危险，因为他会把一个错误的结论以更快的速度、更漂亮的排版扩散出去。

所以对机械研发的朋友，我的建议就三句话：

从"输出可验证"的任务开始用，先把试验数据、文档、脚本这三块吃掉，这是纯收益。
永远不要跳过复核那一步，省下的时间要花一部分在验证上，这是买保险。
把省下来的时间投回到判断力上------多看失效案例、多下车间、多做实物验证。这些是 AI 永远给不了你的，也正是你的价值所在。

工具会一直变，判断力不会过时。