（點擊收聽本期音頻）

采訪｜泓君

圖文｜朱婕

“Harness Engineering”（挽具工程）正在成為硅谷的新共識，Anthropic、OpenAI等公司都在探索這一工程范式。但真正理解Harness的人還不多。前不久，一篇題為《Why Your “AI-First” Strategy Is Probably Wrong》的文章在X上獲得百萬級閱讀和熱議，作者是來自硅谷CreaoAI的Peter Pang。在這篇文章里，Peter展示了Harness Agent系統激發出的極致效率：99%的代碼由AI完成，每天平均3到8次生產部署，過去六周的產品流程，現在一天就能跑完。

本期《硅谷101》播客，主播泓君邀請到Creao的三位創始人，聊聊這家公司對Harness的實踐，以及在組織AI-First轉型上的深度思考。嘉賓們指出，AI-First不等于“使用AI”，想要把效率提升100倍、1000倍，就不能只把AI當成工具，而要讓AI成為所有生產力的主導。組織轉型最難跨出的一步在于——是否能讓所有員工都能做到信任AI。

這場對話中有一些有趣的觀察，比如在Creao，市場不用再追著開發提需求，因為開發速度已經遠超市場消化能力；當大量對齊工作被AI接管之后，拿掉產品經理，反而讓團隊效率大幅提升；初級工程師比資深工程師更適應AI時代的轉型；盡管過去十年積累的專長正在快速貶值，但資深工程師仍然有競爭力，因為未來的核心競爭力不再是寫代碼，而是“找到AI Planning的缺陷”和“判斷什么是有價值的”。

歡迎關注《硅谷101視頻號》的音頻欄目直接收聽本期播客。如 果 你喜歡我們的 節目，更推 薦大家使用 音頻客戶端來收聽，《硅谷101 》已覆蓋各大 主流音頻 平臺（渠道見文末），歡迎訂閱！

以下是這次對話內容的精選：

01

Harness工程詳解

如何把大模型“榨”出極限

泓君：先請Peter介紹一下，什么是Harness engineering （ 挽具工 程） ？

Peter：Harness的概念可以追溯到大模型剛開始的時候，很多人在聊prompt engineering（提示詞工程），之后演變到context engineering（上下文工程），這時候更多的是聚焦在怎么和大模型本身進行交互。

但是對于Harness來講，我們是在“馴化”一個通用的系統，所以從范圍上來講，它比prompt & context engineering要大很多，涉及到tooling（工具鏈）的使用，涉及到你的sandbox（沙箱）的架構設計，你的host service（宿主服務）之間是怎么進行交互的？怎么樣的交互能夠安全？你的sandbox在啟動的時間是多少？你的延遲是多少？……這些都是harness的一部分。

泓君：可不可以理解成，Harness的工程能力決定了怎么把一個大模型“榨出”最佳使用上限？我記得Kai有提到，一個Agent可以一夜之間干掉三個人做SEO（搜索引擎優化）的工作流；同時還有一個內容流水線，它跑了兩天，才有人發現全是垃圾。這兩者之間有巨大區別——一個是Harness的勝利，一個是Harness的失敗。

Peter：我覺得這個完全就印證了為什么我們需要Harness。Harness的本質就是在于，我們怎么能夠持續提升一個系統。當你這個系統產生的效果不好的時候，你這個系統是需要人的feedback（反饋）去提升，還是這個系統本身自己能夠self healing（自我修復）、self improvement（自我優化），這個正好就是Harness的核心。

Harness很重要的一件事情，就是怎么能夠讓Agent在推理階段scaling（擴展），包括你怎么能夠把更多的上下文、工具鏈提供給它，讓它思考更長的時間，完成一個任務，用一個更長的時間。在這個階段如果你的Harness做得不好，就很容易產生hallucination（幻覺）或者context overflow（上下文溢出），你的模型能力會降級。所以Harness是一件非常復雜而且需要一些經驗的事情。

泓君：那今天市場上對Harness有哪些共識和非共識？

Peter：很多人認為Harness是靜態的，就是開發配套系統發揮LLM優勢。但我們認為它是一個動態的過程——你這個系統怎么能夠從一個靜態的狀態真的活起來，能夠self-improve（自我優化），能夠不停地適配來自市場、產品、用戶的各種signal，能夠讓它不停地、迅速地迭代。我覺得這個是可能很多人還沒有意識到的一點。

泓君：這個迭代也是以AI為主導的，而不是人為主導的？

Peter：對，是以AI為主導的迭代。人所需要做的事情，就是怎么把各種各樣的信號feed給AI。

02

六周變一天

AI驅動的開發流程有多快？

泓君：你有一篇很火的推特帖子，講你們25人的公司，99%的代碼由AI寫，早上10點寫了一個功能，中午就進行了A/B test，下午3點就根據數據的反饋把它砍掉了一部分功能，5點又重寫了更好的一個版本。這是一天的工作節奏，在傳統的開發產品的過程中，它是需要6周的。這是你們用Harness探索出來的方式。

Peter：在我們看來，Harness分為兩個部分：一是對Creao自身Agent系統的Harness，二是用戶用Creao構建自己Agent時，怎么幫他Harness自己的Agent。傳統開發過程中，可能要用兩三個月迭代一個功能，現在AI輔助coding只需一兩小時實現，如果還用很長時間去設計和測試，就不是很有意義。所以怎么把設計、規劃、測試都包含到整個Harness過程中，對公司能不能轉型為AI-First至關重要。

Clark：我想先跟大家表達一個觀點：如果想做到所謂的AI-First或者AI native（AI原生）這樣一個狀態，它不是在現有流程上去使用AI工具，而是要圍繞AI能力重新構建工作流程和組織形態。

圖片來源：Peter Pang@intuitiveml

我們在之前很長一段時間里，每一個工程師都在用AI寫代碼，每一個產品經理都在用AI寫PRD（產品需求文檔），每一個設計師都在用AI做圖。但其實這樣并沒有增加我們的效率，反而導致每一個人的工作進度和節奏不一樣之后，我們的alignment（對齊）成本變得非常高，我們還是全部遠程辦公的狀態。

所以我們要去重新想，我們到底怎么樣才能讓AI在公司運營過程中真正地自動化跑起來，才有了Peter設計的一套新的開發流程和架構和新的產品的架構重構，才有了這篇文章里面講的self-healing（自我修復）的Agent Harness。

泓君：可不可以舉個例子，你們重塑組織架構時，哪些方向發生了變化？瓶頸在哪里？

Peter：首先需要解決人的問題——大家能否接受新工作方式。我們花很多時間對齊mindset（思維模式）。以前做這樣一個轉型，通常需要一個架構師或工程師花費好幾個月來demonstrate（展示）新的工作方式更優，但這個轉型成本就很大。

現在在AI輔助下，這個過程就會快很多，可能只需要一兩周把整個系統，包括前端、后端、架構、基礎設施，都進行重構，然后給大家展示它工作起來更高效。不管是部署的頻率、部署的可靠性和最后的效果上，都比之前的工作方式有很大提升。這樣能在很短時間內對齊思維模式，讓大家快速融入到整個開發過程。

Kai：其實Harness本身它更多是在于構建一個系統，真的能讓所謂的AI-First的組織高效運轉。很多組織上的人，思維難以改變，他覺得用AI提升效率就夠了。但是AI-First要求的是，你讓AI來driven（驅動）你整個公司的方向，可能你每天工作的方式都是由AI來驅動的，這是完全不一樣的概念。

泓君：是AI給你們布置任務嗎？

Kai：對。如果還把AI當成一個提升效率的工具，那使用者的效率提升可能最多就是10倍，因為人最多每天可能就工作24小時。如果希望效率提升100倍、1000倍，你不能說你是那個工具的使用者，而是AI應該是所有生產力的主導。人的角色發生變化，更多是在于怎么去復盤結果的好壞。還有在這個系統里，我并不是那個實際的工作者，我應該以怎樣的一個方式去跟這個系統配合起來？這是很多企業在做轉型時，沒意識到或很難去做到的事情。

泓君：舉個例子，你們的系統怎么和人去配合工作？我覺得傳統的團隊開發產品的時候，可能很大的一個痛點就是說，我團隊之間要對齊，然后我要把信息同步到每一個人，任何一個人他可能miss掉了一個信息點，那他在產品做開發的時候，可能就不知道我們上一版的更新是什么。現在是不是所有的這些工作都可以交給AI，或者在這個流程中它就可以自動去做了？

Kai：我覺得這里面核心還是信任的問題。很多人對系統不信任，所以對齊成本就非常高。現在AI-First下，對齊由AI主導，比如AI告訴市場團隊今天工程師要發布哪些功能，市場團隊不用再反復問工程師。

泓君：AI怎么知道工程師團隊明天能把所有的工作做完？

Peter：在AI的思維模式之下，迭代一個產品的過程中，我們更側重的是，這個新的功能能不能夠帶來產品的top line metrics（頂層指標）的提升，或者新的這個功能能不能有真的用戶使用的數據。所以在這個過程中，我們更核心聚焦怎么把整個數據鏈搭建起來。我們把這個鏈條搭建起來之后，都是Agent通過這些數據來決定，好，這個功能到底是不是有用的，我們到底要不要roll out（上線）這個功能，或者fall back（回退）這個功能。

泓君：也就是說工程師寫完代碼以后，不需要手動地跟AI說“我寫完了”，現在AI它就可以自動地根據你的整個代碼質量，你的進程，去做出它的判斷。

Peter：對，這個在傳統的工程中也有，我們叫CI/CD process（持續集成/持續部署流程）。只不過在傳統的CI/CD process中，很多都是rule-based（基于規則）或者一些unit testing（單元測試）驅動的。但是在AI這個情況之下，我們可以有很多AI驅動的測試。比如現在大家比較常用的像Playwright，是可以做AI驅動的完整的end-to-end testing（端到端測試），這樣可以保證我們發布的代碼中沒有明顯的可以破壞這個產品的bug。所以在這個過程中，很多AI驅動的測試是非常重要的。包括你代碼發布之后，在這個日志中有沒有error，有沒有incident，都是通過這些信號能夠反饋給AI，來看整個這個代碼的質量是什么樣子的。

泓君：關于讓AI寫代碼，怎么保證它的質量？Peter的文章提到了，正常情況下寫代碼一天，大家修bug要三天。現在有什么新手段，可以讓大家不用把很多的時間都花在修復上？

Peter：我覺的bug是整個工程中不可避免的，不論AI寫還是人寫。因為Harness不是一個靜止的狀態，它不是說我現在有一個系統之后，我只需要維護這個系統，這個系統不會有bug，也不需要提升。

Harness這個過程的核心就是在于，我能不能找到這個系統中的bug。剛才聊到CI/CD的過程中，我們會有一系列的regression test（回歸測試），去避免一些bug發布到production（生產環境）中破壞這個系統，這是第一步。第二步，即便有一些corner case（邊界情況）或者race condition（競爭條件）發布到這個系統之后，我們怎么能夠在最快的時間識別這些bug，然后及時地修復這些bug。

傳統的情況之下，這兩步都是由人來驅動的，但是在Agent Harness情況之下，我們會有Agent系統來驅動。所以我們開發了Agent-driven的CI/CD系統和Agent-driven的bug triage（分類/定級）系統，會根據系統中的問題去triage這個問題，然后指派給工程師讓他們去修復這些bug。

圖片來源：Peter Pang@intuitiveml

泓君：你覺得在你引入這兩套系統以后，它的效率提升了多少？

Peter：因為很多都是Agent-driven，所以它可以并行地進行，可以有很多Agent同時去identify（辨認）。它發現一個bug只需1-2分鐘，指派給工程師幾秒鐘。工程師再用Agent調查并提出方案，整個cycle大約1-2小時。對比之前，我們識別、修復一個bug，再把它發布到系統中，可能需要一周的時間。

Clark：對，這里面有一個特別有意思的現象。我們以前有一個feature wish list（功能愿望清單），很長，又有一個bug list，有很多bug要修復。以前市場和產品還有工程師就總是討論來討論去：到底是先修bug還是先做功能？現在這兩個清單都沒有了，bug及時發現，及時修復，feature現在的數量遠遠多過于我們所需要的數量。

Peter：我們現在有一個auto-fixing（自動修復）系統。對于我要修復的一些東西，如果只是存在于一些風險比較小的文件夾之下的話，AI自動提交PR（拉取請求），工程師簡單批準即可發布。現在50%以上的問題是通過auto-fixing完成的。

03

架構師：Harness中的核心角色

泓君：因為我不太懂寫代碼，只能用寫文章做比喻。假設我是在改一篇稿子，即使它只出現了一個小錯誤，我可能需要把整個稿子看一遍，那這個時間跟我自己重新寫，花的時間是差不多的。如果Agent幫你搭了一個非常好的技術框架，但在基礎層出了大錯誤，需要工程師解決，工程師是不是得把整個系統重新學一遍？

Peter：我覺得這個問題很好。在之前的我的文章中，我也討論了在AI環境之下的工程團隊可能分為兩種人：一種是architect（架構師），一種是operator（操作者）。架構師在整個這個系統搭建過程中的作用是非常重要的。比如說在搭建整個Creao的系統過程之中，整個Agent的架構是什么樣子，比如說sandbox（沙箱）和host（宿主）之間是怎么交互的，還是由架構師來決定的。

如果說Agent直接通過AI coding或者vibe coding（氛圍編程）的方式，給你一個solution（解決方案），但這個解決方案通常會有安全的隱患或者延遲的隱患。怎么去優化整個這個系統，還是由架構師來決定的。區別在于，傳統搭建Agent的團隊以前可能需要10到20個人，但是現在搭建整個這樣一個系統只需要一個架構師，在一個周的時間之內就能完成。

Clark：我來補充一下。AI能力早就很強了，但為什么還沒達到人們的預期？人們覺得AI沒干好，我還得幫它彌補錯誤。這里需要有一個概念上的轉變：我們要把AI當成一個系統來看待，而不是一個智能。當系統出錯時，不要想著糾正這個智能，而要想著彌補這個系統。這個其實是我們在做Harness跟現在普遍的認知最不一樣的地方，它是一個動態改變和提升的過程，不是靜態的、固定的枷鎖去束縛這個智能，要給它提供空間，讓它能夠成長。這個成長的方式就好像你在養一個孩子，讓它在一個規則內越來越好。

泓君：這個觀點很有意思，以前是“解決問題”，現在是“解決系統上的問題”。

Clark：這里面還有一個更激進的想法，我們自己發的這些內容，可能未來的這些受眾并不一定是人。比如一個市場部門的物料，可能從人的審美上去看它并不好。但實際上你把這個東西投向市場的時候，你會發現，讀這篇文章或者讀這個圖片的是一個Agent在讀，它的數據反饋回來，可能是更好的。

以后可能買東西是由Agent去買，訂報紙是由Agent去訂……那你的廣告是發給Agent看，還是發給人看？你要搞清楚你的工作結果到底是被誰消費，針對這個東西的價值，我們再去思考，到底是提升系統，還是回到最原始的人的創作過程中去彌補一些錯誤。

泓君：我相信在未來做消費決策的時候，可能還是Agent看得多。但是它來得比我預期中要快很多，整個進化還是非常的快的。

Peter：從另外一個角度上來講，也可以很明顯地看到現在SaaS產品的轉型。因為以前很多SaaS產品，它需要一個給人去看、去管理的dashboard（儀表盤）。但是在起碼現在這個階段，我們團隊在使用任務管理的時候，我們更關心的是Agent能不能“看到”并prioritize（設定優先級）這些任務。所以我們會去看這些任務管理產品有沒有更好的MCP（模型上下文協議）和API（應用程序接口）提供給我們的Agent使用。

泓君：所以整個進化還是非常快的。

Kai：其實剛才您提到這個問題，也是很多公司在做AI轉型時候會第一個考慮的問題，他覺得使用AI的時候，我還要review一遍，那跟我人去做時間和成本沒差別。但如果真把AI系統構建起來，仔細算一下，時間和成本會有很大提升。只是這個過程需要整個團隊有共同目標，只要有人覺得還不如人做，改造時間就會被拉長。這是大多數企業從組織上面臨的挑戰。

04

轉型最難的一步

從信任人，到信任AI

泓君：你們是第一天就AI-First，還是后來摸索的？

Kai：我們整個公司也是有一個過程的，你要意識到誰是未來的生產力的核心的角色。2025年上半年，大家還是覺得AI是輔助人去做事情，人在工作中占主導地位。但是到了下半年，我們意識到，如果還是這樣，企業效率提升還是非常有限的。核心問題是沒有把生產力工具的使用者真正從人轉變到AI。這種轉變需要時間，市場團隊和工程團隊甚至花了一兩個月來來回回探討怎樣是更好的工作方式。

Peter：我覺得這也是跟AI能力提升相關的，過去一年內，AI從輔助角色，到參與開發，再到現在能夠相對來說主導開發過程，角色的轉變是和基礎模型能力提升、Agent架構和基礎設施的提升相關的。一年前讓AI主導開發從技術上來說不成立，但在我們重構過程中，當發現AI到達了那一個點的時候，整個重構速度和效果遠超一年前能夠想象的程度。

泓君：你們是從什么時間點開始重構的？做了哪幾件核心的事？

Peter：意識到需要重構是去年八九月份，花的最多的時間就是讓大家轉變思維方式。真正開始重構代碼架構和開發過程是今年1月，用了大概兩周，重構了整個架構，包括現在大家看到的產品。

泓君：有哪些你們覺得之前AI解決不了的事情，然后AI解決了？

Peter：之前AI解決不了的事情主要是在規劃（Planning）階段。比如說我以100分為滿分方案的話，現在它能給我一個90分的方案。我看到這個規劃的時候，我能夠再給它一些criticize（評判），它能夠給我一個revised plan（修改后的方案），而不需要我真實地去改這個規劃。一年之前的話可能也就是50分，我可能需要人為地再去modify（調整）這個規劃，再去改整個架構。

泓君：你覺得AI寫代碼的能力在你之上嗎？

Peter：首先，AI寫代碼的能力肯定是在我之上的，2026年我就沒有寫過一行代碼。但是從規劃的能力上來講，作為一個架構師的價值，不管你是一個CTO還是一個技術負責人，你的價值就是在于找到AI planning的缺陷。現在AI的規劃還是有缺陷的，比如說它一開始給我的規劃可能有安全的缺陷，可能有延遲的缺陷。那我根據我之前的架構經驗，我怎么能夠評判它或者質疑它，能夠進行進一步的提升。

泓君：你教了它，要怎么去做這個延遲性，安全性，它現在再做新的規劃會變得好很多嗎？

Peter：這個就是Harness的核心。之前我教給它，你在安全性上，在設計sandbox和host之間的關系的時候，你要遵循什么樣的準則。這個時候我就可以把它變成一個Skill，在下一次的過程之中，我只需要引用這個Skill，代替我去說更具體的內容，就變成一件很容易的事情了。所有其他的我們團隊的工程師，也可以參考這個Skill。

泓君：可不可以給聽眾一個直觀的印象？你現在有了AI做生產的主力以后，它干出了配多少員工才能干到的事情？給大家一個數字上的直觀的感受。

Peter：如果翻到一年之前，不是AI主導的情況之下，要研發像Creao現在這樣一個產品，我覺得起碼需要100人左右的團隊，花四五個月的時間去研發這樣一個版本。如果大家看其他的general Agent（通用智能體）公司的規模，大概也是這樣一個范圍。現在公司25人，工程師團隊10人以下，從產品第一個階段的部署只花了約兩周。

Kai：從SaaS公司運營一個SaaS產品的角度來看，你會有個很直觀的感受。傳統軟件時代，銷售團隊的概念會超前產品4-5個月；現在反過來了，技術團隊反過來超前了市場團隊4-5個月，市場團隊在追趕開發的功能。這會導致整個運營和組織結構可能都跟原來不一樣。

泓君：Clark，你這一塊會有從市場營銷的層面也用更多的Agent嗎？

Clark：市場拓展團隊會用我們自己公司的產品去構建AI-First的workflow。當然這里面有很多坑。我覺得最大的一個困惑就是：Engineering相對好做評估，它能夠有明確的指標說今天你干得好還是不好。但是從go-to-market的角度，不管你是寫文章也好，做視頻也好，每個人他都有自己對這個價值的判斷，相對比較主觀。那我們怎么樣去構建這個系統，能夠更好地把這些主觀的判斷變成一種信號，讓我們的系統能夠自動去運轉起來，這是一個比較大的挑戰。我們也沒有說我們今天就是100%讓Agent去做決策，但我們會放很多Agent的結果，再由人去判斷說這個結果好還是不好。我們有很多功能，但我覺得市場還沒有準備好，那我們就不會把這些東西放到市場上面去。

05

為什么大企業難轉型？

中小企業的AI紅利期

泓君：我很好奇你們有哪些超前的思想是市場還沒有接受的？

Clark：每個人的Agent都有所有的權限可以讀寫，這個其實是一個相對來說比較大膽的動作。我們希望說，未來為了能夠讓你的組織更加高效，你的很多數據是應該開放給你的Agent，開放給每一個人。但這里面可能還需要更好的一些技術的支持，包括你怎么樣去限制每個人的權限，或者限制Agent權限，怎么樣讓這個Agent在讀取這些數據的時候不會出現失誤。比如說我原來要說“Peter，今天我們有多少個用戶，有這樣的行為”，可能還要去找做數據的同學或者工程師去幫我搭一個新的表格出來。但今天我只需要跟Agent說，我提這個問題，它立刻3秒鐘之后給我一個答復。

Peter：我覺得現在主要的挑戰，不是市場能不能接受這種工作方式，而是市場不知道這種工作方式的存在，或者他不知道怎么去高效地使用一個Agent幫助他能夠完成他自己的工作。所以Creao在整個的這個過程中，我們也做了很多工作，就是讓用戶不用進行復雜的設置，能夠更容易訪問這個Agent，幫助他完成他自己本身的工作。

泓君：所以你們對標的場景跟你們主要的客戶是誰？你是對標大企業里面的工作流程自動化的，還是創業者或者個人，還是普通的大眾？

Kai：都會有。但我們真正的目標，還是那些所謂的SMB（Small to Medium Business，中小企業），因為這個可能是最早去采用AI的人群。越大的企業合規的問題越多，還有很多的“人”的因素，會導致它的整個過程會非常艱難。但是如果一家公司如果沒有太多的合規問題，沒有一些傳統的legacy（遺留系統），其實你就是第一批最容易去做這個轉型的公司。

圖片來源：Pixabay

泓君：一個公司想要做這樣的轉型，是不是他們的創始人也得有一個核心信念，就是相信AI？

Kai：對。更多還是他們得搞清楚，這個轉型最后代表的是什么。我舉個例子，在2023年剛剛大模型出來的時候，很多的SaaS公司想的都是我怎么把AI做成一個功能集成到我的產品里面。這個本質來講是沒有搞清楚：如果你要做這樣的功能，有沒有可能你原來的產品架構是不支持把這些最新的AI能力給集成進來的？因為你的數據庫可能也不符合要求，你的交互可能也不是未來的一個方式。所以說你可能需要去做的事情是整體產品的重構。如果接受不了這個結果，那可能也很難去做這個轉型。

06

當AI主導生產

人類的新角色是什么？

泓君：可不可以講一下你們的組織結構是如何發生變化的？剛剛舉了很多的案例，但是我還是想知道一個whole picture。

Kai：整個組織結構變化，我覺得這里面是很多角色的變化。首先，如果你真的要搞改造，你需要做的第一個點其實是信任上的變化。原來你組織信任的是人，但現在當你把AI拿進來之后，你要先解決第一個問題：就是你能不能信任你的AI做決策或去執行任務。這個信任其實就跟為什么我們要去構建一個Harness系統是一個道理，我們得有很多guardrails（護欄）還有機制，去保障AI做的所有工作，不管它做決策、規劃、還是執行，最后它的這個東西是能夠被人去信任的。

接下來就是你所有的組織結構里面具體位置的變化。我們沒有單獨的產品經理這樣的角色了，他被拆解到了每一個工程師和像Peter這樣子的做工程管理的人身上。這個崗位我并不覺得它不重要，而是在于他通常是矛盾最集中的那個點。產品經理同時要跟市場溝通，跟開發溝通。大量的對齊成本都發生在產品經理的角色上面。但當你把這個角色給拿掉之后，你會發現，對齊的成本反而有時候可能會更低。

泓君：產品經理這個角色，你覺得現在還有價值嗎？或者說重新招一個類似于產品經理角色的人，你覺得他需要有什么樣的新技能？

Kai：未來需不需要產品經理？一定需要的。未來有一種可能，就是產品經理職位的很多權力會分散在開發團隊的各個人身上。因為如果說你的每一個開發團隊成員在AI的幫助下都能夠更好地去有產品觀念的話，其實你本質來講有沒有這個職位也不太重要。因為原來產品經理我覺得他更多解決的是對齊的成本，還有如何幫助公司去降低開發成本。

泓君：我可不可以這樣理解：現在相當于工程師Peter的團隊，他們某種程度上扮演了產品經理的角色。但是反過來，一個好的產品經理，他其實對市場、對產品也是非常有想法的。加上現在開發的成本是非常低的，他可能也很容易就把他的一個想法通過AI的執行能力很快變成了一個好的產品。他甚至不需要工程團隊了。所以說，其實這兩種角色他某種程度上在融合，在變成一種角色。所以這個角色到底是一個技術的團隊來做，還是一個產品的團隊來做，其實不重要，因為都是AI在主導，想法更重要。

Kai：對。未來這個職位本身，它可能不是說一個人，而是一個團隊整體扮演這個產品經理的角色，這個角色本身它會被組織化掉。在傳統軟件時代，有很多個人英雄主義，就說因為某一個產品經理或一個靈魂人物，導致最后這個產品特別受歡迎。但未來可能是一個組織做了一個很好的產品，被這個市場接受。

Peter：我覺得有一個非常明顯的趨勢，復合型人才，或者比較general（通用）的人，他在AI環境之下可以茁壯成長得更好一些。不管是說一個工程師他有產品的感知和市場的感知，還是說一個產品經理他具有implementation（實現）的能力，都會非常的重要。另一個趨勢：UX和UI的設計師會變得非常重要，但他們需要具備把想法落地到產品中的執行能力。如果你需要把你的想法傳遞給另外一個人或者，那你交流或對齊的成本就遠大于你執行的成本，在整個的AI的工作環境之下就變得不是那么的高效。

泓君：Peter，你有一篇文章我印象很深，你說初級工程師比資深工程師更能適應AI環境，為什么？

Peter：因為初級的工程師的技術債務或者他的思想的束縛，通常來說比較小，他能夠接受擴展他的scope（范圍），他不僅是作為一個工程師，也要融入到一些產品的設計之中，包括產品他的feature deploy（功能部署）之后，他還需要做一些分析，他根據分析能夠做出他的一個判斷。

但通常來講，比較高級的工程師因為他比較specialize（專精），比如說你是一個做基礎設施的人，或者你是一個做后端的人，你可能在傳統的工作環境之中，你不關心你的代碼發布之后發生的事情。但是在AI這個環境之下，你的工程師的范圍就需要比之前擴大很多，就不只是在我把這個代碼寫完之后就結束了，而是在于我代碼寫之前我怎么能夠把自己的judgment（判斷）加進去，代碼發布之后怎么能夠判斷它的impact（影響）。整個這個過程是非常重要的。

通常來講初級工程師是能夠更好地接受這樣的一種工作狀態。比如說你跟一個資深工程師說，除了負責前面你代碼已經交完了的這個過程，你還要負責后面的這個過程，他們是不能理解跟馬上去轉變這個思想的。通常來講，需要對齊這個思維模式的成本要高很多。

其實作為一個高級工程師，或者作為一個專業領域的——不管你是做基礎設施的人，還是前端的人——在過去的軟件開發過程之中，你的知識是非常有價值的，因為你能夠知道在開發這個系統之中怎么樣寫最簡潔的代碼，怎么樣設計最好的架構，你可能需要兩三個月的時間去完成這樣一個事情。但是AI編程在現階段它已經很強了，以后會變得更強，所以它會讓你本身的specialty（專長）變得越來越低。所以很多人可能接受不了這樣一種狀態，就是他本身能花了10年、20年時間學到的這樣一些知識，變得可能在未來并不那么重要。

泓君：所以你們現在更傾向于招哪一類的人？

Peter：我文章中雖然提到，轉變一個資深工程師的難度要比一個相對來說初級工程師的難度要大。但是從價值上來講，一個資深的工程師的價值現在是不能被取代的。所以怎么能夠找到一個資深的工程師，他還能夠擁抱AI的思維模式，而且他能夠具有一個產品的感知，他能夠還知道一些市場的知識。這個人雖然很難找，但是對于公司來說是非常有價值的。好處是在于，之前我們可能需要很多這樣的人，但是現在我們可能只需要一到兩個人就可以了。

泓君：現在我們說AI成為主力，AI也可以迭代產品，所有的東西都是動態的。大家覺得未來人最核心的能力是什么呢？

Peter：我覺得人最需要的能力就是系統架構的能力。從以前implement feature（開發功能），變成怎么架構這個AI系統和maintain（維護）這個AI系統。不管是工程師還是市場的角度，你做go-to-market，核心過程也要去搭建一套能夠自主運行的Agent的市場系統，而不只是單純地產生一個市場內容。

Kai：人的價值如果從真的很長遠來看，就跟我們技術發展整個過程一樣，確定技術發展方向永遠是人的需求和這個社會的需求。只要人這個物種還存在，人定義需求的方向和審核最終結果的價值是無法被取代的。

【音頻收聽渠道】

公眾號：硅谷101

收聽渠道：蘋果｜小宇宙｜喜馬拉雅｜蜻蜓FM｜網易云音樂｜QQ音樂｜荔枝播客｜嗶哩嗶哩

海外用戶：Apple Podcast｜Spotify｜TuneIn｜Amazon Music

聯系我們：podcast@sv101.net