
作者 & 采訪 | 王啟隆
出品丨AI 科技大本營(ID:rgznai100)
![]()
三十年的軟件工程江湖,像一條奔流不息的河。
有人淘金,有人擺渡,有人筑壩,而吳穹,是那個試圖畫出河流走向圖的人。
1995 年,師從楊芙清院士和梅宏院士,吳穹正在北大參與“青鳥工程”,一個近乎理想主義的嘗試——在中國建立一條真正的“軟件工業生產線”。做學術研究時,他內心總有一個強烈的聲音在催促:如何將這些抽象的理論“落地”?畢業前夕,他找到了當時在全球軟件工程領域聲名赫掣的 Rational 公司,毛遂自薦,最終竟促成了這家巨頭在中國的第一個辦事處。就這樣,他幾乎是以一己之力,將 Rational 及其方法論 RUP(Rational Unified Process)這本“圣經”引入了中國。
那是一個“引渡者”的黃金時代。UML 統一建模語言、RUP,這些來自海外的嚴謹范式,如同精確的圖紙,被遞到了一群最渴望規范與秩序的中國工程師手中。吳穹和他的同仁們,就像當年的普羅米修斯,將理性的火種帶到東方。他親手將 RUP 翻譯成中文,免費提供給整個社區,無數 CTO 和 CIO 都曾感念,是 RUP 為他們野蠻生長的研發體系,注入了第一支標準化的疫苗。
故事本可以這樣繼續——一位成功的布道者,不斷引進、翻譯、推廣著世界上最先進的理念。然而,河流的走向,遠比地圖復雜。
在美國 IBM 擔任全球產品經理的三年,是他人生中的一次關鍵“離岸”。他負責的是一款名叫 ClearCase 的配置管理工具——用他后來的話說,那是“Git 的爺爺”。他深入到一個全球頂尖產品的肌理之中,從產品經理這個“Mini-CEO”的視角,體驗著一套成熟的、源自西方的研發文化。他看到的不僅是技術和流程,更是土壤之下的文化根系。
2007 年,當他帶著敏捷開發的浪潮再度回國,開始幫助華為、平安科技、招商銀行等巨頭導入新的管理實踐時,他清晰地聽到了“水土不服”的斷裂聲。
矛盾,如同水下的暗礁,開始浮現。
西方的敏捷,誕生于鼓勵試錯、崇尚自組織的土壤,而中國的企業文化,更像一部嚴整的交響樂,強調“偏管控型”的指揮體系,追求令行禁止的確定性。
“很多敏捷教練什么都不管,就強調“敏捷”是對的。” 吳穹回憶。但這種“拿來主義”的失效,讓他猛然驚醒。他意識到,自己不能再做一個單純的“引渡者”。照搬最佳實踐,本質上是一種思想上的懶惰。真正的價值,在于回到第一性原理——“敏捷”究竟要解決什么問題?是溝通效率,是快速反饋,是價值流動。然后,再用這些原理,去重新設計一套真正適合中國這片土壤的“農具”。
這背后,是他堅守了近三十年的核心戰場:軟件,是充滿不確定性的藝術;而工程,是冷冰冰的確定性。他的使命,就是在這兩者之間,為這門藝術建立工程化的秩序,讓高質量的交付變得可預測、可執行。
“這個能力,一直是我們國家很缺乏的”,他認為自己的價值,就是把這件事幫助更多的企業去落地。這是他從“理念的引進者”蛻變為“本土范式的開創者”的轉折點。他不再滿足于給出地圖,而是要親自勘探、繪制一幅屬于中國人自己的軟件工程地圖。這幅地圖,就是他后來參與創立的 Adapt 方法論。到了 2016 年,當他意識到僅靠顧問一人之力難以撬動上千人的組織時,他需要一個杠桿。于是,軟件工程工具“知微”應運而生,將他的思想注入代碼。
然而,就在這幅地圖逐漸清晰之時,一場更大的風暴席卷而來。
AI,以一種近乎蠻橫的姿態,沖進了軟件工廠。比爾·蓋茨那句“我們總是高估未來兩年的變化,低估未來十年的變革”的箴言,正在被狂熱的現實所驗證。CEO 們在云端宣告要“All in”,要徹底顛覆;而一線的開發者,卻在“AI 幻覺”和“上下文缺失”的泥潭中掙扎。
一個新的、更深刻的矛盾擺在了所有人面前。吳穹敏銳地捕捉到了其中的荒誕之處:AI 工具的宣傳,出現了兩個截然相反的化身。“如果這個東西對員工是摸魚神器,在老板那兒它就不會是提效神器。” 吳穹一語道破。生產力的變革,從未如此尖銳地觸及生產關系的根基。工具就在那里,但員工為什么要用它為公司創造價值,而不是提前下班?
這不再是一個技術問題,而是一個直抵人心的管理問題、一個組織變革的系統工程。
當 AI 可以像員工一樣“領取任務”,甚至可以被“管理”,當一個程序員不再是親自耕種的農民,而是變成了擁有一個 AI 軍團的“地主”,我們又該如何衡量他的價值?當軟件的生產成本趨近于零,這張圖景的終點,或許就是一座將燈光熄滅、人類僅負責少量關鍵決策的生產體系,讓 AI 自主編碼的“黑燈工廠”。
這條奔流了三十年的軟件工程之河,正迎來一次史無前例的河道變遷,甚至可能是一場沖毀一切堤壩的洪水。在本場對話中,我們將與吳穹一同探討:軟件工程的舊范式將如何被顛覆?而我們,又該如何自處?
![]()
![]()
“必須有一套中國人自己的、本土的、接地氣的方法論”
王啟隆:吳博的職業生涯經歷了從理念的引進者到一個本土范式的開創者的變化過程。有沒有什么契機讓您覺得單純從海外引進可能不夠了?有沒有什么具體的項目或事件,讓您頓悟到必須有一套中國人自己的、本土的、接地氣的方法論,也就是本土范式?
吳穹:出國之前我服務國內企業,到美國這三年,算是深度參與到一個產品的整個研發過程中。因為那三年我是作為 ClearCase 的產品經理,我跟那邊的客戶、研發團隊、銷售團隊等各種各樣的團隊打交道。產品經理其實是一個 Mini-CEO,相當于一個產品的全面負責人,所以我會跟很多人去打交道。
等到我 07 年回國的時候,一開始我們是把國外的像 Scrum這樣的方法論拿回來落地。前幾年我們也是抱著落地的想法,但過了一段時間就發現會水土不服。因為我這三段經歷有兩段在國內,一段在國外,所以我比較明確地看到兩種文化、兩種思路的不同。我們國內整體上還是一個偏管控型的文化,這沒有對錯,可能是文化不同。
比如你按這樣的方式去管理華為,可能會成功;但用這個方式去管理 IBM 可能會不成功。用 IBM 的方式去管理華為,雖然華為學了一些 IBM 的東西,但也不代表它全盤照抄。實際上華為在落地 IPD 的時候,還是做了很多自己的管理變革和創新。
如果你去國外,沒有那么多人會說我在用 IPD 管理。所以我覺得華為也經歷了一個本土化的過程。我們的管理文化、實踐、組織架構、管理方式,都跟西方公司有很大差別。當你把一個敏捷方法論落進來的時候,我們以前很多時候就是不管,就說這是對的。
王啟隆:你自己去想解決方案。
吳穹:對。但是我們當時覺得這樣不行,要把敏捷的核心思想和國內的本土實踐相結合,給出一個很具體的指導,這樣在國內才能更好地落地。大概是這么一個想法。
王啟隆:我覺得是從單純的去復制成功到去研究他的思路的一個過程。
吳穹:對,相對來講是。就是所謂的馬斯克現在比較推崇的第一性原理。敏捷也是有第一性原理的,但它的第一性原理可能被包裝成了一個適合國外的實踐,當別人在國外做這個敏捷實踐時,就可以產生效果,因為它應用到了第一性原理。現在你把這個實踐完全搬回國內,就會發現它不適用,因為它跟周圍方方面面的東西不適配。所以你要回到敏捷的第一性原理,重新適配國內的情況,這樣的一套實踐在國內就更容易落地。
所以我們今年也出了一本新書叫《敏穩兼顧:數字化研發管理實戰》,專門講規模化敏捷怎么樣在國內落地。我們有一個方法論框架叫 Adapt,也就是把我們這些年的思考做了一個總結。
![]()
![]()
“不會有通用 Agent,最終還是會分化成專用 Agent”
王啟隆:時間延伸到現在,我們看到了 AI 帶來的巨大變革。很多企業高管也對這個新變革感到非常興奮。但一線的研發團隊,包括正在看視頻或讀文章的讀者,會覺得在實際應用中,AI 常常讓人感覺到幻覺很多,令人困惑和掙扎。您作為常年連接國內外高層戰略和一線實踐的顧問,認為當前企業管理者在推動 AI 賦能研發這件事上,最容易陷入的認知誤區是什么?
吳穹:應該是比爾·蓋茨說的,我們總是高估未來兩年的變化,低估未來十年的變革。所以我覺得現在我們就處于一個狂熱期,目前有點過分高估 AI 在這兩年能取得的變化。
我覺得現在最常見的誤區就是太著急,過分樂觀。All in 是沒錯的,方向上 AI 肯定會徹底改變軟件工程的生產方式,五年、十年來看,這肯定是確定的。
但短期之內,它的困難在哪里?我們看到現在 AI 比較強的是什么?如果你做一件任務,大模型壓縮的知識已經足夠了。你讓它在一個熟悉的領域,用它已經掌握的知識去做事,現在它的能力已經相對非常好了。
但軟件開發不是這樣。你讓 AI 在廣場上做任何事情,用的是公域知識。但實際上我們大多數的軟件開發項目都有很多私域知識。它是一個獨特的金融軟件,或者就算它是一個電商系統,但由于前面的人已經寫了五年、十年,雖然它在領域上是個電商,但你的實現方式其實也是私域知識。
所以,這個時候你讓 AI 純粹地去處理,你只是給它一堆代碼。就算現在上下文越來越長,它可以把所有代碼庫、所有文檔都讀進去。但很多時候,我們之前做這些事情的決策過程都在大腦里,沒有留存文檔,或者留存的文檔和代碼對不上。私域知識的質量是不好的,這時候你讓 AI 去處理這些信息,它可能就會遇到短板。
王啟隆:是的,就是常說的上下文工程,上下文不足。給它的私域數據不足。有時候你只是給它一個提示詞,但它需要的可能是一個客戶的聊天記錄,或者你整個工程的記錄,才能把事情做好。
吳穹:對,所以你會發現幾件事情。我自己從今年開始也在試用 Cursor,去一線體感,我要看看這個事情現在進展到什么程度。現在大家會發現,當然最近是日新月異,每天都在變,但至少到現在為止,代碼補全是一個非常高效的場景。為什么呢?因為在代碼補全的上下文下,你已經把要改什么、在哪改等上下文告訴它了。
“我要在這兒改”,這是一個非常重要的上下文。你敲幾行字之后,你的意圖也告訴了它。所以,它在這個非常精確的點上改東西的時候,效率就會高很多。所以大家會發現代碼補全很高效。但如果你不是用代碼補全,而是說“我想干一件事”,那你就得給它很多上下文。
對于一個老系統,很多時候問題不是技術債,而是缺乏歷史信息或歷史上下文。這時候你有兩個選擇,要不你就手寫了,要不你就把歷史信息補全,把那個債補上。但你補這個債的時候,會面臨不確定性:補全了就真的能快嗎?你不知道。或者說要補到什么程度?這個要試驗。所以很多時候大家就會說,那算了,我接著手寫吧。
當 AI 應用到我們私域時,不確定性會多很多。所以現在我們看到大多數團隊給我們的數據,比如 10%、16%、20%,都在體感誤差范圍內。你說我快了,我一定會說我比以前快了,但你說有多大效果嗎?不好說,大家覺得可能會有誤差。
所以我覺得長期來講,我相信 AI 一定會改變整個軟件工程的工藝、工具、組織,這些全都會變。但短期之內大家不能太著急。我看到今年有一些組織,在一些 AI 編碼的突破之后,從 CEO 開始就覺得要顛覆。那 CIO、CTO 只好說好,要顛覆。底下的同學就只好說,你們覺得要顛覆,那我就配合你們顛覆。
當然,這是每次技術浪潮都會有的。比如我們回頭看面向對象、CMMI、Java,每次都是這樣。這是一個我們叫技術成熟度曲線(Gartner Hype Cycle)的過程,好像也是一個不可避免的過程。但我們現在只能說,盡量讓大家冷靜一點。要積極擁抱,但在這個過程中,要意識到上下文的缺失是 AI 發揮作用的一個很重要的阻礙。所以我們現在看到 AI 表現比較好的都是純綠地項目,比如新建一個網站,新建一個原型,都沒有問題。
![]()
圖源:2025 年人工智能技術成熟度曲線 | Gartner官網
王啟隆:而對于已有舊項目的維護和修改……
吳穹:難度大很多。另外,現在大家都在談 Agent。你回頭想,任何一個工程生產線,都沒有人賣通用的工程生產線。真正最后軟件工程實現了,或者說更高度自動化了,它一定會有很多差異化的生產線。沒有人說這是一個萬用生產線,做任何機器——造車、造火車、造導彈——都可以用,因為這不 make sense,肯定是個浪費。
我明明要造車,為什么要用一個萬用生產線?你一定會把它調制成一個造車的生產線,像特斯拉一樣。里面有一定靈活度,可以造 A 類車,可以造 B 類車,但我不會用它來生產飛機,因為沒有道理,不經濟。
所以最后,我覺得 Agent 這個技術一定會越來越分化、越來越專業化。例如,未來會出現專攻特定行業的“金融 Agent”,或專攻特定任務的“測試 Agent”、“重構 Agent”。更進一步,我們甚至需要為這些 Agent 建立一套管理機制,比如如何注冊、如何考核 KPI、如何調解它們之間的任務沖突。
不僅僅是 Agent 會專業化,我們使用的開發語言也會進一步專業化。從模式上講,Vibe Coding 和 Spec Coding 都是一個抽象層次提升的過程。就像原來我們用匯編,后來用高級語言。下一步驟一定是自然語言編程,我可以用一個相對更靈活的自然語言,不需要關心那么多技術細節。
就像今天你寫 C++,不會去看匯編代碼。可能萬分之一的場景,你可能會去看一下匯編代碼,解決一個非常難的問題。但大多數時候你會忘記匯編那一層。所以可能五年、十年之后,也不排除三年之后,我們會說我用自然語言就可以了,不需要看生成的 JavaScript、Java,因為那一層JS、Java就成了新的匯編,我們不需要關心了。
實際上我們是面臨一次抽象層次的提升,抽象到自然語言。但到這個級別你會發現,還是會出現新的東西,我們叫 DSL(領域特定語言)。因為沒有道理一直用一個通用的自然語言。我一定會到某一個點發現,既然都在做 ERP,那為什么不發明一個專用于 ERP 的自然語言描述框架?所以從道理上講,它一定會進入一個熵減的模式,我不需要用一個純自然語言。
我會用一個更特定于這個領域的描述方式,配合特定領域的 Agent,來更精確、更準確地干好這件事。所以這一定會走向一個分化的過程:我們的描述會分化,我們的 Agent 也會分化,逐漸形成更專業化的生產線。我覺得這是大概率會發生的事情,只是這個過程大家要有耐心,不是一蹴而就的。在這個過程中如果過分著急,就會導致動作變形,會付出很多成本和時間。所以我覺得這是我們看到的誤區,大家有點過分著急。
王啟隆:我覺得吳博從邏輯上解釋了為什么不會有通用 Agent,最終在實際生產中還是會分化成不同的專用 Agent。甚至于我們最基本的聊天機器人(Chatbot),它可能也不是純自然語言,而是專門用于對話的、日常口語化的語言。這個觀點很精彩。
![]()
“要把 Agent 當成員工去管理”
王啟隆:您剛剛有提到您創立的愛捷軟件(Agilean),在 AI 時代之前,它是如何發揮在軟件工程上的作用的?AI 帶來的變革之后,它又是如何調整自身定位的?面對現在國內那么多客戶都想要智能化、AI 化轉型,您和您的團隊為他們解決的核心問題,和三五年前相比,發生了哪些根本變化?
吳穹:我們這一套 Adapt 的方法論,包括我們做的事情,可以總結為“人、事、流、數”四件事情。
![]()
“人”其實延伸到組織,就是用什么樣的組織形態最合理。我們一直都說,生產力會推動生產關系的變革,但生產關系決定了生產力能否有效發揮。所以我們一直在做的事情就是理順生產關系。原來很多是科層制的、職能化的組織。我們現在在幫助很多組織做敏捷轉型,建立這些面向交付的敏捷團隊。
我們最近舉的一個例子,跟國家的軍事改革很像,叫“兵種主建,戰區主戰”。因為現在大多數知識工作者都需要跨職能協作,單一職能是做不了事的。但我們很多管理會偏向于按職能管理,職能線管理是一個常見的管理結構。我們現在做的大多數事,就是在職能線上疊加交付型組織,也就是所謂的“戰區”,用這樣一套組織結構,讓它交付得更快、更好。這塊是我們這幾年在做的事情,就是建立組織。
![]()
建立組織之后,第二步就是“事”。要讓組織干活,就要明確它干什么。“事”可以認為是一個指令體系。最上層的組織收到客戶的一個要求,然后我要把它拆解成幾個指令發給不同的組織,有人要做交付,有人要做能力建設。
我希望有一個指令拆解的過程。這個指令拆解的過程就是我們說的“事”,我們把它叫任務體系。相當于我的組織體系建好后,要用任務體系把它落實。
有了任務體系之后,再下面就是“流”,有點像流程,或者我們現在更多地叫價值流。這件事分多少個狀態?每個狀態由誰負責?這就又回到了把事和人連起來,讓事去找人。這個事到了這個階段應該是誰負責,把這個工藝落實下來。有了“人、事、流”之后,我們就會產生很多“數”——有關人的數、有關事的數、有關流的數,我們可以更好地管理整個組織。這就是我們這么多年在干的事,即如何從這幾個角度優化,讓一個組織能夠更高效地運作。
![]()
AI 來了之后,我最近看到一個截圖,好像是阿里的 CTO 或 CIO 說的,他說要把 Agent 當人去管理。這也是我們一直以來的核心觀點:我們未來認為組織會是所謂的 1+N 的組織,即由“1 位人類小隊長”帶領“N 個 AI 特工”協同工作。
因為馬上大家要解決一個問題:今年大概是大家對 AI 最狂熱的一年,明年懷疑就開始出來了。我們投了很多錢,也做了很多事,為什么沒取得效果?因為讓組織使用先進生產力這件事從來就不容易。有一個核心問題大家都在回避:員工為什么要用這個生產力?這個員工我真的用 AI 提升了 50%,那他是多干一倍的活呢?
還是把這個時間用于摸魚?你怎么激勵他把 AI 省下的時間真正用于做更多的事?這是一個生產關系問題,不是生產力問題。AI 有沒有這個生產力是現在大家關心的問題。但實際上這個觀察忘了一個點:就算它有這個能力,你的員工是會把這個能力給公司做貢獻,還是用來早點下班?
你會注意到 AI 工具宣傳中的一個悖論:它既被包裝成給老板的“提效神器”,又被宣傳為給員工的“摸魚神器”。但這兩者本質上是矛盾的,如果它對員工真是摸魚神器,那在老板那兒就不可能是提效神器。
王啟隆:經常有這樣的廣告。
吳穹:但這其實是矛盾的。如果這個東西對員工是摸魚神器,在老板那兒它就不會是提效神器。如果對老板是提效神器,它就不會是摸魚神器。所以現在大家只是在宣傳上決定誰買單,你買單我就跟你說這個,他買單我就跟他說那個。但實際上……
王啟隆:這個矛盾一直存在。
吳穹:這是一個非常深刻的變化:怎么讓組織擁抱 AI?這件事情不容易,不是說你給了工具他就會用。
任何事情我們會有 1% 的嘗鮮者、10% 的早期采納者,他們愿意用 AI,但很多人屬于那種“行吧、可以、還好了”的態度。所以讓組織擁抱 AI 是一個系統工程,很不容易。
所以我們最近的一個想法是,未來要把 Agent 當成員工。當 Agent 成為員工之后,這個 1+N 里的“1”,任何一個人都是一個小隊長或班長。那組織就要看這個班的效能。比如說未來一個人能帶 5 個 Agent,那個人說他能帶 50 個。公司覺得誰的效能更好?那肯定是帶 50 個的效能更好。當然,這是建立在假設 Agent 的產量是一致的。
所以未來的考核體系、組織結構都會發生變化,來適應一個新的模式。原來我們是以人為工作中心的,未來可能是以 Agent 為工作中心。人的角色變成了帶領 Agent 去工作。你的效能就不是你產出了多少,而是你帶領了多少 Agent 產出了多少。這樣的一套組織體系會更有利于發揮 AI 的價值。我們覺得未來整個方法論也會演進,這是一個非常重要的演進:我們怎么讓組織在 AI 來臨之后還能高效運作?這個地方會有非常多的創新需要做。
王啟隆:您剛剛提到假設 Agent 的效能一致,這是基于什么樣的假設?因為目前我們看到,AI 的表現依舊取決于我們給的上下文和提示詞。可能有的人用 AI 比較厲害,他可以讓一個 Agent 發揮出十個的效能。
吳穹:未來我們覺得整體的趨勢是,短期之內最關鍵的不是讓 AI 在一件通用任務上打 90 分,而是讓它在一件簡單的事情上打 99 分。在任務標準化、模型與提示詞均被鎖定的前提下,從統計上說,這些 Agent 的效能就相當于基本一致了。
為什么?因為通用的 90 分,總有 10% 的尾巴要人來收。這個收尾成本非常高,就像在軟件工程的軟件復用領域有一個原則:如果你復用時需要改 10% 的代碼,成本基本上就跟重寫差不多。
別覺得 AI 幫你干了 90% 你就賺了,修正那 10% 可能讓你白忙一場。更別說只幫你干 50% 了,那很可能反而是生產力陷阱。
所以,下一步的重點就是讓 AI 找到那些它能干到 99% 甚至 100% 的任務,讓更多的小任務可以全自動完成。
那人做什么呢?就是進入“planning mode”:先把任務拆出來,確認每個小任務是對的,再分給其他的小 Agent 去做。然后,這些小 Agent 就可以日夜不停地把這些事做完。
這時候體現的就是你這個人的本事,因為你分任務分得好。人跟人的差距就出來了:
分得好的人,可以拆出很多小任務讓 AI 自動執行,利用自己的睡覺時間,更高并發地完成事情。
如果分得不好,AI 做完了你還要改,最后你還是在干很多 review 的事情。
這就是為什么我們認為,未來更傾向于人類帶領很多小 Agent 去工作。那時候,你的績效,就是看你帶的那些 Agent 干得好不好。
![]()
“AI 最重要的就是準確的數據,先把語言拉齊”
王啟隆:我們再延伸聊一聊 AI 時代的 Agilean。您沉淀多年的 Adapt 方法論,其中一個核心理念是在談效率和改進之前,先統一組織的管理信息架構,也就是把大家對需求、任務這些概念的理解先拉齊。在今天這個追求快的時代,為什么這種聽起來有點慢的、先統一語言的工作反而變得更加重要了?
吳穹:因為現在大家都知道,AI 最重要的是數據,是準確的數據。我們現在在很多組織的大多數問題是,如果真正要做到智能化的軟件開發,數據缺乏是非常嚴重的。
在很多組織里面,一個最基本的問題就是:到底什么是需求?什么是項目?我說的需求和你說的項目是不是一個東西?很多組織把任何一個需求都叫項目。在很多組織里,語言非常貧乏,所以什么都叫項目。然后就是 A 類項目、B 類項目、C 類項目,還有的組織叫“需求類項目”、“項目類需求”,各種奇奇怪怪的排列組合。
因為大家沒有經過這個過程。我們在給別人做系統時,可能還做一點架構設計,做一點領域驅動設計(DDD)。但在我們自己的 IT 管理系統里,基本上大家都不做領域驅動設計。這樣,你的概念就是混亂的,數據一定是混亂的,這時候 AI 就無從學習,無從智慧。所以反而要回到第一步:當你真正要開始重新構建一個線上化、數字化的研發管理系統時,反而需要把最基本的概念模型搞清楚。這就是我們說的管理信息架構。
![]()
王啟隆:像 Adapt 框架,除了我們熟悉的研發角色,還擴展到 PMO、財務這樣的角色。為什么一場成功的數字化轉型,必須把這些看似外圍的職能部門也深度卷入進來?他們能帶來哪些研發部門自身不具備的關鍵價值?
吳穹:是這樣,我們認為未來所有組織都會是科技型組織,這個趨勢已經越來越明顯。未來如果一個組織沒有科技能力,很難想象它有競爭力。任何一個組織都是業務和科技的深度融合,科技能力都會成為每個組織必不可少的 DNA,同時也會成為一個巨大的成本中心。對組織來講,科技的成本會成為一個非常大的部分。
這時候我們都會面臨投資決策:我要做什么,不做什么?做了這個東西到底有什么收益?所以研發過程,就不僅僅是開發測試這個過程。從規劃到立項,到中間不斷調整投資決策,再到事后復盤,整個組織管理都要跟科技體系打通。我可以從 CFO 的視角看研發,可以從人力資源的角度看研發。這不僅僅是科技團隊自己的管理問題,而是科技和周邊的整個公司治理都需要打通。
這也是我們在 Adapt 里試圖解決的問題。當然這個比較復雜,還在探索的路上。但我們覺得科技團隊不能孤立地談自己的管理問題,因為最后所有的管理都還是為整個公司治理服務的。
你只要把這條線打通,最后才能有效地管好開發團隊。否則,開發團隊也會受到公司其他部門的挑戰和制約。
![]()
既不是定制開發,也不是盒裝軟件
王啟隆:我們剛剛聊了 Adapt 方法論。順著這個話題,聊一聊具體的工具。您有了 Adapt 這套管理思想之后,您的團隊打造了“知微”這個工具平臺。您曾將它比作一個科技組織的“財務系統”,那它具體是如何將您在 Adapt 方法論中的那些理念,比如分層的需求體系、多維的組織架構,變成一個管理者看得懂、用得上的數字化工具的?
吳穹:剛才我們聊了很多,已經充分體會到每個組織的差異性非常大。我們談了組織結構,可以看到每個組織在每個階段的組織結構都有它的道理。你很難說這就是最好的。每個組織在不同規模、不同階段,都會采用不同的組織結構,所以我們認為組織是柔性的。
其實在大公司都待過的人知道,組織重組(re-org)是每年都會發生的。這并非是簡單地否定過去、肯定現在,而是為了適應當前階段的需要。今年的架構適用于今年的挑戰,明年則可能需要另一套方案。
所以我們認為組織應該是柔性的。這種柔性也體現在企業的“管理信息架構”上,它往往是歷史路徑依賴的結果。比如,同一個概念,在這家公司叫“需求”,在那家叫“產品需求”,在另一家又可能叫“業務需求”。哪個最合理?其實沒有定論,只要內部統一、溝通成本最低,它就是有效的。因此,每個公司的管理信息架構不僅各不相同,而且是動態變化的——今天加一層,明天減一層。流程和角色同樣如此。
我們在咨詢中發現,盡管管理原理相通,但具體到每個組織的“人、事、流、數”(人員、事務、流程、數據)時,卻千差萬別。這就導致了大多數標準化盒裝軟件無法滿足企業的實際需要。客戶買來軟件后,往往會發現這里不匹配、那里不適用,最后只能削足適履,因為軟件本身是固化的。
現在業界基本上就兩種實踐。一種是我找一幫人來定制開發,嚴格按照我的想法來做。這種實踐,我們也看到它大概率的最后結果。因為廠商沒有任何管理經驗,你說什么我就干什么,你說的不對我也照著做,因為我也不知道對不對。所以很多這種定制開發型的管理系統,可能一開始用的時候大家就會覺得不好用,就不斷亂改,改到三五年改不動了就推倒重來。這是一種情況。
另外一種就是買盒裝軟件。雖然不適合我的需求,但我對付著用。但這樣很多時候落地效果也不好。
所以我們做知微的理想,就是把它打造成一個可配置的零代碼平臺。它就像一件‘高級定制’的西裝,既有成熟的方法論支撐,又能真正根據你的情況量體裁衣,而不是生硬的定制開發或僵化的盒裝軟件。簡單來說,知微是一款能深度嵌入客戶現有流程、可靈活配置的柔性研發管理平臺。
![]()
“AI 加速技術債?用好了,技術債反而會減少”
王啟隆:知微是根據已知情況去解決問題。那面對未知問題呢?比如今年行業熱議的新詞“AI 加速的技術債”。以前就有技術債的問題,但 AI 在提升效率的同時,也用更快的速度制造了更多隱形風險。知微這樣的平臺,能不能幫助管理者看穿這些 AI 帶來的表面效率提升,提前發現這些新型的管理風險?
吳穹:沒有 AI,你的技術債也在累積。只不過有了 AI,如果管理不好,它累積的速度會更快。
其實還是用傳統的度量體系,我們可以從交付效率、交付速度、缺陷修復時間、上線修復時間、代碼重復度等各種各樣的方面,去感知質量情況。AI 來了之后,你只是要去更加小心,因為它產出代碼的速度更快了。如果你過分強調某個指標,因為原來還是手寫代碼,這個惡化的速度是有限的。如果你過分強調效率或者代碼行數等指標,那他用 AI 生產低質代碼時,技術債的累積會更快。
這是一個我們需要小心的副作用。但這并非是 AI 自身的問題,而是我們如何引導和協作的問題。事實上,如果使用得當,AI 反而能幫助我們減少技術債。
王啟隆:有沒有什么 AI 時代誕生的新問題?
吳穹:我們現在看到的 AI 時代的新問題,通過觀察,更多是由于領導過分激進的績效目標,導致大家熱議“氛圍編程”(Vibe Coding)。你會看到業界有幾種觀點,其實都對。有人說,作為一個程序員,如果你抵抗氛圍編程,早晚會被淘汰。這個是對的,但是要放在五年、十年的范圍來看。一個程序員肯定要不斷去嘗試,我跟 AI 協作的邊界在哪里?AI 一定可以幫我提效,同時它不能增加我的質量問題,它應該幫我減少技術債。
前一段時間我嘗試用 AI 編碼時,發現現在 AI 做單元測試的能力已經非常強,所以你可以讓它幫你生成很多單元測試代碼。因為開發人員原來就不愿意寫單測,這確實像健身一樣,是一件正確但不容易堅持的事情,是一個額外的成本。
現在你讓 AI 幫你寫單測,對 AI 來講是個自閉環。你寫完的代碼,你自己寫的單測都跑不過,這個事交代不過去。所以對 AI 來講,這是一個初步的自閉環。一旦 AI 把這個跑過了,我前一段時間自己寫代碼的時候,它的單測我是不看的。只有當它繞進去了,繞了幾個循環都繞不出來,我可能會看一看,為什么你自己寫的代碼,自己寫的單測過不了?
大多數時候,現在單測是可以自閉環的。它的作用是什么呢?這些非常高效的單測,變成了一些我們在工業生產里叫“夾具”的東西。比如你這個東西要這么高,每次生產完我拿夾具一測,它就一定是這么高。下次你這個零件如果高了,那個夾具就測不過去。那我們會發現什么?如果它改到了不該改的代碼,我一看這個單測怎么會報錯呢?這個單測不應該報錯。我都不管你改得對不對,首先你就不應該改到這個代碼。這就像我在代碼庫里布了很多鈴鐺一樣,只要哪個地方被改到了,它的鈴鐺一響,我就會判斷:不應該改到這兒。
那我就知道一定出了問題。所以,和 AI 的有效協作其實可以幫我們減少技術債。而且 AI 的算法能力、具體的代碼編寫能力其實還是不錯的,肯定比我們中游或初級程序員寫得好。所以用好了 AI,技術債反而會減少,按理說是這樣。
王啟隆:那大公司也用 Vibe Coding 嗎?目前 Vibe Coding 還是在很多個人開發者那里,可能是玩票性質的。比如用 Vibe Coding 寫個原型(Prototype),但實際代碼還是自己編。那大公司,我們剛才也談到,他們有很多龐大的、需要維護的老項目。這種情況下,對您服務的這些大企業、大公司來說,氛圍編程的作用大嗎?
吳穹:我們嘗試定義一下什么是氛圍編程。因為大家對這個定義都不一樣。我的定義是,它實際上是一個抽象層級的提升。讓我忘記 Java、JavaScript,在一個更高的抽象層面上,我只要給它指令,說我想要一個什么,我想在這個地方加一個什么,我可以不關心細節。
所以回到我們一開始談的話題,當我在一個綠地項目里,相對容易做這個事情。我最近的實驗就是綠地項目。
但一旦你生成了代碼,當你在改第二個動作時,它其實就不是綠地項目了。只不過它是一個技術債稍微小一點,上下文丟失稍微小一點的項目。但實際上我最近在做實驗的時候發現,為了真正保持這種氛圍編程,你的開發模式就會出現變化。不是像以前大家習慣的,我把代碼寫出來就好了,其實不是的。
所以,我們可以將“氛圍編程”理解為兩個層次。
在原型探索或概念驗證階段,它可以是純粹的自然語言“動嘴”編程,讓我們忘記底層代碼細節,快速實現想法。
但要將其應用于真正可持續交付的嚴肅項目中,就必須進入第二階段,即“動嘴+動手+動測試”的模式。你必須在生成代碼的同時,產出完整的文檔、設計決策和測試用例,以確保上下文的完整性,避免后續的維護災難。
因為現在很多大家展示的例子都是一下子就完成一件事,只有第一步,到了第二步的效果就會打折扣。所以到底怎么做這件事,在大公司里我覺得會更難,會面臨前面說的上下文缺失問題。如果你真的把抽象層次完全提高到不看代碼,我覺得會更有難度。
![]()
“知微會逐漸中臺化,大模型也是它的用戶”
王啟隆:我們把話題回到知微這個工具。在 AI 和 AI Agent 越來越普及的趨勢下,知微這樣的管理工具最終的形態會是什么樣?它會成為人類管理者指揮“1+N”模式的核心入口嗎?
吳穹:我們覺得知微這種工具未來會逐漸中臺化。未來我們已經在做 API 的能力。
首先,我們一直認為 IDE 會是一個主入口。現在我們會發現,像 IDE、CLI 這種開發人員常用的方式會成為主流,未來界面會越來越少。因為界面嚴格來講是當我們需要精確控制時才去做的事情,它需要人做很多具體的選擇。
當 AI 能力提升,它不光改善我們的編程,也會改善我們的工具使用。很多時候我不需要自己再去選很多東西,它可以根據我的工作上下文知道我剛才干了什么,然后來幫我做很多事情。
所以未來像知微這種工具,大模型也是它的用戶。大模型可以直接調用它去更新一些信息。包括 Agent,未來人可以通過大模型用它,Agent 可能就直接用 API 接口來應用它。它會更多地變成一個數據管理的后臺。這些后臺數據累積進去之后,又會變成大模型的一些輸入,大模型可以用它來做預警、預測、推薦。
所以未來它會更像一個組織的“流程資產中心”。這個組織整個加工的過程都在里面記錄下來。未來我可以問它,我之前有沒有做過類似的需求?之前類似的需求是誰做的?
做了多久?類似這些信息你都可以從它里面拿到結果。所以界面還會有,偶爾你還是會看一下,但更多場景你是通過大模型、通過 IDE 去跟它打交道,它來做數據的累計。
王啟隆:很多像您一樣經驗豐富的技術專家都提到,AI 的出現重新點燃了他們對技術的熱情。我記得 2023 年 ChatGPT 剛出來的時候,《敏捷宣言》的發起人 Kent Beck 好像說過一句很經典的話,叫 AI 取代了我 90% 的技能,然后放大了剩下的 10%。在行業深耕近 30 年后,當前 AI 浪潮中最讓您個人感到興奮或出乎意料的一點是什么?它是否改變了您對軟件工程這門手藝的原有看法?
吳穹:這次 AI 的變革,說大一點,可以認為它顛覆了原來的馮·諾依曼架構。原來我們是 CPU,后來是 GPU。GPU 也是一種相對確定性的計算。
那么 LLM(大語言模型)來了,我們可以將它理解為一種全新的“概率引擎”。和傳統 CPU 的確定性計算(確定的輸入一定產生確定的輸出)不同,LLM 在收到指令和上下文后,會給出一個基于概率的、最合理的結果。正是這種從唯一正確到合理可能的特性, 極大地拓展了我們軟件的能力邊界。
這個變化會引起兩方面的變革:我們以前所有的軟件形態都被顛覆了。因為原來所有的軟件形態都是基于確定性輸入、產生確定性輸出的場景。但很多時候,比如我讓你給我寫一個旅游攻略,我需要確定性輸出嗎?不是這樣的。
王啟隆:可以是圖文的、純文字的,甚至是視頻的。
吳穹:你想,我找五個旅行規劃師,他們會給我五個不一樣的攻略,我還希望它們不一樣。如果五個人給我五個一樣的攻略,我反而覺得不對了。所以在很多時候,人類要的東西是不確定的。
那原來是怎么解決的呢?原來是一個人找了一個顧問,顧問利用工具收集了很多確定性的信息,然后由他把不確定性的結果提供給你,這里面有一個人工的過程。現在大模型把中間的人去掉了,它代替了你的旅行顧問,用 API 收集確定性的信息,然后根據它的偏好和知識,給了你一個每次不一樣的旅行攻略。這時候你覺得挺好,因為大差不差就行,只是個參考。
所以可以認為,原來我們的邊界在這兒,我們的軟件是在服務那個旅行顧問。現在我們往前推了,有了大模型之后,我們的軟件直接服務用戶了。用戶給我一個模糊的輸入,我可以給他一個模糊的輸出。所以軟件的邊界和形態已經發生變化。
想象一下整個軟件開發過程。當我們的加工目標變了,生產工藝也一定會變。
舉個例子,原來我測試一個網站,就是看搜機票能不能搜出來,搜火車票能不能搜出來。現在怎么測?一個大模型給了一份攻略,我怎么測這份攻略是不是滿足要求?
你可以想象,軟件的邊界發生了巨大變化:它從一個確定性的軟件,變成了一個能給出不確定結果的軟件。
因此,我們的測試過程、整個質量過程都變了。類似的事情,其實在推薦算法出現時就已經變得有些不確定,但大模型是把這件事推得更遠了。因為推薦算法在軟件行業的應用范圍還比較少,但大模型來了之后,應用范圍會廣得多。
所以我們覺得,整個行業我們做的事情、做事的方法,全都會被顛覆。這就是你說的那個興奮的點。因為每一次這種巨大變革,都意味著巨大的挑戰和機會。我們之所以興奮,就是因為這對程序員來講又是一個黃金時代——所有的東西都會被推倒重來,亂世出英雄。
![]()
對年輕工程師的建議:“1+N”模式下的新能力
王啟隆:回到之前聊到的,您說未來可能是一個專家帶多個 AI Agent 的“1+N”模式。如果這是未來趨勢,那它對今天成千上萬的年輕工程師的職業發展意味著什么?企業又該如何調整自己的人才培養體系?包括您的團隊顧問,以前要懂管理、懂敏捷,那現在是不是要更懂 AI?新時代的人需要掌握什么樣的新能力?
吳穹:關于“1+N”模式對人才的影響,我們最近的觀點有了一些變化。
之前我們判斷,未來組織會有點像“鉆石型”,即少數資深員工帶著很多 Agent,初級成員會越來越少。但現在我們覺得未必,因為之前沒太考慮成本因素。如果考慮到成本,一個被 AI 武裝的年輕人,會快速追平中層程序員的能力。最近我聽到很多 CTO 講,原來培訓一個人需要 6 到 12 個月,現在一個熱愛學習的年輕人,在 AI 的幫助下可能三個月就很成熟了,而且他們更愿意主動擁抱新時代的生產力。
所以,未來一個非常重要的能力,就是對 AI 的了解和溝通協同能力。
你要把 AI 在某種程度上當成一個人,學會怎么跟它有效溝通,而不是說一句話它不懂,你就懶得理它了。你反而要不斷去想:它為什么會迷茫?為什么聽不懂我的話?我怎么能跟它協同得更好?這對人的溝通能力、同理心和對 AI 的理解都提出了更高的要求。
因為 AI 不會主動告訴你它的局限,它只會給一個答案。所以當它做得不對時,你要能反思:我是不是少說了什么?或者有什么上下文是它看不到的?這樣你才知道怎么給它更好的提示詞。
這對年輕程序員來講,反而是一個紅利。一方面,他們可以更快地在組織內趕上來;另一方面,AI 對“一人公司”也更友好了,因為整個公司的結構都會受到 AI 的挑戰。
未來,人與人之間的生產率差異會變得更大。我們原來常說,優秀的軟件工程師是普通人的十倍,未來可能就是百倍的差距。這時傳統的雇傭關系就面臨一個問題:就算這個人有 100 倍的能力,你愿意給他 100 倍的錢嗎?大多數組織是做不到的。
但如果你自己變成一家公司,這事就容易了。作為百倍效率的工程師,你可以把成本壓得很低,按單計價。大公司可能會發現,把工作外包給你比自己養人還便宜。
這背后挑戰的是“公司的最佳組織形式”。按照科斯原理,公司的存在是因為交易成本。以前把事外包給你,簽合同、定價都很復雜,成本高。但未來 AI 來了,公司之間的交易成本可能會大幅下降,這就會促使更多工作被外包給高產能的個人或小團隊。原來大公司的結構可能也會因此發生變化。
所以,在這個新時代,無論是新程序員、老程序員還是管理者,你都必須去擁抱 AI。因為它絕對是一個現象級的大事件,是一次會顛覆我們整個行業和社會的巨大變革。
![]()
敏捷已死?不,AI 時代更需回歸其本源
王啟隆:談到公司的本質需要重新思考,公司的結構會產生變化,那這對我們上個時代經常聊的“敏捷”會不會也帶來影響?這種科技與業務部門協作關系的改變,會不會最終實現您多年倡導的兩者真正無縫融合的“業務敏捷”?還是說,會像某些業界大佬說的那樣,敏捷已死?
吳穹:我們先回到第一性原理:什么是敏捷?敏捷最開始呼喚的是按照符合軟件本質的管理方式去管理軟件,它其實是一次回歸。它反抗的是按照工業化的、確定性的方式(就像管建筑一樣)去管軟件。它最開始的本源是說:你不能那么管我,因為我和蓋樓不一樣。
王啟隆:之前我,我記得這個故事最開始其實是程序員和產品經理的“戰爭”。
吳穹:或者和項目經理。所以它嚴格來講是一個對合理管理的呼喊,問題在于,后來敏捷這件事被異化了,很多組織把它搞得形式化、玄學化。所以不是敏捷已死,而是“這個經被念歪了”。
回到敏捷組織的本質——它就是一個面向業務、快速交付、靈活調整的組織。在 AI 時代,你更需要這樣的組織。
我們最近就在思考,AI 時代可能都不能再按照傳統的職能去劃分部門了。傳統時代,職能是強組織架構,交付反而是弱組織架構,我們希望“兵種主建,戰區主戰”。這套邏輯在穩定時代是可行的,但現在,連“兵種”本身都在變。
舉個例子,過去我們有前端開發部和后端開發部。前端覺得后端不懂自己的專業,后端也覺得前端不專業,互相之間存在“鄙視鏈”。在這種結構下,當 CTO 想推行“全棧”時,就會遇到巨大的組織阻力。
所以在 AI 時代,我們反而可能要按照“交付線”去組織——我不管你們是什么職能,你們的目標就是把業務給我干好。當然,組織也需要穩定性,可以按系統來維持。但核心是要弱化職能,因為在這個時代,職能的邊界正在快速消失。如果我們過度強化它,反而會減慢組織擁抱新事物的速度。
這正是我們想強調的:AI 時代來了,你的組織、角色、流程、制度,所有這些東西,都需要去做適配性的變革。
![]()
“我懂但可以不關心,和你壓根不懂,是兩碼事”
王啟隆:我們剛剛談到敏捷的回歸。從更宏觀的視角看,您認為 AI 正在如何重塑軟件工程這門手藝本身?是讓它更趨近于一門可以被精確計算的科學,還是在解放了重復勞動后,讓它回歸藝術性的、更有創造力的本源?
吳穹:從道理上講,為什么現在 AI 能提效?因為我們在軟件開發過程中已經開始重復了。原來我們是 Don't Repeat Yourself (DRY),現在大家開始 Repeat Myself,做的很多東西其實是 CRUD,開始重復。所以從道理上講,引入 AI 之后,確實能夠解放我們的重復勞動。每一次抽象層次的提升,都讓我們更加不關注細節,更加宏觀。
所以在產品經理和程序員的戰爭中,雖然現在大家都比較看好產品經理,但我持不同觀點。
我看好有企業家精神或產品思維的高級程序員或架構師。
為什么呢?這有點像老生常談,是文科生學理容易,還是理科生學文容易?在相當長的一段時間里,我可以不關心那些技術細節,但在需要的時候,我有能力去關心。
因為 AI 把我的注意力解放出來了,所以我可以多關心業務、產品和用戶。但在 1% 的場景下,我可以去幫 AI 搞定那個代碼。但如果我是個產品經理,你就不具備深入底層的能力。很多時候,我能夠不關心那些細節,原因在于我懂那些細節。我懂,但是可以不關心,和你壓根不懂,那是兩碼事。
因為我怎么寫提示詞、怎么給上下文,都取決于我知道“干活的那個人”需要什么。如果你不知道,你大概率只能說第一句話:“給我弄個網站”。等它出來了,你再說第二句話,想在這個網站上改什么,你就掛了。
我反而覺得,純粹的產品經理角色在未來會面臨更大的挑戰。 因為有能力的程序員,在被 AI Agent 解放了大量編碼工作后,是能夠向上兼容去做產品經理的事的。但反過來,如果完全不懂技術細節,很多時候就難以做出最精準的判斷。 我懂,但是可以不關心,和你壓根不懂,那是兩碼事。
你看業界的實際案例,馬斯克、扎克伯格、比爾·蓋茨都是有編程能力的程序員,他們最終成為了頂尖的產品締造者。 這說明,具備技術底色,對于理解和創造產品有著根本性的優勢。
他們做成了產品經理。真正只懂產品、不懂技術細節的,我覺得還是很難成功。因為很多時候你不了解背后的具體原理,就很難做成一件事。
王啟隆:對于這些渴望在 AI 時代有所作為的程序員,您有哪些建議?
吳穹:對程序員來說,一定要放下對 AI 的戒備和抵制。因為它從某種程度上影響了程序員的身份認同:我就是寫程序的,結果你把我寫程序的事干了。但你要這么想,原來你是種地的,現在你變地主了,你應該很高興才對。拖拉機來了,你是恨拖拉機搶了你種地的事,還是應該用拖拉機變成一個農場主?所以這是一個心理角色的轉換,我覺得這是第一點。
我現在看到很多程序員還是會嗤之以鼻,覺得“這也不可能”。那我覺得你就會死得很慘。因為趨勢肯定是他能做到,只是一個過程,在這個過程中你要學會怎么跟它共舞。
所以這是一個心理角色的轉換,我覺得這是第一點。而正是這種看似“危險”的身份顛覆,恰恰開啟了前所未有的機遇。我們之所以興奮,就是因為這對程序員來講又是一個黃金時代——所有的東西都會被推倒重來,亂世出英雄。
第二,在這個時代,因為你要跟 AI 協作,你就要跟 AI 溝通。原來程序員的工作,是跟機器溝通就夠了,不用跟人溝通。跟機器溝通的技巧會掩蓋跟人溝通能力的不足。大家都知道程序員很難溝通,但以后你沒這個借口了。所以與人溝通、與團隊協作的能力,是未來非常重要的一個技能,需要補強。
第三是對業務的理解。我覺得這是一個非常好的時代。程序員不要因為 AI 搶了你的編程工作而悲傷,而應該認為你現在可以擁有一個程序員大軍,而且你又掌握了跟他們合作的密碼,你可以干更大的事,應該為此歡欣鼓舞。
程序員現在創業比以前更容易了。所以要保持市場的敏感度、熱情和觀察。因為所有的軟件都會被重構,你可以想象這是一個什么級別的商機。而且我們又是全球少數掌握這種技能的人。所以,擁抱和享受這個時代,這是我對程序員的建議。
![]()
終極圖景:我們將迎來“黑燈的軟件工廠”
王啟隆:在軟件工程領域深耕三十余載,您最希望留下的思想和成就是什么?
吳穹:我們一直以來面臨的是一個獨特的科技組織管理問題,這也是我一直在研究的領域。所以我希望能夠留下的是,關于科技組織到底怎么有效管理的答案。這是我一直研究的領域,也希望能夠在這方面有所建樹。
像德魯克,他研究過科技組織的管理,但他畢竟年代比較早,自己經歷的科技組織比較少,所以他更多是從理論上覺得科技組織要這么管,但缺少實操。我覺得我們的好處是,這些年我們一直跟科技組織在一起,又比較了解中國的現狀。所以我們希望能夠為中國打造一套適合我們的科技組織管理方法論。
同時現在 AI 來了,又要加一個新因素,就是適合 AI 時代下科技組織的管理方法論。因為原來我們是管理人,現在我們要管理人和 Agent。Agent 對我們來講也是一個管理對象,所以整個管理方法論也會出現巨大變化。
王啟隆:最后一個輕松點的問題。我們今天聊了很多 3 到 5 年或是 5 到 10 年的變革。那么再往后,更遙遠的未來,如果用一句話來描繪您心中 AI 軟件工程的終極圖景,會是一個什么樣的、可能會比較科幻的畫面呢?
吳穹:現在大家也都在試圖探索軟件的未來。前幾天我看到有同學寫了一個“未來軟件是用后即棄”的觀點。但我覺得有挑戰,因為軟件很重要的一個使命是產生數據。如果你是個計算型的 function,可以是用后即棄的。但如果你產生了數據,你的目標就不是用后即棄了,你要持續存在。
但整體來講,大家一直在討論程序員到底會不會失業的問題。大家一直在思考,未來 AI 來了,是不是就自動編碼了,程序員這個職業就消失了?大家經常會拿翻譯和程序員來做比喻。但我一直覺得這個判斷是有問題的。
軟件不會被用后即棄,因為它是管理數據的,它會有很長的生命周期。當軟件一旦存在長生命周期,就會不可避免地形成很多領域知識。一旦形成了這些領域知識,就會有人知道怎么在這個領域里更有效地工作。我們想象一下,現在工業自動化已經做了這么長時間,我們確實有很多黑燈工廠,但我們的制造業都消失了嗎?沒有。我們的制造業在研究什么?怎么建生產線、調試生產線、布置生產線,怎么樣讓生產線效率更高。
所以不用太擔心這個問題。我們面臨的未來,實際上是一些“黑燈的軟件工廠”。可能不是用人去寫代碼,而是用 Agent 寫代碼、寫文檔、做測試。但人在此基礎上,去指揮、規劃,產生更多價值。再看一個例子,半導體(Semiconductor)。這也是個高度自動化的生產,現在還有沒有人自己去焊二極管?這個工作已經被完全自動化了。
但是我們整個半導體行業沒有未來嗎?人家賺得盆滿缽滿,最有未來了。所以我覺得,我們沒法預測,就像半導體行業預測不到今天他們搭了個臺子,AI 涌現出來了。我們也預測不到當軟件生產效率十倍、百倍提升之后我們會做什么。
這就像晶體管給我們帶來了計算機,計算機帶來了軟件,軟件帶來了 AI。那軟件生產力的極大提升會給我們帶來什么?是不是星際旅行?是不是可控核聚變?是不是智能醫藥?有可能。我們原來因為軟件供給不足,導致很多事情被 hold 住了。
你現在看不到所有的需求,是因為那些問題你還解決不了。但當你的軟件成本下降到一定程度之后,就像人工智能算法,40 年沒有變化,只是在 40 年后有了足夠多的算力砸進去,這個算法就 OK 了。軟件會不會也是這樣?當我們有了足夠的產能之后,就會去解決一些原來根本覺得解決不了的問題,從而產生新的需求。
所以我認為把軟件行業和翻譯行業對比是不科學的。軟件這個行業它是存續的,會有獨特的領域知識。而翻譯,雖然在法律、文學等專業領域同樣存在很高的壁壘,但在絕大多數通用場景下,處理的仍是公域知識。而軟件,尤其是企業級軟件,幾乎天生就是私域知識的集合體,生命周期很長,這構成了本質區別。
但大多數翻譯也是公域知識。而軟件是一個長生命周期的東西,我個人更看重它會像制造業、像半導體行業一樣。我們現在處于一個產能飛躍的前期,不用太擔心產能飛躍之后就沒有需求了。可能因為我們還有很多更高階的問題等待解決,當你有了大量的軟件生產能力之后,就有可能產生更多的需求。我更偏向這種樂觀的看法。
王啟隆:您這其實是相當于解釋了 AI for Science 為什么現在如此值得期待。因為它的進展可能是涌現出來的,不可預測的。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.