前言

Day 02 結尾我留了一句話：

Day 03，再來正式玩 AI Studio。

今天就是要兌現這句話。

不過先講清楚，「玩 AI Studio」不代表要開始寫程式。今天從頭到尾都不會打開終端機，全部動作都在網頁上完成。

昨天搞懂了 Project、API Key、Quota 這條線，今天要搞懂的是另一件事：

要怎麼讓 Gemini 表現得像一個「懂事」的助理，而不是每次都要重新解釋一次規則？

答案是今天的主角：System Instructions。

一、先花五分鐘，把介面摸熟

打開 aistudio.google.com，進到 Chat 介面後，畫面大致分三塊：

圖 1｜AI Studio 的 Chat 介面與右側設定面板

右側面板平常很容易被忽略，但今天要用到的兩個功能都在這裡。

• 左邊：對話輸入區，跟一般聊天視窗一樣
• 右邊：模型設定面板，裡面藏著今天的兩個主角——System Instructions 跟 Temperature
• 上方：模型選擇（先固定用 Flash 系列就好，符合 Day 02 講的 Free Tier 邏輯）

在正式動手之前，我先問自己一個問題：

如果每次貼代碼進去都要重講一次「你是資深工程師，請幫我看代碼，用繁體中文回答」，那跟直接用 Google 搜尋有什麼不同？

這就是 System Instructions 存在的理由。

二、幫 Gemini 寫一份「人設」

System Instructions 跟平常打的訊息不一樣，它比較像是貼在 Gemini 額頭上的一張人設卡，設定好之後，不管接下來聊幾輪，它都會記得自己該扮演什麼角色。

對照規劃書裡 DevPulse 的定位——「不直接給答案，而是像資深導師一樣引導思考」——我把今天的第一版 System Instructions 寫成這樣：

你是一位有耐心的資深工程導師，負責審查使用者貼上的程式碼片段。

請用繁體中文，找出程式碼中可能存在的邏輯風險、安全性疑慮或邊界條件問題，
並向初學者解釋「為什麼」這是個問題。

除非使用者明確要求你直接給出修正後的完整程式碼，
否則請先用提示與引導的方式，讓使用者自己想清楚該怎麼修，
不要一開始就把答案整段寫出來。

圖 2｜把上面這段貼進右側的 System Instructions 欄位

三、拿一段真的會踩雷的代碼去試

賽前準備的 samples/ 目錄裡，剛好有一個最經典的踩雷片段：在 forEach 裡誤用 await。

function processOrders(orders) {
  orders.forEach(async (order) => {
    await chargeCustomer(order);
    console.log(`已處理訂單 ${order.id}`);
  });
  console.log("全部訂單處理完成");
}

把這段貼進 Chat，按下送出。

圖 3｜貼上踩雷代碼後，Gemini 的第一次回覆

我們可以看到 Gemini 沒有直接甩出修正版代碼，而是先指出「forEach 不會等待裡面的 async 函式執行完，所以最後那行 console.log 幾乎一定會比訂單處理更早印出來」。

四、Temperature 轉低 vs 轉高：同一個問題，AI 的「個性」差多少

右側面板另一個重點是 Temperature，數值通常落在 0 到 1、甚至到 2 之間，簡單理解就是：

Temperature 越低，回答越穩定保守；Temperature 越高，回答越有變化、也越容易天馬行空。

我用同一段踩雷代碼、同一組 System Instructions，分別在低溫（0.2）跟高溫（2）各測了兩次。

圖 4｜低溫兩次回覆 vs 高溫兩次回覆的對比

低溫的兩次回覆幾乎是同一套講法，用詞、切入點都很接近，感覺像是同一個人照著固定的檢查清單在講話。高溫的兩次回覆明顯不一樣：其中一次除了指出 forEach 的問題，還額外提醒了「如果訂單量很大，全部用 Promise.all 平行送出可能會打爆金流 API」，這個角度是低溫那兩次完全沒提到的。

好處是高溫確實比較有「舉一反三」的味道，但代價是它也開始講一些我沒有明確要求的東西，如果拿來做自動化審查工具，穩定性反而會是問題。這也讓我對之後 DevPulse 要用什麼溫度，心裡有了初步的答案：傾向偏低，先求穩定可預期，再談有沒有創意。

今日 Checklist

• [x] 找到 System Instructions 與 Temperature 的設定位置
• [x] 寫出第一版「資深導師」角色設定
• [x] 用一段踩雷代碼實測角色設定有沒有生效
• [x] 比較低溫與高溫的回答差異

小結

今天沒有寫任何一行程式碼，但其實做了一件比寫代碼更關鍵的事：幫 DevPulse 定義了它的第一個「性格」。

Project、API Key、Quota 是昨天搭好的骨架，今天的 System Instructions 則是第一次讓這個骨架有了具體的行為模式——會怎麼說話、會不會直接給答案、遇到不確定的狀況時傾向謹慎還是發散。

明天 Day 04，要用 Few-Shot 範例跟思考鏈（CoT），讓今天這個還有點生澀的「資深導師」，回答得更精準、更知道分寸在哪裡。