Sui's Portfolio 我的作品集網站上線

我的工作室官網 Funkuki.com 在我停止經銷海外設計後，已呈現暫時中止的狀態很多年了。

因為考慮要把我散落的創業和創作經歷整理歸納，於是很臨時地決定重新製作一份作品集網站。我在工作室官網下另外建立了子網域 sui.funkuki.com，並建立一個專屬於收納上架我的作品、撰寫設計相關長文、以及上架我的數位作品的專門網站。

設計與製作流程

製作網站我有自己的一套工作流程，是目前我覺得最順手的做法：

首先我從網站的主視覺出發。我先用手繪很快地完成了初步的草稿。雖然非常潦草，但能看到我想呈現我平日主要的工作形態。

接下來我把草稿丟進 Midjourney ，讓它為我生成幾個不同的版本，最終我挑出了其中一張我覺得最適合後續再持續生成動作的造型。

接下來我們將選定的版本上傳回到 Nano Banana 2, 讓它為我生成彩色的主視覺，並從中生成乾淨的角色正面圖片。

對我來說，一個網站要有趣，首先畫面素材要準備齊全。不管是圖片、元件、說明插畫，都可以在這一步開始準備。這一個階段和第五步其實有時可以交換順序，你也可以先進行網站初步視覺初版的架構，再回到這一步補齊需要的視覺資產。

在建立網站或APP等數位產品的過程，我總是很習慣地先建立好一份接近高保真的Mockup。這樣讓我能一邊在建立的過程中思考網站的視覺設計系統，同時一邊也能思考使用者的使用旅程。

但別誤會，我這邊所謂的 Mockup 也不是幾十幾百頁的 figma 設計，而是幾張主要頁面，用以確認視覺導覽和元件設計。

這個步驟的確不是最有效率的做法，目前更有效率的作法是用「全文字 Prompt 」或「低保真wireframe」讓AI發揮創意，再加上 design.md 來幫助美化網站，最後再透過持續的迭代來完成設計。

但我個人覺得這是很值得進行的一個步驟。如此一來你在後期開發網站時，就可以專注於程式碼邏輯、資料流程和架構。這比邊寫 Code 邊想這個按鈕或卡片放左邊好還是右邊好要來得順暢多了。

接下來我把視覺資產和 figma 設計匯入Claude Design，並請它根據我的 mockup 很快地生成網站初步的畫面。Claude Design 能快速地把我的視覺想法，精準翻譯成前端程式碼（React/Tailwind）。

在完成初步視覺架構後，你可以將它匯出回到主機的專案資料夾，接下來我們要進入 Claude Code 進行實際邏輯與功能的串接，以及UI 畫面的微調。

這個階段是最燒Token 的。我目前的做法是這樣的：

• 先設計好 Claude 的參考md 檔 （claude.me)，讓他用較少的上下文去進行工作。（這份文件可以是你的

• 我也會讓 Claude code根據在第五步建立好的畫面，建立可重複使用的元件庫，後續開發其他次要頁面時速度就會更快。

• 另外，在不同的工作任務，也選用不同的Claude 模型，單純文字、UI 修調，可以用 Haiku 模型，速度最快捷。邏輯、功能串接則使用 Sonnet，很聰明也很周到，但燒的Token 較多。

• 一個小技巧是在對話 session 過長時，使用 /compact來壓縮對話，就可以釋放一些浪費的 token 。

最終製作完成的網站，我會 Push 到 GitHub 的 Repo， 再由 repo 觸發 Vercel 來佈署網站。這一步每個人作法略有不同，這是我比較順手的作法。

這份作品集網站的 3 個設計重點

這個作品集網站是我用自己的工作流程重新設計的一套輕量內容管理系統。

對我來說，作品集網站不只是靜態展示作品的地方，也應該是一個可以長期維護、快速更新、降低溝通漏接風險的個人品牌基礎設施。

1. 直接使用 Notion 作為 CMS

這個網站沒有另外導入Headless CMS，而是直接使用 Notion Database 作為內容管理後台。如果你和我一樣是 Notion 使用者，可能也會喜歡這套模式。

未來如果我要新增作品、撰寫文章、整理素材，不需要進入傳統網站後台，只要在 Notion 裡新增或更新資料，網站就能讀取對應內容。

技術上，網站透過 lib/notion.ts 與 Notion API 溝通，將 Notion Database 裡的資料轉換成網站可以直接使用的格式，例如作品標題、Slug、標籤、狀態、封面圖與內容資料。

網站也採用 ISR，也就是「靜態網站 + 定期更新」的架構。內容會以靜態頁面的方式提供良好效能，同時每 300 秒重新檢查一次內容是否更新，兼顧速度與維護彈性。

對 Notion 使用者來說，這是一個很實用的網站維護方式，內容仍然放在熟悉的 Notion 裡管理，但前台呈現可以保有完整客製化設計。

2. 自動將 Notion 圖片同步到 Supabase Storage

使用 Notion 作為 CMS 時，有一個很實際的問題要面對：Notion 上傳的圖片通常不是永久網址，而是有時效性的 signed URL。

如果網站直接使用 Notion 提供的圖片連結，圖片可能在一段時間後就會失效，造成網站出現破圖。

所以我額外設計了一套圖片同步機制：當網站讀取到 Notion 裡的圖片時，會將圖片下載下來，重新上傳到 Supabase Storage，轉換成網站可以長期使用的圖片網址。

也就是說：Notion 負責內容管理，Supabase Storage 負責圖片資產保存。

這樣既保留了 Notion 編輯內容的便利性，也避免了圖片連結失效的問題，讓作品集網站更適合長期維護。

3. 用 LINE@ 即時通知取代傳統 Email 通知

傳統網站的聯絡表單，通常會在訪客送出後寄一封 Email 給站主。

但對個人品牌經營者、自由接案者或小型團隊來說，Email 很容易被淹沒，也可能進入垃圾信件匣，導致重要合作機會被漏掉。

因此這個作品集網站將通知流程改成 LINE@ 即時推播。

當訪客填寫 Contact 或 Hire 表單後，後端會先驗證資料格式，接著將表單內容存入 Supabase，最後透過 LINE Messaging API 直接推播訊息到我的 LINE。如此一來，我就不用一直打開信箱，也能即時收到合作詢問，更貼近個人工作者的實際狀態。

台灣使用者與個人工作者最常使用 LINE，因此Line@很適合作為在地市場的即時通知工具。國外的創作者或開發者社群則可以考慮套用同樣的模式，改用 Telegram 或 Discord 來達成目標，根據真實使用情境來優化你的設計工作流程。

小彩蛋

我一直很喜歡在我設計的網站加入有趣的 404 頁面，這次當然也不例外。

持續優化前行的旅程

目前 Sui’s Portfolio 已經上線 Beta 試營運中。

Sui · Funkuki Studio

Designer & creator — Funkuki Studio

sui.funkuki.com

雖然還有一些內容需要持續修調與整理，但整體網站架構從規劃到完成，大約只花了一週左右的時間。對我來說，這是一種非常有效率、也很適合個人品牌經營者的製作方式。

從 2025 年開始，我製作網站的方式開始大量採用 AI 協作。

不過在這個過程中，我也聽到一些 UI 設計師朋友分享他們的困惑：AI 協作的痛點，反而在於「不知道如何跟 AI 溝通」。

過去使用 WordPress、Framer 或 Wix 時，設計師可以直接點選畫面上的元件，修改文字、調整排版、替換圖片。

但現在透過 AI 協作開發網站，很多時候需要一句一句地說明：「哪裡有錯字」、「哪個區塊要調整」、「這個功能應該怎麼改」、「這個元件的狀態不對」。對習慣視覺化工具的人來說，這確實會讓人感覺不夠直覺。

但我認為，這比較像是工具轉換期的摩擦，而不是 AI 協作本身的缺點。

這有點像習慣手繪的人，剛開始接觸電繪時，會覺得圖層、筆刷、快捷鍵、遮色片都很麻煩。

可是當新的操作方式被內化之後，它就不再只是「比較麻煩的替代工具」，而會變成一種新的工作能力。

AI 協作也是如此。

它要求我們把原本藏在腦中的設計判斷，轉換成可以被理解、被執行、被驗證的語言。這意味著設計師不只是操作工具介面，而是要更清楚地描述自己的意圖：為什麼這裡要調整？什麼樣的狀態才算正確？使用者在這個流程中應該感受到什麼？

所以我不認為 AI 協作會讓設計師變得不需要設計能力。相反地，它會更放大設計師的判斷力，也會讓設計師回到設計的原始定義：解決問題。

對我來說更重要的是，AI 可以協助設計師更快完成頁面、元件與功能，但網站本身仍然需要被放回 User Journey 裡思考，必須回到 UX 原點，理解這個網站的目標受眾是誰、訪客會從哪裡進入、他們需要先理解什麼、接著會想看什麼、最後應該被引導到哪一個行動。

很近的未來，數位產品必須同時服務兩種受眾。表層是給人類看的情感化設計（視覺佈局、互動、品牌氛圍）；裡層則是給 AI 閱讀的結構化邏輯（極致的語意化 HTML、精準的標籤、清晰的狀態管理）。我們也會面臨除了理解人類受眾的UX之外，也需要考慮 AI Readable，如何設計元素讓 AI 更能從中萃取上下文，讓它不至於迷路或誤判，我想必然會是新的UX挑戰！