本期播客前半部分是任川的單人分享，后半部分是現(xiàn)場交流，原文約 14500 字，本文經(jīng)過刪減整理后約 5600 字。

任川單人分享

我們公司成立于去年 4 月，一開始就采用了 AI Native 的組織形式，兩三個月后，就把 AI 深度嵌入了研發(fā)的各個環(huán)節(jié)，這一年多實踐下來，效率和效果都很好。

今天我就會從工作流、人才、組織三個維度，分享我們打造 AI Native 工程團隊的經(jīng)驗。

先說第一部分：如何用 AI 重構(gòu)研發(fā)工作流，把效率提升 10 倍。

所謂「10 倍提效」只是保守說法，實際體感遠不止于此。拿 Code Review 舉例，這件事即使在效率優(yōu)化到極致的 Google，平均也要一兩天，而我們只需 10 分鐘。

我們是怎么做到的呢？

很簡單：只讓 AI 來做 Review。

AI 不僅能提效，還有一個意想不到的好處，就是減少摩擦。人工 Review 很容易讓人覺得是在「挑刺」，但如果是 AI 指出問題，工程師反而會感謝它幫自己排雷。所以在我們團隊里，大家都會相互推薦好用的 AI Review 工具。這種「好用」很難用量化指標衡量，更多取決于工程師的主觀體驗。

目前我們覺得最好用的工具是 CodeRabbit。只要它批準，我們就直接合并代碼。

當然，即便 AI Review 的效果已經(jīng)很好了，還是有可能會漏掉 bug。這聽起來有點危險，因為在傳統(tǒng)工作流里，上線后再發(fā)現(xiàn) bug 很麻煩，但 AI Review 的速度極快，所以哪怕出現(xiàn)問題，我們也可以立刻回滾或線上修復。

通過這個例子，我想和大家分享我們用 AI 重構(gòu)工作流的三條經(jīng)驗。

首先，我們默認由 AI 來承擔所有研發(fā)工作。

這并不是說要無腦地把一切都交給 AI，而是要轉(zhuǎn)變思維模式。

在傳統(tǒng)工作流里，我們通常會默認所有事都由人類完成，只有偶爾發(fā)現(xiàn) AI 能幫上忙時，才會讓它介入。但這樣可能會錯過很多 AI 提效的機會。

我們的邏輯正好相反：我們默認所有事都由 AI 完成，只有當 AI 遇到確實解決不了的問題時，再由人類來補位。

這樣思考下來，AI 其實可以直接完成很多工作，重構(gòu)我們的工作流。

它不止能寫代碼，還可以寫文檔、寫測試、寫設計文檔、做 Review、上線和監(jiān)控等等。和大家分享幾個場景和工具：

在 Coding 環(huán)節(jié)，我們會用 Linear 管理任務，用 Devin 生成代碼。我們可能會一次性在 Linear 中創(chuàng)建 10 個任務，然后由 Linear 將任務自動分配給 Devin，再由 Devin 批量生成代碼。整個過程中，我們甚至都不需要打開 IDE?，F(xiàn)在，我們大約 90% 的代碼都是通過這種方式生成的。

在生產(chǎn)監(jiān)控中，我們會用 incident.io。它會收集我們的工作日志，自動分析和預警，甚至在出現(xiàn)問題時給出初步診斷，目前這已經(jīng)能覆蓋我們近一半的監(jiān)控需求?，F(xiàn)在我們已經(jīng)不需要專職的運維人員了，只靠工程師配合 incident.io 就足夠。

此外，我們最近還發(fā)現(xiàn)了一個 AI 可以重塑的工作流，就是 go-to-market。傳統(tǒng)銷售流程很長，一個客戶可能從頭到尾要接觸四五個人，但有了 AI，整個鏈條將被大幅壓縮，或許一個人就能 end-to-end 地完成全部工作?，F(xiàn)在硅谷很多公司都在做 GTM 自動化，我也覺得這里面大有可為，很值得關注。

雖然 AI 現(xiàn)在還不能完全替代人力，比如 Infra 層還是比較依賴人工，但在前端、產(chǎn)品等環(huán)節(jié)，AI 的表現(xiàn)已經(jīng)非常好了。隨著 AI 的效果越來越好，我相信未來需要人類參與的部分也會越來越少。

第二條經(jīng)驗，就是我非常推薦大家使用 Claude Code。

這點現(xiàn)在講起來有點尷尬，因為 Anthropic 最近限制了國內(nèi)訪問…但我們用下來，它確實還是最好用的，一是 Claude Code 能力本身就很強；二是它有 SDK，可以做大量二次開發(fā)。

而且 Calude Code 能做的事遠不止寫代碼。Claude Code 「全球第一人」劉小排（他用 200 美元的套餐消耗掉了價值 5 萬美元的 token）就說過：只要有 SOP，就沒有 Claude Code 執(zhí)行不了的任務。

第三條經(jīng)驗有點反直覺。

大家通常覺得開會、對齊很重要。但在 AI Native 的工作流里，人與人之間的交流很容易變成瓶頸。

所以我們的做法是：讓每個人從頭到尾獨立完成工作，盡量減少對齊。如果必須要對齊，那大家就把原則和想法寫進 codebase，讓人和人、人和 AI 在代碼里自動對齊。

講到這里，其實大家能感受到，AI Native 的工作方式和傳統(tǒng)的工作方式很不一樣，這也對人才提出了新的要求。

那么AI Native 的工程團隊最需要什么樣的人才呢？

第一，人需要成為 AI 的「Context Provider」。

我們使用 AI 有個原則，就是「人 + AI」的產(chǎn)出必須大于「AI 單獨工作」的產(chǎn)出。

這聽上去非常合理，但在實踐中，很多時候人類的介入反而會拖慢效率。

很多人只把 AI 當提效工具，但其實大家應該轉(zhuǎn)變思路：讓人類為 AI 提效。這樣或許反而能取得更好的效果。

因為今天模型的能力已經(jīng)很強了，AI 產(chǎn)出效果不夠好，更多是因為 Context Engineering 不夠好，或者是人類沒有為 AI 提供足夠的上下文

所以在 AI Native 的團隊里，人類很重要的價值，就是成為 Context Provider，為 AI 打造更好的上下文，提供它不具備的知識。

比如我們的產(chǎn)品主要是用 AI 幫餐飲行業(yè)提效，讓 AI 幫忙接電話、預約、下單等等。要做好這些工作，需要對餐飲行業(yè)有很深的理解，而 AI 本身不具備這些知識。但我們有同事暑假常在餐廳端盤子，ta 所積累下來的對餐飲流程的理解，就是對 AI 極有價值的 Context。

第二，人應該做「Fast Learner」，快速掌握最少必要知識，從而與 AI 高效溝通。

現(xiàn)在一個人遇到新問題，已經(jīng)不太可能在短時間內(nèi)學得比 AI 還強了。所以在面試和日常工作中，我們不太在乎一個人已有多少技能，更在乎 ta 能否快速掌握基本知識，把目標和問題定義清楚，然后激發(fā) AI 的潛力，用 AI 的力量去解決問題。

第三，每個人都應該是「Hands-on Builder」。哪怕一個人只負責產(chǎn)品中的一小部分，也要對全流程和最終結(jié)果負責。

舉個例子，如果你只做前期研究，卻不 Build、也不對結(jié)果負責，那你就需要和上下游反復傳遞 Context。而只要出現(xiàn)這種傳遞，團隊效率就會顯著下降。

講完人才，最后，我們再講講AI Native 工程團隊的組織形式和分工模式。

首先，我們實踐下來，發(fā)現(xiàn)更合理的方式是「按結(jié)果分工」，而不是「按流程分工」。

什么叫「按結(jié)果分工」呢？

舉個例子，我們有一個對商家需求負責的小組，還有一個對消費者體驗負責的小組。其實后者的日常工作更偏前端，但我們不會把它定義成前端組，而是要求這個小組具備前后端、運維等全鏈路能力。只要消費者體驗出了問題，不管在哪個環(huán)節(jié)，都由這個小組直接解決。

甚至我們的工程師也要參與產(chǎn)品設計、GTM 等環(huán)節(jié)。我也非常鼓勵我們的工程師自己去跑客戶，獲取一手反饋，而不是像在傳統(tǒng)團隊里那樣，由銷售去見客戶、把客戶的需求轉(zhuǎn)達給 PM、再由 PM 轉(zhuǎn)達給工程團隊，因為這樣層層轉(zhuǎn)述下來，一來工程團隊未必能實現(xiàn)，還要再反復溝通，二來客戶的需求可能已經(jīng)走樣了。

「按結(jié)果分工」不一定是最佳模式，但我相信即便未來繼續(xù)演變，也不會再回到工業(yè)時代、互聯(lián)網(wǎng)時代那種「按流程分工」的模式。

原因很簡單：過去需要在每個環(huán)節(jié)安排不同的人，而在 AI 時代，可能 98% 的工作都能由 AI 完成，人類只需在 AI 做不了的地方補位。到那時，還按流程來分工明顯就很不合理。

第二，我們的組織以工程團隊為核心，因為工程團隊最容易為結(jié)果負責。

比如我們要上線一個功能時，工程團隊會第一時間利用各種各樣的工具，完成包括研發(fā)、產(chǎn)品、設計在內(nèi)的基礎工作，先做出一個 60 分的版本，快速上線。而其他團隊，比如專業(yè)的設計師，會再在這個 60 分版本的基礎上優(yōu)化。

過去大家總說「talk is cheap, show me the code」，但上線一個新功能的成本很高，所以大家要開很多會，讓所有人全部拉通對齊，得出一個很完善的方案再付諸行動。

但現(xiàn)在「talk is cheap, but code is cheaper」，生成代碼的成本極低，所以我們完全可以追求「速度優(yōu)先」，先上線一個 60 分的東西，大家再一起努力把它做到 100 分。

正是這種方式，讓我們在一年內(nèi)就能搭起一個復雜系統(tǒng)。

第三，未來的組織形態(tài)，可能是「少量核心合伙人 + 大量靈活合同工」。

在傳統(tǒng)互聯(lián)網(wǎng)公司里，每個崗位都會有 back up 員工。但在 AI Native 的組織中，每個人都按結(jié)果分工、為結(jié)果負責，所以一個人的價值和不可替代性很高。一旦一個員工離開，就會對公司產(chǎn)生很大的影響。

那為了留住這些人才，就需要給這些員工提供類似于合伙人的待遇。

但如果所有的員工都享受合伙人級別的待遇，成本又很高，所以全職的核心員工數(shù)量不會特別多，需要大量的靈活合同工來作為補充。這些合同工往往在某個領域有很豐富的經(jīng)驗，他們也更愿意和多個組織合作，而不是全職綁定在一家企業(yè)。

我們這套模式在硅谷算是比較先鋒，但絕不小眾，更不是最激進的。灣區(qū)初創(chuàng)公司各有各的做法，不過大家的思路基本都在往這個方向發(fā)展。

Q&A 精選

（活動的另一位嘉賓是上期

的虞快，所以 Q&A 部分也有一些虞快的補充）

Q1：為什么大廠不效仿你們這種 AI Native 的組織形式？是不是這種方案只適合初創(chuàng)公司，一旦公司規(guī)模大起來，就很難行得通？

任川：我在 Google 的時候，內(nèi)部一些小團隊也會這么做，但要推行到整個公司確實非常困難，因為大廠想調(diào)整組織架構(gòu)，要考慮的不只是效率，還有很多額外因素。比如微軟 CEO 最近就公開道歉，說之前裁員過猛，需要重建員工信心。

不過現(xiàn)在很多明星 AI 公司規(guī)模都不大，甚至有人在討論會不會出現(xiàn)「一人獨角獸」。如果未來幾個人就能做出驚人的產(chǎn)品，那可能也不需要 Google 這樣十萬人的公司了。

Q2：在你們這種組織模式下，團隊的一天是怎樣的？

任川：我們的工作節(jié)奏表面上可能和傳統(tǒng)公司差不多，但實際產(chǎn)出效率差別很大。

我們每天會把會議集中在中間的 3–4 個小時，其他時間盡量不排會，大家分頭去做事。像我最開始提到的 Code Review，每個人每天都會收到 3-5 個這種請求，然后會各自完成寫代碼、AI review、merge 的全流程，效率非常高。

Q3：有些代碼可能已經(jīng)迭代了十年，非常復雜，人類工程師都未必能完全掌握。這種情況下，AI 介入的可行性有多大？是不是 AI 更適合從 0 到 1，而不太適合從 1 到 100 的場景？

任川：這個問題特別好。你所提到的，就是典型的需要人來給 AI 做 Context Provider 的場景。

就像你說的，大模型不具備這么多年的經(jīng)驗積累。在這種情況下，AI Coding 的效果，很大程度上取決于人類所提供的 Context 的準確性和信噪比。如果 AI 跑出來的效果不夠好，并不是因為模型能力不行，而是因為我們提供的上下文不夠好。

要解決這個問題，要么就是等模型更強大，強大到上下文不夠也沒關系；要么就是人類想辦法給 AI 提供更好的上下文。前者成本很高，也很難預期，但后者是公司和個人都可以努力的方向 。從個人角度來看，學會為 AI 提供更好的 Context，將是未來 AI 工程師非常核心的技能和價值。

Q4：PM 在你們內(nèi)部是什么樣的角色？

任川：我們團隊現(xiàn)在差不多 20 個人，沒有全職的 PM，基本上工程師就把 PM 的工作做了，這樣工程師也可以直接拿到客戶反饋，比中間隔著一層 PM 的效率更高。

而且其實對于創(chuàng)業(yè)公司來說，CEO 或者工程負責人就是最重要的 PM。

虞快有什么補充嗎？

虞快：我覺得公司早期沒有 PM 很正常。Mercor 到現(xiàn)在已經(jīng)有大約 150 人，也只有 2 個 PM。

很多時候不是工程師做不了 PM 的事，而是他們知道有 PM 的存在后，就容易喪失 ownership，傾向于把難題推給別人?？?PM 在做決定時，又必須回過頭來找工程師確認，來回溝通一大圈，最后這個決定往往還是工程師和 PM 一起下的。

所以其實只要你招的人足夠聰明、善于解決問題，ta 沒理由只能做工程決策、做不了產(chǎn)品或商業(yè)決策。

Q5：大家對工程師的固有印象可能是特別擅長寫代碼，但不善與人溝通，而 PM 則是懂用戶、會溝通、能提煉需求。如果讓工程師兼做 PM，是不是對工程師的要求特別高？這樣的人好招嗎？

任川：這樣的人確實不太好招?，F(xiàn)在能快速學習 AI、用好 AI 工具的工程師本就不多，還兼?zhèn)洚a(chǎn)品能力的更少。

但其實現(xiàn)在軟件工程師崗位，已經(jīng)不是只有懂代碼的人才能勝任了。我認識一些 PM，他們不會寫代碼，但現(xiàn)在用各種強大的 AI Coding 工具，也能獨立做出產(chǎn)品。

所以我覺得未來可能不會再有「PM」和「工程師」的嚴格區(qū)分，大家都是 Builder。只要能 Build 出東西、對結(jié)果負責就可以。

Q6：怎么篩選出真正會用 AI 的人？

任川：我們有兩種方式。

首先，我們不做傳統(tǒng)的一小時面對面的面試，而是會直接給候選人一個 take-home 的任務。

比如我們會讓你在兩天時間內(nèi) Build 一個產(chǎn)品，而這個產(chǎn)品比較復雜，沒有 AI 基本做不出來。如果你能在兩天內(nèi)做出這個產(chǎn)品，那你肯定很會用 AI 工具。如果你手搓了一個產(chǎn)品出來，那說明你更是技術(shù)大牛（笑）。

兩天后，我們再約著聊半小時，請你講講過程中的思路和細節(jié)。這樣我們也可以進一步判斷你能不能用好 AI。

當然，有些背景很強的人可能不愿意花時間來做這個任務，那這本身也是一種雙向篩選。我們可能會因此錯過一些人，但這種方式整體來看效率比較高，最后也能幫我們招到想要的人。

另外，我們最近也在嘗試一些新的辦法。比如我們會給你一個寫好的大型 project，其中埋了很多雷，然后要求你在一小時內(nèi)優(yōu)化它。這個項目很復雜，時間又很緊迫，你大概率只能靠 AI 來快速理解和解決問題。

Q7：該如何打造一個 AI Native 的團隊？

任川：我們比較幸運，公司很新，沒有歷史包袱，所以一開始就在用全新的 AI Native 的方式來組建團隊。

在我看來，經(jīng)驗在這個時代未必是優(yōu)勢，很多時候甚至會成為負擔。

比如有一些比較 senior 的人，已經(jīng)習慣了傳統(tǒng)的工具和工作流，連 Cursor 都不愿意用，就很難適應新的組織方式。相比之下，一些剛畢業(yè)、學習能力和求知欲都很強的年輕人，反倒是更適應 AI Native 的團隊。他們在讀書時就已經(jīng)離不開 AI，用 AI 工作對他們來說非常自然。這樣的人雖然不好招，但我相信未來一定會越來越多。

Q8：公司在 10 人、50 人、100 人的規(guī)模下，分別需要設立哪些崗位？

任川：我們現(xiàn)在只有 20 人，所以我不敢斷言 50 人、100 人的公司會怎樣。但我們的底層原則始終是「按結(jié)果分工」，也就是每個人都要為某個目標或問題負責。至于怎么實現(xiàn)，我認為沒必要通過分工設太多的限制，可以讓大家自由發(fā)揮。

這里可以請虞快補充下，Mercor 擴張到 150 人之后，出現(xiàn)了什么新崗位？

虞快：我們一上來就是每個人負責一個 feature，公司漸漸變大了之后，開始招負責安全、QA、測試的人，后面隨著平臺擴張，也會需要平臺工程師。

Q9：該怎么招到和留住優(yōu)秀的人才？

任川：前面我有提到過一點，就是未來需要給核心員工合伙人級別的待遇。

另外，我很認同一位朋友說過的一句話：與其費勁招人，不如先提升自己。

有時候你招來兩三個人幫忙，可能比你一個人干還要忙。但如果你能用好 AI 工具，那你一個人也有可能完成原本需要兩三個人才能完成的工作，效率反而更高。

虞快：我補充一點。

在招人時，我發(fā)現(xiàn)越是強的人，越要給 ta 上面試難度。因為強者往往有天然的好奇心和挑戰(zhàn)欲，如果你的公司名不見經(jīng)傳，面試流程卻很特別、很有挑戰(zhàn)，ta 可能更愿意加入。

42章經(jīng)

思考事物本質(zhì)