論述基礎與限制

本卡從一篇觀測設計章節被對抗性審查推翻的核心成本論證抽出。

那一章要處理的問題是：對外 API 要能回答「還有誰在用這個欄位」，而消費者乘上欄位是乘積，維度會爆。章節據此發展出一整套設計——把問題分成存在性與形狀兩類、存在性不能抽樣（抽樣會讓長尾消失，而長尾正是退場風險所在）、因此不長期維持全量觀測、改用「決定要退場時才開一段全量取樣窗口」的做法，並附上窗口長度怎麼定、窗口太短的事後訊號、以及成本反轉的交叉點。

這條推導每一步都成立，而它整個是多餘的。審查指出：存在性問題不需要時間序列。一張「消費者、欄位、最後看到的時間」的表、每次請求 upsert 一次就答完了——列數是活躍組合數而非時間點數、原地更新、沒有保留階梯，成本比同一份資訊做成 metrics 低一到兩個量級，而且可以永遠開著。取樣窗口那一整套是為了繞開一個成本問題，而那個成本問題是「用 metrics 實作」這個假設造出來的。

章節從頭到尾沒有提過 metrics 這個選擇。它不是被論證後選定的，是預設的——寫的人在觀測這個語境下自動想到時間序列，於是後面所有推導都在那個容器裡進行。

限制：本卡談的是推導正確而前提未被辨識的情形。前提被辨識過、討論過、然後選定的不算，那是正常的設計取捨。

核心原則

一套判準可以建立在正確的軸上，而它底下有一個實作前提從未被當成選擇。 前提不是論點，因此它躲得過所有針對論點的檢驗：對抗性審查找論點的反例、事實審查查論點的來源、斷言審查問論點的支撐——三者都預設了「要被檢驗的東西已經被說出來」。沒說出來的那個不在檢驗的射程裡。

它的可辨識訊號是費力。推導每一步都對，結論卻需要一整套機制去繞開某個困難；而那個困難在換一種實作形態之後不存在。費力本身不是缺陷（真實的取捨常常費力），但它值得一次追問：這個困難是問題本身的性質，還是我選的容器帶進來的。

這跟「承重論點沒被驗證」是不同的失效。那裡缺的是對一個已經說出口的主張做檢驗；這裡缺的是把一個沒說出口的選擇變成可檢驗的東西。前者的修法是驗證，後者的修法是先讓它顯形。

為什麼專業經驗反而讓它更難被看見

熟悉一個領域的人在該領域的語境下會自動選定實作形態，而自動的那一步不會留下決策的痕跡。觀測想到 metrics、狀態想到資料庫、非同步想到佇列、設定想到環境變數——這些聯想多數時候是對的，而正因為多數時候對，它們不會被拿出來檢查。

反過來說，對該領域不熟的人會在這一步停下來問「這要存在哪裡」，而那個問題正是把前提顯形的動作。這解釋了一個常見現象：外行的第一個問題有時會擊中內行的盲點，而它擊中的不是知識缺口，是被自動化掉的那個選擇。

修法：把前提寫進正文，讓它跟判準並列

修法不是換掉那個前提——原本的選擇可能仍然正確。修法是把它從隱含變成明示，讓讀者知道判準的適用範圍。

那一章的實際改法是在分層之前加一句：分界有兩層，第一層是實作形態。存在性問題用一張最後出現時間的表答完，形狀問題才需要時間序列與直方圖。取樣窗口從「標準做法」降級成「這張表建不起來、而問題又是前瞻型時的退路」，並補上它的適用前提（該維度本來就在發射）。

這個改法的副產物是章節變短、判準變硬：原本要花整節處理的成本兩難消失了，而剩下的分界（存在性與形狀）因為不必再兼顧成本，變成純粹的語意分界。前提顯形之後，為了繞開它而長出來的結構會自己脫落。

判讀徵兆

  • 推導成立而結論費力。每一步都對、結論卻是一整套機制，且那套機制的存在理由是「否則會很貴／很慢／很難維護」。困難的來源值得單獨查一次。
  • 一個實作名詞從頭到尾沒有出現過，而全篇都在它的約束下推導。掃自己的稿件時問：這篇假設東西存在哪裡、用什麼形式存、誰來查詢它——這幾個問題答得出來但文中沒寫，就是前提未顯形。
  • 判準有一個需要單獨處理的例外。例外常常是前提在特定情況下不成立的痕跡；把前提換掉之後，例外會併回主線。前述案例的「欄位退場要用取樣窗口」正是這種例外。
  • 成本論證用了一個沒有換算過的量級。「乘積會爆」這類說法若沒有標明它在哪種實作下成立，多半是前提在說話而不是機制。
  • 領域內的人讀完覺得順、領域外的人第一句就問「為什麼不用某某」。後者問的通常正是那個前提。

跟其他原則的關係