結論

寫作規範的違規分兩類、判定性質根本不同。形式違規（emoji、編號、broken link、裸 URL、frontmatter 缺欄）可完全機械判定、命中即違規、該進工具鏈。register / 品味違規（核心概念前置、否定起手、喊話、誇飾、口語修辭）的判定有不可消除的品味核心、偵測可機械化但判定不可。

「不是 X、而是 Y」是 register 違規裡最隱蔽的一種、因為它的偵測可機械化（句型明顯、grep 抓得到）、這個「偵測可機械化」偽裝成「判定也可機械化」。被這個偽裝誤導、就會無限投入更精緻的判定方法（補 grep → 概念位置判準 → 行為測試）、而判定（這個否定在建立概念還是做對照）本質是品味判斷、始終在品味側、始終放水。

後續校正（見 #166 重點優先陳述是跨語言的資訊結構原則）：「不是 X、而是 Y」這個子集後來被釐清為資訊結構問題（重點後置）、不是純品味 —— 判定其實可操作（核心概念第一次正面出現在不在句首）、主解是強制執行重點位置判準、異源視角降為補充。本卡論的「品味核心 / 同源上限 / 異源為真防線」對喊話、誇飾這類無單一重點位置的 register 仍成立、但對「重點優先」這個可操作子集是過度推論。

為什麼 register 違規的判定不可機械化

判定要回答「這個句子讀起來對不對」、這是品味問題、品味需要一個會讀的主體去感受、沒有可機械化的判準能取代。「不是 X、而是 Y」的判定要區分兩種角色：

• 建立核心概念的否定（違規）：「外包一塊能力不是二元、而是有深度的」—— 核心概念「有深度」被擠到「而是」之後、句首先丟一個被否定的錯誤理解。
• 反例對照的否定（合規）：在明示反例段落裡、否定就是對照本體（見 #94）。

兩者 grep 命中長得一樣、語意角色相反。要判對、reviewer 得讀懂段落結構、感受核心概念的位置 —— 這是品味判斷。任何想把它機械化的嘗試都只是換個地方做品味判斷：「概念位置判準」要判斷哪句是概念句、「刪除測試」要判斷剩下的概念完不完整、終點都回到「這讀起來對不對」。偵測的可機械化掩蓋了這個事實。

同源自審的結構上限

更深一層的原因、解釋了為什麼再多輪 LLM 審查都跨不過：產出 register 違規的主體跟審查它的主體共享同一套文體直覺。「不是 X、而是 Y」是 LLM 高頻自產的定義句型、LLM reviewer 讀到它「讀起來自然、權威」、違規感不觸發 —— 作者的盲區跟 reviewer 的盲區是同一個。

這讓 register 違規的同源自審有結構上限。加 reviewer 數量、加審查輪次、換 frame、都在同一套文體直覺內打轉、跨不過盲區。要看出 register 違規、需要一雙「不共享作者文體」的眼睛。

這條上限是 #149（命中後判定會放水）跟 #147（立規範不等於自審執行）的共同根因：#147 的修法是「立規範當下轉 grep + sweep」、#149 的修法是「命中後用概念位置判定」、兩個修法都還在自動化側、對 register 違規都攔不住、因為判定的品味核心要異源的眼睛才感受得到。

理想做法

把違規先分類、再配對應的防線。

第一步：分類 —— 這個違規在哪一側

問一個判別問題：「這條規則的判定、是命中即違規（確定性）、還是要讀懂句子讀起來對不對（品味）？」確定性的進工具鏈、品味的進異源審查。emoji、編號、broken link 在確定性側；概念前置、否定起手、喊話、誇飾在品味側。

第二步：register 違規 —— 偵測機械化、判定靠異源

偵測仍用 grep、但定位是「曝光候選給異源視角抽查」、產出不是「自動判定違規」。判定交給文體異源的眼睛：

第三步：接受 100% 自動 catch 不可能

把 register 違規的審查目標設成「曝光候選 + 異源抽查」、而不是「自動判定 clean」。回報時誠實標「register 層靠異源抽查、未做窮舉自動判定」、不把同源自審的 clean 當成真 clean。

沒這樣做的麻煩

在錯的一側無限用力

把 register 違規當成自動化側問題、就會持續投入「更好的檢查方法」（補 grep、寫判準、做測試）、每次都改進一點、每次都還是放水 —— 因為判定始終在品味側。投入的努力跟結果脫節、看起來在進步、實際在原地。

同源 clean 製造虛假信心

跑完多輪 LLM 審查、回報「字句層 clean」、這個 clean 是同源盲區的產物、不是真 clean。比沒審更危險：沒審還知道沒查、同源審完誤以為查過了、register 違規帶著「已審查」標籤留在稿件裡。

規範卡越多、越以為夠了

blog 累積了 #94 / #147 / #149 一整套 register 審查原則、看起來防護很完整、反而讓人以為「照卡片做就夠」。這次的失敗證明：原則齊備、修法齊備、同源執行仍跨不過上限。原則的數量不等於防線的強度。

跟其他抽象層原則的關係

• #149 字句層 review：keyword bank 命中是候選、不是判決：#149 揭露「命中後判定會放水」這個現象、本卡是它的上層 —— 揭露放水的根因（判定在品味側、同源自審有結構上限）跟結構解（異源視角、不是更好的判定準則）。#149 的「概念位置判準」是好的判準、但它仍要同源 reviewer 執行品味判斷、本卡指出這一步有上限。
• #147 規範化跟自審是兩種認知任務：#147 講「立規範不等於自審執行」、修法是轉 grep + sweep。本卡補它沒覆蓋的：對 register 違規、grep + sweep 命中了、判定仍跨不過同源盲區。#147 解「自審有沒有做」、本卡解「自審做了、為什麼對 register 仍失效」。
• #82 字面攔截 vs 行為精修：本卡把 #82 的「字面 vs 行為」推到極限 —— 對 register 違規、連「行為精修」（讀者能不能驗證）都還是品味判斷、需要異源的讀者才感受得到。形式違規停在字面層即可、register 違規連行為層都需要異源。
• #95 Multi-pass review scope 要蓋同類風險區：#95 解 scope 軸（同類違規要 corpus-wide grep）、本卡解 source 軸（同類違規的判定要文體異源）。兩個一起才完整：grep 把候選掃出來（#95）、異源的眼睛判它違不違規（本卡）。這次三個 surface 鏡像內容共享同一違規句型、grep 掃得到、但同源判定全放行 —— scope 對了、source 沒換。
• #114 Multi-pass review 的 frame 顆粒度盲點：#114 解偵測層（展開成 keyword bank）、本卡指出對 register 違規、偵測層做好了、判定層仍需異源 —— frame 顆粒度再細、同源 reviewer 對品味違規仍有盲區。

判讀徵兆

適用範圍與邊界

• 適用：register / 品味類寫作規範（正向陳述、概念前置、喊話、誇飾、口語修辭、文體）的 review 流程設計；AI 輔助寫作的 self-review（最容易在 register 層同源放水）；multi-round-review 的 frame 與資源配置。
• 不適用：形式違規（emoji、編號、broken link、frontmatter）—— 這類確定性判定、進工具鏈即可、不需異源、本卡的「同源上限」不適用。
• 邊界：「同源自審有上限」不等於「同源自審無用」 —— 同源 reviewer 仍能抓形式違規、抓部分明顯的 register 違規；上限指的是「對 register 違規無法做到窮舉可靠」、所以要補異源、不是廢掉同源。也不等於「只能靠人」 —— 偵測機械化、對抗文體 reviewer、reader-simulation 都能降低對純人工的依賴、只是接受殘餘要異源抽查。

Self-case：本卡的觸發來源

本卡觸發於一次 backend 章節 + skill 的四輪 multi-round-review。流程是 12 個 LLM reviewer、4 輪、frame 涵蓋規範遵循 / 技術 / 一致性 / cadence / reader-simulation / title / self-application / steelman / outbound / cold-read / misuse / regression。Round 1-A 與 Round 3-A 都跑了 compositional-writing 的正向陳述 grep keyword bank、命中了三個 surface 的「不是 X、而是 Y」、全部判成「合規對照」放行、回報「字句層 clean」。

四輪結束、三個 PR 合併之後、使用者讀稿件、一眼指出「外包一塊能力不是二元、而是有深度的」是否定句型 + 概念後置違規。同一個違規在 0.22 章節、知識卡、skill principle 卡三個 surface 都存在、12 個 LLM reviewer 全漏、使用者一眼抓到。

對應本卡：register 違規的判定在品味側、12 個 LLM reviewer 共享文體直覺、同源自審跨不過盲區；使用者是文體異源的眼睛、所以一眼看到。這次失敗證明 #147 的「轉 grep + sweep」、#149 的「概念位置判定」、補 grep keyword bank —— 三個自動化側的修法疊起來、對 register 違規仍跨不過同源上限。結構解是把異源視角寫進流程、不是再疊第四個自動化側修法。