最近準備一場技術分享時，我做了一個有點任性的決定：不用 PPT，改用 HTML 做整份簡報。
不是因為我突然想當前端藝術家，也不是覺得投影片已經過時。單純是我發現，當分享主題從「講一個概念」變成「展示一套正在運作的 AI Agent 工作流」時，傳統簡報很快就會開始卡手。你想放流程圖、想跳 demo、想補一段架構說明、想現場修正某個順序，PPT 當然都做得到，但每一步都像在隔靴搔癢。
技術分享最怕變成漂亮截圖展
很多技術分享最後會變成一堆截圖。系統畫面截圖、終端機輸出截圖、流程圖截圖、文件截圖，然後講者在每張圖旁邊補充：「這邊實際上會呼叫某個服務」、「這裡背後有一個排程」、「這張圖只是示意」。
我不是說截圖不好。截圖很穩，離線可用，不會現場炸掉。但它也有一個問題：截圖會把一個動態系統壓扁成靜態證據。
尤其 AI Agent 這種東西，真正有價值的不是某個單點畫面，而是整個鏈路：資料怎麼進來、模型拿到什麼上下文、工具怎麼被呼叫、結果如何驗證、錯誤怎麼回報、人在哪些節點介入。這些東西用一張張截圖切開之後，觀眾很容易只看到「哇，好像很酷」，但看不清楚它到底怎麼被治理。
這也是我後來越來越在意的事：技術分享不只是展示成果，而是讓別人理解你的判斷。你為什麼這樣切邊界？為什麼這一步不自動化？為什麼這個工具要先查證來源？如果簡報工具本身讓你很難呈現這些脈絡，那它就不只是排版問題，而是溝通品質問題。
HTML 的優勢：它本來就是互動介面
HTML 做簡報最直覺的好處，是它不是「投影片格式」，而是一個小型互動介面。
我可以做固定側邊目錄，分享時快速跳章節；我可以把 demo 連結、流程圖、程式碼片段、注意事項放在同一頁，不用一直切視窗；我也可以把某些內容設計成可展開區塊，講到再打開，沒講就收起來。這些在 PPT 裡不是不能做，但做起來通常很笨重。
更重要的是，HTML 很適合技術人的修改節奏。分享前一小時突然想到某個段落順序怪怪的？直接改檔案。有人指出流程圖 actor 順序不對？改完存檔，重新整理瀏覽器。需要補一個章節？複製一段 section，加上 anchor，目錄連結就能跳。
這種「即時修正」對技術分享很重要，因為真正的技術內容常常不是一次寫對。尤其當你在整理一套複雜工作流時，最常發生的不是視覺設計問題，而是語意順序問題：到底是排程先 poll，還是 API 先觸發？到底是 agent 主動查知識庫，還是技能規範要求它先查？這種錯誤如果被包成一張漂亮投影片，反而更難修。
我想呈現的是鏈路，不是工具清單
這次準備分享時，我一開始也差點掉進一個坑：把內容做成工具 demo。
技術人很容易這樣。看到一套 runtime、一堆 skills、一個排程系統、一個郵件處理器、一個知識庫查詢流程，就會想逐項介紹：「這個可以做什麼，那個可以怎麼設定。」但對公司內部分享來說，這其實不是最重要的。
真正重要的是 implementation story：我們怎麼把零散工具變成可運作的流程？怎麼讓 AI 不只是聊天，而是能依照來源查證後回答？怎麼把人類的審核、回饋、修正，變成下一輪系統改善的一部分？
所以我後來把分享重心從「工具有多厲害」調整成「一個工作流如何被設計、治理與迭代」。這件事用 HTML 表達起來特別順，因為頁面可以像文件，也可以像產品介面；可以先給整體地圖，再讓觀眾跳進某個節點看細節。
flowchart LR
A[需求與真實情境] --> B[資料來源與權限邊界]
B --> C[Agent 工作流]
C --> D[工具呼叫與查證]
D --> E[人類審核與回饋]
E --> F[知識與流程迭代]
F --> C
這張圖其實就是我現在看企業 AI 導入的基本模型。不要只問「模型能不能回答」，要問「它回答之前看了什麼、能動什麼、誰負責驗證、錯了怎麼修」。
遠端會議裡，簡報也是一個產品
以前實體分享時，PPT 的限制比較不明顯。講者站在台上，投影機播出來，觀眾主要看大畫面。可是遠端會議不一樣。有人用筆電，有人用手機，有人網路卡，有人晚進會議，有人想回頭看某段。
這時候簡報就不只是「畫面」，它更像一個臨時產品。
HTML 的好處是可以直接給 URL。會議中有人跟不上，可以自己打開；講完後有人想複習，也不用等我匯出 PDF。甚至我可以在頁面裡保留章節 anchor，讓人直接跳到「安全性」、「工作流」、「需求表達」這種段落。
當然，這也代表你要承擔一些工程責任。字級要夠大，版面不能太花，連結要能點，頁面要在常見瀏覽器上正常跑。不要把它做成炫技網站，最後投影出來什麼都看不到。這一點跟寫內部工具很像：使用者不是來欣賞你的 CSS，他們是要理解事情。
HTML 不是取代 PPT，而是換一種思考方式
我不會說以後所有簡報都該用 HTML。商務簡報、提案、需要嚴格版型控管的場合，PPT 還是很方便。它成熟、穩定、協作門檻低，也比較不會現場出現「CSS 怎麼跑版了」這種讓人想找洞鑽的事情。
但如果主題本身就是系統、流程、agent、資料治理、工程實作，我現在會優先考慮 HTML。因為它逼我用「使用者怎麼走過這份內容」來思考，而不是用「下一張投影片要放什麼」來思考。
這兩者差很多。
PPT 的單位是 slide，HTML 的單位是 experience。前者適合線性敘事，後者適合呈現網狀關係。技術系統偏偏常常是後者：一個需求會連到資料來源，一個資料來源會連到權限，一個權限會連到 agent 行為，一個 agent 行為又會連到監控與回饋。
用 HTML 做簡報，對我來說不是為了看起來比較潮，而是讓簡報形式更接近我想講的東西。
最後：工具選擇會影響你怎麼講故事
這次的收穫不是「HTML 比 PPT 強」。這樣講太粗暴，也不公平。
真正的收穫是：工具選擇會影響敘事方式。當我用 PPT，我會自然地把內容切成一張一張；當我用 HTML，我會開始想路徑、層次、互動、連結，以及觀眾如何在分享後繼續使用這份材料。
這剛好也呼應我最近對 AI Agent 的看法。很多導入失敗不是模型不夠強，而是團隊把它當成單點工具，沒有把流程、知識、權限、驗證和回饋一起設計進去。簡報也是一樣。如果我只是丟一堆截圖，那我其實也在用單點工具思維溝通一個系統問題。
所以，下次如果你要分享的是一套真的會跑的工作流，而不是一個靜態結論，可以試著問自己：我需要的是投影片，還是一個可以被走讀的小介面？
答案不一定永遠是 HTML。但光是這樣問，通常就會讓整份分享更清楚。這大概就是我這次踩完簡報工具選擇後，最想留下來的教訓。