「錯的來源不只一種，而輸出都不帶訊號」主詞與謂語都在，語法完整，照 #358 的四個槽位（動作者、動詞、受詞、結果）查下來全部通過。它缺的成分在名詞裡：「來源」是什麼的來源、「輸出」是誰的輸出、「訊號」是什麼的訊號；「錯」是形容詞被當成名詞用，連什麼錯了都沒說。

有一批名詞本身要求一個補足語——來源、輸出、結果、原因、代價、差別、位置、範圍、邊界、訊號、層、線、情形。它們的所屬是句子的一格，跟受詞一樣要寫出來：寫在這一句，或寫在緊接的前一句。形容詞與動詞不直接當名詞用。判斷問句是：這個名詞是誰的、什麼的，能不能從這一句或前一句逐字指出來。

失效的形態

一篇 SQL 教材的段標與收尾段：

錯的來源不只一種，而輸出都不帶訊號

結果集由什麼決定，到這一篇有了完整的答案：那個語意模型、它與直覺相反的那幾處，以及模型學對了仍然會錯的這一層。判一段查詢合不合法的是某一家引擎，而各家的線不同——那條線本身在 1.19；線以外還有識別字、權限、最佳化器、約束與 collation 各自決定一部分結果。

段標裡的四個名詞都沒有所屬。收尾段多一層：「結果集由什麼決定」是分類目錄頁把各篇分成三個問題時用的名稱，而目錄頁的正文在網站上不顯示——讀者讀到「有了完整的答案」時，不知道問題是什麼。「那條線」「線以外」是同一種形態：線是什麼的界線，要回到本篇開頭第二段才找得到。

改寫後：

答案錯掉的成因不只一種，而引擎一種都不會報錯

收尾段改成直接交代查詢文字以外還有哪幾件事決定結果、各由誰決定，逐項連到負責那件事的那一篇。

為什麼操作句的槽位規則沒擋住

同一類問題 2026-09-22 剛處理過（#355 形態二、#358），處置寫成「操作句先填四個槽位再成句」，審查端在探針問題裡加「這個動作是誰做的」一欄。兩頭的範圍都是描述操作的句子。 論斷句、總結句、段標、過渡句沒有動作者，規則不觸發；就算觸發，主詞與謂語都在，四格全部通過。

缺陷的定義是「讀者無法從這一句還原完整的命題」，規則卻被寫成它最常見的那個句型。#302 記過同一種失效方向相反的版本（規則的觸發條件比判斷標準先生效，於是規則被套到不該套的地方）；這一次是觸發條件比缺陷窄，規則在它沒寫到的句型上從不生效。

這一類集中在作者做抽象與收束的位置：段標、段落的第一句與最後一句、總結段、過渡句。作者寫到這些位置時手上有整篇內容，「輸出」「那條線」對他都是完整的指涉——跟 #365 的審查者持有全文地圖是同一個成因，這一次發生在寫的人身上。

偵測：量過的四種做法

一組二十句的校準集，已知違規與已知合規各十句，打亂、不標示；正例取自那篇 SQL 教材改寫前的段標與收尾段，以及 #358 的原例。每種探針各派三份 Haiku，指令逐字相同。

關係名詞清單（腳本）。 列出來源、輸出、代價這一批名詞，在它前面沒有「的」或修飾語時標記。命中已知違規的一半、已知合規的七成。合規句的所屬常寫在前一句（「連接後的關係多了一列。原因是配對是逐列做的」），清單分不出來。它只能告訴判讀者該看哪裡。

要探針把句子改寫完整，缺的成分標成【？】。 沒有鑑別力：違規句平均標出 2.5 個缺項、合規句 2.7 個，二十句沒有一句被任何一份判為無缺項。只給兩句話時，它把「共用資料的範圍」這類本來不必寫出來的成分也全標成缺項——跟 #365 裡探針自動補完的方向相反，是過度標記。

要探針從兩句裡逐字引出每個名詞的所屬，引不出就寫引不出。 三份裡至少兩份判「有引不出」的，名詞缺所屬這一類的違規抓到八之七，操作句那一類三之一，合規句被標出九之三（多是邊界情形：「位置」是什麼的位置、「輸出的列集合」是哪一段查詢的輸出）。三種句子層做法裡唯一有鑑別力的，而有效的理由是任務從生成換成抽取：列出缺什麼可以無限展開，指出一段逐字存在的文字要嘛做得到、要嘛做不到。

目錄頁詞彙外漏（腳本）。 取同目錄 _index.md 的段標片語，找文章正文裡出現的那些，略過文章自己的段標、連結文字與三篇以上共用的模板段名。改寫前的收尾段被抓到；全站教學分類命中四十四處，其中兩處是文章把讀者指到目錄頁的某一段（「模組入口的『判定問題的答案要留下痕跡』那一節」「書單的『四個主題排在三層上』段」），而那兩段在網站上看不到。

校準集裡有一句標成合規的，是主 session 剛改寫 1.13 時寫的「回來的那批列本身也看不出錯」——逐字引出的探針判它引不出「錯」的所屬，判對了。改寫的人剛修完這一類，下一句就寫出同一類。

修法

  • 生成端規格擴大到每一句：槽位多一格「名詞的所屬」，寫到段標、段落首末句、總結段、過渡句時逐句問判斷問句。規則住在 compositional-writing 的〈每一句先填槽位再成句〉。
  • 審查端：對那些位置派逐字引出所屬的探針，至少兩份判「引不出」的列為候選，由主 session 逐條判讀。操作句那一類仍歸四槽位的冷讀與「這個動作是誰做的」探針欄。
  • 目錄頁詞彙外漏：scripts/index-leak-check.py --all，命中逐條判讀。

全分類掃過一次之後：篩選這一步重演了同一個錯

逐字引出所屬的探針在 SQL 分類 24 篇、1150 個目標句上跑完，至少兩份判引不出的 541 句交給篩選者對照全文判定。篩選這一步出了四種問題，每一種都在稿件以外的地方：

規則寫進了預期比例。 第一版篩選規則有一句「不改是多數——探針只看兩句，大部分標記是誤報」，並要篩選者先讀全文。第一組 88 個候選只判 2 個要改，把已知的兩處真違規判成不改（「每一步手上有什麼」被說成「手上明確掛在每一步上」）。那一句就是 #365 刪掉的「寧可少報」，寫規則的人剛寫完那張卡，下一份指令又寫了一次；讀全文則讓篩選者重新拿到作者的地圖。第二版刪掉比例、判定時先只看兩句、每一條不改附逐字依據，同一批候選判出必改 26、建議改 36。

篩選者自己發明豁免。 第二版的不改依據裡反覆出現「下一句就展開」「段標由下文說明」——規則沒有這一條。依這兩類依據與泛稱名詞（形態、缺口、段、方向）挑出九十多項重讀，又改出 11 處，其中多數是段標：「方向常常相反：拆開讓最佳化器多知道一件事」「差別在於誰會讓列數變多」，段標是承載結論的位置，把結論交給下文正是違規。

替換文字會補錯事實。 一條替換把「同樣的列集合」寫成「跟開頭那個例子相同的四列」，而實際比的是鏈尾換成 RIGHT 的那段查詢（一列）。篩選者要寫出所屬就得決定所屬是什麼，決定錯了，改稿就把一個錯誤寫進文章。替換文字裡新增的每一個事實要回原文核對。

同一篇的判定在實例之間差很多。 一位篩選者把工作分給幾個子實例，同一篇文章的必改數從 0 到 7。單一實例的判定不能直接套用，主 session 的抽查是必要步驟。

另有一個形態只有在全分類掃過才看得到：被標出的譬喻是全分類的用詞。「手上」在這個分類裡指「這一步的中間結果」，出現三十多次，連段標與 description 都用它；逐句修只改掉被標出的那一句，同一個概念就有了兩個名字。譬喻被判定之後，先數它在分類裡出現幾次，再決定整批換成什麼。

同一輪另一個工具的缺口：CLAUDE.md 裡掃「連到目錄頁錨點」的指令只比對單層路徑，多層路徑的七處全數漏掉；改成 scripts/index-leak-check.py --anchors。

論述基礎與限制

校準集二十句，每種探針三份。樣本小，量到的是這幾種做法在這批句子上的相對鑑別力，不是漏報率；正例與反例的標籤由主 session 判定，至少錯了一句（「回來的那批列本身也看不出錯」那一句）。逐字引出的探針還沒在整篇文章上跑過，整篇的候選量與判讀成本未知。

跟其他抽象層原則的關係

判讀徵兆

  • 句子的主詞與謂語都在，而讀者問得出「誰的」「什麼的」。
  • 段標、總結句、段落首末句裡出現「輸出」「來源」「代價」「那條線」這類名詞，而前一句沒有交代它屬於誰。
  • 文章用一個讀者沒見過的框架名稱（「結果集由什麼決定」）當成已知，而那個名稱只在目錄頁出現。

Case

2026-09-24，SQL 教材分類。使用者指出 SQL.13 的收尾段「語氣不通順、主詞跟受詞都用得不明確」，以及段標「錯的來源不只一種，而輸出都不帶訊號」——「錯是什麼錯了？來源是指什麼？誰的輸出，哪一部分的輸出，什麼的訊號？」並指出這一類前一天已經抓過一次，仍然出現，代表辨識方法不夠，要先分析怎麼辨識再動手。