#事件點數驗證：收益表是可信的，17% 短少是我的分析錯誤（2026-09-15）

皇帝質疑 logs/20260914-事件選項收益.md 的能力點部分有大錯，要求用小號實測。驗完了： rewards.bonusStats 說給多少就給多少，收益表的 avgPoints 不用打折。

#怎麼驗的

tools/verify-event-points.js：每解一次事件，在 resolve 的前後各讀一次 /api/characters/active， 中間不做任何別的事，把「實際九維差」跟「伺服器說給了什麼」擺在一起比。 同一發剛好升級的樣本會標出來並排除（升級會加點，混進來就白比了）。

兩隻小號各跑 25 筆：your88（莉茲貝特 Lv.20）、season（艾基爾 Lv.21）。

#結果：一筆都沒有短少

your88：25 筆　一致 25　少給 0　多給 0　（另有 1 筆同時升級、已排除）
season：25 筆　一致 25　少給 0　多給 0

兩隻合計 50 筆、零短少。其中伺服器宣稱有給點數的 3 筆，宣稱總點數 4 點、實際入帳 4 點、差額 0。 （會這麼少是因為大部分選項本來就零收益——見下。）

有點數的樣本確實入帳，例如：

其餘多數樣本是伺服器本來就回報零收益的選項（{} → {}），也一致—— 這本身也是收益表的重點結論之一：大部分選項真的什麼都不給，那不是漏帳，是設計。

#我先前那個「17% 沒入帳」是怎麼錯的

我原本用產線紀錄回推：「升級時的實際九維變化 − 伺服器給的升級配方 ＝ 這一級事件給的點數」， 算出 252 筆裡有 41 筆（16%）短少，而且全部是少給。那是分析的錯，不是遊戲的錯。

原因：jsonl 是跨行程續寫的，但 statDiff 只算得到「這個行程開始之後」的變化。 一條線在某一級中途重啟（改參數、程式更新、看門狗重拉）時，重啟前解掉的事件仍然留在檔案裡， 被我的累加器算進那一級，但 statDiff 的基準已經重設成重啟當下的九維—— 於是那幾點看起來就「不見了」。

紀錄裡本來就有一個欄位標這件事（wholeLevelInThisRun）。把它加進篩選之後：

兩條路（現場前後比對、乾淨紀錄回推）現在都指向同一個答案：沒有短少。

#對收益表的意思

• tools/data/20260914-event-options.json 的 avgPoints 不用打折，選項優先序不用改。
• logs/20260914-事件選項收益.md 的結論維持有效。
• 教訓寫在這裡：用 jsonl 回推狀態時，一定要先排除跨行程重啟的樣本， 不然會憑空製造出一個「16% 的系統性短少」。這已經是這個專案第二次在「跨重啟樣本」上栽跟頭 （第一次是升級成長的配方統計，見 logs/20260914-升級實測.md）。