入口頁的開頭屬於最外圈讀者 — 背景最少、最容易跳出的那群人、決定了分流句能放多深。分流要出現在他們還活著的位置：開頭每多一段他們看不懂的內容、活到分流點的機率就掉一截；分流句寫得再清楚、放在詞彙牆後面就等於沒寫、會被牆擋住的讀者正是分流要服務的讀者。

操作型判準：找出入口頁服務的最外圈讀者、用他的詞彙量重讀開頭 — 第一個他看不懂的術語出現之前、他需要的分流出現了嗎？

為什麼分流會自然長在牆後

入口頁通常由門內的人維護、預設讀者跟自己共享詞彙。為門外讀者補新章節時、自然的動作是「把新章節加進章節列表、在相關段落補一句路由」— 而「相關段落」的位置由內容邏輯決定（交付形態的討論屬於需求討論的前提、所以放在需求討論段前）、不是由讀者存活曲線決定。內容邏輯上正確的位置、可以在讀者旅程上完全失效：邏輯說「這段在第 41 行很合理」、旅程說「目標讀者活不過第 10 行」。

兩個座標系都對、服從的對象不同 — 入口頁的開頭屬於旅程座標系、內容深處才屬於邏輯座標系。

反模式與修法

位置的選擇可以很粗暴：入口頁前三句之內、每一種讀者都拿得到一個自己看得懂的出口。內容邏輯再怎麼支持別的位置、都排在這個約束後面。

跟其他抽象層原則的關係

• #131 教材完整性要用讀者旅程驗證：本卡是 #131 在「入口頁」這個單點的特化。#131 驗證整條旅程（從哪開始、按什麼順序、讀完能做什麼）、本卡聚焦旅程的第 0 步 — 旅程設計得再好、入口斷路就沒有人走上來。
• #139 新增頂層 content 資料夾要同步首頁入口：同屬「內容存在 ≠ 內容可達」家族。#139 處理結構性不可達（首頁清單沒列、完全找不到）、本卡處理體驗性不可達（列了、但目標讀者活不到那一行）— 後者更隱蔽、因為 link checker 與結構審查都會通過。
• #97 Metadata surface 要納入寫作 review 範圍：#97 的 navigation surface 列舉的是索引條目、MOC hook 與 link label；本卡把入口頁的開頭段視為這個 surface 的延伸 — 這是本卡的擴張、原卡分類未列 — 理由是它跟那批元素共享同一個責任：決定讀者入口、跟正文品質是兩個 review 維度。新章節寫完只 review 章節本身、入口 surface 的失效就漏掉了；本卡的 case 正是被 reader-simulation 而不是內容 review 抓到。
• #73 搜尋引擎的匹配模式跟使用者預期對齊：同型的「入口錯位 = silent 失敗」— 使用者帶著自己的模型來、系統用另一個模型回應、沒有錯誤訊息、只有流失。

觸發 case

一個後端選型模組為「還沒決定要不要自建的讀者」補了交付形態章節（託管平台 / BaaS / 自建的判讀）— 這是整個模組唯一為光譜左端讀者寫的內容。Reader-simulation 審查用人設實走：獨立開發者、剛用低程式碼工具做完接案網站、想知道該不該自建。結果：模組入口頁開頭三段全是自建世界的詞彙（consumer lag、dead-letter queue、replay）、唯一的分流句在第 41 行的「需求討論順序」標題下、章節列表中該章排在第 17 列 — reviewer 的判定是「這個讀者最可能的真實行為：開頁、前兩段每個名詞都不認識、跳出、根本走不到那一章」。修復後的入口頁在第二段就給出分流（值不值得自建、連到該章）、原本第 41 行的路由保留作第二觸點。

判讀徵兆

• 為新讀者群補了內容、commit 裡只有新章節跟列表項、入口頁開頭沒動 — 大概率長在牆後。
• 入口頁 review 用門內視角讀（「資訊都在」）— 換最外圈讀者的詞彙量重讀開頭十行、數第一個陌生術語出現的位置。
• 分流句的位置由「內容邏輯歸屬」決定而不是「讀者存活範圍」決定 — 兩個座標系打架時、開頭讓給旅程座標系。