GitHub Copilot CLI 安裝完之後，下一題通常是：我到底要怎麼讓它真的幫忙？我建議先拿一個可以清楚驗收的小改動練習。這篇用「替既有網站加上聯絡按鈕」當教學情境，不是客戶成果案例，也不預設你的網站使用哪一套前端框架。
還沒完成安裝與登入，先回到GitHub Copilot CLI 基礎教學。已經能啟動的人，就從工作目錄和 Git 狀態開始。
開始之前，先確認什麼可以改
cd /path/to/your-project
git status --short
git switch -c feature/contact-button
copilot路徑要換成自己的專案。建立分支不等於備份資料庫，也不會自動隔離未提交的變更。如果 git status 已經有檔案，先看清楚是誰改的、是否與這次任務相關；不要叫 AI 清空狀態。GitHub 官方也提醒，信任目錄後，CLI 可能讀取、修改或執行該目錄下的檔案。
提示詞先寫驗收條件，不是只說做漂亮一點
先讀取專案規範與現有元件，不要修改。
我要在首頁既有主視覺下加入「預約諮詢」，沿用網站按鈕樣式。
目的網址用我提供的實際聯絡頁，不自行猜網址。
先列出要改的檔案、手機版排列與測試方式；不改導覽、套件版本及其他頁面。先等它回報，再確認實作範圍。只給「幫我加 CTA」，它可能重做整段主視覺；把位置、目的地、既有樣式與不能動的範圍寫清楚，返工通常比較少。請讓 AI 描述它在專案裡找到的元件，不要要求它憑空套用不存在的設計系統。
授權一次動作，不等於授權整個部署流程
修改檔案、執行命令及連線可能需要額外核准。核准前先看它要做什麼：執行既有測試與安裝新套件不是同一種風險，git commit 和 git push 也不是同一件事。不要為了少按幾次確認，就讓所有 shell 命令永久通行。
讓它先完成最小修改，再要求列出差異。如果需要加一個新套件才做得到，先問是否能用現有工具處理。這次練習的目的是完成聯絡入口，不是順便整理整個專案。
驗收網站：按鈕能看到，還要能到正確地方
| 檢查項目 | 要確認的結果 |
|---|---|
| 桌機 | 位置符合需求，不擋主視覺文字 |
| 手機 | 按鈕不超出畫面，文字不被截斷 |
| 滑過與鍵盤 | 文字和圖示都有足夠對比，焦點可見 |
| 導流目的 | 開啟實際聯絡頁，不是空連結 |
| 專案檢查 | 使用專案既有測試與建置指令，不捏造通過結果 |
要求 AI 回報測試命令、結果與沒有測到的部分。沒有測試腳本，就明講沒有；不要把「沒有出現錯誤」寫成完整測試通過。需要自動化瀏覽器驗收，可延伸閱讀Playwright 與 AI Agent 測試教學。
Git 提交只收這次要交付的檔案
git diff --stat
git diff
# 用實際檔案路徑取代下方範例
git add path/to/changed-file
git diff --cached
git commit -m "Add contact call to action"不要直接 git add . 把其他人未完成的變更一起包進去。提交後仍要看 git status；是否推送、合併及部署，需要另外決定。若只要求本地修改，就不該自動推上正式環境。
CIO Taiwan 的《2026 CIO Insight》整理了 623 位中大型企業 CIO 的調查。這類資料能提醒我們重視人機分工，但不能直接當成小公司採用 Copilot 的成效證明。我更看重的是：每次修改能不能說清楚改了什麼、如何驗收、怎麼回復。閱讀 CIO Taiwan 調查。
第一次做完，記錄提示詞、差異與驗收結果，下次就能沿用。如果你的目標不是單次修按鈕，而是建立團隊可以交接的網站工作流程，可以預約 AI 工作流程與網站導入諮詢。
