# 動態討論視覺化：讓口頭討論可以及時轉成 polis 意見的工具

## 緣起：
- 本專案的工具討論源自於 2026 年 1 月 28 日的每週小松討論：
- [20250128小松](/kPBOQnhPS6OazYaNUnKtkg)
- 延續相關的討論，決定與 AI 協作，撰寫成一個可以用於開發引導的共筆。

## 專案內容
### Project Vision
- 在面對面審議或實體討論中，「誰拿著麥克風，誰就擁有話語權」。但在許多文化脈絡（包含台灣本地的實踐），沈默不代表沒有意見，而是沒有適合的表達介面。本專案嘗試解決「講話者的獨裁」問題，打造一個工具，讓 實體討論現場的聲音，可以即時轉化為可被所有人投票、分群與收斂的意見結構，並與 Polis 式的審議流程無縫銜接。目標不是取代討論，而是讓沈默多數也能在不打斷討論的前提下，實質參與共識形成。
### Core Problems We Address
- 沈默多數的結構性失語
- 不想／不敢講話
- 不擅長即席表述
- 害怕佔用公共時間
- 現場討論與數位審議工具的斷裂
- Polis 多在「討論之後」才使用
- 無法即時反映現場脈絡與情緒
- 意見過多、難以快速收斂
- 討論時間有限
- 主持人難以即時判斷「該先談哪個分歧」
### 流程 overview
#### Phase 1：從「聲音」到「可投票的意見」
在有人發言的同時，讓其他參與者可以用手機「低干擾地」參與。
流程包含：
- 語音輸入
- 即時擷取現場發言（麥克風 / Line-in / Web audio）
- 語音辨識（ASR）
- 將發言轉成逐字稿
- 意見抽取與整理
- 將長句、敘事轉為 Polis-style statements
- 一句一個可判斷立場的陳述
- 即時投票介面
- 同意 / 不同意
- 加上「優先級」評分投票（例如 1~3 分 或 1~5 分）
- 參與者不需要發言，只需用手機投票或標記優先順序。
#### Phase 2：意見分群與收斂輔助
在第一階段累積投票資料後，系統提供即時輔助分析：
- 共識度計算：哪些意見共識度高 vs 哪些共識度低意見分歧
- 優先級排序：計算得分，哪些議題被認為「優先級較高」vs「優先級較低」
- 找出「高優先級 × 低共識」的關鍵張力點，優先討論
- 分群（Polis-like clustering）
- 將立場相近的參與者與意見分群
- 分群摘要（Summarization）
- 各群體在意的是什麼
- 分歧背後的價值差異
這些結果可即時回饋給主持人，作為下一輪討論該聚焦哪裡的依據。
### Expected Use Cases
- 實體審議工作坊
- 公民論壇 / 市民大會
- 混合式（Hybrid）會議
- 時間有限、但需要共識形成的討論場景
### Design Principles
- 低干擾：不打斷正在進行的討論
- 即時性：不是會後整理，而是「當下可用」
- 輔助而非主導：工具不替人做決定
- 以 Polis 精神為核心：找共識、而非比人氣

## 開發方向（技術／產品層）
1️⃣ 系統模組拆解（非常重要）
- **Audio & Transcription Layer**
Audio input（現場）
ASR（Whisper / API / local model）
Speaker segmentation（可先不做）
- **Statement Extraction Layer**
從逐字稿切出「可投票陳述」
約束：
一句一個主張
避免複合句
這一層是成敗關鍵之一
- **Voting Interface**
Mobile-first
投票類型：
同意 / 不同意
優先級（數值）
- **Aggregation & Analysis**
共識度計算
優先級加權
Polis-style clustering（可先簡化）
- **Facilitator Dashboard**
即時看到：
高優先 × 低共識
值得拉回討論的 statements

2️⃣ MVP 切法（務實建議）
如果一開始就想「即時 + AI + 分群 + Polis」，會死。
最小可行版本（MVP 1）應該是：
人工 or 半自動把發言轉成 statements
手機即時投票（同意 / 不同意 + 優先級）
簡單排序，不做分群
先證明：
這樣做，主持人真的比較好帶討論

3️⃣ 目前還不足、但「一定要補」的地方
我會直接列「缺口清單」。
- **你還沒定義「誰是主要使用者」**
至少要選一個主角：
主持人？
參與者？
記錄者？
現在 README 是「大家都很重要」，但產品一定要偏心。
- **Statement 的品質控制機制不清楚**
這是最大風險點：
誰決定一句話能不能變成 statement？
AI 自動？人審？
錯誤或偏誤怎麼修？
如果 statement 爛，後面全部都爛。
「不影響討論」還是停留在願望層次
你提出了很好的問題，但還沒回答：
手機亮起來會不會反而分心？
投票時機怎麼控制？
主持人要不要 cue？
這需要一個流程設計（facilitation flow），不是只有工具。
- **與 Polis 的關係還模糊**
現在是三種可能混在一起：
Polis-like（自己重做）
Polis bridge（資料送進 Polis）
Polis-inspired analysis
這個要早點選，不然技術路線會亂。

## 可參考資料

- 2020年論文 [CommunityClick: Capturing and Reporting CommunityFeedback from Town Halls to
Improve Inclusivity](https://dl.acm.org/doi/abs/10.1145/3432912) 分享by社群夥伴 Tzu-Sheng Kuo