前一篇講 Playwright 為什麼是 vibe coding 必學，重點是：AI agent 很會改程式，但改完要能打開瀏覽器驗證，不能只靠它自己說「已完成」。
這篇要接著講另一個更基本，但很多人反而忽略的工具：GitHub。
如果你開始用 Claude Code、Codex、Cursor、Copilot 這類工具做 vibe coding，我會建議你不要只把程式碼放在本機資料夾。AI 改得越快，你越需要 GitHub 幫你管理版本、任務、Pull Request、測試結果和回滾路線。
vibe coding 不是「讓 AI 隨便改」。比較好的做法是：讓 AI 在 GitHub 的流程裡改，讓每一次修改都有紀錄、有審查、有測試、有回頭路。
為什麼 AI 寫程式越快，越需要 GitHub？
以前自己寫程式，錯了大概知道剛剛改了哪裡。AI agent 不一樣，它可能一次改好幾個檔案，順手重構、順手改命名、順手調 CSS，甚至順手刪掉一段它以為沒用的程式。
這種時候，如果你沒有版本管理，很快就會進入一種尷尬狀態：
- 不知道 AI 到底改了哪些檔案。
- 不知道哪一版是還能正常運作的版本。
- 測試失敗時，不知道該回到哪裡。
- 改壞網站後，只能靠記憶慢慢復原。
- 多人協作時，大家互相覆蓋彼此的改動。
GitHub 在 vibe coding 裡的角色，不只是備份程式碼。它更像是一個「AI 修改紀錄中心」。你可以看 diff、開 branch、做 PR、跑 Actions、寫 issue、讓人審查，最後才決定要不要 merge。
GitHub 不是只給工程師看的，是 AI 工作流的控制台
很多中小企業主或 WordPress 站長聽到 GitHub，第一反應是：「那不是工程師才用的東西嗎？」
以前也許是。但在 AI agent 時代，你可以把 GitHub 想成三件事：
- 版本紀錄：每次 AI 改了什麼，都留下清楚 diff。
- 任務系統：用 Issue 記錄要修什麼、為什麼修、誰負責確認。
- 驗證流程：用 GitHub Actions 自動跑測試，避免錯誤直接上線。
如果說 Playwright 是 AI agent 的「眼睛」，GitHub 就是 AI agent 的「工作紀錄與審查流程」。兩個要一起用，才會比較穩。
vibe coding 必學 GitHub 觀念 1：branch 不要直接改 main
我知道很多人一開始用 GitHub，最直覺就是直接在 main branch 改。小專案也許還好，但一旦你讓 AI agent 開始改程式，這會很危險。
比較好的規則是：每個任務都開一個 branch。
git checkout -b ai/fix-contact-form
這個 branch 可以專門處理「修聯絡表單」。AI agent 在這個 branch 上改壞了，main 還是乾淨的。你要看 diff、跑測試、退回某個 commit，都比較安心。
我會建議 branch 命名簡單一點：
- `ai/fix-contact-form`
- `ai/add-playwright-tests`
- `ai/update-homepage-cta`
- `ai/refactor-wordpress-plugin`
你一看就知道這條分支是 AI 協助做什麼，不會過兩天完全忘記。
必學觀念 2：commit 是 AI 修改的時間點紀錄
很多人用 AI coding 會有一個壞習慣：讓 AI 一路改、一路改、一路改，最後才想起來要存版本。這樣很容易變成一大坨 commit，裡面混了 UI、後端、CSS、測試、文件，未來根本看不懂。
比較好的做法是：每完成一個清楚的小步驟，就 commit 一次。
git status
git diff
git add .
git commit -m "Fix contact form validation"
如果你是讓 AI agent 幫你做，我會要求它每次 commit 前先回報：
- 改了哪些檔案。
- 每個檔案為什麼改。
- 有沒有跑測試。
- 有沒有高風險變更。
這樣 commit 就不只是存檔，而是 AI 工作流的檢查點。
必學觀念 3：Pull Request 是 AI 改完後的審查門
GitHub 官方把 Pull Request 定位成提出合併程式碼變更的協作功能，可以在 merge 前討論與審查修改。這件事放到 AI coding 裡特別重要，因為 AI 改得快，但 merge 應該慢一點。
一個好的 AI PR，我會希望包含這些內容：
- 這次要解決什麼問題。
- AI 改了哪些範圍。
- 怎麼測試。
- Playwright 或單元測試結果。
- 有沒有截圖或 trace。
- 有哪些地方需要人特別看。
你可以請 AI agent 幫你產 PR description，但不要讓它寫一堆空話。PR 描述最好長這樣：
## 這次改什麼
- 修正聯絡表單手機版送出按鈕被遮住
- 新增 Playwright 測試確認 CTA 與表單欄位可見
## 驗證方式
- npm test
- npx playwright test tests/contact.spec.ts
## 需要人工確認
- 表單送出後的實際 Email 通知是否正常
這樣人類 reviewer 才看得懂，不會被 AI 的漂亮總結騙過去。
必學觀念 4：Issue 是讓 AI 不要亂改的任務邊界
AI agent 最怕的不是不會做，是太會自己延伸。你叫它修 A，它順手覺得 B 也可以改、C 也可以重構，最後整個範圍爆掉。
所以我會建議用 Issue 來定義任務邊界。
Issue 不用寫得很複雜，但至少要有：
- 問題描述：現在哪裡壞了？
- 預期結果：修好後應該長怎樣？
- 允許範圍：可以改哪些檔案或模組？
- 不要碰：哪些檔案、資料、設定不能動？
- 驗證方式：怎麼確認完成？
給 AI agent 的 Issue，不只是待辦事項，而是工作邊界。邊界越清楚，AI 越不容易亂跑。
必學觀念 5：GitHub Actions 是 AI 改完後的自動驗證員
GitHub Actions 是 GitHub 的 CI/CD 平台，可以自動跑 build、test、deploy。官方文件也提到，你可以建立 workflow 來測試每個 pull request，或在合併後部署到正式環境。
放到 vibe coding 裡，Actions 的用途很清楚：AI 改完，不是自己說了算，要讓測試說話。
例如一個很簡單的 Playwright workflow 可以長這樣：
name: E2E Tests
on:
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test
這樣每次 AI 開 PR，GitHub 就會自動跑 Playwright 測試。測試沒過，就不要 merge。這比你相信 AI 的自我報告可靠太多。
必學觀念 6：branch protection 保護正式版本
如果你的 repo 已經是正式專案，我會建議設定 branch protection。GitHub 的 protected branches 可以限制重要 branch 被刪除或 force push，也能要求 PR、review 或 status checks 通過後才能合併。
對 AI coding 來說，這很像安全護欄：
- AI 不能直接推壞 main。
- 測試沒過不能 merge。
- 至少要有人 review 才能進正式分支。
- 避免 force push 把重要歷史洗掉。
這些設定一開始看起來麻煩，但只要被 AI 改壞過一次，你就會覺得它很值得。
GitHub CLI：讓 AI agent 更容易跟 GitHub 合作
GitHub CLI，也就是 `gh`，可以讓你在終端機處理 PR、Issue、Actions 等工作。官方文件也把它定位成把 GitHub 功能帶到 terminal 的工具。
這對 AI agent 很重要，因為 Claude Code、Codex 這類工具本來就常在終端機裡工作。你可以讓它用 `gh` 做很多事：
gh issue list
gh issue view 12
gh pr create
gh pr checks
gh pr view --web
這樣 AI 不只是在本機改檔案，它可以讀 issue、建立 PR、看 CI 檢查結果，整個流程會更接近真正的工程協作。
我會怎麼設計一個 vibe coding GitHub 流程？
如果是我，我會把流程設計成這樣：
- 先開 Issue，寫清楚任務與限制。
- 從 Issue 建立 branch。
- 讓 AI agent 在 branch 上修改。
- 每完成一個小步驟就 commit。
- AI 寫或更新測試，至少包含 Playwright 關鍵流程。
- 本機測試通過後開 PR。
- GitHub Actions 自動跑測試。
- 人類 review PR diff、截圖、測試結果。
- 確認沒問題後 merge。
這其實就是我前面寫的 Loop Engineering 思路：AI 負責執行，但流程要有目標、狀態、驗證和停止條件。
GitHub 在這裡就是狀態與審查中心，Playwright 是畫面驗證，Actions 是自動檢查，Issue 是任務邊界，PR 是合併前的關卡。
WordPress 站長也需要 GitHub 嗎？
如果你只是單純寫文章，不一定。但如果你會改佈景主題、寫外掛、改 Elementor Custom Code、做自動化工具、串 API，我會建議一定要用 GitHub。
尤其現在 AI 可以幫你很快寫出 WordPress 外掛、REST API、短碼、Gutenberg block、前端互動。越快寫出來，越要有版本控管。你不會希望某一天網站出問題，才發現不知道 AI 上週到底改了什麼。
對 WordPress 專案來說，我會至少管理這些東西：
- 自訂外掛程式碼。
- 自訂佈景主題或 child theme。
- Elementor Custom Code 的備份。
- 部署腳本與 WP-CLI 指令。
- Playwright 測試。
- 重要文件與操作流程。
這樣 AI 可以幫你改，但每次修改都有跡可循。
我的結論：GitHub 是 vibe coding 的安全帶
很多人講 vibe coding，重點都放在「AI 幫我寫多快」。但我覺得真正能長期用的人，不會只追求快，而是會建立一套讓 AI 快、但不亂的流程。
GitHub 就是這套流程裡最基本的安全帶。
- Branch 讓 AI 不直接污染正式版本。
- Commit 讓每一步修改可以追蹤。
- Issue 讓任務有邊界。
- PR 讓修改可以被審查。
- Actions 讓測試自動跑。
- Branch protection 讓正式分支不被亂推。
AI agent 會越來越會寫程式。接下來差距不在誰會叫 AI，而在誰能把 AI 放進一套可控、可驗證、可回復的工程流程裡。
vibe coding 可以很快，但 GitHub 讓你快得比較有底氣。
常見問題 FAQ
vibe coding 為什麼需要 GitHub？
因為 AI agent 改程式很快，也很容易一次改多個檔案。GitHub 可以幫你留下版本紀錄、建立 branch、開 PR、跑測試和回滾修改，避免 AI 改壞後不知道怎麼找回穩定版本。
AI agent 可以直接改 main branch 嗎？
不建議。比較安全的做法是每個任務建立獨立 branch，讓 AI 在 branch 上修改，測試通過後再用 Pull Request 合併。正式專案最好搭配 branch protection，避免 main 被直接推壞。
Pull Request 對 AI coding 有什麼用？
Pull Request 是 AI 修改進入正式版本前的審查門。你可以在 PR 裡看 diff、測試結果、截圖、trace、討論紀錄與需要人工確認的地方，避免只看 AI 的文字總結就直接合併。
GitHub Actions 在 vibe coding 裡扮演什麼角色？
GitHub Actions 可以在 PR 或 push 時自動跑測試，例如單元測試、lint、build 或 Playwright E2E 測試。這讓 AI 改完程式後，不是自己說完成，而是由自動化測試先檢查一次。
WordPress 站長也要用 GitHub 嗎？
如果你只是寫文章，不一定。但如果你會改外掛、佈景主題、Elementor Custom Code、WP-CLI 腳本或 API 串接，我會建議用 GitHub 管版本。AI 協助開發越多，越需要知道每次到底改了什麼。
