技術文章描述的是一個系統裡多個層級之間的操作。一段說明裡同時有操作者、工具、系統元件、資料在經過，每一句的職責是讓讀者知道四件事裡的至少兩件：誰在做（操作者、工具、系統元件）、對什麼做（哪一份資料、哪一段輸出）、做了什麼（轉換、比對、寫入）、結果是什麼（輸出變什麼、狀態變什麼）。

這四件事省掉任何一件，讀者都要從上下文還原。一句兩句的還原成本可以忽略，散布在每一段時，讀者的工作記憶被還原動作佔滿，留給技術內容的空間變少。而這種省略在中文裡語法完全正確，所以所有審查——包括三輪 17 個 agent、理解探針、字句層 bank 17 個類別——全部通過。「讀得懂」作為審查標準對這一類有結構性的盲區，因為審查者做的正是讀者做的事——自動補完。

失效的形態

指令片段當主詞

「tr -d '\r' 處理的是行尾」——主詞是一個管線裡的工具片段。寫腳本的人（操作者）和 adb 回來的輸出（受詞）都消失了。讀者要自己還原：誰在跑 tr、tr 對什麼做事、為什麼要做。

改後：「腳本裡每一行 getprop 的結尾都接了 tr -d '\r'，作用是去掉輸出裡的歸位字元（\r）。」——操作者（腳本）、工具（tr）、受詞（輸出裡的 \r）、動作（去掉）全部在句內。

這個形態在指令手冊裡合理——手冊的讀者正在看這個工具的文件，主詞就是這個工具。搬到跨層的技術文章或操作指引裡，同一段涉及好幾個工具，指令片段當主詞讓讀者搞不清楚是哪一層在做事。

系統元件省略層級

「核心會對經過的位元組做終端機處理」——哪個核心？哪一層的位元組？一句話裡跳了三層（adb → pty → 作業系統核心）而每一層都沒指名。

改後：「作業系統核心的 pty 行規則會把每個 0x0A（換行）補成 0x0D 0x0A（歸位加換行）」——系統元件指名（作業系統核心）、機制指名（pty 行規則）、輸入指名（0x0A）、動作指名（補成）、輸出指名（0x0D 0x0A）。

「這裡」「在這」替代條件描述

「字串比對在這裡會靜默失敗」——「這裡」是在 pty 配置的情況下？在這一行程式碼裡？在這篇文章的這個段落？讀者要回頭找「這裡」綁定的位置。

改後：「補進來的 0x0D 肉眼看不見，但它會讓 shell 的字串比對失敗」——直接說出原因（0x0D 被補進來）和後果（shell 的比對失敗），不需要讀者去解「這裡」指的是什麼。

段落的順序由工具視角驅動而非讀者的問題序

上面三個形態合在一起時，段落的順序通常也有問題。改前的順序是工具視角：工具做什麼 → 為什麼需要它 → 後果。讀者的問題序是：這行在幹嘛（他看到腳本裡有這一行）→ 不加會怎樣（他想知道能不能省）→ 為什麼會這樣（他想理解機制）→ 副作用（他想知道加了會不會壞掉別的）。

主詞換對之後，段落順序通常自動修正。操作者視角的自然順序就是讀者的問題序——因為讀者本身就是操作者。

判讀方式

每一句問：這一句的主詞是一個人或系統元件，還是一個指令片段（參數、管線的一段、子命令）。 這是四槽位規格裡動作者那一格的檢查；受詞那一格的檢查在 #357（受詞是不是動詞在領域裡能作用的對象），兩格用同一套規格：寫操作句先填動作者、動詞、受詞、結果，槽位填不出領域內的名詞就不成句。 指令片段當主詞時，句子語法完整但四件事（誰、對什麼、做什麼、結果）至少缺了兩件。

對一整段的判讀：讀完之後問讀者「這一段涉及幾個層級？每一層各做了什麼？」——讀者答得出來代表四件事都有交代，答不出來代表某一層被省略了。

grep 抓不到這一類——缺席的主詞沒有關鍵詞。偵測靠冷讀或理解探針裡的「這個動作是誰做的」那一欄。

寫操作說明的具體做法

描述一個工具或指令要寫成好幾段時，段與段之間依讀者的疑問順序排列，讀者照段落順序讀就能理解，不需要回頭找脈絡；每一段的第一句是那一段的主題句。這是段與段之間的順序，不是每一段內部的固定結構：

1. 讀者會看到什麼——他看到腳本裡有 tr -d '\r'、他看到 file 回報 data、他看到兩列 adb devices 而手邊只有一台機器。從他眼前的畫面開始。
2. 這個東西做什麼——tr -d '\r' 去掉輸出裡的歸位字元、file 判斷檔案的類型、adb devices -l 印出在線裝置與機型。寫出工具對什麼對象做什麼、輸出是什麼。
3. 為什麼需要它或為什麼會看到這個——adb 在某些條件下會配置 pty，pty 的行規則會把換行補成歸位加換行。這一段交代機制，每個系統元件指名。
4. 不做（或做錯）的具體後果——$model 的值尾端多了一個 \r，shell 的字串比對永遠回假，而印出來看不出差別。後果要具體到讀者能對照自己遇到的症狀。
5. 副作用或適用範圍——tr -d '\r' 在沒有 pty 的情況下是空操作，加上去沒有副作用。這一段回答「加了會不會壞掉別的」。

不是每一次都要五個面向全寫。判斷看讀者讀到這裡時手上有什麼：機制在前面已經交代過時，只需要「讀者會看到什麼」與「這個東西做什麼」兩段；這個機制第一次出現時，五個面向都要寫。

跟省略主詞的差別

#355 形態二是主詞完全省略（「回答的卻是沒問的那個問題」——什麼在回答？回答了什麼？沒問的是哪個問題？）。本卡是主詞被換成指令片段（「tr -d '\r' 處理的是行尾」——語法完整，但做事的人與被做事的資料都消失了）。

差別在偵測難度：省略主詞的句子在語法上不完整，偶爾會被抓到；指令片段當主詞的句子在語法上完整，審查者讀到時覺得「主詞有了、句子完整、讀得懂」，永遠不會覺得有問題。

動作者那一格還有兩種被填上東西而仍然缺席的形態，在 #378：被動句或「由……」句只交代次要動作的動作者（「工具產生的檔案由工具改寫……處置是從統計排除」，排除的人沒有寫），以及數字、清單當「決定」的主詞（「這個數字決定哪些檔案值得回頭讀」）。那一張另外加上四格之外的時機與觸發原因兩格。

程式碼區塊不在這條標準的射程裡

本卡的判定單位是句子，所以它走到程式碼區塊就停下來——指令沒有主詞也沒有謂語，逐句填槽位的動作對它不產生任何判定。區塊裡的引數因此需要另一套檢查，在 #360：問讀者要改哪幾個位置、每個位置文章有沒有說過它填的是什麼。兩張卡的盲區成因相同（審查者自帶答案所以讀起來完整），偵測動作不同。

適用範圍

這條標準獨立於文章的定位。教學文章、操作指引、report 卡、規範文件——讀者需要的是同一件事：知道是哪一層在做事、對什麼資料做、做完變成什麼。指令片段當主詞在任何一種文體裡都會讓讀者多做一步還原。