16個月估值破10億美元！眾多VC押注一個新品類，AI寫代碼越快，這個問題越致命

你有沒有發現一個悖論？AI讓我們寫代碼的速度提高了10倍，但半夜被叫醒修bug的次數似乎也在增加。兩年前，幾乎沒人用AI寫代碼。一年前，GitHub Copilot讓AI輔助編程成為標配�，F在，幾乎每個開發者都在用AI agent幫忙寫代碼。代碼產出速度飛快，新功能上線越來越頻繁。聽起來很美好對不對？但這里有個被忽視的問題：當AI生成的代碼越來越多，這些代碼部署到生產環境后，誰來保證它們能穩定運行？誰來在凌晨三點系統崩潰時找出問題并修復？更關鍵的是，當代碼量呈指數級增長，而工程師對這些AI生成的代碼并不完全熟悉時，維護生產環境的難度也在呈指數級上升。

這個矛盾正是Resolve AI要解決的核心問題。這家成立僅16個月的公司剛剛完成了1.25億美元的A輪融資，估值達到10億美元。由Lightspeed Venture Partners領投，Greylock Partners、Unusual Ventures、Artisanal Ventures和A*等早期投資者全部超額跟投。更值得關注的是，他們已經拿下了Coinbase、DoorDash、MongoDB、Salesforce、Zscaler等重量級客戶。這些公司每分鐘的停機都意味著巨額損失，而Resolve AI幫助Coinbase將關鍵事故的調查時間減少了72%，幫助Zscaler將每次事故所需的工程師數量減少了30%。這不是小打小鬧的優化，而是生產環境運維方式的根本性改變。我認為，他們正在定義一個全新的品類：AI for prod，也就是用AI來運行和維護生產環境中的軟件。

AI代碼革命帶來的意外后果

讓我先談談這個行業正在發生的變化。過去一年里，AI編程工具的進步速度超出了所有人的預期。從GitHub Copilot到Cursor，再到Claude Code，這些工具讓開發者能夠用自然語言描述需求，然后AI就能生成相應的代碼。這種效率提升是革命性的。一個開發者現在可以完成以前需要一個小團隊才能完成的工作量。創業公司可以用更少的人更快地構建產品。這聽起來像是軟件工程的黃金時代。

但我在和工程師朋友交流時發現了一個普遍的焦慮：代碼寫得快了，但系統運維變得更難了。有研究數據顯示，隨著AI編程工具的廣泛使用，生產環境中每次代碼變更導致的事故數量實際上在增加。這背后的邏輯其實很簡單：當你用AI生成代碼時，你對這些代碼的熟悉程度不如自己一行行寫出來的代碼。代碼中可能存在的邊界情況、潛在的性能問題、與其他系統的交互方式，這些細節你可能并不完全清楚。當這些代碼部署到生產環境后出現問題，你需要花更多時間去理解到底發生了什么。

Resolve AI的CEO Spiros Xanthos在接受采訪時提到了一個關鍵洞察：軟件工程最難的部分從來不是寫代碼，而是運行生產環境。問題很少只存在于單個系統中，根因通常隱藏在各個工具之間的關系里：一個延遲峰值可能與最近的部署有關，一個配置變更可能影響了特定的數據庫分片。我深有體會，因為我見過太多這樣的場景。工程師們在半夜被拉進戰情室，對著幾十個不同的監控面板，試圖在Datadog、Splunk、Grafana、Kubernetes和Slack之間來回切換，手動拼湊出到底哪里出了問題。

更糟糕的是，解決這些生產環境問題所需的知識往往是無法成文的"部落知識"。它存在于最資深工程師的腦海中：這個服務在什么情況下會出現這種錯誤？這個配置參數為什么要設成這個值？這個依賴關系為什么這么設計？當這些工程師不在崗時，這些知識就無法獲取。當他們離職時，這些知識可能就永遠消失了。對于一個快速增長的公司來說，依賴部落知識來維護生產環境是極其脆弱和不可擴展的。

所以現在的情況是：AI讓我們能夠更快地生成代碼，但如果我們不能同樣快速地運行和維護這些代碼，整體的技術迭代速度并不會真正提升。你可能在開發階段快了5倍，但如果在運維階段慢了3倍，整體效率的提升就大打折扣了。更不用說，生產環境的不穩定會直接影響用戶體驗、業務收入和公司聲譽。這就是為什么我認為Resolve AI瞄準的是一個被嚴重低估但極其關鍵的問題。

為什么生產環境是AI最難攻克的堡壘

我一直在思考一個問題：為什么AI在代碼生成方面取得了如此大的突破，但在生產環境運維方面卻進展緩慢？Resolve AI團隊給出了一個非常深刻的解釋：生產環境對AI agent來說是一個獨特困難的環境。

首先，現有的工具都是為人類設計的。監控系統、日志平臺、基礎設施管理工具，這些都是按照人類的思維方式和操作習慣構建的。AI agent要使用這些工具，就必須學會像人類一樣操作它們。這不像訓練一個模型去理解代碼那么簡單，因為代碼是結構化的文本，而生產環境的數據則分散在各種不同的系統中，每個系統都有自己的數據格式、查詢語言和訪問方式。

其次，做出任何決策都需要跨多個維度同時推理。你需要查看代碼變更歷史、系統遙測數據、基礎設施配置、部署記錄，然后把這些信息綜合起來才能理解到底發生了什么。舉個例子，一個API響應時間突然變慢，可能的原因包括：最近部署的代碼中有性能問題、數據庫查詢效率下降、某個依賴服務出現了延遲、網絡層面有擁塞、緩存失效導致了更多的數據庫訪問，或者僅僅是因為流量突然增加。要準確診斷問題，你需要檢查所有這些可能性，而每一個都需要訪問不同的系統、執行不同的查詢。

第三，最關鍵的上下文往往是未成文的。文檔經常過時，配置文件的注釋不完整，某個奇怪設置背后的原因可能只有當初做這個決定的工程師知道。這種"部落知識"是人類通過長期在特定環境中工作積累起來的，很難通過簡單的文檔或日志來傳遞。對于通用的大語言模型來說，它們無法獲取這些特定于每個組織的知識。

Spiros在訪談中提到了一個很有意思的類比：這就像自動駕駛汽車。我們不會讓自動駕駛汽車上路，除非它們能用數據證明自己比人類司機開得更好。而且自動駕駛也有不同的級別，從輔助駕駛到完全自動駕駛。同樣的道理也適用于生產環境的AI。我們不能一步跨越到讓AI完全自主管理生產系統，我們需要一個漸進的過程。一開始，AI執行調查工作并報告發現，由人類工程師做最終決策。然后，AI可以執行一些低風險或可逆的操作。最終，AI應該能夠解決人類無法解決的問題，并且在速度和可靠性上都超越人類。

這種漸進式的方法不僅是技術上的必要，也是文化上的必要。工程師們需要時間來建立對AI系統的信任。他們需要看到AI的推理過程，理解它為什么做出某個判斷，驗證它的結論是否正確。只有當AI能夠持續提供高質量、可解釋的結果時，工程師們才會愿意讓它承擔更大的責任。

Resolve AI如何破解這個難題

在了解Resolve AI的解決方案后，我對他們的技術架構印象深刻。他們構建的不是一個簡單的AI助手，而是一個復雜的多agent系統，專門為生產環境的特殊需求設計。

核心思路是這樣的：Resolve AI持續從代碼庫、可觀測性平臺、部署系統、云基礎設施、配置管理和運維歷史中提取上下文信息。這不是一次性的數據導入，而是持續的、實時的信息收集。系統需要理解你的服務架構、依賴關系、部署模式、常見故障模式等等。這些信息構成了一個知識圖譜，映射出服務、容器、組件之間的交互關系，捕捉那些原本只存在于資深工程師腦海中的部落知識。

當生產環境出現問題時，比如觸發了一個告警或發生了一次事故，Resolve AI的多agent系統就開始工作。有一個規劃agent負責整體協調，它會調度多個專門的子agent，每個子agent都經過訓練，擅長使用不同的工具和執行不同的任務。這些agent會系統性地分類問題、形成假設，然后通過收集證據來驗證或推翻每個假設。

我覺得特別聰明的是他們的驗證機制。一個agent執行某項工作后，會有另一個agent審查這項工作并提供反饋，然后第一個agent會根據反饋進行迭代。當多個agent協同工作時，它們各自完成任務后，還會有一個監督agent來審查整體的分析結果，如果發現推理中有漏洞，會要求相關agent重新工作。這種多層次的檢查和驗證機制確保了最終結果的可靠性。

Spiros在訪談中詳細解釋了這個多agent架構的設計考慮。他提到，對于需要長序列推理的復雜任務，他們會使用最強大的推理模型，通常是大型的閉源模型。而對于具體的執行任務，可能只需要一兩個步驟，就可以使用更快的閉源模型或者針對特定任務后訓練的開源模型。這種分層設計既保證了推理質量，又控制了成本和延遲。

最重要的是，Resolve AI不只是給出一個答案，而是提供一個帶有引用和推理過程的結構化解釋。它會展示推理步驟、相關查詢、甚至指出是哪個具體的Pull Request引入了問題。這種透明度對于建立工程師的信任至關重要。工程師可以驗證AI的推理是否正確,理解它為什么得出這個結論，而不是盲目接受一個黑盒的建議。

更進一步，隨著系統在特定組織中運行的時間越來越長，它會學習到越來越多關于該組織特定環境的知識。哪些模式通常預示著即將發生的問題？哪些操作序列最有效？哪些配置組合最穩定？這些都會被系統記錄下來，用于訓練和改進模型。這創造了一個數據飛輪：系統越用越好，越來越了解你的環境，也就越來越有價值。

從客戶的實際使用情況來看，效果確實顯著。Coinbase報告說，在測試的事故中，定位根本原因的時間減少了73%。想象一下，如果原本需要2小時才能找到問題根源，現在只需要半小時。這不僅僅是節省時間，更重要的是減少了用戶受影響的時間、降低了業務損失。Zscaler則報告說每次事故所需的工程師數量減少了30%。這意味著更少的人被半夜叫醒，更少的團隊協調成本，以及工程師有更多時間專注于構建新功能而不是救火。

為什么偏偏是現在

我一直在思考，為什么是現在這個時間點，Resolve AI能夠取得突破？為什么不是三年前或三年后？我認為有幾個關鍵因素的匯聚創造了這個機會窗口。

第一個因素是大語言模型和agent技術的成熟。過去一年里，我們看到了agent系統在軟件開發領域的巨大成功。這證明了agent不僅僅是概念驗證，而是可以在復雜、多步驟的任務中創造實際價值。Resolve AI團隊吸引了14位前DeepMind的工程師加入，這些人是agent AI的先驅者。他們帶來的不僅是技術能力，更是對agent系統設計的深刻理解。同時，他們團隊中還有在Microsoft、Google、Tesla、SpaceX等公司運行過世界上最復雜生產環境的工程師。這種AI前沿研究與生產系統深度專業知識的結合非常罕見。

第二個因素是AI代碼生成帶來的緊迫性。正如我前面提到的，AI正在讓代碼產出速度呈指數級增長。這意味著部署到生產環境的代碼量也在快速增加，服務數量增加、依賴關系變復雜、潛在故障點增多。如果運維能力跟不上開發速度,整個技術迭代就會卡在生產環節。這個痛點變得越來越尖銳，企業對解決方案的需求也越來越迫切。

第三個因素是企業開始真正理解這個問題的成本。Spiros提到,在AI輔助編程出現之前,工程師就已經花費大約70%的時間在維護生產系統上,而不是開發新功能�，F在隨著代碼量的增加,這個比例可能更高。對于一個科技公司來說,讓最優秀的工程師把大部分時間花在救火而不是創新上,是一種巨大的資源浪費。更不用說,生產環境的不穩定直接影響用戶體驗和業務收入。這已經不是一個可以忍受的問題,而是必須解決的戰略性問題。

第四個因素是投資者開始認識到這個領域的價值。Lightspeed的合伙人Sebastian Duesterhoeft在解釋為什么投資Resolve AI時說:"雖然軟件開發一直是AI增長最快的應用領域之一,但Spiros和Mayank很早就意識到真正的價值和更難的問題在于生產環境。"這種認知的轉變很重要。過去,投資者可能更關注那些直接提高開發效率的工具,但現在他們開始理解,如果不解決運維問題,開發效率的提升是不完整的。

我還注意到一個有趣的現象：Resolve AI的兩位創始人Spiros Xanthos和Mayank Agarwal在可觀測性領域有超過20年的經驗。他們之前的公司Omnition被Splunk收購,他們還共同創建了OpenTelemetry,這是管理遙測數據的全球開源標準。在Splunk,Spiros擔任可觀測性業務的高級副總裁兼總經理,管理著400多人的團隊。這種深厚的領域專業知識讓他們能夠真正理解生產環境的復雜性,而不是簡單地把AI技術套用到這個領域。他們知道現有工具的局限性在哪里,知道工程師真正的痛點是什么,知道什么樣的解決方案才能真正被采用。

從市場表現來看,時機確實成熟了。Resolve AI在16個月內就達到了10億美元估值,拿下了Coinbase、DoorDash、MongoDB、Salesforce、Zscaler這樣的重量級客戶,并且從種子輪到A輪的所有投資者都選擇了超額跟投。這些信號都表明,市場不僅認可這個方向,而且認為Resolve AI團隊有能力執行。

這將如何改變軟件工程

我認為,如果Resolve AI代表的"AI for prod"這個方向成功了,它將從根本上改變軟件工程的工作方式和職業發展路徑。這不是一個小的工具升級,而是整個范式的轉變。

最直接的影響是工程師的工作重心會發生遷移�，F在,即使是最資深的工程師也要花大量時間在瑣碎但緊急的運維任務上：查日志、分析監控數據、定位問題、制定修復方案。當AI能夠自動完成這些工作時,工程師可以把時間投入到更高價值的活動上：系統架構設計、性能優化策略、新技術評估、業務邏輯創新。這不是說運維工作不重要,而是說這些工作可以被自動化,讓人類專注于那些真正需要創造力和判斷力的任務。

Spiros在訪談中提到了一個很有啟發性的觀點：就像過去50年里軟件從機器語言到高級編程語言的演進一樣,AI代表的是又一層抽象。工程師不需要擔心他們會失去底層技能,因為問題不在于人類技能是否會退化,而在于我們應該讓AI agent能夠同時很好地完成代碼生成和代碼運維這兩件事,讓工程師在更高的抽象層面上工作。他們不再需要記住特定的查詢語言、API調用方式或CLI命令的具體語法,這些繁重而壓力巨大的底層工作都由AI處理,工程師則在更高層面思考和決策。

我預測會出現一種新的工作模式：工程師和AI agent的協同。在這種模式下,AI不是完全自主地運行一切,而是作為一個極其能干的助手,處理大量的繁瑣工作,然后向工程師報告關鍵發現和建議。工程師則負責做出重要決策、處理邊緣情況、處理需要業務判斷的問題。隨著AI系統變得越來越可靠,它可以承擔的責任范圍也會逐漸擴大。Spiros估計,大約一年后,AI將成為軟件運維的主要"駕駛員",人類在更高層面進行監督和決策。兩到三年后,AI可能會做出大部分決策,人類則負責設定高級框架和處理異常情況。

對于企業來說,這意味著技術團隊的規�；绞綍l生改變。傳統上,隨著系統復雜度增加,你需要雇傭更多的工程師和SRE來維護它。但有了AI for prod,同樣的團隊可以管理復雜得多的系統,或者說同樣復雜的系統需要更少的人來維護。這不一定意味著裁員,更可能意味著工程師可以把時間投入到創新而不是維護上,讓公司能夠更快地推出新產品和新功能。

我也想到了對人才市場的影響。會不會出現新的職位,比如"AI agent設計師"、"生產環境AI訓練師"或者"AI系統審計員"？這些角色負責設計agent的工作流程、訓練agent理解特定組織的環境、審查agent的決策是否合理。就像DevOps工程師這個角色是隨著云計算和自動化的興起而出現的,AI for prod可能也會催生新的專業角色。

從更宏觀的角度看,這可能會改變整個軟件行業的經濟學。如果運維成本大幅降低,軟件公司可以承擔更大的技術復雜度。那些原本因為運維成本過高而不可行的產品想法,可能變得可行了。創業公司可以用更小的團隊支撐更大規模的服務。這可能會加速整個行業的創新速度,因為從idea到production的障礙變小了。

Spiros說過一句話讓我印象深刻："在agent時代,會產生比以往任何時代都多得多的軟件。獲勝的團隊不會是寫代碼最快的,而是能夠可靠、安全地運行他們所寫代碼的團隊,并且速度要跟上開發節奏。"這就是AI for prod要實現的目標。而這次1.25億美元的A輪融資,讓Resolve AI有資源繼續構建這個未來。他們計劃把資金主要投入三個方向：研發,繼續推進作為世界級應用AI實驗室在軟件工程領域的前沿探索；產品深度,改進生產環境推理能力,向閉環系統邁進,并擴展與生產技術棧的集成；客戶成功,支持全球企業客戶的快速增長。

我相信,五年后回頭看,我們會認為2025-2026年是一個轉折點。就像2022-2023年是AI代碼生成的突破年一樣,2025-2026年可能會被記住為AI生產運維的突破年。當代碼生成和運維都被AI顯著增強后,軟件的整個生命周期都將加速,這才是真正意義上的生產力革命。

結尾

也歡迎大家留言討論，分享你的觀點！

覺得內容不錯的朋友能夠幫忙右下角點個贊，分享一下。您的每次分享，都是在激勵我不斷產出更好的內容。

歡迎關注深思圈，一起探索更大的世界。

- END -

兩個“特別坑”的AI產品創業方向，你知道嗎

速度將成為AI時代唯一的護城河

a16z重磅預測：Vibe coding贏者通吃？錯了，垂直專業化才是未來