AI 協作開發：Claude 怎麼幫我寫 14 款遊戲

過去一年，我把 Claude 當成正職 pair programmer。期間從 0 寫到 14 款瀏覽器遊戲、一個 Cloudflare Workers 後端、一份完整的工作室官網，外加幾個內部工具。這篇不是 AI 吹捧文，也不是「AI 會取代工程師嗎」的辯論文，而是把實際合作過程攤開講：哪些任務丟給 AI 是純賺、哪些是隱形地雷、人在這個流程中該扮演什麼角色。

先講結論：AI 是「實習生 × 高速搜尋」

把 Claude 想成一個讀過所有公開技術文件、寫程式速度比你快 5 倍、但對你的專案脈絡完全陌生的實習生，比較貼近真相。它能在 30 秒寫出一個能跑的物件池實作，但無法知道你 codebase 裡已經有一個更通用的版本在 utils/pool.js。它能背出 Canvas API 所有方法，但不知道你三天前因為 iOS Safari 的 bug 故意避開 roundRect。

所以「AI 協作得好不好」很大程度取決於你給的脈絡夠不夠，以及你對輸出的把關有多嚴。下面把實際工作流拆成幾個階段。

哪些任務我會放心丟給 Claude

1. 樣板程式碼（boilerplate）

這是 AI 表現最穩定的領域。例子：

「幫我寫一個 React component，props 是 title, items, onSelect，UI 是垂直清單，被點擊時呼叫 onSelect(item)」
「把這個 D1 schema 的 5 張表都生對應的 TypeScript interface」
「為這個 utility function 寫 5 個 Vitest 測試案例」

這些任務有明確輸入、明確輸出、沒有業務邏輯爭議。AI 寫一次比我手 typing 快 5～10 倍，而且很少出錯。

2. 翻譯、轉換、格式化

「把這個 jQuery 寫法改成 vanilla JS」、「把這份 SQL 翻譯成 Cloudflare D1 prepared statement」、「這份 README 用 Markdown 改寫成 HTML」。AI 在「A 形式 → B 形式」的轉換上幾乎不會錯，因為兩邊都有明確規則。

3. 解釋陌生程式碼

接手別人的專案、或讀開源庫的時候，貼一段函式給 Claude 問「這在做什麼、可能的副作用是什麼」往往比自己一行行追快很多。注意它有時會「幻覺」說某個函式有不存在的副作用 — 把它當成一份「需要驗證的 hypothesis」就好。

4. 寫第一版 prototype

當我有一個模糊的想法（「想做一款連連看，要支援多種主題」），讓 Claude 寫出一個 200 行的最小可玩版本，比自己從零開始快多了。第一版的程式架構通常會被我重寫，但有東西可以批評，比盯著空白檔案快。

哪些任務我絕對自己寫

1. 牽涉「為什麼這樣設計」的決策

架構決定、技術選型、資料庫 schema、API contract。這些決定會持續影響半年以上的專案，必須由真正了解業務脈絡的人下。我會跟 Claude 討論 — 把它當白板 — 但最終的拍板由我來。

2. 關鍵安全邏輯

JWT 簽章驗證、SQL 參數化、權限檢查、CORS 設定。這些寫錯就是真實的安全漏洞，AI 偶爾會生出看起來對但實際有缺陷的版本（例如把 verify() 寫成 decode()，前者驗簽後者只解碼）。我都自己寫，再請 Claude review。

3. 業務邏輯的核心算法

遊戲的得分計算、難度曲線、AI 對手策略。這些是遊戲好不好玩的關鍵，需要設計師直覺，AI 給的版本通常太「平均」、缺乏記憶點。

實戰流程：寫一款新遊戲

用前陣子做的 Color Match 為例：

需求拆解（人）：我寫一份 200 字的 spec — 玩法、控制方式、計分規則、視覺風格。
骨架（AI）：丟給 Claude，請它生 React component 結構（state、effects、handlers 列表）。
核心算法（人）：我自己寫關卡生成邏輯與計分公式。這是遊戲魂的部分。
UI 樣式（AI）：把核心 component 給 Claude，請它寫 CSS 與動畫，給定色票與字型。
邊角案例（協作）：我列出所有可能的 edge case（連點、視窗縮放、tab 切換暫停），Claude 補相對應的處理。
測試與 QA（人）：自己玩、找朋友玩、看 console、看效能。AI 不會替你按手機螢幕。

這個分工大約讓我寫遊戲的速度提升到 3～4 倍。一款規模類似 DODGE MASTER 的小遊戲，過去要 5～7 天，現在 2 天可以上線。

Claude 最常犯的隱形錯誤

1. 過度抽象

給它一段重複出現 3 次的 if-else，它常會直接抽出 strategy pattern。但抽象層越多，未來改動越貴。我會明確要求：「先複製貼上，等真的有第 4 處再抽」。

2. 加防禦性程式碼到不需要的地方

內部 helper function 被加上 if (typeof input !== 'string') throw 之類。如果 caller 已經是受信任的內部程式碼，這層防禦只是雜訊。我會直接刪掉。

3. 寫過於詳細的註解

每個 if 上面都寫一行「// Check if user is logged in」。我會掃過全檔刪光，只留下解釋「為什麼」而不是「做什麼」的註解。

4. 用過時的 API

偶爾會看到 componentDidMount 或 React.createClass。新的對話要明確告訴它「用 React 18 + hooks」。

5. 假裝知道你的檔案結構

「你可以把這個放到 src/utils/index.ts」 — 但我的專案根本沒有 src/。這是 LLM 的「自信幻覺」。修法：在系統提示裡先列出實際的目錄樹。

Code review 的五個必檢點

每次 AI 產出新程式碼，我會固定跑這份 checklist：

檢查項	工具 / 動作
編譯 / 解析錯誤	跑一次 `node --check` 或在瀏覽器開來看
變數有沒有用到不存在的	看一次完整 diff，腦補 import 列表
有沒有把 secret 寫死	grep `SECRET\|TOKEN\|sk_`
有沒有改到我沒指定的檔案	看 git status，`git diff` 兩眼
UI 在實機上有沒有壞	必親手在手機 + 桌面跑一次

給協作 AI 的有效提示模板

我手邊有一份「對 AI 開口」的模板，每次重複使用：

【脈絡】
- 專案：Hao0321 遊戲大廳
- 檔案：game/dodge-master-v5.html（單檔 HTML，純 Canvas）
- 已有功能：物件池、分數、金幣、商店、簽到
- 現在要：新增「角色稀有度」系統，影響商店價格與抽獎機率

【限制】
- 不要引入新的 npm package
- 不要改動現有的 game state shape，只在 player 物件新增 rarity 欄位
- 必須跑在 iOS Safari 14+ 上

【期望輸出】
- 列出所有需要修改的函式名稱（不要寫程式碼）
- 等我點頭再動手

明確的脈絡 + 限制 + 階段性確認，可以省掉 70% 的「先生一坨我不要的程式碼」時間。

結語：AI 不是替你寫，是替你打字

用了一年下來最深的體會是：AI 沒有取代「思考」，它取代的是「打字」與「查文件」。判斷「這個 feature 該不該做」「這個架構正不正確」「這個 bug 影響有多嚴重」依然是你的工作。但那些把腦中已經想好的東西寫成 200 行可運作程式碼的勞動，AI 的確大幅縮短。

對獨立開發者而言，這個改變是巨大的 — 一個人能撐起的專案規模，從「一份小工具」直接放大到「一個小工作室的全部產出」。我自己這一年從原本兼職寫 1 款遊戲，變成同時推進 14 款 + 後端 + 官網，而且還沒燒掉。

如果你也在用 AI 寫程式碼、想交流心得，歡迎寄信 lo246179268@gmail.com。