系列：奇幻塔防開發實錄：用 Claude 打造一款有靈魂的塔防遊戲
今日工具：claude.ai 對話 ／ Claude Cowork
今日進度：把一個模糊的念頭收斂成一頁立項書，建好筆記系統與空 repo

前言

「軟體開發只是 Claude 應用的其中一塊拼圖。」這句話我在很多場合聽過，但一直沒有親手驗證。所以這 30 天我想做一件夠具體、夠難、又夠有趣的事：從零打造一款有分支劇情、能實際部署上線的奇幻塔防遊戲，並且把每一個用到 Claude 的環節——設計、寫程式、平行開發、自訂工作流、整理文件——原原本本地攤開來記錄，包括失敗的部分。

遊戲叫做《薪火要塞》（Emberhold）。今天不寫程式，今天只做三件事：講清楚為什麼、把想法收斂成立項書、把筆記與 repo 的地基打好。如果你正在思考「Claude 到底能在一個真實專案裡扮演什麼角色」，這個系列就是為你寫的。

一、為什麼是塔防？為什麼是 30 天？

我選塔防不是因為它簡單，而是因為它剛好夠複雜，複雜到每一層技術都逃不掉：

還有一個私心：塔防是少數「單人也能做出完整體驗」的遊戲類型。它不需要多人同步、不需要大量美術，靠系統與數值就能好玩。而「有靈魂」指的是劇情——大多數塔防的故事只是關卡之間的過場，我想做的是選擇會改變結局、也會改變戰鬥的塔防。

至於 30 天，那是鐵人賽的規則，也是一個很誠實的壓力測試：如果 Claude 真的能加速開發，我應該做得完；如果做不完，那些「做不完的地方」本身就是最有價值的記錄。我會如實寫下進度落後的日子，而不是把文章寫成事後追認的成功故事。

二、用 claude.ai 把念頭收斂成一頁立項書

我最初的想法只有一句話：「做一個有劇情分支的奇幻塔防」。這種程度的描述交給任何人都做不出東西。我第一次嘗試是直接請 Claude「幫我規劃這個遊戲的架構」，它十秒內給了一份漂亮的方案：模組清單、技術棧、里程碑一應俱全。問題是讀完之後我完全沒有「這是我的專案」的感覺——每一個決定都不是我做的，我也答不出為什麼要那樣做。

於是我把對話砍掉重來，改變目標：不是要答案，而是要逼自己回答問題。

Prompt（給 claude.ai）
「我想在 30 天內做一款有分支劇情的奇幻塔防遊戲，前端 Vue 3 + Canvas，後端 Go，部署 AWS。請不要直接給我方案，先問我 10 個會影響架構的關鍵問題，一次問一個，等我回答後再問下一個。」

這段對話花了 40 分鐘。Claude 問的問題包括：戰鬥邏輯跑在前端還是後端？劇情分支會影響戰鬥數值嗎？要不要多人？存檔要跨裝置嗎？美術資源從哪來？手機是「能玩」還是「主要平台」？每一題我都得停下來想，有兩題我當場答不出來，只能先寫「暫定」。這些答案最後收斂成五條核心設計原則：

1. 資料驅動：塔、敵人、波次、劇情全部是 JSON，程式只是解譯器。
2. 劇情與戰鬥耦合：劇情選擇會產生一種戰鬥中可用的資源「薪火」，兩個系統不能是兩張皮。
3. 原創命名：世界觀、塔名、角色、關卡全部原創，避免任何版權聯想。
4. 可部署：不是本機 demo，而是有 IaC、CI/CD、監控的真實服務。
5. 可量測：所有「Claude 讓我更快」的主張都要附數據，不然就不寫。

接著我請它把對話整理成一頁式立項書，貼到 docs/pitch.md。立項書裡定下的世界觀很簡單：維斯佩拉大陸上的薪火王國，傳說王城地底有一團「初火」，只要它不熄王國就不會滅亡；北方灰原湧來名為「灰潮」的灰燼軍團；你是邊境要塞的年輕守望者。三位關鍵人物——參謀艾瑟琳、老將軍卡爾登、逃出灰潮的信使米菈——各自代表一條命運之路，這會在 Day 4 展開。

三、用 Claude Cowork 建立 30 天的筆記系統

寫鐵人賽最容易失敗的不是技術，而是記錄斷掉：做到第十幾天，程式做了但忘了當時為什麼那樣做、花了多久、踩了什麼雷。所以我用 Claude 桌面版的 Cowork 模式建了一套筆記結構。做法是指定一個資料夾 ~/emberhold-notes/，然後用自然語言描述我要的東西：

Prompt（給 Claude Cowork）
「在這個資料夾建立 30 天開發日誌結構：daylog/day01.md 到 day30.md，每個檔案用同一份模板（今日目標、實際做了什麼、時間紀錄表、踩雷、明日計畫）；另外建 decisions/ 資料夾與 decisions/TEMPLATE.md，格式參考 ADR（背景、選項、決定、後果）。」

Cowork 直接在資料夾裡產出了 32 個檔案。我特別要求時間紀錄表要有「開始／結束／專注分鐘／Claude session 數」四欄，因為原則五說了：沒數據就不寫。這張表會在 Day 7、12、14、29 派上用場。

Cowork 的定位我想講清楚：它適合非程式碼的知識工作——建結構、整理文件、產出試算表、從一堆檔案裡彙整報告。它不是用來寫程式的；程式碼的事，從 Day 3 起交給 Claude Code。這個分工在接下來 30 天會反覆出現。

四、repo 初始化與 30 天可驗證目標

最後是最樸素的一步：

mkdir project && cd project
git init
printf '# Emberhold 薪火要塞\n\n30 天鐵人賽開發中。\n' > README.md
git add . && git commit -m "chore: init repo"

以及我對自己的承諾。30 天結束時，以下每一項都必須能被讀者驗證，做不到的我會在 Day 29 誠實列出：

• [ ] 一款可在瀏覽器（含手機）遊玩的塔防，至少 3 關完整可玩
• [ ] 三條劇情路線、三種結局，可從 DynamoDB 單表 emberhold-prod 的存檔項目查證
• [ ] Go API 部署在 AWS，Terraform 全程可重建：Go 二進位 bootstrap 包成容器映像推上 ECR（base public.ecr.aws/lambda/provided:al2023 / arm64），由 Lambda 拉起來跑，經 API Gateway REST API 對外
• [ ] CI/CD 一鍵部署，CloudWatch 告警實際觸發過至少一次
• [ ] worktree 平行開發與序列開發的對照數據
• [ ] 一套可複製的自訂 Claude Code workflow（/ultracode）

四週的作戰計畫如下：

第三週我自己標為高風險區：Vue 渲染、CI/CD、監控三件事撞在一起。我的對策是現在就把每天的大綱寫好，即使程式落後，也照實記錄「進行中」的狀態。

小結

把今天的動作串起來看，其實只是一條很單純的線：

今天沒有一行遊戲程式碼，但我認為這是 30 天裡最重要的一天。用 claude.ai「反問」而不是「求解」，逼出了五條之後每天都會拿來對照的原則；用 Cowork 建了筆記系統，讓「可量測」不只是口號。踩到的第一個雷就是最有價值的：一開始讓 Claude 直接給方案，得到一份漂亮但完全不屬於我的架構——所以才改成讓它問我問題。這個教訓會貫穿整個系列：Claude 負責加速，方向必須是你的。

今日產出

• [x] docs/pitch.md（一頁式立項書，含五條核心設計原則）
• [x] ~/emberhold-notes/daylog/day01–30.md、decisions/TEMPLATE.md
• [x] project/ repo 初始化與第一個 commit

明日預告

Day 02：用 Claude Design 畫出奇幻大陸的第一張地圖——從對話到遊戲原型的設計流程。