三十天回顧：把工作交給 Agent，也把接手的方法留下來

寫到第三十天，再看一次系列的名字：From (Unity) Game Dev to Orchestration of (Unity) Game Dev。

第一天想做的事很具體：讓 Agent 參與遊戲開發，從理解專案、修改程式，到取得測試與執行結果，逐步形成可以交辦、驗收與接手的工作流程。

實際寫下來，篇幅最多的卻是 Station、Plugin、Bundle、生命週期、權限、記憶與操作介面。Unity 一直是要回去的地方，開發工具本身則成了這三十天主要的實驗現場。

到了最後一篇，我想把這段路整理清楚：我們做過哪些嘗試，哪些失敗改變了工作的方式，以及這些準備距離真正用來開發遊戲，還差哪一段驗證。

從每天會用到的一件事開始

Day 001 選的是自動發文。

文章放在 repository 裡，Agent 讀取 Markdown、圖片與時間，操作瀏覽器，再回到公開頁確認結果。這件事的規模足夠小，又每天都會遇到，很適合先練習一個完整的工作迴圈：

觀察目前狀態
→ 決定這次可以做什麼
→ 執行操作
→ 重新讀取結果
→ 保存下一次需要的證據

一旦真的操作網站，就會碰到生成文字之外的問題。登入可能失效，草稿可能已經存在，按下按鈕後也可能沒有得到預期結果。下一次執行之前，需要先知道上一次究竟做到哪裡。

這些問題後來一直出現，只是對象逐漸換成 Agent session、背景 process、Plugin，以及工作區。

現在回頭看，第一天的案例已經包含了整個系列最常追問的事情：操作之後，要取得什麼證據，才知道下一步該繼續、停止，還是交給人處理？

三十天裡，問題怎麼一路改變

若依照當時要解決的問題，可以把這個月分成幾段。

中間出現了 BearPunch、Star、Comet、Blink、Saturn、Jupiter 等名字。它們承載了不同的實作與架構實驗，不能把某個 repository 的驗收結果直接套到另一個上面。Day 027 記錄的是 Jupiter 恢復 BearPunch 名稱；前面各條探索的能力，仍要各自核對。

這條路也有幾次停下來整理。Day 014 沒有新功能，重點是分辨設計、實作與驗證。Day 015 重新開啟 Jupiter，先處理分支、worktrees 與舊紀錄的關係。Day 029 則回頭確認，哪些工具已接起來，哪些還會卡住日常使用。

這些篇章讓後面的工作有了比較清楚的起點。下一位接手者可以知道該從哪份 source 繼續，也能找到尚未完成的檢查。

幾次卡住，改變了我判斷完成的方法

回顧整個月，最值得留下的，是幾個原本看似成功、繼續追問才露出缺口的例子。

第一個是 Day 008：Agent 做出了修改，工作仍未必能跨重啟延續。

當時 Saturn 已經能經由 Plugin 路徑啟動 Agent，完成一件受監督的小型程式修改。但管理它的 Station 從頭到尾都沒有重啟，外圍也仍有上層 Agent 協助處理。若 Station 消失，worker 與互動所需的 pipes 仍會一起消失。

保存下來的對話文字有助於回顧，卻不足以讓原本的互動繼續。這讓後續的驗收開始分別追蹤 process、輸出、身分與控制權，逐項確認中斷後還剩下什麼。

第二個是 Day 021：執行者接替時，必須連驗證責任一起交接。

兩個 Provider 先後遇到額度限制，留下的工作分散在幾個 worktrees 裡。有些子集已通過檢查，有些還有未提交修補，Client 接線也尚未完成。

那次由上層 Agent 協調的交接，保存了 source 位置、差異、已接受的部分與待驗證項目。它讓接手者知道，下一步要先處理什麼。原本負責 review 的執行者若改做實作，獨立檢查的責任也必須重新安排。

這份經驗很直接：交接時只留下「請繼續」，仍有太多事情需要下一個人重新猜測。

第三個是 Day 025、026：資料存了、找到了，還要確認最後交到 Agent 手上的是什麼。

召回品質改善後，正確紀錄可以排到前面，結果裡卻仍可能夾帶已失效的敘述。接著，context assembly 的探測又發現，工作需要的 review findings 雖被召回，卻在組裝時遭到排除。

於是「Agent 有記憶」被拆成幾個需要分開驗證的行為：資料是否仍適用、是否能被找到、是否屬於這個工作範圍，以及是否真的進入初始上下文。Manifest 記下選了什麼、排除了什麼，才有機會追查 Agent 為何少拿了一段背景。

第四個是 Day 027、028：測試通過與畫面有資料，都還需要追問來源。

Day 027 的 review 刻意移除 Station 身分檢查，原本相關測試仍全部通過，才發現測試沒有涵蓋連線目標被替換的情境。Day 028 的 Activity 畫面則曾經有資料，卻尚未接到即時事件；補上訂閱後，又因為收到自己的更新通知而反覆觸發。

這些案例讓我開始多問一句：如果那條重要規則被拿掉，哪個檢查應該失敗？如果畫面出現結果，能否沿著它找回實際的資料來源？

這樣留下的證據，才比較能支撐「這項行為已經驗證」的說法。

我對 Vibe Coding 的期待變得更具體

這三十天用了很多 Agent，也花了很多篇幅處理它們周圍的系統。對我來說，這段經驗讓 Vibe Coding 多了一組很實際的工作要求。

交辦之前，要把想要的行為與可修改範圍說清楚。執行途中，要知道 Agent 正在哪個專案、使用哪些工具，以及哪些決定需要人介入。交回結果之後，要把 diff、測試與原先要求放在一起看。

這也改變了我想保存的東西。

這份資料可以先以簡單的工作說明與交接紀錄保存，再依實際需要放進工具。每次接手若還得重新確認同一批事情，就能從那裡找出值得自動化的部分。

人的工作也跟著改變。我需要花更多心力決定什麼值得做、驗收要看什麼，以及遇到不確定狀態時該如何處理。Agent 可以協助實作與調查，接受結果的理由仍需要能被說清楚。

到第三十天，成果與缺口一起留下

沿用 Day 028、029 已核對的範圍，這段系列留下了幾組可以繼續使用的基礎。

工具與 Skills 能依工作設定配發；記憶可以查詢，初始上下文也有可追查的組裝清單。人與外部 Agent 開始經由 App 連到明確的 Station。Workspaces、Sessions 與 Activity，則提供辨認工作範圍、操作請求與觀察事件的入口。

但要判斷它們能否支撐日常開發，前文的缺口也要一起帶著。

前文核對到的 BearPunch 主線是 e8796d8。本篇以這份既有紀錄作為回顧終點；各篇屬於 Saturn 或早期實驗的能力，沒有因此全部成為這份主線的功能。

同樣地，這三十篇沒有提供一份已交付並驗證的 Unity consumer，也沒有量測使用 BearPunch 後的遊戲開發工時改善。這部分成果要等實際工作留下證據，才能接著寫。

下一段路，從一件 Unity 修改開始

Day 029 留下的候選情境，我想繼續保留：在 Fantasim 選一個 Unity Component，修正一項能用 Edit Mode test 重現的行為。

具體的 Component 與問題仍要從專案裡挑選。下一次開始時，可以先把驗收縮到以下範圍：

1. 確認工作目錄、Git 基線，以及 Unity Editor 實際開啟的 project。
2. 寫清楚錯誤如何重現、預期行為與允許修改的檔案範圍。
3. 讓 Agent 經由預定的工作入口處理修改，記錄期間需要人工補上的步驟。
4. 檢查實際 diff，保留修改前後的測試結果，確認測試確實針對這項行為。
5. 留下驗收判斷、未解問題與接手說明，讓下一次工作能從這裡開始。

第一次跑這條路，我最想知道的是自己在哪裡仍必須停下來：補背景、找核准請求、確認測試對象，或重新整理上一次的結果。

這些介入都有機會變成下一件具體工作。若卡在目錄設定，就先把操作修好；若 Agent 做完了卻找不到測試證據，就補上結果的保存與對應。等一件小修改能被清楚地交辦與接受，再擴大工作範圍。

寫完三十天之後

這個月留下了文章、程式與一批驗收紀錄，也留下幾次改方向的理由。有些日子適合往前實作，有些日子則需要停下來，把分支、失敗與尚未完成的承諾整理清楚。

對我而言，最有用的收穫是：現在談到「把工作交給 Agent」，我會接著想，它從哪裡取得背景、如何回報狀態、誰來接受結果，以及中途停下來之後要留下什麼。

系列寫到這裡，回到 Unity 的下一步也更具體了。找一件值得修的小問題，讓這些工具實際承擔一次工作，再用結果決定接下來的方向。

謝謝讀到這裡的人。這三十篇先把走過的路、碰到的問題與當時的判斷留下來；下一段，就從一件能親自驗收的遊戲修改開始。

本文依本 repository 的 Day 001–029 文章整理，功能與驗收敘述沿用各篇當時記錄的範圍。本次未重新查核 BearPunch 今日主線或重跑其 gates，文中的 Unity 任務仍是後續驗證計畫。