20 個能展現真實技能的作品集專案點子

最好的作品集專案點子，會為真實的人解決真實的問題，清楚展現一到兩項技能，而且是已完成的：可以上線、有文件、能夠解說。審閱者每份作品集只會花幾分鐘，因此為真實使用者打造的可用 App（例如社團的預約系統、公開資料的儀表板、有研究基礎的重新設計），勝過又一個知名產品的複製品。以下是依職務分類的二十個點子，每個都說明它展現什麼、第一版要怎麼做，以及坦白說最困難的部分。

以上所有專案都可以做成網頁 App 或網站，並附上連結。當你有三到四個專案後，如何建立作品集網站會說明如何展示它們。

強大的作品集專案應具備的特質

前端開發者

1. 無障礙表單函式庫示範

• 展現： 語意化 HTML、鍵盤支援、錯誤訊息、螢幕閱讀器測試。
• 第一版： 以正確的方式建置五種常見表單模式（註冊、地址、日期範圍、檔案上傳、多步驟），並附上一頁說明每項無障礙設計的選擇。
• 最困難的部分： 使用實際的螢幕閱讀器測試，而不只是依賴自動化檢測工具。如何讓你的網站符合無障礙標準提供了檢查清單。

2. 重建真實世界的頁面，然後加以改進

• 展現： 版面配置、響應式設計、對細節的注意。
• 第一版： 挑選一個有明確問題的公開頁面（例如難以理解的時刻表、雜亂的選單），重新建置，然後發布一個修正了問題的版本，並附上改版前後的對照。
• 最困難的部分： 尊重原作者。使用你自己的文字與圖片，標示為概念作品，不要複製標誌，也不要讓人以為這是該公司的作品。

3. 維持高速的大量資料表格

• 展現： 效能、排序、篩選、分頁、載入狀態。
• 第一版： 使用公開資料集中的一萬筆以上資料，建立一個具備搜尋、篩選與儲存檢視功能的表格。
• 最困難的部分： 量測。展示你修改前後的載入時間。

4. 適合離線使用的待辦清單 App

• 展現： Service Worker、本機儲存、恢復連線後同步。
• 第一版： 在沒有訊號時也能運作的待辦清單，並在連線恢復時同步。原生 App 與漸進式網頁 App說明了各種選擇。
• 最困難的部分： 兩台裝置同時編輯同一份清單時的同步衝突。

全端與後端開發者

5. 為真實小型企業打造的預約系統

• 展現： 資料建模、登入、電子郵件、時區、邊界情況。
• 第一版： 服務項目、可預約時段、預約紀錄、確認信件，以及管理者檢視頁面。預約建置工具可以先設定好基本功能，讓你專注於困難的規則。
• 可能的收入： 如果這家企業實際使用，可以收取少額月費。
• 最困難的部分： 重複預約與取消。撰寫你如何防止這些問題。

6. 具備角色權限的多使用者客戶入口網站

• 展現： 身分驗證、權限、檔案上傳、安全性思維。
• 第一版： 客戶登入後只能看到自己的檔案與訊息，員工則可以看到全部。請參閱如何建立客戶入口網站與入口網站建置工具。
• 最困難的部分： 證明某位客戶無法看到其他客戶的資料。把你的測試寫進說明中。

7. 附稽核紀錄的庫存追蹤工具

• 展現： 關聯式資料、歷史紀錄表、報表。
• 第一版： 品項、庫存異動、低庫存提醒，以及誰在何時改了什麼的紀錄。可從庫存建置工具開始。
• 最困難的部分： 當兩個人同時更新庫存時，仍要確保數量正確。

8. 附文件的公開 API

• 展現： API 設計、資料驗證、請求頻率限制、文件撰寫。
• 第一版： 針對你關心的資料集建立一個小型 API，包含金鑰、用量限制與文件頁面。如何建立 REST API說明了基本架構。
• 最困難的部分： 良好的錯誤訊息。這是 API 使用者最在意的地方。

9. 背景工作處理管線

• 展現： 佇列、重試機制、排程工作、監控。
• 第一版： 一個能匯入 CSV、在背景處理，並在完成後寄出報告的 App。請參閱如何執行背景工作。
• 最困難的部分： 失敗情況。展示工作在處理到一半失敗時會發生什麼事。

數據與分析

10. 帶著問題的公開數據儀表板

• 展現： 清理資料、選擇圖表、說故事。
• 第一版： 一個公開資料集、一個明確的問題（「哪些公車路線最常誤點？」）、三張圖表，以及一段書面解答。儀表板建置工具可以處理版面配置。
• 最困難的部分： 說明資料「沒有」顯示的內容。標註資料的缺口與限制。

11. 個人消費分析

• 展現： 分類、時間序列、隱私意識。
• 第一版： 匯入銀行帳單匯出檔（公開版本請使用範例或已去識別化的資料），自動分類，並呈現趨勢。
• 最困難的部分： 絕不公開真實的財務資料。

12. 小型企業 KPI 追蹤工具

• 展現： 將商業需求轉換為指標。
• 第一版： 為朋友的店家或社團製作：他們真正會問到的五個指標，從試算表更新。如何將 Google 試算表連接到你的 App說明了連接方式。
• 最困難的部分： 與業主一起挑選指標，而不是替他們決定。

設計師

13. 有研究基礎的重新設計

• 展現： 使用者研究、問題界定、迭代。
• 第一版： 訪談某個在地服務網站或 App 的三位使用者，找出一個問題，設計並測試修正方案。呈現的是研究發現，而不只是畫面。
• 最困難的部分： 找到真實的使用者。三次簡短的對談就足夠；如何進行客戶訪談可以提供幫助。

14. 小型產品的設計系統

• 展現： 一致性、元件、文件。
• 第一版： 色彩、字體、間距、十個含各種狀態的元件，以及一個展示它們實際應用的即時頁面。
• 最困難的部分： 要在真實產品中展示，而不只是一張樣本貼紙表。

15. 可運作的原型，而不只是設計稿

• 展現： 你理解設計在真實資料下如何運作。
• 第一版： 挑選一個你的設計專案，把它建置成可運作的網頁 App，即使是小型的也可以。像 Mythex 這樣的 AI App 建置工具，能把你的描述轉換為附即時預覽的可運作 App，讓你用真實資料與真實使用者來測試。
• 最困難的部分： 誠實說明哪些是你自己做的，哪些是工具產生的。

產品與無程式碼職務

16. 從問題到上線的案例研究

• 展現： 探索、排定優先順序、交付上線。
• 第一版： 在你所屬的某個群體中找出一個小問題，寫一份一頁的規格書，建置最簡單的解法，上線後量測使用情況。如何用 AI 撰寫產品需求文件提供了範本。
• 最困難的部分： 量測真實的數據。即使是「二十位成員中有 12 位在第一週使用了它」，也是一項成果。

17. 取代試算表的內部工具

• 展現： 流程思維、變革管理。
• 第一版： 把工作、社團或慈善機構中凌亂的共用試算表，改成一個簡單的 App。請參閱如何將試算表轉換為 App。
• 最困難的部分： 讓大家願意改用。撰寫你做了什麼來促使他們轉換。

18. 附公開路線圖的意見回饋入口

• 展現： 收集並排定使用者意見的優先順序。
• 第一版： 使用者提交並投票支持想法；你標示為規劃中、進行中或已完成。請參閱如何建立客戶意見回饋入口。
• 最困難的部分： 在公開場合說「不」。

以 AI 為重點的專案

19. 專門處理單一狹窄任務的 AI 工具

• 展現： 提示詞設計、成本意識、處理錯誤的輸出。
• 第一版： 把一件事情做好，例如把食譜轉換為購物清單，並保存結果，同時提供修正錯誤的方式。如何使用 LLM API說明了金鑰與成本。
• 最困難的部分： 展示你如何評估它：十組測試輸入，以及答對了幾組。

20. 搜尋你自己的文件

• 展現： 檢索、文本切分、引用來源。
• 第一版： 上傳一組公開文件（例如社團規章、遊戲手冊），並回答問題，同時附上原始段落的連結。什麼是 RAG說明了這種方法。
• 最困難的部分： 坦承答案不在文件中時，就直接說明。

如何完成並展示專案

1. 開始前先選定一位真實使用者。 可以是朋友、社團、前雇主，或你自己。
2. **在兩週內交付一個小版本，**然後根據使用者的意見加以改進。
3. 把程式碼放進 Git。 即使你是從 AI 建置工具開始的，也要匯出；如何將 Git 用於 AI 建置的 App說明了做法。（在 Mythex 上，程式碼匯出與 GitHub 功能屬於 Pro 方案。）
4. 閱讀並理解程式碼。 如果部分程式碼是 AI 寫的，如何審查 AI 產生的程式碼能幫助你達到面試時能夠說明的程度。
5. 寫成說明。 問題、使用者、你建置了什麼、關鍵決策、什麼地方出了問題、接下來要做什麼。一頁即可。
6. 讓專案持續上線。 失效的示範連結比沒有連結更糟。每次投遞前都要檢查你的連結。

如果想看看不以雇主為目標的更多點子，可以參閱你可以用 AI 建置的副業專案點子或網頁 App 點子。

常見問題