多人協作房間

v2.7.0 新增

多人協作房間把標註從一個人的活兒變成即時的共享會議。一組標註者同時處理同一個條目，其中的社交動態被測量下來，而不只是被允許發生。不需要 LLM，不需要外部服務，也沒有新依賴。

三種房間類型：

為什麼要用 Norming 房間

標註團隊本來就會開螢幕共享的標準對齊會，而結論最後只留在某個人的筆記裡。房間把這場會議變成工具的一部分，並給它裝上儀表。

• 先盲投。 揭曉之前，成員只看得到誰投了票，看不到投了什麼。這一點由服務端強制，所以第一印象是真正獨立的。
• 揭曉本身就是一次測量。 盲投票一經揭曉便不可更改。揭曉後的每一次改票都會被記錄：從什麼改成什麼，以及當時的多數意見是什麼，由此得到每個成員的從眾記錄。
• α 儀表回答“這場會值不值”。 Krippendorff's α 會在已揭曉的條目上算兩次：一次基於盲投票，一次基於當前投票。兩者之差就是這場會帶來的對齊增益，會議進行中就顯示在螢幕上。

配置

rooms:
  enabled: true
  who_can_create: any      # "any" logged-in user, or "admin" only
  persist_votes: true      # final votes write into members' annotation state
  poll_interval_ms: 1500   # client sync cadence (500–30000)
  max_members: 12          # per room (2–100)
  schema: sarcasm          # optional; defaults to the first radio/likert scheme

房間只對一個單選方案（radio 或 likert）投票。如果沒有設定 schema，就用 annotation_schemes 裡的第一個這類方案。

開一場會

1. 啟動伺服器，登入，開啟 /rooms。
2. 建立房間（選類型和條目數）。房間會拿到一個六字母房間碼，比如 MKT4QP。房間碼避開了容易混淆的字形，方便口頭念出來。
3. 其他人從大廳列表加入，或者直接開啟 /rooms/<CODE>。
4. 投票，主持人揭曉，在側邊聊天區討論，被說服就改票，然後主持人推進到下一條。最後一條結束後房間關閉並給出會議總結，主持人可以下載完整的事件日誌。

Huddle

建立時選擇 Huddle，房間會裝入該房間所用方案下標註者當前存在分歧的所有條目，最多 200 條。原始標註顯示在投票面板上方作為上下文。分歧是從標註狀態即時算出來的，所以不需要啟用裁定子系統。

Shadow 會話

在 shadow 房間裡，除主持人外所有人都以觀察者身份加入。觀察者不能投票，但能看到主持人的投票、揭曉和文本選區，延遲約 1.5 秒。主持人當前的選區會在觀察者螢幕上以琥珀色高亮。

持久化與崩潰恢復

每個房間都是事件溯源的。每次變更（加入、投票、揭曉、改票、發訊息、推進、關閉）都會向下面的檔案追加一行 JSON：

<output_annotation_dir>/rooms/room-<CODE>.jsonl

房間狀態完全由該日誌重放得到，因此進行中的房間能挺過伺服器重啟。這份日誌同時也是會議的審計軌跡：盲投票、時間戳、討論內容，以及揭曉後每一次改票及其當時的多數意見。GET /rooms/api/<CODE>/export（主持人或管理員）以 JSON 返回日誌加上計算出的指標。

設為 persist_votes: true（預設）時，主持人推進條目時會把每個成員在已揭曉條目上的最終投票寫入其常規標註狀態。房間裡的工作算作真實標註，並進入所有現有的匯出路徑。

客戶端通過帶游標輪詢 /events 來同步。這裡沒有用 WebSockets，因此房間在多執行緒開發伺服器和任何 WSGI 部署下都能工作。

API 一覽

延伸閱讀

• 心理測量學引擎 —— 每個標註者的能力和條目難度；它標出的標註手冊問題，正是在房間裡修好的
• 裁定與分歧處理 —— huddle 的非同步對應物
• 撰寫標註指南
• 原始碼文件