在AI的努力之下，加了相當多的機制和workflow去防止runner一直執行造成的問題，再加上runner用量恢復，終於又可以開始用GitHub Copilot了。

而昨天晚上開始，試著用GitHub Copilot的網頁版。它裡面有Space的功能，目前處於Preview的狀態。昨晚問它Space和在Visual studio code裡的GitHub Copilot agent mode有什麼不同之處時，它的回答是所有在Space裡的discussion，都可互相參考到，但vsc裡的agent mode只有該session有相關聯。當時給的想法就是GitHub Copilot Space和Chat-GPT裡的Project是相等的。

然而，今天早上於Space裡另開一條Discussion，並詢問它之前相關的問題時，它居然直接回答說它只能看到同一個discussion裡的引用，而不能看到其它在同一個Space裡的discussion的內容。這樣我當下很費解，不停的詢問，最後終於認清了是昨晚它的回答應該是不正確的。反正每個回答都有其免責聲明，也不能說它欺騙。

奇特的是今天突然發現有不少的RFC都轉換成GitHub Issue，並且都已經完成了(!?)，本想說如果都按照原先所定的RFC進行，那執行完成就意味著已經具有一定的功能。可是一拿下來執行時就發現根不是這麼一回事，無法執行。

比方說由RFC轉換成如下的issue

Objective: Build provider selection and service registry system for dependency injection
Requirements:

Create GameConsole.Core.Registry project targeting net8.0
Implement IServiceRegistry interface for service registration
Add ServiceProvider class with provider selection logic
Create ServiceDescriptor for service metadata
Implement service lifecycle management (Singleton, Transient, Scoped)
Add service resolution with dependency injection support
Implementation Details:
Use Pure.DI compatibility patterns
Support both programmatic and attribute-based registration
Implement circular dependency detection
Add logging for service registration and resolution
Support conditional service registration
Include performance optimizations for service lookup
Acceptance Criteria:

ServiceRegistry handles all lifecycle types correctly

Circular dependency detection prevents infinite loops

Service resolution performance <1ms for cached services

Unit tests achieve >95% code coverage

Integration tests validate Pure.DI compatibility

Memory usage remains stable during service resolution cycles

由於是完成採取只要PR有commit進來，並且沒有其它的錯誤就進行approve pr, merge並關閉的動作。其實沒有辦法可以確定這個pr是否達到了預想的功能，就算是有test，沒有明確的test目標之下，其實AI也不可能精準的產生出test。

在正常開發的情況下，應該會有人進行pr的檢試，並於多次的討論來回修正後達到一定的”標準”後才會approve, merge。但這裡完全採用AI產生出一個版本的程式碼後，就直接將其產出物直接合進到main裡。採取此流程和實際的開發方式不同，主要也是為了要試驗這樣的模式是否適合以AI為主體的開發。

正常的開發因為已有明確的方向，故可以花時間在打磨程式碼以期品質達到一定的水準，但在已AI為主體發想並開發的流程下，並不會要求一步到位，先用大略的方式將其製作到一個階段後，看到了實際產出的呈現後，再進行和AI多次的溝通，再利用agent進行現有程式碼的週整。一直反覆這個流程直到有可接受的版本出來。

如同一開始提及的地城生成概念，AI產生的程式碼雖然大致上有個方向，但每次都會產出不同的程式碼。只要大方向相同，接下來就是慢慢地修正或是增加其精細度。反正AI在產生RFC時也不是一次到位，先順著這個方向開發，再做調整。

不過整個App暫時也還不能執行，要先進行修正才知道agent達到了RFC多少百分比的功能，但今天至少解決了runner過度使用，也算是在預期之內。