Gemini Code Assist 上手：先把 AI 建議當成 Patch

課程概述

Gemini Code Assist 可以在 IDE 裡補程式、解釋既有邏輯、產生測試，也能用 Chat 討論一段修改。不過它最適合扮演的是「幫你準備候選 Patch 的協作者」，不是按一下就能替你負責的自動程式設計師。

這篇以 Gemini Code Assist Standard／Enterprise 為主。官方已在 2026 年 6 月 18 日停止讓 IDE 擴充套件和 Gemini CLI 服務個人版、Google AI Pro 與 Ultra tier，受影響的個人使用者要依最新文件評估遷移到 Antigravity；公司環境則要確認 Standard 或 Enterprise License、專案和 IAM 都已設定好。Standard／Enterprise 訂閱也已進入退場時程（官方說明，2026-10-12 查證）：2026 年 10 月 9 日起不能再新購，既有訂閱可用到合約期滿（年訂閱可自動續約到 2027 年 1 月 31 日，月訂閱到 2027 年 12 月 31 日）；官方說明之後的代理式程式開發輔助改由 Antigravity 提供，可透過符合資格的 Gemini Enterprise（原 Google Agentspace）訂閱或 Gemini Enterprise Agent Platform（原 Vertex AI）取得。Gemini Enterprise 版本比較表只在 Standard、Plus 與 Pay-as-you-go 三版列出 AI developer tools（Business 與 Frontline 沒有），且專案要連到月結（invoiced）的 Cloud Billing 帳戶。

你將學到

• 在支援的 IDE 中使用行內補全、Chat 與 Smart Actions
• 提供剛好夠用的專案脈絡，不把整包敏感資料一起送出
• 將模糊需求改寫成可驗收的 Prompt
• 逐行審查 AI 產生的 Patch、測試和設定檔
• 依變更風險決定要跑哪些檢查，什麼情況直接捨棄建議

目前支援哪些開發環境？

Gemini Code Assist Standard／Enterprise 支援 VS Code、JetBrains IDE、Cloud Shell Editor、Cloud Workstations 與 Android Studio。VS Code 和 JetBrains 需要安裝 Gemini Code Assist 擴充套件或 Plugin，並登入已取得 License、能存取指定 Google Cloud Project 的帳號。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

功能和快捷鍵會因 IDE、擴充版本與 Release channel 不同。Lab 畫面若和目前版本不一樣，先查 Extension 版本與官方文件，不要一直找一個已經改名的按鈕。

Prompt 不用長，但要能驗收

「幫我重構這段」的結果很難判斷好壞。可以改成：

把這個同步 TypeScript 函式改成 async，保留現有 public API；逾時 3 秒後要取消請求，不能重試 POST；請先列出修改計畫，再只回傳 Diff 和需要新增的測試案例。

一個好用的開發 Prompt 通常包含：

• 任務：要修 Bug、加功能、解釋還是產生測試
• 現況：相關檔案、介面、錯誤訊息和套件版本
• 限制：不能改的 API、效能、安全、相容性和 Style
• 驗收：輸入輸出、邊界案例與要通過的命令
• 輸出格式：先提計畫、只給 Diff，或逐項說明假設

先讀 Diff，再跑測試

AI 很會產生「看起來像真的」API、套件名稱和設定欄位。建議出現後，先逐行回答：我看得懂這段嗎？它有沒有偷偷改 public behavior？錯誤處理、併發、交易、權限和資源釋放是否合理？

接著再用工具檢查：

1. Format、Lint、Type check 和 Build
2. 既有測試、針對新行為的測試與回歸測試
3. Secret、Dependency、SAST 與 IaC Policy 掃描
4. API、套件版本和安全建議是否能在官方文件找到
5. 高風險變更由另一位熟悉該領域的人 Review

「AI 幫我寫了測試，而且測試有過」仍不夠，因為程式和測試可能一起誤解需求。先自己寫出驗收案例或從 Bug 重現開始，才能避免自我證明。

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 20, "rankSpacing": 28, "wrappingWidth": 600}}}%%
flowchart TB
  subgraph REQUEST_STAGE["1. 先把需求說清楚"]
      direction LR
      TASK["寫下任務、相關 Context<br/>限制與驗收條件"] --> SANITIZE{"Prompt 或檔案裡<br/>有 Secret、個資或無關內容嗎？"}
      SANITIZE -->|"有"| REMOVE["先移除、遮蔽<br/>或縮小提供範圍"]
      SANITIZE -->|"沒有"| GENERATE["請 Code Assist 提計畫<br/>再產生候選 Patch"]
      REMOVE --> GENERATE
  end
  GENERATE --> REVIEW
  subgraph REVIEW_STAGE["2. 人先讀懂，再交給工具"]
      direction LR
      REVIEW{"能逐行說明變更<br/>以及主要風險嗎？"} -->|"不能"| REJECT["捨棄或縮小 Patch<br/>不要憑感覺接受"]
      REVIEW -->|"可以"| CHECK["Format、Lint、型別、測試<br/>Secret、SAST 與依賴掃描"]
      CHECK --> PASS{"所有檢查和需求案例<br/>都真的通過嗎？"}
  end
  PASS -->|"否"| FIX["補 Context 或自行修改<br/>重新驗證，不硬湊綠燈"]
  PASS -->|"是"| RISK
  subgraph MERGE_STAGE["3. 依風險決定合併門檻"]
      direction LR
      RISK{"是否碰權限、金流、資料<br/>部署、密碼學或公開 API？"} -->|"是"| HUMAN["由領域 Reviewer 複核<br/>必要時先做小範圍驗證"]
      RISK -->|"否"| MERGE["合併並觀察 CI<br/>保留可回滾變更"]
      HUMAN --> MERGE
  end

實作重點

• 使用專案的 Node、Python、Java 或 Provider 版本，不要接受 Code Assist 自己假設的最新版
• 要求先列假設和修改計畫，能提早發現它理解錯檔案或選錯 API
• 產生單元測試時加入錯誤、空值、重複請求、逾時與權限拒絕，不只測 Happy path
• IDE Context 可能包含目前檔案、相鄰檔案與對話歷史；分享前先確認資料政策
• 若建議和公開程式碼高度相似，查看產品提供的 Source citation，再依授權政策處理；Agent mode 不會顯示來源引用，那裡產生的程式碼要自己查來源
• Agent mode 能呼叫工具，不代表應該給它無限制 Shell、雲端管理員或整個工作區權限

Lab 指引

Lab 連結：到 Google Skills 搜尋「Gemini Code Assist」相關 Lab

做 Lab 時別只追求接受建議的速度。至少挑一段生成程式碼，手動加入一個邊界測試，再故意給 Code Assist 一個不完整需求，觀察它會澄清、假設還是直接產生結果。這能更快理解工具真正需要人補上的地方。

延伸學習

• 組織層級設定 Gemini Code Assist — 管理 License、Project、Logging 與私有程式碼索引
• Gemini 輔助 DevOps 工程師 — 把候選 Patch 放進安全的 CI/CD 閘門
• Gemini API 動手做 — 用 API 自己控制模型輸入輸出
• Gemini Code Assist 官方概觀 — 確認目前 IDE、Edition 和功能狀態