Vibe Coding 道場 Dojo
第 11／20 章 · 0 XP ← 回目錄
綠帶 · Vibe Coding 素養
第 11 章

讀懂 AI 的 code —
你不用會寫，但要會讀

這章結束你會用由上而下的方法讀懂 AI 產出的程式碼，知道先看哪裡、何時追細節、哪些地方要警覺。

開場 · 主管要看得懂廚房

很多人第一次拿到 AI 寫好的程式碼，反應不是開心，而是心虛：畫面好像能跑，但下面那一大坨字到底在做什麼？你不需要立刻變成會從零發明菜色的大廚。讀程式碼比較像看食譜：你先看菜名、材料、步驟順序，再決定哪一段需要細讀。這章要練的不是硬背語法，而是主管能力。AI 是很會做事的實習生，但交上來的東西你要看得懂，才能知道它是不是照你的需求做。

讀 code 不等於寫 code

先把壓力放下來：讀程式碼（code）跟寫程式碼不是同一件事。你可以看懂一份料理食譜，知道先切菜、再熱鍋、最後調味，但不代表你現在就能發明一道新菜。讀 code 也是這樣。你要練的是看出「這段在處理什麼事」、「資料從哪裡進來」、「結果從哪裡出去」。這三件事，比一開始就追每個符號重要得多。

AI 寫出來的 code 常常看起來很長，因為它會一次把資料、函式、判斷、畫面更新都塞進來。初學者最容易犯的錯，是從第一行開始逐字硬啃，啃到第三行就累了。更有效的方法，是先把整份 code 當成一張地圖。你先找大路，再找門牌，不要一開始就盯著地磚的花紋。

你在前面章節已經有足夠的積木了。ch02 學過變數（variable），所以你知道有名字的盒子在存東西。ch03 學過判斷和迴圈，所以你認得「如果」和「重複」。ch04 學過函式（function），所以你知道一段步驟可以被打包、取名字、反覆呼叫。AI code 不是新的魔法，它只是把這些積木堆得比較高。

因此，讀 code 的第一個目標不是「每行都懂」，而是「能說出這份 code 大概分成哪幾塊」。如果你能指著一段說：「這裡是資料」、「這裡是在算總數」、「這裡是在顯示結果」，你已經從純 vibe coder 往主管前進一大步。主管不必親手切每一片菜，但要知道廚房現在在做哪道菜、哪一步可能出錯。

先看出三塊：資料、加總函式、印出結果。
const orders = [120, 80, 45];
function addTotal(numbers) {
  let total = 0;
  for (const number of numbers) {
    total = total + number;
  }
  return total;
}
console.log("總金額：" + addTotal(orders));

三層閱讀法：名字、流程、細節

讀 AI code 最穩的順序，是三層閱讀法。第一層叫掃名字：看函式名、變數名、按鈕名、資料名。命名（naming）是 code 裡最像人話的部分。看到 calculateTotal，你不用知道每個符號，也能猜它在計算總數。看到 userList，你大概知道它是一份使用者清單。好命名像食譜標題，先告訴你「這鍋在煮什麼」。

第二層叫追流程：誰先做、誰呼叫誰、資料怎麼一路往下走。你可以把它想成外送訂單：顧客送出訂單，系統檢查地址，計算金額，再顯示結果。讀 code 時，不要只看單行，要看動線。常見線索是函式呼叫，也就是一個名字後面接括號，例如 calculateTotal(items)。這代表「現在按下這台機器的按鈕」。

第三層才叫鑽細節。只有當你知道某一段很關鍵、或結果明顯錯了，才進去看那一行到底怎麼算。這就像看食譜時，你不會一開始研究鹽的化學式；你會先看這道菜是不是需要鹽，什麼時候加鹽，最後味道不對才回頭檢查份量。讀 code 也一樣，不要把細節當入口，把細節當最後的放大鏡。

這個順序能保護你的注意力。AI 產出的 code 有時候會長到讓人想逃，但你每次只做一件事：先圈出名字，再畫出流程，最後只查卡住的細節。你不是在背語法考試，你是在判斷這份工作有沒有照規格走。這就是綠帶的閱讀力。

用函式名先猜功能，再追 printReceipt 呼叫 calculateTotal。
const cartItems = [
  { name: "咖啡", price: 90 },
  { name: "蛋糕", price: 130 }
];
function calculateTotal(items) {
  let total = 0;
  for (const item of items) {
    total = total + item.price;
  }
  return total;
}
function printReceipt(items) {
  const total = calculateTotal(items);
  console.log("收據總計：" + total + " 元");
}
printReceipt(cartItems);

追資料流：資料從哪裡來，到哪裡去

如果你只能學一個讀 code 的動作，請學「追資料流（data flow）」。資料流就是資料的旅程：一開始被放在哪個變數，經過哪個函式處理，最後變成什麼結果。多數 app 的本質，都是資料進、資料處理、資料出。記帳工具是輸入花費，算出總額；小費計算機是輸入金額和人數，算出每人要付多少；猜數字遊戲是輸入猜測，輸出太大、太小或答對。

追資料流時，先找最像「原料」的地方。它可能是一個清單、一個表單輸入、一段 JSON，或使用者按下按鈕後傳進來的值。接著找處理原料的機器，也就是函式。最後找結果被印出、顯示、回傳或存起來的地方。你可以在紙上畫三欄：輸入、處理、輸出。很多看似可怕的 code，一畫成三欄就變短了。

要特別注意「資料型別」的轉換。ch02 提過，數字和文字不是同一種東西。AI 有時會從畫面拿到文字 "100"，卻忘了轉成數字 100，結果加法變成黏字。這種 bug 不一定會紅字報錯，卻會算錯錢。讀 code 時，只要看到金額、數量、分數，就問自己：它現在真的是數字嗎？這是很實用的主管問題。

還有一個實用習慣：替每個中途結果取一個暫時名字。看到 filteredItems，你可以在心裡翻成「篩過後的清單」；看到 total，翻成「目前加到多少」。如果某個名字翻不成人話，或同一份資料一下叫 list、一下叫 data、一下叫 x，閱讀成本就會上升。這時不是你太笨，而是 code 沒有把路標立好。你可以請 AI 先把命名整理清楚，再繼續檢查功能。

追資料流也能幫你跟 AI 對話。你可以說：「請指出資料從 userInput 進入後，經過哪些函式，最後在哪裡更新畫面。」這句話比「幫我解釋一下」更有方向。你不是叫實習生自由發揮，而是指定它帶你走一條路線。

同一份資料如果還是文字，加法結果會完全不同。
const inputFromPage = "100";
const serviceFee = 20;
const wrongTotal = inputFromPage + serviceFee;
const correctTotal = Number(inputFromPage) + serviceFee;
console.log("錯誤結果：" + wrongTotal);
console.log("正確結果：" + correctTotal);

讓 AI 當導遊，但你要指定路線

讀不懂 AI 寫的 code 時，可以請 AI 解釋。這不是作弊，這是正確使用工具。差別在於，你不要只丟一句「看不懂」。那會讓 AI 實習生自由發揮，可能講得很長，卻沒有回答你的問題。更好的問法是把閱讀任務拆清楚：先請它列出主要段落，再請它追資料流，最後請它解釋你卡住的那一行。

你可以使用這個固定模板：「請用繁體中文白話解釋這份 code。先分段說每段功能，再畫出資料從輸入到輸出的流程，最後列出三個我應該檢查的風險。不要重寫 code，除非我要求。」這段話的重點是限制任務。你不是請它再做一份新的菜，而是請它帶你參觀廚房。

如果你貼的是跟金錢、帳號、刪除資料有關的 code，還要加一句：「請特別標出會改資料、刪資料、送出請求、處理付款或使用金鑰的地方。」這是防守常識。讀 code 不只是為了懂，更是為了知道哪裡不能隨便跑。純 vibe coder 常常看到 AI 說可以就按下去；綠帶讀者會先找出危險動作。

另外，請 AI 解釋後，你仍然要抽查。AI 可能把不存在的函式講得很合理，也可能漏掉邊界情況。你可以用本章的三層閱讀法回頭核對：它說的段落名對不對？流程有沒有跳過判斷？它標出的風險是否真的存在？這樣 AI 就從魔法箱變成導遊，而你仍然是拿地圖的人。

把解釋任務寫成清楚的導覽 prompt。
const guidePrompt = [
  "請用繁體中文白話解釋這份 code。",
  "先分段說每段功能。",
  "再說資料從輸入到輸出的流程。",
  "最後列出三個我應該檢查的風險。",
  "不要重寫 code，除非我要求。"
];
console.log(guidePrompt.join("\n"));

危險訊號：看到這些要停下來問

讀 code 時，有些訊號代表你不該急著按執行。第一個是「看不懂的一大坨」。如果一份 code 沒有函式、沒有段落、沒有註解（comment），所有事情擠在一起，就像食譜把買菜、切菜、開火、裝盤寫成一整句。它未必一定錯，但很難檢查，也很難修改。你可以要求 AI 先重構成幾個有名字的小函式，再討論功能。

第二個危險訊號是重複貼三遍。重複代表未來很容易改漏。例如同一段計算折扣的 code 出現在三個地方，其中兩個修了、一個忘了，bug 就會躲在沒修的那一份。看到重複，你可以問：「這能不能抽成一個函式？」這不是炫技，而是讓食譜少一點重複步驟，之後比較不會前後矛盾。

第三個是只有快樂路徑（happy path）。快樂路徑指的是一切都正常時才會成功的流程：使用者一定有輸入、金額一定是正數、網路一定正常、資料一定存在。真實世界不會這麼乖。AI 很常先寫出可以展示的版本，卻沒有處理空值、0、負數、格式錯誤、找不到資料。看到沒有 if 的輸入處理，尤其要小心。

第四個是命名太混亂，例如 a、b、data2 到處飛。機器看得懂，人看不懂。你不必接受這種 code。可以請 AI 改成有意義的名字，例如 monthlyExpenses、calculateTotal、renderSummary。可讀性不是裝飾，是驗證的前提。你看得懂，才知道它有沒有做對；你看不懂，就只能相信。

實務上，你可以替自己設一個停損線：如果五分鐘內仍說不出這份 code 的三個段落，就先不要改功能。先請 AI 分段、補註解、改命名，再重新讀一次。這不是拖慢速度，而是避免在看不清楚的廚房裡亂加調味料。

清楚命名讓你不用逐字猜，也能知道資料和函式在做什麼。
const monthlyExpenses = [320, 120, 80];
function calculateTotal(expenses) {
  let total = 0;
  for (const expense of expenses) {
    total = total + expense;
  }
  return total;
}
console.log("本月支出：" + calculateTotal(monthlyExpenses));
招牌互動 · code-xray

X 光閱讀室

A-F · data flow

先把滑鼠移到程式段落看白話解說，再回答哪一段負責哪件事。

定位任務

點 A-F 回答每題。答錯會直接顯示正解；答對會標綠。

Boss 題：哪一版適合維護？

清楚命名不是為了漂亮，而是讓你更快追資料流。

清楚版

const monthlyExpenses = [320, 120, 80];
function calculateTotal(expenses) {
  return expenses.reduce(function(total, expense) {
    return total + expense;
  }, 0);
}
function printMonthlyTotal(expenses) {
  console.log(calculateTotal(expenses));
}

混亂版

const a = [320, 120, 80];
function b(c) {
  return c.reduce(function(d, e) {
    return d + e;
  }, 0);
}
function f(g) {
  console.log(b(g));
}
完成條件：五題全過，並答對 boss 題。
✓ X 光閱讀完成 你已經能用段落、資料流、命名品質來檢查 AI 的 code。+30 XP 入袋。

純 vibe coder 看到 AI 產出的 code，只能問「能不能跑」。你會先掃函式名和變數名，再追資料從輸入到輸出的路線，最後只鑽真正可疑的細節。遇到一大坨、重複、沒有邊界判斷的快樂路徑 code，你會停下來要求 AI 拆段、改名、補檢查。這些都是具體動作，不是信心喊話。

隨堂測驗 · 5 題

檢查一下這章

下一章預告

下一章會把閱讀力接到驗證力：不要只看懂，還要測到它真的對。