學習PingCAP，打造你公司的AI原生軟體開發團隊

本文是對黃東旭（PingCAP CTO）最近的文章《Vibe Engineering 2026.1》的一個響應。如果你還沒有讀過他這篇文章，我強烈推薦你去讀一遍。

黃東旭的核心觀點：頂級模型配合主流工具，已經能超越大多數資深工程師的水平。他用AI重寫TiDB的PostgreSQL相容層，程式碼品質”已經接近生產水平”。但人的瓶頸在驗收——他90%的時間花在評估AI的工作成果，而不是寫程式碼。

他對未來軟體公司形態有一個判斷：

這種工作方式更像是頭狼帶著一群狼群（Agents），在一片自己的領地裡面耕耘，但是同一片領地裡很難容納兩匹頭狼，會造成 1+1 < 2。

但是PingCAP是中國最優秀的基礎軟體公司之一，黃東旭是中國最優秀的程式員之一，PingCAP的這種實踐有多大的通用性？如果你我直接抄襲他的做法，究竟是見賢思齊，還是東施效顰？本文將盡力回答這個問題。

頭狼是精英路線

黃東旭的”頭狼+狼群”模式，是一個公司內部的超級個體，讓一個頂級工程師端到端負責產品。

七牛雲也在嘗試類似的方案，叫產品架構師：一個人負責PRD、架構、實現、測試的全流程。CEO 許式偉的評估標準很直接：

如果一定時間內做不到端到端負責，就淘汰，換能做到的人來。

但是，產品架構師需要傳統產品經理 + 架構師 + 主程式員 + 測試Team Leader的綜合能力。能接近這個定位的人都是鳳毛麟角。大多數公司的大多數團隊，找不到這樣的人。筆者運營一個世界一流的AI Coding社區：Agent管理學論壇，裡面敢於說自己滿足這個條件的，也就三個人。

即使找到了，你怎麼知道他/她下個月不會去做一人公司？上面說的那三個人，都是自己開公司的 CEO，沒有一個給別人打工的。

因此，這個精英路線的致命問題是它依賴一個幾乎不可及的人才市場。

把超級個體拆成產品端到端三人組（Product Tri-Ownership框架）

在軟體工程之外，建築行業早已解決了類似的問題。他們不依賴超級個體，而是通過角色分工來保證品質。建築師定義空間，土木工程師設計結構，監理獨立驗收，施工方負責執行。四個角色，四種專業，互相補全。

我和我的朋友們借鑑這個模式，發明了產品端到端三人組框架（Product Tri-Ownership）。

PTO框架把超級個體的工作拆開：

產品架構師/頭狼/超級個體（一個人做端到端的所有事）拆分為 ↓

Product Owner	Quality Owner	Tech Owner
owns 做什麼	owns 什麼是對的	owns 怎麼做
≈ 建築師	≈ 監理	≈ 土木工程師

細心的讀者會問：施工方去哪了？

答案很直接：施工方就是AI Agent。它們按指令寫程式碼、跑測試、生成文檔，就像施工方按圖紙砌牆。它們不配有署名權。

Product Owner（產品負責人，PO）：負責做什麼

對應於建築師，產品負責人是一個擴展的角色，合併了傳統PM和PO的職責：定義產品願景和商業價值、敢於說No；管理用戶故事、驗收標準和優先級；規劃版本節奏、迭代計劃和里程碑；負責向上匯報、跨團隊協調和客戶溝通。

PO對產出的價值負責（accountable for outcomes），而不是對產出本身負責。PO不是寫需求文檔的秘書，而是決定”什麼值得做”的人。不僅定義”做什麼”，更要有勇氣說”不做什麼”。沒有合格的PO做第一層質控，後面的質量鏈條都會出問題。

Tech Owner（技術負責人，TO）：負責怎麼做

技術負責人對技術實現負責，他/她帶領一群不同角色的AI Agent寫出正確的軟體。負責詳細設計、程式碼review報告（不是程式碼本身）和工具選型，但最重要的職責是編排多個Agent的工作流。

黃東旭發現：

當前的 Coding Agent 在面對單一模塊複雜度超過大約 5 萬行程式碼之後，就開始很難在 1-shot 裡把問題一次性解決掉。Agent 通常不會主動去做項目結構和模塊邊界的治理。

下面是我團隊的TO設計的一個AI Agent工作流程：

標準開發流程

/story → 從用戶故事生成詳細設計
tester → TDD紅階段（寫失敗測試）
coder → TDD綠階段（讓測試通過）
/qc → 質量檢查並提交程式碼
deployer → 監控CI/CD，確保staging和生產環境正常

不同任務類型需要不同的工作流。Bug fix流程不同於新功能流程，綠地項目不同於棕地項目。TO負責為不同的任務建造、觀察、優化合適的工作流。

在此之外，TO負責解決過程中的任何異常。比如在我們的一個集成項目中，合作方沒有提供API，TO不得不想盡辦法去拼湊出一個openapi.yaml。

Quality Owner（質量負責人，QO）：負責做得對不對

質量負責人對交付品質負責，不同於建築行業的監理，QO要設計質量流程，全流程管理品質。

獨立的QO解決了幾個AI Coding問題：

卸載TO的職責

在PingCAP的實踐中，CTO：

在我個人和 AI 開發項目的過程中，我 90% 的時間和精力都花在了這個階段：也就是如何評估 AI 的工作成果。我在完成大目標前，我一定會先和 AI 一起做一個方便的集成測試框架，並提前準備好測試的基礎設施。

黃東旭個人能力強，所以他扛了90%的驗收工作，但是對於大多數人來說，這很容易成為瓶頸。

Tri-Ownership框架通過設置專職QO來卸載這部分工作。

通過對抗式測試保證質量

有一定AI Coding經驗的朋友都知道，LLM很擅長投機取巧。如果多次無法通過一個測試用例，它很可能註釋掉測試用例以滿足用戶期望。

NASA在挑戰者號災難後建立了獨立驗證與確認（IV&V）項目，核心原則是軟體驗證必須由既不是開發者也不是採購方的獨立組織執行。

我們借鑑這種思想，設置獨立的QO崗位。QO的agents在一定程度上能夠對抗TO的agents這樣作弊。

全流程的質量控制

不同於傳統的測試人員，QO需要參與軟體開發生命週期（SDLC）的每個環節，並且設計多層次的測試體系（單元測試 → 集成測試 → 端到端測試）嵌入到每個環節。比如，PO在提供產品需求說明書的時候，QO就會參與驗收標準（Acceptance Criteria）的編寫，確保需求是可驗證的。又比如，在我項目中，我們選擇Makefile作為golang項目的測試入口，禁止Claude Code自行呼叫go test命令。並且把make test嵌入到git commit hook和CI workflow中，確保低級錯誤在早期得到糾正。頭狼模式把所有質量壓力集中在最後驗收（黃東旭說的90%），這極度依賴於頭狼的個人素質。Tri-Ownership框架通過覆蓋全流程的測試體系，把質量工作的門檻降低了。

每天完成一個用戶故事

就節奏來說，Tri-Ownership框架應該能做到一天完成一個用戶故事（Story）。

這個速度有多快？看看Claude Code的發布節奏：10天內發布了10個版本，有些天甚至發布2-3個版本。不能滿足這個速度的團隊，是低於業界平均水平的。

正常的節奏應該是：早上PO寫完用戶故事，QO同步定義驗收標準；午飯前AI Agent完成詳細設計，TO審核批准，觸發AI開發流程；午飯中AI完成第一版程式碼和測試；下午TO審核程式碼審查報告，可能迭代多次以提升程式碼品質；下班前Github Action自動觸發端到端驗收，QO審閱通過即合併上線。

為什麼能這麼快？因為最繁重的編碼任務被多個AI Agent承擔了，三個人可以並發工作，QO提前準備好測試框架不需要臨時搭建，自動化工作流減少了人工交接的等待時間。請注意，承擔最繁重任務的AI agent是不需要吃午飯的。

**小技巧：三個Owner必須坐在一起。**物理上坐在一起，有問題隨時討論，不需要預約會議。每日站會已經不夠了，迭代速度快意味著決策頻率高，等到明天站會就太晚了。

如果一個故事超過一天還沒完成，說明故事太大，需要拆分。AI時代的故事應該比傳統開發小得多。

傳統實踐成為瓶頸。

很多團隊引入AI後速度沒有提升，因為傳統流程拖後腿：

4-eyes code review：每行程式碼必須兩人審核。當AI一天能寫完一個功能，等兩個人排期review就要三天。實際上，我的CTO都抱怨這個機制拖慢了他自己用AI生成的程式碼的合併。
Change Advisory Board：每次上線都要開會審批。AI可以一天部署十次，CAB一週才開一次
手工部署：AI寫完程式碼還要等運維排期手工部署。AI可以一天迭代十次，手工部署一週才排一次

支撐角色

Tri-Ownership之外，還需要一些支撐角色：

Sponsor（決策者）：提供資源，解決衝突。首先要保證充足的token預算和合適的硬體，因為AI原生開發的瓶頸往往不是人力成本，而是token成本。其次，當三個Owner之間發生分歧時，Sponsor應該有權限做最終決策。

Architect（架構師）：定義系統架構、模塊邊界、接口契約、程式碼規範、技術棧選型（語言、框架、資料庫等）。黃東旭說Agent在5萬行以上的模塊就很難一次搞定，架構師預先拆分，讓每個模塊保持在AI可處理的規模。例如，我們團隊使用mono repo，每個應用天然繼承架構師選定的Gin、Gorm、Observability等技術棧。這個角色，小項目中可由TO兼任。

Platform Engineer（平台工程師）：負責生產環境運維、監控告警、安全合規、成本優化。取決於技能，還應該幫助QO搭建阂優化CI/CD pipeline。

Specialty Expert（領域專家）：按需諮詢，不參與日常開發。比如我的朋友Nick在開發一個互聯網To Consumers服務的時候，需要一個UI/UX設計師。他不懂程式碼，但可以跟Lovable這樣的AI agent協作，把UI Kit做出來交給TO。Security、DBA等領域專家也是類似的模式：需要的時候介入，不需要全職配備。

另一種方法：培訓模式

不是所有公司都能重組團隊結構。我的朋友楊工使用了一個更溫和的替代方案：培訓模式。他不動組織結構，自己定制skills、agents和workflows，然後讓實施團隊按流程執行，用便宜的模型降低成本門檻。

優點是門檻低，不需要組織變革，團隊負責人就可以實施。缺點也很明顯，這個模式只覆蓋開發流程的很小一部分，產生的價值被限制在一個不高的天花板下。

AI Coding的下一個核心問題

個人與AI結對程式設計已經是成熟的實踐。Claude Code、Cursor等工具的普及證明了這一點。但是，團隊如何與AI Agents協作？

AI Coding的下一個核心問題，是在AI agents極大地降低實現成本之後，如何系統性地構建人機協作團隊，以可持續的方式保證交付質量，並且將生產力的提升轉換為市場競爭力。

黃東旭的頭狼探索證明了AI原生開發的可行性。但頭狼太稀缺。

Product Tri-Ownership的價值：提供一個可複製的框架，把”不可能的超級個體”拆成”三個可培養的專業角色”，讓普通團隊也能實現AI原生開發。

你們公司的AI原生團隊是什麼結構？遇到了什麼問題？歡迎留言討論。也歡迎願意深入探討的朋友在公眾號對話框和我直接聯繫。

引用來源

黃東旭《Vibe Engineering 2026.1》: https://mp.weixin.qq.com/s/YQ-GuDfqDW0yhtghjKK8Rg
超級個體（The Rise of the Super Individual）: https://medium.com/@yangxu_16238/the-rise-of-the-super-individual-how-ai-is-replacing-teams-and-redefining-work-88dacad036b8
一人公司（Company of One）: https://www.goodreads.com/book/show/37570605-company-of-one
Claude Code GitHub: https://github.com/anthropics/claude-code
NASA IV&V Program: https://www.nasa.gov/ivv-overview/