學(xué)習(xí)PingCAP，打造你公司的AI原生軟件開發(fā)團(tuán)隊(duì)

本文是對(duì)黃東旭（PingCAP CTO）最近的文章的一個(gè)響應(yīng)。如果你還沒有讀過(guò)他這篇文章，我強(qiáng)烈推薦你去讀一遍。

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

他對(duì)未來(lái)軟件公司形態(tài)有一個(gè)判斷：

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

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

頭狼是精英路線

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

七牛云也在嘗試類似的方案，叫產(chǎn)品架構(gòu)師：一個(gè)人負(fù)責(zé)PRD、架構(gòu)、實(shí)現(xiàn)、測(cè)試的全流程。CEO 許式偉的評(píng)估標(biāo)準(zhǔn)很直接：

如果一定時(shí)間內(nèi)做不到端到端負(fù)責(zé)，就淘汰，換能做到的人來(lái)。

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

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

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

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

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

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

PTO框架把超級(jí)個(gè)體的工作拆開：

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

Product Owner

Quality Owner

Tech Owner

owns 做什么

owns 什么是對(duì)的

owns 怎么做

≈ 建筑師

≈ 監(jiān)理

≈ 土木工程師

細(xì)心的讀者會(huì)問：施工方去哪了？

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

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

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

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

Tech Owner（技術(shù)負(fù)責(zé)人，TO）：負(fù)責(zé)怎么做

技術(shù)負(fù)責(zé)人對(duì)技術(shù)實(shí)現(xiàn)負(fù)責(zé)，他/她帶領(lǐng)一群不同角色的AI Agent寫出正確的軟件。
負(fù)責(zé)詳細(xì)設(shè)計(jì)、代碼review報(bào)告（不是代碼本身）和工具選型，但最重要的職責(zé)是編排多個(gè)Agent的工作流。

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

當(dāng)前的 Coding Agent 在面對(duì)單一模塊復(fù)雜度超過(guò)大約 5 萬(wàn)行代碼之后，就開始很難在 1-shot 里把問題一次性解決掉。 Agent 通常不會(huì)主動(dòng)去做項(xiàng)目結(jié)構(gòu)和模塊邊界的治理。

下面是我團(tuán)隊(duì)的TO設(shè)計(jì)的一個(gè)AI Agent工作流程：

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

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

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

Quality Owner（質(zhì)量負(fù)責(zé)人，QO）：負(fù)責(zé)做得對(duì)不對(duì)

質(zhì)量負(fù)責(zé)人對(duì)交付質(zhì)量負(fù)責(zé)，不同于建筑行業(yè)的監(jiān)理，QO要設(shè)計(jì)質(zhì)量流程，全流程管理質(zhì)量。

獨(dú)立的QO解決了幾個(gè)AI Coding問題：

卸載TO的職責(zé)

在PingCAP的實(shí)踐中，CTO：

在我個(gè)人和 AI 開發(fā)項(xiàng)目的過(guò)程中，我 90% 的時(shí)間和精力都花在了這個(gè)階段：也就是如何評(píng)估 AI 的工作成果。 我在完成大目標(biāo)前，我一定會(huì)先和 AI 一起做一個(gè)方便的集成測(cè)試框架，并提前準(zhǔn)備好測(cè)試的基礎(chǔ)設(shè)施。

黃東旭個(gè)人能力強(qiáng)，所以他扛了90%的驗(yàn)收工作，但是對(duì)于大多數(shù)人來(lái)說(shuō)，這很容易成為瓶頸。

Tri-Ownership框架通過(guò)設(shè)置專職QO來(lái)卸載這部分工作。

通過(guò)對(duì)抗式測(cè)試保證質(zhì)量

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

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

我們借鑒這種思想，設(shè)置獨(dú)立的QO崗位。QO的agents在一定程度上能夠?qū)筎O的agents這樣作弊。

全流程的質(zhì)量控制

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

每天完成一個(gè)用戶故事

就節(jié)奏來(lái)說(shuō)，Tri-Ownership框架應(yīng)該能做到一天完成一個(gè)用戶故事（Story）。

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

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

為什么能這么快？因?yàn)樽罘敝氐木幋a任務(wù)被多個(gè)AI Agent承擔(dān)了，三個(gè)人可以并發(fā)工作，QO提前準(zhǔn)備好測(cè)試框架不需要臨時(shí)搭建，自動(dòng)化工作流減少了人工交接的等待時(shí)間。請(qǐng)注意，承擔(dān)最繁重任務(wù)的AI agent是不需要吃午飯的。

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

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

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

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

支撐角色

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

Sponsor（決策者）：提供資源，解決沖突。首先要保證充足的token預(yù)算和合適的硬件，因?yàn)锳I原生開發(fā)的瓶頸往往不是人力成本，而是token成本。其次，當(dāng)三個(gè)Owner之間發(fā)生分歧時(shí)，Sponsor應(yīng)該有權(quán)限做最終決策。

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

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

Specialty Expert（領(lǐng)域?qū)＜遥?/strong>：按需咨詢，不參與日常開發(fā)。比如我的朋友Nick在開發(fā)一個(gè)互聯(lián)網(wǎng)To Consumers服務(wù)的時(shí)候，需要一個(gè)UI/UX設(shè)計(jì)師。他不懂代碼，但可以跟Lovable這樣的AI agent協(xié)作，把UI Kit做出來(lái)交給TO。Security、DBA等領(lǐng)域?qū)＜乙彩穷愃频哪Ｊ剑盒枰臅r(shí)候介入，不需要全職配備。

另一種方法：培訓(xùn)模式

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

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

AI Coding的下一個(gè)核心問題

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

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

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

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

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

引用來(lái)源

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

2. 超級(jí)個(gè)體（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/