数字、日期与人名一类具体细节的错误最难察觉且后果最大

概念解释

公司沿革写「成立于 1989 年」，真实年份是 1998。标题、叙事、相邻句子都对，错的是一个四位数里的一位。读者对「成立于某年」这个框架没有异议，不会把每个数字当成嫌疑。具体细节错误（specific-detail errors）指的是数字、日期、人名、型号这类槽位上的替换：它们占用的注意力最少，一旦被采用，后果往往最大——钱、身份、时限都挂在这些槽上。

整句假或整段假会绊住阅读。槽位假不会。

机制

阅读抓的是命题框架（「有成立年」），槽位由快速通道填入，很少再做语义校验。合法格式的数字看起来都像真的：四位年份、带单位的剂量、看起来像姓名的专有名词。生成器在这些槽上的先验又很强——常见年份、常见名、常见剂量——于是错槽仍然「长得对」。

后果不对称。框架对、槽位错，下游系统会按槽位执行：转错账、吃错药、写错当事人。框架错往往在采用前就被人拦住，因为整句对不上任务。

怎么研究

在框架正确的文本里替换槽位：年份 ± 若干年、金额改一位、人名换同姓。不提示有错。因变量：自发检出率、被问「检查数字」之后的检出率、采用后的任务后果（模拟）。自变量：槽位类型、格式是否合法、是否用不同样式标出槽位。

基线应是「未被提示时的自发检出」。提示后再查会高估日常检出。把框架错误（整句与任务无关）作为对照，以显示槽位错误的漏检高出多少。

边界

槽位被外部系统约束时（日期选择器、从通讯录插入姓名、金额来自接口），生成器写不出假槽，这条减弱。用户对那个数字有情景记忆（自己的生日、刚看过的报价）时，错槽会撞记忆。纯估算或数量级讨论（「大约几十万」）不是槽位承诺。代码与表格里的槽位有时比散文更容易被工具检查。这条不处理错误分散逼出逐句全检的成本结构。

怎么落地

• 把数字、日期、人名、标识符从散文里抽成独立字段，用与正文不同的样式显示，并尽量改为选择或引用，而不是自由生成。
• 对仍须生成的槽，并排显示来源中的原值；对不上则标冲突，不要静默写入。
• 复制、导出、提交前单独列出槽位清单，让人按字段确认，而不是再读一遍文章。
• 验证：在一篇框架全对、只改了三处槽位的文本上，不提示，看有多少人采用。采用率高而槽位错，说明核验还在读框架，没在读槽。

延伸

• 同组：L3.03.1 流畅表述不等于正确 · L3.03.2 核查成本可能高于自行完成 · L3.03.3 高后果场景不应把核查完全交给用户 · L3.03.4 错误分散在正确内容之中时，核查必须逐句进行，成本接近自己重写 · L3.03.5 用户越不熟悉某领域越难核查，而这正是最可能求助系统的场景 · L3.03.6 表述的确定语气与内容的可靠程度之间没有关系 · L3.03.8 把核查责任写进免责声明并不减少错误的实际传播
• 相邻：L3.02 来源标注 · L3.08 生成结果的来源标注
• 站内检索：specific-detail errors · entity slot error · numerical hallucination