騰訊雲的 CodeBuddy NPC，想解決的不是「怎樣讓聊天式 AI 多寫幾行程式」，而是「怎樣讓 AI 真正進入團隊每天交付軟體的流程」。

做法是把 AI 放進 CNB 的 Git 工作流：開發者在 Issue 或 Pull Request（PR，合併請求）中 @ 提及一個 NPC 角色並交辦任務後，AI 可在雲端非同步讀取專案脈絡、規劃方案、修改程式、送出 PR、跑測試；若持續整合（CI）失敗，還會讀取紀錄並嘗試修正，再進行下一輪驗證。開發者不必全程守在聊天視窗裡等待。 16

值得留意的是，所提供資料對正式發布日期有不同說法：多篇同期報導指向 2026 年 7 月 23 日，另有後續報導寫為 7 月 29 日。 625

「AI Native Git」：把工程紀錄變成 AI 的工作記憶

騰訊雲將這套方法稱為 AI Native Git。意思並不是 AI 只會讀 Git 程式碼，而是讓程式庫周邊原本就存在的協作紀錄，成為它持續工作的上下文：

• Issue：任務背景、目標與討論，也就是需求脈絡。
• 程式碼庫與歷史紀錄：專案結構、相依關係與過去變更。
• PR：變更提案、程式內容與審查意見。
• CI/CD 結果：建置與測試是否通過、失敗原因，以及修復過程。

因此，它和一次性的程式碼補全或聊天問答不同。AI 不必由人反覆貼上需求、程式片段與錯誤日誌；它在團隊原有的工程紀錄中取用資訊，也把自己的變更與驗證結果留回同一套紀錄。騰訊雲表示，這種模式可重用既有 Git、Docker、CI/CD 與品質關卡，形成「提交 → 驗證 → 修復 → 再驗證」的閉環。 123

如何在 Issue 或 PR 裡「@ AI 派工」？

CNB 文件列出兩個與 NPC 有關的事件：

• issue.comment@npc：在 Issue 描述或留言中提及 NPC 時觸發。
• pull_request.comment@npc：在 PR 描述、審查內容或留言中提及 NPC 時觸發。 35

對開發者而言，操作邏輯近似於 @ 一位同事：在 Issue 或 PR 指定角色並寫下任務，例如請它調查問題、實作功能，或審查某項變更。這些任務不要求另開一段持續互動的 coding chat。

團隊也能在 .cnb/settings.yml 為程式庫設定專屬 NPC，包括角色名稱、提示詞、匯入的知識庫與介面設定；若有需要，還可以在 .cnb.yml 定義其自訂行為與執行環境。CNB 文件指出，若未自訂，系統會使用預設的 NPC 執行映像。 3235

這使它不只是單一泛用型助手。一個團隊可自行設計「問題調查」、「功能實作」或「程式碼審查」等角色，並在最適合的流程節點呼叫它們。

從任務到可審查 PR：非同步交付循環

CodeBuddy NPC 的流程核心是非同步執行。接到任務後，AI 可取得程式庫上下文、擬定方案、修改程式、提交 PR、執行測試，並根據 CI 回饋繼續調整。 16

可將其工作循環理解為五步：

1. 在 Issue 或 PR 指派任務：以 @ 提及觸發 NPC 事件。
2. 讀取工程上下文：結合任務內容、程式庫、現有變更與既有流程紀錄。
3. 規劃並實作：提出處理方向，接著撰寫程式變更。
4. 提出 PR 並驗證：以測試與流水線檢查變更是否可行。
5. 面對失敗再迭代：若 CI 未通過，讀取錯誤結果、診斷問題、更新變更後再次驗證。 1623

所以騰訊雲強調的，不只是 AI 產出一段建議程式碼，而是讓它參與把一個任務轉化為「可審查、可測試的變更」這段工程程序。

CNB 是執行層，也是控制層

AI 要能建立分支、送 PR、跑測試或處理失敗，不能只有模型能力，還需要可重現的執行環境及受控權限。這正是 CNB 扮演的角色。

CNB 的流水線設定可指定 Docker 映像、由 Dockerfile 建立的映像、dev container 環境、掛載磁碟區，以及 runner 標籤或 CPU 設定。如此一來，建置與測試可依程式庫定義的環境重複執行，而非依賴某位開發者電腦上的個人設定。 34

CNB 也支援重用 Docker 快取，後續建置可避免重複下載相依套件等網路資源。 33

在授權方面，CNB 會在流水線執行期間提供 CNB_TOKEN。文件說明，這個暫時性權杖可用於程式碼與制品的拉取、推送及 API 呼叫，流水線結束後即銷毀；其權限則取決於觸發事件。針對以 NPC 身分執行的情況，文件也列出程式碼、PR、Issue 與留言等讀寫權限。 44

對企業來說，這類界線格外重要：AI 若有權寫入程式庫或提出 PR，就必須有明確、可追溯且受限制的存取範圍。CNB 的密鑰倉庫文件則提到，敏感資料可搭配存取控制、操作限制、稽核日誌與浮水印等機制管理。 38

YAML 角色設定，讓 AI 符合專案的工作方式

YAML 定義的 NPC 角色，讓團隊能把部分 AI 行為收進程式庫層級的設定。角色可帶有提示詞與匯入知識來源，而對應流水線則決定其執行方式。 3235

實務上，團隊可據此劃分不同工作模式，例如：

• 調查角色：蒐集脈絡、釐清問題並提出方向；
• 實作角色：修改程式並準備 PR；
• 審查角色：依需求檢視 PR；
• 多角色協作：將較複雜的任務拆給不同 NPC。

騰訊雲表示，多個 NPC 可組成 NPC Team 以處理複雜工作；而具體要怎麼切分職責，仍是各團隊要自行設計的工程決策。 63235

Token 從逾 2 萬降至約 2,000，代表什麼？

騰訊雲稱，其官方研發 NPC 的首輪 Token 消耗，已由早期超過 20,000 降至約 2,000，降幅超過 90%；原因包括持續最佳化提示詞、工具呼叫、CLI 輸出及快取命中率。 623

這個數字的意義在於，代理型任務常要進行多輪模型呼叫。若首輪的系統提示與工具描述會在後續反覆使用，起始上下文與工具負擔愈小，整體任務的成本基礎便愈低。騰訊雲另稱，企業可按任務複雜度選擇模型策略，在效能與成本間取捨。 1523

不過，這是廠商公布的效率指標，並非獨立測試得出的總成本或任務品質比較。實際消耗仍會受程式庫規模、任務範圍、模型選擇、重試次數與 CI 工作量影響。

從 AI 輔助寫碼，走向 AI 工程協作

騰訊雲所說的「AI 工程協作」，重點在於 AI 位於研發生命週期的哪一個位置：

• AI 輔助寫程式：協助開發者撰寫或修改程式。
• AI 驅動任務執行：把一個獨立動作交給 AI 處理。
• AI 工程協作：讓 AI 接入任務承接、實作、審查、驗證與修復彼此相連的流程。 110

最務實的解讀，不是 AI 可以不經把關就自動上線，而是它被整合進現有的協作機制：任務在既有的 Issue 或 PR 中交辦、變更透過 PR 提出、CI 與品質檢查提供回饋，最後仍由既定規則決定是否接受。這保留了可追蹤的工程脈絡：AI 被要求做什麼、實際改了什麼，以及系統如何驗證該變更。 144

對正在評估此類工具的團隊，真正該問的問題是：現有的權限控管、測試覆蓋、程式碼審查規則與部署關卡，是否足以監督一個擁有實質程式庫存取權的 AI？CodeBuddy NPC 可以自動化閉環中的部分步驟，但不能取代人類審查與組織治理。

騰訊雲的 CodeBuddy NPC，想解決的不是「怎樣讓聊天式 AI 多寫幾行程式」，而是「怎樣讓 AI 真正進入團隊每天交付軟體的流程」。

做法是把 AI 放進 CNB 的 Git 工作流：開發者在 Issue 或 Pull Request（PR，合併請求）中 @ 提及一個 NPC 角色並交辦任務後，AI 可在雲端非同步讀取專案脈絡、規劃方案、修改程式、送出 PR、跑測試；若持續整合（CI）失敗，還會讀取紀錄並嘗試修正，再進行下一輪驗證。開發者不必全程守在聊天視窗裡等待。 16

值得留意的是，所提供資料對正式發布日期有不同說法：多篇同期報導指向 2026 年 7 月 23 日，另有後續報導寫為 7 月 29 日。 625

「AI Native Git」：把工程紀錄變成 AI 的工作記憶

騰訊雲將這套方法稱為 AI Native Git。意思並不是 AI 只會讀 Git 程式碼，而是讓程式庫周邊原本就存在的協作紀錄，成為它持續工作的上下文：

• Issue：任務背景、目標與討論，也就是需求脈絡。
• 程式碼庫與歷史紀錄：專案結構、相依關係與過去變更。
• PR：變更提案、程式內容與審查意見。
• CI/CD 結果：建置與測試是否通過、失敗原因，以及修復過程。

因此，它和一次性的程式碼補全或聊天問答不同。AI 不必由人反覆貼上需求、程式片段與錯誤日誌；它在團隊原有的工程紀錄中取用資訊，也把自己的變更與驗證結果留回同一套紀錄。騰訊雲表示，這種模式可重用既有 Git、Docker、CI/CD 與品質關卡，形成「提交 → 驗證 → 修復 → 再驗證」的閉環。 123

如何在 Issue 或 PR 裡「@ AI 派工」？

CNB 文件列出兩個與 NPC 有關的事件：

• issue.comment@npc：在 Issue 描述或留言中提及 NPC 時觸發。
• pull_request.comment@npc：在 PR 描述、審查內容或留言中提及 NPC 時觸發。 35

對開發者而言，操作邏輯近似於 @ 一位同事：在 Issue 或 PR 指定角色並寫下任務，例如請它調查問題、實作功能，或審查某項變更。這些任務不要求另開一段持續互動的 coding chat。

團隊也能在 .cnb/settings.yml 為程式庫設定專屬 NPC，包括角色名稱、提示詞、匯入的知識庫與介面設定；若有需要，還可以在 .cnb.yml 定義其自訂行為與執行環境。CNB 文件指出，若未自訂，系統會使用預設的 NPC 執行映像。 3235

這使它不只是單一泛用型助手。一個團隊可自行設計「問題調查」、「功能實作」或「程式碼審查」等角色，並在最適合的流程節點呼叫它們。

從任務到可審查 PR：非同步交付循環

CodeBuddy NPC 的流程核心是非同步執行。接到任務後，AI 可取得程式庫上下文、擬定方案、修改程式、提交 PR、執行測試，並根據 CI 回饋繼續調整。 16

可將其工作循環理解為五步：

1. 在 Issue 或 PR 指派任務：以 @ 提及觸發 NPC 事件。
2. 讀取工程上下文：結合任務內容、程式庫、現有變更與既有流程紀錄。
3. 規劃並實作：提出處理方向，接著撰寫程式變更。
4. 提出 PR 並驗證：以測試與流水線檢查變更是否可行。
5. 面對失敗再迭代：若 CI 未通過，讀取錯誤結果、診斷問題、更新變更後再次驗證。 1623

所以騰訊雲強調的，不只是 AI 產出一段建議程式碼，而是讓它參與把一個任務轉化為「可審查、可測試的變更」這段工程程序。

CNB 是執行層，也是控制層

AI 要能建立分支、送 PR、跑測試或處理失敗，不能只有模型能力，還需要可重現的執行環境及受控權限。這正是 CNB 扮演的角色。

CNB 的流水線設定可指定 Docker 映像、由 Dockerfile 建立的映像、dev container 環境、掛載磁碟區，以及 runner 標籤或 CPU 設定。如此一來，建置與測試可依程式庫定義的環境重複執行，而非依賴某位開發者電腦上的個人設定。 34

CNB 也支援重用 Docker 快取，後續建置可避免重複下載相依套件等網路資源。 33

在授權方面，CNB 會在流水線執行期間提供 CNB_TOKEN。文件說明，這個暫時性權杖可用於程式碼與制品的拉取、推送及 API 呼叫，流水線結束後即銷毀；其權限則取決於觸發事件。針對以 NPC 身分執行的情況，文件也列出程式碼、PR、Issue 與留言等讀寫權限。 44

對企業來說，這類界線格外重要：AI 若有權寫入程式庫或提出 PR，就必須有明確、可追溯且受限制的存取範圍。CNB 的密鑰倉庫文件則提到，敏感資料可搭配存取控制、操作限制、稽核日誌與浮水印等機制管理。 38

YAML 角色設定，讓 AI 符合專案的工作方式

YAML 定義的 NPC 角色，讓團隊能把部分 AI 行為收進程式庫層級的設定。角色可帶有提示詞與匯入知識來源，而對應流水線則決定其執行方式。 3235

實務上，團隊可據此劃分不同工作模式，例如：

• 調查角色：蒐集脈絡、釐清問題並提出方向；
• 實作角色：修改程式並準備 PR；
• 審查角色：依需求檢視 PR；
• 多角色協作：將較複雜的任務拆給不同 NPC。

騰訊雲表示，多個 NPC 可組成 NPC Team 以處理複雜工作；而具體要怎麼切分職責，仍是各團隊要自行設計的工程決策。 63235

Token 從逾 2 萬降至約 2,000，代表什麼？

騰訊雲稱，其官方研發 NPC 的首輪 Token 消耗，已由早期超過 20,000 降至約 2,000，降幅超過 90%；原因包括持續最佳化提示詞、工具呼叫、CLI 輸出及快取命中率。 623

這個數字的意義在於，代理型任務常要進行多輪模型呼叫。若首輪的系統提示與工具描述會在後續反覆使用，起始上下文與工具負擔愈小，整體任務的成本基礎便愈低。騰訊雲另稱，企業可按任務複雜度選擇模型策略，在效能與成本間取捨。 1523

不過，這是廠商公布的效率指標，並非獨立測試得出的總成本或任務品質比較。實際消耗仍會受程式庫規模、任務範圍、模型選擇、重試次數與 CI 工作量影響。

從 AI 輔助寫碼，走向 AI 工程協作

騰訊雲所說的「AI 工程協作」，重點在於 AI 位於研發生命週期的哪一個位置：

• AI 輔助寫程式：協助開發者撰寫或修改程式。
• AI 驅動任務執行：把一個獨立動作交給 AI 處理。
• AI 工程協作：讓 AI 接入任務承接、實作、審查、驗證與修復彼此相連的流程。 110

最務實的解讀，不是 AI 可以不經把關就自動上線，而是它被整合進現有的協作機制：任務在既有的 Issue 或 PR 中交辦、變更透過 PR 提出、CI 與品質檢查提供回饋，最後仍由既定規則決定是否接受。這保留了可追蹤的工程脈絡：AI 被要求做什麼、實際改了什麼，以及系統如何驗證該變更。 144

對正在評估此類工具的團隊，真正該問的問題是：現有的權限控管、測試覆蓋、程式碼審查規則與部署關卡，是否足以監督一個擁有實質程式庫存取權的 AI？CodeBuddy NPC 可以自動化閉環中的部分步驟，但不能取代人類審查與組織治理。