萃靈 Essevin
问一个看似幼稚的问题：strawberry 有几个 r？正确答案是三个。把字母逐个写开：s t r a w b e r r y，第三、八、九个位置都是 r。
但把同一题交给 AI，偶尔会收到两个、四个，甚至一段语气十分肯定的错误解释。这个例子之所以流行，不是因为所有模型都答不出来；相反，很多模型现在能答对。它有用，是因为一个简单错误把一件重要的事照亮了：答案读起来顺，不代表它已经逐字核对。
AI 看到的不是一串小方格
人眼读 strawberry，很自然会把它当成十个字符。语言模型接收的却通常是 token 序列。Token 可以是一个完整单词，也可以是单词的一部分；切法由 tokenizer 的规则决定，不是按照「每个英文字母一格」的直觉排列。
这里有一个茶餐厅比喻。你点一份餐，厨房不一定逐粒米记数，可能先按「白饭」「配菜」「酱汁」几个组合备料。若有人突然问「这份饭有几粒米」，厨房的流程本来就不是为这个问题设计的，便需要另拿工具计算。
Tokenization 只是其中一层。语言模型的主要工作是根据前文预测合理的下一段文字，不是内置一个逐字元计数器。当问题要求它在单词内做精确位置操作时，它可能先依熟悉的语言模式猜一个答案，再用流畅句子包装起来。
这也不能简化成「AI 看不见字母」。模型可以通过更仔细的推理、特殊的字符表示或外部工具答对；不同模型、不同上下文和不同提示，结果都可能不同。真正可靠的结论不是「某模型永远数错」，而是「需要精确计数时，不要只依赖一次直觉回答」。
三种验证方法
方法一：要求逐字编号
先不要让 AI 报总数，要求它把中间步骤摊开：
不要直接回答。请把 strawberry 拆成逐字符编号表，格式为「位置｜字符」，完成后只计算字符 r 的出现次数，最后列出出现位置。这个方法把「猜答案」改成「展示可检查的证据」。如果表格本身已经错，你会在总数之前看见问题。
方法二：改变输入表示
把字母用分隔符号拆开，降低模型把整个单词当成一个熟悉形状的机会：
s | t | r | a | w | b | e | r | r | y然后问：「只计算 r，请列出位置与总数。」这不是魔法，只是把任务转成更接近你要核对的数据结构。对姓名、产品代码和文件编号，同样可以先逐项分隔。
方法三：交给确定性工具
只要有一点点程序或表格经验，计数应当交给规则明确的工具：
word = "strawberry"
count = sum(1 for character in word.lower() if character == "r")
print(count) # 3不写程序也可以要求 AI 生成公式，再由表格执行；重点是把「解释」与「计算」分开。模型负责把问题翻成步骤，工具负责返回可重现的数字。
这个小测试真正教你的事
流畅度不是证据。 一段完整、肯定、语法正确的文字，只能说明它很会写，不代表每个细节都查过。
中间表示要能被人读懂。 要求表格、编号、引用原句或计算式，等于把黑盒打开一条窄缝。你不需要看见模型所有内部过程，只需要一条能检查结论的路。
问题越细，越要指定验证方式。 写一张贺卡可以接受「先给一版」；核对身份证号、合同日期或药物剂量，就应当要求来源和第二次确认，必要时交回专业人士。
三个常见误解
「把同一题问三次，少数服从多数」
三次回答可能共享同一个错误模式，并不构成独立验证。换一种表示法，或改用程序、表格与原始文件，才是真正增加证据。
「模型越大，就不会犯这种错」
能力较强的模型可能更常答对，但没有模型可以替你保证每一次字符计数。任务的风险，决定你需要多少核对，而不是模型名称本身。
「只要叫它逐步思考，就一定可靠」
要求步骤可以改善可读性，却不等于步骤必然正确。仍要检查输入、规则和最后结果；涉及重要决定时，保留人工复核。
一张可保存的核对清单
下次遇到精确数字、字符串或条款，按这个顺序走：
先问模型给出结论，但把它当草稿。
要求逐项表示：位置、来源句或计算式。
用另一种表示法重做一次。
重要结果交给确定性工具或另一位专业人士。
strawberry 的三个 r 看似只是趣味题，实际上是在提醒你：AI 最适合先帮忙整理和提出方向；当答案需要精确到每一个字符，就应该让证据走在语气前面。
＊本文资料截至发稿日（2026 年 8 月 6 日），仅供一般参考，不构成任何建议；第三方产品之功能、价格与政策，以其官方最新公布为准；Essevin 服务详情以官网与 console 实际显示为准。