跑通 ≠ 跑对:用 DeepSeek 类模型做 MATLAB / Simulink 仿真

Running ≠ correct: a practical workflow for driving DeepSeek-class LLMs to produce verifiable MATLAB / Simulink simulations — focused on numerical verification and human root-cause judgment, not just getting code that runs.

有一次我把一套裂缝扩展的 DDM 求解器从 Python 移植到 MATLAB,让模型照着参考实现写。 代码很顺地跑通了,也出了裂缝张开的结果,乍看没什么问题。可我一查全局影响系数矩阵的条件数, RCOND 到了 1.9e-39——矩阵基本是奇异的,那个"看着对"的结果数值上根本是垃圾。 模型不会主动告诉我这件事,因为对它来说代码"能跑"就算交差了。

我没在算法参数上瞎调,而是回到 Python 参考实现逐行对公式,最后发现问题出在影响系数的积分核: MATLAB 版写成了 ∫R dS,参考实现是 ∫(r/R³) dS。积分核的量纲错了,直接决定了矩阵病态。 换回正确的核,矩阵条件数恢复正常,结果也能和参考实现对上。

这件事是这份文档的由来。在工程仿真里,让 AI 写出"能跑"的代码是整个流程里最容易的一段; 难的是判断它写得到底对不对。而几乎所有关于 AI 辅助编程的讨论都停在"能不能跑通、效率高不高", 跳过了这件最要命的事——跑通不等于跑对,一个能跑、还画得出漂亮波形的仿真,数值上可能从头错到尾。 这份文档讲的就是怎么解决它:怎么把任务切成有可验证产出的小块,怎么用 run-verify 回路逼出正确结果, 怎么在模型判不了对错的地方靠人把关。

工具上我绕了一圈才落定:最早用 windsurf 直接操控 MATLAB 的 COM 接口,后来换 opencode 的 plan/code 模式——但这俩模式要人工切换、呆板低效,最后落在 Claude Code 直接接 DeepSeek。 DeepSeek 产出快、迭代快,需求说清楚就能高效出活;但"能产出"和"产出正确"是两回事, 后者才是本文要解决的。

贯穿全篇的一个前提:模型对"对不对"没有可靠的自我判断,它的价值在于快速产出和快速改; 判对错、定根因这两件事必须由人锚住(详见第 4、6 块)。下面六块按这个逻辑展开。

可复现例子

• examples/robot_arm_ctc_interp_demo:第 4.7 节的六自由度机械臂 CTC 例子。它用同一组 waypoint 分别跑 linear 和 spline 插值,展示"位置跟踪看起来正常,但 linear 会在力矩里打出周期尖峰"。脚本会输出曲线图和关键统计值,当前 J3 力矩峰值比约为 5.44。

---

1. 适用什么类型的任务

适合的共同特征:

• 数学 / 物理模型清晰,有参考实现或参考文献可对照(移植类、复现类)。
• 结果可量化验证:波形形状、收敛值、矩阵条件数、力矩曲线、误差量级——能用一个数或一张图判对错。
• 单机本地 MATLAB 能跑,迭代回路短(改一版几十秒到几分钟看到结果)。

实测跑得通的任务类型:

• 控制算法仿真:电力电子 / 电机(NTSMC、NFTSM、ADRC、PHF 无感 FOC、导纳控制等)。
• 数值方法移植:把已有的 Python / 参考实现搬到 MATLAB(裂缝扩展 DDM、DDM-FVM 耦合、砂土液化)。
• 论文 / 报告出图:按参考文献的出图模式批量画图。
• Simulink 程序化建模:用脚本搭 Simscape Electrical(powerlib)电路或控制框图,自动连线。
• 课程设计 / 客户报告交付:含旧版本(如 R2017)兼容要求。

吃力 / 不适合(详见第 6 块):

• 没有参考真值、纯靠模型判断对错的探索性研究。
• 强依赖现场状态、要先读旧模型再外科手术改的紧耦合改稿。
• 对美观 / 排版有高要求的 Simulink 布局(能做,但费人工)。

---

2. 一个需求怎么拆成能交给模型的子任务

按"每个子任务都有独立、可验证的产出"来切。典型分层:

1. 环境探测——版本、工具箱、块路径、参数名。必须放最前面,因为后面全部依赖它。
2. 参数与数据准备——电机 / 材料参数表、struct、轨迹 waypoints、边界条件。
3. 核心算法 / 模型单元——控制律、影响系数、ESO、积分核等,一个一个写。
4. 求解 / 仿真驱动——solver 选型、步长、积分方式、循环耦合。
5. 后处理与出图。
6. 验证与对照——与参考实现 / 文献对数。
7. 交付整理——文件分类、报告渲染。

拆解时的两条判断:

• 哪些整段丢给模型写:规格已定死、一次能跑完、不依赖现场状态的(独立函数、批处理出图脚本)。
• 哪些留在贴近现场的主回路里做:要先读现有模型 / 文件状态、每步都得在本机跑着改的。 这类转包给便宜模型不划算——把诊断、坐标、现有代码再喂一遍的成本,常常比直接写还高。

工具约束补一句:Simulink 这种,逻辑上按上面分层,但"建块 + 连线 + 保存"在实操里要尽量 压进一次调用完成(中途关模型会丢未保存的连线),所以"子任务边界"和"一次调用边界"不完全等同。

---

3. 怎么 prompt 让它产出能用的 MATLAB 代码 / Simulink 配置

话术分两层,这是这套打法最容易被忽略的点。看历史会话里真实发出去的 prompt, 绝大多数是高层委派、很短,例如:

• "根据需求文档建模,用 MATLAB 的 MCP 跑,跑完生成结果图"
• "生成对应需要的图片吧 / 图片也要重新生成并删掉旧图"
• "最后再复查一下客户的需求"
• (客户给一段运行模式文字 + 一张系统图)"按这个建 Simulink 模型"

也就是说,具体的工程约束(MATLAB 版本、已知坑、验证标准、看图协议)不靠每条 prompt 重复打, 而是前置固化在持久文件里——全局规则文件、skill 说明、项目的 HANDOFF / STATE / 协议文档。 模型每次会话开头读这些,等于把"长 prompt"摊销成了一次性配置。所以"怎么 prompt"真正的功夫 在于:把下面这些护栏写进持久文件,而不是指望临场把它们说全。

要固化进持久文件的护栏 ——

让它探测,别让它猜:

• 明确告诉它 MATLAB 版本(块参数名、默认值、可用块都随版本变)。
• 要求"先用 get_param(block,'DialogParameters') 列出可设参数,确认后再 set_param"。
• 要求"先在 new_system 里测块的参数名,跑通再写进正式 build"。

把已知坑写进 prompt 当护栏(这些是反复栽过的):

• struct 动态字段名不能是纯数字,加字母前缀(bc.(['e' num2str(i)]))。
• 块名不能含 /(被当路径分隔符)。
• arrayfun 匿名函数逐元素处理:@(s) f(s) 而不是 @(s) f(整个数组)。
• 轨迹微分别用 diff()+zero-pad(端点出伪值),用中央差 + 端点前后向差。
• 轨迹插值一律 interp1(...,'spline') 不用 'linear'(linear 的二阶导出尖峰)。

要求可独立运行 + 自带自检输出:

• 脚本末尾打印关键统计值 / 收敛标志(ALL_OK、RCOND、Pmax、final 值等), 让"对不对"直接出现在 stdout 里,不用人去翻变量。

移植类任务锚定参考实现:

• prompt 里要求"逐行对照参考实现的公式,先核对积分核量纲和初始化机制,再开始写"。 量纲错会直接体现成矩阵病态,这一步省不得。

指定交付体系(有兼容要求时):

• 例如客户要 R2017:明确"只用基础语法和函数,禁用 tiledlayout / exportgraphics / writematrix / readmatrix / string / arguments / datetime / table"。

Simulink 配置:

• 优先全量重建一个新模型,不要让它增量 patch 旧模型(patch 极易出连线冲突)。
• 让它区分物理端口和信号端口:Block/LConn1 是 Simscape 物理口,Block/1 是 Simulink 信号口。

---

4. 结果怎么验证对错(最重要的一块)

模型自己判不了对错,验证基准必须人来定。按下面几层逐层过。

4.1 先看数值健康度(跑完第一眼)

• 矩阵条件数 RCOND:奇异 / 病态最快的信号。RCOND 到 1e-39 这种量级,基本就是 积分核量纲写错或初始化缺失,别再往算法细节里钻。
• 非物理量级:压力跳到 2.6e25 MPa、转速 ±2700 rpm 极限环、电流估计冲到几万—— 出现非物理量级立刻停,是初始化 / 反馈结构问题,不是参数没调好。
• 收敛性:看迭代步数 + 残差。加上必要的初始化机制后该是几十步内收敛(例:25 迭代)。

4.2 与参考真值对照(有就一定要对)

• 移植类:跟参考实现对数。关键标量逐个比(例:Pmax、Wmax 与 Python 版一致才算过)。
• 复现类:对照文献的出图模式和关键曲线趋势。
• 没有参考真值时:这正是模型最不可靠的地方,见第 6 块。

4.3 看曲线形状找伪信号(最考验判断)

• 周期性力矩 / 加速度尖峰:先怀疑轨迹表示,不是控制器。 判据:换两个完全不同的控制器,尖峰还在同样的位置同样的频率——那就是上游数据问题。 例:20Hz 尖峰对应 waypoint 间距 0.05s,根因是 interp1 用了 linear; 末端单点尖峰,根因是 diff()+zero-pad 造的伪加速度。
• 收敛假象:角度估计 0→6.28 来回跳看着不收敛,其实只是没 wrap 到 [-π,π]。 "显示问题"和"真不收敛"要分清,别拿显示问题去调算法。
• 输出恒零:高频注入解调后 LPF 恒为零,是注入 / 解调相位没差 90° 的结构错。 恒零通常是结构错的典型信号,不是参数问题。

4.4 物理合理性 sanity check

• 量级对不对(力矩 Nm、转速 rpm、压力 MPa、位移 mm,各自该在什么数量级)。
• 前提是否成立再谈算法:无凸极(Ld=Lq)时 PHF 必然失效(误差信号恒零), ESO 带宽不够时快速暂态会注错前馈。前提不成立的话,算法怎么调都没用。
• 物理模型 vs 简化模型:纯状态方程里验证过的算法,搬到 Simscape 物理模型大概率 不直接 work,两者对高频信号的响应机制不同。别假设"数学模型过了物理模型就过"。

4.5 工具层验证(配置到底生效了没)

• Simulink 连线:某些接口下 find_system('Type','Line') 返回空, 连线是否生效要用 get_param(block,'PortConnectivity') 查 SrcBlock。
• 别被缓存骗:改了 .m 没重载,跑的可能是旧版,先 clear functions; rehash; .m 和 .slx 同名时 run 跑的是模型不是脚本。
• 出图必须落地看图:报告 / DOCX 渲染成 PNG 逐页查,不看 XML; 图片段落别设固定行距,否则渲染时图被裁成只剩坐标轴。
• 交付目录别直接跑脚本验证:csvwrite 会覆盖带表头的 CSV、print 会覆盖 PNG, 用临时副本跑,跑完再确认正式目录没被污染。

4.6 验证的回路纪律

• 长仿真后台跑(后台任务 + 轮询输出),别阻塞整条回路。
• Simulink 建块 + 连线 + 保存压进一次调用完成,中途关模型(不保存)会丢掉刚连的线。
• 跨多次调用时 MATLAB session 状态会残留,验证前 bdclose('all') 清干净再重载。

4.7 一个端到端的例子:周期性力矩尖峰

把上面几层串起来看一个真实例子——六自由度机械臂的轨迹跟踪控制仿真。

1. 拆解:几个 waypoint 插值生成轨迹,送进计算力矩控制(CTC),输出关节力矩。 子任务是"给定 waypoint,插值出 q / qd / qdd,跑 CTC,画力矩曲线"。
2. 跑出来:仿真跑通,关节位置跟踪曲线很漂亮,跟着轨迹走,位置误差也小。单看位置,这结果"对"。
3. 发现异常:看关节力矩曲线,上面有规律的尖峰,J3 从正常的 -0.6 Nm 冲到 -13.5 Nm。 位置对、力矩不对——这就是典型的"看着对、其实不对"。
4. 判断不是控制器:第一反应可能是 CTC 参数没调好。但换一个完全不同的控制器(Fuzzy)重跑, 尖峰还在同样的位置、同样的频率(约 20Hz)。两个不相干的控制器出一模一样的尖峰, 问题就不在控制器,而在它们共同的上游:轨迹。
5. 定位根因:20Hz 对应 waypoint 间距 0.05s。插值用了 interp1 的 linear——分段线性的 q 让 qd 阶梯跳变、qdd 在每个 waypoint 处出尖峰,CTC 前馈项 M*qdd 把这些尖峰直接映射成力矩脉冲。 根子是轨迹表示不够光滑,不是控制律。
6. 修复:插值换成 spline(C2 连续),qdd 平滑,力矩尖峰消失;两个控制器一起恢复正常, 反过来印证了根因判断是对的。

这条线里每一步都对应前面的一层:可量化产出(力矩曲线)、看形状找伪信号(规律尖峰)、 用对照实验区分控制器问题和数据问题(换控制器重跑)、归因到上游表示、做最小修复。 模型能跑完整条仿真,但"位置对就算对"这个坑它自己跨不过去——识别尖峰、设计对照、 追到 interp1 这一串判断,是人做的。

---

5. 出错时怎么迭代纠正,哪些它改不动

迭代策略

• 参数名 / 版本类报错:让它查 DialogParameters,别对着文档猜参数名。
• 反复发散:不要在同一结构上调参死磕。判据是"调参只能缓解、换结构才根治"—— 这时就是结构问题(例:速度环回灌扰动前馈一直过冲,根因是结构,解法是退回纯 PI 打底)。
• 移植不一致:回到参考实现逐行对公式,优先核对量纲和初始化,而不是改算法细节。
• Simulink 增量改出连线冲突:别 patch,bdclose('all') + 全量重建更可靠。
• 中文 locale / 编码坑:整体跑 .m 报日期格式错时改成逐段执行; 含中文路径写成脚本文件跑,不要用命令行内联(编码会乱)。

它改不动 / 越改越糟的(要人来判"是不是工具在骗我")

• 工具自身的 bug:某些雅可比 API 在特定模型约定下返回的结果与正向运动学帧不一致, pinv(J)*dx 不产生实际位移。根因不一定能定位清,务实解是绕开(改数值差分)。 模型不会自己发现这类,得人意识到"工具可能在骗我"。
• API 文档级的坑:旧版本导出会清空编译态库子系统,按文档调 API 必失败, 正解是绕到文件格式层手改版本标记。模型按文档走只会反复撞墙。
• 物理求解器层面的限制:接线和参数全对,物理 solver 仍可能滤掉高频电流。 这不是改代码能解决的,是建模层面的取舍问题。

---

6. 哪些环节它不行、必须人工接管

下面第一条是 DeepSeek 类模型实测最硬的短板,有具体案例;其余几条是从任务性质里 总结的、任何模型都要人把关的点。

视觉:模型没有视觉,做仿真最常撞的墙

仿真任务里图无处不在:客户给的系统单线图、技术图纸、衰减曲线截图, 以及"参考图 vs 当前仿真输出对不对"的对照判断。盲模型这几件事全做不了。实测两类典型:

• 客户甩一张系统单线图(光伏 / 储能 / 逆变器拓扑)+ 一段运行模式文字,要求建 Simulink 模型。 文字能读,图读不了——拓扑、连接关系、参数标注全在图里,模型只能瞎猜。
• 客户拿一张控制效果曲线图(如 RBF-PID vs 传统 PID 衰减对比)说"效果就看这张图"。 模型判不了曲线形状对不对,也判不了自己跑出来的图和客户参考图差在哪。

实测可行的解法是给它配一双"外挂眼睛":把图截下来交给一个独立视觉模型(Qwen-VL 一类), 让视觉模型出文字描述 / 差异点,主模型再据此改代码。这个看图协议要写进持久文件 (例如 "你没有视觉能力,所有图片判断先截图交给视觉模型评价,再据反馈改代码"), 否则盲模型会默默忽略图、按文字硬编,产出和客户图对不上。

补充:DeepSeek 近期已上视觉模型,这道墙在变矮;但"主模型 + 外挂视觉模型"的分工对 任何缺视觉 / 视觉弱的中转模型仍是稳妥兜底,值得作为默认流程保留。

其余必须人接管的点

• 定验证真值锚:没有参考实现或文献真值时,模型给的结果对错它自己判不了。 对 Python、对文献曲线、对解析解——验证基准必须人来选。
• 数值根因归因:模型能跑能改,但"这是量纲错 / 初始化缺失 / 结构问题 / 还是工具 bug" 这一步要人主导。模型倾向于在错误的层面(调参)死磕。
• 物理直觉与前提检查:凸极、ESO 带宽、注入相位这些"前提不成立则算法必废"的判断, 模型常常跳过、直接去改算法。
• 工具的隐性约束:版本相关的块参数名、接口限制、编译态模块不可降版、 物理端口 vs 信号端口的区分——这些要么人喂约束,要么人替它踩。
• 紧耦合现场改稿:要先读现有模型 / 文件状态再外科手术改、每步在本机验证的, 回路里的翻译损失大于省下的成本,直接在主回路自己做。
• 美观与交付规范:原理图式布局、报告分页防裁图、清理交付目录和元数据—— 能自动化,但标准要人定、结果要人抽查。
• 长会话状态管理:跨调用的 session 残留、缓存旧脚本——这些状态陷阱要人来意识到并清。