專案 · 產品改造
傳統 WordPress 網站改造
以 AI 團隊協作、驗收與遷移決策推進網站與內容架構改造。
這個專案在做什麼
Gwarket 的網站改造不是一次換版，而是三段相連的工作：先處理 WordPress 與前端架構，再重整內容分類和閱讀介面，最後把沉浸式頁面移進正式技術架構。AI 加快了研究、設計和實作，但需求取捨、風險判斷與最後驗收仍由人負責。
如果只把 AI 當產生器畫面很快改完，責任卻混在一起
設計建議、工程限制與發布判斷都藏在同一段對話，出了問題很難追查。
這次採用的方式不同 AI 各自負責一層，人做最後整合
策略、視覺與實作分開，所有輸出仍要通過瀏覽器、路由、效能與回滾檢查。
三次改造，各自解決不同問題
從 WordPress 頁面轉向 Next.js
一天內完成 14 項變更，保留既有網址並用 Lighthouse 追查效能回歸。
重整首頁、導覽與 85 篇文章分類
AI 分擔策略、視覺與程式工作；Aaron 負責跨角色翻譯、編輯與最後決定。
把沉浸式頁面移入正式前端
同時處理桌機與手機、SEO 可讀內容、素材壓縮、路由與回滾。
PM問題與範圍定義要改善的體驗、不能破壞的路由和驗收條件。
Design視覺方向在不讀程式碼的情況下提出介面與互動建議。
Code工程實作把設計轉成可執行頁面，處理效能和技術限制。
Aaron整合與驗收區分建議與契約，決定取捨並在真實瀏覽器確認。
可以直接回查的改造結果
文章重新分類到 4 個主題與 4 個系列，79 個標籤完成清理。
導覽項目由 4 個縮成 2 個，並補上手機選單遷移過程曾從 88 回落到 74，再修正回 88。
保留回歸過程，不只展示最後分數圖片由 13.3 MB 壓到 1.5 MB；兩支影片也分別降到 4.5 MB 與 1.75 MB。
網址維持不變，頁面 SEO 稽核達 100驗收盲點自動檢查看到什麼最後怎麼發現
影片檔案存在、編碼資訊正常真實瀏覽器播放才發現問題
來源素材可載入人工回查才確認檔案是否來自正確版本
字級CSS 數值符合設計最後發現差異其實來自瀏覽器縮放
AI 加速之後，人仍要負責什麼
把策略、設計與實作隔離
每個角色只處理自己需要的背景，降低單一 AI 同時扮演所有角色造成的盲點。
保留網址與回滾路徑
改造不是只看新畫面；舊連結、部署紀錄和撤回方案都屬於交付。
效能回歸必須被看見
分數從 88 掉到 74 時不掩蓋，而是回頭定位哪個變更造成退步。
自動驗收後仍進真實瀏覽器
影片、來源和視覺感受不是所有自動工具都能判斷，最後需要人實際操作。