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

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

黃東旭的核心觀點：頂級模型配合主流工具，已經能超越大多數資深工程師的水平。他用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原生團隊是什么結構？遇到了什么問題？歡迎留言討論。也歡迎愿意深入探討的朋友在公眾號對話框和我直接聯系。

引用來源

1. 黃東旭《Vibe Engineering 2026.1》: https://mp.weixin.qq.com/s/YQ-GuDfqDW0yhtghjKK8Rg

2. 超級個體（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

3. 一人公司（Company of One）: https://www.goodreads.com/book/show/37570605-company-of-one

4. Claude Code GitHub: https://github.com/anthropics/claude-code

5. NASA IV&V Program: https://www.nasa.gov/ivv-overview/