CodeBuddy NPC：用 @mention 驅動嘅 AI Native Git 協作流程

CodeBuddy NPC 嘅關鍵，係將 AI 放進現有 Git 工程系統之內，而唔係當佢只係 IDE 或網頁旁邊嘅問答工具。開發者喺 Issue 或 PR 用 @ 點名某個角色，NPC 就會由事件觸發，非同步跟住程式庫內嘅工作紀錄處理任務：先調查，再規劃、實作、建立 PR、跑 CI、分析失敗原因、修正，然後重新驗證。16

Git 變成 AI 嘅工作上下文

所謂 AI Native Git，意思係將 Git 程式庫、歷史紀錄、Issue、PR、CI/CD 結果同品質閘口，當成 AI 持續可用嘅工作上下文。團隊毋須反覆將需求、程式碼片段同 build log 複製去另一個聊天視窗；NPC 直接圍繞呢啲工程產物做嘢，沿用既有開發流程。17

要留意，現有文件描述嘅觸發位置係 CNB 入面嘅 Issue 同 PR：issue.comment@npc 可由 Issue 描述或留言中提及 NPC 觸發；pull_request.comment@npc 則可由 PR 描述、審查或留言中提及 NPC 觸發。6 呢個概念同「喺 GitHub Issue 點名 AI」相似，但提供嘅資料主要證明 CNB 自身平台嘅機制。

NPC 隊友可以按 repository 定義

CNB 容許團隊喺 .cnb/settings.yml 為 repository 設定 NPC，包括角色名、prompt、知識庫匯入、頭像同互動按鈕等。例如可分成負責實作、程式碼審查、問題調查或專案協調嘅角色。3

如果要令角色喺被點名後採取特定步驟，團隊可以再喺 NPC 所屬 repository 嘅 .cnb.yml 定義事件流水線；如無自訂，系統會使用預設 NPC 執行環境。6 呢種設定令較大型工作可以由多個專責 NPC 分工，而唔係所有要求都交畀同一個通用助手。

由一句 @mention 到交付循環

一次典型流程可以理解為：

1. 開發者喺 Issue 或 PR 留言，以 @角色名 指派工作；
2. NPC 讀取程式庫及相關工程內容，調查問題並擬定方案；
3. NPC 實作改動、建立 PR，並執行測試或流水線；
4. 如 CI 失敗，NPC 根據結果修正，再跑驗證；
5. 工作成果連同 PR、commit、留言同流水線紀錄，留喺團隊原本嘅協作軌跡之中。17

因為工作係非同步進行，開發者唔需要全程停留喺互動式對話等 AI 一步步回覆。不過，系統能夠完成循環係架構能力描述，唔代表每一類改動都必然適合跳過人手 review。17

CNB 提供執行環境同權限邊界

NPC 背後需要唔止模型，仲需要可重現嘅工程環境。CNB 流水線 YAML 可指定 Docker image、用 Dockerfile 建立臨時 image、devcontainer、掛載 volume，以及帶 CPU 標籤嘅 runner；亦支援 Docker cache，以減少重複下載依賴。45

權限方面，流水線運行期間會注入臨時 CNB_TOKEN，可用於程式碼與制品拉取、推送及 API 呼叫；令牌喺流水線結束後會自動銷毀，而權限取決於觸發事件類型。以 NPC 身份運行時，文件列出可獲程式碼、PR、Issue 同留言等讀寫權限。15

換言之，AI 唔係攞住長期、無限制憑證喺開發者部電腦任意操作；佢係喺流水線及事件規則所界定嘅環境和權限內執行。

可追溯，亦方便企業管治

由 Issue 指派、PR 提交、commit 改動到 CI 結果，所有關鍵步驟都留喺既有 Git 協作物之中。對團隊而言，呢個比將工作散落喺 AI 對話紀錄更容易追查「邊個要求、AI 做過乜、改咗乜、測過未」。17

涉及敏感資料時，CNB 嘅密鑰倉庫文件提到存取控制、操作限制、審計日誌同浮水印等保護措施，並可由流水線設定匯入密鑰檔案作環境變數。9

成本主張：靠減少無效上下文與工具輸出

騰訊將首輪 token 消耗由逾 20,000 降至約 2,000、即超過九成嘅降幅，歸因於持續優化 prompt、工具呼叫、CLI 輸出及快取命中率；同時會按任務難度採用相應模型策略，而非所有任務一律使用最昂貴能力。811

整體而言，CodeBuddy NPC 所講嘅「AI 工程協作」，唔只係叫 AI 幫手寫幾行 code，而係令 AI 透過標準 Issue、PR 同 CI/CD 流程接收工作，喺真實嘅建置、測試、權限同政策控制下完成回饋循環。呢個模式嘅價值，在於將 AI 變成一位可配置、可管治、可追溯嘅團隊成員，而唔係一個脫離交付流程嘅聊天機械人。17