系列：奇幻塔防開發實錄：用 Claude 打造一款有靈魂的塔防遊戲
今日工具：Claude Design → Claude Code（對照實驗）
今日進度：三種「餵設計稿」方式的實測對照，第一週回顧

前言

第一週的六天沒有寫遊戲邏輯，全在打地基：立項書、設計稿、資料契約、劇情樹、ADR、專案記憶。週記我不想只寫回顧，想回答一個從 Day 2 就掛在心上的問題：Claude Design 畫出來的東西，Claude Code 真的用得上嗎？還是只是好看的圖？

這個問題值得認真回答，因為它決定了接下來的工作流：如果答案是「用得上」，那所有 UI 元件都應該先在 Claude Design 畫好再交給 Claude Code；如果答案是「用不上」，設計稿就只是給我自己看的參考，不必花時間寫意圖說明。今天做一個小而嚴謹的實驗。

一、實驗設計

目標：讓 Claude Code 從 Day 2 的對話框 artboard 產出 frontend/src/components/DialogueBox.vue（含頭像、名字、對白、三個選項、第三個灰化），先不接資料。選對話框是因為它狀態最多——有正常選項、有灰化選項、有 RWD——最能看出差異。

三種餵法，每種都在乾淨的 claude session 執行（避免前一輪的記憶影響），Prompt 主體完全相同，只改附件：

Prompt（三組共用）
「依附件的設計稿實作 DialogueBox.vue：<script setup lang="ts">，props 為 speaker、text、choices（含 disabled 與 hint）。樣式用 CSS 變數，不要 inline 色碼。RWD：寬度 < 768px 時面板高度改為 40%。」

量測方式：我以 Day 2 的 artboard 為「標準答案」，列了 23 個檢查項（版面 6 項、色彩 5 項、灰化選項 4 項、RWD 3 項、props 介面 5 項），逐項檢查產出；記錄「不修改可直接用的比例」（通過項數／23）、我為了達到標準答案修改的行數（git diff --stat）、以及從送出 Prompt 到我認可的總分鐘數（含我閱讀與修改的時間）。三組各跑兩次取平均。

同一份 Prompt、同一份 23 項檢查表，只換附件——這就是這次實驗唯一改動的變因：

二、結果

註：樣本只有兩次，兩次之間的差異在 A 組最大（52% 與 64%），C 組最穩（兩次都是 21/23）。數字有偏差，但趨勢很清楚。

幾個值得記下的觀察：

• PNG 的問題不是「看不懂」而是「猜太多」。Claude Code 能從圖理解版面——頭像在左、名字在上、三個選項卡片——但色碼、比例、字級全靠估，每一個估值都是一處要改的地方。41 行修改裡有 28 行是數值修正。
• HTML 讓數值正確，但帶來噪音。Claude Design 匯出的 HTML 為了預覽會包幾層容器與定位用的 wrapper，Claude Code 會忠實地搬過去，反而要我手動拆。它「太聽話」了。
• 意圖說明是關鍵的 12%。README 裡那句「灰色選項要顯示『需要薪火 ×2』的 hint」與「色彩以 token 命名，對照表如下」讓 C 組一次到位。狀態沒寫出來，程式就不會有——Day 2 猜的這件事被驗證了。

C 組的產出我只改了 6 行就 commit 進 frontend/src/components/DialogueBox.vue，Day 18 會直接沿用並接上劇情 store。

三、所以答案是什麼？

能，但「直接」兩個字要打折。 Claude Design 的產出要對 Claude Code 有用，需要三個條件，恰好對應三種餵法的差距：

1. 給帶數值的格式（HTML），不要只給圖——這是 A 到 B 的 21 個百分點。
2. 附一份人寫的意圖說明：尺寸基準、色彩 token、狀態清單——這是 B 到 C 的 12 個百分點。
3. 在 Prompt 裡指定程式的介面（props、CSS 變數、RWD 斷點），設計稿只管長相，不管介面。三組都有這條，所以它的貢獻沒被量到，但少了它 props 一定會亂長。

這個實驗有明顯的限制，我不想誇大：只測了一個元件、只跑了兩次、檢查項是我自己訂的，而且對話框是「狀態多但版面簡單」的元件——換成戰鬥畫面那種有 Canvas 與 DOM 混合的版面，三組的差距可能更大也可能更小。它能證明的只有一件事：同一份設計稿，餵法不同，結果差三成。 這已經足以決定接下來的工作流。

換算成成本：意圖說明我在 Day 2 花了 15 分鐘寫，這次實驗一個元件就省回 4.5 分鐘；接下來還有 HUD、塔選單、世界地圖、結局頁至少四個元件要從設計稿來，這 15 分鐘是穩賺的投資。更重要的是 C 組的產出「不需要我盯著」——8.5 分鐘裡有 6 分鐘我在做別的事。

四、第一週回顧：三個教訓

教訓一：讓 Claude 反問，不要讓它直接給答案。 Day 1 的立項書與 Day 5 的 ADR 都靠這一招。單人專案最缺的不是產能，是有人挑戰你的假設；Claude 當反方比當顧問有價值得多。

教訓二：契約先於程式。 Day 3 的 data/*.json 與 Day 4 的 graph.json 是這週最有價值的產出。它們讓 Go 後端、Vue 引擎、模擬器可以從下週起各走各的——Day 12 的 worktree 實驗完全建立在這個前提上。

教訓三：專案記憶要寫「怎麼做」，不是「是什麼」。 Day 6 重寫 CLAUDE.md 那 30 分鐘，是整週投資報酬率最高的 30 分鐘。今天實驗的三組 session 都自動載入了它，產出的 Vue 元件全部用 <script setup lang="ts">、全部沒有 inline 色碼——這些規則我在 Prompt 裡沒有重複，是 CLAUDE.md 在背後生效。

坦白說進度上有一件事落後：docs/story/script.md 第 4–6 關的對白還是草稿，六關 60 個節點只有 40 個定稿。我決定不在第一週硬補，因為 Day 10 的狀態機只需要圖的結構，對白可以在 Day 18 前補完。

第一週時間紀錄（從 Cowork 建的 daylog 彙整；以下六天只到 Day 6，不含今天——今天的時間會併入下週紀錄）：

平均一天不到三小時，這是可持續的節奏；下週後端要開工，我預期會拉到四小時。Session 數也值得看：12 個 session 裡有 5 個是「反問型」（讓 Claude 問我），7 個是「產出型」，第一週的比例偏向思考，這是對的。

小結

一週的地基工程，換來一個可以驗證的答案：設計稿要「帶數值、附意圖、指定介面」才能餵給 Claude Code，三者到位可以達到九成可直接用。更重要的是這週建立的三個習慣——讓 Claude 反問、契約先行、記憶寫規則——會是接下來 23 天的底層作業系統。下週進入後端：Go Clean Architecture、Terraform（這次不是建網路，是建那些刪掉會痛的東西）、劇情狀態機、goroutine 模擬器，還有我最期待的 worktree 平行開發實測。

今日產出

• [x] 三種餵法對照實驗與數據（~/emberhold-notes/decisions/0002-design-to-code.md）
• [x] frontend/src/components/DialogueBox.vue（C 組產出，已 commit）
• [x] 第一週時間紀錄彙整

明日預告

Day 08：建造要塞——Go 後端專案架構設計，用 Claude Code 生成 Clean Architecture 骨架。