前端工程師：建置工具與部署管線

這行的痛點

前端工程師的時間表裡，有一大塊從來不是「寫新功能」，而是「讓寫功能這件事本身能繼續運作」——升級卡住的建置工具、拆分越滾越肥的 CI YAML、修一個因為版本不合就整條管線紅燈的 pipeline。這類工作有個共同特徵：範圍明確、驗證標準清楚（build 過不過、測試綠不綠、Lighthouse 分數有沒有回升），卻又機械繁瑣到讓人提不起勁。這正是 CLI AI 最不容易失手的一塊——比起要它判斷「這個介面好不好看」，「這段程式碼有沒有照著遷移指南改完」是可以被機器驗證的問題。

本章的兩個子題其實是同一塊工程債的正反兩面。建置工具端（Vite / Webpack / Turborepo / Monorepo）處理的是「工具鏈本身老化」——CRA 已經不是官方推薦、多個 package 各管各的型別定義、大型測試套件卡在舊版 API 改不動。部署管線端（CI/CD）處理的則是「管線本身要能自我維持」——從零生成一條 lint→test→build→部署的流水線，以及管線紅燈之後怎麼收斂而不是靠人肉盯著。兩者共用同一套心法：先把規則寫成 CLAUDE.md/AGENTS.md 讓 AI 有依據可循，再用「小步、每步都跑機械驗證」把風險鎖住，絕不整批丟給全自動模式賭運氣。

場景一、二示範建置工具這一側的大規模改造——一個是 970 個測試檔案的框架版本遷移，一個是建置工具本身的替換；場景三、四則切到部署管線這一側——一個是從 CLAUDE.md 規則生出整條 CI/CD pipeline，一個是管線紅燈之後怎麼讓 AI 自己查、自己修、自己驗證。四個場景合起來，才是「建置與部署」這個工作面向真正的全貌：不只是把工具設定好，還要讓它在專案演進過程中持續能跑。

動手前的準備

• 先看 Claude Code 教學第 1 章「踏出第一步：打開終端機」，把安裝、基本操作與權限模式搞定；若你是 Codex CLI 陣營，對應看 Codex CLI 教學第 1 章。
• 先看 Claude Code 教學第 5 章「CLAUDE.md 與工作記憶」——本章幾乎每個場景都靠 CLAUDE.md（Codex CLI 對應 AGENTS.md）先立規則，AI 才不會用猜的。
• 手邊要有一個真的能跑 npm run build / npm test 的專案，本章所有場景都靠 build 過、測試綠、E2E 過這三道機械驗證收斂——沒有可驗證的基線，就無法判斷 AI 改得對不對。
• 若要跑場景三、四的 GitHub Actions 案例，先確認對目標儲存庫有 admin 權限（安裝 GitHub App、加 repo secrets 都需要）。
• 大規模遷移（場景一）動工前，先確認版本控制乾淨（git status 無殘留改動），建議搭配 git worktree 或獨立分支，方便隨時回滾。
• 熟悉 pnpm / turbo 這類 monorepo 工具的基本指令會有幫助，但不是必要——本章場景會直接給可複製的設定片段。

場景一：970 檔測試大遷移

Filestage 團隊要把 970 個測試檔案、超過 6000 個測試用例，從 React Testing Library（RTL）v13 遷移到 v14——v14 把所有 API 都改成非同步，連帶時序行為整個變了。這種規模的遷移，手動改光是抓錯誤訊息就能耗掉一整個 sprint，而且改壞的風險極高：每改一個測試檔案就得重新確認行為沒有跑掉。

Claude Code 怎麼做

1. 1

   先讓 Claude Code 讀官方 migration guide 及專案現況，產出一份團隊自己的 migration guide markdown——過程中這份文件從 4,532 字擴充到 7,517 字，等於先把遷移知識蒸餾成一份可查閱的文件，而不是每次遷移都重新摸索一次。

2. 2

   package.json 讓 v13、v14 版本共存，避免一次性大爆炸式衝突。

3. 3

   用 jscodeshift 把程式碼解析成 AST，讓 Claude Code 協助撰寫 codemod 把機械性改動自動化——codemod 本身也是逐步養大的（從 271 行成長到 992 行，測試案例從 1 個到 14 個），不是一次寫死交出去。

4. 4

   實際下指令時明確要求分批處理與硬性護欄：

   用 jscodeshift 讀取 tests/**/*.test.tsx，套用 rtl-v13-to-v14.codemod.js 進行轉換。
   每處理 10 個檔案為一批：先跑 codemod → 跑 eslint --fix 修排版 →
   跑該批次單元測試 → 確認覆蓋率沒有下降，再繼續下一批。
   過程中禁止修改任何非測試檔案（src/ 下的正式程式碼一律不能動）。

   複製
5. 5

   拆成 50 個 PR 逐批合併，每個 PR 約 30 分鐘完成審查——批次夠小，審查者才有辦法真的看懂每一次改動，整週完成原本可能要拖上數週的遷移。

換成 Codex CLI

npx codemod ai 官方明確表示這套流程設計上同時支援 Cursor、Claude Code、OpenCode、Antigravity 等 agent，透過 MCP 工具讓任何相容的 coding agent 都能在對話中查 AST dump、跑 codemod 測試取得紅綠回饋——所以這條 workflow 理論上對 Codex CLI 同樣適用，只是目前找到的實測敘事以 Claude Code 為主，沒有看到 Codex CLI 版本的 970 檔案遷移紀錄可以拿來對照。

場景二：Vite 建置遷移實測

某專案用 Create React App 加 craco 客製化設定，建置時間拖到約 10 秒，npm audit 還跑出 17 個高風險漏洞。團隊想換成 Vite，但心裡沒底——工作量估不出來，而且 Jest、ESLint、Tailwind、Chromatic 這些周邊工具鏈全部要跟著調整，牽一髮動全身。

Claude Code 怎麼做

1. 1

   給 Claude 的 prompt 就是作者實測用的這句原文：

   prepare a plan with effort to migrate the setup used in this project with craco
   by one that is more modern with vite

   複製
2. 2

   Claude 分析 repo 後產出一份含工作量估計的分步 migration plan markdown 檔，作為整個遷移過程的參考指南——先有全局藍圖，而不是邊做邊想。

3. 3

   採增量遷移，每個步驟後都跑三組驗證：npm run build、npm test（Jest）、npx cypress run（E2E）——任何一步紅燈就停下來，不往下一步硬推。

4. 4

   七個階段依序推進：建置工具替換 → Jest 設定調整 → ESLint 現代化 → Tailwind 修復 → 覆蓋率工具轉換 → Chromatic 處理 → 安全性修復。

成效（作者在 M2 MacBook Pro 上實測，3 次取平均）：建置時間從約 10 秒降到約 3 秒（約 70% 加速），安全漏洞從 17 個高風險降到 4 個低風險，最終 154 個模組能在 1.63 秒內編譯完成。

換成 Codex CLI

沒有找到同一個專案的 Codex CLI 版本可以直接對照；但另一篇談 Codex CLI 前端設定的文章提到，若專案沒有明確的 AGENTS.md，Codex CLI 對「該用哪套建置工具（Vite/Next.js/Remix）」也會用猜的，而且常猜錯——這跟「沒有 CLAUDE.md 時 Claude 生成的 Vite 設定會用錯套件、破壞 HMR、硬編碼路徑」是同一類問題，兩邊都得先靠專案層的規範檔案（CLAUDE.md / AGENTS.md）把技術堆疊寫清楚才能解決。

場景三：CI 管線一鍵生成

前端工程師面對 GitHub Actions 陡峭的學習曲線——YAML 語法、job 依賴關係、金鑰管理、藍綠部署，作者估計手動從零搭建整套 pipeline 要花約 13 小時，多數團隊因此長期擱置，繼續用手改到能動就好的舊管線。

Claude Code 怎麼做

1. 1

   先在 CLAUDE.md 定義規則：分支策略（禁止直推 main，一律走 PR）、pipeline 階段順序（lint→test→build→deploy）、測試覆蓋率門檻（最低 80%）、健康檢查端點規格（GET /health → 200）。

2. 2

   用一句話請它生成 CI workflow：

   生成 Node.js 應用的 GitHub Actions CI workflow，
   含 lint、test、build 三階段，Node 20.x，啟用 npm 快取，
   並依 CLAUDE.md 的覆蓋率門檻規則加一道覆蓋率檢查。

   複製

   產出的 .github/workflows/ci.yml 含 ESLint/Prettier、Jest 覆蓋率報告，並用一段 Node 腳本讀 coverage-summary.json 做覆蓋率門檻判斷（低於 80% 就 process.exit(1) 讓 job 失敗）。

3. 3

   加一個 PR 自動貼覆蓋率比較留言的 job：比較 base branch 覆蓋率，覆蓋率下降就顯示警示符號，並更新既有 PR 留言而非每次重複建立新留言。

4. 4

   最後生成藍綠部署 workflow：建 Docker image→部署到 Green 環境（port 3001）→健康檢查（10 次重試、間隔 5 秒 curl /health）→成功則改 nginx 設定的 port 並 reload 切流量→失敗自動停掉 green 容器回滾→Slack 通知成敗兩種結果。

成效（實測前後對照）：

換成 Codex CLI

這個「CLAUDE.md 規則驅動生成整套 pipeline」的實測案例，目前沒有找到對應的 Codex CLI 版本文章；Codex 官方文件強調的是同一種「透過 AGENTS.md 提供上下文」的做法，概念上是同構的，但語料裡沒看到針對前端藍綠部署場景的具體 Codex CLI 案例——這段對照屬於「延伸自通用用法」，不是直接查證到的實測。

換成 GitHub Copilot CLI

這個場景換成 GitHub Copilot CLI，最大差異不是「會不會寫 YAML」，而是它本來就是 GitHub 自家 CLI——跟 GitHub Actions、PR、Issues 的整合是原生內建，不用像 Claude Code、Codex CLI 那樣得自己額外接一個 GitHub MCP server。官方文件逐字：「The GitHub MCP server is built into Copilot CLI and is already available without any additional configuration.」而且預設所有唯讀工具（讀 PR、讀 commit、讀 issue）就是開的。這代表本場景第 3 步「PR 自動貼覆蓋率比較留言」這類要讀寫 GitHub 物件的 job，Copilot CLI 開箱就能動手，不用先想辦法把 GitHub API 接進 agent 的工具箱。

在 workflow 裡呼叫 copilot，官方給了兩條認證路徑。較省事的一條不用另外申請、保管 PAT，直接用 Actions 內建、範圍已收斂的 GITHUB_TOKEN，只要在 workflow 的 permissions 區塊多加一個新 scope：

permissions:
  contents: read
  copilot-requests: write   # 官方新增的 scope，讓 workflow 可以發 Copilot 請求

steps:
  - uses: actions/checkout@v6
  - name: Install Copilot CLI
    run: npm install -g @github/copilot
  - name: Run Copilot
    run: copilot --yolo -p "Summarize the changes in this commit"
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

組織層還要先由管理員在 Copilot CLI policy 開啟「Allow use of Copilot CLI billed to the organization」，這條路徑才能用。另一條路徑是申請帶「Copilot Requests」這個新 PAT scope 的 token，存成 COPILOT_GITHUB_TOKEN secret——權限模型更細，但多一道金鑰簽發與保管手續；組織自己的 repo 想省事，官方文件建議優先走 GITHUB_TOKEN + copilot-requests: write 這條路。範例裡的 --yolo（等同 --allow-all）不是圖方便亂開，官方逐字說明這是非互動環境的必要設定：「suppresses interactive prompts, which is required for non-interactive environments like GitHub Actions.」

但官方同時給了明確的安全警語：直接在 workflow step 裡跑 copilot，等於讓它拿到整個 workflow 環境的廣泛存取權，其中「由 fork 送出的 PR 觸發」這類情境風險最高——外部人開的 PR 若能觸發帶寫入權限的 CI，就有機會碰到帶金鑰的執行環境。官方給的正解不是「小心用」，而是建議改用另一個產品：GitHub Agentic Workflows，一個用 Markdown 寫 CI workflow 的獨立框架，預設 read-only、寫入操作一律要走宣告在 frontmatter 裡的 safe-outputs 驗證，且 engine 欄位官方支援 copilot／claude／codex／gemini 四選一，不是 Copilot CLI 綁死的專屬功能。這個框架目前仍在 Technical Preview，格式可能還會變動，真要採用前務必重新查最新文件。

本場景實測的「手動約 13 小時 vs Claude Code 約 20 分鐘」這組數字，目前查證範圍內沒有找到同一個前端專案的 Copilot CLI 版本可以直接對照；以上是延伸自官方 GitHub Actions 整合文件的機制說明，不是查證到的實測時間數字，不能當成等價的成效基準。

場景四：CI 紅燈自動修復

前端工程師開了一張 PR，CI 卻因為一個 flaky test 或 lint 錯誤卡住紅燈，人已經下班或在開別的會，回來才發現要自己重新查 log、重跑、推修正——每一次紅燈都是一次 context 切換成本。

Claude Code 怎麼做

1. 1

   手動／本地版做法（Chris Dzombak 於 2025 年 10 月的實測）：在 Claude Code 互動 session 直接下這句 prompt：

   CI is failing on main. Figure out why, fix it, commit & push,
   and monitor to be sure your fix worked.

   複製

   Claude 透過 GitHub MCP server 查失敗的 workflow run、在本地跑 linter/build 重現問題、修復、commit&push，再輪詢 CI 狀態直到綠燈——但每一步仍會請求使用者授權，不是無人值守。作者建議搭配 git worktree 建立獨立 checkout，避免 Claude 在 CI 執行期間佔用你正在用的工作目錄。

2. 2

   雲端版做法（Anthropic 官方 Cloud Auto-Fix 功能，Auto Mode 於 2026 年 3 月 24 日上線、Cloud Auto-Fix 於 3 月 26 日上線）：在 Claude Code Web/Mobile 的 PR 視圖打開開關，或在終端機 session 下 /autofix-pr（會自動推斷目前分支對應的 PR 並開始監看）。

   Claude 訂閱該 PR 的 GitHub events：CI 失敗時讀錯誤、調查、推 commit 修復並附說明；收到明確的 review comment 時直接改動、推送、回覆討論串；模糊回饋則先追問；架構決策或有爭議的意見則上報人工。

3. 3

   限制要先知道：Auto-Fix 可以推 commit 到 PR 分支，但預設不會推到受保護分支（main/master 或設了 branch protection 的分支），也不會自動 merge 除非明確設定。

成效：這塊目前沒有 Anthropic 官方公布的精確量化數字；文章引用競品 Cursor Bugbot Autofix 的 78% 問題解決率（其中 35% 變更直接合併），並提到 Codex 對標約 45%——但這組百分比來自 paddo.dev 對社群/競品資料的引用整理，不是 Anthropic 官方公布的 Cloud Auto-Fix 數字，需要標註來源不確定性，不能當成 Claude Code 自身的成效基準。

換成 Codex CLI

OpenAI Cookbook 提供對等的「Auto-Fix on Failure」模式：用 workflow_run 事件監聽既有 CI workflow 的 conclusion == 'failure'，觸發 openai/codex-action 以 sandbox_mode="workspace-write" 執行，prompt 明確要求「找出讓所有測試通過所需的最小改動，只實作那個改動，然後停手」——強調最小修改、禁止順道重構。官方範例場景設定在 Node.js monorepo + Jest，沒有看到前端框架專屬的實測案例。

常踩的坑

延伸資源

• AI Library Migration Guide — Filestage RTL v13→v14 遷移實錄
• Migrating from craco to Vite（M2 實測前後數字）
• CI/CD Pipeline Design with Claude Code: GitHub Actions from Zero to Deploy
• Ask Claude Code to fix CI（Chris Dzombak 本地版 Auto-Fix 實測）
• Claude Code 大型程式碼庫官方設定文件（Context Scoping / CLAUDE.md 階層）