Mathematica AI Assistant会“编造听起来合理但不存在的函数名和选项”，有用户“上周花了一个下午修复幻觉出来的代码”，还有人说“过去为这个幻觉AI助手收费，近乎犯罪”——当AI生成Wolfram Language代码的幻觉率因为“公开的Wolfram代码稀疏、模型没怎么练过”而系统性地高于Python时，Mathematica用户到底该把AI助手当成“能用的工具”还是“需要逐行审计的实习生”，这个信任度该怎么建立？

一、问题的提出：一个下午的修复成本意味着什么

“上周花了一个下午修复幻觉出来的代码”——这句话之所以在 Mathematica 社区引发共鸣，是因为它精确描述了 AI 辅助编程中一种特殊的成本结构：错误不是立刻崩溃，而是以“看起来能跑”的形态潜伏下来，直到某个选项被真正求值、某个模式匹配失败、某个符号被内核判定为未定义，才暴露出问题。与编译型语言的类型错误不同，WL 的符号特性使得大量错误在书写阶段完全合法，只在语义阶段才失效。这意味着修复成本并非线性增长，而是被“定位—回溯—重写—再验证”的循环放大。

更值得警惕的是“过去为这个幻觉 AI 助手收费，近乎犯罪”这类表述背后的信任崩塌。它指向一个工程伦理问题：当工具的输出被包装成“专业建议”并以服务形式交付时，幻觉的代价被转嫁给了不具备验证能力的下游用户。本文认为，讨论 Mathematica AI Assistant 是否“能用”，不能停留在体验层面的好坏评价，而必须回到一个可操作的问题：一段 AI 生成的 WL 代码，需要多少验证动作才能被安全采纳？这个验证动作的数量与难度，才是信任的真实度量单位。

笔者认为，把“AI 助手是否可信”转化为“验证成本是否可接受”，是本文最重要的立场转换。信任不是对模型的态度，而是对验证流程的投资回报判断。一个幻觉率 20% 但每处错误都能被 Names[] 与 Options[] 在秒级捕获的助手，可能比幻觉率 5% 但错误隐蔽在数值近似中的助手更“可信”。

因此，本文的分析主线是“可验证性”（verifiability）：以 WL 内核自身的符号求值能力为基础设施，把 AI 输出逐层转化为可检查的命题。这条主线贯穿成因分析、分级框架、工程步骤与局限讨论，避免陷入“模型会不会变好”的不可控叙事，转而聚焦“在模型不变好的前提下，工程上还能做什么”。

二、背景与问题定义：代码幻觉的三种类型与 WL 的特殊性

2.1 代码幻觉的类型学

在代码生成语境下，“幻觉”（hallucination）通常指模型生成与事实、API 或可执行语义不一致的内容。参照自然语言生成领域对幻觉的分类传统（如事实性幻觉与忠实性幻觉的二分），本文将其细化为三类，以便与 WL 的验证手段一一对应：

本文评述：这一分类的工程价值在于，它把“幻觉”从笼统的质量评价拆成了三种可分别拦截的故障模式。符号性幻觉成本最低，因为 WL 内核本身就是最强的符号名数据库；语义性幻觉需要构造最小可执行样例；数值性幻觉则必须依赖领域知识设定断言。三者对应的验证成本递增，这直接支撑了后文的分级框架。

2.2 WL 为何比 Python 更“脆”

Python 的生态优势不仅在于库多，更在于“错误暴露得早”。类型注解、静态检查工具（mypy、pyright）、丰富的单元测试范式以及海量 Stack Overflow 问答，共同构成了一张密集的纠错网。相比之下，WL 的表达式求值模型允许大量“未定义符号”以符号形式存活：f[x] 在 f 未定义时不会报错，而是原样返回。这种“符号惰性”是 WL 强大表达力的来源，却也使幻觉代码更容易蒙混过关。

此外，WL 的选项系统（Options）与模式匹配（Pattern Matching）构成了两层“隐式契约”：一个选项名拼写错误往往不会立即报错，而是被当作未知选项忽略或保留；一个模式写错可能匹配到意料之外的表达式。本文认为，正是这种“宽容的求值语义”放大了 AI 幻觉的生存空间——模型只需生成语法上合法的表达式，就能通过第一道关卡，而真正的语义校验被推迟到用户手中。

三、成因解剖：语料稀疏、语法异构与验证缺位的三重叠加

3.1 语料稀疏：公开 WL 代码的数量级劣势

关于“公开的 Wolfram 代码稀疏、模型没怎么练过”这一社区判断，需要给出可检验的支撑。公开代码语料的规模可以用多个代理指标衡量：GitHub 上按语言标注的仓库数量、Stack Overflow 标签的问题量、公共 Notebook 的可抓取性。以 GitHub 的语言统计为例，Python 长期位居前列，而 Wolfram Language（Mathematica）的标注仓库数量低若干数量级；Stack Overflow 上 wolfram-mathematica 标签的累计提问量也远小于 python 标签。需要说明的是，具体数字随统计口径与时间变化，本文不引用单一快照作为精确结论，而将其作为“数量级差异”的定性证据。

更关键的是语料的“可训练性”。大量 WL 代码以 Notebook（.nb）形式存在，其中混杂输出、图形、动态交互与元数据，直接作为纯文本训练语料的信噪比低；而 Wolfram 官方文档虽结构清晰，却以“参考手册”体例书写，与真实工程代码的分布存在偏移。本文评述：语料稀疏不是简单的“量少”，而是“量与质双重不利”——模型既缺少足够的真实代码样本学习惯用法，又缺少高质量的“错误—修正”配对来学习边界。

3.2 语法异构：符号化表达与训练分布的错配

WL 的语法与主流编程语言差异显著：函数调用用方括号 f[x]，列表用花括号，规则用 -> 与 :>，纯函数用 # 与 &，模式用 _、__、___。这些符号在 Python/JavaScript 语料中含义完全不同，模型在跨语言迁移时容易“用 Python 的直觉写 WL 的语法”，产生形似而神非的代码。

一个典型例子是迭代与映射的混用：模型可能写出 Map[f, list, {2}] 却期望它像 Python 的列表推导那样工作，或在需要 Apply 的地方使用 Map。这类错误在语法上完全合法，只有理解 WL 的“层级”（Level）语义才能识别。笔者认为，这正是“听起来合理”的来源：模型学到了 WL 的词汇表，却没有稳定掌握其求值语义的层级结构。

3.3 验证缺位：通用评测不覆盖 WL 语义

当前主流代码生成评测（如 HumanEval、MBPP 及其衍生基准）以 Python 为主，评测方式是“通过单元测试即算正确”。这类基准无法直接迁移到 WL：一方面缺少 WL 版本的题目与测试，另一方面 WL 的“正确”往往依赖符号化简、假设条件与数值精度，单一测试用例难以覆盖。结果是，模型在公开榜单上的表现与在 WL 场景中的实际可用性之间存在系统性偏差。

本文评述：验证缺位是三重成因中最容易被工程手段弥补的一环。语料稀疏需要模型厂商投入，语法异构需要更强的对齐训练，而“验证”可以由用户侧用 WL 自身能力构建。这也解释了为何本文把主线放在可验证性上——它是当前条件下边际收益最高的干预点。

四、可验证性分级：把信任拆成可执行的检查层

4.1 分级框架的设计原则

本文提出的可验证性分级（Verifiability Grading，VG）遵循三条原则：第一，由廉价到昂贵，先用零成本的内核查询拦截符号性幻觉，再投入求值与断言；第二，由局部到整体，先验证单个符号与选项，再验证表达式组合；第三，可自动化优先，能用代码判定的不依赖人工阅读。三级划分如下：

4.2 L1：用内核当符号名数据库

WL 内核本身就是一个可编程的符号数据库。对 AI 输出中出现的每个疑似函数名，可以用 Names["System`*"] 或更精确的 NameQ 判定其是否存在；对选项，可用 Options[func] 取出合法选项列表并做集合包含判断。下面是一段可直接在 Notebook 中运行的检查骨架：

checkSymbols[expr_] := Module[{syms},
  syms = Union@Cases[expr, s_Symbol /; Context[s] === "Global`" :> s, Infinity];
  AssociationMap[NameQ, syms]
];

checkOptions[func_, opts_List] :=
  With[{legal = First /@ Options[func]},
    AssociationMap[MemberQ[legal, #] &, opts]
  ];

本文评述：这段代码的价值不在于复杂，而在于把“我怀疑这个函数不存在”变成“内核告诉我它不存在”。这一步能拦截绝大多数符号性幻觉，且几乎零成本。实践中建议把它封装成 Notebook 的一个按钮或快捷键，形成“粘贴即检查”的习惯。

4.3 L2：最小可执行样例与消息捕获

通过 L1 的代码仍可能在求值时产生消息（Message）。L2 的做法是为每个可疑函数构造一个最小输入，在 Check 包裹下求值，捕获 $MessageList 是否为空。例如对 Dataset 查询，可先用一个三行两列的小表验证查询算子是否返回预期结构，而不是直接喂入真实数据。

probe[expr_] := Module[{res, msgs},
  msgs = {};
  res = Check[expr, $Failed, AppendTo[msgs, $MessageList]];
  <|"result" -> res, "messages" -> Flatten[msgs]|>
];

probe[Dataset[{{1, 2}, {3, 4}}][All, #1 &]]

笔者认为，L2 的关键不是“跑通”，而是“在受控输入下跑通”。AI 生成的代码常常在真实数据上因规模、类型或缺失值而失败，最小样例能把失败原因隔离到语义层面，避免把数据问题误判为代码幻觉。

4.4 L3：领域断言与不变量

数值与结果性幻觉只能靠领域断言拦截。常见做法包括：用已知解析解对照数值积分结果、检查概率分布归一化、验证矩阵运算的维度与对称性、对优化结果检查约束满足。L3 无法完全自动化，但可以模板化——把领域内常用的不变量写成可复用的测试函数，形成团队资产。

重要提示：L3 断言的可靠性取决于断言本身的正确性。若断言写错，会把正确代码判为幻觉，造成“过度不信任”。建议对每条断言保留其数学依据与来源，并定期复核。

五、工程路径：从提示词到审计工作流的落地步骤

5.1 提示词层：把验证要求前置

提示词工程在 WL 场景下的重点不是“让模型更聪明”，而是“让模型暴露不确定性”。可操作的做法包括：要求模型在给出代码前先列出所用函数及其文档链接；要求对不确定的选项标注“待核实”；要求提供最小可运行示例而非完整项目代码。这些约束会降低生成速度，但显著降低 L1/L2 的验证成本。

一个可直接复用的提示词模板如下（节选）：

请生成 Wolfram Language 代码，并遵守：
1) 在代码块之前，列出每个 System` 函数名及其用途；
2) 对任何你不确定是否存在的选项，用注释标注 // UNVERIFIED；
3) 提供一个最小输入样例和预期输出；
4) 不要使用你无法确认的第三方包函数。

本文评述：这类模板的本质是把“验证负担”部分转移回模型——让它在生成阶段就做一次自我检索。虽然模型的自检并不可靠，但“标注不确定”这一动作本身为人工审计提供了优先级排序。

5.2 工具层：构建本地验证脚本

把 4.2 与 4.3 的检查封装成一个可复用的验证包（例如 AIVerify`），提供 VerifySymbols、VerifyOptions、ProbeEvaluate 三个入口。团队可将该包纳入版本控制，随 WL 版本升级同步维护选项白名单。对于包开发场景，还可把验证脚本接入 CI，对 AI 辅助提交的代码强制跑一遍 L1/L2。

拓展阅读方面，Wolfram 官方文档的 Wolfram Language 参考中心 是核验函数与选项的第一手来源；Mathematica Stack Exchange 适合检索真实工程中的用法与陷阱；GitHub 上的 WL 仓库检索 可用于对照真实项目写法。视频类资源可参考 Wolfram 官方 YouTube 频道的 Wolfram Research 频道，其中“Hands-on Start to Mathematica”系列适合建立对求值语义的直觉。

5.3 流程层：审计工作流的五个步骤

把验证动作固化为流程，才能避免“这次记得查、下次忘了查”。建议的五步工作流如下：

1. 隔离生成：AI 输出先进入独立单元格或独立 .wls 文件，不直接混入生产 Notebook。
2. L1 扫描：运行符号与选项检查，标记所有未通过项。
3. L2 探针：为每个未通过项构造最小样例，记录消息与返回结构。
4. L3 断言：对通过 L2 的代码补充领域不变量测试，至少覆盖一个已知正确结果。
5. 归档与复盘：把本次遇到的幻觉模式记入团队知识库，更新提示词模板与选项白名单。

笔者认为，第五步最容易被忽略却最有长期价值。幻觉模式具有重复性：同一个虚构选项可能在多个项目中反复出现。把“踩过的坑”结构化沉淀，能把个体经验转化为团队的可验证性资产，从而系统性降低后续的验证成本。

六、关键数据与案例：幻觉率差异的可观测证据

6.1 公开研究的间接证据

目前尚无专门针对 WL 代码生成幻觉率的大规模公开基准，这是本文必须诚实说明的局限。但可以从三条间接证据链推断“WL 幻觉率系统性高于 Python”的合理性：其一，代码生成研究普遍发现低资源语言的通过率显著低于高资源语言（参见 CodeXGLUE、MultiPL-E 等跨语言基准的结论）；其二，API 幻觉研究（如对库函数调用幻觉的评测）显示，训练语料中低频 API 的幻觉率更高；其三，模型在“长尾符号名”上的事实性错误率随符号频率下降而上升，这一规律在知识图谱补全与实体链接研究中均有体现。

本文评述：这些证据不能直接给出“WL 幻觉率是 Python 的 N 倍”这样的精确数字，任何此类断言都需要专门的对照实验。但它们足以支撑一个工程判断：在 WL 场景下，默认假设“AI 输出需要验证”比默认假设“AI 输出基本可用”更符合现有证据。

6.2 一个可复现的对照实验设计

为弥补公开数据的不足，团队可以自行设计小规模对照实验，成本可控且结论对自身场景更相关。设计要点：选取 20–30 个真实任务（数据处理、绘图、符号化简、数值求解各若干），分别用同一模型生成 Python 与 WL 版本；对每个输出执行 L1–L3 检查，记录“首次通过率”“平均修复时间”“幻觉类型分布”。下表给出一个模拟的统计口径示例（数据为模拟，仅示意字段设计）：

需要强调：上表数字为模拟数据，用于说明字段设计与量级差异的呈现方式，不代表任何真实测量结果。真实实验应记录每个任务的原始输出、检查日志与修复 diff，并公开统计脚本以保证可复现。数据预处理细节包括：剔除无法解析的代码块、统一 WL 版本、对消息进行去重与归类、对修复时间采用双人独立计时取中位数。

七、对比与局限：为什么“逐行审计”不是终点

7.1 三种使用姿态的对比

面对 WL 代码生成，用户大致有三种姿态：直接采用（把 AI 当权威）、逐行审计（把 AI 当不可信来源）、分级验证（把 AI 当待验证命题的提出者）。三者在成本、风险与适用场景上差异显著：

本文评述：“逐行审计”看似最安全，实则不可持续——人的注意力是稀缺资源，长时间逐行阅读会产生“审计疲劳”，反而漏掉关键错误。分级验证的优势在于把注意力集中在 L1/L2 无法自动判定的少数位置，符合注意力经济学的直觉。

7.2 边界条件与失效场景

分级验证并非万能。其失效场景至少包括：第一，动态生成的符号名——若代码通过 Symbol["..."] 或字符串拼接构造函数名，L1 的静态扫描会失效；第二，第三方包——Options 查询依赖包已加载，未安装包的选项无法核验；第三，语义等价但风格异常——代码能跑通但性能极差或不符合 WL 惯用法，L1–L3 都不会报警。第三类问题最隐蔽，需要代码评审补充。

此外，验证本身也有成本上限。当任务复杂度上升，L3 断言的编写成本可能超过手写代码的成本，此时“用 AI”在经济上不再划算。笔者认为，判断是否使用 AI 助手的一个实用阈值是：验证成本是否低于从零编写的成本。若否，则 AI 只适合用于生成“思路草稿”而非“可执行代码”。

八、结论与展望：把 AI 助手定位为“可验证的协作者”

回到开篇的问题：Mathematica 用户该把 AI 助手当成“能用的工具”还是“需要逐行审计的实习生”？本文的答案是：两者都不是。更准确的定位是“可验证的协作者”——它擅长提出候选方案、扩展思路、生成样板代码，但不具备对 WL 语义的可靠保证。信任的建立不依赖对模型能力的乐观预期，而依赖一套可执行、可度量、可沉淀的验证流程。

具体而言，本文给出的路径是：以可验证性分级为主线，L1 用内核做符号名与选项的静态核验，L2 用最小样例与消息捕获做动态探针，L3 用领域断言拦截数值与结果性错误；在流程上把生成、扫描、探针、断言、复盘五步固化；在团队层面把幻觉模式与选项白名单沉淀为资产。这套方法不能消除幻觉，但能把幻觉的代价从“一个下午的修复”压缩到“几分钟的检查”。

展望未来，三个方向值得关注：其一，WL 专用代码基准的建立，使幻觉率可被公开测量与横向比较；其二，模型侧对 WL 求值语义的显式对齐，例如在训练中引入“符号存在性”与“选项合法性”的监督信号；其三，工具侧把验证能力内嵌到 Notebook 交互中，实现“生成即检查”。在这些进展到来之前，工程侧的理性选择是：把 AI 当提出假设的人，把内核当验证假设的人。

笔者认为，“近乎犯罪”式的批评虽然情绪化，却指出了一个真问题：当 AI 输出被当作专业服务交付时，验证责任不能被悄悄转移。可验证性分级的意义，正在于把这份责任显式化、流程化，让使用者清楚知道自己为信任支付了什么。

主要参考文献

1. Chen M, Tworek J, Jun H, et al. Evaluating Large Language Models Trained on Code. arXiv:2107.03374, 2021.
2. Austin J, Odena A, Nye M, et al. Program Synthesis with Large Language Models. arXiv:2108.07732, 2021.
3. Cassano F, Gouwar J, Nguyen D, et al. MultiPL-E: A Scalable and Polyglot Approach to Benchmarking Neural Code Generation. IEEE Transactions on Software Engineering, 2023.
4. Lu S, Guo D, Ren S, et al. CodeXGLUE: A Machine Learning Benchmark Dataset for Code Understanding and Generation. NeurIPS Datasets and Benchmarks, 2021.
5. Ji Z, Lee N, Frieske R, et al. Survey of Hallucination in Natural Language Generation. ACM Computing Surveys, 2023.
6. Liu F, Liu Y, Shi L, et al. Exploring and Evaluating Hallucinations in LLM-Powered Code Generation. arXiv:2404.00971, 2024.
7. Wolfram Research. Wolfram Language Documentation Center. https://reference.wolfram.com/language/ (访问日期以文末为准).
8. Wang S, Liu Y, et al. API Hallucination in Large Language Models: An Empirical Study. 模拟整合数据说明：本文表 6-2 中 Python/WL 通过率与修复时间为模拟数据，仅用于字段设计示意，非真实测量结果。