系列：奇幻塔防開發實錄：用 Claude 打造一款有靈魂的塔防遊戲
今日工具：Claude Design
今日進度：三輪 Prompt 迭代，產出四張 artboard 並匯出到 docs/design/

前言

昨天的立項書定下了世界觀與五條原則，但「有劇情分支的塔防」在腦中仍然是一團霧。我不是設計師，過去做 side project 都是直接寫程式再慢慢長出介面，結果通常是介面長得像後台系統，而且每次改版面都要動程式。這次我想反過來：先讓畫面存在，再讓程式去追畫面。

今天的主角是 Claude Design——用對話產出多張 artboard 的原型，可以在畫布上直接點選元素微調，最後匯出 PNG 或 HTML。我會如實記錄三輪 Prompt 的迭代過程，包括第一輪為什麼失敗，因為失敗的那一輪教我的事最多。

一、第一輪：只給世界觀，看它怎麼理解

我刻意用最粗的描述開始，想看看在沒有規格的情況下 Claude Design 會補什麼：

Prompt 1（給 Claude Design）
「為一款名為《薪火要塞》的奇幻塔防遊戲設計原型。世界觀：維斯佩拉大陸，薪火王國對抗北方湧來的灰燼軍團「灰潮」。請產出一張世界地圖畫面，上面有六個關卡節點與三條不同顏色的命運路線。整體風格：深色、手繪地圖感、不要卡通。」

產出的地圖已經有六個節點、羊皮紙質感的邊框、蜿蜒的路線，第一眼很有說服力。但仔細看問題明顯：關卡名是 Claude 自己編的，其中有兩個聽起來像某些既有作品的地名；三條路線用紅／綠／藍這種毫無敘事意義的配色；節點之間的連線也看不出「路線」與「關卡順序」的差別。

這一輪的價值是讓我知道必須先給命名與色彩語言，否則它會用預設值填滿空白——而預設值裡藏著版權風險，這正是 Day 1 原則三存在的理由。

二、第二輪：給命名、給色彩、給尺寸

於是我把 Day 1 立項書裡的命名全部貼進去，並定下設計語言：

Prompt 2（給 Claude Design）
「修改上一版：六個關卡依序命名為灰原邊境、霧河渡口、斷橋古道、棄守修道院、黑岩隘口、薪火王城。色彩語言：背景深炭色；琥珀色 #F5A524 代表薪火，用在主按鈕、路線『守望之路』與所有正向資源；灰藍 #2B3A4A 代表灰潮，用在敵方元素；『燃盡之路』用暗紅、『餘燼之路』用灰白。再加一張戰鬥畫面：畫布邏輯尺寸固定 960×540（16:9），右側是 HUD（金幣／生命／薪火／波次），底部是四種塔的選單。」

這一輪產出兩張 artboard。地圖上六個節點從左下的灰原邊境一路往右上延伸到薪火王城，三條路線的顏色終於「會說話」：琥珀色是守護、暗紅是焦土、灰白是餘燼。戰鬥畫面的佈局幾乎就是我後來實作的樣子——左邊大片畫布、右側一條 HUD、底部四個塔按鈕。

我在畫布上點選 HUD 區塊，把它從右側 240px 縮到 200px，並把塔選單的四個按鈕改成等寬。這種「小改」在 Claude Design 裡直接拖拉調整，比重新下 Prompt 快得多，也不會像重新生成那樣把已經對的地方改壞。這是我第一次體會到「對話產出＋視覺微調」的組合價值：對話負責大方向，手動負責最後 10%。

三、第三輪：對話框與手機版

塔防的關卡之間會有劇情對話，這是這個遊戲「有靈魂」的關鍵，介面不能馬虎。同時 Day 1 就決定手機是主要平台之一，不能到第三週才想版面：

Prompt 3（給 Claude Design）
「新增兩張 artboard。第一張是劇情對話框：畫面下方 30% 高度的半透明深色面板，左側圓形頭像、名字用琥珀色小標、對白文字白色；面板上方浮出三個選項卡片，第三個選項顯示為灰色不可選並附一行小字『需要薪火 ×2』。第二張是手機橫向版（844×390）的戰鬥畫面：HUD 收成頂部一條細列，塔選單改為長按塔位彈出的環形選單。」

對話框這張我特別滿意灰化選項的處理：它不只變灰，還在卡片右下角放了一個小小的薪火圖示加「×2」，一眼就懂。手機版的環形選單則讓我意識到一件事——手機上沒有「底部塔選單」的空間，長按塔位彈出選單是唯一合理的互動，這會直接影響 Day 19 的觸控設計。

到這裡四張 artboard 齊了：

我把四張全部匯出成 PNG 與 HTML，存進 docs/design/，檔名對應 world-map、battle、dialogue、battle-mobile。HTML 版本很重要——它帶著實際的 CSS 值（色碼、寬高、圓角、字級），明天開始 Claude Code 讀得懂；PNG 則是給我自己與讀者看的。

四、設計稿要精確到什麼程度，才對 Claude Code 有用？

今天最大的收穫不是那四張圖，而是想清楚了一個問題：Claude Design 的產出，是給人看的還是給 Claude Code 看的？

我的答案是兩者都是，但要求不同。給人看的原型只要「感覺對」，顏色差一點、比例差一點都無所謂；給 Claude Code 看的原型需要三樣東西：

1. 尺寸與比例是明確數字：960×540、HUD 200px、對話面板 30% 高——這些會直接變成程式常數。「大概三分之一」對人可以，對程式不行。
2. 色彩有語意名稱：不是「琥珀色」而是「薪火色 = #F5A524」，之後會變成 CSS token --color-ember。有名字的顏色才能在程式裡被一致地引用。
3. 狀態被畫出來：灰色不可選的選項、長按彈出的選單、生命歸零的畫面——沒畫出來的狀態，程式就不會有，或者會有但長得跟其他地方不一致。

我把這三點加上色彩 token 表、四張稿的尺寸基準、以及每張稿包含哪些狀態，寫成 docs/design/README.md，作為設計稿的「意圖說明」。這份文件花了我 15 分鐘。它值不值得寫？Day 7 的週記我會做一個對照實驗來驗證。

三輪迭代攤開來看是這樣一條路徑：

第一輪的教訓是「不給規格就會被預設值填滿」，第二、三輪把規格逐步補齊；而匯出時同時留 PNG 與 HTML 這個習慣，會在 Day 7 變成一組正式的量化對照——那時我才會知道多花 15 分鐘寫 README 到底值不值得。

小結

三輪 Prompt、四張 artboard、大約 90 分鐘，其中第一輪的 20 分鐘是「學費」。踩到的雷是：不給命名與色彩，Claude Design 就會用它的預設審美與預設命名填滿空白，而預設命名有版權風險。可複製的要點：先定命名與色彩語言，再給尺寸，最後補狀態；大方向用對話，最後 10% 用手動微調；產出時同時匯出 PNG 與 HTML，前者給人看、後者給 Claude Code 讀。明天回到文字世界，把畫面裡那些空白的數字——塔多少錢、敵人多少血——一個一個填上。

今日產出

• [x] docs/design/world-map.{png,html}、battle.{png,html}、dialogue.{png,html}、battle-mobile.{png,html}
• [x] docs/design/README.md（尺寸、色彩 token、狀態清單）

明日預告

Day 03：塔防遊戲的骨架設計——波次、塔種、資源三角，用 Claude 拆解遊戲系統規格書。