為什麼表達和作品一樣重要

很多人有一個直覺：作品做得好，自然就會被看見。但現實是，評審、面試官和競賽裁判每次要看的東西都很多，如果你的作品說不清楚，它的好就很難被感受到。

更重要的是：呈現一個作品的方式，本身就是一種能力的展示。你能不能把複雜的東西說得清楚、你能不能在有限時間內讓別人抓到重點、你能不能預測聽眾的問題並提前回答——這些都是評審真正在評估的東西，不只是作品本身。

一個做得不那麼完整但說得清楚的作品，通常比一個做得很複雜但說不清楚的作品更有說服力。因為清楚代表你真的理解自己在做什麼。

三分鐘說清楚一個作品的結構

不管是 Hackathon 的 Demo、面試裡的自我介紹，或者備審裡的作品說明，有一個結構幾乎適用於所有場合：

1. 問題（30 秒）：你在解決什麼問題？這個問題為什麼值得解決？讓聽眾先理解問題，才能理解你的解法有什麼意義。

不要說：「我做了一個 AI 學習工具。」 要說：「我發現同學在準備申請的時候，花了很多時間在找資料，但找到的東西常常不相關或太難懂。我想解決這個問題。」

2. 解法（60 秒）：你的解法是什麼？怎麼運作的？這裡重點是讓聽眾理解你的核心選擇，不是每個技術細節。最好有一個 Demo 或截圖，讓人能看見它長什麼樣子。

3. 過程（45 秒）：你遇到了什麼挑戰？你怎麼解決的？這部分是最容易被忽略但最重要的，因為它展示的是你真實的思考過程，不只是最終結果。

4. 成果與反思（30 秒）：你做出了什麼？從這個過程裡學到了什麼？下一步想怎麼繼續？

5. 為什麼這件事和你有關聯（15 秒）：你為什麼做這個？它對你申請的科系或方向有什麼意義？

這五個部分加在一起，大約是三分鐘。如果只有一分鐘，保留問題、解法、和為什麼你做這個——其他的等對方問。

Demo 的實際技巧

讓東西真的能跑。 Demo 最差的結果是現場跑不起來。如果可能，事先準備一個備用方案：錄好的操作影片、截圖，或者一個已經部署好的版本，讓你在網路不穩或環境有問題時還有東西可以展示。

Demo 的動線要提前想好。 不要在 Demo 時即興決定要展示哪些功能。提前決定你要展示的三到五個核心操作，按照一個有邏輯的順序來，讓聽眾能跟著你的思路理解這個東西。

說明你在做什麼，不要只是操作。 很多人在 Demo 時只是在操作，但沒有說「現在我在做什麼、為什麼這一步很重要」。好的 Demo 是帶著聽眾走的，而不是讓他們自己猜你在做什麼。

先展示核心功能，再展示細節。 如果時間有限，從最重要的一個功能開始，確保那個核心價值被理解了，再展示其他東西。很多人想一次展示全部，結果每個部分都沒有說清楚。

簡報的基本原則

如果你需要用簡報（Hackathon 最後的 Pitch、競賽說明、面試的視覺輔助），幾個基本原則：

每張投影片只有一個重點。 如果一張投影片需要讀完才能理解你在說什麼，它包含太多了。聽眾應該在兩秒內抓到這張投影片的核心，然後透過你說的話深入理解。

用圖和數字，少用文字段落。 文字段落讓聽眾在讀和聽之間切換，兩件事都做不好。圖表、截圖、簡單的流程圖，通常比一段說明文字更清楚。

問題 → 解法 → 成果 的三段式結構，是最容易讓人理解的框架。 不需要複雜的敘事結構，清楚就是最好的。

不要在簡報上放你打算說的所有話。 簡報是視覺輔助，不是你的講稿。如果你把所有話都放在投影片上，聽眾就會讀投影片而不是聽你說話，而你說話就變成多餘的了。

面試裡怎麼說

面試裡說明一個 Side Project，和 Demo 有一個很大的不同：面試官會追問，而且追問的目的是測試你真的理解這件事。

這意味著你不能只準備一個流暢的說明版本，你需要準備「被追問時怎麼回答」。

常見的追問方向：

  • 「你為什麼選擇這個方法，而不是 XX 方法？」（測試你對技術選擇的理解）
  • 「如果這個方法失敗了，你的備選方案是什麼？」（測試你的問題解決思維）
  • 「如果再做一次，你會改什麼？」（測試你的反思能力）
  • 「這個作品現在有人在用嗎？反饋是什麼？」（測試你對成果的誠實認識）

準備這些追問的方式不是背答案，而是確保你真的做過這件事、真的遇到過問題、真的思考過這些選擇。面試追問能測出來的，正是你有沒有真實的第一手經驗，而不是一個整理過的表面說法。

如果有一個問題你不知道答案，說「我沒有想過這個問題，但我覺得可能是 XX，你有什麼想法嗎？」比硬撐一個你不確定的答案誠實得多，評審也更能接受。