實務指南

適合：

• 議題是開放的——「我們該往哪走」而不是「A 或 B 二選一」。
• 你想知道意見的分布：有幾種立場？各自在意什麼？哪裡其實有共識？
• 參與者彼此有基本信任（社群、班級、社區、組織內部、工作坊）。
• 會前意見蒐集：把爭點先攤開，開會直接談分歧。

不適合：

• 需要具名發言或正式表決的場合（這裡一切匿名）。
• 高對抗、有灌票誘因的公共爭議（請用官方 pol.is 或有身分驗證的工具）。
• 只有兩三個人的小組（直接談就好；4 人以上才會分群）。

題目訂成一個開放式問題，例如「我們的社區接下來兩年最該投資什麼？」。避免是非題。

種子意見是討論開場時就存在的 8–15 句話，參與者一進來就有東西可投。要領：

• 一句一個想法——「應該增設腳踏車道，也要加強路燈」要拆成兩句。
• 可以被同意或不同意——寫成立場句，不要寫問句或事實句。
• 涵蓋不同立場——刻意放進你不同意、但社群裡確實有人持有的看法；地圖要照出全部光譜。
• 放幾句你猜大家都會同意的——共識也需要被「看見」，這些句子會出現在共識清單。
• 口語、具體、280 字內。「改善溝通」太空泛；「重要決定應該提前一週公告」可以投。

範例（社區題）：「社區的公共空間應該優先給兒童活動使用」「管理費可以調漲，前提是帳目每月公開」「線上會議的參與品質不輸實體會議」⋯⋯

• 新意見直接公開：信任圈內建議開著，討論才有活水；公開連結、或議題敏感時關掉，改由你逐句核准（手機就能按）。
• 開放參與者提意見：這是 Polis 方法的靈魂，盡量開著。只有在純粹「測試既定選項」時才關。
• 公開資料下載：學術、公民科技場合建議開，任何人都能驗證你的結論；組織內部討論通常關。

• 4 人起會開始分群（每人要投滿門檻票數：意見少於 7 句時要全投，7 句以上投 7 句）。
• 20 人以上地圖趨於穩定；50 人以上代表性意見與共識清單開始可靠。
• 現場工作坊抓 10–20 分鐘投票（20–40 句意見）；線上非同步跑 3–7 天，中途提醒一次。
• 系統設計上支撐到數百至上千人、數百句意見。

1. 開場 3 分鐘：說明匿名（見下方話術）、示範投一句、強調「略過」是正當選項。
2. 投票 10–20 分鐘：把參與連結變成 QR code 投影（任何 QR 產生器貼上連結即可）。鼓勵大家投完後丟出自己的意見——新意見會優先出現在別人的投票序列裡。
3. 你同時開著管理頁：核准新意見（若開了審核）、順手把明顯重複的下架。
4. 一起讀地圖 10 分鐘：投影結果頁。先讀跨群共識（「原來這些我們都同意」），再讀各群代表意見（「我們的分歧到底在哪」）。不要急著辯論，先讓大家看見結構。
5. 接到下一步：把共識句變成行動清單；把最大的分歧句變成下一輪深談的題目。

「這個工具是匿名的：不用註冊、不留姓名 email，系統只在你的瀏覽器裡放一個隨機代號，避免同一個人重複計票。你投的每一票只會變成統計；結果頁上的每個點看得出『有一個人在這裡』，但看不出是誰。你提出的意見會公開顯示，但不會標示是誰寫的。」

想像把每個人的全部投票排成一列。投票模式越像的兩個人，就被放得越近；整體攤開成一張二維地圖後，系統自動把「靠在一起的人」圈成群（會自動嘗試 2 到 5 群，選分得最乾淨的那種）。

每一群的「代表性意見」是：這群人的投法和其他群差異最大、而且差異大到不是巧合（有統計檢定把關）的句子。「跨群共識」則是每一群都傾向同意的句子——只要有一群不買單，就上不了共識清單。

這套方法重新實作自 Polis 的公開文獻，並用官方公開的真實對話資料驗證過（分群結果與官方高度一致）。想看數學細節：演算法說明、驗證報告。

• 討論結束時到管理頁關閉投票（結果頁保持可看），下載兩個 CSV 留檔。
• 寫總結時的順序：參與規模 → 共識清單 → 群的樣貌與代表意見 → 下一步。共識放最前面——這是這個方法最有價值的產出。
• 把共識句直接變成提案或行動項；把分歧最深的句子帶進下一場（審議式）討論。

• 匿名代號存在瀏覽器裡：換裝置＝新身分。擋得住誤按、擋不住刻意灌票。
• 意見地圖呈現「投票行為的結構」，不是民調的代表性樣本——參加的人不等於母體。
• 分群是演算法的整理，不是標籤。讀地圖時談「這一群的投法」，不要談「這一群是什麼人」。