教材用中性陳述、不對讀者喊話
論述基礎與限制
本卡的論述基於 1 個 case（HOF / typedef 可讀性文章的 review、一次抓到 3 種對讀者喊話的形式）抽出來的觀察。具體限制：
- 三 sub-case 是 starting set、不是窮舉：安撫 / 第二人稱 / 祈使是這次出現過的、不代表「對讀者喊話的完整形式庫」。新形式（反問句「想想看為什麼？」、預告「接下來你會看到」）出現時要持續擴充。
- 「中性 vs 親近」是情境化取捨、不是 zero-sum：本卡聚焦「判斷工具型 / 概念建立段」的喊話；hook / 引言 / narrative 段落的輕度第二人稱反而幫讀者進入論述、不適用本卡。
- 修補有效性未獨立驗證：改成中性陳述後讀起來更聚焦、但「register 跟讀者實際理解之間的相關性」沒做使用者測試。
讀者使用本卡時、先判斷段落是否屬於「概念建立 / 判斷工具型」——是 → 套用；否（hook / narrative）→ 評估親近感跟中性的取捨。
核心原則
教材的責任是把概念講清楚、不是管理讀者的情緒或閱讀節奏。 對讀者喊話的句子讀起來親近、但承載的是「對話 stance」而非概念內容 —— 把讀者當成要被安撫、被代入、被指揮的對象，多出來的是資訊負擔、拖慢進入正題。
下面三種形式是觀察到的 pattern —— 不是窮舉、實際形式可能更多：
| 對讀者喊話的形式 | 具體案例 | 喊話的 stance | 中性改法 |
|---|---|---|---|
| 安撫情緒 / 訴諸群體 | 「很多人卡在…」「大家都會搞混…」 | 讓讀者覺得「不是只有自己不會」 | 直接講概念：「這個簽章的關鍵是分清 X」 |
| 第二人稱代入 | 「你天天寫的 int count」「你天天在用 map」 | 把讀者拉進句子當主詞 | 中性指稱：「常見的 int count」 |
| 祈使控制閱讀 | 「先讀懂這個簽章」「先釐清 X」「別搞混」 | 指揮讀者的閱讀順序 / 動作 | 描述性名詞標題：「簽章的型別與名字拆解」 |
關鍵是這三種精度都沒問題 —— 「你天天寫的 int count」指涉完全正確、「先讀懂這個簽章」語意清楚。違反不在用詞精度、在 register/stance：教材該是「陳述概念」、喊話是「對讀者說話」。
三種形式的具體 case
形式 1：安撫情緒 / 訴諸群體
喊話版：「很多人卡在『這串到底哪裡是型別、哪裡是名字』。」
問題：「很多人」沒有資訊量 —— 讀者不會因為「別人也卡」而更懂型別跟名字怎麼分。它的功能是情緒安撫（你不孤單）、不是概念傳遞。教材的價值在講清楚概念、讀者的情緒不是它的責任。
中性版：「這個簽章的關鍵是分清『哪裡是型別、哪裡是名字』。」
差別：中性版第一句就是概念聚焦（要分清什麼）、喊話版前半句純安撫、讀者要跳過它才到正題。
形式 2：第二人稱代入
喊話版：「順序跟你天天寫的 int count、Color color 一樣」
問題：「你天天寫的」把讀者拉進句子當主詞、預設讀者的日常（萬一讀者沒天天寫 Dart？）。它想營造親近感、但概念（int count 是 型別 名字 順序）不依賴「誰寫的」。
中性版：「順序跟常見的 int count、Color color 一樣」
差別：中性版用「常見的」指涉同一組例子、不預設讀者身分、概念一樣到位。
形式 3：祈使控制閱讀
喊話版：小節標題「先讀懂這個簽章的每個部分」、「先釐清：什麼是 X」
問題：「先讀懂 / 先釐清」是對讀者下閱讀指令、控制節奏。標題的責任是標示這段在講什麼（讓讀者自己決定讀不讀）、不是指揮讀者「先做什麼」。
中性版：描述性名詞標題「簽章的型別與名字拆解」、「什麼是『函式型別裸寫在簽章』」
差別：名詞標題讓讀者掃目錄就知道內容、祈使標題把目錄變成指令清單。
沒這樣做的麻煩
資訊負擔累積、稀釋概念密度
每句喊話都是「非概念」的字 —— 安撫、代入、指令本身不傳遞知識。教材裡散佈喊話、讀者要持續過濾「這句給資訊還是在跟我說話」、概念密度被稀釋。
預設讀者身分、對不上就失效
「你天天寫的」「很多人卡在」都預設了讀者的背景 / 經驗 / 困難。對不上的讀者（沒天天寫、第一次就懂）會感到突兀、甚至被排除 —— 跟 AGENTS 原則六「讀者定位用內容體現、不貼標籤」同源的失效。
Keyword bank 抓不到、靠語意 pass
第二人稱（你 會誤命中 code 註解）跟祈使（句式發散、無固定詞）沒有穩定關鍵詞、grep keyword bank 結構上抓不到 —— 這類問題只能靠 reader-simulation 語意 pass（「這句在給資訊、還是在指揮 / 安撫讀者？」）。正是 #149 講的 coverage gap。
跟其他抽象層原則的關係
- #111 口語化修辭會稀釋技術精度：兩卡是字句層的 sibling、但軸不同。#111 是「精度」軸（用詞能不能反推機制 / 條件 / 契約）；本卡是「register/stance」軸（陳述概念 vs 對讀者說話）。「你天天寫的
int count」精度完全正確、卻是錯 register —— #111 抓不到、要本卡。兩卡共享同一個情境邊界：hook / narrative 段落都放寬。 - #149 keyword bank 命中是候選、不是判決：本卡是 #149 的 content 對偶。#149 是 review-process（偵測≠判定、怎麼審）、本卡是 content 原則（prose 該怎麼寫）。#149 把「安撫贅語」當 coverage-gap 的舉例、本卡把它確立成 content 原則。產生情境不同：#149 源於 reviewer 誤判 grep 命中、本卡源於寫作當下 prose 對讀者喊話。
- #114 Multi-pass review 的 frame 顆粒度盲點：本卡的三形式裡、第二人稱跟祈使沒有固定關鍵詞、是 #114 keyword bank 機制的已知盲區 —— 補強的是 #114 的 reader-simulation 機制（換視角）、不是 keyword bank（換工具）。
- AGENTS 原則六（讀者定位用內容體現）：兩者相鄰但機制不同。原則六禁「貼標籤」（叫讀者『新手 / 新人』）、本卡禁「稱呼 / 指揮」（你 / 先讀懂）。可以不貼標籤卻仍在喊話（「你天天寫的」沒叫讀者新手、仍是第二人稱代入）—— 本卡補原則六沒覆蓋的 stance 維度。
判讀徵兆
| 徵兆 | 該做的行動 |
|---|---|
| 段落 / 標題出現「很多人 / 大家 / 不少開發者」 | 訴諸群體安撫 —— 刪、改成概念聚焦句 |
| 概念建立段出現「你 / 你的 / 你會 / 你天天」 | 第二人稱代入 —— 改中性指稱（常見的 / 一般而言） |
| 標題或開場是「先讀懂 / 先釐清 / 別搞混 / 記住」 | 祈使控制閱讀 —— 改描述性名詞標題 |
grep 你 命中、但分不清正文還是 code 註解 | keyword bank 抓不準 —— 改 reader-simulation 語意問句 |
| 自問「這句給新概念、還是在跟讀者說話」答後者 | 對讀者喊話 —— 刪 stance、留概念 |
適用範圍與邊界
- 適用：概念建立段、判斷工具型段落、小節標題 —— 這些地方的責任是傳遞概念 / 標示內容、喊話純屬負擔。
- 不適用：hook / 引言 / narrative 開場 —— 輕度第二人稱（「假設你在維護一個…」）能幫讀者進入情境、跟 #111 的 hook 例外同理。
- 邊界：中性化 ≠ 消滅所有「你」。判別線是「這句在傳遞概念 / 標示內容、還是在管理讀者（安撫情緒 / 代入身分 / 指揮閱讀）」—— 後者才刪。protocol 型文件（操作步驟、checklist）的祈使是合理 stance、不適用本卡。
Self-case：本卡的觸發來源
本卡觸發於 review 為什麼這個場景適合用高階函式 時、由讀者連續指出三種對讀者喊話：
- 安撫：「很多人卡在『哪裡是型別、哪裡是名字』」—— 訴諸群體、讓讀者覺得不孤單。
- 第二人稱：「順序跟你天天寫的
int count一樣」「你天天在用 map」—— 把讀者拉進句子。 - 祈使：小節標題「先讀懂這個簽章的每個部分」「先釐清：什麼是 X」—— 指揮閱讀順序。
三者在 grep keyword bank 的表現不一（安撫有部分關鍵詞「很多人」、第二人稱跟祈使幾乎無固定詞）、但共享同一個違反 —— 教材在對讀者喊話、而非中性陳述概念。修法統一：安撫句刪、第二人稱改中性指稱、祈使標題改描述性名詞標題。
對應本卡：對讀者喊話是獨立於精度（#111）跟 review-process（#149）的 content register 議題 —— 一個句子可以精度完全正確、grep 完全乾淨、卻因為 stance 錯（在跟讀者說話）而不該留在教材裡。