用 AI 工具一天完成網站架構遷移：從管理者的決策框架實錄
用 Claude Code 在一天內完成 gwarket.com 從 WordPress + Elementor 到 Next.js SSG + headless CMS 的全站遷移，14 項改動、零 SEO 損失。這篇拆解的不是技術細節，而是驅動整個過程的決策框架 — 一套可以複製到任何「需求到落地」場景的管理邏輯。
當技術不再是瓶頸，企業落地的瓶頸變成什麼？
先講結論：是決策品質。
過去，企業要做一次網站架構遷移，流程大概是這樣：業務端提需求、PM 翻譯成規格、工程團隊排期開發、QA 測試、上線。中間的溝通成本、等待時間、來回修改，少則兩週，多則數月。
現在 AI 開發工具成熟到什麼程度？我用 Claude Code 作為主要開發工具，一天之內完成了 14 項改動，包含全站架構從 WordPress + Elementor 遷移到 Next.js SSG + WordPress headless CMS。這些改動對資深工程師來說是基本功，但重點從來不是技術多難 — 而是誰來做決策、怎麼排優先級、怎麼控制風險。
當 AI 把「寫 code」這件事的門檻大幅降低，企業內從需求到落地的瓶頸就從技術能力轉移到了決策能力。你要決定先做什麼、不做什麼、怎麼驗證做對了、出問題怎麼退回安全狀態。這些判斷，AI 不會替你做。
五個決策節點：從需求到落地的管理邏輯
以下是這次遷移過程中實際使用的五個決策框架。它們不是事後整理出來的方法論，而是在每個任務節點上即時做出的判斷。
影響面積決定順序，不是「重要性」
一天要處理 14 項改動，不可能全部同時推進。排序邏輯是兩個維度：影響範圍和時間壓力。
效能修復影響所有訪客，優先做。favicon 只是視覺 polish，排最後。Elementor 外掛停用有 4 月 1 日的訂閱續費 deadline，必須在那之前確認能安全移除，所以它的優先級高於 dark mode 這類功能性優化。
這跟產品開發的 prioritization 邏輯一樣 — 不是什麼重要做什麼，是什麼「現在不做會有損失」就先做什麼。管理者做資源配置時的思維模式，直接搬過來就能用。
大改動前永遠有退路
架構遷移最怕的不是做不出來，是做壞了退不回去。
每次大改動前，我做兩件事：跑 UpdraftPlus 完整備份，打一個 git tag 標記當前狀態。這樣任何改動出問題，能在幾分鐘內退回上一個已知正常的版本。
Elementor 的移除更謹慎。它分 Pro 版和免費版兩層，我不是一次全砍 — 先停用 Pro 版，確認前台所有頁面正常渲染，沒有排版崩壞，才停用免費版。分階段驗證，而不是一口氣賭運氣。
這個思路適用於任何高風險的系統變更：永遠確保你有退路，永遠用最小步幅前進。企業做數位轉型踩的最多坑，就是一口氣切換、出問題退不回來。
功能、效能、Polish — 三層不能跳著做
很多專案喜歡一開始就追求完美，結果核心功能還沒跑通就在調 UI 細節。順序應該是固定的：
第一層，功能正常。頁面能不能正確載入、資料有沒有正確渲染、路由有沒有通。第二層，效能達標。跑 Lighthouse 看分數，解決阻塞問題。第三層，視覺 polish。favicon、dark mode、微調排版。
這三層不能跳著做。功能還有 bug 就去調效能是浪費時間，因為 bug 修完效能數字可能完全不同。這跟企業推新產品的邏輯一樣 — 先確認核心價值成立，再優化體驗，最後打磨細節。
每個節點都驗證，不是最後才總驗收
每個任務完成後，我會跑一次 Lighthouse 或手動驗證。不是最後做一次總驗收，是每個節點都驗。
這次的 Lighthouse Performance 分數變化過程：66 → 88 → 74 → 84 → 88。
注意中間那個 74 — 分數從 88 掉回 74，代表某個改動引入了效能退步。如果我只在最後驗一次，看到的是「從 66 進步到 88」，一切順利。但因為每步都驗，我及時發現了退步，追查到原因並修正。
持續檢驗的價值不在於確認成功，而在於及時發現失敗。這個原則在軟體開發叫 CI/CD，在製造業叫品管節點，在管理上叫里程碑檢查 — 本質上是同一件事。
不猜原因，看數據；不找 workaround，修根因
三個實際案例：
Lighthouse 起始分數 66。看瀑布圖，發現 Google Fonts 的外部請求是渲染阻塞的主因。解法：改用 next/font 把字體內建到 build 產物中，消除外部請求。分數直接拉到 88。
分數從 88 掉到 74。檢查後發現一張 2560px 的原始圖片被直接當縮圖使用，瀏覽器要下載完整大圖再縮小顯示。解法：改用 WordPress API 回傳的 medium 尺寸縮圖，而非載入 2560px 原圖。
Deploy Hook 重複觸發。WordPress 更新文章時透過 Cloudflare Pages Deploy Hook 觸發自動 rebuild，但同一次更新觸發了兩次。解法：用 WordPress transient 機制加上防重複邏輯。
三個問題的共通模式：從現象找到數據，從數據定位根因，從根因設計解法。不是靠直覺猜，不是找 workaround 繞過去。Lighthouse 瀑布圖、Network tab、Cloudflare Pages build log — 工具都在那裡，關鍵是你知道要看什麼、怎麼解讀。這跟管理者看報表找問題是同一套思維。
一天的具體成果
列出來，讓數字說話：
- Lighthouse Performance：66 → 88，提升 33%
- Elementor 完整移除，省下 Pro 版訂閱費用，減少外掛依賴與安全風險
- 文章內頁遷移至 Next.js SSG，載入速度大幅提升
- 自動 rebuild pipeline，WordPress 發文後 webhook 觸發 Cloudflare Pages 自動 build，不需手動部署
- AdSense 廣告接入，廣告系統整合到新架構
- 專案頁標籤系統，內容分類與篩選功能上線
- SEO 零損失，遷移過程中沒有掉排名、沒有斷連結
14 項改動，全部在一個工作天內完成。主要工具是 Claude Code。
我的觀點
這次經驗讓我重新理解了一件事：AI 工具改變的不是「誰能寫 code」，而是「需求到落地的距離」。
傳統流程中，一個業務需求要經過 PM 轉譯、工程師開發、QA 驗證、來回溝通，最終才能上線。每一次轉手都有資訊損耗，每一次等待都有時間成本。當管理者能直接用 AI 工具把需求轉化為成品，省掉的不只是人力成本 — 是整個溝通鏈條的摩擦力。
但有一個容易被忽略的前提：AI 加速的是執行，不是判斷。你省掉的是寫 code 的時間，省不掉「該不該做」、「先做哪個」、「風險怎麼控」這些決策。事實上，當執行速度變快，決策品質的影響被放大了 — 錯誤的決策會更快地產出錯誤的結果。
對企業來說，這意味著一個結構性的轉變：過去瓶頸在技術資源，未來瓶頸在決策能力。能不能正確拆解需求、排出合理的優先級、設計驗證機制、控制變更風險 — 這些管理能力，會比「團隊裡有幾個工程師」更決定一個組織的交付效率。
我不認為這會取代工程師 — 複雜系統的架構設計、效能調優、安全性考量，仍然需要深厚的工程專業。但在「從需求到可用成品」這個區間，管理者直接用 AI 工具落地的可行性已經被驗證了。這不是未來式，是現在進行式。
常見問題 FAQ
不懂技術的管理者，真的能用 AI 工具做架構遷移嗎？
可以，但前提是你要有清楚的需求定義和決策框架。AI 處理的是「怎麼實作」，你負責的是「做什麼」和「先做哪個」。如果連需求都講不清楚，AI 也幫不了你。這次遷移能在一天內完成，不是因為技術簡單，是因為每個決策點都有明確的判斷標準。
這套決策框架可以用在網站開發以外的場景嗎？
完全可以。優先級判斷、風險管理、持續檢驗這些框架本質上是管理邏輯，不限於特定技術領域。任何「需求到落地」的過程都適用 — 產品開發、流程優化、系統導入都是同一套思路。差別只在於每個領域的驗證指標不同。
企業導入 AI 開發工具，第一步該做什麼？
不要從工具開始，從決策流程開始。很多企業買了 AI 工具卻用不起來，不是工具不行，是組織內沒有人能做「需求 → 優先級 → 驗證標準」這條鏈路的決策。先建立決策框架，再導入工具，效果會完全不同。
