[情報] Spec-Kit × Claude Code：先寫規格再做全端，再丟上 VPS

一、這集在幹嘛、會用到的工具

作者拿一款網頁版「割草／肉鴿」當案例：訪客也能玩，登入後能記分、排行、升級角色。前端畫面、後端 API、資料庫一個都不能少。

這集會用到這幾個工具：

• Claude Code：Anthropic 的 AI 寫程式助手（在終端／專案裡跑）；流程差不多也能套 Codex、Cursor。
• Spec-Kit（指令 specify）：GitHub 開源的「規格驅動」工具箱，把憲法→規格→釐清→計畫→任務→實作做成固定步驟。
• SDD：規格驅動開發——先講清楚要做什麼、怎樣算過關，寫成文件，再請 AI 照著做。
• MCP：讓 AI 能直接呼叫外部工具／服務的接法；這集用 Hostinger MCP 操作主機商後台。
• VPS：虛擬專用伺服器，適合同時跑前端、後端、資料庫。
• Phaser：常見的 2D 網頁遊戲框架。

二、為什麼小工具行、全端就崩

功能單純時，把需求講清楚，AI 多半能搞定。一旦加上登入、商城、排行：

• 請它改一個功能，另一個常一起壞掉
• 開新的對話窗，過去的約定很容易沒了
• 做完了，卻不知道怎麼正式上線

作者的判斷：不是「AI 突然變笨」，而是系統變複雜卻沒有規格——人跟 AI 都會失憶。所以這集從頭走一遍 Spec-Kit，再部署上線，最後誠實講上線後還缺什麼。

三、開工前：環境、初始化、先備素材

確認 Node、Git、Docker 等都就緒後，用 uv 裝 Spec-Kit，再初始化專案（指定接 Claude）：

specify init web-survivor --integration claude

左側會看到 .claude（相關 Skill／SOP）跟 .specify（規格模板與腳本）。再裝 Playwright 類 MCP，讓 AI 能開瀏覽器做自動化驗證。

很多人會跳過的一步：先準備可合法使用的美術／音效（這集用 Kenney 等 CC0），並把 Phaser Skill 放進專案。素材範圍講死，AI 比較不會上網亂抓沒授權的檔案。

四、Spec-Kit 主流程：從憲法寫到任務清單

1. 專案憲法——先釘技術棧、Docker Compose 本機／部署共用、密碼與 API 驗證、.env 不進版控但要有 example、素材範圍、決策要寫進文件。AI 會幫你補「為什麼這條存在」。

2. 寫規格——直接寫清楚遊戲類型、一局怎麼跑、核心規則、開放決策（手感／數值可交給 AI 提案）、素材、成功條件（＝驗收清單）。

3. 釐清——跑 clarify，讓 AI 追問還沒想清楚的地方，回寫進規格。規格本來就不可能一次完美；別被「一行指令出完美系統」騙了。

4. 技術規劃——心裡已有技術組合就先餵給 AI（這集：網頁＋Phaser、自己熟的後端／資料庫、登入後才能交成績等）。

5. 拆任務——把複雜計畫拆成可勾的清單（依賴、驗收）；可選 analyze 交叉檢查規格／計畫／任務有沒有打架或缺漏。

6. 實作——任務齊了可清對話再開 implement，省 token。這集實作大概一小時級；做完一定要自己玩一輪。

五、親自驗證、修 bug、再上 Git 存檔

作者實測：訪客可玩、打怪與升級大致符合預期；註冊流程曾出現部分按鍵沒反應——原因是表單攔截了 WASD／空白鍵，請 AI 修完再重測。

基礎功能過關後立刻上 Git，並推到 GitHub。把 commit 想成存檔點：AI 改動幅度大，沒存檔常常回不去。環境變數、套件跟建置產物別進版控。

修明顯 bug 可以直接講；若是需求變更（手機直式、暫停鍵、武器圖示等），再走一輪 Spec-Kit，留下變更文件當決策紀錄。對話太長就清掉再開，別讓新舊需求混成一團。

六、Hostinger VPS：請 AI 幫你部署

專案同時有前端、後端、資料庫，適合放到 VPS。選延遲較低的機房、Ubuntu、開安全掃描／Docker 管理等選項後，在 Hostinger 開 MCP：只開需要的權限（例如網域／DNS、VPS），產生 API token（務必自己保管）。

設定寫進 Claude 設定檔並重啟，確認 MCP 工具連線後，直接跟它說：照 Docker 設定，把前後端跟資料庫裝到這台 VPS。先可用 IP 驗證玩一局；再買網域請 AI 綁定（這集示例 game.deanlin.tech）。

有了 MCP，AI 能直接操作外部工具，你就不用背每一家主機商介面——但下一節才是重點：做完 ≠ 做法正確。

七、上線後：你不知道你不知道

規格再完善，系統還是要反覆改。作者盤了幾件「沒提出來就不會自動出現」的缺口：

• 部署路徑：Private repo 時，AI 可能用 rsync 推「你電腦當下狀態」，而不是從 GitHub 拉版；多人協作會亂。比較穩的做法是 deploy key／推到特定分支自動部署。
• 資料與帳號：怎麼進資料庫看資料？忘記密碼、使用者管理有沒有做？
• 公開面防護：API 若沒有 rate limit（呼叫頻率限制），惡意腳本可以把資源打爆，正常玩家反而連不上。

一句話收斂：AI 很會完成「你提出來的需求」；沒提出來的，規格跟測試都罩不住。自己動手驗、反覆改，才能早點抓到問題。

八、跟 OpenSpec 怎麼選（作者看法）

• OpenSpec：步驟比較短，規格人讀起來比較舒服。
• Spec-Kit：每個環節確認比較嚴，產出比較偏給 AI 看；規格太長時人只能抓重點讀。

沒有誰絕對比較好，看你要「人好讀」還是「流程關卡嚴」。

九、可帶走的檢查清單

• 大專案先定憲法跟驗收條件，再讓 AI 動手
• 素材跟框架 Skill 先備好，少亂抓、少繞路
• 修 bug 可直講；需求變更走 Spec-Kit 留文件
• 早點 Git／遠端備份當存檔點
• MCP 部署後還是要問：從哪拉碼、資料怎麼管、公開面有沒有防護

※ 來源：YouTube 【Claude Code × Spec-Kit 教學】（工程師下班有約｜林鼎淵，約 28:19，上傳 2026-09-17）· 參考文章／連結見影片描述 · 本頁為非官方圖文整理