1. 为什么“AI 调 MATLAB”这件事，大多数人第一步就走歪了
先说一个我观察了很久的现象：身边不少做算法验证、控制系统仿真、信号处理的同行，最近都在琢磨同一件事——让 AI 帮忙写 MATLAB 代码。想法很朴素，MATLAB 语法虽然不算难，但那些矩阵索引、句柄函数、Simulink 参数配置，写起来琐碎又容易出错，要是能让 AI 直接生成、直接跑通，效率能翻好几倍。
于是很多人第一反应是去找“让 AI 操作 MATLAB”的现成方案，比如各种 MCP（Model 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*maxLag+1，对应滞后 -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:n+lag) .* signal(1-lag:n)); elseif lag > 0 acf(lag + maxLag + 1) = sum(signal(1:n-lag) .* signal(1+lag: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 模型的配合
如果你的项目涉及 Simulink，AI 生成 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 这件事，其实可以很顺。
