Demo 要有情境，不要只點功能
很多新手 Demo 作品時，會從首頁開始介紹按鈕，然後一個一個功能點過去。這樣很容易讓人失去耐心，因為對方還不知道這個工具為什麼重要。
比較好的方式是先給情境：一個轉職者拿到職缺，但不知道履歷哪裡不夠；一個上班族收到很長的 PDF，不知道哪些段落要先看；一個客服每天重複回答同樣問題。
有了情境，功能才有意義。Demo 的目的不是證明你會做畫面，而是證明你能把問題變成流程。
如果你想轉 AI 工程師，Demo 其實是在回答一個問題：你是不是只會把 API 接上畫面，還是你真的理解使用者、資料、AI 輸出和錯誤處理？
這就是為什麼 Demo 不能只照著功能表走。你要像在講一個小案例：原本使用者卡在哪裡，你的工具如何接住資料，AI 在哪一步幫忙，最後使用者得到什麼可以採取行動的結果。
Demo 腳本
用問題帶出功能
要展示前後差異，別只展示漂亮畫面
如果是 PDF 摘要工具，你可以先展示原始文件有多長，再展示工具整理出的摘要、待辦和風險。這樣讀者會明白工具節省的是哪一段工作。
如果是履歷分析器，你可以先展示原履歷和職缺要求，再展示分析結果。重點是讓人看到「原本看不出差距，現在差距被整理出來」。
如果是 FAQ Bot，你可以先展示客服資料散落在不同文件裡，再展示使用者提問後，系統如何根據知識庫回答。這會讓讀者知道你做的不是聊天玩具，而是有資料來源的問答流程。
前後差異會讓作品更有說服力。因為真正的工具價值通常不是畫面本身，而是使用者完成任務的方式改變了。
你可以把 Demo 分成兩張畫面：左邊是原本狀態，右邊是工具處理後的狀態。這種對照比單純展示結果更容易被記住，也更適合未來拆成 IG 輪播或短影片。
前後對照
Demo 要讓人看見任務怎麼變簡單
一個完整 Demo 可以照六段來講
第一段，先講使用者情境。不要急著打開工具。先用一兩句話說明使用者原本遇到什麼問題。
第二段，展示原始資料。讓對方看到履歷、PDF、FAQ 文件或文字資料原本長什麼樣。這一步會建立痛點。
第三段，展示輸入方式。使用者要貼文字、上傳檔案、輸入問題，還是選擇條件？這裡要讓人理解工具的入口。
第四段，展示 AI 處理流程。你不一定要秀程式碼，但要說清楚 AI 負責什麼。它是摘要、比對、分類、產生建議，還是根據知識庫回答？
第五段，展示輸出結果。不要只秀一大段 AI 文字。最好把結果分成欄位、清單、風險提醒或建議步驟，讓人知道結果可以被使用。
第六段，展示限制和下一版。說明什麼情況下結果需要人工確認，下一版要補什麼。這會讓 Demo 從「功能展示」變成「工程判斷」。
Demo 六段式
從情境講到限制，Demo 才完整
Demo 時要講判斷，不要只念畫面
很多人 Demo 會一直說：「這裡可以上傳、這裡可以按、這裡會輸出。」這些話沒有錯，但價值很低，因為畫面已經看得到。
你應該補的是畫面看不到的判斷。例如：我為什麼把輸出分成這幾個區塊？為什麼這裡要提醒使用者確認？為什麼不讓 AI 直接給最終答案？為什麼需要保留原文對照？
這些判斷才是面試官想聽的內容。因為他不是只看你會不會做介面，而是看你是否理解 AI 工具在真實使用時會遇到什麼問題。
如果你是非本科轉職者，更要講出這些判斷。你的優勢不一定是模型理論，而是你能把工作場景、使用者痛點和 AI 工具流程講清楚。
Demo 要控制時間，不要讓人陪你迷路
一個作品 Demo 不應該無限制地講下去。你可以準備三種版本：三十秒版本、一分鐘版本、三分鐘版本。
三十秒版本適合社群短影片或自我介紹。只講問題、工具做什麼、結果長什麼樣。
一分鐘版本適合作品頁或 LinkedIn 貼文。可以補上輸入、AI 處理和一個限制。
三分鐘版本適合面試。這時候可以完整講情境、流程、技術選擇、錯誤處理和下一版。
如果你連三十秒都講不清楚，通常代表作品定位還不夠清楚。這不是口才問題，而是作品敘事還沒有整理好。
時間版本
同一個作品要準備三種 Demo 長度
準備一個失敗案例，反而更像專業人士
AI 工具一定會遇到不確定情況。資料太少、問題太模糊、文件品質太差、使用者期待太高，都可能讓結果變差。
如果你的 Demo 能說明「這種情況我會提醒使用者補資料」或「這種問題會轉人工處理」，會比假裝工具永遠正確更專業。
面試官通常不是只看你會不會接 API，也會看你知不知道系統在真實環境裡會怎麼壞。
你可以刻意準備一個壞例子。比如使用者只輸入「幫我分析履歷」，但沒有提供職缺；或是上傳的 PDF 是掃描圖片，文字抽不出來；或是 FAQ Bot 遇到政策文件沒有寫清楚的問題。
這些壞例子可以展示你的處理方式：請使用者補資料、顯示無法判斷、提醒人工確認、或轉交真人處理。這些不是失敗，而是成熟產品應該有的防線。
失敗案例
成熟的 Demo 會展示工具怎麼處理不確定
如果是面試 Demo，要補一點技術深度
面試 Demo 不需要一開始就講很多程式碼，但你要準備好被問到技術細節。尤其是 AI 作品，面試官可能會問資料怎麼進來、Prompt 怎麼設計、API Key 怎麼保護、結果怎麼驗證。
你可以用白話說明架構：前端負責收集資料和顯示結果，後端負責呼叫模型和保護金鑰，AI 負責產生摘要或分析，最後再把結果整理成使用者能檢查的格式。
如果你有使用 JSON 格式，也可以說明為什麼。不是因為 JSON 聽起來技術，而是因為結構化資料能讓結果更容易呈現在畫面上，也比較容易檢查。
這一段不要講成背誦技術名詞。你要把技術和使用者需求接起來，讓對方知道每個技術選擇都有原因。
錄 Demo 影片時，先寫腳本再錄畫面
很多人錄 Demo 影片時會直接開錄，結果邊操作邊想要說什麼，影片就會變得很散。比較好的做法是先寫腳本，再錄畫面。
腳本可以很簡單：第一句說問題，第二句說工具做什麼，第三句展示輸入，第四句展示輸出，第五句說限制或下一版。
錄畫面時不要滑太快，也不要把滑鼠到處晃。畫面上每一次切換，都要對應你正在講的內容。
如果影片要放到社群，建議不要從程式碼開始。先從痛點或前後差異開始，因為大多數讀者不是為了看你的程式碼，而是想知道這個工具跟他有什麼關係。
這些 Demo 方式會讓作品看起來變弱
第一，只展示一段很漂亮的 AI 回答。這會讓人懷疑你只是把 ChatGPT 包進畫面。
第二，完全不講資料來源。AI 作品如果不知道資料從哪裡來，可信度會下降。
第三，沒有展示錯誤處理。真實工具一定會遇到錯誤，完全不講錯誤反而不自然。
第四，從技術名詞開始講。除非對方明確要看技術，否則先講使用者問題比較容易建立理解。
第五，Demo 太長。時間太長不代表內容有深度，常常只是沒有整理重點。