Day 04：馴服大模型：用 Few-Shot 與思考鏈（CoT）讓 AI 看懂代碼

前言

Day 03 結尾我寫下這句話：

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

經過昨天的測試我們能夠知道
Temperature 只能決定「講話穩不穩」，決定不了「講話的範圍跟格式」。

要讓 AI 的回答範圍收斂、格式固定，靠的不是調參數，是今天的主角：Few-Shot 跟 思考鏈（Chain of Thought, CoT）。

今天一樣不寫程式，還是在 AI Studio 網頁上動手，但今天做完會留下一個實體產出：一份存成檔案、以後真的會被載入使用的 Markdown Prompt 模板。

一、先搞懂問題出在哪

昨天的 System Instructions 只告訴 Gemini「要做什麼角色」，卻沒有告訴它「答案應該長什麼樣子」。

沒有範例可以參考的時候，Gemini 只能自己猜格式該多長、該講到多細——溫度一高，猜出來的版本自然就開始各講各的。

所以今天不是要換一個更厲害的角色設定，而是要多做一件事：直接示範幾個「好答案」給它看。

二、Few-Shot：先示範幾個「好答案」長怎樣

Few-Shot 的概念很直覺：與其抽象地描述「請簡潔、請有條理」，不如直接放一兩組「輸入代碼 → 期望回答」的範例，讓 AI 直接照著格式模仿。

我挑了兩段跟 Day 03 不同類型的踩雷代碼，準備當作範例。

範例一：邊界崩潰

function getCity(user) {
  return user.address.city;
}

期望的回答格式：

1. 這段程式碼在做什麼：從 user.address 裡取出 city 欄位。
2. 可能的疑慮：如果某個 user 沒有 address 欄位，這行會拋出「無法讀取 undefined 的屬性」的執行期錯誤。
3. 為什麼會這樣：JavaScript 存取巢狀屬性時，只要中間任何一層是 undefined，就會直接中斷並拋出例外。
4. 想一想：如果 address 有可能不存在，你會怎麼安全地取出 city？（提示：可以查查 Optional Chaining）

範例二：SQL 字串拼接

const query = "SELECT * FROM users WHERE name = '" + username + "'";
db.execute(query);

期望的回答格式：

1. 這段程式碼在做什麼：把使用者輸入的 username 直接拼接進 SQL 查詢字串。
2. 可能的疑慮：如果 username 被輸入類似 ' OR '1'='1 的內容，查詢條件可能被竄改，這是常見的 SQL Injection。
3. 為什麼會這樣：字串拼接不會過濾或跳脫輸入內容，資料庫執行時會把使用者輸入直接當成語法的一部分。
4. 想一想：有沒有辦法讓資料庫明確區分「語法」跟「資料」？（提示：查查 Prepared Statement 或參數化查詢）

圖 1｜把這兩組範例貼進 System Instructions

兩個範例的答案格式一模一樣，都是固定的四段式：現象 → 疑慮 → 原因 → 引導提問。這個固定順序，就是接下來要講的 CoT。

三、思考鏈 CoT：讓步驟變成可以檢查的路徑

CoT 常常被講得很玄，但拆開來看很單純：與其讓 AI 直接跳到結論，不如逼它先把「怎麼想到這個結論」的過程按順序寫出來。

上面 Few-Shot 範例裡的「現象 → 疑慮 → 原因 → 引導提問」，其實就是一條 CoT 路徑：

1. 先重述看到的代碼在做什麼（確認 AI 真的有讀懂）
2. 再指出可能的疑慮（不是馬上給答案）
3. 解釋為什麼這是疑慮（推理過程攤開來看）
4. 最後才丟一個引導性問題（把思考權留給使用者）

把這個順序寫進範例裡，AI 之後遇到新代碼，也會很自然地照著同一條路徑走，而不是想到哪講到哪。

四、把三樣東西合體成 v2 Prompt

把 Day 03 的角色設定、今天的兩組 Few-Shot 範例、還有一句明確限制範圍的邊界說明，合併成今天的 v2 版本：

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

請用繁體中文，依照以下固定順序回答：
1. 這段程式碼在做什麼
2. 可能的疑慮（邏輯風險、安全性疑慮或邊界條件問題）
3. 為什麼會這樣（說明推理過程）
4. 想一想（丟一個引導性問題，不要直接寫出完整修正代碼，除非使用者明確要求）

請只針對這段程式碼本身的問題作答，不要額外提出與這段代碼無關的架構、效能或第三方套件建議，除非使用者主動詢問。

以下是兩個範例：

【範例輸入】
function getCity(user) {
  return user.address.city;
}

【範例輸出】
1. 這段程式碼在做什麼：從 user.address 裡取出 city 欄位。
2. 可能的疑慮：如果某個 user 沒有 address 欄位，這行會拋出「無法讀取 undefined 的屬性」的執行期錯誤。
3. 為什麼會這樣：JavaScript 存取巢狀屬性時，只要中間任何一層是 undefined，就會直接中斷並拋出例外。
4. 想一想：如果 address 有可能不存在，你會怎麼安全地取出 city？（提示：可以查查 Optional Chaining）

【範例輸入】
const query = "SELECT * FROM users WHERE name = '" + username + "'";
db.execute(query);

【範例輸出】
1. 這段程式碼在做什麼：把使用者輸入的 username 直接拼接進 SQL 查詢字串。
2. 可能的疑慮：如果 username 被輸入類似 ' OR '1'='1 的內容，查詢條件可能被竄改，這是常見的 SQL Injection。
3. 為什麼會這樣：字串拼接不會過濾或跳脫輸入內容，資料庫執行時會把使用者輸入直接當成語法的一部分。
4. 想一想：有沒有辦法讓資料庫明確區分「語法」跟「資料」？（提示：查查 Prepared Statement 或參數化查詢）

特別加了「請只針對這段程式碼本身的問題作答」這句，就是直接針對昨天 Promise.all 那次離題寫的邊界限制。

五、換一段新代碼、轉回高溫，看會不會還離題

這次我沒有選新的 bug，反而故意拿 Day 03 用過的 forEach 誤用 await 那段代碼，把 Temperature 轉回昨天離題的那個高溫設定，再測一次。

圖 3｜同一段代碼、同樣的高溫，這次 v2 Prompt 的回覆

這次的回覆確實照著「現象 → 疑慮 → 原因 → 想一想」的順序走，也沒有再自己延伸出 Promise.all 或其他沒被問到的建議。格式跟範圍都比昨天穩定不少，就算溫度沒有變。

這也印證了今天一開始的判斷：Temperature 管的是穩不穩，Few-Shot 跟 CoT 管的才是準不準、範圍對不對。兩件事本來就不是同一層的問題。

六、存成可重複使用的 Markdown 模板

把上面那段 v2 System Instructions 存成檔案，放進 devpulse/ 專案裡，順便更新一下目前的資料夾結構：

devpulse/
├─ .env
├─ .gitignore
├─ package.json
├─ index.js
└─ prompts/
   └─ code-review-v2.md

prompts/code-review-v2.md 裡的內容，就是今天整理出來的那一大段 v2 Prompt。之所以現在就存成檔案，是因為 Day 08 開始要用代碼呼叫 Gemini API 時，這份檔案會直接被讀進去當作 System Instructions 使用，不用再重新手打一次。

今日 Checklist

• [x] 找出昨天只靠 Temperature 沒辦法解決的問題
• [x] 準備兩組不同類型 bug 的 Few-Shot 範例
• [x] 用固定的四段式格式，把 CoT 內建進範例裡
• [x] 合併成 v2 System Instructions，加上邊界限制
• [x] 用高溫重測舊代碼，確認沒有再離題
• [x] 把 v2 Prompt 存成 prompts/code-review-v2.md

小結

今天沒有再增加任何新的角色設定，而是把 Day 03 那個「還有點生澀」的資深導師，用 Few-Shot 跟 CoT 磨得更穩定——講話順序固定了、範圍也收斂了，連原本溫度一高就容易亂飄的問題，也一併解決。

更重要的是，今天第一次留下一份會被之後代碼真正讀取的檔案，devpulse/ 資料夾也第一次長出了 prompts/ 目錄。

明天 Day 05，要來測試 Gemini 的百萬 Token 長上下文，看看直接丟一整份技術文件進去，AI 能不能精準回答裡面的細節。