這 30 天做出來的《異世界救援》，目前還在上架流程中，還不能直接下載遊玩。
先放一段實際操作影片，讓大家看看這個專案最後做成了什麼樣子。
這三十天，我幾乎每天都會跟 AI 開啟一個以上的新對話。對話一旦重開，AI 就不會自動知道昨天做了什麼，也不一定記得前幾天為什麼做出那些決定。
所以，這次做遊戲的過程中，我也開始摸索怎麼替 AI 留下「記憶」，把專案進度、開發歷程和重要決策寫進文件裡。
實際做下來，我發現光是記錄進度還不夠。AI 也需要知道專案有哪些工作規範、過去做過哪些決定，以及目前還有哪些事情要處理。
因此，我把這些資訊分別整理到幾種不同用途的文件中。
CLAUDE.md：專案操作手冊這份文件告訴 Claude Code，專案是什麼、開始工作前要讀哪些文件、開發時有哪些規範，以及 commit、部署和上架前有哪些事情需要注意。
例如，這個專案有四個獨立的 Git repo，不能把 doc/ 當成主 repo 裡的一般資料夾處理。每次完成一段工作，也要分別檢查 DEVLOG.md 和 HANDOFF.md 是否需要更新。
這些規則寫在 CLAUDE.md，讓 Claude Code 開始工作時，有明確的指引可以依循。
HANDOFF.md：目前進度記錄專案現在做到哪裡、有哪些已知問題，以及接下來要做什麼。
每次工作結束後更新，讓下一次對話知道從哪裡接手。它比較像交接摘要，不需要把每次除錯的過程全部寫進去。
DEVLOG.md：開發歷史記錄重要決策、遇到的問題、嘗試過的方法，以及最後為什麼這樣修改。
這份文件只往後新增，不覆蓋舊紀錄，保留專案一路走來的過程。
如果沒有先把重要細節寫進 DEVLOG.md，它們就只存在於當次對話裡。對話結束之後，想再找回當時的決策原因，就得重新翻找，甚至重新推導。
project_specs/PLAN_*.md：功能規格用來整理需要多次討論的大型設計，例如世界觀、王國擴充和變現機制。
等設計逐漸確定，再把需要的結果整理回交接手冊和開發日誌，讓規格、進度與歷史紀錄各自發揮作用。
這些文件不是寫得越多越好，重點是要知道什麼資訊該放在哪裡。否則文件一多，連 AI 都可能找錯地方。
但有文件，不代表一切就會自動同步。
有一次，DEVLOG.md 新增了紀錄，HANDOFF.md 卻忘了更新；也有一次，交接手冊寫得很完整，開發日誌卻沒有留下對應紀錄。
文件沒有同步更新，下一個 AI 就可能接錯進度，甚至找不到重要決策的原因。
所以我後來多了一個習慣：每次結束工作前，請 Claude Code 比對程式和文件，確認進度與紀錄是否一致。
不過，Claude Code 也曾把已經記錄在其他文件中的項目，誤判成可能遺漏。所以，即使請 AI 幫忙檢查，我還是得確認它的判斷是否正確。
三十天前，我對 Godot 和遊戲開發還很陌生。這三十天，我跟著 AI 寫程式，也會追問它為什麼這樣寫。遇到問題時，就再一起找原因。
要說自己已經入門，可能還稱不上。現在再看 YouTube 上的 Godot 教學影片，倒是沒那麼陌生了。看到一些名詞，我開始知道它們在遊戲裡負責什麼，也比較能跟上教學的內容。
至於把遊戲正式上架，還有不少事情要處理。除了程式碼，還得確認遊戲在不同平台能正常運作，處理測試、權限、簽章和商店送審等工作。這些事情不會因為 AI 寫程式很快，就自動完成。
《異世界救援》是這三十天最大的成果。另一個重要的收穫，是我練習指揮 AI Agent 完成任務，也懂得把這次累積的經驗留給下一個專案。
例如，這個專案已經整合了 AdMob。假設下一個專案也要接入 AdMob，我不必讓新的 AI 從頭研究該用哪個套件、怎麼整合，可以直接請它參考《異世界救援》的現有實作。
透過閱讀程式碼和相關文件，它就能了解目前採用的整合方式與既有設計，不必每次都從零開始摸索。
一個專案累積的經驗，可以成為下一個專案的起點。
這也讓我重新看待文件這件事。
大家都知道文件很重要，但工程師常常忙著把功能做完，沒時間補文件。也有人說「程式碼就是文件」，但即使程式碼寫得很完整，也不一定能看出當初為什麼選擇這種設計、考慮過哪些替代方案，以及最後為什麼放棄其他做法。
以前寫程式時，常常想著先把功能做完，文件以後再補。結果一忙起來，就忘了當初為什麼這樣改。
現在我可以在工作告一段落時，直接請 Claude Code 整理這次做了什麼、為什麼這樣做，以及測試結果。至少不用等到有空，才想起還欠一份紀錄。
當然，AI 寫下來的紀錄還是需要檢查，不能因為文件存在，就認為內容一定正確。
這次做完《異世界救援》，我留下的不只是一個遊戲，還有一套可以帶到下一個專案繼續使用的工作方式。
AI 寫得越完整、說得越有道理，就越容易讓人直接相信。所以除了自己測試，也可以讓另一個 AI 交叉檢查。
Day 27，Claude Code 審查 Gemini 提出的 MainMenu 規格，發現它會跳過選牌流程，破壞原本的遊戲流程。
Day 29，Claude Code 查了設定、文件，甚至追到 Godot source，認為 iOS 雙方向旋轉可能是引擎限制。最後我自己檢查，才發現只是 Project Settings 的 Orientation 沒有選對。
AI 查了很多資料，不代表一開始的前提就是對的。
三十天前，我只有一個想法：
做一個 Godot 遊戲。
三十天後，我真的做出了一個可以玩的《異世界救援》。
這三十天，我用 Gemini 討論想法、規劃功能，再讓 Claude Code 動手修改程式。從一開始不熟悉 Godot，到後來能追查問題、檢查 AI 的提議，也逐漸找到適合自己的協作方式。
Vibe Coding 有人喜歡，也有人質疑。對我來說，AI 降低了開始開發遊戲的門檻，讓原本沒有遊戲開發經驗的我，也能一步步把想法做成可以玩的作品。
它可以幫我加快開發，但最後做出來的東西好不好、是不是符合自己的想法，還是得由自己判斷。
這次參加鐵人賽，我不只完成了一個遊戲，也親自走過了用 AI 從零開始開發、測試，再一路準備上架的過程。
寫完這三十天，我又翻了一下以前參加鐵人賽的文章。
突然發現，這些系列文其實很像我替自己留下的 DEVLOG.md。
每次開新的 AI 對話，都需要讀取 HANDOFF.md、DEVLOG.md，才能知道專案之前發生過什麼。
人好像也一樣。
如果沒有這些文章，過幾年再回頭看，我可能只記得「2026 年好像做過一個 Godot 遊戲」，卻忘了當時為什麼想做、遇到什麼問題，又是怎麼一路走過來的。
回頭看這幾年的鐵人賽，我才發現自己研究過不少不同的東西：
從機器學習、跨平台開發、工作自動化，到生成式 AI、Swift，再到用 AI 閱讀經典，這些年研究的主題一直在變。到了今年，乾脆叫兩個 AI 一起幫我爆肝寫遊戲。
每一年學的東西都不一樣，但這些文章把它們串成了一條線。
只有 2022 年沒有留下系列文章。現在反而有點可惜，因為我已經想不起來那一年到底在研究什麼。
所以這幾年的文章，我會繼續留著。以後忘記了，至少還能回來看看。
《異世界救援》如此，這些鐵人賽文章也是如此。
明年再回頭看，我至少不會只記得「2026 年好像很忙」。
我會記得，那一年我做了一個 Godot 遊戲，還曾經叫兩個 AI 幫我一起爆肝。
有網友說，可惜錯過了鐵人賽的開賽日期。
其實，寫下學習紀錄，不一定要參加鐵人賽。
平常學了一個新工具、完成一個專案，或是解決了一個困擾自己很久的問題，都可以整理成文章，放在自己的部落格裡。當下可能只是想記錄一下，過了幾年再回頭看，這些文章就成了自己的學習資料庫。當初為什麼這樣做、遇到什麼問題、最後怎麼解決，都還有跡可循，不必只靠記憶。
鐵人賽提供了一個集中寫作的機會，但留下學習紀錄，不必等到參賽才開始。
iThome鐵人賽
看影片追技術