論述基礎與限制

本卡從一個 API 設計模組連續八輪審查裡反覆出現的同一種 finding 抽出。三次的形狀相同、分屬不同批內容、由不同 frame 的 reviewer 各自抓到。

第一次在一篇版本策略的文章上。標題與承重論點是「識別碼指向什麼決定誰付遷移成本」，而對抗性審查找得到直接反例——URI 版本配上服務端轉換層，成本結構就長得像日期釘選；日期釘選配上逐版本凍結部署，就長得像 URI 版本。同一個識別碼形式可以對應相反的成本分配，所以識別碼不是決定變數。真正在做功的是消費者不動作時被解讀成什麼（沉默算維持舊約還是算同意跟上），而那句話已經寫在文章中段的案例段落裡，只是沒有讓它承重。

第二次在一篇觀測章的分層軸上。軸名是「做決定的維度全量、查問題的維度抽樣」，而它跟同章第一節直接矛盾——第一節的表把某個維度列為「決定所需」，第四節把同一個維度歸為「查問題可抽樣」。正確的機制寫在下一段的括號裡：抽樣毀掉「有沒有人」、保留「大致的形狀」。改名成存在性問題與形狀問題之後，「同一個維度在不同時候落在不同一側」變成這條分界最實用的性質，而原本要單獨處理的例外自動消失。

第三次在同一批的另一章。動工順序的第一步叫「per-consumer 用量觀測」，而這個複合名詞蓋住了兩件成本差一個量級的工作：埋計數是當天可開工的加法，補「金鑰對得上組織」的歸屬層在既有系統上多半補不回來。兩者因為共用一個名字而繼承了同一個成本評價，於是「第一步可以立刻開工」這個判斷對其中一半是錯的。而成本差異在同批的另一章裡已經寫清楚了。

限制：本卡談的是已經想清楚機制、而在替它命名時選了較弱的詞的情形。機制本身沒想清楚是另一回事，那種情況下把括號裡的話升格成軸名不會有幫助，因為括號裡也沒有東西。

核心原則

判準失真最常見的來源不是機制想錯，是替機制取名字時選了一個相關但較弱的代理變數。 三個實例的共同結構是：正確的機制在文字裡存在，位置在括號、在下一句的理由、或在別節的說明裡；而承載判準的那個名字——標題、軸名、步驟名——用的是它的代理。

代理之所以會被選中，是因為它在多數情況下與機制同向，而且更好講。識別碼形式跟預設行為多半連動、「做決定」聽起來比「存在性問題」具體、「per-consumer 觀測」比「計數加歸屬層」順口。代理與機制分岔的那些情況正是判準要處理的難題，於是判準在最需要它的地方失效。

這件事對讀者的傷害比對作者大。作者知道括號裡那句才是重點，讀者拿走的是名字——他會用那個名字去分類自己的情境、去跟同事討論、去建自己的檢查表，而那些用途全部繼承代理的失真。

為什麼一般審查抓不到

字句層審查看不到它：名字通順、沒有廢話、沒有負向起手。結構層審查也看不到：H2 是結論句、表格每列都有延伸段、段落順序合理。事實層更看不到：機制的描述是對的。

抓得到它的只有兩種 frame。對抗性審查會去找反例，而代理與機制分岔的地方正是反例的所在——這也是為什麼三個實例裡有兩個是 steelman 抓到的。個案實跑會發現照名字走跟照機制走得到不同答案，因為讀者只拿得到名字。

自己看不見的原因是作者同時持有兩者。讀到軸名時腦中補的是機制，所以怎麼讀都對。

修法：把括號裡那句升格成軸名

三個實例的修法一律相同：找出那個真正在做功的句子，讓它當名字，原本的代理降級成入口或例子。

降級之後代理常常仍然值得留著，因為它是讀者的入口——識別碼是讀者看得見的東西、「做決定」是他關心的事。做法是在開場交代兩者的關係：讀者的入口是這個，要盯住的是那個。這比直接刪掉代理好，因為代理承擔了可搜尋性與第一眼的辨識。

複合名詞蓋住不同性質的那一種（第三個實例）修法略有不同：拆名字，讓兩件事各自有名字與各自的成本評價，而不是找一個更好的合稱。

判讀徵兆

  • 正確的說法出現在括號、破折號之後、或「因為……」的理由子句裡，而標題或軸名用的是另一個詞。這是最直接的訊號，掃自己的稿件時把括號內容單獨讀一遍，看有沒有哪一句比它所在段落的名字更準。
  • 同一份內容的兩處把同一個東西歸到軸的兩側。這通常表示軸名允許兩種讀法，而機制不會。
  • 套到具體個案時分不開。抽象讀都對、拿三個真實情境走一遍卻得到「這兩個看起來都算」，多半是名字比機制粗。
  • 一個名詞底下的東西成本差一個量級。複合名詞的訊號是它的組成部分可以分開執行、分開排期、分開失敗。
  • 對抗性審查的反例集中在同一處。反例都指向「這個名字宣稱的因果其實由別的東西決定」時，反例本身就在指出真正的機制。

跟其他原則的關係