Readability Review 報告輸出模板
寫入
report/{article}-readreview-{YYYY-MM-DD}.md的標準格式。 在步驟 4（組裝寫檔）時套用此模板。 報告自己的散文也要過 writing-conventions.md：先給結論、可指認、好讀。
模板全文
# Readability Review: {article}
- **審查文章**：{path}
- **審查日期**：{YYYY-MM-DD}
- **讀者人設**：產品設計師（不會寫程式、讀得懂技術文章）
- **預設讀者／用途**：{使用者在步驟 1 確認的目標讀者}
---
## 兩軸總評
| 軸 | 判斷 | 一句根據 |
|---|---|---|
| 通順（讀得下去嗎） | ✅ / ⚠️ / ❌ | {最關鍵的一個理由} |
| 可被討論（找得到地方同意或反對嗎） | ✅ / ⚠️ / ❌ | {最關鍵的一個理由} |
> 判斷尺度：✅ 讀者順利／❌ 讀者卡死（讀不懂或完全無從討論）／⚠ 之間。
> 細節見下方發現清單，每筆帶可指認錨點。
---
## 發現清單
> 每筆：類別圖示 ＋ 錨點 ＋ **現狀引文（before）** ＋ 卡在哪 ＋ **修正預覽（after，示意）**。
> 缺 before／after 不算完成。修正預覽是示意、供參考，作者自行定稿；本報告不改原檔。
### 🚧 卡關點（通順）
1. **{節標題／第幾段}**
- 現狀：> {直接引有問題的原文}
- 卡在哪：{讀者讀到這裡為什麼卡，一句}
- 修正預覽（示意）：> {改寫示意，讓作者看到方向長什麼樣}
2. ...
### 🔇 插不上話（可被討論）
1. **{節標題／第幾段}**
- 現狀：> {引出「無法同意或反對」的那段}
- 卡在哪：{為什麼讀者找不到入口}
- 修正預覽（示意）：> {示意怎麼給錨點／攤平選項／補出結論}
2. ...
### 📖 術語裸詞（沒鋪路的前提）
1. **{節標題／第幾段}**
- 現狀：> {引出含裸詞的原句}
- 卡在哪：「{裸詞或前提}」首次出現沒交代
- 修正預覽（示意）：> {在原句旁補一句極短 gloss，保留英文名，不必重寫整句}
2. ...
---
## 文件級判準對照
> 對照 writing-conventions.md 架構 A～E，只列命中項。沒命中的判準不必逐條寫「通過」。
| 判準 | 命中？ | 對應發現 |
|---|---|---|
| A 雙層（白話上層＋深究層） | 是 / — | {指到上面哪筆發現，或一句說明} |
| B 大綱不搶結論、分析節結論先行 | 是 / — | ... |
| C 標題有資訊 | 是 / — | ... |
| D 中性專業、不對讀者喊話 | 是 / — | ... |
| E 分歧攤平、給可指認錨點 | 是 / — | ... |
---
## 統計
- 🚧 {N} ｜ 🔇 {M} ｜ 📖 {K}
- 兩軸：通順 {✅/⚠️/❌}、可討論 {✅/⚠️/❌}
---
## 後續
- [ ] 作者拿各筆「修正預覽」當起點自行揉終稿（預覽是示意，本報告不改原檔）
- [ ] 若要逐段協作改寫 → 另開 /humanizer-zh-tw 或直接對段落改
- [ ] 揉完想再審一輪 → 重跑本 skill，產新一份 readreview 報告
> 本報告只回報可讀性／可討論性，不評論內容對錯、不代改、不替作者拍板哪裡要改。連結慣例（GFM，寫檔時遵循）
- 審查文章路徑：寫成相對路徑 markdown 連結。報告在
report/（單層），連到 vault 根的文章用../{file}.md，連到 spec 用../spec/{feature}/…。範例：[cross-repo-rule-seam-design.md](../cross-repo-rule-seam-design.md)。 - 發現錨點的節標題／段落：行內維持純文字引述（不必做成跳轉連結 —— 讀者拿著節標題自己回去找即可）。
- 標籤一律含非數字字元；純數字
#1不是合法 tag。
組裝檢查清單
寫檔前確認：
- 標頭四項全填（審查文章、日期、讀者人設、預設讀者／用途）
- 兩軸總評各有判斷 ＋ 一句根據（這是使用者最想看的結論，放最前）
- 每筆發現都記滿三格：錨點 ＋ 現狀引文（before） ＋ 修正預覽（after），沒有「整體有點難讀」這種無引文項
- 修正預覽是看得見的示意，不是抽象方向（沒有只寫「拆三段」「斷句」就交差）
- 修正預覽標明「示意」，沒有改原檔、沒有替作者定稿
- 沒有評論內容對錯的句子（沒寫「這個設計不必要」這類）
- 📖 項都通過「補一句白話就能懂」的分界（真的需要 coding 知識的沒誤報）
- 文件級判準對照只列命中項
- 統計數字與發現清單相符
命名與路徑
report/
├── cross-repo-rule-seam-design-readreview-2026-06-17.md
├── rough-cut-scheduler-spec-vs-legacy-readreview-2026-06-18.md
└── ...
- article：被審文章的檔名去副檔名
- 日期：今日（審查跑的日期）
- 同一篇一天內多審 → 加序號：
...-readreview-2026-06-17-2.md
例子：報告片段
# Readability Review: cross-repo-rule-seam-design
- **審查文章**：[cross-repo-rule-seam-design.md](../cross-repo-rule-seam-design.md)
- **審查日期**：2026-06-17
- **讀者人設**：產品設計師（不會寫程式、讀得懂技術文章）
- **預設讀者／用途**：給老闆與跨團隊 reviewer 確認跨 repo 規則接縫設計
---
## 兩軸總評
| 軸 | 判斷 | 一句根據 |
|---|---|---|
| 通順 | ⚠️ | 開頭直接進「tag 消費」機制，沒先一段白話框出「這份在解什麼問題」。 |
| 可被討論 | ⚠️ | 兩處設計取捨沒並排選項，reviewer 想反對其中一個方案沒有可指的錨點。 |
---
## 發現清單
### 🚧 卡關點（通順）
1. **§0 導讀**
- 現狀：> 「code repo 只消費 tag 過的 spec，不吃工作樹半成品。」
- 卡在哪：第一句就進機制，讀者還不知道「為什麼要有這個接縫、它在解什麼」。
- 修正預覽（示意）：> 「兩個 repo 怎麼對接？規則是：spec 一旦簽核就打 tag，code 端只認 tag 過的版本。這樣 code 不會吃到還在改的半成品。」（先一句白話框出問題，再給規則）
### 🔇 插不上話（可被討論）
1. **§3 交接約定**
- 現狀：> 「簽核即打 tag；code 端 manifest 記錄消費的 tag/SHA。」
- 卡在哪：兩個機制黏在一句並列，reviewer 若只想質疑其中一個，沒有可指的獨立錨點。
- 修正預覽（示意）：> 拆成兩個編號小節 ——「**3.1 簽核即打 tag**：……」「**3.2 code 端 manifest**：……」，讓人能指名討論某一條。
### 📖 術語裸詞（沒鋪路的前提）
1. **§2**
- 現狀：> 「新舊模型走 shadow 並跑。」
- 卡在哪：「shadow 並跑」首次出現沒解釋。
- 修正預覽（示意）：> 「新舊模型走 shadow 並跑（shadow＝新舊同時跑、比對輸出但不對外生效）。」
---
## 文件級判準對照
| 判準 | 命中？ | 對應發現 |
|---|---|---|
| A 雙層 | 是 | §0 直接進機制，缺白話上層（見 🚧1） |
| B 大綱不搶結論 | — | |
| C 標題有資訊 | — | |
| D 中性專業 | — | |
| E 分歧攤平給錨點 | 是 | §3 兩機制沒並排錨點（見 🔇1） |
---
## 統計
- 🚧 1 ｜ 🔇 1 ｜ 📖 1
- 兩軸：通順 ⚠️、可討論 ⚠️
---
## 後續
- [ ] 作者拿各筆「修正預覽」當起點自行揉終稿（預覽是示意，本報告不改原檔）
- [ ] 揉完想再審一輪 → 重跑本 skill