為什麼需要一個有意識的流程？
Side Project 失敗最常見的原因不是能力不足，而是「沒有結構的投入」——某天突然有了靈感，花幾天衝一衝，遇到第一個卡關就停下來，然後再也沒有繼續。
有意識地把流程拆開，有兩個好處：第一，每個階段有明確的目標，不容易因為遇到困難就不知道下一步；第二，拆開之後每個階段都短，更容易找到繼續的動力。
以下五個步驟，是大多數 Side Project 從概念到可展示成果的通用框架。
Step 1：定義問題（不是定義解法）
最常見的錯誤是：一開始就想「我要做一個什麼東西」，而不是先想清楚「我想解決什麼問題」。
問題定義越清楚，後面的方向越不容易跑偏。這一步要回答三個問題：
- 這個問題從哪裡來？ 是你自己觀察到的，還是別人提到的？自己觀察到的問題動機更強，也更容易說清楚「為什麼做這個」。
- 誰有這個問題？ 只有你，還是有一群人？不需要服務很多人，但能清楚說出「這個問題的存在對某類人是真實的」，成果的說服力更高。
- 解決這個問題，成功的樣子是什麼？ 不用完美，但要有一個具體的「完成標準」，讓你知道什麼時候可以說第一版做完了。
這一步建議花一到兩個小時，把問題寫下來，不要跳過。
Step 2：縮小範圍，定義 MVP
MVP（Minimum Viable Product）的概念是：做出一個最小可以展示、可以驗證方向是否正確的版本。
很多學生最大的問題是範圍定得太大。「我要做一個 AI 學習平台」是一個三年都做不完的題目；「我要做一個可以把文章自動摘要成三個重點的工具」是一個兩週可以有第一版的題目。
縮小範圍的原則是：把你想要的所有功能列出來，然後問「如果只保留最核心的一個功能，這個東西還有沒有意義？」找到那個「最小有意義的版本」，就是你的 MVP 目標。
MVP 不需要漂亮，只需要能運作、能展示、能得到第一個反應。
Step 3：做出第一版，記錄過程
這是最重要也最容易卡住的階段。幾個讓這個過程更順的原則：
- 設定一個截止日期：不是「做完再說」，而是「X 月 X 日，不管做到哪裡，先看一下現在有什麼」。截止日期不是為了催你，而是為了防止無限期拖延。
- 遇到卡關，先繞過去：如果某個技術問題讓你卡了兩個小時，先跳過它，用暫時的替代方案讓其他部分可以繼續。等整體跑起來之後，再回來解決這個問題。
- 每次工作結束，寫一行筆記：「今天做了什麼」、「卡在哪裡」、「下次從哪裡繼續」。這三行筆記兩個功能：一是讓你下次比較容易進入狀態，二是這些紀錄後來就是備審裡「執行過程」最真實的素材。可以用 Notion 系統集中管理這些開發日誌。
Step 4：得到第一個外部反應，然後優化
第一版做出來之後，最重要的一件事是：讓一個真實的人用它，或者看它，並且告訴你他的反應。
這個人不一定是你的目標使用者，可以是朋友、家人，或者任何願意花五分鐘給你反饋的人。重點是得到「我完全不了解這個背景的人」的第一反應，而不是你自己對它的評估。
外部反應最有價值的部分通常是：他看不懂的地方，和他覺得有用但你沒想到的地方。這兩個地方，就是優化的起點。
優化不需要做很多輪。一個完整的「做第一版→得到反饋→優化一輪」的循環，就已經比大多數只做但沒有反思的 Side Project 有說服力。
Step 5：整理成可展示的形式
Side Project 做完之後，如果沒有整理成可展示的形式，在申請上的效果會大打折扣。評審沒有時間自己去弄懂你做了什麼，你需要主動幫他們把「這是什麼、為什麼做、做了什麼、有什麼成果」說清楚。
依專案類型，最低限度的展示應該包含：
| 專案類型 | 怎麼整理 |
|---|---|
| 程式類 | GitHub Repo 附上清楚的 README（專案介紹、功能、使用技術、Demo 截圖或連結）。如果有部署，附上可以直接點開的網址（Vercel、GitHub Pages 都能免費部署） |
| 研究類 | 一份簡短的研究報告或 Kaggle Notebook，說明問題背景、分析方法、發現了什麼，以及你的反思 |
| 設計類 | Behance 或 Figma 連結，每個設計決策加上一句說明「為什麼這樣設計」 |
| 社群/品牌類 | 帳號連結加上一份簡短的成效說明（做了什麼、觀察到什麼、學到什麼） |
整理這些材料的過程，也是你自己回顧「這個 Side Project 讓我學到什麼」的最好時機。這個反思，是備審說明裡最值錢的部分。