以下是進階講者才會遇到的錯誤——已經會做乾淨投影片、也講過不少場，但簡報仍然沒達到效果。每一條先給症狀，再給機制，最後給修法。順序按出現頻率。
一、投影片太滿，且刪不下去
症狀：每頁六到十行文字，講的時候必須依賴畫面。自己也知道太滿，但每一行看起來都必要。
機制：太滿的根因不是不懂設計，是缺少安置刪除物的容器。當投影片同時要當現場視覺、講者提詞、事後文件，三種需求疊加，必然滿。
修法：建立三個容器再刪（見 05）——講者備忘（notes）、附錄頁、獨立文件。刪除變成搬移，阻力就消失。open-slide 的結構性幫助是 /slide-authoring 規定 agent 必須先把整頁的垂直空間預算對到 1080 px，寧可拆兩頁也不縮字級。
二、投影片朗讀
症狀：講的內容與螢幕文字幾乎逐字相同。聽眾低頭看手機——他們已經讀完了，而閱讀比你說話快。
機制：這是 Mayer 冗餘原則的直接違反。口說與螢幕文字爭搶同一條語言處理通道，兩者都變慢。它同時是症狀而非病因——真正的病因通常是「沒有排練，所以需要提詞」。
修法：三步。第一，把論述搬進 notes。第二，做第一輪逐字排練，讓內容存在腦中而非畫面上（見 09）。第三，把頁面標題改寫成完整結論句——標題若已是結論，你就不需要念它，可以直接解釋。
三、標題是名詞片語
症狀：「營收表現」「架構現況」「未來規劃」。聽眾要等你講完才知道剛才那張圖要看什麼。
機制：違反 signaling 原則。標題本該是組織結構的線索，名詞片語只提供分類，不提供訊息。
修法：全 deck 檢查一次，每個標題改成完整句子且是結論。這是投入產出比最高的單一改動——通常一小時可以改完 40 頁，效果比重做版面明顯。
四、節奏失控：前面太慢、後面趕
症狀：規劃 15 分鐘，講到 12 分鐘時還在支點二，結尾用 40 秒帶過。
機制：兩個原因。開場鋪陳超編（背景講了五分鐘），以及沒有時間錨點所以無法在中途察覺偏移——等到發現時只剩結尾可以砍，而結尾正是峰終定律裡最貴的部分。
修法：排練到規劃時間的 90%；設兩到三個時間錨點寫進 notes；事先標記一到兩個「超時就跳」的段落。永遠不砍結尾——寧可砍中段兩個案例。
五、一頁承載兩個重點
症狀：看起來很有效率（一頁講完兩件事），但聽眾事後只記得其中一件，而且不同的人記得不同的那一件。
機制：注意力無法分配到同一畫面的兩個焦點；聽眾會選一個，選哪一個由視覺權重決定，而不是由你的口說決定。
修法：檢驗法是遮住整頁只留標題，問「標題自己能不能成立為一個完整主張」；再遮住標題只看圖，問「這張圖是否只支持這一個主張」。兩題有一題不過，就拆頁。
六、把最強的反對意見留到 Q&A
症狀：正文很順，Q&A 第一個問題就把整場的結論打回原點，而且你只有 40 秒可以回應。
機制：正文裡你有版面、時間與準備好的證據；Q&A 裡你只有臨場記憶。把最重要的攻防放在你最弱的場地，是自己造成的劣勢。
修法：在支點三的位置設一頁「你可能會說⋯⋯」，複述反對意見的最強版本再回應。附帶效果是建立可信度：聽眾會判斷你是否誠實地理解了另一面。
七、Q&A 崩盤
症狀：一個人問了五個延伸問題吃掉全部時間；或一個挑戰型問題演變成十分鐘的辯論；或沒有人提問，尷尬三十秒後結束。
機制：把所有問題當成同一類處理。五類問題（釐清、延伸、挑戰、展示、無關）需要五種不同的處理方式，見 10。
修法：Q&A 開始前先講規則（時間、一人一題、範圍）。挑戰型先複述再回應。僵持不下時把爭論轉成待驗證項：「我們對這一點看法不同，短時間不會收斂，我提議記下來用資料決定。」冷場時不要問「有沒有問題」，改問具體的：「剛才那個 trade-off，有沒有人的專案是反過來的？」
八、把互動當成裝飾
症狀：安排了投票或提問，但無論結果如何，後面的內容完全不變。聽眾會察覺到這一點，之後的互動參與度歸零。
機制：互動的價值來自它真的影響接下來發生什麼。純儀式性的互動消耗信任。
修法：設計互動時先想「如果他們的答案跟我預期的相反，我要怎麼調整」。答不出來，就把這個互動改成預測題（見 06）——預測題不需要改變後續內容，因為它的作用是編碼而非資訊蒐集。
九、live demo 沒有備援
症狀：demo 失敗，重試兩次，共花四分鐘，全場注意力清零。
機制：demo 依賴的環節（網路、服務狀態、資料狀態、版本、輸入法）任何一個變化都會失敗，而現場環境永遠與你的機器不同。
修法：每個 live demo 都準備靜態備援（錄影或截圖序列），並事先決定失敗一次就切換。把切換規則寫進 notes：'⚠️ demo 失敗一次就切錄影，不要重試'。這條規則的價值在於它讓你在慌亂時不需要做決定。
十、深色投影片在明亮會議室
症狀：在自己螢幕上優雅的深底淺字，投出來變成灰底淺灰字，後排讀不到。
機制：投影機的實際對比度遠低於螢幕，且會議室通常不會全暗。深色底的可讀性完全依賴環境光可控。
修法：場地不確定時用淺底深字。已確認可調暗才用深底。無論哪種，都不要靠純飽和色表達差異——用明度差。實際驗證只需要進場後走到最後一排看一次。
十一、「講得很清楚」但沒人記得
症狀：現場反應良好，點頭、有笑聲，一週後問起來沒有人說得出重點。
機制：流暢的講解會製造熟悉感錯覺——聽懂了，於是不再投入認知努力，事後無法提取。這是進階講者最容易掉進去的陷阱，因為它偽裝成成功。
修法：加入需要動用大腦的時刻：預測題、提取點、停頓、讓聽眾說出 takeaway。代價是幾分鐘的內容量，換來的是實際的保留。詳見 06。
十二、把 60 分鐘當成長版的 15 分鐘
症狀：一小時的簡報結構是「開場 → 五個重點 → 總結」，聽眾在第 25 分鐘進入被動接收。
機制：沒有結構性的注意力復位機制。人可以聽 60 分鐘，但無法連續 60 分鐘維持同一種認知模式。
修法：章節化 ＋ 每章的預測／解釋／案例／提取微結構 ＋ 一次中場（練習、鄰座討論或批次 Q&A 三選一）。見 04。
十三、器材靠運氣
症狀：轉接頭不合、presenter view 開在投影幕上、電量不足、網路連不上而 demo 全掛。
機制：對每一個依賴都只有一條路。
修法：每個依賴列出備援（見 08 的表）。最重要的一條是不依賴網路的版本：open-slide 的 dist/ 是純靜態站，配上 PDF 匯出就是兩份離線備援。注意 PDF 匯出在 Safari 不支援。
十四、notes 索引錯位
症狀（open-slide 專屬）：presenter view 顯示的備忘是上一頁或下一頁的。
機制：notes 是與頁面陣列索引對齊的字串陣列。插入一頁而忘了補一個 undefined，之後全部錯位，且 dev server 不會報錯。
修法：把「notes.length === 頁數」列為 review 的固定檢查項；每次改動頁面陣列後開一次 presenter view 掃過。
十五、agent 產出後不做結構審查
症狀（open-slide 專屬）：/create-slide 產出的 deck 版面一致、型級正確，但論證是「議程 → 三個並列重點 → 總結」，沒有主張、沒有反對意見、沒有記憶錨點。
機制：agent 擅長一致性與版面，不擅長判斷「這群人需要被說服的是哪一點」。給它主題而非主張，它只能產出主題結構。
修法：先寫 big idea 與 outline 再呼叫（見 01、12），並把「標題寫成完整結論句」「每頁一個重點」這類原則寫進 theme 的 markdown，讓每次生成都自動遵守。
延伸
- 證據強度與哪些是風格取向：16