AI Coding 或者 Coding Agent，或許是當下最火熱的 AI 賽道。這是模型能力的主線，更強的代碼能力，意味著模型能夠解鎖更多應用場景。

在全行業都在體驗 AI Coding 的時候，氛圍編程 Vibe Coding 成為了最熱門的關鍵詞。

Vibe Coding 引入了大量非專業代碼人群，因此飽受關注。但陳志杰意識到，嚴肅場景的軟件生產比想象中復雜的多。

軟件開發是一個數十年的產業，軟件開發構建了今天我們熟悉的整個「數字世界」。

而寫代碼，僅僅是軟件工程的一個子環節。這意味著，剛剛能夠做到基礎 Coding 的大模型，也許之后有機會解決更大更難的問題。

一個有機會被 AI 顛覆的價值極高的存量市場。

2025 年初，前 TikTok 算法負責人陳志杰選擇創業，與老搭檔劉曉春一起，創辦言創萬物，聚焦 AI Coding 方向，更準確地說，AI SWE（軟件工程）。

我們找到陳志杰和劉曉春，聊了聊他們眼中的 AI Coding 和 AI SWE。AI 將會如何改變軟件生產的全鏈路？未來工程師與 AI 之間的關系會是怎樣？作為創業公司，他們打算怎么做？

采訪 ｜ Nico、李一豪

編輯 ｜ Nico、萬戶

言創萬物投資人，早期基金 Creek Stone 的合伙人李一豪也參與了本次采訪，感謝他提出了很多有價值的問題。

超 6000 人的「AI 產品市集」社群！不錯過每一款有價值的 AI 應用。

邀請從業者、開發人員和創業者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準的AI產品曝光渠道

公司 & 團隊介紹

言創萬物是一家致力于以 Agent 技術重構軟件研發的 AI 初創公司，成立于 2025 年初，已完成近千萬美元天使輪融資。我們正在構建一支 AI 驅動的團隊，從產品、技術到組織全面擁抱 AI，以推動軟件開發進入下一個時代。

陳志杰，2010 年畢業后加入百度鳳巢從事算法研發工作。2019 年之后在歡聚時代內部創業，2020 年底加入字節，開始做推薦算法。當前為言創萬物 cofounder & CEO。

劉曉春，2011 年起在百度鳳巢從事算法研發，2019 ～2020 年在歡聚時代內部創業。2020 年底返回百度，先后在鳳巢、搜索、電商等負責技術、產品。當前為言創萬物 cofounder & COO。

01寫代碼只占軟件工程師工作的 30%

Founder Park：從 TikTok 出來創業，為什么不選擇原本非常熟悉的泛娛樂賽道？

陳志杰：我個人感覺這一波最本質的其實是生產力的提升。我之前也看過很多 ToC 的娛樂向產品，不僅 DAU 體量非常小，最可怕的是 DAU 不怎么漲，這是一個很大的問題。

但真正提升用戶效率的方向，像 Cursor、Replit 等編程工具，ElevenLabs 、Harvey.ai 、Glean、Abridge、Sierra、manus、Genspark 等法律、醫療領域應用，還有智能客服等場景都涌現出很多不錯的公司。所以我們創業一開始的大方向，也是鎖定在提升生產力與效率的領域。

劉曉春：我們確實也考慮過 C 端，但最后還是覺得——AI 在 C 端目前缺少一個真正有吸引力、能打動用戶的產品形態。它雖然很強，但離「讓人非用不可」的階段還有點距離。

而反過來看，生產端就不一樣了，效率提升這件事本來就和 AI 是天然契合的。它解決的是實際的問題，能帶來非常明確的價值，效果看得見，摸得著。所以我們覺得，還是應該把精力聚焦在這個方向上。

李一豪：過去幾個周期里面，很多 C 端娛樂產品還是借助媒體載體形態的變化，從廣播、電視到 PC、移動設備，每一次硬件迭代都催生出適配新形態的產品，具有強烈的媒介依賴性。但是我們現在看到的這波 AI 進展，還是初步的、文本 based 的智能，剛剛到推理的階段。對于娛樂的顛覆，它現在還沒辦法跟現有的、高質量內容生產的上一代工具去 PK。

陳志杰：是的，你看上一波那些很成功的產品，比如 Facebook、YouTube、Instagram、Twitter、TikTok/抖音、快手，它們背后的本質是某種智能嗎？不是。是某種生產力的提升嗎？也不是。它其實本質還是人與人之間的連接，或者是內容本身。

Founder Park：提到 Coding，現在最火的詞是 Vibe Coding，你怎么理解這個概念？

陳志杰：vibe coding，跟著感覺走編程。可能對于一些 demo 或自娛自樂開發很有趣。但嚴肅的開發場景沒那么簡單。不要小看嚴肅場景的復雜度，也不要小看專業工程師的才智，那些嚴肅場景的開發不是那么容易被 vibe coding 替代的。

很多人只看到 AI Coding 本身，卻忽略了它只是軟件研發生命周期的一環。實際上，工程師日常工作中，coding 環節的時間占比通常不超過 30%。國內外公司普遍都這樣，像紅杉對 Codex 團隊的采訪也說到，工程師編碼時間不超 35%。真正的機會在于 AI SWE（AI 軟件工程，Software Engineering）。

Founder Park：寫代碼只是整個軟件工程（SWE）中的一環，怎么理解 Coding 在 SWE 中的定位？

陳志杰：SWE 是一個很復雜的事情。無論是從軟件生命周期還是軟件架構分層視角看，coding 都只是其中一個環節。

從軟件研發生命周期視角看，SWE 是指軟件（傳統軟件/互聯網產品/新一代 AI 產品等）生產的全流程，包括需求溝通、技術設計、writing code、code review、testing、代碼合并、程序構建、部署發布、監控運維的整個過程。 寫代碼僅僅是整個 SWE 全流程中的一部分。從統計數據看，中外公司工程師日常工作寫代碼的時間，平均下來都不會超過 35%。

從軟件分層架構的視角看，任何一個真正有實際應用價值的 online service，靠一個單一模塊（代碼庫）是無法 work 的。比如一個嚴肅的在線服務，除了你直接寫代碼的那個模塊，還需要考慮負載均衡、緩存機制、數據存儲、前后端架構、服務監控、數據落盤、報表分析等等很多依賴的模塊。

當前 AI 主要還是單個模塊下的代碼生成，這還遠遠未到達終態。寫某個模塊的代碼僅僅是第一步，SWE 中還需要眾多工作要完成。現實中的這些服務模塊、配置項、環境依賴需要嚴絲合縫的「咬合」在一起，否則是 run 不起來了的。

整個數字世界都是建立在軟件基礎之上，產值不言而喻。傳統 SWE 領域發展至今，涌現出了眾多優秀的開源或閉源工具了，也出現了非常多以「提供軟件技術服務為核心業務」的高市值公司，比如云廠商，Oracle，databricks、mongoDB 等等。

「軟件工程/軟件生產」不是一個 fancy 的詞匯，也不是新概念。但任何所謂 fancy 的概念的落地，都是在軟件基礎之上的。而作為 foundational infrastructure，SWE 領域的發展依然欣欣向榮，在每個技術大突破浪潮下，都會創立非常優秀的公司。

Founder Park：這樣一件復雜、長鏈路的事情，為什么不是大廠做？創業公司有什么機會？

陳志杰：正是因為 AI SWE 覆蓋的場景足夠廣泛而且很復雜，目前還沒有一家公司能解決所有環節的問題，這正是行業的巨大機會所在。我們可以看下云廠商，aws 上的 CI/CD 服務，多數云客戶傾向于使用第三方工具，而非完全依賴云廠商自家的 CI/CD 服務。所以我相信，AI-SWE 的發展也會如此，未來可能會有十幾家很有價值的 AI-SWE 公司，而非一兩家壟斷。

大公司在這方面的推進速度也未必快。例如，GitHub Copilot 作為最早做 AI Coding 的產品之一，如今它的使用體驗好像不如后起之秀 Cursor。谷歌前段時間推出的編碼工具 Jules，實際體驗也較為一般。

相比之下，創業公司雖資源有限，但在聚焦的細分領域投入往往不小。以 coding 產品化項目為例，大公司投入的人力可能也就幾十人，這樣去對比的話，考慮到大廠還存在組織效率等其他客觀條件的限制，我覺得這里一定有創業公司的機會。

劉曉春：我補充幾點看法。

首先，AI Coding 是一個問題特別多、用戶又特別挑剔的領域。很多用戶會因為某個功能特別好用就留下來，也會因為一個點不順手就立馬流失。這種情況下，其實是有利于新玩家進入的。因為一旦現有產品解決不了用戶的問題，用戶就會自然轉向更好的新產品。

第二點，這個領域技術更新特別快，可能前幾個月還領先的模型，沒過多久就被別的模型超越了。這種技術的快速演進，會不斷打破已有的優勢，也就給了新公司更多機會。不像一些壁壘已經建立好的行業，新人很難撼動老大地位。AI Coding 這個方向，恰好是那種「你能解決問題、就能獲得用戶」的地方。

第三，其實所謂的資源優勢，在這個方向里作用挺有限的。你說資金、人力，大公司當然有，但他們投入到這個業務上的資源并沒有我們想象中那么多。像一些大公司，相關項目也就幾十上百號人。再多了，協作成本反而上來了。而反過來，像 Cursor 這種公司，早期也就三十人，市值卻已經很可觀了。所以在這個領域，人多錢多，不一定真的是優勢。

整體看下來，這里問題多、變化快、用戶要求高，又沒有資源碾壓，我們自己其實也沒什么可怕的，反而覺得這是一場很有機會的比賽。

02Coding 之于 SWE，就像壘磚之于建筑設計

Founder Park：AI對 SWE 的影響，長期來看會分成幾個階段？Cursor 也服務專業程序員，它在其中扮演怎樣的角色？

陳志杰：現在大家常拿 Cursor 做對比，Cursor 目前還是在「以人為中心」的 IDE 下的產品形態，也主要是在 coding 環節。

從未來視角看，AI 或 Agent 有可能成為整個研發流程的 Controller 和 Planner，統籌寫代碼、查 bug、code review、測試、持續集成部署等各個環節。因此AI SWE 的一階影響在于，它能以控制器和規劃器的角色滲透到軟件研發生命周期的每個階段—— 目前已有一些跡象，比如讓 Agent 修復 bug 或合并代碼請求，未來必然會在更多環節實現提效。當然不會有一個大招一次性到達那個狀態，一方面是模型能力還不夠，另一方面傳統 workflow 還需要時間改造，可能會逐漸滲透到各個環節，終態會是 Agent 作為 planner+controller，更自主的完成任務。

二階影響則體現在 AI-native 的軟硬件基礎設施的變革上。為適配 AI Agent 的運行，整個 Agent 依賴的 Infra 都會變化。目前已出現面向 Agent 生成后端服務的 Superbase、解決多 Agent 通信的 MCP 協議，以及提供運行沙盒隔離的 E2B 等工具。這意味著我們與 Cursor 等產品并不是直接競爭關系，而是在 SWE 領域中解決不同維度、不同場景的問題，整個行業仍處于非常早期的探索階段。

另外值得注意的是，Cursor、Copilot 等產品目前仍依托 VS Code 這種傳統 IDE 形態發展，但當 Agent 具備持續自主運行數小時的能力時，這種產品形態未必是最優解。未來更可能出現的工作模式是：通過統一的工作控制臺調度多個 Agent—— 它們可能分別負責編寫代碼、執行工作流或修復漏洞，而開發者只需完成任務委托和結果校驗。這種基于多 Agent 協同的工作范式，顯然會突破現有 IDE 的產品框架。

Founder Park：AIIDE 形態只是暫時的解決方案。OpenAI Codex 的負責人也提到，他們很在意 Agent 的運行時間，還提到正確用法是同時跑 20 個任務再去驗收結果。長遠看，用戶與代碼的交互會有更多變化，產品形態也會逐步演進。

陳志杰：對，所以總而言之，我覺得當前態勢是這樣：

第一，軟件工程（SWE）是一個更大的市場，coding 只是其中一環，大家可以在里面解決不同的問題。

第二，Cursor、windsurf 現在的產品形態，也不是一個黃金標桿，因為現在的 IDE 是為人設計的，不是為 agent 設計的。

李一豪：SWE 的未來是在不同的抽象層級解決問題。Cursor 現在也很重要，但它就是在 coding 這個 level 不斷提高智能水平。但是一個工程的完成是高度復雜的，涉及到調度、溝通、安排，是更復雜的問題。未來的產品可能是在一個更 high level 的層面，去統籌、調度所有現有的工具，是一個更整體的系統性工程。

陳志杰：對，剛才咱們討論的其實是一個更長遠的愿景。具體演化到那個階段也是一步一步來的。總之我覺得，我們的方向會更聚焦在：怎么樣讓更大粒度的任務，盡可能自動化地完成，并且結果是可信賴，agent 運行過程是安全。

Founder Park：和過去的 SWE 相比，AI進來以后，它能夠在哪些方面提效或解決問題？

陳志杰：從一些論文中能看到 Google 和 Facebook 都有相關研究。像 Google 曾進行系統升級，涉及 Protocol Buffer 的某個字段升級，而相關代碼可能達百萬行以上，以前靠人工逐個確認、測試，要花費很長時間，甚至好幾年，大部分工程師都覺得這是臟活累活，后來他們結合自身工作流程，讓模型進行修改，晚上運行一整晚，白天人再去檢查、驗收、合并，通過這種方式大大提高了效率。

再如 Facebook 也有類似的工作，用 AI 來提高單元測試的覆蓋率，使整個系統的可測性大幅提升。此外，美國紅杉前兩天采訪 Codex 的案例中提到，他們在發布會前要修復一個 bug，查了很久，最后是 Agent 把 bug 修復了。這里有個很有意思的點，就是工程師真正寫代碼的時間其實不多，大量時間都花在這些臟活累活、事務性工作上，而這些都是 AI 可以逐步幫助提升的。

劉曉春：如果從一個普通人的角度來看，我覺得 AI Coding 和 AI SWE 的關系，其實有點像蓋房子時「壘磚」和「蓋大樓」的區別。

很多人覺得開發軟件就是寫代碼，就像覺得蓋樓就是一塊塊把磚壘上去。但你想想，像東方明珠、SOHO 大廈這樣的建筑，它的核心難道只是磚壘得整齊嗎？肯定不是啊。這里面包括結構設計、材料選型、力學計算、施工流程，每一步都需要很強的專業能力和系統配合。

軟件開發也是一樣。寫代碼只是最基礎的一步，像是在「壘磚」。但如果真的要把一個完整的系統建出來，還要考慮技術選型跟業務匹配不匹配，不同的技術棧怎么協同，工具平臺能不能支持不斷迭代，還要做各種取舍和規劃，這些才是整個工程里最復雜的部分。

AI SWE 想解決的，其實就是這些系統性的問題 —— 就像蓋樓不能只盯著磚塊，軟件開發也不能只盯著代碼行數。它關心的是整個生命周期里的各種環節，從架構設計到持續交付，每一塊都要想清楚、打通，這才是真正的難點，也是最有價值的地方。

李一豪：那你們怎么規劃未來的產品，去設計這套蓋大樓的流程，包括工程圖紙、驗收細節、debug 等等？這個先后順序和重要程度是怎么規劃的？

劉曉春：首先，我們其實是跳出 AI coding 的范疇去思考的。我們更關注的是，做 AI SWE 的最終目標到底是什么？我們的方向，是希望真正對齊軟件工程師和產品經理的任務目標，站在軟件工業的視角去看這個問題。不是為了寫代碼而寫，而是希望 AI 能參與到整個任務的達成過程中，幫大家一起把事情真正做成。

第二個角度是，光有目標還不夠，要達成這個目標，其實需要非常多的工具、平臺和服務配合。那 AI 就不能只會寫代碼，它要能理解工具、調動工具，甚至知道什么時候該用哪個工具。我們現在做的事，跟傳統意義上的 AI coding 最大的區別就在這兒：我們是從「目標出發」，而不是從「代碼出發」。

所以簡單說就是兩點：一方面目標導向，另一方面是具備調動工具和平臺的能力。這兩者加在一起，才有可能讓 AI 真正參與到蓋樓的每一個環節里，而不是只會搬磚。

Founder Park：之前跟志杰溝通，提到過《人月神話》（軟件工程領域的「圣經」），其中的觀點認為，在軟件工程流程中，人力增加反而造成了效率的折損。AISWE 會如何解決這個問題？你們有怎樣的思考？

陳志杰：軟件開發有兩類困難。第一類叫作「固有困難」，它是指軟件開發本身固有的復雜性，比如 Complexity，Conformity，Changeability，Invisibility，《人月神話》認為這一類復雜性是軟件生產的本質屬性，是沒法消除的。

另一類困難就是「人為困難」，也就是說這些問題不是軟件本質導致的，而是由于當前工具、方法或組織方式不完善造成的。包括：溝通和協作能力的問題，看看大公司有多少會議就知道了；進度估計的困難， 軟件開發進度難以準確估算，容易低估所需時間，尤其是后期集成和調試工作量。另外就是特別著名的「人月神話」，布魯克斯最著名的觀點之一：「將一個項目分配給更多的人并不能總是加快進度」，有時還會適得其反，因為增加人手會帶來更高的溝通和協調成本。

過去幾十年，大量的軟件工程進展正是致力于降低這類偶發復雜性。現代 IDE、版本控制系統（如 Git）、測試框架、持續集成工具、容器化部署、甚至 AI 編程助手（如 GitHub Copilot、ChatGPT）等，都是在不斷消除偶發困難，使得開發者可以更多地聚焦于本質部分。

我們舉一個現實中很常見的例子：100 個工程師持續迭代某一個模塊，每周可能都會有幾十次代碼合入。因為是人類在開發，現實的排期壓力（想想業務方 40 米的大刀）等因素下，他們未必會很好的遵循開發規范，長期以往，整個模塊的封裝被完全破壞掉了，這就是所謂代碼屎山的來源，整個系統變得原來越難維護，整個模塊開發效率反而下降。

因為現實世界本質就是復雜的，數字世界是現實世界的映射，所以梳理清楚需求，這一步是必不可少的。但如果未來的工作主力由「人」變成 Agent 后，上面講的「人為困難」應該能大幅緩解了。只要你設定清楚規則，agent 的規范遵循能力未來還是會比人強很多的。另外，agent 之間的「溝通」可能比人之間的溝通要容易點（笑）。

03Cursor 很成功，但也有掣肘

李一豪：其實 Cursor 也在做類似的事情，它在寫代碼維度上，提供快速的 reward 機制，擴充 context，從插件到自己的 IDE，再到理解已有代碼庫。它也在做自己的 MCP，希望拓展可調度的工具空間。這個思路會不會跟你們類似？

劉曉春：現有產品像 Cursor/Windsurf 其實挺成功的，從終極目標來說我們是一致的 —— 都是希望 AI 能夠完成更大粒度的任務，能夠自主規劃、選對工具，最后把事情完整地做出來。

但現在看，這些產品的成功同時成為了他們的包袱：

第一個問題是，他們當前用戶里有不少是傳統或半傳統的工程師，這類用戶習慣了強手動控制，所以 他們 至今還需要花很多精力在編輯器、補全這些底層功能的完善上。

第二是月費制的商業模式其實有點掣肘。現在是月費 20 美元的訂閱，但很多用戶其實是奔著大模型來的，如果要搭 Claude 4 用，算力一上來，成本就有點頂不住了。

第三是堅守專業工程師的定位很有挑戰。它的用戶結構里其實也有不少小白用戶，希望能像 Lovable 或 Bolt 那樣，開箱即用、直接解決問題。所以你看 Cursor 最近上線的 Background Agent，雖然本意是做大任務的自動執行，但放在云端托管后，反而更像是給小白用戶用的，對專業工程師未必有吸引力。

所以我覺得既有產品的成功有兩面性，一方面有先發優勢、有品牌、有用戶；但另一方面，這些「已有的包袱」也確實會限制它在大方向上的推進速度。尤其是在追求「大任務自主完成」這個目標上，可能很多產品選擇會被牽著走，不那么純粹了。

陳志杰：我覺得，Cursor 是從 VScode 這種 IDE 模式下演變過來的，它一開始在搶占用戶心智方面非常好。但在 agent 化的趨勢下可能會受到制約。而我們更多是朝著 「大粒度任務由 agent 自主完成」 的目標邁進，整個產品和技術體系都圍繞這一核心展開。

劉曉春：剛才聽志杰說完，我也想拋一個可能稍微「激進」一點的觀點：我其實覺得，在大粒度任務的自主執行這個方向上，未來的贏家很有可能不是 Cursor/Windsurf。就算不是我們，也很可能不會是它們。

原因其實也挺簡單的。他們現在已經有了不少存量用戶，而且也積累了相當程度的品牌認知，這些反而成了它往前走的束縛。它很難完全跳出來，去專注攻克這個方向。而恰恰這個方向，本身挑戰就很大，需要的專注度也很高，不是說你順帶做一下就能做好的。

所以我們現在是完全圍繞這個目標在做事情，從架構到底層機制，都是奔著這個去的。這點我覺得可能是我們相對更有機會的地方。

Founder Park：解決這個問題的企業或產品應該具備怎樣的素質或能力？當你們去解決這個事情的時候，優勢是什么？

劉曉春：首先我們沒有 Cursor 那種存量包袱，這反而是創業公司的一個天然優勢。沒有那么多歷史負擔，不需要去遷就原來的產品形態或者用戶預期，所以從一開始我們就可以圍繞「大任務的自主運行」這個目標去設計產品、打磨算法。

比如剛才志杰提到的幾個點：我們希望任務起步階段能和用戶對齊得更清楚；我們希望 agent 能在沙盒環境里更安全地自主執行任務，不需要用戶總是點確認。這些都是從目標出發去設計的。我們所有的產品思路和技術路徑，其實都是圍繞這個方向來展開的，也因此能更聚焦、更徹底。

陳志杰：大公司里即便有經驗豐富的高階人才負責，推進起來也較為困難。事務性工作往往會占據他們一半的時間，加上同時負責多個項目，真正能投入到一個項目上精力實則有限。在創業公司，比如說我，基本上 100% 的時間都是在 focus 在這一件事情上面，而且沒有那么多事務性的工作需要處理，我天天琢磨的就是這個事。我覺得這個也是很不一樣的。

劉曉春：另外，從團隊角度來看也有挺明顯的差異。我們之前問過公司里的同學，大家普遍感覺，自己現在的產出效率大概是大廠時期的兩到五倍。

這種變化來自兩個方面：一是像志杰說的，雜事少，注意力更集中；二是我們自己就是一家 AI 產品研發公司，會非常主動地用 AI 來提效。只要有提升空間，我們就會去調整基礎設施，讓大家用得更順手。

現在公司里每個人其實都在同時使用多款 AI coding 工具，還對接了多個賬號，哪個工具體驗好、效率高，就隨時切換。整個組織的運行模式，本身就是圍繞「AI 驅動」來構建的。

Founder Park：用AI更高效率地組織和運轉，能夠去做到原來想象不到的一些事情。

劉曉春：現在很多大廠也在說自己用 AI 提效了，比如提升了 10%、20%。但說實話，我覺得可能很少有人敢說自己提效超過 30%。因為它有各種現實的掣肘——流程復雜、權限繁瑣、組織層級多，AI 再強也很難發揮到極致。

但我們這邊就不太一樣了。我們更像是從零開始去構建一個 AI 原生的組織，這樣 AI 的效率空間能被充分釋放出來。它不是錦上添花，而是變成了整個運轉方式的核心，很多過去覺得「只能靠人做」的事，現在真的可以靠 AI 來解決。

陳志杰：補充一點思考。過去所有的軟件設計原則，其實都是為「人」作為開發者來設計的，為了解決人為的復雜性。比如說，為什么要有函數？為什么要有面向對象？為什么編程語言從匯編一直發展到現在的高級語言？其實都是為了人作為工程師更好的理解和維護代碼而設計的，是為了減少人的認知負擔。

那你想，以 agent 為中心的開發模式下面，會變成什么樣子呢？軟件工程的的原則會變成什么？現在這些軟件工程原則是不是還會不會存在？當這些第一性原則都發生改變的時候，整個領域一定會發生天翻地覆的變化。

04優秀的工程師，未來能帶 100 個 Agent 干活

Founder Park：有觀點認為，針對軟件工程，AI其實并不擅長精確計算的問題，反而非常擅長「模糊」計算的問題，所以理論上它在做架構設計時，應該會比人類更強。你們認同這個觀點嗎？

陳志杰：我理解很多人說的 「架構」 其實指日常業務開發，比如寫前端或后端代碼，而領域術語中的 「架構設計」 門檻其實很高。

其實我覺得應該是反過來，我們可以類比自動駕駛，把 AI SWE 的能力分成幾級。

• L0：完全沒有輔助，控制主體是人，所有工作都是人完成，這是傳統的軟件開發模式。

• L1：控制主體還是人，但是 AI 可以進行一些補全，比如說 Tab 補全、腳手架代碼或一個函數的生成等等。這是 Copilot 最開始的形態。

• L2：局部任務的自動化。工程師負責描述需求、設計方案、交互決策，AI 可以完成多個任務，比如自動生成測試用例、接口設計、fix bug 等等。我覺得現在整個 AI SWE 或者 AI coding 大概屬于 L2 這個階段。

• L3：整個模塊級別的自動化。這個時候 AI 承擔整個模塊的開發和維護，相當于達到一個初級程序員的水平。人類的角色會變成一個軟件的系統設計師。

• L4：能夠達到系統級別實施的水平，也就是高階程序員的水平。它能夠進行技術設計，比如說你的數據庫應該怎么選？你的負載均衡、存儲應該怎么設計等等。我覺得到 L4 這個階段，才是能夠做架構，但它仍然是不能替代創造性的工作。比如說，我前兩天和一個 Infra 的朋友聊，他說，你讓 AI 寫一個 TensorFlow 的算子，它是可以寫出來的，但是你說讓它設計一套 TensorFlow 這種架構，我覺得是絕對不可能做出來的，現在這個階段還差太遠。

• L5：SWE AGI 真正實現。Result-As-a-Service，人類提需求，AI 負責實現。

劉曉春：你看現在一些評測，比如 SWE-bench 上面，其實在涉及架構選型的任務里，AI 的準確率反而比寫代碼還高。這說明它在一些高層次的判斷上，其實是有潛力的。

AI 今天之所以還難以真正做「架構」，一方面是它缺少我們人類架構師腦子里的那些「隱性經驗」——不是那種寫在教材里的通用知識，而是對具體業務、具體場景長期積累下來的判斷力。如果哪天能把這些知識系統性地接入進去，我覺得 AI 未必不能比人做得更好。

陳志杰：如果只是泛泛給出基礎建議，比如負載均衡方式，AI 沒問題。

但真正的 L4 架構能力是指設計并實施整套Infra：線上系統拓撲結構、前后端的實現、模塊設計、接口定義、依賴關系、corner case 處理、部署運維方案，甚至多區域全球服務部署等。這需要針對具體業務定制化設計，而非輸出通用文檔。目前看，這條路還很長。我認為真正的架構師不是只能動嘴的，是能夠動嘴并且能實施的。當然，L4 畢竟是遠期目標，大家只是「開腦洞」探討。

這里需要補充的是，這個類比只是為了形象說明，AI SWE 與無人駕駛有本質區別：無人駕駛領域 L2/L3 技術因為是涉及生命安全的，要是效果不好，可能造成嚴重后果，實際幫助有限；但 AI SWE 每個發展階段都能交付成果，即便 AI 執行出錯，重啟或回滾就能解決。另外，技術路線差異 —— 無人駕駛 L2/L3 與 L4/L5 可能路線不同，但 AI SWE 的技術路線是連貫的，前期能力是后期發展的基礎，每個階段都能交付提效成果，讓工程師聚焦創造性工作，臟活累活由機器承擔。

李一豪：在一級一級升級到 L4 的過程中，現實社會中這個過程可能會怎么樣發生？是不斷有一些中低端的程序員慢慢被替代，更優秀的人可以做更有創造力的架構層面的思考？

陳志杰：我個人認為，在未來相當長的一段時間里，AI 其實都離不開人的結果驗收、需求澄清和中間問題干預。隨著技術發展，機器會逐步承擔更多臟活累活，讓工程師得以聚焦更具創造性的工作 —— 畢竟工程師群體本就善于通過工具創新解決問題，而 AI 本質上也在發揮類似的輔助作用。

AI 在企業中的落地也不是自上而下的強制推行，要是工程師不愿意用，就算是硬性部署也沒用。因此核心在于提供優質的產品體驗，讓用戶在實際使用中感受到效率提升，進而推動團隊從下到上形成共識，最終通過采購實現全公司的效率優化。

長遠來看，或許 10 年后 AGI 真的能實現，那個時候 AI Agent 可能包攬開發、部署、運維等全流程工作。到那時，工作模式可能演變為 「需求溝通者 + AI 執行者」 的組合 —— 專人負責梳理復雜的現實業務需求，agent 按需求輸出最終成果，形成 「Result as a Service」 的形態，這種情況下對工程師的人力需求可能會大幅減少。

劉曉春：我補充一點，其實未來角色的分工可能會越來越清晰，人更多是負責設定目標和驗收結果。

這里面之所以還是需要工程師來做這件事，而不是產品經理，是因為很多目標本身就帶有很強的技術性。比如你要評估系統容量、并發用戶數、帶寬消耗等等，這些都不是拍腦袋能決定的，它們背后都需要有扎實的技術判斷。所以哪怕是「設定目標」，也不是一句話那么簡單，是需要理解整個系統邊界的工程判斷。

這其實挺像現代流水線的邏輯 —— 工人只需要在機器上設定要生產什么零件，機器就能自動把它做出來，人只要監控過程、最后驗收產品就行。未來 AI 在軟件工程里的角色，可能也會是類似的。

但這里還有個很現實的問題，就是「兜底」。現在很多 AI 已經可以把事情做到 90%、甚至 95%，但那最后 5% 通常才是最難搞的。如果這個尾巴太難，初級工程師可能兜不住，那就必須得是更資深的工程師來兜底。

這就產生了一個有趣的現象：看上去 AI 替代的是「人」，但真正被替代得最快的，可能是那些純做底層實現、不參與技術決策的初級工程師。相反，AI 對高階工程師來說，反而是一個「倍增器」，讓他們效率更高、覆蓋面更廣。

陳志杰：對，中短期里面可以想象成一個工程師帶 5 個或 10 個 Agent 去干活。對我們工程師來講，我更愿意干有創造力的工作，我不喜歡修 bug，寫文檔，我喜歡去設計系統，喜歡做有挑戰的事情。當你帶 5 個、10 個 agent 干活的時候，可以把那些工作交給 agent，你更專注于讓自己獲得技術成長、做更有挑戰性和創造力的工作。這對工程師個人和對整個公司都是非常有價值的。

劉曉春：以前有些工程師會覺得「我帶了多少人」是一種成就感。將來可能不是這樣了，真正厲害的工程師，不是帶了多少人，而是能帶 100 個 agent 去并行干活。

因為你能協調的 agent 越多、組織效率越高，你的生產力就越強。這才是未來工程師真正「牛 X」的方式。

陳志杰：衡量一個最優秀的工程師，永遠不是說 ta 敲了多少代碼，而是 ta 解決問題的能力，這個才是工程師的核心。

李一豪：我們觀察到新一代的創始人，對技術的理解很深，使得產品解題思路跟過去的互聯網很不一樣。大家都在關注針對模型、模型之間的串聯調度、有效的 context、reward 等等。你們在探索過程中有相似的感受嗎？

陳志杰：我天然感覺，落地一個產品是個系統工程，不是靠一個單一模型或產品外殼所能支撐。比如說 Google，它是一個產品，但它后面其實有非常復雜的一套系統，包括眾多模型和算法策略。廣告或推薦系統看似只輸出幾條結果，實際上是上百個模型、策略與數據交織的產物。

所以我覺得我們做這件事情也是一樣的，可能每個維度上都需要去做到極致。

• 產品上，我們需要去了解用戶的真實需求痛點和 workflow，設計出很好的產品體驗。

• Infra 方面，為了讓 agent 運行得好，要提供很多外圍的基礎設施，比如很好的沙盒隔離系統、服務發現機制、工具調用。

• 算法方面，用戶行為數據的反饋是非常有幫助的。那么算法上，未來的一個發展方向應該也是更端到端的 agent learning，也就是說用戶的反饋數據會進入到訓練模型里面。當然，這里的模型可能不單純只有一個大模型，還有很多外圍的其他模型。

總而言之，它是一個系統工程。

05開會少了，干活多了，特別爽

Founder Park：兩位都在大廠做了很多年，為什么決定出來創業呢？

陳志杰：我從學校開始做自然語言處理， 2010 年畢業后加入百度鳳巢從事廣告算法工作。2019 年之后出去到另一家公司待了一年半，然后去了字節，開始做推薦算法。

劉曉春：我 2011 年加入百度鳳巢，和志杰是一路打拼過來的「老同事」。我自己差不多有 14 年的互聯網經驗，除了中間有兩年出來創業，大多數時間都在百度工作。

創業原因挺簡單的：

一方面是心里那股勁兒沒消——看到很多鳳巢的同事朋友都陸續出來創業了，自己也難免會想，不試試看，可能以后會后悔。

另一方面是從行業本身出發吧，我們長期都在 AI 領域工作，上一次移動互聯網浪潮其實就有創業的想法，我自己也確實嘗試過，但不算太成功。這一次 AI 的發展機會又擺在眼前，我們倆人想了想，如果現在都不行動，那還等什么時候呢？所以決定還是全身心投入，認真試一次。

Founder Park：我其實還挺好奇一點，去實現這樣一個比較長期的愿景，到那一天，言創萬物會是一個很龐大的組織嗎？還是說，像你剛提到 Cursor，也就 30 多人就能做出很不錯的成績。

陳志杰：不會很龐大。我們現在團隊也就 30 來人，我覺得今年不會超過 40 人。你看那些 foundation model 的團隊，他們的核心團隊其實人也都很少，也就幾十人這樣的規模。

劉曉春：多其實不是我們的目標。對我們來說，更重要的是把事情做成，而且是在成本可控、風險可控的前提下做成。組織龐大不一定代表效率或者成果，關鍵還是看能不能把復雜的事情做扎實、做漂亮。

Founder Park：你們接下來的產品節奏是怎樣的？

陳志杰：我們正在優化第一版產品，可以期待下。大家老是調侃說做應用是「套殼」，但其實 AI SWE 真的是一個非常非常復雜的業務。舉個例子，光我們開發那個 MVP 版本，現在前端后端代碼就已經差不多 10 萬多行了。

Founder Park：哪怕MVP都是一個非常復雜的產品。

陳志杰：是，你要考慮很多很多的邊界條件和各種情況下的處理，挺復雜的。

Founder Park：創業半年來感受如何？

陳志杰：我感覺挺爽的。我比較喜歡自由。之前不了解的時候會覺得創業很焦慮，包括我創業之前也會對未來會很焦慮。但是，至少到目前為止的話挺爽的，我沒怎么焦慮過。

Founder Park：現在的團隊日常工作風格，跟之前你們在大廠會有什么區別？

陳志杰：我最大的感受就是會特別少，特別爽。之前的話可能一天至少一半的時間要開會。我是一個特別內向的人，照相都是往邊上站那種。現在會少了很多，效率也高了很多。我們團隊絕大部分人一天不會超過兩個會議，效率自然而然就高非常多。

劉曉春：你覺得你得到你想要的自由了嗎？

陳志杰：得到了，哈哈哈，我不想開會。

現在團隊確實是一個特別精干的團隊，絕大部分人也都是工程師。我們 30 人多人，除了兩個產品經理、一個 UG 和兩個職能的同學，剩下都是工程師。

劉曉春：我們現在這個團隊，雖然規模不大，但整體的能力和配合度都挺讓我安心的。每個人都很專注，也都愿意深挖問題、解決問題，這種氛圍對一個創業團隊來說其實挺難得的。

有些人可能覺得創業公司招人會比較困難，但我們確實還挺幸運的，團隊里很多同事之前都有很扎實的實戰經驗，也愿意放下已有的穩定狀態，來做這樣一件挑戰性比較高的事。我覺得這本身就已經非常寶貴了。

像志杰，能從原本資源很好的環境里走出來，一起來創業，我心里其實特別佩服。他不是為了所謂「更好」的 title，而是真的相信這個方向值得做。我們能走在一起，更多是因為對事情的判斷一致。我也更相信，只要我們認真、一點點往前推進，它一定是能做出真正價值的。

陳志杰：這個就……我就是一個普通工程師，低調做人，我就是很喜歡技術。

轉載原創文章請添加微信：founderparker