前言

「單獨看每個字眼都很技術性、很通用，怎麼會被抓出識別風險？」

這正是最容易被人工複查漏掉的一種情況——不是某個字眼本身敏感，而是好幾個各自看起來無害的技術細節湊在一起，組合出的訊息量足以讓業內人士反查到具體情境。這篇要講一個真實發生過的案例：幾個單獨看都合理的技術描述，湊在一起被指出有識別風險。

今日目標

• 理解「組合風險」跟「單一敏感字眼」是兩種不同性質的識別資訊
• 看到一個具體案例：哪些各自無害的描述，湊在一起變成有風險的組合
• 學會在寫作時，除了檢查單一句子，也要檢查同一篇（甚至同一系列）裡多處描述湊在一起會不會洩漏太多
• 理解為什麼這類風險特別容易被人工複查放過

案例：技術細節的組合比單一細節更容易洩漏

CLAUDE.md 的寫作規範裡提到一個具體教訓：某些技術細節（無框架的 PHP 系統、多年期系統、上億筆歷史資料）單獨看都只是技術背景描述，不涉及廠商名稱、不涉及產業類型，但這幾項細節加上原本考慮要寫的業務術語（例如描述系統功能時用到的業界慣用詞）湊在一起，對業內人士來說已經足以縮小到能對應到具體的系統類型。

這種風險之所以容易被人工複查放過，是因為複查時通常是逐句、逐段檢查「這一句有沒有問題」，很少刻意退一步看「整篇文章（或整個系列）湊起來透露了多少訊息量」。單獨檢查每一句都會得到「沒問題」的結論，但訊息量是會疊加的——問題不在任何一句，而在整體。

• ❌ 只逐句檢查有沒有敏感字眼：確認每一句話裡都沒有廠商名稱、沒有真實路徑，就認為這篇文章去識別化完成
• ✅ 額外檢查整體訊息量會不會疊加：逐句檢查之後，再退一步通讀整篇，問自己「如果我是業內人士，看完這幾個技術細節的組合，能不能大致猜出這是哪一類系統」，如果答案是能，就需要把其中幾項細節換成更泛化的描述，降低組合起來的可識別度

組合風險的解法不是刪掉某一個細節，而是確保保留下來的細節，湊在一起時整體訊息量仍然夠模糊，不會比單一細節的風險總和更高。

今日思考題

回想你寫過的內容，有沒有某幾個各自看起來無害的細節，如果讀者把它們放在一起看，可能會拼湊出比你以為的更多訊息？

今日重點回顧

• 組合風險跟單一敏感字眼是兩種不同性質的識別資訊，前者更容易被逐句檢查的複查方式放過
• 技術細節本身通用，但跟業務術語或其他細節湊在一起，訊息量會疊加超過任何單一細節
• 逐句檢查之後，還要退一步通讀整體，檢查訊息量疊加後會不會透露太多
• 解法是確保保留的細節組合起來仍然夠模糊，不是刪掉某一個細節就了事

明日預告

Day 16 是第二部的收尾：品質守門機制的維護成本——規則越加越多之後，怎麼確保它們不會互相打架。

寫在最後

第一次意識到組合風險存在，是發現規則清單裡有專門針對「業務術語跟其他技術細節同時出現」的樣式——這種規則寫法本身就在提醒我，去識別化不能只逐句想，還要有人願意退一步看整體。