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

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

黃東旭的核心觀點：頂級模型配合主流工具，已經(jīng)能超越大多數(shù)資深工程師的水平。他用AI重寫TiDB的PostgreSQL兼容層，代碼質量"已經(jīng)接近生產(chǎn)水平"。但人的瓶頸在驗收——他90%的時間花在評估AI的工作成果，而不是寫代碼。

他對未來軟件公司形態(tài)有一個判斷：

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

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

頭狼是精英路線

黃東旭的"頭狼+狼群"模式，是一個公司內(nèi)部的超級個體，讓一個頂級工程師端到端負責產(chǎn)品。

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

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

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

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

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

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

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

我和我的朋友們借鑒這個模式，發(fā)明了產(chǎn)品端到端三人組框架（Product Tri-Ownership）。

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

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

Product Owner

Quality Owner

Tech Owner

owns 做什么

owns 什么是對的

owns 怎么做

≈ 建筑師

≈ 監(jiān)理

≈ 土木工程師

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

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

Product Owner（產(chǎn)品負責人，PO）：負責做什么

對應于建筑師，產(chǎn)品負責人是一個擴展的角色，合并了傳統(tǒng)PM和PO的職責：定義產(chǎn)品愿景和商業(yè)價值、敢于說No；管理用戶故事、驗收標準和優(yōu)先級；規(guī)劃版本節(jié)奏、迭代計劃和里程碑；負責向上匯報、跨團隊協(xié)調和客戶溝通。

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

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

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

黃東旭發(fā)現(xiàn)：

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

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

標準開發(fā)流程
- /story → 從用戶故事生成詳細設計
- tester → TDD紅階段（寫失敗測試）
- coder → TDD綠階段（讓測試通過）
- /qc → 質量檢查并提交代碼
- deployer → 監(jiān)控CI/CD，確保staging和生產(chǎn)環(huán)境正常

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

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

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

質量負責人對交付質量負責，不同于建筑行業(yè)的監(jiān)理，QO要設計質量流程，全流程管理質量。

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

卸載TO的職責

在PingCAP的實踐中，CTO：

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

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

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

通過對抗式測試保證質量

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

NASA在挑戰(zhàn)者號災難后建立了獨立驗證與確認（IV&V）項目，核心原則是軟件驗證必須由既不是開發(fā)者也不是采購方的獨立組織執(zhí)行。

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

全流程的質量控制

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

每天完成一個用戶故事

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

這個速度有多快？看看Claude Code的發(fā)布節(jié)奏：10天內(nèi)發(fā)布了10個版本，有些天甚至發(fā)布2-3個版本。不能滿足這個速度的團隊，是低于業(yè)界平均水平的。

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

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

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

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

傳統(tǒng)實踐成為瓶頸。

很多團隊引入AI后速度沒有提升，因為傳統(tǒng)流程拖后腿：
- 4-eyes code review：每行代碼必須兩人審核。當AI一天能寫完一個功能，等兩個人排期review就要三天。實際上，我的CTO都抱怨這個機制拖慢了他自己用AI生成的代碼的合并。
- Change Advisory Board：每次上線都要開會審批。AI可以一天部署十次，CAB一周才開一次
- 手工部署：AI寫完代碼還要等運維排期手工部署。AI可以一天迭代十次，手工部署一周才排一次

支撐角色

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

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

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

Platform Engineer（平臺工程師）：負責生產(chǎn)環(huán)境運維、監(jiān)控告警、安全合規(guī)、成本優(yōu)化。取決于技能，還應該幫助QO搭建閡優(yōu)化CI/CD pipeline。

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

另一種方法：培訓模式

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

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

AI Coding的下一個核心問題

個人與AI結對編程已經(jīng)是成熟的實踐。Claude Code、Cursor等工具的普及證明了這一點。但是，團隊如何與AI Agents協(xié)作？

AI Coding的下一個核心問題，是在AI agents極大地降低實現(xiàn)成本之后，如何系統(tǒng)性地構建人機協(xié)作團隊，以可持續(xù)的方式保證交付質量，并且將生產(chǎn)力的提升轉換為市場競爭力。

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

Product Tri-Ownership的價值：提供一個可復制的框架，把"不可能的超級個體"拆成"三個可培養(yǎng)的專業(yè)角色"，讓普通團隊也能實現(xiàn)AI原生開發(fā)。

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

引用來源

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/