替代 Devin、顛覆 Cursor！ AI 程式設計不再需要 IDE，用並行智慧體重構開發範式：MongoDB CEO 高調月臺
在 AI 工具風靡開發圈之前，一批經驗豐富的資深程式師，對它們始終保持警惕。 這些人，包括 Flask 作者 Armin Ronacher（17 年開發經驗）、PSPDFKit 創始人 Peter Steinberger（17 年 iOS 和 macOS 開發經驗），以及 Django 聯合作者 Simon Willison（25 年程式設計經驗）。 然而，就在今年，他們的看法都發生了根本轉變。
Armin 在過去幾個月中徹底改觀。 他曾對 AI 工具「不敢授權」，如今卻願意將工程主導交給程式設計代理，自己轉而去泡咖啡或陪孩子玩耍。 “如今顯而易見，我們正經歷一場翻天覆地的變革。”
Peter 作為擁有 17 年經驗的 iOS 和 Mac 開發者，近期重新開始撿起了編碼工作。 2021 年，PSPDFKit 獲得 1 億歐元融資時，他出售了自己在公司的全部股份，此後就只是偶爾寫點東西。 “現在，我們正處於技術發展的一個令人難以置信的十字路口。” “這些工具徹底改變了軟體構建的方式。” “Agentic AI 工具是有史以來最大的一次變革。”
' fill='%23FFFFFF'%3E%3Crect x='249' y='126' width='1' height='1'%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
Simon 曾是 Django 的創始人，目前是一名獨立軟體工程師。 對於當前 AI 工具在軟體開發中的實際能力，他是這樣評價的：「現在，編碼代理（Coding Agents）真的能用了：你可以把一個 LLM 放進迴圈中，讓它運行編譯器、測試框架、linter 和其他工具，給它一個目標，然後看著它完成整個流程。 在過去六個月，模型的進步已經從『好玩的玩具演示』，躍升到了日常可用的生產工具。 ”
在這個背景下，像 Copilot、Cursor 和 Claude Code 這樣的智慧 IDE 無疑是促成大家看法轉變的關鍵因素之一。 與此同時，我們也注意到了一種新的產品類別正在興起：Factory AI，它比 Copilot、Cursor 走得更遠，聲稱目標是擺脫傳統 IDE 的形態。
Factory AI 由理論物理學博士 Matan Grinberg 和曾任 Hugging Face 及微軟數據科學家的 Eno Reyes 共同創立的公司打造。
Grinberg 指出，如今 AI 被視為超越以往所有平台變革的強大力量，但 Copilot 和 Cursor 依然是傳統的 IDE。 “儘管大家普遍認為軟體開發模式會改變，但目前主流的做法仍是'在原有流程上附加 AI'：開發者在 IDE 中編碼 15 年，現在只是把 AI 塞進 IDE，成了 AI IDE。 換句話說，真正的轉型尚未發生。 ”
因此，Factory AI 的核心理念是重新思考軟體工程，不僅僅是寫代碼，而是關注整個端到端的軟體開發流程。
Factory 基於 Grinberg 所稱的「Droid 」構建：一個引擎，用於提取和處理公司工程系統數據以構建知識庫; 以及一個演算法，用於從知識庫中提取洞察以解決各種工程問題。 Droid 的第三個核心元件 Reflection Engine，充當 Factory 所利用的第三方 AI 模型的篩檢程式。
在過去的兩年裡，這家公司一直 只面向企業提供服務 ，據說在企業領域取得了顯著成功，其客戶涵蓋了從「種子期」到「上市」等不同發展階段的企業。 一個月前，Factory AI 首次向公眾開放 ，並獲得了 MongoDB CEO 的高度讚揚：
有些人將其與 Devin 對比，但兩者也存在不同的地方：Devin 宣揚的是“取代所有工程師”，但 Factory 更強調的是“增強”工程團隊的能力。
Matan Grinberg 在最近的一次訪談中也體現出他對這個行業的獨特見解。 他認為 AI 的到來將使程式師的工作重心轉向更高層次，並且「可解決的問題總量」也會因此變得更多。 未來那些具備系統性思維、深入理解底層原理並善於利用 AI 工具的程式師，將更具價值。
我們翻譯了 Matan 的訪談，來瞭解 Factory 的思想。 一些亮點摘錄如下：
五年後的世界會是什麼樣？ 我認為，從“想法”到“解決問題”的這段旅程將會高效得多。 可能以前需要一千個人才能完成的事情，將來只需要十個人就可以搞定。
會有一些軟體問題，其規模之大，就算地球上所有工程師一起上也解決不了。 而個人使用者面對這些問題時，能夠藉助一支“虛擬工程師大軍”來完成解決。
我們習慣於線性思維，但很多技術的演進卻是指數級的。
如果大家都有 AI 技術，這種競爭態勢會強制性地抬高「好軟體」的標準。
Matthew Berman：Factory 是一個和傳統 IDE 非常不同的產品。 它本質上就不是一個傳統意義上的 IDE。 這可能也反映了你對當前 AI 與軟體工程結合現狀，以及未來走向的看法。 那我們直接切入正題：你為什麼要做 Factory？ 能先說說背後的故事嗎？
Matan Grinberg： 好的，我可以從為什麼開始做 Factory 說起。 在做 Factory 之前，我當了十年理論物理學家，主要研究弦論。 當時我執著地堅持這條路，並不是因為我覺得它最適合我，而是因為它很難——我對難的事情總是有種莫名的吸引力。 後來我去了伯克利，開始攻讀博士學位。
在伯克利期間，我開始接觸一些 AI 的研究生課程，接觸到了當時還叫「程式合成」（program synthesis）的領域——現在我們稱之為“代碼生成”。 我一頭栽進去，很快就徹底轉向了 AI 研究。 那是 2022 年初。 代碼生成讓我著迷，是因為我從理論物理和弦論轉過來，已經被訓練成習慣關注那些最基礎、最普遍的事物。 而代碼或軟體開發，在整個 AI 領域裡扮演了極其普適的基礎角色。
模型在編碼方面的能力，往往直接關聯到它在其他下游任務中的表現。 不管是寫詩，還是回答學術問題，模型的編碼能力越強，它在其他任務中的能力也越強。 這種核心能力吸引了很多數學家和物理學家進入這一領域，這也是我當初被吸引的原因。
至於你剛才提到的「為什麼關注 IDE 之外的新交互模式」這個問題，我想先引用一句我們在 Factory 很認同的話——亨利·福特曾說過：「如果我問人們他們想要什麼，他們會說更快的馬。 ”
我們認為軟體工程的未來也是如此。 現在的開發模式基本都建立在 IDE 上，這種範式已經存在二十多年了，開發者都很熟悉，形成了非常固定的使用習慣。 而大家普遍也認同，軟體開發在未來五年會變得非常不同。 問題在於：我們現在是一個開發者寫每一行代碼的世界，而未來我們可能會進入一個開發者幾乎不再寫代碼的世界。
有一種思路是：從當前「寫滿代碼」的世界逐步演進到「零代碼」的理想狀態。 但我們的觀點是——這就像是試圖從馬演化出汽車。 但歷史上並不是這樣發生的。 我們是從第一性原理出發，直接造出了汽車。 我們現在的做法就像是在重新思考「交通」這個問題一樣，重構軟體工程的方式。
我們把這種模式叫做 agent-native 軟體開發，與傳統的 IDE 程式設計方式有本質的不同。
傳統開發者的思維是：「我怎麼才能更快地完成這個任務？ “於是會使用自動補全、單元測試等等工具來加快效率。 但 agent-native 的模式，是思維方式發生轉變：面對一個大任務，開發者要思考“我怎麼把它拆解成離散、可驗證、可並行執行的小步驟”，然後把這些步驟交給智慧體去並行完成。
這和串行地更快工作是兩種完全不同的提速方式。 一個任務如果能並行拆成四個部分去做，其速度提升遠超在原有流程中微優化。
Matthew Berman：我在使用 AI 產品時，最讓我驚豔的時刻，往往是當我意識到可以“並行”處理任務的時候。 第一次有這種感受，是我看到 OpenAI 的 operator，可以啟動一個需要數分鐘甚至幾十分鐘完成的長任務，然後再啟動第二個任務。 我意識到：我手裡有多個 agent 同時處理我原本要一個個完成的任務，真的是非常震撼。 我確實非常相信這種多智慧體並行執行任務的未來願景。
Matthew Berman：你剛剛提到一個很有意思的觀點：代碼生成的能力是模型其他強大能力的“上游”。 那我就想問一下——你有沒有看到蘋果這個週末剛發佈的那篇論文？ 你笑了，我猜你看過。 這篇被大家廣泛傳播的論文探討了“推理的錯覺”——它指出語言模型可能並沒有真正地在用自然語言進行推理。 他們設置了一些謎題，當複雜度上升后，模型就無法解決這些謎題了。
但這篇論文沒有提及的一點是：這些模型可以用代碼解決這些謎題，而且在任意複雜度下都能做到。 這讓我特別想問你：你認為語言模型用代碼進行邏輯推理、解謎題的能力，算是「智慧」嗎？ 你怎麼看這篇論文？
Matan Grinberg：—坦白說，我沒有認真讀那篇論文，只看了摘要。 沒來得及通讀全文。 說實話這篇論文的發表時機，和蘋果現在在 AI 市場的處境聯繫起來還挺有意思的。
至於「寫代碼算不算智慧」？ 我覺得我們現在所處的時代特別有意思的一點是，整個“智慧”這個概念本身正面臨質疑。 每當一個大模型做成某件事，我們總會本能地想：“哦，那不算智慧，那只是記憶”或者“那只是訓練數據的複現”。 我們總會說它只是插值，不是真正的推理。
但這其實很難定義。 我至今也沒看到過一個真正清晰、統一的「智慧」定義，能夠明確劃分」這算智慧“、”那不算“。
我覺得有意思的一個方向是 ARC 獎（ARC Prize）那邊在做的研究。 他們強調泛化能力、模式匹配等等。 這方面他們做了不少不錯的探索。 有一點非常明確：模型在訓練數據中接觸越多的任務類型，它在這些任務上的表現就越好。
當然，這也會引發一種質疑：「它只是做熟了，才會。 “但人類也是這樣。 人類能泛化得更好一些，從一種題型推廣到另一種題型，但本質上，我們也需要訓練。
Sarah Guo 最近說了句話我挺認同：當人們談論 AGI 或智慧時，其實他們潛意識裡說的是“意識”（consciousness），這兩個概念經常在無意識中混淆。
回到你問的問題，我的看法是：要解決某些編碼問題，確實需要智慧。 所以按這個標準來說，這些模型當然具備智慧。 至於它們有沒有超越訓練數據的「廣義智慧」？ 答案是否定的。 但這正是各大實驗室現在努力攻克的方向。
Matthew Berman：我也相信，相比於自然語言，模型通過寫代碼的方式，展現出的泛化能力要更強。 我想回到“並行處理”這個話題上來。 過去幾十年裡，人類工程師團隊協同工作時，通常不會在同一段代碼上一起開發——否則就會產生大量衝突。 而 Git 就是為了解決這些衝突而生的。 那麼，智慧體在並行協作時的方式和人類有何不同？
Matan Grinberg： 好問題。 我認為這也涉及一個關鍵問題：當軟體開發智慧體越來越強大時，人類在其中扮演什麼角色？
如果是兩個完全獨立的任務，比如開發功能一和功能二，那當然可以並行。 但如你所說，如果它們要修改相同的核心代碼區域，那就會出現合併衝突。
我認為人類工程師在未來將扮演一個非常重要的角色：比如在處理“功能一”的時候，如何最優地將任務拆解成子問題 ，而這些子問題必須是可以並行處理的 。
那人類需要什麼樣的能力才能做到這種高效拆解？ 答案是：系統性思維（systems thinking）。
真正優秀的工程師從來都不是那種記住每門語言所有細節的人，而是具備系統性思維、能在各種限制條件下做出合理推斷的人。 現在我們擁有了一種全新的交互模式和開發方式：不再是“思考完怎麼做，然後自己動手實現”，而是儘快地整理出一個完整的“任務包”，包含可執行的步驟，以及驗證這些步驟是否完成的標準，然後交給智慧體去實現。
Matthew Berman：你提到系統性思維，我很認同。 我經常被問到一個問題，你可能也會遇到：現在還值得學程式設計嗎？ 我問過 GitHub CEO 這個問題。 我自己有兩個年幼的孩子。 對我來說，學會程式設計是我一生中最重要的技能之一，它讓我可以把腦海中的想法變成現實，而不依賴他人。 *
幾年前，如果你問我，我會毫不猶豫地告訴我的孩子：「程式設計是最重要的技能，必須學。 ”
但之後有一段時間我產生了動搖。 不過讓我再次把這個問題拉回到系統性思維。 除了學程式設計之外， 系統性思維本身也是我學到的最重要能力之一。 即使未來大多數代碼都由智慧體來寫，這種思維方式依然對整個工作流程至關重要，甚至放在整個“人生技能”範疇下也一樣重要。 你怎麼看？
Matan Grinberg： 我完全同意，甚至想說個稍微更“激進”的觀點：對現在還在讀高中或大學的年輕人來說，他們學的是計算機、數學、物理還是生物，其實並沒那麼重要。
重要的是：他們進入的這些領域，問題空間都非常龐大、資訊密度極高，還有幾百年的學術歷史——現實中沒人有時間把所有細節都學一遍。
所以關鍵在於：你是否具備一種能力—— 進入一個複雜領域后，迅速搞清楚核心基礎是什麼，哪些細節是你必須弄懂的，哪些可以暫時模糊理解，但依然能繼續往前推進。
我可能有點偏見，因為我自己花了十年時間研究物理。 一個比喻是這樣的：每次我站在黑板前寫下一個公式時，我不會每次都重新推導相關定理——那樣效率太低。 但在我人生中的某個階段，我確實做過這些推導，而且如果有人現在讓我推一次，我也能推出來。
我覺得這和軟體開發很相似。 在大學的計算機課程中，我們通常會從底層逐步學到高級語言。 現實中你可能永遠不會用到機器碼，但理解它是有説明的。
這同樣回到了系統性思維的問題：你得瞭解你所工作的「整個技術棧」的結構。 就像物理學家和數學家也會使用計算機、用各種他人推導好的定理，他們不會每次都重頭再證明一遍，但他們曾經學過這些推導 ，知道如何從頭做一次。
如果你忽略了這些基本功，哪怕現在有智慧體幫你寫代碼，最終也可能吃虧。 因為你沒有那個「在資訊大山中摸索出路徑」的經驗和能力。
而這正是你說的那個關鍵技能：面對一個複雜領域，知道該深入掌握什麼、又能對哪些東西保持模糊但足夠用的理解，並繼續往前推進。
Matthew Berman：我聽你描述的其實是“抽象層”的概念。 而放回軟體工程的上下文裡，今天很多人都在問：未來我們會成為 orchestrator（編排者）嗎？ 我們是不是主要職責就是檢查智慧體的工作？ 無論是哪種角色，瞭解底層原理仍然是必須的。 哪怕你不親自去寫每個演算法、不從頭實現每個函數，你也需要有基本的判斷力才能檢查智慧體做的是否正確，或者調度它們正確地協作。
Matthew Berman：過去兩年裡，軟體工程的變化速度真的令人震驚。 讓我意外的是：AI 對軟體工程的影響居然是最大的（儘管現在看好像也不算意外了）。 而且它的變化速度還在持續加快。 你剛剛描述了未來幾年可能出現的「智慧體編排」形態，以及從 IDE 向更高抽象層的遷移。 那麼你覺得 5 年後、10 年後的世界會變成什麼樣？
Matan Grinberg： 當然我知道這類預測不可能準確，但我還是很想聽聽你的願景。
我完全同意你說的“預測很難”這個前提。 預測 5 年後的事情本來就極具不確定性。
2020 年的時候，可能有極少數人能預見我們今天的樣子，但真的非常少。 因為每一代模型的進步都會產生指數級連鎖反應，而這些累積效應會影響未來每一年的節奏。
所以預測時，一個很重要的意識是： 人類並不擅長處理“複利”這種非線性思維方式。
這不是我第一個提出來，也不會是最後一個這麼說的人。 我們習慣用線性方式思考，但科技進展是指數曲線。 有一個很棒的梗圖我想跟你分享。 這來自 Daniel Kokotajlo 的博客。 這張圖非常形象地說明了我們在處理非線性增長時的無能。
比如，全球 GDP 增長就是一種非常誇張的指數曲線。 但在 2010 到 2020 這十年裡，大多數人並沒有覺得進展有多“瘋狂”。 但其實那段時間 GDP 曲線幾乎是垂直往上的。
所以當我們試圖思考未來 5~10 年時，我們其實很難做出有高置信度的判斷。
我唯一能說的是， 在思考未來時，我會盡量回歸初衷 。 我們搞軟體工程的初衷並不是為了寫代碼本身。 我們不是為了代碼而寫代碼，而是為了造出我們想造的東西。
我們寫程式，是為了藉助計算機這種比人類快得多的「計算機器」完成我們的目標。 計算只是手段，不是目的。 真正的目標，是用它來構建連接世界的工具、解決現實的問題。 我們想要實現的是有意義的終點。 比如，我們想要類比某些科學現象，以便研發新藥; 又比如，我們只是想讓打車這件事變得更高效，不必再等上三十分鐘才叫到計程車。
這些才是我們的目的 ，而手段是軟體，因為我們想用機器來完成這些事，而不是僅依靠人工系統。 為了與機器交流，我們不得不學習一種非常精確的語言——程式設計語言。 後來我們慢慢讓這種語言變得越來越抽象，因為直接用比特與機器交流實在是太低效了。 用更高層次的抽象語言，效率反而更高。 所以我認為這個趨勢還會持續下去。
過去，我們必須深入學習程式設計，才能知道如何與機器協作。 但現在我們正開始“抽離”出來，重新關注我們真正想實現的目標。
所以回到你剛才的問題——我認為在未來的 5 到 10 年裡，我們能以更快速度解決更多問題。 比如，以前一個問題可能需要1000名工程師和10年時間去建立一家公司來解決它。 但未來你可能只需要 10 個人，就能把一個想法變成現實並完成整個閉環。
從這個角度看，好像會出現公司人數下降、不會再有一萬人的大公司了。 但我認為還有另一個相反方向的力量存在：如果你有 1 萬名工程師，而他們每個人都能把任務分派給幾百個智慧體——那麼軟體能實現的規模和複雜性也會大大提升。
現在我們都很難想像如何協調一個十萬人規模的軟體開發組織。 但像微軟這樣的公司正在嘗試這麼做。 雖然它們的效率肯定還存在瓶頸，但如果你把時間放到未來 5~10 年，屆時軟體系統的複雜性可能遠超我們今天的想像。
那會是一個我們幾乎無法理解的世界。 想像一下“相當於一百萬名軟體工程師同時工作”的產出規模——這都難以想像。
Matthew Berman：聽你講完，我感覺我們對未來的看法其實非常一致，而且你也非常樂觀。
很多人覺得，如果現在一款產品過去需要 1000 名工程師，而將來只需要 10 個，那公司一定會裁掉那 990 個人。 但我持反例，甚至持更樂觀的態度。 因為真正發生的事是——「可解決的問題總量」會急劇擴大。 雖然現在 10 人就能解決一個問題 X，但之後你會有問題 Y、Z、α 等等。 那些原本做 X 的工程師可以繼續去解決這些新問題——他們只是“被超級加持了”。
所以我不認為最終會是那種“一個人領導一家公司，下面全是 AI 軍團”的格局。 我不認為未來世界只剩下 10 家公司，每家就一個人 + 一堆智慧體。 恰恰相反。 以前有些“長尾問題”之所以沒人解決，不是因為它們不重要，而是 解決它們的“智力成本”不划算 ——但這一點即將改變。
Matan Grinberg： 確實如此。 通常一個問題的「可服務市場規模」（TAM）會決定它能吸引多少工程師和資金來解決。 比如某個問題只影響全世界 20 萬人，那你就會根據他們的消費能力來判斷值不值得投入資源去解決。
以前，也許這種問題只值幾百工程師的投入。 但現在情況不同了：哪怕某個問題只影響幾千人，你也可以投入相當於十萬工程師的“智慧體產能”去解決它。
我覺得這太酷了。 哪怕一個問題只影響 2000 人，我也覺得值得解決——理想世界里，不該有人被遺留，而現在我們可以把這種“計算力”集中起來去解決這些問題。
Matthew Berman： 甚至可能最終把問題細化到只影響一個人的程度。 而那時，軟體的開發成本也會降到如此之低，以至於哪怕是“為一個人量身定製”的解決方案都能盈利。 這真的非常有趣。 當然，我們剛才討論的，是那種極致長尾的問題。 未來也還有另一類—— 我們現在甚至想像不出的龐大問題 。 這些也許是幾十年以後的事。 但假如我們未來走向星辰大海，一定會產生一些巨大的軟體問題 ，是全人類的工程師都解決不了的。
但在那個未來，每一位人類工程師都會擁有屬於自己的“虛擬工程師軍團”。 所以也許，到時候這些原本無法解決的問題就變得可解了。
Matan Grinberg： 完全同意。 我特別喜歡你剛才說的那種描述方式：這不是為了軟體工程本身而做軟體工程，而是每個人有自己的問題——他手上有 AI 工程軍團，能用來解決問題。
無論是探索宇宙，還是別的什麼，人們總會在路上遇到各種挑戰，而他們可以更高效地解決這些問題。 這種效率的提升，顯然是對整個社會的巨大正向推動。
Matthew Berman：說回 Factory 產品本身。 我最初使用它時，最打動我的是它的“設計”。
不僅是 UI，更是整個使用體驗（UX）。 它顯然不是一個 IDE。 所以，談談你們的設計理念吧。 Factory 的 UI/UX 正在走向什麼方向？ 它如何影響人與產品之間的交互？
Matan Grinberg： 首先，我要大大表揚我們的設計師 Cal——他其實是我親哥哥。 能和他一起工作，真是一種樂趣。 我們設計上的幾個亮點之一是：Cal 的背景其實是工業設計，他畢業於 RISD（美國最頂尖的藝術院校）。 而 Factory 有 22 位世界頂尖的工程師。
我認為我們特別注重在設計時吸收不同視角，哪怕我們做的是給程式師用的工具。 很多人會直覺地認為：「這是程式師用的產品，那就讓程式師來設計吧，聽聽他們的意見就行。 “比如功能 A 放這兒還是放那兒，大家一起投票決定。 但 Cal 作為一個「局外人」，他的設計背景和 UX/UI 視角，其實帶來了非常寶貴的價值。
因為我們的目標之一，是擺脫 IDE 的形態 。
而市面上最頂尖的程式師過去十幾年都一直在使用傳統 IDE，所以他們腦子裡已經形成了非常深的習慣。 反而是 Cal—— 他從沒用過 IDE，所以他根本沒有這些「舊習慣」，這就讓他能提出一些全新的視角。
這有點像物理學領域也會出現的現象：為什麼很多物理學家的「最強突破」都發生在 27 歲左右？ 因為那時候他們既有足夠的專業背景，又沒被各種教條和慣性思維束縛住。 他們還有勇氣和能力去「質疑一切」。
這種心態在我們的設計工作中非常有説明。
至於產品未來的走向，如我之前所說，我們在嘗試構建一輛“車”，而不是在“馬車”上反復加速。 傳統做法是在 IDE 上堆疊更多 AI 功能。 但我們的目標是徹底跳出 IDE。
最終理想是，人類開發者不再需要手動去寫代碼。 開發者只需要提供一份清晰的計劃——不僅僅是“給我做個儀錶盤”這種模糊需求，而是通過設計正確的交互，引導他們提供真正準確、可操作的限制條件和目標定義。 這樣我們才能真正理解開發者的意圖，並盡可能忠實地將其實現。
我們希望能有確定性的方式來驗證生成結果。 舉個稍微有點傻的例子：假設我想做一個藍色的儀錶盤。 我對 Factory 說：“嘿，幫我做一個符合 Factory 主題風格的儀錶盤。 “結果它給我生成了一個粉色的介面——這顯然違背了我們現有的設計系統。
我們想要的是，即使 Factory 出現這種偏差，生成了不符合我們預期約束的內容，它也應該具備能力去發現這個問題，然後自動反覆運算修正，而不是通知我“我搞定了”，然後我點開一看——結果居然是粉色的。 然後我還得說：“我們通常是深色模式啊。 ”
所以，我們正在塑造一種交互模式，讓人類開發者可以更清晰地表達他們的約束條件，或者系統能隨著使用不斷學習這些約束，這樣他們就不需要每次都重複說明。
與此同時，在底層的系統層面，我們也在確保檢索和代碼生成的能力始終保持領先。 確保那些執行代碼的「droid」 （智慧代理） 能基於運行結果進行反覆運算，比如某個測試失敗了，它能據此修復而不是讓人來回手動干預。
我們越能搞定這一點，開發者就越不需要自己手動修改代碼——這也是我們走向“Agent-Native”未來的重要一步：人類開發者只需要清晰地定義他們的目標和任務範圍，然後把它交給代理去完成。
Matthew Berman：Factory 對企業的代碼庫理解得非常深。 那麼，你能不能分享一些幕後內容，比如 Factory 的 droid（智慧代理）是如何理解代碼、保持模式一致、不做不該做的修改的？ Factory 在這些方面有哪些獨特的方法？
Matan Grinberg： 我覺得主要有三點關鍵技術，我們可以一一聊一下：
原生集成
記憶系統
本地和遠端的代碼執行能力
首先是原生集成。
MCP 伺服器確實挺強的，但我覺得它目前有點被過度炒作了。 MCP 的優點在於，它能把 IDE 中的資訊注入到模型里，但它的缺點也很明顯——對於大型代碼庫或企業環境，它的計算都是臨時完成的，這和人類工程師的工作方式非常不同。
人類工程師在處理問題時，並不會「清空記憶」然後重新搜索所有相關內容。 通常他們已經對自己的代碼庫和團隊架構有一定的「先驗理解」，遇到問題時可以直接想到：「哦，這個跟那塊代碼有關」，然後快速定位、解決問題。
Factory 採用類似的思路。 我們和 GitHub、Slack、Jira、Sentry、Datadog 等工具進行了深度原生集成，並且預先計算了它們之間的關聯關係。
比如：某個 Notion 文件裡寫了一份技術設計方案，它是基於一些客戶需求或問題產生的，然後你提交了一個 PR 去實現它，之後 Sentry 報告了這個 PR 引發的故障。 現在，如果你要追溯問題來源，我們不需要臨時從各個系統中“抓資訊”，而是已經知道這些內容的上下文鏈條。 你可以更快、更高品質地排查和修改問題。
所以相比 MCP，Factory 的原生集成方式在大型企業中更節省時間，也更穩定可靠。
Matthew Berman：好的，那我們再聊聊“記憶”這一塊。 我本來也想問這個，因為像 ChatGPT 的記憶功能就非常重要，它提升了交互品質。 那麼 Factory 是如何實現記憶機制的？
Matan Grinberg：Factory 的記憶分為多個層級，能讓系統逐步“瞭解你”：
組織層級記憶 ：瞭解整個組織的工作方式、產品細節、面向的客戶、使用的技術棧等。
團隊層級記憶 ：不同團隊可能有各自的流程和習慣，Factory 會分別學習。
個人層級記憶 ：比如你寫代碼時總是忘記寫測試，Factory 會記住，並在你提交 PR 時自動補上測試; 或者你們團隊對 PR 有嚴格要求，Factory 就會自動幫你調整格式、補文檔等，以滿足這些要求。
這些記憶會隨著使用持續學習和進化，當然，你也可以手動修改或配置這些記憶，不管是組織負責人、團隊 leader 還是個人開發者都可以自定義。
第三個關鍵點是——Factory 可以執行代碼。
具體來說，Factory 提供了兩種執行模式：
遠端執行 ：你可以在雲端環境中併發啟動多個 droid，讓它們同時處理不同任務，比如同時生成多個模組或完成多項需求。
本地執行 ：如果你想更親自參與控制流程，比如更精細地監控執行細節，那你可以讓代碼在本地設備上運行。
另外，具備真實的代碼執行能力，意味著你不再是“寫完代碼就盲目提交”，而是能夠真正運行它、驗證它能否編譯通過、測試是否成功，以及它是否真的按照你的預期功能去執行。
這與人類工程師的工作方式非常相似。 人類不會只是寫完代碼就提交 PR，覺得「應該能行」。 他們會實際運行、檢查並確認：「這個代碼真的完成了我想要的功能嗎？ 所有測試都通過了嗎？ ”
Matthew Berman：現在 Factory 大大降低了寫代碼的門檻，讓高品質、規模化的代碼生產變得容易。 這讓我在思考：垂直型 SaaS 公司會不會受到衝擊？ 比如以前那些不是技術型的企業，沒有富餘的工程師團隊，也無法自建系統解決內部需求。 那麼你覺得這些企業是否該採用 Factory，自建一些工具？
Matan Grinberg： 事實上，我們目前最大的一些客戶，其核心競爭力也並不是軟體開發。 比如說我們的一位客戶是德國製藥巨頭拜耳（Bayer），也就是那個做阿司匹林的公司。 他們就是我們的使用者之一。
他們並不賣軟體，但現實情況是， 今天的每一家企業，在某種程度上都依賴軟體 。 即便軟體不是你直接銷售的產品，它對企業提高槓桿效率來說依然至關重要。
如果你現在能讓「droid」 （智慧代理） 來幫你分擔任務，或者說你之前為了一些舊系統支付了大量費用，但實際上只需要用到其中的一小部分功能——現在你完全可以自己內部搭建一個更符合需求的工具。
或者說，你可以用更少的工程師，更快地發佈產品。 因為對於那些軟體不是核心業務的公司來說，他們手上的工程師本來就不多。 那你就更需要給他們配備最前沿、高效的工具。
而且還有「乘數效應」——每位工程師都能有多個智慧代理協作，這種一對多的工作方式會極大提高產出。 所以我的答案是：是的，非技術公司特別適合使用 Factory。
Matthew Berman：尤其是因為 Factory 的存在，才讓那些沒有太多開發經驗的人，也能真正寫出優秀的軟體。 這一點非常有意義。 那我們接著說吧。 像 Factory 這樣的產品正在把軟體開發的成本壓縮到接近零。 那麼，這對垂直型 SaaS 公司意味著什麼？
Matan Grinberg： 是的，現在確實是一個非常有意思的時間點。 這其實也呼應了你剛剛提到的一個觀點：如果 AI 工具能讓每個工程師的效率提升 10 倍，那公司是否會因此裁員？
如果世界上不存在競爭 ，那也許會這樣。 但現實是—— 每一家你的競爭對手現在也能讓他們的工程師效率提升 10 倍 。
所以你當然可以裁員，然後保持當前的生產效率。 但如果你的對手沒有裁員 ，反而用這些效率工具讓自己變得更強，那他們的整體產出將是你的 100 倍，最終你只會被甩在後面。
這對軟體用戶來說是好事，因為這意味著—— 你所用軟體的門檻和質量標準將會顯著提高 。
這其實就像博弈論的經典場景：如果只有你一個人擁有 AI 技術，那你當然可以靠它降本增效。 但現實是，大家都有這項技術。 這種競爭態勢會強制性地抬高「好軟體」的標準 。
類似的例子還有 90 年代的網站。 當時要做出一個漂亮的網站非常難，而現在有了各種低代碼工具，幾分鐘就能搞定炫酷網站。 所以現在我們眼裡的“好網站”門檻，比以前高了很多——90 年代那種頂尖網站，現在只能算入門水準 。
Matthew Berman：最後一個問題，Matan。 你覺得大家接下來該關注什麼？ 你們未來 6 個月會做哪些新東西？
Matan Grinberg： 我覺得最值得期待的是， 智慧代理（agents）會變得更可靠，品質更高 ，你用更少的提示，它們就能更準確地完成你想要的任務。
現在我們看到，真正沉浸在 「Agent Native」 軟體開發方式里的使用者，在使用 Factory 時會有一種「魔法般的體驗」。 但即使在那些擁有上萬名開發者的大公司里，仍有很多人對 AI 和 Agent 不感冒。 他們可能並沒有太強烈的意願去嘗試這些新工具，因為現在確實還需要一些“善意的投入”——你要去寫清楚你希望 Agent 做什麼，才能讓它給你一個好的結果。
但我相信，再過 六個月 ，哪怕你完全不在乎 AI、依然每天待在你的 Emacs 裡、只想按照老方式寫代碼，只要你肯花一分鐘嘗試一下 Factory——你就會被驚豔到。
那種提升開發者能力和工作槓桿的方式，會真正讓你感受到 empowered，讓你願意擁抱這種新的範式。
參考連結：
https://www.youtube.com/watch?v=sI3D1UY-cV0&t=5s
https://www.youtube.com/watch?v=8gKN29Ea-J8
https://techcrunch.com/2023/11/02/factory-wants-to-use-ai-to-automate-the-software-dev-lifecycle/
聲明：本文為 InfoQ 翻譯整理，不代表平台觀點，未經許可禁止轉載。
印度工程師長達一年「多頭騙薪」，Meta 也曾力挺！ 矽谷多位創始人實名舉報
跳槽實現財富自由！ 小扎千萬年薪快要「掏空」OpenAI 核心人才，還高調「曬」挖人成績單：各棧大牛，近 70%是華人
十周前才寫下第一行代碼，如今顛覆 9 個行業？ 員工人均 10 萬粉，00 後創業者狂言：我們將超越 OpenAI
我押注 12 億美元買下當年移動界的“OpenAI”，卻眼睜睜看它 49 天夭折
首屆 AICon 全球人工智慧開發與應用大會（深圳站）將於 8 月 22-23 日正式舉行！ 本次大會以 「探索 AI 應用邊界」 為主題，聚焦 Agent、多模態、AI 產品設計等熱門方向，圍繞企業如何通過大模型降低成本、提升經營效率的實際應用案例，邀請來自頭部企業、大廠以及明星創業公司的專家，帶來一線的大模型實踐經驗和前沿洞察。 一起探索 AI 應用的更多可能，發掘 AI 驅動業務增長的新路徑！