Gemini 3.5 Pro 上線日準備清單

這篇教你在 Gemini 3.5 Pro 上線日先把測試環境、API 金鑰和比對基準準備好。

如果你要在模型開放後立刻驗證長上下文、寫碼表現和 agent 流程，這份操作指南可以直接照做。

做完之後，你會拿到一個獨立測試專案、一支可跑的請求腳本、可重複的評測清單，還有一份方便和現有模型對照的結果紀錄。

開始之前

• Google Cloud 帳號，且已啟用計費
• 可查看 Gemini API 文件
• Google Cloud Console 中的一個專案
• 已開通的 Gemini API 金鑰
• Node 20+ 或 Python 3.11+
• Git 2.40+
• 一份小型程式碼庫或文件集，供長上下文測試使用
• 可選：Google Gemini GitHub repos 與範例應用

Step 1: 建立 Gemini 測試專案

目的：把上線日測試和正式流量分開，避免權限、配額與日誌互相干擾。

在 Google Cloud Console 建立或選取一個專案，然後為這個專案啟用 Gemini API。若你的團隊有獨立計費或 IAM 規則，請直接新建一個測試專案，不要沿用正式環境。

gcloud config set project YOUR_PROJECT_ID
# 接著在 Console 或你們核准的流程中啟用 Gemini API

你應該看到這個專案的 Gemini API 狀態變成已啟用，而且團隊一看就知道這是拿來做模型評估的專案。

Step 2: 產生 API 金鑰

目的：先拿到可用憑證，讓模型一開放就能立刻送出請求。

透過 Google AI Studio 或你們核准的 Google Cloud 流程建立 API 金鑰，然後把它存成本機環境變數。金鑰不要寫進原始碼，若政策要求，測完後記得輪替。

export GEMINI_API_KEY="your_api_key_here"

你應該能在本機確認這個環境變數已存在，並且在跑任何請求之前就完成設定。

Step 3: 建立最小請求腳本

目的：先驗證你的 client 可以送出提示詞並收到回應，不先碰複雜流程。

先用一支短腳本送出單一提示詞，觀察回應格式、延遲，以及是否出現安全性或配額錯誤。先保持提示詞簡單，等連線穩定後再切到寫碼與推理測試。

import os
from google import genai

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
response = client.models.generate_content(
    model="gemini-3.5-pro",
    contents="Summarize this repository structure in three bullets."
)
print(response.text)

你應該看到一段純文字答案順利回傳，且沒有驗證錯誤，這代表 client 和金鑰都已經可用。

Step 4: 載入長上下文樣本

目的：用真實工作負載測試長上下文，而不是只丟一個玩具提示詞。

準備一份長輸入，例如多檔案程式庫、大型技術手冊，或一組產品文件。接著要求模型做跨檔摘要、依賴關係整理，或需要引用遠處內容的變更計畫。

例如，請它找出所有碰到驗證的函式，再說明改動其中一個檔案會如何影響其他部分。若模型能在大輸入中維持一致參照，這就是長上下文能力的明確信號。

你應該看到模型能引用輸入中相隔很遠的細節，而且不會丟失主線，這才算完成這一步的驗收。

Step 5: 比對寫碼與 Deep Think 表現

目的：把模型的寫碼品質與多步推理，和你目前的基準版本放在一起看。

準備三種提示詞：一個重構任務、一個修 bug 任務，還有一個需要非平凡推理鏈的問題。分別評分正確率、修改幅度，以及模型在需求不明確時主動追問的次數。

把同一組提示詞送到你現在使用的模型和 Gemini 3.5 Pro，然後並排比較結果。若你有 agent 工具或 CLI 自動化，也加入一個需要讀檔、產生 patch、最後驗證的任務。

你應該看到多檔案修改更乾淨、錯誤假設更少，而且步驟式推理更穩定，這才算完成這一步的驗收。

Step 6: 鎖定上線日評測基準

目的：把測試集和結果固定下來，方便團隊在初次上線波動後持續追蹤。

把提示詞、預期輸出、延遲數值和失敗案例存進共享文件或 repo。也要記錄提示詞長度、上下文大小，以及這次測試是純聊天、程式生成，還是工具呼叫。

在正式上線後的前幾天再跑一次同樣的測試，因為早期可用性常會隨配額、路由和模型版本穩定而變動。

你應該最後得到一份可重跑的基準，讓團隊之後比較新版本時，不必重新設計整個測試流程。

常見錯誤

• 拿正式專案直接做第一次測試。修法：另外建一個 sandbox 專案，分開計費、日誌和配額。
• 只測短提示詞。修法：加上一個長上下文任務，確認模型的遠距記憶與檢索行為。
• 沒有基準就直接比輸出。修法：所有模型共用同一組提示詞，並把結果存到共享評測檔。

接下來可以看什麼

等 Gemini 3.5 Pro 上線後，可以把這份流程擴成結構化 eval、agent 工作流和團隊專用寫碼測試，進一步決定它在你的技術堆疊裡的位置。