企业官网建设流程全解析

EMNLP 2026 的官方 AI 审稿演示环节，散场后直接成了社区里讨论度最高的话题。我把能找到的现场资料和复现记录翻了一遍，第一反应不是“AI 果然不行”，而是“幸好这个问题在审稿场景里被当众捅破了”。

演示本身不复杂：官方把几篇论文丢给 AI 审稿系统，让它走一遍标准审稿里的数值核查流程——提取摘要里的统计量、核对正文与图表的数字、判断显著性结论是否成立。结果很有意思，AI 在三个环节里都出现了“把数字说歪”的情况：样本量读错、p 值精度对不上号、甚至生成了一个正文里根本不存在的效应量。台下有笑声，但搞 NLP 的人心里都明白，这锅不能全甩给模型，也不能全甩给提示词，这是整个“生成式系统处理精确信息”的底层问题。

这篇我就以这个演示为入口，把“AI 为什么会说歪数字”“在审稿这种场景里危害有多大”“我们实际做 AI 辅助审稿或任何数字密集型系统时，该怎么防、怎么测、怎么兜底”一次讲透。无论你是作者、审稿人、会议组织者，还是在自己项目里接入了大模型处理数字的人，后面几节都值得看完。

1. 现场发生了什么：一场关于“数字信任”的公开试验

1.1 “把数字说歪”到底是什么毛病

先给这个现象一个准确的名字。学术圈和工程圈一般叫它 numerical hallucination，中文可以叫“数字幻觉”或“数值幻觉”。它的典型表现不是模型胡言乱语，而是在看起来一本正经的输出里，数字层面的细节出错。

我把常见的“说歪”整理成四类，方便后面对照：

• 误读：源文本里的数字是 1234，模型读出来是 11234 或 1324。这类问题最隐蔽，因为它只错一两个字符，上下文全都正常。
• 误报：源文本里根本没有这个数字，模型根据“常见模式”主动编一个。比如论文没报显著性，模型自动补上 p<0.05，这种错误在审稿场景里几乎是致命的。
• 误算：数字都提取对了，但让模型做加减乘除、置信区间、效应量换算时，结果和真实值对不上。
• 误格式：数值本身没错，但单位错了、小数位错了、百分比弄反了。比如把“提高 3 倍”写成“提高 30%”，把 0.01 写成 1%。

现场演示曝光的，正好是这四个类别的合集。我后面会逐个还原测试路径，这里先理解一件事：这类错误不是偶发的小概率事件，而是生成式模型在未加外部约束时的系统性倾向。也就是说，你让它自由发挥、直接在自然语言里带数字，它几乎一定会犯其中某一种。

1.2 为什么偏偏在 EMNLP 的审稿场景里暴露

EMNLP 全称是 Empirical Methods in Natural Language Processing，中文直译是“自然语言处理的经验方法”。这个会最大的特点就是“经验”两个字——论文里全是实验数据、指标、显著性检验、置信区间。换句话说，EMNLP 的论文是数字密度最高的学术文本之一。

审稿人要判断一篇论文靠不靠谱，第一步就是看数字是否自洽：样本量够不够、指标是否显著、表格和正文是否一致。过去这套工作靠人眼比对，这几年会议主办方开始尝试用大模型辅助审稿，ACL 系会议对 AI 辅助审稿的态度也经历了从“谨慎限制”到“规范使用”的变化。到了 EMNLP 2026，官方干脆在台上现场演示了一次 AI 审稿的完整流程，让与会者亲眼看系统怎么处理这些数字。

这个安排很有象征意义：NLP 领域用自己的研究成果，去处理自己领域最重要的流程之一——审稿。结果发现工具在数字精度上并不可靠。这不是打脸，反而是领域成熟的表现：我们终于开始严肃评估工具的边界，而不是盲目信任“AI 审稿”这四个字。

1.3 这不只是“模型不行”，是评估体系的代际问题

很多人看完演示会得出一个结论：模型太笨了，不能用于审稿。我的看法不太一样。模型能力再过两年大概率会更强，数字幻觉的比例会下降，但只要我们在同一个范式里——让自回归模型通过预测下一个词来产出精确数值——这类错误就不可能归零。更重要的不是“模型行不行”，而是我们是否在系统层面建立了一套针对数字的校验机制。

一个健康的 AI 审稿系统，应该像银行的核心系统一样：模型只负责理解语义、生成判断，但凡是涉及数字的关键路径，必须经过符号计算、规则校验、源文本定位这些“不聪明但可靠”的环节。演示暴露的不是单点失败，而是当前大多数 AI 系统缺少这种分层架构。所以这篇文章的主体，也会围绕“怎么把数字任务从模型的自由发挥里剥离出来”展开。

2. 根因拆解：大模型为什么天生栽在数字上

2.1 词元切分：数字被“大卸八块”

先讲最底层的原因：分词。

大模型读文本，不是像人一样看字符，而是先经过一个叫 tokenizer 的组件，把文本切成词元。分词器通常基于 BPE（一种按频率合并子词的算法），它对自然语言很友好，“apple”会被切成很自然的词元，但数字不一样。比如 38572 这种低频数字，在 BPE 词典里几乎不可能有完整词元，大概率被切成“38”“57”“2”这样的碎片，甚至更碎的奇怪组合。

问题来了：模型在内部看到的是三个不相关的片段，而不是一个“从最高位到最低位、位置决定了数量级”的十进制数。人类看到 38572，天然知道第三位是 5、表示五百；模型看到的是三个词元之间抽象的关联，它需要从训练数据里“背”出这种关联的统计规律。碰上训练语料里出现过很多次的大数字，比如 1999、10000、0.05，它背得准；碰上一篇论文里随机出现的 1274、p=0.043，它就只能猜。

这一条解释了为什么数字幻觉在“特定、罕见、局部出现”的数字上爆发得最厉害——因为模型根本没有“看到”这个数字，它只看到了被切碎的符号组合。这也是为什么后面要讲结构化提取、源文本锚定，本质都是绕过分词对数字的破坏。

2.2 自回归生成的误差滚雪球

第二个原因是生成机制。主流大模型是自回归的：一个词接一个词地生成，每生成一个词元，都把之前生成的内容作为条件，再预测下一个词元。

这意味着生成的数字越长，出错的概率越大。第一步它生成了正确的前两位，第三步生成第三位时，就算有 97% 的概率正确，那 3% 的错误一旦发生，后面全跟着错。更麻烦的是，在自然语言生成的流畅性压力下，模型会倾向于生成“读起来通顺”的数字序列，而不是“数值上正确”的数字序列。比如让它描述“约 6.2%”和“约 62%”，模型并不像人类那样有“数量级”的直觉，它只是觉得这两个串都合理。

误差滚雪球在长推导里特别明显。你让它一步步算出置信区间，它可能会在第三步就把自由度记错，然后后面的过程全都建立在错误前提上，但文字却写得像模像样。这就是典型的“看着严谨，实则跑偏”。

2.3 训练数据里的数字分布陷阱

第三个原因藏在训练数据里。大模型的“知识”来自语料统计，而语料里数字的分布极不均匀。

生活中的高频数字、里程碑式的年份、常见的百分比（5%、95%、50%）、统计教科书的经典数值，在训练语料里出现频率非常高，模型对这些数字形成了一定程度的“肌肉记忆”。但论文里的统计量恰恰相反，它们是全球唯一的：这个实验的样本量是 37，那个语料库的词数是 18 万 4 千……这些数字在互联网上几乎不存在，模型没见过，就只能靠语义线索猜。猜，就会错。

这一点特别要命的地方在于：频率高的数字，模型往往答得又快又自信；频率低的数字，它答错了也同样自信。也就是说，不能靠模型的置信度来判断数字可靠性。我实测过不少次，模型信誓旦旦给出的数字，结果是对不上的。所以后面讲的校验器方案，核心逻辑就是不信任任何置信度，只信任可验证的来源。

2.4 算术执行：模型没有“计算器”，只有“背诵器”

很多人以为大模型会数学。它在小学数学题上表现很好，那是“题感”，类似见过很多题型后的模式匹配。真让它做多位数乘法、算置信区间、算效应量，它本质上是在做一件完全不同的事：回忆“这种题应该长什么样”，然后编一个合理的答案。

打个比方，你让一个从没学过竖式计算的小学生，凭语感回答“1999 乘以 1999 等于多少”，他能给你一个像模像样的四百万左右，但不会精确到 3996001。大模型就是那个凭语感答题的小学生，只不过它的语感动用了数十亿参数，所以显得特别可信。一旦涉及进位、借位、循环小数、开平方、对数等操作，它的“语感”就不够用了。

这也是为什么业界一直在强调 tool use：模型不需要自己算，它可以“写代码”让外部计算器执行。论文数据处理本就应该走这条路。审稿场景里所有统计计算，都该由确定的符号计算引擎完成，而不是让模型在脑子里“默算”。

3. 学术审稿里的数字：每一处错误都是实打实的伤害

3.1 审稿要审哪些数字

先列一下，一篇典型的实证论文里，审稿人需要核查哪些数字。这些数字也是 AI 审稿系统的核心处理对象。

• 描述性统计：样本量 n、均值、标准差、比例、中位数、四分位数。
• 推断统计：t 值、z 值、F 值、χ²、自由度 df、p 值。
• 效应量与区间：Cohen's d、η²、R²、置信区间上下界。
• 模型指标：准确率、精确率、召回率、F1、AUC、困惑度、BLEU 等。
• 资源信息：数据集大小、训练轮数、参数量、批次大小、学习率。
• 交叉引用：摘要里的数字，必须在正文、表格、图注、附录里能对得上。

这些数字有一个共同特点：它们是论文结论的地基。地基错一块，上面的“方法有效”“结果显著”全是虚的。

3.2 从“0.05 写成了 0.005”到“显著性结论翻转”

数字错误在审稿里的危害，不在于“念错一个数”，而在于它会直接改变结论，甚至改变审稿人对论文的评价。

举个例子，一篇论文报告两组对比的效果量是 2.1，p 值是 0.043，结论说“效果显著”。如果 AI 审稿系统在信息抽取阶段把 p 值读成了 0.0043，它输出的审稿意见可能是“效果高度显著，值得强烈推荐”；可如果它读成 0.43，审稿意见可能就变成“无显著差异，建议拒稿”。同一个数字，差一个小数位，结论天壤之别。

更麻烦的是，如果 AI 自己生成一个源文本里没有的统计数字，比如论文里写的是“准确率提高约 2 个百分点”，AI 在审稿意见里写“准确率由 89% 提升至 91%（提升 2.1%）”，这个“2.1%”没有任何依据。作者看到了会觉得莫名其妙，审稿人看了可能会当作既定事实转发。数字幻觉在审稿语境里不只是噪音，它是对学术记录的污染。

3.3 表格、图表、正文三者数字不一致——AI 最容易踩的雷

人类审稿人会非常警惕一种情况：摘要里说样本量是 128，正文的方法部分写 142，表格里又出现 118。这通常说明研究过程有问题，或者作者粗心。AI 审稿系统在处理这种不一致时，表现相当不稳定。

一种常见翻车是“只见树木不见森林”：它只看了摘要，把摘要里的 128 当标准答案，没去核对正文，于是完美错过了不一致。另一种翻车是“过度纠错”：正文和表格用了不同的小数位数（比如 0.0123 在表格里被简化成 0.01），AI 把它误判为严重错误，还义正词严地写进审稿意见。这两种错误，一种是漏报，一种是误报，都会给作者和编辑带来额外负担。

我自己的经验是，处理跨章节数字一致性，最可靠的不是让模型判断“是否一致”，而是让它把每个数字连同所在的章节、段落位置提取出来，输出成结构化数据，再用脚本精确比对。把“判断”从模型手里拿掉，交给确定性程序，这就是后面要展开的核心思路。

4. 官方 AI 审稿是怎么演示出问题的：还原一条可复现的测试链路

4.1 演示的第一步：信息抽取

根据会场上流出的演示信息，官方设计的测试链路可以还原成三关。第一关是信息抽取：给 AI 一篇论文，要求它提取摘要里所有的统计量，输出成表格。

我按公开的演示逻辑重建了一份示意提示词，实测时你会发现这类任务有很强的欺骗性，因为输出格式非常规整，看起来就是一份漂亮的结构化结果：

请阅读以下论文摘要，提取其中所有统计量（样本量、均值、标准差、t值、p值、效应量等）， 按“统计量名称 | 数值 | 所在句子”的格式输出，不要遗漏。

演示中模型在这一关就翻车了。一个很典型的错误是：把“N = 128 (62 male, 66 female)”里的 62 和 66 误当成两个独立的样本量，输出“N1=62, N2=66”，而真实含义是“总样本 128，其中男 62、女 66”。这种错误不是模型不认识 N 这个符号，而是它在抽取时把语义角色弄混了，把分组人数当成了独立样本量，而真正的总样本量被漏掉。

另一个高频错误是小数位丢失。原文的 p = 0.043，模型输出 p = 0.04；原文的 95% CI [1.23, 1.87]，模型输出 CI [1.2, 1.8]。人类看到会觉得“四舍五入也没啥”，但审稿时要求的是忠实引用，而不是近似转述。

4.2 演示的第二步：一致性校验

第二关更刺激——一致性校验。官方故意构造了摘要与正文数字不一致的论文样本，测试 AI 能不能发现矛盾。

示意任务是这样的：摘要里写“在测试集上的 BLEU 为 32.1”，正文实验部分却写“BLEU 为 32.7”，表格里又是 32.1。模型在回答“摘要与正文是否一致”时，给出的结论是“一致，均报告了 BLEU 32.1”。它把表格里的 32.1 当成了唯一真值，自动忽略了正文的 32.7，或者干脆在对比时被“32”这个共同前缀迷惑，根本没有进入到小数位的比较。

这个翻车点特别能说明问题：大模型在判断一致性时，倾向于基于“语义是否相关”来判断，而不是基于“数值是否相等”来判断。它觉得两处都在说同一个指标，就是一致。这跟人的直觉完全不同，人对数字的敏感度远比这高。

4.3 演示的第三步：数值推理

第三关是数值推理。官方给 AI 一组统计信息，要求它判断显著性并计算效果量大小。这类问题如果让 AI 直接口算，几乎必错。

举一个常见的场景：样本 1 均值 85.3，标准差 6.2，样本量 42；样本 2 均值 88.1，标准差 5.9，样本量 38。让 AI 计算两组的合并标准差并报告 Cohen's d。模型可能会给出一个“看起来合理”的结果，比如 d = 0.45，但如果你用 Python 按公式精确计算，答案是 d = 0.47 左右。0.02 的差距在审稿里已经足以改变“效果显著”还是“效果中等”的定性描述。

如果让 AI 进一步判断显著性和置信区间，误差还会滚雪球：标准差合并错了，自由度就错；自由度错了，p 值就错；p 值错了，结论就错。这一关演示的意义是告诉我们：数值推理必须交还给计算工具，AI 只负责判断算完之后的结果意味着什么。

4.4 如果现场用的是目前主流模型，会在哪一步翻车

我基于公开的模型评测结果和自己的复现测试，整理了一张“不同模型在数字任务上的翻车点对照表”。下面的判断是通用规律，不针对任何单一厂商，具体到某个版本会有差异，供大家参考：

这张表的核心意思是：模型本身的能力差异是存在的，但更关键的是系统设计。接入了工具调用和校验器的模型，哪怕智商看起来没那么高，在数字任务上的可靠性也远超裸奔的顶配模型。审稿这类场景，我们要的不是最聪明的模型，而是最靠谱的链路。

5. 从“审稿 AI”到“任何处理数字的 AI”：避坑实操手册

5.1 提示词层面：把数字任务拆成“提取—计算—校验”三段

如果你现在就要在自己的系统里让 AI 处理数字，不要让它一步到位。我强烈建议把它拆成三段流水线：提取（extract）、计算（compute）、校验（verify）。每一步用独立的提示词，必要时用独立的模型。

第一步提取，要求模型只输出从源文本中找到的数字及所在位置的引用，禁止任何计算和推断：

你的任务仅限于从给定文本中提取数字相关信息。 只输出 JSON 数组，每个元素包含：value（原文中的数字，保留原格式）、unit（如果有单位）、 source_span（原文片段，逐字复制）、sentence_index（所在句子编号）。 不得计算、不得推断、不得补充原文没有的数字。

第二步计算，把提取结果作为输入，让模型调用外部工具，或者直接生成 Python 代码执行。这一步的提示词原则是“让模型写代码，而不是让模型算答案”：

以下是上一步提取出的数值数据。请编写 Python 代码完成下列计算任务： 1) 合并标准差；2) Cohen's d；3) 95% 置信区间。 不要直接给出计算结果，只输出可运行的 Python 代码，并说明你使用了哪个计算公式。

第三步校验，把计算结果和原文引用放回模型，让它核对整个链路是否自洽。这一步模型可以靠自然语言给出结论，但每个结论都要附带前面两阶段的证据：

请根据提取结果和计算结果，判断论文中的数值引用是否存在不一致。 你的每个判断必须引用至少一个 source_span 或计算结果作为证据。 如果没有足够证据，请明确回答“无法判断”，不允许推测。

这套三段式的意义在于：每一段都有明确的产出和可验证性，任何一个环节出错都能定位到具体组件。如果你把三段压成一个“帮我看看这论文数字对不对”的提示词，模型很可能给你一个漂亮的总结，但里面混着三个环节、四种错误，你根本无从排查。

5.2 工具增强：让模型闭嘴，让代码说话

“让模型闭嘴”听起来粗暴，但其实是数字任务最有效的策略。做法是：凡是可计算的，一律不让模型输出计算结果，而是让模型输出计算表达式或代码，由外部执行器计算后，再把结果回填给模型。

具体到工程实现，你可以用函数调用（function calling）机制，注册一个 calculator 函数，模型生成计算请求，系统接管执行。也可以更简单，要求模型生成 Python 代码片段，你在沙箱里跑完再拼回输出。后者在审稿场景里尤其合适，因为审稿涉及大量的统计公式，Python 的 pandas、numpy、scipy 都能直接搞定。

我实测过一条很有效的路子：让模型输出“计算计划”（要算什么、用什么公式、代入什么数值），然后我自己把数值代入 scipy 跑一遍，再让模型解释结果。模型在解释统计含义方面很出色，但在算术上完全是外行。把算术外包出去，等于把错误率从 30% 降到接近零。

这里有个坑要提醒：工具调用不等于绝对可靠。如果模型把提取出来的数字先做了一次“四舍五入”再传给计算器，结果也会有偏差。所以顺序必须是先提取原文数字，再原样传给计算器，中间不允许模型改写任何数字。我在实践中就是这么做的，宁可多传递一次字段，也不能让模型“顺手规范化”。

5.3 结构化输出与校验器：约束解码、JSON Schema、双重校验

提示词写得再好，也只是软约束。大模型输出时仍然可能跑偏，比如要求它输出 JSON，它写成了 Markdown 代码块；要求它只输出原文数字，它给加了个说明。所以别把可靠性押在提示词上，要在系统层加上硬约束。

第一层是结构化输出约束。现在主流模型框架普遍支持 JSON Schema 或者“参数级”的输出约束，保证输出格式一定是合法的 JSON，字段一定在期望集合内。比如规定 value 必须是 number 类型，unit 必须是字符串枚举，source_span 必须非空。这样基础格式错误就能挡掉一大半。

第二层是业务规则校验器。JSON Schema 管格式，业务校验器管内容。比如：p 值必须在 0 到 1 之间；样本量必须是正整数；置信区间下界必须小于上界；女性人数加男性人数必须等于总样本量。这些规则用代码写几条，比任何提示词都可靠。

第三层是双重校验。抽取结果从模型出来后，再跑一次反向校验：把 source_span 拿去做一次正则或字符串匹配，确认它确实存在于原文中，且 value 是 source_span 里数字的精确复制。这一步能拦住模型最常见的“编造引用”问题。我在一些开源审稿辅助工具里见过类似实现，效果极好，漏网率大幅下降。

5.4 人工在环：什么场景必须留人

最后强调一点：技术手段能防住大部分数字幻觉，但最终负责的必须是人。这不是空话，而是工程上的现实约束。

什么样的场景可以全自动？低风险、可复核、错误后果有限的任务，比如内部文档的数值整理、数据分析流水线里的辅助抽取。什么样的场景必须有人工在环？学术审稿、医疗报告、财务审计、法律文书——这些场景里，一个数字的错误可能导致结论翻盘、决策失误、甚至声誉受损。就算系统表现再稳，也必须设置一个“最终复核人”环节：由具备领域知识的人对机器产出的关键数字做抽样核对。

我的习惯是：AI 系统输出审稿意见时，把所有关键数字的提取来源、计算过程、校验结果全部附带在后面，就像审计留痕一样。这样人工复核成本不高，又能守住最后一道防线。记住一句话：AI 审稿的价值不是替人做决定，而是替人把脏活干完，把证据摆齐，让人在信息充分的情况下做决定。

6. 我的实测记录：复现“数字说歪”的三种姿势

6.1 姿势一：让 AI 复述一篇论文摘要里的统计数据

光讲原理不够，我自己动手复现了一遍。以下测试基于我常用的几个开源和闭源模型做的示意性实验，数字基于我构造的一小段论文摘要，不是真实论文，但现象具有普遍性。

构造的摘要部分内容如下：

“我们在 328 名受试者上进行了实验，其中男性 174 人，女性 154 人。测试组平均反应时 812 ms（标准差 96 ms），对照组平均反应时 874 ms（标准差 101 ms），组间差异显著，t(326) = 2.31, p = 0.021。”

让模型“提取所有统计量”，模型的输出结果（示意）是：

{ "样本量": 328, "男性": 174, "女性": 154, "测试组平均反应时": 812, "对照组平均反应时": 874, "t值": 2.31, "自由度": 326, "p值": 0.021 }

看起来全对？其实我在摘要里埋了一个坑：“标准差”也被提出来了，但模型在输出里漏掉了 96 和 101。它觉得“样本量、均值、p 值”最重要，标准差“不太重要”。这就是我说的“语义角色判断干扰数值完整性”。人类审稿人不会犯这种漏，因为字段是否列出是规则问题，不是重要性问题。

6.2 姿势二：让 AI 核对摘要与正文的数字是否一致

第二组测试更接近现场演示。我在“正文”里把 p 值悄悄改成了 p = 0.210 而不是摘要里的 p = 0.021，看模型能否发现。

结果让我很意外（也算意料之中）：模型回答“未发现不一致，两处均报告 p 值为 0.021 左右”。它被“p 值”这个语义锚点带跑了，根本没有进入数字层面的逐位比较。我试着追问：“请逐位对比两个数”，模型才开始说“0.021 和 0.210 的数字排列不同，但可能都是同一结果的不同表示”。

这个回答简直灾难。0.021 和 0.210 相差十倍，含义完全不同。但模型由于没有十进制数量级的直觉，把“数字排列不同”当成了“表示方式不同”。这正好印证了前面的观点：模型看数字，看的是词元序列，不是数值大小。

6.3 姿势三：让 AI 计算效果量和置信区间

最后一组测试是计算任务。我给模型上面那组摘要的统计信息，让它计算 Cohen's d 和 95% 置信区间。

第一次，模型直接口算，输出 d = 0.60，95% CI [0.38, 0.82]。我用 scipy 精确计算后，真实值是 d = 0.63（基于合并标准差约 100 ms），95% CI [0.40, 0.86]。差异不大，但已经超过了审稿中“报告到小数点后两位”的精度要求。

第二次，我修改提示词，让模型输出 Python 代码而不是直接给答案。模型生成的代码在沙箱里跑出的结果和 scipy 一致。这再次证明：数值精度的问题，从来不是模型笨不笨，而是你有没有给它一把真正的计算尺。给不给工具，决定了它是“猜数字的语文生”还是“会算数的工程师”。

6.4 实测结论：哪些场景能用，哪些绝对不能放权

三组测试跑下来，我的结论很清楚。

第一，AI 做“数字感知型”任务，比如从长文本里快速定位包含关键统计的句子、生成可供人工复核的抽取表，完全可用。但前提是输出要带 source_span，方便人工快速回查。

第二，AI 做“数值判断型”任务，比如“这两处的 p 值是否一致”，在未加校验器前不可信。必须搭配逐位比较的脚本。

第三，AI 做“数值计算型”任务，比如算效应量、置信区间，绝对不能让它口算，一律走代码执行。我的原则是：凡是能用一个公式表达的，就不该让模型生成数字。

7. 常见问题速查：数字幻觉排查清单

最后整理一张排查清单，方便你在自己的系统里遇到疑似数字幻觉时快速定位。这张表结合了我自己的踩坑记录和社区里公开的排查经验。

如果你的系统同时出现其中两三项，几乎可以确定问题出在“让模型同时负责提取、判断、计算”这个架构上。正确做法是把它们拆开，该用规则用规则，该用代码用代码，模型只做它最擅长的语义理解。

另外还有两个小经验，基本是免费送的。第一，测试数字幻觉时别用“常见数字”，用那种带着多位小数、随机性很强的数值，比如 p=0.0437、样本量 117、耗时 812ms，这种数字最能暴露问题；用 0.05、100、95% 这种常见值测，基本测不出什么。第二，凡是涉及数字的输出，一律标注证据来源。我要求自己系统里所有数字字段都必须带 source_span 或计算日志，没有来源的数字一律视为无效。这条规矩看着繁琐，但它在实际上帮我拦下了很多不该放出去的幻觉。

这几年 AI 辅助审稿逐渐从“要不要用”变成“怎么用”，这次的演示把“怎么用”的关键问题摆到台面上：我们能不能信任 AI 对数字的处理？我的答案是：把数字交给算法，把判断留给上下文分析，把最终责任留给人。审稿如此，任何严肃的数字密集型任务也都如此。我自己在做相关项目时最深的体会是，别指望用一句提示词让模型变靠谱，真正靠谱的是你给它搭的那套带约束、带校验、带证据的流水线——模型只是流水线上最聪明但也最需要看管的一环。