上周有个老系统，手画的模型，路径长到人一看就烦。我让一个 agent 帮忙生成测试路径，它给了我一条挺短的路径。我美了五分钟，跑去和原模型对照，发现它把一条不该跳过的边跳过去了。不是它不会走，是它在“优化步长”这件事上太殷勤了。
然后我看到了那篇 arXiv:2608.27094。第一反应是——又是拿几个 LLM 在基准上跑一圈，结尾说“有潜力”。这种论文我一年要看几十篇。但有一件事让我停了一下：它把 GraphWalker 的随机算法和快速随机算法分别摆出来，还专门分边覆盖和顶点覆盖两种设置。为什么这么摆？不像是凑实验表，倒像作者知道，MBT 这事的衡量标准本身有两层。
同一个指标，在 GraphWalker 手里和在 LLM 手里，底层机制是两码事。GraphWalker 的随机算法，说难听点就是“蒙”。它不追求最优，追求稳。LLM 生成的路径，从训练分布里带出来，天然就倾向于“像那么回事”——GPT-5.1 或 Gemini 2.5 Pro 生成的路径，往往短、顺、该转弯的地方转弯。可这种“像那么回事”，有时候反而会把不该牺牲的边覆盖牺牲掉。所以实验分开报边覆盖和顶点覆盖，我猜是这个意思：顶点覆盖对 LLM 友好，边覆盖才是照妖镜。
顶点覆盖这事，只要能戳到每个点，路径短一点也能体面地及格。但边覆盖不同——你得把每条边都走一遍。不能只挑“看起来顺”的路，得走那些你不想走、但必须走的路。这对 LLM 是件反直觉的事：模型在设计上就倾向于在 token 层面挑高概率的方向，那些边恰恰可能是低概率、甚至有点别扭的方向。所以当论文说这些 LLM 在“优化和缩短测试路径及步长方面有较强潜力”时，我不太满意。这句话停在了最外层的结论，没告诉我们缩短步长的那条路径，到底有没有在边覆盖设置里也能站住。这才是真问题。
先停一下，问个问题：MBT 里为什么要分随机算法和快速随机算法？
随机算法图的是覆盖有保障，代价是路径长、步数多。快速随机算法图的是效率，代价是覆盖质量可能下降。把 LLM 放进这个对比框架里，其实是在问：LLM 到底姓“随机”还是姓“快速随机”？我一开始也以为它俩之间选一个，后来才发现都不对——它姓“看起来好”。这层答案，决定了你该在什么场景下让它替你生成路径。如果只是拿它比“谁更短”，那太便宜它了。它最可能在对比中赢的方式，恰恰是它最不老实的方式：把路径做得短，短到好像很聪明的样子。
我承认自己一开始也带着偏见。看摘要里那句“大语言模型在软件工程任务、尤其是软件测试中展现出较强潜力”，心想这不就是标准结尾吗。再往下读表格——他们用了五个模型，从 GPT-5.1、GPT-5.2 到 Claude Opus 4.5、Sonnet 4.5、Gemini 2.5 Pro；四个被测系统，Parabank、Testinium 是 Web 应用，TLC、RISC-V 是硬件验证。这个配置搭得挺真，不是拿一两个玩具模型糊弄。
有个点我没想通，先撂这儿。Web 应用的状态图，通常是页面和跳转；硬件模型的状态，往往是寄存器和指令周期，边的含义重得多。一个 LLM 在 Web 模型上能走出漂亮路径，不代表它在硬件模型上还能保持。这层差异要往下剥，问题就不是“LLM 能不能做 MBT”，而是“LLM 对哪一类模型更可能做对”。我自己的感觉是，Web 那种模型路径像导航，模型见过太多类似结构，容易发挥；硬件那种模型路径像电路，走错一条边可能意味着某种非法状态迁移，LLM 不一定能凭“见过”兜住。这层实验里没看见太多讨论，可能是我对论文要求太高了。
但说回来，有件事我越来越确定：把 LLM 放进 MBT 生成的位置，最怕的根本不是它不聪明，而是它太想证明自己聪明。最短路径这种东西，在测试里从来不是免费的。你缩短一步，可能就绕过了一个状态转换的边界条件。我那个 agent 跳掉的那条边就是例子。GraphWalker 的随机算法不会跳边，因为它没这个概念，它只会笨笨地走；LLM 会跳边，因为它有概念，而且它知道短路径更好看。这恰好就是“看起来对”的老毛病：它生成的路径看起来专业，但只有人跑回去对照原始模型，才发现那条边在真实系统里对应的是一个必须走到的地方。
再往下呢？我猜会撞到一个 trade-off：你愿不愿意为了效率，让一个不一定知道你系统里哪条边有历史的模型来决定路径。效率可以量化——路径长度、步数。风险几乎不可量化，除非你的模型文件里已经标注了每条边的业务含义。换句话说，LLM 能不能用于 MBT，真正的分水岭可能不在模型本身，而在你喂给它的模型文件里，有没有承载足够多的、关于“哪条边不能省”的信息。这又撞回上周那件事：不是 agent 不会做，是我没告诉它哪些地方不能省略。它把“生成短路径”当成了优先级，那它确实做到了，只是我的优先级和它不一致。
这篇论文我最想看的，就是这个不一致，不是那些基准数字。因为一旦把期望拉平，结论会自己冒出来：LLM 有缩短路径的潜力，这是真的；GraphWalker 有可预测的笨拙，这也是真的。问题在于，前者赚到的效率，能不能抵消后者失去的那种“笨拙里的安全感”。我不太想替谁拍板。但我心里有偏向——新写的、没有边历史沉淀的模型，可以放手让 LLM 生成；带着历史包袱、老工程师看一眼就心颤的模型，我宁愿留着 GraphWalker 的那份笨。
最后说句有点扫兴的。论文说这些 LLM“有较强潜力”，我不反对。可“潜力”这个词在 MBT 里最值钱的地方，恰恰不是它能不能更短、更快，而是它能不能在补全路径这件事上，保住人的那点“边界意识”。这个能力现在看起来还不算稳。再往下，就该拆“如何把模型里的边约束喂给 LLM”了。我还没想明白，先撂这儿。
所以那天晚上的事，再往深一点想，不是我让 agent 生成路径，而是我默认它懂得为什么某些边必须走。它不知道。它只是知道怎么走得更短。这两件事，在它那儿是一件事。这大概就是很多人对 LLM 做 MBT 抱期待、又心里发虚的原因——我们想要的是更短的路径，但它给的，可能只是看起来更短的路径。这两个在大部分时候重叠，可惜测试偏偏属于那条不重叠的缝。