52 張照片、5 位評審、96% 同分機率：我怎麼設計這套評分系統
一場攝影比賽，一堆藏在細節裡的規則
醫院今年 40 週年院慶，辦了一場攝影比賽。同仁組收到 29 件投稿，社會組 23 件，五位評審要分別替兩組照片打分數。
任務交到我手上的時候，聽起來輕輕鬆鬆——找幾位評審、發幾張照片、算一算分數、公布名次。我心裡也是這麼想的，直到我坐下來，把整件事在腦子裡認真跑過一遍。
麻煩是一層一層冒出來的。
評審之間不能知道彼此是誰，免得互相參考、互相影響——那要怎麼設計登入方式，才不會讓某位評審不小心瞄到別人的帳號？投稿者的任何資訊也不能讓評審看到，「這是誰拍的」這種念頭一旦浮現在評審腦中，評分就不可能純粹——那資料庫裡的備註欄位，要怎麼確保它永遠不會被任何一支 API 不小心吐出來？每一項評分標準——構圖、主題、創意——權重不同，加權總分要怎麼算才公平、才禁得起質疑？
我在紙上寫下這些問題，越寫越安靜。最後一個問題冒出來的時候，我停下筆：如果兩張照片算出來的分數一模一樣呢？名次要並列，還是要有一套讓人心服口服的規則去分出高下？
用 Excel 表單湊合著算，或許能跑得完。但我幾乎可以想像比賽結果公布那天，有人皺著眉頭問一句：「這個排名到底是怎麼來的？」而我答不出一個站得住腳的答案。
那一刻我告訴自己：這次我想做的，不是一個能用的東西，而是一個經得起檢驗的東西。
這次，先寫SDD規格書
我沒有馬上打開編輯器。
我先開了一份空白文件，把整件事，一條一條寫成規格書。
角色有哪些、每個角色能做什麼不能做什麼、資料表怎麼設計、API 要怎麼隔離評審跟評審之間的視角、加權總分的公式、例外狀況要怎麼處理——一條一條列下去，像是在替一棟還沒動工的房子，先把每一根樑柱畫進藍圖裡。不是因為這次比較有時間，而是這次牽涉到的是同事的作品、評審的公正性、比賽結果的公信力。這種東西一旦砸了，沒有「重新上傳一次」這種退路可以走。
規格寫好，我把它交給 Claude Code，看著終端機一行一行吐出程式碼。兩天內，系統的骨架跟核心功能就成形了：管理後台、評審登入、評分頁面、成績總表、CSV 匯出、資料庫備份——我對著規格書，一項一項勾掉，心裡踏實了不少。
但規格書裡有一條，我的游標在上面停了很久，遲遲沒有動手寫死。
同分機率：一個藏在心裡的疑問
那一行字是這樣寫的：「排名依加權平均分數由高到低排序，同分時排名並列。」
我自己打下這句話的時候，心裡就有一種說不上來的不踏實。評分是 1 到 10 分的整數，五位評審各打一次，加權平均再取到小數點——直覺告訴我，同分應該是少數的意外，頂多寫一句「同分重評」就打發過去了，誰會那麼剛好，五個人打出來的分數，加權平均完全一樣？
但那個念頭沒有散去，反而在我心裡越滾越大聲：真的是這樣嗎？如果同分其實不是少數意外，而是常態呢？如果「並列名次」最後變成一半以上的照片，全都掛在同一個名次上，那這場比賽的排名，還有什麼意義？
我盯著螢幕，手指停在鍵盤上方，沒有繼續往下寫規格。
直覺這種東西，我不敢信。我決定不要用它來回答這個問題——跑一次模擬看看，數字會告訴我答案。
模擬結果出爐的那一刻
我另外開了一個檔案，寫了一個小程式。分別針對同仁組 29 件、社會組 23 件，模擬五位評審打分數的情境，跑了兩種假設：一種是評審完全隨機打分，另一種是評審打分習慣比較集中——多數落在 6 到 9 分之間，比較貼近真實世界評審下手的手感。
我按下執行，螢幕安靜了一兩秒。
數字跳出來的時候，我盯著螢幕愣住了。
| 情境 | 同仁組（29 件）同分機率 | 社會組（23 件）同分機率 |
|---|---|---|
| 評審完全隨機打分 | 96.1% | 86.3% |
| 評審打分習慣集中（多數落在 6-9 分） | 100.0% | 99.1% |
不是「偶爾會同分」。是幾乎必然會同分。
而且評審打分越集中——也就是越貼近真實比賽裡評審手鬆、大家都給高分的情況——同分機率反而衝到接近 100%。我原本以為自己在處理的是一個邊緣案例，一個規格書裡順手寫一句「並列」就能打發的小地方。跑完模擬才知道，這其實是這整套系統最核心的問題。如果沒有一套破同分規則，這場比賽有極高的機率，會用一句「並列」草草結束——五位評審熬夜認真評分的心血，最後被同一個分數，埋在一起。
我把椅子往後推了一點，重新看著那張表格。這不是我可以隨便寫死一句話就交代過去的地方了。
破同分規則：三層比較
有了這兩個數字，破同分規則就不再是憑感覺硬湊的邏輯，而是有明確目標要解決的設計。
我又坐回螢幕前，開始想：加權總分算出來的那個平均值，到底漏掉了什麼？
漏掉的，是「有沒有評審真心覺得這張照片很突出」這件事。一張被多位評審打了 9、10 分的照片，跟一張所有評審都給 7 分、平均起來剛好一樣的照片，理應不是同一個等級——但加權平均會把它們看成完全相同的東西。
於是規則就這樣定下來了。當兩張照片的加權總分完全相同時，系統依序比較：
- ≥9 分評審人數——哪張照片拿到比較多評審給出的高度肯定，由多到少排。
- 如果還是相同，再比單一評審給過的最高分，由高到低排。
要三個條件都完全一致，才會真正並列名次。寫完這段邏輯，重新跑一次模擬——同分機率終於從 96%、100% 這種嚇人的數字，掉回一個合理的範圍。破同分規則，其實是在把加權平均分數看不見的訊號，重新找回來。
三天，系統上線
從第一次落筆寫規格書，到系統實際部署上線，前後大概三天。五個角色的權限隔離、匿名性、破同分規則，每一項都經不起「先求有再求好」，值得花這三天，把規格跟邏輯都想清楚。
部署到既有的 VPS 上那天，我其實做好了心理準備，以為會跟主機上原本就在跑的網站打一場架。結果比想像中順利——核心程式先跑起來，只綁在本機的連接埠上，等網域生效了才接上反向代理跟 HTTPS，中間沒有動到任何一個原本就在運作的站台。
系統正式上線那天晚上，我打開後台，看著評分一筆一筆即時跳出來——五位評審各自在自己的畫面裡，看不到彼此，也看不到投稿者是誰，安安靜靜地替 52 張照片打著分數。而在那些分數背後，有一組規則正安靜地等著：一旦同分發生，就把該分出的高下，不動聲色地分出來。
我看著螢幕，沒有什麼戲劇性的瞬間，只是心裡某個地方，慢慢地、安靜地放鬆下來——那是一種把一開始只是直覺懷疑的問題，真的算出數字、找到答案的踏實感。
