我從 25 年前就開始斷斷續續寫日記，寫了好多年，從一開始的手寫筆記本，到後來的手機電腦雙端雲端筆記，到現在的 md 檔，工具的轉換見證了時代變革。為什麼說是斷斷續續，因為沒有固定的輸出機制倒逼，完全靠興致的話，很容易冷一陣熱一陣。 七月底構建個人網頁的時候，決定換個做法：每天的想法、進展隨手丟進素材箱，隔一到兩周給 claude 整理，看有什麼值得提煉或展開的地方，然後我再來成稿。有每天固定的 scheduled AI 會追著我問當日進展後，"想起要記錄" 這件事就被系統解決了，只剩下真的去記錄本身，剩下如何從腦子裡挖掘出有用的內容。這篇就是第一次整理出來的東西。
Crypto Adventure
Crypto Adventure 是我現在主要在實驗的網頁 AVG 遊戲，感謝 AI，讓我終於能開始把多年來的想法落地。詳情寫在另一篇裡面了，可以點過去看。這兩週做了兩件事：把存檔機制修好，以及把敘事的呈現方式整個換掉。
存檔：從瀏覽器裡的七天，到本地雲端雙自動存檔
原來本地存檔和雲端存檔是兩套邏輯，會打架，現在有 slots 可以開新遊戲，本地與雲端同時自動存檔。雲端用的是 vercel 上的 Neon。
我在開發初期先採用了最簡易的方式來儲存進度，也就是僅存在瀏覽器的 localstorage 裡面，只有我一個人在做這遊戲，不涉及多端，測試也方便。但一件事讓我改變了路線，就是在得知 Safari 的 localStorage 有個七天規則時：玩家連續七天沒打開你的網站，WebKit 就會把整個本地儲存自動清掉。玩家放置一週回來發現存檔沒了，這對遊戲來說可不是什麼好事，於是萌生了保存在雲端的想法。借鑒玩 nonogram 的經驗(一個數字圖畫解謎遊戲，想放鬆腦子時就會拿出來，累積玩 1000+ 小時了)，最簡易的方法可能是每個玩家有個帳號，進度綁定帳號，實時上傳雲端。
聽起來容易，不就是同步嘛，實際上隨著實作，發現要考慮的問題越來越多。如果兩台裝置 AB 同時登入同個帳號，但選擇了不同路線導致檔案衝突怎麼辦？如果拿著裝置 A 在斷網的時候繼續玩，裝置 B 沒有推進但聯網，因此裝置 B 有更新的雲端同步時間戳，但實際上裝置 A 的進度更靠前，一旦裝置 A 要聯網就會有同步問題，怎麼處理？如果玩家選擇重新開始，是直接覆蓋舊存檔嗎，已經收集過的詞條怎麼處理？如果重新開始是因為一周目結束了要進行二周目呢，邏輯又相同嗎？
越思考，越發現腦子不夠用，根本不是一句"雲端同步"就能解決的。後來還是靠 gpt 和 claude 不斷拷問彼此、更新方案、修復問題，才暫時結案。
敘事：從視覺小說改回傳統 AVG
敘事這件事暴露出我另一個，由於沒思考清楚就直接投入實作，所造成的問題。
寫故事的時候我是按照寫小說的方式來的，直接敘述的方式會把場景如何、哪個角色什麼動作、誰說了什麼，都融合在一起；然而傳統 AVG 由對話驅動，更像是劇本的寫作方式，需要把不同屬性的內容都拆開。當我意識到這個問題時，已經把一條故事線實裝了，呈現形式是點擊出段落內容，就像在讀小說一樣。
這時候我讓 AI 做了個調研，是繼續保持現有的方式，還是改成傳統 AVG？AI 調研回來說有很多受歡迎遊戲都是敘事型 AVG，玩家們對此很熟悉了，保持下去沒問題。我沒有繼續提問，深入思考敘事型跟對話型的本質區別，就接受了結論。
直到把所有故事都寫完、串完，拿給 Sama 試玩時，他說，好多文字看得好累，有角色對話為什麼看不見角色長啥樣呢？不太有沉浸感。並且，從下方彈上的選項好像在考試啊......
這時候我才發現，一直藏在心底的隱隱不安是有道理的。敘事型更需要有其他遊戲機制來支持，極簡的敘事型鳳毛麟角，對話型有人物立繪、背景圖片，更容易把玩家帶入到故事中，而我想做的正是深入角色關係、用選擇驅動故事的遊戲，更適合後一種。
那就改吧。
學到什麼
- 雖然說實踐出真知，但實作前多討論、多推演，建立起比較完整的方案，沒有明顯漏洞，心裡也沒有疑惑了再動手，能減少不少返工。
- 不同功能不要混同一個 branch，更別說是同 commit 了，想要乾淨 rollback 某個功能會很困難。
- 從敘事改成對話之後，AI 寫作最大的缺點露出來了：它可以寫敘述，但特別不會寫對話，可能是英文翻譯成中文的緣故，有股味兒。雖然本來就是要自己重寫的，只是先把架構跟發展路徑定下來，但是現在看起來就特別彆扭。
- 想了一圈別的遊戲的存檔是怎麼演進的，從以前單機手動存檔，到單機多 slots 有手動有自動，到多端雲端自動存檔，其實就是各種資源配置的取捨。也終於理解為什麼有時候打遊戲中途斷線，再登進去人物的位置會跟斷線前差一小段。
AI 協作
四月和現在：差了三個月，也差了一個量級
重整個人網頁的時候，發現上一次更新是四月。四月時我用的是 VSCode 的 Codex 插件，還有 Antigravity 裡的 Gemini，就是一句一句講、確認、調整。有很多敘述、也給了參考圖，但做不到的地方就是做不到。例如「山」的形狀要幾層、誰疊誰、顏色怎麼調，只口述的方式下都沒法盡如人意。過了三個月，現在版本的 Claude，已經可以直接出一個完整改良方案，它會從更全面的視角思考，還會模擬幾個不同方案，直接把結果用圖片展示，差別很大。
如果要精細化調整設計稿，進 Claude Design 更合適，他靠代碼控制每一個部件，不像 gpt 或 gemini 靠一次性渲染出圖，試錯成本因此低很多，可以反覆折磨設計師反覆修改:D。
看看我給 IMC 國際工商研究社設計社長交接刊物封面的範例就明白了：
我現在的全局 Instructions
出方案的時候有幾條原則壓著，不容易跑偏，能大大降低返工。這是我現在的全局 Instructions：
- 定方案時如有需要，一條一條跟我討論確認
- 開發功能的時候，用奧卡姆剃刀，如無必要，勿增實體
- 驗收測試的時候，用墨菲定律，凡是可能出錯的，一定會出錯
- 解決問題、修 BUG、設計架構或者方案的時候，從第一性原理出發
- 在做完相對比較複雜的任務後，可開啟多次級 Agent 進行對抗性審查
- 讓任務分給子 Agent 做的時候，用科斯定理過一遍
- 生成簡報時不要給思考過程和評論，只要結論，每個區塊必須有清楚邊界，同樣內容不可以出現在不同地方
學到什麼
- 不管是規劃、實作，或是 debug，但凡稍微複雜點，先出方案再動手，都比直接動手來得強。
- 出方案的時候善用第一性原理、莫非定律、奧卡姆剃刀、對抗性審查，也就是拿上面那份 Instructions 壓陣。
- 讓兩家不同模型互相來回也很重要。我都是用"我同事說..."在 GPT 跟 Claude 間輪流給對方反饋，他們會說"這個反饋很扎實，我核實了，他說的大致是對的"，然後給更完善的改進方案。
- 建立方案->實作->發現問題->改進問題->把改良方式落進文檔裡面->再實作，幾輪跑下來，基本上能把一個工作流完善。
- 給 Sama 測試遊戲的時候，本來用英文跟他解釋，後來索性直接把 GitHub repo 給他，他自己讀代碼、拿 AI 問問題出反饋意見，比跟我聊更能了解這個遊戲的細節。這個年代分享項目倉庫比口頭解釋快多了。