AI 如何串聯部署與配置

這正是 vibe coding 大放異彩的地方。部署配置恰恰是那種精確、文件完善、充滿樣板程式碼的工作，AI 擅長此道。你來指揮；它來編寫。

有效的提示聽起來像這樣：

• "為這個 Node 應用新增一個 Dockerfile，以及一個用來部署它的 Railway 配置。"
• "寫一個 GitHub Actions 工作流，在每次推送到 main 時把 dist/ 資料夾部署到 Cloudflare Pages。"
• "我的無伺服器函式遇到了冷啟動超時——可能哪裡出了問題，我該怎麼修復配置？"

下面是 AI 會為你生成的那類檔案——一個部署工作流，每當你推送程式碼時就自動釋出一個靜態網站：

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci && npm run build
      - name: Publish to Cloudflare Pages
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CF_API_TOKEN }}
          command: pages deploy dist --project-name=my-app

你不需要背下這個語法。你需要認出它做了什麼：在每次推送到 main 時，它檢出你的程式碼，構建它，併發布結果。當出問題時，你把錯誤貼上回給 AI，讓它修復配置。

很多構建者一開始乾脆跳過 GitHub Actions 檔案，直接在自己的終端裡用一條命令部署。要在第一天就看到東西上線，這往往是最快的路。同樣的 Cloudflare Pages 部署，從命令列看是這樣：

# install the CLI once
npm install -g wrangler

# build your site, then push the output folder live
npm run build
wrangler pages deploy dist --project-name=my-app

第一次執行會讓你通過瀏覽器登入；之後就是一條命令的事。取捨很簡單：終端命令適合"現在就發"，GitHub Actions 檔案適合"永遠自動地發"。大多數專案從前者開始，等部署成了家常便飯再加上後者。看你處在哪個階段，就讓 AI 給你那個合適的。

幾條能省下真切痛苦的指揮技巧：

• 讓 AI 先解釋再行動。 "在寫配置之前，告訴我哪種託管型別適合這個專案，以及為什麼。" 這能及早抓住過度工程。
• 讓金鑰遠離程式碼。 API key 和密碼要放進平臺的環境變數／金鑰儲存中，絕不要放進你提交的檔案裡。讓 AI 使用一個金鑰引用，就像上面的 CF_API_TOKEN 那樣。
• 儘早部署，頻繁部署。 在第一天就讓一個"hello world"上線。一條從一開始就在執行的流水線，比一條在釋出時才拼湊起來的流水線要好除錯得多。
• 提前問清楚回滾的辦法。 "如果這次部署壞了，我怎麼回到能用的那個版本？" 好的平臺會把你之前的部署放在一鍵之遙。在你需要之前就知道有撤銷按鈕，能把凌晨兩點的恐慌變成一個聳肩。