這個網站是怎麼做的？

這個網站本身就是第一個作品集項目。 它要回答的問題只有一個：一個 Design Engineer，如何把一份 Pencil 設計稿轉化為架構清楚、可維護的 React 前端實作？

以下記錄的不是功能清單，而是每個關鍵取捨背後的理由。 設計稿的數值怎麼被提取成 token、token 又怎麼約束元件、元件如何被分解、RWD 斷層如何劃定、瀏覽器相容問題如何面對、上線如何控制、設計如何被優化 —— 每一步其實都有取捨，而這個網站就是我把那些取捨實際做出來的結果。

想優化某處時，我習慣先用程式碼把概念做出來 —— 真實的互動與動態，只有跑起來才看得準，靜態稿騙不了手感。如果視覺還要再磨，才把那個局部丟回 Pencil，請它產出幾個方向的變體並列比較，必要時人工介入調整。定案後再回寫程式碼。Pencil 是探索與溝通的畫布，程式碼始終是唯一真實來源。

首頁「關於我」那顆展開按鈕 ↗就是這樣磨出來的：先有可運作的 read_more() 初稿，再用 Pencil 來回試 chip 尺寸、箭頭、hover 態與間距的變體，挑定後回寫 —— 設計與工程不是兩段交棒，而是在同一個開發迭代裡來回校準，把「能動、看起來對、可上線」收成一件事。

Hero section 是這個網站裡拆分邏輯最密集的地方。Hero.tsx不負責把所有畫面細節都渲染出來，它只做一件事：判斷目前要使用哪套版型，然後把內容交給對應的子元件。容器元件的責任是編排與分派，不是把所有視覺邏輯都收進自己身上。

桌機與手機的版型差異大到無法靠同一套 CSS 優雅處理。我的取捨是維護兩棵獨立的 render tree，讓子元件透過 variant 接收情境，各自處理自己的佈局。這會增加一些重複程式碼，但換來的是明確的責任邊界：子元件不用知道lg 斷點在哪裡，也不用在 children 裡藏一堆斷點判斷。

同樣的原則也用在 navbar 上。NavBarBase只保留 sticky 與毛玻璃外殼，各頁透過 children 注入自己的 inner row —— 共用外殼、各自決定列裡放什麼。這和 variant 是處理差異的一體兩面：variant 讓同一個元件依情境在內部分叉，children 則把會變的部分整個交給呼叫端。首頁與 case study 的 navbar 結構差異太大，硬抽成同一個元件反而會變成錯誤抽象。與其急著共用，不如先把差異看清楚，只抽出穩定、可共用、且不造成視覺差異的最小部分。這樣的 refactor 才是真的降低複雜度，而不是把複雜度藏進元件裡。

技術選型本身很單純：Next.js 16 App Router、TypeScript、Tailwind v4 與 Vercel。真正值得記錄的，不是用了哪些工具，而是上線後那些容易被忽略的細節怎麼處理。第一個例子，是 PDF 更新日期。

Vercel 部署時，git checkout 會重置檔案的 mtime，所以如果直接讀取 resume.pdf 的修改時間，production 上永遠會顯示部署當天，而不是履歷真正更新的時間。我的解法是在 next.config.ts 裡，於 build time 執行 git log -1 --format=%cd --date=format:%Y.%m，從 git commit 紀錄抓出 PDF 最後更新的月份，再注入成環境變數。這樣不管網站重新部署幾次，畫面上顯示的都會是那份 PDF 最後被更新的月份，而不是部署時間。

另一個細節是上線開關。正式網域 hire.lukelin.dev/* 前面先掛一層 Cloudflare Worker 作為 coming-soon gate：啟用時回應 503，並加上 noindex，避免搜尋引擎收錄半成品；停用時，流量就直接回到 Vercel，正式上線。這個做法讓上線切換不需要重新 build，也不需要重新部署。staging 的 vercel.app URL 不經 Cloudflare，仍然可以獨立驗收。