正在載入議題列表
關於這個平臺
送審之前，草稿完全不上傳伺服器。沒有人（包含管理員）看得到你正在寫什麼；代價是換裝置或清除瀏覽器資料就會遺失。
AI 先做前置過濾與重複偵測，但它不能單方面終結一筆提案。被擋下時你可以申訴轉人工複核。送審逾期未裁決會自動上報值班主管。
公開後任何同事都能匿名附議、發表正反論述、參與共識沙盤。附議一經送出即無法取消——它是一次性表態，不是可反覆切換的按讚。
附議數達到議題公開當下快照的門檻值就自動轉態，不需要人工按鈕。達門檻是單向的：之後附議數怎麼變動都不會退回，沒有人能靠等待門檻回落來規避回應。
管理者必須在 SLA 期限內做出核准／駁回／暫緩，而且每一種結果都要附具實質內容的公開理由。逾期未回應會在前台公開標記並自動上報。
核准的議題會建立公單、指定當責負責人與里程碑。對外進度由「已完成里程碑比例」自動計算，執行者無法手動填百分比。公單停滯或受阻，前台都看得到中性提示。
這些是系統確實提供的保障，且由程式結構而非流程紀律強制執行。
短時間內大量送出的請求會被限流擋下（5 分鐘窗次數上限 + 單次動作後的冷卻時間）。這對「寫一支腳本送一千筆附議」非常有效——那正是它被設計出來要擋的東西。
附議的唯一性由存在你瀏覽器裡的「議題憑證」判定，跨議題不可鏈結、不含裝置指紋或 IP 成分。憑證的生命週期涵蓋議題的整個開放期，不會因為跨日或鹽值輪替而失效。
憑證是單向 HMAC：伺服器拿到的是衍生值，無法反推出你裝置上的密鑰，也無法把不同議題的憑證關聯起來。即使資料庫外洩，也拼不出「某個人做過哪些事」。
限流判斷用的是粗粒度裝置資訊（瀏覽器大版本、語系、時區）加 IP 子網的加鹽雜湊，TTL 不到 24 小時，只存在限流快取、絕不寫入任何業務資料表。系統設計上沒有、也不會有反查機制。
這一段刻意寫得跟上一段一樣詳細。把限制藏起來短期好看，長期會反噬信任——而信任正是這個平臺的產品本身。
清除瀏覽器資料、換一台裝置、換一個網路環境，就可以對同一個議題再附議一次。限流與冷卻只能提高刷票的成本、降低規模，無法徹底杜絕。因此附議數的正確讀法是「上界估計值」，不是「精確的支持人數」。
前台完全匿名，資料庫裡不存在可以拿來核對部門的欄位。BU 月會投票的「資格」是程序性的軟限制——場次連結只在該 BU 的月會與內部管道公告，但任何取得連結的人都能投票。這是匿名架構下的殘餘限制，不是實作疏漏。
提案的認領碼（追蹤碼）只在送審那一次回傳明文，伺服器只保存雜湊值。遺失後無法尋回，管理員也無法復原——因為它刻意不與任何身分綁定。這個不方便，正是「沒有人能查出提案人是誰」的代價。
平臺刻意不提供這個查詢：要回答它，就得在你每一次瀏覽時都送出裝置憑證，憑證的暴露面會從「寫入時」擴大到「所有瀏覽」。所以按鈕的已附議狀態是由你的瀏覽器自己記住的。清除瀏覽器資料後按鈕會回到「未附議」的外觀，但再按一次伺服器仍然冪等，不會重複計數。
一條不可跨越的紅線
偵測到疑似以多裝置操弄的表態叢集時，資料仍會計入，並在共識視圖中揭露， 讓審議者自行判讀。偷偷刪掉資料等於平臺自己成為另一個黑箱。
所有下架與警告都由人工確認，被裁決者可以申訴，申訴由第二位審核者複核， 原裁決者不得自審。裁決寫入 append-only 稽核鏈，更正的方式是新增反向紀錄而非改寫。
審核了多少、依什麼理由、被推翻多少次，全部公開在審核透明報表。 治理者本身也必須被治理。
前台完全零登入
提案、附議、討論、投票、瀏覽都不需要帳號。系統沒有「前台使用者」這個概念，也沒有任何欄位可以把你的行為連回真實身分。
限流信號用完即銷毀
防止機器人灌票用的信號，是把粗粒度裝置資訊（瀏覽器大版本、語系、時區）與 IP 子網加鹽後雜湊而成，不到 24 小時就失效銷毀，只用於限流判斷。系統設計上沒有、也不會有任何反查機制。
不同用途用不同憑證，彼此不可鏈結
附議唯一性、論述按讚、共識表態各自使用存在你瀏覽器內的獨立憑證，跨議題無法互相關聯，也不含裝置指紋或 IP 成分。即使資料庫外洩，也拼不出「某個人做過哪些事」。
只要平臺承諾前台完全匿名，就無法同時做到「精確識別並封鎖每一個惡意使用者」——這兩件事在邏輯上有根本張力。 所有反濫用機制的目標是提高濫用成本、爭取告警時間、讓人工有機會介入， 而非保證杜絕。這一點我們選擇說清楚，而不是讓你以為系統萬無一失。
草稿只存在你的瀏覽器
送審之前，草稿完全不上傳伺服器、不綁定任何帳號或代碼。沒有人（包含管理員）看得到你正在寫什麼。
限制與殘餘風險：換裝置或清除瀏覽器資料就會遺失
正因為草稿不上傳，換一台電腦、清除瀏覽紀錄、或使用無痕視窗關閉後，草稿就找不回來了。重要內容請自行另存。
限制與殘餘風險：送審後會產生一次性追蹤代碼
這組代碼只會顯示一次，是你之後回來查看提案狀態、補充說明、管理訂閱的唯一憑證。遺失後無法尋回，管理員也無法復原——因為它刻意不與任何身分綁定。
只要平臺承諾前台完全匿名，就無法同時做到「精確識別並封鎖每一個惡意使用者」——這兩件事在邏輯上有根本張力。 所有反濫用機制的目標是提高濫用成本、爭取告警時間、讓人工有機會介入， 而非保證杜絕。這一點我們選擇說清楚，而不是讓你以為系統萬無一失。
附議不記錄你是誰
每則議題每個裝置憑證只會產生一筆附議紀錄。這組憑證存在你的瀏覽器裡、由你的裝置產生，跨議題無法互相關聯。
限流與冷卻是為了擋腳本，不是為了認出你
短時間內大量送出請求會被暫時擋下。判斷所用的信號不到 24 小時就銷毀，且只用於限流，不會用來查「這筆附議是誰按的」。
限制與殘餘風險：誠實說：這擋不住蓄意刷票
清除瀏覽器資料、換裝置、換網路仍然可以對同一議題再附議一次。限流與冷卻只能提高刷票成本、降低規模，無法徹底杜絕。平臺另以異常偵測、人工複核與透明報表作為第二道防線，而不是假裝已經完全防堵。
只要平臺承諾前台完全匿名，就無法同時做到「精確識別並封鎖每一個惡意使用者」——這兩件事在邏輯上有根本張力。 所有反濫用機制的目標是提高濫用成本、爭取告警時間、讓人工有機會介入， 而非保證杜絕。這一點我們選擇說清楚，而不是讓你以為系統萬無一失。
論述與按讚都不綁身分
發表論述不會記錄任何身分資訊；按讚的唯一性由存在你瀏覽器內的獨立憑證判定，與附議、投票所用的憑證彼此不可鏈結。
共識分群是統計樣態，不是個人檔案
你的同意／不同意／跳過會被用來計算群體的意見結構，但分群結果無法、也不允許被回溯到任何個人。樣本量不足時系統寧可不產生分群，也不硬跑出看似可靠的結果。
限制與殘餘風險：異常表態會被揭露而非靜默剔除
若偵測到疑似以多裝置操弄的表態叢集，資料仍會計入並在共識視圖中揭露，讓審議者自行判讀——不會偷偷刪掉資料。
只要平臺承諾前台完全匿名，就無法同時做到「精確識別並封鎖每一個惡意使用者」——這兩件事在邏輯上有根本張力。 所有反濫用機制的目標是提高濫用成本、爭取告警時間、讓人工有機會介入， 而非保證杜絕。這一點我們選擇說清楚，而不是讓你以為系統萬無一失。
不要求登入，也不儲存「誰投了什麼」
匿名投票不需要任何帳號。系統只以場次憑證做 best-effort 的軟性去重，不是票證、也不對應到人。
開放期間不顯示即時票數分布
避免從眾效應與末端衝票，投票進行中只顯示已投票數等聚合進度，完整結果在截止後才揭露。
限制與殘餘風險：投票資格是程序性軟限制，不是身分驗證
所謂「某 BU 的場次」，實際上是把場次連結只在該 BU 的月會與內部管道公告。前台不記錄部門，系統技術上無法驗證投票者身分——任何取得連結者皆可投票。也因此本結果只是諮詢性民意，不具約束力。
只要平臺承諾前台完全匿名，就無法同時做到「精確識別並封鎖每一個惡意使用者」——這兩件事在邏輯上有根本張力。 所有反濫用機制的目標是提高濫用成本、爭取告警時間、讓人工有機會介入， 而非保證杜絕。這一點我們選擇說清楚，而不是讓你以為系統萬無一失。
訂閱只綁一組本機識別碼
關注議題所用的識別碼在訂閱當下產生、存在你的瀏覽器，與限流信號和任何身分資料完全無關。預設以站內信通知，不需要留下任何聯絡方式。
Email 是自願的，且存在隔離名單
若你選擇用 Email 接收通知，該信箱只會存放在與匿名資料實體隔離的獨立通知名單，不與後台身分資料庫比對，也不提供任何「以 Email 反查誰附議」的查詢功能，並可隨時自助刪除。
限制與殘餘風險：沒有訂閱或遺失代碼就收不到通知
系統無法主動找到匿名提案者本人推播。這是匿名設計的必然限制，不是疏漏——請務必保存你的追蹤代碼。
只要平臺承諾前台完全匿名，就無法同時做到「精確識別並封鎖每一個惡意使用者」——這兩件事在邏輯上有根本張力。 所有反濫用機制的目標是提高濫用成本、爭取告警時間、讓人工有機會介入， 而非保證杜絕。這一點我們選擇說清楚，而不是讓你以為系統萬無一失。
同樣的議題與資料，也有以參與感為主軸的另一種呈現方式。
切換到遊戲化版