這個計畫選擇公開一般平台多半視為商業機密的審查與偵測方法，但公開不代表所有資訊一次釋出。哪些可以立即公開、哪些需要延後公開、哪些必須先去識別再分級釋出，都要依照濫用風險、個資風險與公共利益逐項判斷，不能套用單一規則。
程式碼公開後，仍需要可理解的文件
關於「公開」這件事，計畫內部一再討論的不是只有要不要公開，還包括公開後能否被理解、被檢驗、被申訴。把程式碼放到 GitHub 上，常被當成透明度的終點。但在今年（2026） g0v Summit 的討論上，我們的共識是需要進一步將程式碼背後的意義用更通俗易懂的語言來討論。一般使用者讀不懂程式碼，是因為程式碼預設讀者已經是工程師g0v Summit 2026 校正版逐字稿（草案，非現場逐字）如果只是把程式碼丟出來，其實不等於透明。因為一般使用者不一定能讀懂程式碼，也不一定知道資料怎麼來，規則怎麼被套用，模型怎麼影響結果。
。
「如果只是把程式碼丟出來，其實不等於透明……所以開源只是第一步。後面還需要文件、案例、可理解的說明、申訴管道，以及社群能夠參與的工作流程。」
本「科普」網站還可以做更多，像是把程式碼庫裡的系統狀態值、資料庫查詢規則與判定門檻，整理成一般讀者可讀、可討論、可申訴的形式。另一個問題來自使用者端。長期使用者、同時有 PTT 自治經驗的 Denken，在工作坊上指出「開放」與「共創」之間仍有距離。Matters 已經開放應用程式介面（API），也公開 spam-detection-scaffold，但仍未走到共創g0v Summit 2026 簡報文字記錄（Denken 觀察 2）開源 ≠ 社群參與；開放 API ≠ 使用者能影響治理決策。
原始連結 ↗。 應用程式介面（API） 讓其他程式可以串接、自動取用平台資料或功能的對外介面。 讓外部程式可以串接、自動取用平台資料；但能取用資料，不代表能參與決策。他親身參與多次不同社群的公開開發會議，最後常常發現「只有我」。
因此程式碼公開不等於透明，因為公開後仍可能看不懂；透明也不等於共創，因為看得懂仍不代表能影響決策。不同社群會長出不同的治理形態。對平台而言，比較可行的角色是支撐既有社群，而不是替社群預先設計治理樣貌。真正費力的工作在公開之後，讓資料、文件、案例與申訴流程持續被理解與使用。
為什麼 Matters 選擇公開程式碼
大多數平台不公開審查邏輯，偵測門檻一旦公開，攻擊者就能據此調整規避策略。但 Matters 願意承擔這項風險，原因在於中小型平台的成本效益不同。在 TWIGF 2026 工作坊中也被公開討論到：
「我們想說我們已經太小了，開源出去，feedback 已經換到更多了，再多一點點沒關係。」
對一個中小型平台來說，公開程式碼可能換到社群信任與外部回饋，也會增加被繞過的風險。Matters 的判斷是，前者對它更重要。同一件事放到超大型平台，結論可能不同，因為公開偵測細節等於把規避方法交給大量攻擊者；放在小平台上，公開則可能換來原本缺乏的檢視與協作。這項判斷取決於平台規模、攻擊壓力與社群資源，不能直接套用成所有平台都適合的規則。
程式碼公開，敏感參數延後揭露
選擇公開程式碼不等於全部公開。真正落地的折衷是分層揭露。治理流程與程式碼可立即公開、可檢驗；但可能被直接濫用的敏感參數，例如垃圾內容判定門檻、帳號群聚規則、門檻掃描細節，則延遲六到十二個月才釋出，或先做抽象化處理。
這道分層有工程根據。判定門檻 spamThreshold 存在功能開關資料表（feature_flag），並透過 Redis 快取生效，調整門檻不必重新部署。也就是說，它本身就是一項可即時調動的營運設定，公開它幾乎等於公開了繞過規則的攻略。我們認為：理論上一切都該公開，現實上門檻一旦公開，攻擊者就能調整輸入避開偵測《自由與管制的天平》簡報（東吳法律研究所分享, 2026-05-26）折衷：分層開源——程式碼公開，但敏感參數延遲發布 6–12 個月。
。
「一個永續的抗審查平台，如果要犧牲透明度來換安全，不如一開始就不要太多個人資訊，這樣就可以做到只揭露流程與打詐公式。」
這句結論說明了分層揭露的核心取捨。它和守望相助隊「處置行為全公開」形成對照。同一個平台，在處置行為上追求高度透明，方便問責；在偵測參數上卻必須延遲揭露，以降低被規避的風險。哪些該即時透明、哪些該延後，不只是技術問題，也是治理判斷。研究報告也因此全程用【內部】標記，把這道分層落實於文件。
尚未發布的資料集如何設計
公開程式碼之後，下一步是資料公開。matters-spam-dataset 是一個研究資料集，目標是把平台累積的垃圾內容標註語料去識別後對外發布matters-spam-dataset README原始連結 ↗。不過目前尚在調整內容，尚未正式發布。目前還在確認服務條款是否允許再散布與衍生使用、法務複核資料說明卡與資料使用協議。歡迎來信討論垃圾資料集的釋出方法matters-spam-dataset README（分階段路線圖）P0 平台授權 ✅ / ToS 再散布條款核對 + 法務複核 DUA ⬜ 待法務
原始連結 ↗。所以下文描述的是一套已設計、已寫成程式碼，但尚未對外發布的方法。
規模與授權
首發版本 v2026.06 以文章為主，留言與動態規劃以增量釋出。規模與標籤分佈來自程式碼庫中的資料說明卡與發布清單（站方自述，未經第三方獨立驗證）。
授權依產出與來源分流，不能用單一條款概括。資料整體採 CC BY-NC-ND 4.0 相容授權，並受資料使用協議（DUA）約束；但單筆樣本因為承襲原始內容授權，可能是 CC0、CC BY-NC-ND 2.0 或 CC BY-NC-ND 4.0。v2026.06 因此只收 CC／CC0 來源，並排除保留所有權利的內容（ARR，也就是作者沒有釋出再利用授權的內容）。發布清單記錄為此移除了 436 筆原本會被舊政策放行的 ARR 垃圾內容。程式碼採 MIT 授權，資料採 CC BY-NC-ND 4.0，兩套授權刻意分開matters-spam-dataset LICENSE / DATACARD資料：CC BY-NC-ND 4.0 相容授權；單筆來源含 CC0、CC BY-NC-ND 2.0、CC BY-NC-ND 4.0，且須遵守 DUA
原始連結 ↗。發布通道則分成兩種。大量下載與重現用 Hugging Face 上的限申請取用資料集，使用者需同意資料使用協議，並用 git 標籤標示版本；查詢增量與回貢標註則使用自建介面。兩種需求不同，所以分開處理。
公開去識別 ≠ 內部去識別
這份資料集對政策與開發社群都可能有參考價值，原因在於它把「內部用」與「對外公開」當成兩種不同的去識別等級。內部的訓練語料只雜湊 id、保留原文，因為原文裡的 LINE ID、電話、錢包地址、返佣連結，既是個資，也是最強的 spam 訊號。公開版必須在「保留 spam 結構訊號」與「不外洩真人聯絡方式」之間取得平衡，做法分成三層。
① 重新產生公開識別碼（不可反推）：原始 user／comment／article id 會用一把獨立的 release_salt 重新做一次 HMAC 雜湊（ HMAC 雜湊（HMAC） 把身分資訊轉成不可還原代碼的加密方法，用來去識別、保護個資。 ，演算法為 HMAC-SHA256），取前 16 個十六進位字元作為公開 id。這把 salt 刻意不同於營運用的 HASH_SALT，且發布後即封存或銷毀，確保即使拿到公開資料，也無法反推回平台內部 id。公開 id 使用獨立 salt，發布後封存，是「公開 id 不可反推內部 id」的關鍵設計matters-spam-dataset schema/dataset_schema.json（id 欄位）= HMAC-SHA256(release_salt, 內部 comment_hash/article_hash) 取前 16 hex。release_salt 與營運 HASH_SALT 不同且不隨資料公開，發佈後即封存，確保無法反推平台內部 id。
原始連結 ↗。原因在於我們仍然擔心，即使是整理過的 Spam 資料集，也有被誤判的可能性。
② 聯絡方式改成佔位符：文本裡的聯絡方式會被換成帶有類型的佔位符，包括 <PHONE>、<EMAIL>、<LINE_ID>、<WECHAT>、<TELEGRAM>、<QQ>、<WALLET>、<URL>、<MENTION>、<NUM>。網址只保留網域，去掉路徑與查詢參數，避免返佣碼與追蹤碼夾帶個資。佔位符讓模型仍能學到「這裡有一個 LINE 帳號在招攬」的結構，卻不外洩真實帳號。
③ 時間資訊粗化：時間只保留到「年-月」桶（created_bucket），不提供精確時間戳，降低靠時間反推個案的風險。
去識別流程的程式碼註解裡，有不少瑣碎但關鍵的細節，足以說明去識別不是跑一條正則表示式就結束。聯絡方式換成佔位符後，後面常殘留「<LINE_ID>:abc888」這種真實帳號，所以要再收尾兩遍，把緊跟佔位符的帳號字串一併移除。錢包地址、QQ 號、被空白拆開的網址（https:// example.com）也都各自有專門規則。這些細節說明，去識別品質取決於邊界案例怎麼處理，而不只取決於主規則本身。
標籤結構與可信度分層
資料集並沒有把每一個標籤都當成同等可靠。每筆樣本除了二元標籤 spam／ham，還帶研究用的垃圾類別欄位 spam_category、標籤來源欄位 label_source，以及建議訓練權重 label_weight。權重沿用內部 2.0／1.0／0.5 的慣例。來源可信度被明白排序：管理員逐篇判定（admin_set_spam）與人工矯正（human_relabel）權重 2.0，被推翻的處置（reversed_moderation／restored_content）代表「這其實是正常內容」，是很強的修正訊號；純模型輔助（model_assisted）權重最低，資料卡也明文要求下游不要把它當成絕對正解。
還有一個容易被忽略卻很關鍵的設計。測試集切分後就固定不動。資料切分以 id 雜湊穩定分流，測試集一經發布就不再變動，作為協作評測的固定裁判集，避免不同貢獻者各自挑資料衝高成績，也避免測試集外洩。對一個邀請外部貢獻標註、共同訓練的資料集來說，這是維持評測公正性的基礎。
誠實揭露殘餘誤標
早期部分正樣本來自一種代理判斷：「作者被限制 → 名下全部內容標 spam」。儘管機率很低，但這仍然有可能會誤掃合法的政治評論、學術與創作長文，尤其是華語長文。資料集已用人工加上 大型語言模型（LLM） 像 ChatGPT、Claude 這類能讀寫、理解語言的大型 AI 模型。 協助判讀，矯正約 5,000 筆，之後會預計進行全量掃描。
資料卡把代理標籤的已知噪音寫進「組成」一節，並用標籤來源與訓練權重提供可信度分層matters-spam-dataset DATACARD（已知標籤噪音）本資料集已用人工+LLM-judge 矯正 4,980 筆（human_relabel），其中 2,649 筆由 spam 改回 ham，但未矯正部分仍可能殘留華語長文誤標。
原始連結 ↗。被改回正常內容的樣本，是降低誤刪的重要反例。它教模型辨認「看起來像曾被處置，其實是正常內容」的案例。資料卡同時標出盲點：高變化模板與跨帳號廣告集團（ 垃圾集團（Ring） 同一個人或團隊操作、用相同版型大量洗版的一群帳號；原始碼裡稱為 Ring。 ）在純文本層偵測不足。把「我們哪裡還會錯」寫進對外文件，本身就是透明度的一部分。
用法邊界：開放，但不是無條件
資料使用協議寫明禁止用途：禁止任何形式的反識別（不得還原、推測樣本對應的真實作者或聯絡對象，不得與其他資料交叉比對達成反識別）、禁止商業用途（受 CC BY-NC-ND 4.0 與 DUA 雙重約束）、禁止用於騷擾或起底、禁止用來訓練生成垃圾內容或規避偵測的工具。Hugging Face 端設計成需申請取用，下載前要填用途、勾選同意 DUA。並且保留 PDPA 下的移除請求機制：當事人可要求複審或下架；資料集發布移除紀錄後，使用者須在下次同步時刪除對應樣本，不得保留原文。一份去識別資料集的「開放」程度，最後取決於這些邊界條件，而不只是筆數。
分層揭露的原則
透明需要逐項設計揭露方式，不能理解成一次性的全量公開。程式碼可以立即公開，敏感參數可以延後揭露，資料則要先去識別再分級釋出。公開之後，還要持續把資料、文件、案例與申訴流程整理成可讀、可討論、可參與的形式。分層揭露要回答的是「安全與透明能不能兼得」這個問題。做法是逐項排序、逐層設計，並把每一個公開或延後公開的決定留下可被檢驗的理由。