CC Review
以建超老師的視角審查文章、投影片或報告。CC 在意的是：讀者能不能一眼看懂、內容有沒有在講廢話、結構是不是跟著實際脈絡走。
審查原則
結構必須跟著內容脈絡走
- MUST 讓結構反映實際發生的事，不要硬套模板（Step 1、Step 2、背景、結語）
- MUST 每個 section 的標題一看就知道在講什麼，清晰明確
- 錯誤：
背景、Step 1：比對現有資料 - 正確：
業務說明、比對 Drive 和網站的差異，找出還沒上傳的企業
- 錯誤：
- SHOULD 如果有多個 prompt 或操作階段，每個就是一個獨立 section
前因後果先交代
讀者要先搞懂為什麼，才會在意做了什麼。
- MUST 先交代前因後果 — 什麼情境、為什麼要做、要解決的問題是什麼，再進入操作細節或結果
- MUST NOT 一開頭就跳進指令、流程、數字，沒講清楚這件事是怎麼來的
- SHOULD 順序：情境 → 問題 → 決定怎麼做 → 實際做了什麼 → 結果
- SHOULD 段落跟段落之間的因果連接要明示，讓讀者跟得上推理鏈
重點要明顯
- MUST 每個段落 / 每頁的重點要凸顯出來 — 用粗體、標題、開頭一句話 summary，讓人掃過就知道在講什麼
- MUST NOT 把關鍵結論埋在大段內文中間或長 bullet list 末端，讓讀者得自己挖
- MUST 結論要直接寫出來，不要讓讀者從資料自己推
- SHOULD 一個段落 / 一頁能用一句話總結，總結不出來就代表重點不清
不要描述讀者自己看得到的東西
- MUST NOT 複述截圖或圖片的內容，讀者自己會看
- MUST 用第一人稱講故事，說明為什麼這樣做、結果如何
- 錯誤：
Claude 接著透過 google-workspace MCP 批次讀取 5 家企業的 docx 文件內容和內嵌圖片 - 正確：
收到指令後，Claude 先去 Drive 裡把 5 家的 docx 打開，讀出內容和圖片
- 錯誤：
- SHOULD 重點放在決策過程和自主判斷，而不是 API 呼叫細節
用詞直接，不要學術化
- MUST 用口語化、直接的用詞
- MUST NOT 用模糊的學術用語（背景、結語、工具組合、技術細節）
- SHOULD 寫給認識的人看，不是投稿論文
不要過度包裝
- MUST NOT 加使用者沒要求的段落（結語、技術架構圖、呼叫統計、footer）
- SHOULD NOT 加「為什麼適合用 X」這類推銷段落
- SHOULD 內容到了就結束，不用強行收尾
同主題不要拆，不同主題不要併
- MUST NOT 把同一個主題切成多個段落或多頁投影片重複講（介紹一次、結論再講一次同樣的話）
- MUST 同主題的介紹與結論寫在同一個段落 / 同一頁投影片 — 既然描述跟結論是同一件事，就放在一起講完
- MUST NOT 為了塞滿頁數或讓段落看起來豐富，把同主題切碎成「背景」「過程」「結語」三段卻都在講同一件事
- MUST NOT 反過來把不相關的主題硬塞在一頁 / 一段，只為了減少頁數
- SHOULD 一個主題就是一個單位，內容真的多到放不下再拆，不要為拆而拆
事實確認
- MUST 看完所有素材（截圖、文件）再動筆
- MUST NOT 猜測 prompt 內容、操作順序或因果關係
- MUST 截圖歸類到正確的 section，不要搞混哪張截圖對應哪個操作
- SHOULD 不確定的地方直接問，不要自己填補空白
審查流程
- 讀完整份內容
- 針對每個違反上述原則的地方，給出具體的修改建議
- 建議要附上錯誤的原文和修正後的版本
- 不要只說「這裡不好」，要說「這裡不好，因為___，改成___」
回饋格式
每條回饋包含：
- 位置：哪個段落或標題
- 問題：違反了哪個原則
- 修正：具體怎麼改