投票系統怎麼做到公正？計票規則、防灌票機制與開發選型判斷

作者｜瞻新資訊　張安邦執行長（台大醫工背景・十年以上IT服務公司創辦人）

多數人想到「投票系統」，腦中畫面通常是一個按鈕、一個統計圖表。但真正讓一場投票站得住腳的，往往不是介面做得好不好看，而是計票規則有沒有先講清楚、同一個人能不能重複投票、結果被質疑時拿不拿得出紀錄。這篇文章從系統開發的角度，把投票系統該想清楚的事拆開來講。

投票系統要解決的問題，其實不是「按一按」

假設你要辦一場員工滿意度調查裡的「最想要的員工福利」票選，或是協會理監事改選前的內部提案表決，第一個念頭通常是「找個工具讓大家投票」。但真正決定這場投票成不成立的，是投票結束之後那句話：「這個結果，你要怎麼證明它是對的？」

這句話回答不出來，麻煩才真正開始。有人質疑同一個人投了兩次票，你拿得出紀錄嗎？有人問為什麼加權計分的方式是這樣，你解釋得清楚嗎？投票系統的核心價值，從來不是「讓人按一按」，是「規則透明、票數經得起核對」。這跟蓋一棟房子先打地基是一樣的道理：地基看不到，但房子塌不塌就靠它。

投票系統、抽獎系統、問卷系統，差在哪？

不少人搜尋「投票系統」時，心裡想的其實是票選活動或問卷調查，三者常被混著講，但決策邏輯完全不同。

系統類型	核心目的	讀者最擔心的事
投票系統	統計每個選項得到多少票，做出決策或排名	計票準不準、有沒有人重複投票
抽獎系統	從合格名單中隨機選出中獎者	名單有沒有清理乾淨、抽選過程公不公平
問卷系統	蒐集意見與數據，找出趨勢	樣本夠不夠代表性、題目設計合不合理

三者最大的差別在「結果的用途」：投票要的是一個可以拿去執行的決策（誰當選、哪個方案通過），抽獎要的是一個隨機但公平的結果，問卷要的是一份可以分析的資料。搞錯這個定位，選出來的系統功能會對不上真正的需求——用問卷工具硬做投票，計票邏輯常常不夠嚴謹；用投票系統硬做抽獎，隨機性設計反而不是它的強項。

企業內部投票，跟股東會電子投票不是同一件事

搜尋「投票系統」的時候，常常會連到「股東e票通」「股東會電子投票」這類資訊。這裡要先講清楚：企業內部投票（活動票選、內部提案表決、理監事選舉）跟上市櫃公司股東會電子投票，是兩個完全不同的合規層級，不能混為一談。

台灣集中保管結算所（TDCC）建置的「股東e票通」電子投票平台，是搭配非對稱式加密機制（PKI）的法規強制系統，證券主管機關規範自2023年起全體上市（櫃）及興櫃公司股東會強制採行電子投票，這套規格是為了保護股東的表決權而設計，牽涉的是公司治理法規。

換句話說，你不需要把內部投票系統做到跟股東會電子投票一樣的法規等級，但也不能因為「反正不是股東會」就完全不管計票規則的嚴謹度。這中間有一個合理的區間，取決於這場投票的重要性。

規劃投票系統前，先想清楚這五件事

不管最後是用現成工具還是找人客製開發，下面這五個問題想清楚了，才不會投票做到一半發現規則沒定好。

1. 計票規則怎麼設計：不是只有「選一個」這麼簡單

投票不是只有單選這一種玩法。就像球類比賽的計分方式不一樣——足球進一球算一分，跳水是裁判打分數再加權平均，賽跑看誰先抵達終點——選哪一種計票規則，會直接影響誰「贏」，這件事要在投票開始前想清楚，不是開票當下才決定。

常見的計票規則有：

• 單選：每人一票、投一個選項，最直觀、爭議也最少。
• 複選：每人可選多個選項，適合「選出前三名」這類情境。
• 加權：不同身分或條件的票，權重不一樣（例如理監事選舉可能依會員資格分級）。
• 排序投票：讓投票者對候選項目排序，用排序結果決定名次，適合候選項目多、想避免「贏者僅拿三成票」爭議的情境。

國外還有一種比較進階的設計叫「平方投票法」（Quadratic Voting），最早由經濟學者Eric Posner與E. Glen Weyl在法學期刊《Vanderbilt Law Review》發表的論文中系統性提出。簡單說，傳統投票像每人手上只有固定張數的選票，只能整張投給一個選項；平方投票法則是給每人一筆「聲量預算」，可以分散投給不同選項，但同一個選項投得越多，邊際成本越高（投兩票要付四點、投三票要付九點）。這種設計是為了讓「非常在意某件事」的人能把偏好強度表達出來，而不是每個人的一票看起來都一樣重。這不是要企業內部投票都去導入這套機制（它源自學術界對民主機制設計的研究，實務導入需要額外的規則說明成本），而是說明計票規則本身就是一門可以講究的學問，不是系統裡勾一個選項就結束了。

2. 身分驗證要多嚴，看的是「投票結果重不重要」

驗證強度不是越高越好，是要跟這場投票的重要性成正比。活動人氣票選，用手機號碼或社群帳號登入通常就夠；內部提案表決會影響資源分配，可能就需要綁定企業內部帳號或員工編號；理監事選舉這類牽涉會員權益的投票，通常需要更嚴謹的實名制與資格核對。

驗證強度大致可以分三級：

• 輕度：手機號或Email驗證，適合低風險、參與人數多的活動票選。
• 中度：綁定既有帳號系統（會員帳號、LINE官方帳號、企業內部帳號），適合需要追蹤誰投了什麼的情境。
• 高度：搭配一次性密碼（OTP）簡訊驗證，或串接企業SSO（單一登入），適合結果會影響資源分配、需要事後可追溯個人投票紀錄的情境。

3. 防灌票機制要疊加，不能只靠一道關卡

防止灌票沒有單一的萬靈解法，通常是好幾層機制疊在一起用，任何一種手法單獨用都有繞過的空間。這個原則不只是台灣的工具廠商在講，美國網路安全暨基礎設施安全署（CISA）在討論選舉系統安全時，也強調要用「多層防護」搭配「持續稽核」，而不是依賴單一防線——這是通用的資安工程原則，跟是不是選舉系統無關，企業內部投票系統一樣適用這個思路。

常見的防灌票機制疊加方式：

• 帳號登入制（同一帳號限投一次）
• 相同IP的重複投票限制
• 裝置或瀏覽器指紋比對
• 投票時段限制
• 圖形驗證碼或人機驗證
• 手機號碼綁定（一號一票）

常見誤解：不少人以為「裝了圖形驗證碼」或「用了知名的現成工具」就等於防灌票做完了，這是兩個常見的誤解。圖形驗證碼只能擋掉自動化程式灌票，擋不住真人手動用不同裝置重複投票；現成工具的防護等級也不是統一的，有沒有IP限制、裝置指紋、時段限制，要看方案等級，不是「用了付費工具就自動安全」。另一個誤解是「即時開票畫面看起來很專業，代表這場投票很公正」——這其實跟公正與否是兩回事，詳見下一節。

4. 開票是即時公布，還是要能事後回查？

多數投票工具都會強調「即時開票、統計圖表自動產生」，這確實方便，但公正不是靠一個即時跳動的數字，而是靠「這份結果能不能被回查」。就像考試改完卷之後，學校能不能調出「哪一份考卷改了幾分、誰改的、什麼時候改的」，這份紀錄的存在本身就是公信力的來源。

投票系統如果只丟出一個最終數字，遇到爭議時很難說服人。美國國家標準暨技術研究院（NIST）在討論投票系統安全時，把「事件紀錄」（event log）列為關鍵設計要素，強調系統應該記錄重要操作的軌跡、並定期檢查是否有異常——這同樣是選舉等級的稽核概念，但「保留可回溯的操作軌跡」這個原則，企業內部系統一樣用得上。比較嚴謹的投票系統做法會保留：

• 每一票投票的時間戳記（不需要對外公開投票內容，但系統要保存得住）
• 計票規則的版本紀錄（規則有沒有中途被改過）
• 異常票數的排除紀錄與排除理由
• 管理端操作紀錄（誰在什麼時候調整過設定、有沒有人動過票數）

即時開票跟事後可回查不衝突，可以做到「前台即時顯示、後台完整保存原始紀錄」，兩者並存。真正要避免的是「開票之後資料就消失、沒人能回頭核對」。投票系統若只保留最終加總數字，沒有保留逐票的事件紀錄，遇到爭議時很難證明結果沒有被竄改——這一點不管是幾十人的部門表決，還是上千人的活動票選，道理是一樣的。

5. 個資只蒐集用得到的，不要順手多要

投票系統為了驗證身分，常會蒐集姓名、手機、Email、會員帳號這類個人資料。依《個人資料保護法》，蒐集個資應該告知蒐集目的與使用方式，並且以完成投票所必要的欄位為原則，不是「順便多蒐集一點以後可能用得到」。這一點跟前面〈抽獎系統怎麼選〉一文提到的個資處理原則是同一套邏輯，只是套用在投票情境上：驗證身分需要的資料就蒐集，不需要的欄位不要放進表單。涉及後續行銷利用或跨活動保存個資的情況，建議再取得法律專業意見。

一個常見情境：內部提案表決

有些企業會遇到這樣的狀況：部門提了三個年度提案，需要全體員工投票決定優先順序，但過去都是用一份Google表單，結果送出後才發現有人重複填了兩次、有人是用共用帳號登入所以分不清楚是誰投的。等到要跟主管報告結果時，除了一個總票數，什麼都拿不出來。

這種情境通常代表：帳號驗證強度不夠（沒有綁定員工身分）、防灌票機制沒有疊加（沒有限制重複填寫）、結果不可回查（沒有保存逐票紀錄）。三個問題疊在一起，投票結果的可信度就會被質疑，即使規則設計本身沒有問題，也很難說服人。這種情況通常不是工具不好用，是投票開始前的規則沒有先想清楚。

現成工具，還是客製開發？

想清楚上面五件事之後，接下來要決定：買現成工具，還是找人客製開發。這個選擇有點像用現成的樂高積木組裝模型，跟自己開一副模具做零件——樂高積木組合快、成本低、彈性有限；自己開模具前期投入大、要花時間，但可以完全貼合你要的形狀。

比較項目	現成工具	客製開發
部署速度	快，通常當天可用	需要開發時程
整合需求	彈性有限，較難串接內部系統	可依需求串接會員系統、LINE Bot、企業SSO
計票規則彈性	多為標準選項（單選/複選/排序）	可自訂特殊加權邏輯或跟內部治理規則綁定
資料主權	資料存放在第三方平台	資料留在企業自己的環境
成本結構	訂閱制、依用量計費	一次性開發成本＋後續維護
適合情境	規則單純、一次性的活動票選	需要長期使用、規則特殊或需要整合內部系統

規則單純、參與人數可控、不需要跟內部系統整合的活動票選，現成工具通常就夠用；但如果你需要跟會員系統、LINE官方帳號或企業內部帳號整合，或是計票規則有特殊邏輯（例如加權表決要對應內部職級），這時候客製開發才划得來。

至於客製開發要花多少時間，很難給一個固定數字，因為差異主要來自「要不要整合既有系統」跟「計票規則複雜度」——單純的投票功能開發時程通常比要串接會員系統、權限管理的完整方案短上不少，實際規劃還是要看需求範圍才能估算。這個「先問需求再決定要不要客製」的判斷順序，跟〈預約系統怎麼選〉一文的邏輯是同一套；若最後決定要客製，接下來要面對的是找誰做、怎麼判斷廠商可不可靠，這部分可以參考〈系統整合商是什麼〉整理的判斷標準。

張安邦的開發者觀點：計票規則設計時最容易被忽略的事

我在規劃這類系統時，很少把「開票畫面好不好看」放在優先順位。真正容易被忽略、卻最影響公信力的，是兩件事：計票規則要不要允許事後修改，以及逐票紀錄怎麼保存查核。

規則中途被改，是投票爭議最常見的起點。假設一開始說好單選，投票進行到一半發現票數集中在某個選項，臨時改成複選——不管出發點是什麼，只要規則被動過，結果的公信力就會被打折扣。規則一旦公告，就不該再改；真的需要調整，也應該重新開始一輪投票，而不是在原本的結果上修修改改。

這一點延伸到系統設計上，還有一層更根本的問題：就算系統技術上「做得到」讓管理者事後調整票數或修改規則，也不代表應該把這個權限開放出來。權限設計本身就是公信力的一部分——一套讓任何人都改不動已公告規則與已產生票數的系統，遠比一套「理論上管理者可以改但承諾不會改」的系統更值得信任，因為公信力最怕的就是「要不要相信某個人的承諾」這種模糊地帶。

逐票紀錄的保存也是同樣道理。很多系統只保存最終加總的數字，這在規則單純、沒有爭議的情況下沒問題，但一旦有人質疑，你需要的是能回頭查「這一票是什麼時候投的、有沒有異常」的能力，不是重新再投一次。先把規則想清楚、紀錄留得住，再選工具，通常比先買一套投票模組再回頭補規則更省事。若後續需要把投票流程接進官網或既有系統，也可以先確認官網的承接動線是否順暢，延伸閱讀〈官網架設完整指南〉。

常見問題