1. 为什么“AI 调 MATLAB”这件事大多数人第一步就走歪了先说一个我观察了很久的现象身边不少做算法验证、控制系统仿真、信号处理的同行最近都在琢磨同一件事——让 AI 帮忙写 MATLAB 代码。想法很朴素MATLAB 语法虽然不算难但那些矩阵索引、句柄函数、Simulink 参数配置写起来琐碎又容易出错要是能让 AI 直接生成、直接跑通效率能翻好几倍。于是很多人第一反应是去找“让 AI 操作 MATLAB”的现成方案比如各种 MCPModel Context Protocol工具链想着把 MATLAB 当成一个被调用的外部工具让 AI 通过协议去执行命令、读返回值、再继续推理。听起来很美好实际用起来却处处别扭环境配置复杂、上下文传递容易断、每次调用都要重新描述一遍任务背景稍微复杂一点的单元设计AI 就开始“幻觉”出不存在的函数名或者把end和endfunction搞混。我踩过这个坑之后慢慢想明白一件事我们真正需要的不是让 AI 去“操作” MATLAB而是让 AI 直接“产出”符合工程规范的 MATLAB 代码和测试用例。这两件事看起来像本质完全不同。前者是把 AI 当成一个远程操作员后者是把 AI 当成一个懂 MATLAB 的工程师。前者依赖外部工具链的稳定性后者只依赖 AI 本身对 MATLAB 语言和工程规范的理解能力。这个思路转变之后整个流程一下子顺了。我不再折腾那些协议和中间层而是把精力放在一件事上怎么把“单元设计规范”和“测试用例”这两件事用原生 AI 一次性生成出来。所谓“原生”就是不借助任何外部 MATLAB 执行环境纯靠 AI 对语言和规范的理解直接输出可用的.m文件内容。你拿到代码之后自己在 MATLAB 里跑一遍验证即可。这篇文章就是把我这套方法完整拆开讲。适合谁看如果你正在做 MATLAB 相关的算法开发、课程设计、仿真建模或者你是一个团队里负责代码规范的人想让 AI 帮你批量生成符合规范的函数单元和配套测试那这篇内容应该能帮你省下不少试错时间。如果你只是偶尔写几行 MATLAB 脚本那可能用不上这么重的流程但里面关于“怎么跟 AI 描述工程规范”的思路放到其他语言里也一样成立。接下来我会从“为什么 MCP 路线容易翻车”讲起然后给出我实际在用的提示词结构、单元设计规范的拆解方式、测试用例的生成策略最后附上几个我踩过的坑和对应的规避方法。全程不涉及任何外部工具配置纯讲怎么把 AI 用明白。2. MCP 路线在 MATLAB 场景下到底卡在哪2.1 协议层和执行层的错位MCP 这类方案的核心思路是让 AI 通过一个标准协议去调用外部工具。放在 MATLAB 场景里就是 AI 发出一个“执行这段代码”的请求中间层负责把请求转成 MATLAB 能识别的命令执行完再把结果回传给 AI。听起来很顺但问题出在协议层和执行层的错位上。MATLAB 不是一个无状态的命令行工具。它有自己的工作区workspace、路径path、全局变量、图形句柄还有 Simulink 这种带状态的仿真环境。当你通过协议去调用它时每次调用默认是独立的上一次定义的变量下一次可能就没了。你得手动维护一个会话状态或者每次调用都把完整的上下文重新传一遍。这个上下文一旦变长AI 的注意力就会被稀释开始漏掉关键约束。我实测过一个典型的翻车场景让 AI 通过 MCP 生成一个滤波器设计函数然后立刻调用它跑一组测试数据。AI 第一次生成的函数里用了一个自定义的窗函数第二次调用测试的时候它忘了这个窗函数还没定义直接报错。然后它开始“修复”修复的方式是重新生成一个内联的窗函数结果和第一次的版本不一致测试自然过不了。整个过程来回折腾了七八轮最后生成的代码还不如我手写十分钟。2.2 上下文窗口被无谓消耗另一个容易被忽略的问题是上下文窗口的消耗。MCP 的每一次调用都需要把工具描述、参数 schema、历史调用记录都塞进上下文。MATLAB 的函数签名本来就长加上各种可选参数、名称-值对一个中等复杂度的函数描述就能占掉几百个 token。你还没开始写业务逻辑上下文已经被工具描述吃掉一大半。更麻烦的是MATLAB 的错误信息往往很长堆栈跟踪加上警告信息一次报错就能回传上千个 token。AI 为了“理解”这个错误又得把前面的代码重新读一遍。几轮下来上下文窗口满了AI 开始丢失早期的关键约束生成质量断崖式下跌。提示如果你非要用 MCP 路线至少要把 MATLAB 的调用封装成“无状态”的纯函数——每次调用只传输入参数返回输出结果不依赖任何工作区变量。但即便如此上下文消耗的问题依然存在只是缓解而已。2.3 原生 AI 生成路线的核心优势对比下来原生 AI 生成路线的优势就很明显了。你不需要维护任何会话状态不需要中间层不需要担心协议兼容性。你只需要把“单元设计规范”和“测试用例要求”用自然语言描述清楚让 AI 一次性输出完整的.m文件内容。AI 生成完之后你自己在 MATLAB 里跑一遍有问题再针对性地让它改。这个路线的关键假设是AI 对 MATLAB 语言本身的理解已经足够好好到可以生成符合工程规范的代码。从我实际使用的情况看这个假设在大多数场景下是成立的。MATLAB 的语法相对规整函数式编程风格明显AI 在训练数据里见过大量的 MATLAB 代码对常见的矩阵操作、绘图函数、工具箱调用都很熟悉。真正需要你花心思的不是“AI 会不会写 MATLAB”而是“你怎么把工程规范翻译成 AI 能理解的指令”。3. 把“单元设计规范”翻译成 AI 能执行的指令3.1 什么是单元设计规范为什么它重要在 MATLAB 工程实践里“单元”通常指一个独立的函数文件或者一个 Simulink 子系统或者一个类的方法。单元设计规范就是对这个独立单元在接口、命名、注释、错误处理、边界条件等方面的统一约定。比如函数名用驼峰还是下划线、输入参数怎么校验、错误码怎么定义、注释用哪种格式、是否允许使用全局变量等等。为什么这件事重要因为 AI 生成的代码如果没有规范约束每次风格都不一样。今天生成的函数用validateattributes做参数校验明天生成的直接assert后天生成的干脆不校验。你把这些代码放到一个项目里维护成本会非常高。更严重的是没有规范约束的代码测试用例很难写——你都不知道这个函数在非法输入下应该抛什么错怎么测所以我的做法是在让 AI 生成代码之前先把单元设计规范写成一份“提示词模板”。这份模板不是给人类看的文档而是给 AI 看的指令集。它要足够具体具体到 AI 不需要“猜”你的意图。3.2 提示词模板的结构拆解我实际在用的模板分五个部分接口定义、参数校验、错误处理、注释规范、输出格式。下面逐条说。接口定义部分我会明确告诉 AI函数名是什么、输入参数有几个、每个参数的类型和维度、输出参数有几个、每个输出的含义。比如函数名computeMovingAverage 输入 - data: 数值向量长度 windowSize - windowSize: 正整数标量 1 且 length(data) 输出 - avg: 数值向量长度与 data 相同前 windowSize-1 个元素为 NaN这样写的好处是AI 不需要猜“data 是行向量还是列向量”“windowSize 能不能等于 0”。它拿到的是一个精确的契约生成代码时就会围绕这个契约来写。参数校验部分我会指定用哪种校验方式。MATLAB 里常见的有validateattributes、inputParser、手写if-else加error。我一般要求用validateattributes因为它语义清晰、报错信息规范而且 AI 对它很熟。我会在模板里写参数校验要求 - 使用 validateattributes 对每个输入参数进行校验 - data 必须为 numeric 类型非空非 NaN - windowSize 必须为 numeric 类型标量整数正数 - 校验失败时抛出 MATLAB:computeMovingAverage:invalidInput 错误标识错误处理部分我会定义错误标识的命名规则和错误信息的格式。错误标识统一用MATLAB:函数名:错误类型的格式错误信息用英文首字母大写不加句号。这样生成的代码在报错时调用方可以通过catch ME拿到ME.identifier做精确处理。注释规范部分我要求每个函数头部有一段 H1 帮助文本包含函数用途、语法、输入输出说明、示例。函数内部的关键逻辑要有行内注释注释用英文动词开头。这个要求看起来琐碎但实际用下来AI 生成的注释质量比很多人类写的还高因为它不会偷懒。输出格式部分我明确要求 AI 只输出.m文件的完整内容不要加任何解释性文字不要用 Markdown 代码块包裹。这样我复制出来直接存成文件就能跑。如果它加了代码块标记我还得手动删很烦。3.3 一个完整的提示词示例把上面五个部分拼起来就是一个完整的提示词。我拿一个实际用过的例子来说明请生成一个 MATLAB 函数文件满足以下规范 接口定义 - 函数名computeMovingAverage - 输入data数值向量长度 windowSize、windowSize正整数标量 - 输出avg数值向量长度与 data 相同前 windowSize-1 个元素为 NaN 参数校验 - 使用 validateattributes 校验 data 和 windowSize - data 必须为 numeric、vector、nonempty、nonnan - windowSize 必须为 numeric、scalar、integer、positive - 校验失败抛出 MATLAB:computeMovingAverage:invalidInput 错误处理 - 如果 windowSize length(data)抛出 MATLAB:computeMovingAverage:windowTooLarge - 错误信息用英文首字母大写不加句号 注释规范 - 函数头部包含 H1 帮助文本含用途、语法、输入输出说明、示例 - 关键逻辑行内注释英文动词开头 输出格式 - 只输出 .m 文件完整内容不加解释不用代码块包裹这个提示词丢给 AI一次生成的成功率大概在八成以上。剩下两成的问题通常是边界条件处理得不够干净比如windowSize等于 1 的时候前 0 个元素为 NaN逻辑上没问题但 AI 有时候会多写一个判断分支。这种小问题我一般直接手动改比来回让 AI 改更快。4. 测试用例生成从“能跑”到“测得住”4.1 测试用例的三种类型AI 生成测试用例最容易犯的毛病是只生成“正常路径”的测试。你给它一个函数它写几个典型输入验证输出形状对不对、数值范围对不对就完事了。这种测试用例跑起来全是绿的但真出了 bug 一个都抓不住。我要求 AI 生成三类测试正常路径测试、边界条件测试、异常路径测试。正常路径测试覆盖典型输入验证核心逻辑正确。边界条件测试覆盖参数取最小值、最大值、空值、单元素等情况。异常路径测试覆盖非法输入验证错误标识和错误信息是否符合预期。这三类测试的比例我一般控制在 4:3:3。正常路径不用太多因为核心逻辑通常就一两条路径。边界条件和异常路径才是真正能暴露问题的值得多花篇幅。4.2 用 MATLAB 单元测试框架组织用例MATLAB 自带的单元测试框架是matlab.unittest用类的方式组织测试。我要求 AI 生成的测试文件继承matlab.unittest.TestCase用methods (Test)块定义测试方法用verifyEqual、verifyError、verifyTrue等断言方法做验证。一个典型的测试文件结构是这样的classdef computeMovingAverageTest matlab.unittest.TestCase methods (Test) function testNormalPath(testCase) data [1 2 3 4 5]; windowSize 3; avg computeMovingAverage(data, windowSize); expected [NaN NaN 2 3 4]; testCase.verifyEqual(avg, expected, AbsTol, 1e-10); end function testWindowSizeOne(testCase) data [1 2 3]; windowSize 1; avg computeMovingAverage(data, windowSize); testCase.verifyEqual(avg, data, AbsTol, 1e-10); end function testWindowTooLarge(testCase) data [1 2 3]; windowSize 5; testCase.verifyError(() computeMovingAverage(data, windowSize), ... MATLAB:computeMovingAverage:windowTooLarge); end end end这个结构的好处是每个测试方法独立互不影响。verifyEqual带容差参数避免浮点数比较的精度问题。verifyError直接验证错误标识比验证错误信息字符串更稳定因为错误信息可能会改错误标识一般不变。4.3 让 AI 生成测试用例的提示词要点生成测试用例的提示词和生成函数本体的提示词要分开写。因为测试用例的约束条件和函数本体不一样。我会在提示词里明确测试文件类名函数名Test继承matlab.unittest.TestCase每个测试方法以test开头方法名描述测试场景正常路径测试至少 2 个边界条件测试至少 3 个异常路径测试至少 2 个使用verifyEqual时带AbsTol参数容差 1e-10使用verifyError验证错误标识不验证错误信息字符串输出格式只输出.m文件完整内容不加解释这里有个细节值得说容差参数的选择。MATLAB 默认的浮点数比较是精确比较两个理论上相等的浮点数因为计算顺序不同可能差一个极小量。我一般用1e-10作为容差对于大多数工程计算够用了。如果你的计算涉及大量累加或者病态矩阵容差可能要放宽到1e-6。这个参数我会在提示词里写死不让 AI 自己决定因为它有时候会忘记加容差导致测试随机失败。5. 一次完整的生成流程演示5.1 从需求到函数文件假设我要一个函数计算一个信号的自相关函数输入是信号向量和最大滞后数输出是自相关向量。我先按第 3 节的模板写提示词请生成一个 MATLAB 函数文件满足以下规范 接口定义 - 函数名computeAutocorrelation - 输入signal数值向量长度 2、maxLag正整数标量 length(signal)-1 - 输出acf数值向量长度 2*maxLag1对应滞后 -maxLag 到 maxLag 参数校验 - 使用 validateattributes 校验 signal 和 maxLag - signal 必须为 numeric、vector、nonempty、nonnan - maxLag 必须为 numeric、scalar、integer、positive - 校验失败抛出 MATLAB:computeAutocorrelation:invalidInput 错误处理 - 如果 maxLag length(signal)-1抛出 MATLAB:computeAutocorrelation:maxLagTooLarge - 错误信息用英文首字母大写不加句号 注释规范 - 函数头部包含 H1 帮助文本含用途、语法、输入输出说明、示例 - 关键逻辑行内注释英文动词开头 输出格式 - 只输出 .m 文件完整内容不加解释不用代码块包裹AI 生成的函数大概长这样我做了简化function acf computeAutocorrelation(signal, maxLag) %COMPUTEAUTOCORRELATION Compute autocorrelation of a signal. % ACF COMPUTEAUTOCORRELATION(SIGNAL, MAXLAG) returns the % autocorrelation of SIGNAL for lags from -MAXLAG to MAXLAG. % % Example: % signal [1 2 3 4 5]; % acf computeAutocorrelation(signal, 2); validateattributes(signal, {numeric}, {vector, nonempty, nonnan}, ... mfilename, signal, 1); validateattributes(maxLag, {numeric}, {scalar, integer, positive}, ... mfilename, maxLag, 2); if maxLag length(signal) - 1 error(MATLAB:computeAutocorrelation:maxLagTooLarge, ... MaxLag must not exceed length of signal minus one); end n length(signal); acf zeros(1, 2*maxLag 1); for lag -maxLag:maxLag if lag 0 acf(lag maxLag 1) sum(signal(1:nlag) .* signal(1-lag:n)); elseif lag 0 acf(lag maxLag 1) sum(signal(1:n-lag) .* signal(1lag:n)); else acf(lag maxLag 1) sum(signal .^ 2); end end end这个代码基本可用但有一个小问题acf没有归一化。自相关函数通常要除以零滞后值做归一化让零滞后处的值为 1。我在提示词里没写这个要求AI 就没做。这不是 AI 的错是我的规范没写全。所以提示词的完备性直接决定生成代码的可用性这一点怎么强调都不为过。5.2 从函数文件到测试文件拿到函数文件后我接着写测试用例的提示词请为 computeAutocorrelation 函数生成 MATLAB 单元测试文件满足以下规范 测试文件类名computeAutocorrelationTest 继承matlab.unittest.TestCase 测试方法要求 - 正常路径测试至少 2 个典型信号、单频正弦信号 - 边界条件测试至少 3 个maxLag 等于 1、maxLag 等于 length(signal)-1、signal 长度为 2 - 异常路径测试至少 2 个maxLag 超过 length(signal)-1、signal 包含 NaN - 使用 verifyEqual 时带 AbsTol 参数容差 1e-10 - 使用 verifyError 验证错误标识不验证错误信息字符串 - 输出格式只输出 .m 文件完整内容不加解释AI 生成的测试文件会覆盖上面这些场景。我实际跑下来正常路径和边界条件的测试基本都能过异常路径的测试偶尔会因为错误标识拼写不一致而失败。这时候我会检查函数文件里的错误标识和测试文件里的做对比手动统一一下。这个问题的根源是 AI 在生成两个文件时对错误标识的记忆可能不一致。解决办法是在提示词里把错误标识写死让它照抄。5.3 在 MATLAB 里跑通并迭代把两个文件存到同一个目录下在 MATLAB 命令窗口运行results runtests(computeAutocorrelationTest); disp(results);如果全绿说明生成质量合格。如果有红的看失败信息判断是函数的问题还是测试的问题。函数的问题就改函数测试的问题就改测试。改完之后重新跑直到全绿。这个迭代过程通常一到两轮就能收敛。比起 MCP 路线那种来回七八轮的折腾效率高太多了。而且整个过程你完全掌控不需要调试任何中间层。6. 踩过的坑和对应的规避方法6.1 错误标识不一致这是最常见的问题。AI 生成函数文件时错误标识写的是MATLAB:computeAutocorrelation:maxLagTooLarge生成测试文件时可能写成MATLAB:computeAutocorrelation:maxLagExceeded。两个文件单独看都没问题放一起跑就报错。规避方法很简单在提示词里把错误标识作为常量写死让 AI 在两个文件里都照抄。我一般会在提示词里加一行“错误标识必须严格使用以下字符串不得修改MATLAB:computeAutocorrelation:maxLagTooLarge”。这样 AI 就不会自由发挥了。6.2 边界条件遗漏AI 对边界条件的敏感度不如人类。你让它生成测试用例它可能只测maxLag等于 1 的情况忘了测maxLag等于length(signal)-1的情况。后者才是最容易出索引越界的地方。规避方法是在提示词里显式列出所有需要覆盖的边界条件不要指望 AI 自己想到。我一般会写“边界条件测试必须覆盖以下场景参数取最小值、参数取最大值、输入为空、输入为单元素、输入包含 NaN”。这样 AI 就有了明确的清单不会漏。6.3 浮点数比较失败MATLAB 的verifyEqual默认是精确比较。两个理论上相等的浮点数因为计算顺序不同可能差1e-16测试就红了。这个问题在涉及矩阵运算、三角函数、指数对数的时候特别常见。规避方法是在提示词里强制要求带容差参数。我一般写“所有 verifyEqual 调用必须带 AbsTol 参数容差为 1e-10”。这样 AI 就不会用默认的精确比较。如果你的计算精度要求更高可以把容差调到1e-12但不要低于1e-14否则和精确比较没区别。6.4 注释语言不统一我要求注释用英文但 AI 有时候会混用中英文。函数头部是英文行内注释突然冒出一句中文。这在团队协作里很尴尬代码审查的时候会被挑出来。规避方法是在提示词里明确注释语言并且强调“所有注释”。我一般写“所有注释必须使用英文包括函数头部帮助文本和行内注释不得出现中文”。这样 AI 就不会混用了。6.5 输出格式带多余标记我要求 AI 只输出.m文件内容但它有时候会用 Markdown 代码块包裹或者在前面加一句“以下是生成的代码”。这些多余内容复制到 MATLAB 里会报语法错误。规避方法是在提示词里用强指令。我一般写“只输出 .m 文件完整内容第一行必须是 function 或 classdef最后一行必须是 end不得有任何其他文字或标记”。这样 AI 就知道边界在哪里了。7. 把这套方法扩展到更复杂的场景7.1 多函数协作的生成策略上面讲的都是单个函数的生成。实际项目里一个功能往往由多个函数协作完成。比如一个信号处理流程可能包含预处理函数、特征提取函数、分类函数。这时候如果一个个单独生成函数之间的接口容易对不上。我的做法是先生成接口定义再生成实现。具体来说先让 AI 输出一份“接口清单”列出每个函数的名称、输入输出、依赖关系。我确认无误后再逐个生成函数实现和对应的测试。这样函数之间的契约是提前定好的不会出现“A 函数输出 3 个参数B 函数只接收 2 个”这种问题。接口清单的提示词大概是这样请为一个信号处理流程设计函数接口包含以下功能 1. 信号预处理去均值、去趋势 2. 特征提取计算均方根、峰值因子、峭度 3. 分类基于阈值判断信号状态 输出格式 - 列出每个函数的名称、输入参数、输出参数、功能描述 - 标注函数之间的调用关系 - 不输出具体实现代码拿到接口清单后我再针对每个函数写详细的生成提示词。这个两阶段流程比一次性让 AI 生成所有代码要可靠得多。7.2 与 Simulink 模型的配合如果你的项目涉及 SimulinkAI 生成 MATLAB 函数的能力依然有用但用法略有不同。Simulink 里的 MATLAB Function 模块本质上就是一个 MATLAB 函数你可以用同样的方法生成代码然后粘贴到模块里。需要注意的是Simulink 的 MATLAB Function 模块对代码有一些额外限制不支持某些工具箱函数、不支持动态内存分配、变量大小必须可确定。这些限制我会在提示词里提前说明让 AI 避开。比如“生成的代码将在 Simulink MATLAB Function 模块中使用不得使用 eval、feval、动态字段名、可变大小数组”。这样 AI 就会选择符合限制的写法。7.3 批量生成的自动化思路如果你需要生成大量类似的函数比如一个工具箱里几十个函数每个函数的结构都差不多只是参数和计算逻辑不同。这时候可以写一个“元提示词”把变化的部分参数化。比如你有一个函数模板输入参数名、输出参数名、核心计算公式是变量。你可以写一个提示词让 AI 根据你提供的参数表批量生成所有函数的代码和测试。这个思路我试过对于结构高度相似的函数族效率提升非常明显。但前提是你的参数表要足够精确否则 AI 会生成一堆需要手动修的东西。8. 我实际用下来的一些体会这套方法我用了大概半年覆盖了信号处理、控制系统、数据分析几个方向。最大的感受是AI 生成 MATLAB 代码的质量取决于你给它的规范有多细。你写得越细它生成得越准。你写得含糊它就自由发挥结果往往不是你想要的。另一个体会是测试用例的生成比函数本体的生成更有价值。函数本体你手写也就几分钟但测试用例要覆盖各种边界和异常手写很费时间。AI 生成测试用例的速度快覆盖面广你只需要检查它有没有漏掉关键场景。这个检查过程本身也能帮你发现自己对函数行为的理解盲区。还有一点不要追求一次生成就完美。我现在的流程是第一轮生成函数和测试跑一遍看哪些红了。然后针对红的用例判断是函数的问题还是测试的问题写一个针对性的修复提示词让 AI 改。通常两轮就能收敛。这个迭代成本比调试 MCP 工具链低太多了。最后说一个容易被忽略的点版本管理。AI 生成的代码建议单独放一个目录和手写代码分开。每次生成后用 Git 提交一次记录提示词和生成结果。这样如果后面发现某个版本的代码有问题可以回溯到之前的版本看看当时的提示词是怎么写的。这个习惯帮我省了好几次“这个函数当时是怎么生成的”的困惑。如果你也在做 MATLAB 相关的开发不妨试试这套原生 AI 生成的路线。不用折腾协议不用配置中间层把精力放在规范描述和测试验证上。你会发现AI 写 MATLAB 这件事其实可以很顺。
