Jun Lin 作品集網站複盤｜AI BLOG

我想讓作品集網站撐得住海外找上門的商業開發機會，但舊版網站的架構已經不夠用，只能整個砍掉重練。這是一人 AI 協作開發的成果，從設計稿、內容資料到三語版上線，我自己從頭盯到尾。

成果速覽

繁體中文站 6 頁（含作品內頁與部落格列表）加部落格文章頁，英文、日文各 7 頁，另加三語 404 頁，全部在建置時期就先產生好；整站只有聯絡表單那支功能是即時運算的。
49 個修改紀錄，從 8 月 31 日開工到 9 月 3 日完成三語與流量分析上線，四天內做完。
三語站台沒有用網址轉寫或攔截規則，語言結構、禁用詞全部靠腳本機械檢查，不是靠人眼看過一遍。
部落格文章不是在這個網站上寫的，正本放在另一個筆記庫，靠一支同步腳本搬過來，網站這邊只負責顯示。
三個原本拍板「不做」的決定，後來全部因為情況改變而推翻，但推翻時刻意保留了原始判斷的文字，沒有直接刪掉重寫。

舊站砍掉重練

重建之前，舊版網站已經整個刪除，新版從設計稿、決策文件和內容資料檔重新開始。開工的規則很簡單：每次工作前先看任務清單，找出可以做的最小一件事，做完要留下能驗證的證據，不能只寫「完成了」就算數。這套流程跑了四天，一路做到正式上線，中間補了作品內頁、聯絡信箱調整，最後三天集中做完三語版和流量分析。

note技術細節：任務推進方式

任務編號從 T-01 到 T-48，共約 49 個 commit。開工前有三份文件打底：任務清單、設計決策記錄、技術架構決策記錄，外加內容資料檔。前段 T-01 到 T-16 是打地基，包含版控、頁面骨架、色彩字體、聯絡表單、SEO 基礎設施。

網站怎麼蓋出來的

網站頁面全部在建置的當下就先算好、存成固定檔案，訪客打開網頁看到的是現成頁面，不用等系統臨時運算。唯一的例外是聯絡表單，那是使用者按下送出的那一刻才真正執行的功能。這個限制是刻意選的：為了讓表單能用，就得放棄「整站完全不需要伺服器運算」這個更輕量的做法。

文案內容放在有固定格式規範的資料檔裡管理，不是散落各處的隨手字串，也沒有另外接一套內容管理系統，因為內容量不大、結構固定，資料檔就夠用。三語化之後，資料檔分成三份，繁體中文那份是基準結構，英文和日文版本只要少一個欄位、多一個欄位，寫程式階段就會直接報錯，不必等上線後才被讀者發現漏翻。

note技術細節：技術骨架與部署

用 Next.js App Router、TypeScript、Tailwind 建成，靜態預渲染搭配一支伺服器端的表單 API。部署走 GitHub 私有倉庫接 Vercel 自動部署，push 到主分支就直接更新正式環境，沒有額外的預覽保護關卡，這是本人明確接受的風險取捨。

三個「不做」後來都做了

一開始的架構文件白紙黑字寫著三件事不做：不做多語言版本、不開部落格頁面、不用 Google Analytics 這套外部流量追蹤工具。後來這三件事全部被推翻，不是原本判斷錯了，是外部情況變了。每次推翻，原始文字都用刪除線保留下來，不直接改寫，旁邊補一段說明為什麼變、誰決定、哪天決定。這有點像本來說好公寓不裝電梯，後來住戶變多了才回頭加裝，加裝的理由要記著，不是假裝一開始就打算裝。

graph TD
    A[一開始拍板不做] --> B[外部條件出現變化]
    B --> C[裁決推翻原決定]
    C --> D[保留原文加註記，不直接改寫]

多語言版本是因為海外的商業開發機會出現，受眾不再只有台灣的中文讀者，才加開英文和日文版本。繁體中文版網址完全沒動，讓既有的搜尋引擎收錄不受影響，英文和日文版本才加上路徑前綴。部落格頁面則是因為筆記庫那邊建了一條「筆記完成就自動發佈成文章」的管線，才重新打開這條路由，文章頁樣式刻意沿用原本作品內頁的視覺語言，沒有重新設計一套。流量分析則是因為海外機會，決定加掛 Google Analytics 和原本用的分析工具並存。

note技術細節：三個決定各自的取捨

多語系不用 rewrite、不用 middleware，語言版本在建置時就各自產生靜態頁面；英日文翻譯由 AI 產生草稿後直接上線，沒有人工審閱關卡，日文語感風險是已知並接受的。GA4 與 Vercel 內建分析並存，兩者都不做 cookie 同意橫幅，歐盟訪客未經同意就被追蹤的法規曝險是本人明確知情的決定。

部落格文章從哪來

網站上的部落格頁面自己不寫文章，內容正本放在另一個筆記庫專案，那邊有一整套潤稿與發佈的管線。網站這邊有一支同步腳本，像搬家公司一樣，把標記好要對外發佈的文章和圖片搬進網站的資料夾，同時整理出一份延伸閱讀的外部連結清單。搬進來的東西不能自己動手改，因為下一次同步會整個覆蓋掉，要改內容得回到筆記庫原地改，重跑管線再重新同步。同步腳本刻意不會自動推上正式環境，要人看過確認才提交，留住最後一道人工把關。

note技術細節：同步管線踩過的坑

建置設定檔曾經把整個內容資料夾排除在建置範圍外，導致文章本機能建置、上線卻整個消失，且沒有任何錯誤訊息，改成逐檔列出才修好。另一次是同步腳本寫入的檔案帶了 Windows 換行符號，導致摺疊區塊語法渲染失效、變回一般引用區塊，同樣不會報錯，得在渲染入口統一正規化換行符號才根治。這類問題共同點是「建置綠燈、畫面是壞的」，後續驗收都改成親自打開瀏覽器核對畫面。

表單設計反著寫

一般網站的聯絡表單如果寄信失敗，通常只在後台記一筆日誌，前端照樣告訴訪客「送出成功」，因為失敗只是次要的小狀況。這個網站沒有資料庫，那封信本身就是唯一的紀錄，如果寄信失敗還告訴訪客成功，找上門的人就會無聲無息地消失，我完全不會知道。所以這裡反過來，失敗時一定要讓訪客看到明確的錯誤訊息，並且直接把電子信箱顯示出來，讓對方可以改用信箱聯絡。

note技術細節：如何驗證表單真的可靠

不另外搭測試端點做近似驗證，而是直接對正式站送一筆真實表單請求，走的是與訪客完全相同的路徑，包含刻意讓寄信金鑰失效，確認訪客真的會看到錯誤訊息而不是假成功畫面。

用詞這條線怎麼守住

對外文案有一套明確的用詞規則，理由是技術掌握度不宜說滿。這是一人與 AI 協作完成的作品，措辭上一律用「一人 AI 協作開發」，不寫成像是憑一己之力寫出所有程式碼；產業定位一律寫「遊戲產業」，不寫更精確但對求職觀感不利的產業全名。這套規則不只套在網站自己的文案上，連從筆記庫同步過來的部落格文章也要遵守。曾經有一次筆記庫那邊的潤稿管線因為範例用詞沒調好，讓好幾篇文章跑出規則裡禁用的字眼，後來在筆記庫那一側補了兩處防線才解決。

三語版上線後，這套規則也延伸到英文與日文版本，禁用詞清單用固定的比對規則寫死，由一支驗證腳本在每次三語驗收時機械掃描，不再只靠人工看過一遍。