前兩個星期，我完成了 ZenGTPX。它可以將 Zen7（天頂圍棋）包裝成標準 GTP 引擎，除了可供人機對局使用，也能與其他圍棋 AI 引擎進行自動對局。
🔗 https://github.com/kenming/ZenGTPX
我把 ZenGTPX 加入 LizzieYzy Next，作為其中一個 GTP 引擎。如此不僅可以在該介面內進行人機對局，也能安排 Zen7 與 KataGo 等不同引擎進行自動對局。
🔗 https://github.com/wimi321/lizzieyzy-next
不過，LizzieYzy Next 原本的引擎設定介面主要提供通用的啟動與對局參數，無法直接呈現 ZenGTPX 專屬的棋力設定。
ZenGTPX 提供三種棋力設定模式：rank、fixed-time 與 advanced。
rank 模式最為方便，只要直接設定棋力，範圍從 6 級到 9 段即可；fixed-time 模式則固定每手棋的思考時間，實際能完成多少搜尋計算，仍會受到 CPU 運算效能影響；advanced 模式提供更細部的參數設定，可透過 Config 設定檔調整多組 Zen7 搜尋參數，包括部分原 Zen7 GUI 未直接提供的底層設定，用以進一步微調棋力與搜尋行為。
因此，我在 LizzieYzy Next 的 GitHub 提出了一篇 Issue，希望它可以支援 ZenGTPX 的棋力參數設定。
作者好有心，很快就回覆，並且提出一個更具擴展性的方向：由 GTP 引擎透過穩定的擴充協定，自行提供設定 Schema、目前生效值、參數驗證與 Profile；LizzieYzy Next 則負責偵測引擎是否具備這項能力，並依據 Schema 自動產生設定介面。
如此一來，這套機制不會只適用於 ZenGTPX，未來其他支援標準 GTP 協定的 AI 引擎，也可以使用相同方式擴充自己的專屬設定。
從設計角度來看，這是以擴充協定、能力偵測與設定 Schema 為核心的 Plugin 設計。LizzieYzy Next 不需要預先知道各種引擎有哪些參數，而是由引擎自行描述能力與設定內容。
🔗 https://github.com/wimi321/lizzieyzy-next/issues/101
我依照這個方向，在 ZenGTPX 端完成了 Configuration Protocol v1；LizzieYzy Next 作者則在 Next 端完成通用協定的偵測、設定介面、Profile 保存、執行中套用、多引擎設定隔離與錯誤處理。
作者先使用模擬的 fake ZenGTPX Process 跑過完整流程，驗證能力偵測、設定、保存與重新啟動後的 Profile 還原。自動化測試全部通過後，他提交了 PR #126，將這套通用的 GTP 引擎棋力設定機制整合進 LizzieYzy Next。
🔗 https://github.com/wimi321/lizzieyzy-next/pull/126
PR 合併後，作者希望我協助進行 Windows 與真實 Zen7／Zen.dll 的整合驗證。
我先使用 VS Code 開啟原來的 ZenGTPX 專案，再將 PR 連結交給 Codex 分析。Codex 隨即取得相關分支內容，並整理出兩組可供 LizzieYzy Next 使用的 ZenGTPX 設定檔；接著我再請 Codex 啟動 LizzieYzy Next，讓我直接進行實機驗證。
實際測試結果完全正常。rank、fixed-time 與 advanced 三種模式皆可正常顯示與套用，設定保存、執行中更新、重新啟動後還原，以及相同執行檔的多引擎 Profile 隔離也都沒有問題。
完成測試後，我將結果交給 Codex 整理成 PR 回覆。作者之後又在最新的主分支上重新執行相同測試，確認全部通過，最後正式關閉原來的 Issue。
整個遠端協同開發的過程，不到一個星期便完成了兩個應用程式的擴展整合。真正讓我感到有意思的，並不只是功能最終得以實現，而是整個合作過程幾乎完全建立在 GitHub 的標準協作機制上：先透過 Issue 整理需求與交換設計想法，再由開發者建立獨立分支完成實作，透過 PR（Pull Request）公開變更內容，交由另一方測試、驗證與回報，最後才合併至正式版本。
雙方不需要共享相同的開發環境，也不需要頻繁召開會議或同步各自的工作進度，只要將需求、協定、程式變更與驗證結果清楚地留在 Issue 與 PR 中，便能各自在相對獨立的情況下完成工作。這正是一種 Loose Coupling 的協同開發模式：彼此保持低度依賴，卻能透過明確的介面、流程與可追蹤的紀錄，快速完成跨專案的合作與整合。