結論

教學章引用 case 時、帶進來的敘事要收斂到論證需要的最小結構：對比結構與機制留下；事件帳目（票數、案例數、版本號）、規模鋪陳（「版本收尾上百張票」）、產品身分與領域功能詞（「書籍管理 App」「書庫」）留在 work-log。修法階梯是「先刪、刪不動才泛化」：逐句問「拿掉後論證還成立嗎」、成立就刪；論證需要一個具象載體才泛化成無身分形態（「一個專案」「存在至少一筆資料」）。

本卡的邊界

本卡管的是引用既有 case 記錄時該剝離什麼，不是禁止教學章出現敘事。章節自己寫的無身分短敘事——沒有公司名、沒有年份、沒有數字帳目，只保留失敗過程與它為什麼沒被及時發現——不在本卡範圍：它沒有第二住址問題（不對應任何一份 case 記錄、也就無從漂移），也沒有映射成本問題（本來就是無身分的、讀者不需要翻譯）。

把本卡讀成「章節不該有敘事」是過度推論，而且實測發生過：一輪教材補寫因此只補了分類語言（系統形態、觸發事件），漏掉讀者真正需要的「出事會長什麼樣」，直到提需求的人用原本的詞再問一次才發現。無身分敘事的寫法與四拍結構見 #242。

為什麼

兩個 surface 的讀者契約不同。work-log 是事件記錄、它的價值正是具體性——版本號、票數、錯誤字串原文讓事件可回溯、可被搜尋直達。教學章是判準層、它的價值是可轉移性——讀者要把論證映射到自己的專案；case 專屬敘事每多一分、映射成本多一分（讀者要先翻譯「書庫」對應自己系統的什麼）。

教學章搬運 case 敘事還有第二個代價：帳目有了第二個住址。work-log 是事件事實的單一來源、教學章複述數字之後、事件記錄修正時教學章靜默漂移——與工程值的 SSoT 失效同構。

規模鋪陳的隱蔽性在於它「感覺在幫論證」：「上百張票收尾全綠」讀起來像在加強反差。實際上反差來自對比結構本身（單元測試全數通過 vs 實機找出斷裂）、與數字大小無關——一張票的專案發生同樣的事、論證同樣成立。作者與同源 reviewer 共享「保留一點規模感」的直覺、所以這類搬運會通過字句層與案例準確性審查——數字是準確的、只是不該在這裡。

修法階梯

逐句對教學章的 case 引用問三問：

1. 這句是論證的對比項、還是事件鋪陳？ 鋪陳（背景、規模、收尾狀態）直接刪。
2. 刪掉後論證還成立嗎？ 成立就刪定；不成立代表論證需要載體、泛化成無身分形態——「一個專案」「一筆資料」「一個入口」。泛化有下限：全部代詞化會讓論證懸空、讀者無法想像場景、具象載體要留。
3. 讀者需要細節時去哪找？ 教學章留 case 連結、細節單一住址在 work-log。

反模式

跟其他抽象層原則的關係

• #242 形態讓讀者對號入座，微案例才讓他想像得出後果：本卡的互補面。本卡說明教學章不能搬進來什麼（帳目、身分、規模鋪陳），#242 說明要用什麼填（無身分的四拍短敘事）。只讀本卡會得出「章節不該有敘事」這個過度推論，兩張合起來才是完整的教學層敘事規則。

Case

ddd「組裝層的可達性」章多輪審查（2026-07-13）。Round 1 reviewer 抓到教學章搬運「113 張票」「十三個案例、修復前十一個確定性紅燈」、判為 case 帳目搬運；修法選了通用化（「上百張票」）。使用者兩次指正把階梯補完：第一次指出「版本收尾上百張票」的前情提要整句該刪——對比結構（單元測試全數通過 vs 實機找出五個問題）自足；第二次指出「一個書籍管理 App」的產品身分該收斂為「一個專案」、領域詞（「書庫中存在至少一本書」「空書庫」）泛化為（「存在至少一筆資料」「資料為空」）。

三步的訊號：reviewer 能偵測帳目搬運、但修法停在通用化——「保留規模感幫論證」是作者與同源 reviewer 共享的直覺、要用「刪掉後論證還成立嗎」的機械測試取代直覺判斷。

判讀徵兆