萃靈 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 實際顯示為準。