AI Coding大有可為，但Vibe Coding還是先洗洗睡吧

在正文開始之前，先說一個結(jié)論：AI Coding 和 Vibe Coding 不是一回事。AI Coding 大有可為，但 Vibe Coding 勸你先冷靜。前者面向?qū)I(yè)開發(fā)者，后者面向非專業(yè)開發(fā)者。

近期，有非常多所謂 “ Vibe Coding 奇跡 ” 出現(xiàn)。

不論是曾經(jīng)的 AI 懷疑論者、Rust 大牛 Steve Klabnik 用 AI 寫出新的編程語言 Rue，還是對 AI 敵意頗大、曾嘲諷 “ AI 編程是垃圾 ” 的 Linux 發(fā)明者 Linus Torvalds 親自下場 Vibe Coding。甚至近期有不少 Vibe Coding 出來的 ToC App 或網(wǎng)頁游戲一夜爆火，被切中痛點的用戶還相當(dāng)愿意買單。

AI 編程產(chǎn)品王者 Claude Code 也頻創(chuàng)神話，比如 1 小時復(fù)現(xiàn) Gemini API 負責(zé)人 Jaana Dogan 的團隊花費一年構(gòu)思的分布式 Agent 編排器，10 天復(fù)刻 “ Manus ” 也就是 Cowork 。

Redis 作者 Antirez 近期坦言道，大部分項目不再需要寫代碼了，除非是為了興趣或好玩。

隨著 Anthropic 等廠商不斷完善編程工具套件，比如 Code Simplifier 等，代碼編寫階段的難度也將變得越來越低。

越來越強大的 AI 編程工具甚至讓曾提供原始養(yǎng)料即 “ 代碼數(shù)據(jù) ” 的廠商變得越來越難過，比如讓 Stack Overflow 流量 “ 一夜回到剛發(fā)布 ”，比如 AI 讓 TailWind 使用量越來越大，卻讓發(fā)明者本人 Adam Wathan 的公司越來越難賺錢，被迫大幅裁員。

但實際上，大部分人關(guān)注到表面的喧囂，而沒有關(guān)注到一個極其重要的點——代碼復(fù)雜度。

那些復(fù)雜度很高的 Vibe Coding 產(chǎn)品，背后都有專業(yè)的工程師兜底和指引。那些復(fù)雜度很低又很火的 Vibe Coding 產(chǎn)品，幾乎秒被抄襲，且存在大量缺陷，比如可維護性、可擴展性、安全風(fēng)險等。

專業(yè)程序員也都會時刻強調(diào)，寫代碼一直是開發(fā)中最不重要的一步，決定代碼質(zhì)量上限的是 AI 尚不具備的深層業(yè)務(wù)理解和復(fù)雜架構(gòu)設(shè)計能力。

甚至近期 Cursor 讓 GPT-5.2 連續(xù)運行 7 天寫出的數(shù)百萬行代碼的 Chrome 項目，最終被社區(qū)發(fā)現(xiàn)只是無法運行、無法修復(fù)、無法復(fù)現(xiàn)的 “ AI 泔水 ”，連被稱為 “ 屎山代碼 ” 的資格都沒有，體現(xiàn)出復(fù)雜度提升給 AI 帶來的壓力。

確實當(dāng)下 AI 能驗證可行的場景并不多，編程場景整體已經(jīng)算樂觀的了。Replit CEO Amjad Masad 前一陣子還坦言，現(xiàn)在真正能賺錢的 Agent 只有兩類，一類是 AI 客服，另一類是 AI 編程。

所以 AI 編程為何可行，天花板又在哪里？AI Coding 和 Vibe Coding 可行性判斷的底層邏輯是什么？為解答這些問題，知危與多名業(yè)內(nèi)專家進行了交流。

整體來看，專家們對 AI Coding 保持樂觀，對 Vibe Coding 的當(dāng)下表示質(zhì)疑。但專家們沒有否定 Vibe Coding 這個目標的長期合理性，只是我們需要清楚，Vibe Coding 目前只是資本市場的 “ AGI 愿景 ” 下的產(chǎn)物，和 “ 通用 Agent ” 概念一樣，有被過度炒作的風(fēng)險。

認清現(xiàn)狀，并解答如何以更理性的方式逐步達到 “ Vibe Coding ” 這個理想的結(jié)局，才是本次探討的目標。這不僅適用于 Coding Agent 產(chǎn)品創(chuàng)業(yè)者和軟件產(chǎn)品創(chuàng)業(yè)者，也適用于當(dāng)下最焦慮的程序員。

本文有以下 9 個章節(jié)，您可按需觀看：

• 什么是 AI Coding 和 Vibe Coding？
• 對 AI Coding 樂觀的本質(zhì)
• 對 Vibe Coding 悲觀的本質(zhì)
• 國內(nèi)外差距依然存在
• 關(guān)鍵落地場景：舊代碼重構(gòu)
• 對傳統(tǒng) SaaS 市場的沖擊
• AI Coding 對程序員的影響
• 與 AI 協(xié)作之道
• 展望未來

在正式進入討論前，還是要先把概念徹底理清楚。

平安保險技術(shù)平臺組負責(zé)人張森森對知危表示，“從概念上來說，AI Coding 就是開發(fā)者利用大模型語言輔助開發(fā)軟件，主要涵蓋：代碼編寫、代碼調(diào)試、代碼重構(gòu)、測試過程等，目前最典型的工具其實還是 GitHub Copilot。” “這其中最重要的是，整個開發(fā)流程基本上還是由系統(tǒng)的架構(gòu)師和負責(zé)人主導(dǎo)。AI 扮演的角色，如果按照敏捷研發(fā)的角度，更多是一個 ‘ 角色程序員 ’。AI Coding 的核心工作目標，還是針對工程效率的提升。” “到了 Vibe Coding 這個層面，有了新的變化。過去是人去適應(yīng)代碼，但 Vibe Coding 提倡的是 ‘ 擁抱這種指數(shù)級增長 ’，甚至可以完全忘記代碼的存在。它的基本邏輯是：程序員要適應(yīng)這種 ‘ Vibe（ 氛圍 ）’，通過感性和直覺去驅(qū)動開發(fā)。在這個模式下，用戶大部分是非專業(yè)開發(fā)者，當(dāng)然不能簡單地稱之為 ‘ 小白 ’，他們更多是業(yè)務(wù)人員、產(chǎn)品經(jīng)理或非技術(shù)背景的從業(yè)者在承擔(dān)開發(fā)角色。”

“Vibe Coding 重點強調(diào)通過 ‘ 自然語言描述意圖 ’ 來完成開發(fā)，讓 AI 實現(xiàn)端到端的代碼生成，比如從理解需求到 UI 設(shè)計，從前端代碼生成到后端數(shù)據(jù)庫連接，甚至包括最后的部署工作。”

可以理解為，知危與各位專家在本文中定義的 “ AI Coding ” 和 2 月 5 日 Andrej Karpathy 回顧 Vibe Coding 一周年時提到的Agentic Engineering意思相近。

在 GitMe.ai 聯(lián)合創(chuàng)始人王威看來，以Claude Code、Cursor等產(chǎn)品為代表的AI Coding方向，并不存在泡沫，他向知危表示：“ 原因是，業(yè)界對于未來 AI 的發(fā)展、AI 技術(shù)加持下的軟件交付和研發(fā)最終形態(tài)仍然沒有達成共識。”

“ 同時，雖然目前 AI 的迭代速度可能沒有 2022、2023 年那么快，但在 AI 編程賽道里，迭代速度仍然比較快。無論是 OpenAI、Anthropic 還是 Anysphere（ Cursor 所屬公司 ），每個月至少會有一兩個對市場有吸引力或者沖擊力的產(chǎn)品發(fā)布。”

“ 既然技術(shù)還在持續(xù)迭代，意味著用戶體驗仍然不穩(wěn)定，也就是說用戶在 AI 上的工作流程還沒有共識，還需要探索。探索階段沒有泡沫。”

“ 如果資本都注意到這個賽道，都愿意投資，可能會讓賽道略微喧囂，這是難免的。”

“倒退五年，當(dāng)時對于軟件工程，大家的共識是 ‘ DevOps 一定是行業(yè)未來 ’，而且 DevOps 是可以講清楚的：從組織協(xié)作到 CI/CD 流水線，再到具體工程實踐，都有體系化描述。而今天 AI Coding 沒有這樣的體系化描述，因此我不認為市場需求遠小于創(chuàng)業(yè)公司和資本的投入，整個市場空間仍然很大。”

相對地，對于以 Lovable、Bolt.New 等產(chǎn)品為代表的主打 ‘ 一句話生成可用網(wǎng)站 ’ 的 Vibe Coding 方向，張森森并不看好，“Vibe Coding 的端到端特性，說明它更多想通過略過技術(shù)層，提升創(chuàng)新速度，加速從想法到成品的轉(zhuǎn)化。所以Vibe Coding 其實真正在推動的是全民研發(fā)，這是國外非常常見的概念，即讓非專業(yè)背景的人也能參與研發(fā)。”

“ 但是 Vibe Coding 在實踐中存在一個核心問題，它完全依賴自然語言驅(qū)動，并且是端到端生成的，這必然導(dǎo)致中間的很多生成環(huán)節(jié)具有高度的不可確定性。一旦程序復(fù)雜度一上去，且需要長期維護，這種模式的弊端就會顯現(xiàn)。”

“用戶無法對系統(tǒng)進行非常確定性的校驗或掌控，系統(tǒng)非常脆弱，充滿各種漏洞，從而不可維護。所以我不是特別看好 Vibe Coding 方向，這類軟件本質(zhì)上就是即用即棄的一次性軟件。” 創(chuàng)新偏好和產(chǎn)出即用即棄的特點，分別表明了 Vibe Coding 產(chǎn)品的需求剛性和用戶持續(xù)付費意愿都是存疑的。

在效率提升方面，AI Coding 的使用體驗確實是驚人的，王威分享了很具體的例子，“最驚艷的點是它能夠完成新項目的快速啟動。原來新項目的快速啟動是很耗時的。比如我們過去做一個可交互原型需要一個四人團隊兩周的時間，相當(dāng)于 40 人天，成本是很高的。”

“ 現(xiàn)在情況完全不同，AI 工具的月費可能只有 10 美金、20 美金，可能只需要花 5 分鐘甚至更少時間就能完成這個工作。提升如此明顯，以至于我們都認為這已經(jīng)不能稱為效率提升，而是完全顛覆了原來的工作方式。這意味著我們對人、流程、組織都需要重新做反復(fù)的思考。”

比如在人和流程這些方面，AI 編程對于促進團隊協(xié)作也能提供幫助，OneHouse Hudi Flink 負責(zé)人陳玉兆向知危表示，“ 比如代碼分析這一塊，尤其是對于新手或剛?cè)胄械膽?yīng)屆生。如果是過去，面對復(fù)雜項目時，需要一行行跟新同學(xué)解釋代碼是干嘛的，其實挺花時間的。如果現(xiàn)在有 AI 的幫忙，能讓新同學(xué)快速融入團隊，并且對代碼有更深入的了解。”

“ 另外，在編程過程中，像 Cursor 有代碼提示功能，可以讓團隊保持比較固定的代碼風(fēng)格。如果不斷告訴它團隊趨向于用什么樣的風(fēng)格，那么代碼風(fēng)格層面也會更加統(tǒng)一。”

“ 最后，在測試這一塊，現(xiàn)在 AI 寫測試的能力挺強的。Cursor 和 Claude Code 在這方面已經(jīng)比較成熟。復(fù)雜的端到端可能比較難，但是對于基礎(chǔ)類的、帶 Mock 上下文的那種單元測試，是沒有問題的。我們甚至還在用國內(nèi)阿里的通義千問來生成測試集，只需要簡單改一下，基本上就可以直接去提 PR 了。”

“ 單元測試的代碼生成確實能節(jié)省很多 ‘ 苦活、臟活、累活 ’ 的時間，讓大家用來干別的事情。原來那種單元測試，要么是有同學(xué)懶得寫，要么是寫得不夠充分。現(xiàn)在有了 AI 工具，大家下意識地都會先用 AI 生成一遍，所以測試內(nèi)容寫得更加豐富。”

Claude Code 曾經(jīng)分享過 13 個使用技巧，其中之一是 “ 給 Claude 一種驗證工作的方式，最終結(jié)果質(zhì)量能提升 2-3 倍。” 現(xiàn)在這個質(zhì)量提升機制甚至能由模型自己完成，效率提升幅度也很大，“ 在寫測試這一塊，大概幫我們節(jié)省了 30% 到 40% 左右的時間。”

專業(yè)的軟件開發(fā)不會滿足于完成一個可行的原型或較為簡單的測試場景，最終的目的是將原型重構(gòu)為企業(yè)級、生產(chǎn)級代碼，AI Coding 在這一塊也展現(xiàn)出了很強的執(zhí)行水平和協(xié)同能力。

陳玉兆表示，“ 代碼重構(gòu)主要是為了提升可用性和擴展性（ 比如當(dāng)用戶從 10 萬增長到 100 萬，需要相應(yīng)提升系統(tǒng)容量 ）而進行的重構(gòu)。Claude Code確實比較擅長代碼重構(gòu)。但要做好這一步，需要一個非常好的輸入和交互過程。”

“ 比如需要提供團隊積累了十幾年的代碼風(fēng)格偏好，再給予足夠的上下文參考后，它會很好地幫你進行重構(gòu)。但這個過程必須經(jīng)過 Review。比如它會在 GitHub 上提 PR，由你來 Review，這樣 Review 的粒度就會很細致。對每一個 PR，只有當(dāng)你告訴它 ‘ OK，可以合并 ’ 時，它才會執(zhí)行，而不是無腦地直接把整個代碼庫全部替換掉，是一個受控的過程。它相當(dāng)于是一個程序員在和你溝通、協(xié)作。” “ 甚至你可以嘗試讓AI先寫一些樣例代碼，然后告訴它哪里符合預(yù)期、哪里不符合預(yù)期。”

“ 通過這種不斷的溝通和調(diào)整過程來積累上下文，可以逐漸地調(diào)教AI到你想要的樣子。如果調(diào)教得比較好，除了代碼分析之外，代碼重構(gòu)應(yīng)該是 Claude Code 非常突出的一個能力。”

作為專業(yè)的開發(fā)者，能非常清晰感受到 AI Coding 過程中，AI 模型本身的上限，比如單次獨立執(zhí)行任務(wù)的復(fù)雜度上限，對新增功能的理解能力，以及更廣義上的 Context 理解能力，這些感知也是開發(fā)者把控何時接手、如何接手的標尺。

比如在代碼重構(gòu)場景下，通常涉及的項目規(guī)模會很龐大，那么AI模型目前的單次獨立執(zhí)行復(fù)雜度上限是什么？

陳玉兆表示，“ 復(fù)雜度不能按整個倉庫的代碼行數(shù)來評估，重構(gòu)應(yīng)該是按功能模塊為單位的。即使項目有 100 萬行，也可以切分成 10 個 10 萬行的模塊，甚至更細。項目越大，代碼文件間的引用和依賴關(guān)系就越像樹狀或圖狀，AI 工具會自行分析重構(gòu)功能覆蓋了哪些類及其復(fù)雜度。”

“AI 最擅長的重構(gòu)場景包括：基礎(chǔ)邏輯轉(zhuǎn)換，比如重命名、代碼風(fēng)格變換；跨語言重構(gòu)，比如從 Java 切換到 Python，或者從 Scala 切換到 Java，這種邏輯對等的跨語言實現(xiàn)是 AI 最擅長的事情；還有一種技巧是漸進式重構(gòu)，可以先嘗試讓它重構(gòu)一個文件，通過 ‘ 調(diào)教 ’ 讓它符合預(yù)期，再讓它按同樣的方式處理剩下的文件。”

“ 只要 Scope（ 作用域 ）足夠小，邏輯沒那么復(fù)雜，但需要投入大量精力去手動處理的事情，AI 表現(xiàn)得非常出色，能節(jié)省很多時間。”

“AI 難以處理的重構(gòu)場景包括：高耦合核心邏輯，比如存儲引擎的內(nèi)核代碼，邏輯千絲萬縷，‘ 剪不斷理還亂 ’；帶大量 ‘ 補丁 ’ 的邊緣場景，如果核心功能上下游依賴非常多，且有很多歷史遺留的邊緣 Case，打了很多補丁，重構(gòu)時必須非常仔細地 Review，小心這些補丁被 AI 忽略或重構(gòu)掉。”

“ 如果要更加精確、量化地描述，從模塊間依賴角度，比如覆蓋了四五十個模塊、兩百多個文件的這種代碼規(guī)模，尤其如果邏輯本身非常復(fù)雜，邊邊角角的邏輯又多，這種重構(gòu)就很難了，還是需要人來主導(dǎo)完成。”

基于金融業(yè)務(wù)場景，張森森提供了另一個層面的描述，“關(guān)于代碼復(fù)雜度的量化，可以根據(jù)項目的規(guī)模和業(yè)務(wù)深度來看 AI 的勝任可能性。Demo 級別基本上所有的 AI 都能勝任，成功率可以達到 95% - 99%。中型/獨立項目（ 如企業(yè)內(nèi)部小工具 ）AI 的表現(xiàn)依然不錯，勝任率大概在 70% - 80% 左右。復(fù)雜業(yè)務(wù)系統(tǒng)（ 如涉及微服務(wù)、支付、鑒權(quán)、高并發(fā)系統(tǒng) ），這種情況下，AI 基本上只能做一些代碼補全。指望它通過理解來幫你完成代碼生成是不太現(xiàn)實的，勝任率最高可能只有 40% - 50% 。極高復(fù)雜度場景（ 如銀行系統(tǒng)重構(gòu) ），這種系統(tǒng)的代碼非常脆弱，任何微小的改動都可能引發(fā)無法接受的后果，重構(gòu)需要 ‘ 手術(shù)刀式 ’ 的精細化操作，AI 的勝任率非常低，估計最多只有 20%。”

相對于代碼重構(gòu)主要面向舊代碼的處理，新增功能則需要添加大量新的業(yè)務(wù)邏輯。

陳玉兆明確表示，“ AI并不擅長開發(fā)新功能。我們開發(fā)新功能都沒有用過 AI。”

“ 因為開發(fā)新功能的邏輯更加復(fù)雜。作為高級工程師或資深工程師，我們都要耗費很長時間。首先是立項一個 Idea，然后大家出初始方案，進行一輪輪的討論。我們需要權(quán)衡 A、B、C 好幾種方案，分析每種方案的優(yōu)勢和缺點。最后拍板決定選哪種方案，定下基本的架構(gòu)框架和接口（ API ）長什么樣子。寫代碼只是最后一步。這么復(fù)雜的決策和設(shè)計過程， AI 是 Cover 不了的。”

“ 它無法完成這個過程，因為需要的上下文不僅多，也很難從工程師思維中顯式地提取。決策的過程非常復(fù)雜，高度依賴工程師本身的技術(shù)敏感度和經(jīng)驗，比如在進行技術(shù)選型時，工程師會有很多的權(quán)衡，AI 目前還沒有辦法完全像人一樣去思考，也不具備人類那種長年累月積累的經(jīng)驗和敏感性。”

即便隱性上下文能提取出來，如果規(guī)模太大，目前的模型大概率也承載不下，張森森表示，“ Cursor 目前采用 RAG 來緩解這個問題，但業(yè)內(nèi)其實還沒有針對長上下文完全完美的解決方案。雖然像 Gemini 這樣的模型正在嘗試通過不斷擴大上下文長度來解決，但長度終歸是有上限的。在早期，Cursor 的對話進行到 10 輪左右，邏輯就開始出現(xiàn)偏差，目前國內(nèi)大部分 AI 編程軟件基本也處于這個水平。”

“ 不過，隨著 Claude 或 Gemini 的長上下文能力的提升，這個問題正在逐步改善。未來，我們只能期盼大模型技術(shù)對 Token 容量支持的進一步發(fā)展，從底層技術(shù)層面來徹底解決細節(jié)遺忘的問題。”

Vibe Coding 的產(chǎn)出基本都是一次性軟件，但也不代表這個方向的所有產(chǎn)品都一無是處，其中 Lovable 是比較受到認可的。

張森森表示，“ Lovable 相比 Cursor 有一些創(chuàng)新，比如它能實時地把業(yè)務(wù)界面跑給用戶看，讓用戶看到即時的效果。生成完成后，用戶還可以用 UI 交互的方式直接在界面上進行框選，指出具體的問題在哪里，并直接教 AI 怎么去修改。”

盡管有這些亮點，但 Lovable 也避免不了 Vibe Coding 天生的問題，“ 它的代碼維護性極差，基本上產(chǎn)生的都是 ‘ 屎山代碼 ’。比如到第十輪生成時，把第一輪的一個底層邏輯搞壞了，之后就根本無法進行有效的 Debug。”

“ 在產(chǎn)品開發(fā)上，普通的 Dashboard 落地確實非常快，一旦涉及到復(fù)雜算力、高并發(fā)處理、特殊硬件交互，或者是非常精細的動畫邏輯，Web 開發(fā)就顯得很吃力。對于具有復(fù)雜跳轉(zhuǎn)和狀態(tài)關(guān)聯(lián)的邏輯（ 例如：從點 A 跳到 B、C、D，且 D 與 A 之間存在邏輯閉環(huán)，需保證特定狀態(tài)同步 ），目前市面上沒有一個產(chǎn)品做得好。”

“ 雖然 Claude 算是不錯的，Gemini 最近的前端表現(xiàn)也讓人感到 Surprise。但如果要處理復(fù)雜的工程項目，指望用 Vibe Coding 來搞簡直是天方夜譚。”

“ 所以 Lovable 再優(yōu)秀，做的也仍然是一次性工程的生成。”

盡管 Vibe Coding 有如此大的限制，但類似產(chǎn)品依然層出不窮，更廣義來看，“ 一句話生成 ” 或 “ 端到端 ” 的 AI 產(chǎn)品頻繁在社交媒體上爆火、號稱數(shù)千萬甚至上億美元估值，這背后的底層邏輯是什么？

張森森表示，“ 對于 Vibe Coding 的應(yīng)用邊界，我的建議非常明確：如果一定要用 Lovable 去做一個復(fù)雜的項目，我建議立即 ‘ 停手 ’。”

“ 但資本市場的思考邏輯完全不同。資本市場看重的是 ‘ 端到端 ’ 的愿景。在投資者眼中，這是未來必須發(fā)展的方向。就像現(xiàn)在大家談?wù)摯竽Ｐ蜁r，已經(jīng)不再只談?wù)撃Ｐ捅旧恚侵苯又赶?AGI。資本市場對 AI 的熱望已經(jīng)上升到了全新的層面，投資邏輯早已超越了簡單的代碼補全，到了讓 ‘ 具身智能 ’ 滿世界飛、滿世界跑的層面了。”

“ 所以，從資本角度來看，Lovable（ 或同類 Vibe Coding 產(chǎn)品 ）的邏輯是一定成立的，這代表了未來。”

“ 但它能不能活到資本實現(xiàn)宏大目標的那一天，全看它自己的造化。”

“ 相比之下，Cursor、Windsurf 以及一些新興的集成開發(fā)工具（ 如 Google Antigrativity ），生存邏輯就很務(wù)實，他們也認同 Lovable 的端到端邏輯是長遠趨勢，但為了 ‘ 當(dāng)下能活下去 ’，為了適配現(xiàn)有的技術(shù)實踐，他們選擇了超級編輯器這種模式。”

“ 在專業(yè)工程師眼里，那些 Vibe Coding 產(chǎn)品東西更像是個玩具，但資本愿意買賬。”

“因此，我預(yù)計 Cursor 目前的營收能力一定會遠強于 Lovable。Cursor 面向的是實實在在的開發(fā)者，是在為能創(chuàng)造價值的生產(chǎn)力過程做增值。 Lovable 這類產(chǎn)品的邏輯完全不同，它主要收割資本、股民、想走捷徑的小白用戶。”

“ 當(dāng)然，在這場資本游戲中，投資人也不一定會是 ‘ 倒霉 ’ 的那一個，關(guān)鍵看誰在玩這出‘擊鼓傳花’的游戲。投資人可能也根本不在乎這個事（ 產(chǎn)品能不能最終落地 ），他們只要是第一個把這個故事推出來、講得很明白的人就行。只要確保自己不是最后一個接棒的人，他們就能在泡沫破裂前成功套現(xiàn)退出。”

“和創(chuàng)業(yè)者一樣，投資人也在賭，賭自己投的方向能夠隨著技術(shù)的快速迭代，最終把那些現(xiàn)在聽起來不可思議甚至是純粹 ‘ 做夢 ’ 的故事，轉(zhuǎn)化為真實的生產(chǎn)力。”

“ 而之所以這個游戲能玩下去，也是因為現(xiàn)在 AI 技術(shù)發(fā)展的速度確實已經(jīng)基本上超過了想象。”

在理清 AI Coding 和 Vibe Coding 在工程和資本層面的本質(zhì)之后，也要了解到，當(dāng)前國內(nèi)外 AI Coding 的差距仍然客觀存在。

某大型金融科技公司 AI 技術(shù)專家李楠（ 化名 ）向知危表示，“目前國內(nèi)大廠的 Coding Agent 產(chǎn)品整體表現(xiàn)都不太行，大家都在努力做一個國外產(chǎn)品的 ‘ 平替 ’。比如做 Claude Code 或 Cursor 的國內(nèi)替代版本。”

“目前還沒有看到哪家公司能真正從行業(yè)邏輯或者從編程范式發(fā)展的深度，提出比較有創(chuàng)新性的見解。當(dāng)然這跟底層模型的理解與能力有直接關(guān)系。”

“ 國內(nèi) AI 編程模型雖然跑分上表現(xiàn)得很好，隨時跑到 SOTA 水平，但其實有一個限制使得最后要達到天花板是非常吃力的，因為大部分國產(chǎn)大模型公司十之有九做的都是蒸餾模型，他們自己有沒有能力去做訓(xùn)練數(shù)據(jù)呢？其實很困難。”

“困難不在于技術(shù)，大模型在技術(shù)上是沒有秘密的，而在于硬件的匱乏，工程整合能力可能稍微弱一些，以及訓(xùn)練數(shù)據(jù)沒有國外豐富。我們雖然也有碼云這樣的平臺做代碼管理和存儲，但里面高質(zhì)量的代碼還是非常少的，比不上 GitHub。”

近年來，國內(nèi)大廠也紛紛推出自己的 AI Coding 產(chǎn)品，產(chǎn)品結(jié)構(gòu)和 Cursor 等 AI IDE 都是類似的，面向全球市場，可以使用國內(nèi)外的開源、閉源大模型，“ 國內(nèi)大廠紛紛發(fā)力 AI Coding 海外版產(chǎn)品，背后的邏輯非常現(xiàn)實：付費意愿。海外用戶（ 尤其是歐美市場 ）已經(jīng)培養(yǎng)了良好的 SaaS 付費習(xí)慣，出海是實現(xiàn)商業(yè)變現(xiàn)的 ‘ 捷徑 ’。更何況，在海外市場，這些產(chǎn)品可以無縫套用 GPT-5 或Gemini 等國際頂尖模型。”

“我親自試用了國內(nèi)某大廠的 AI Coding 產(chǎn)品，整體評價是 ‘ 還行 ’。目前該產(chǎn)品還處于免費階段，即便要訂閱也比 Cursor 更便宜。我在其海外版官方 Discord 社區(qū)觀察到，外國人的使用者非常多，很多外國人也不想花錢訂閱 Cursor。”

“ 即便調(diào)用的模型是一樣的，從結(jié)果來看，至少我用 Cursor 寫的代碼，質(zhì)量會比這個產(chǎn)品高非常多。雖然它被視為 Cursor 的免費平替，但兩者的差距非常明顯。”

“ 具體而言，Cursor 比較厲害的點在于它更傾向于對研發(fā)行為的預(yù)測，它通過閱讀代碼，能大概預(yù)知你下一步要做什么。而這個產(chǎn)品更像是 Lovable 和 Cursor 的中間態(tài)，兩者在上下文管理上的差距很明顯。Cursor 的索引管理技術(shù)非常成熟，加上基于 RAG 的代碼庫檢索，能讓開發(fā)者遵循一定的 I/O 行為規(guī)則，使得它在處理超大型規(guī)模代碼時，速度快很多。相比之下，這個產(chǎn)品目前在處理超大項目時不如 Cursor 快。”

“ 總體來看，這個產(chǎn)品還是更傾向于全自動、端到端地完成所有任務(wù)，實際上更接近 Lovable 的定位。甚至可以說，國內(nèi)大廠的 AI Coding 產(chǎn)品，本質(zhì)上也是在面向未來的資本方收割市場，偏向 Vibe Coding，而不是 AI Coding。”

“但其實最終繞不開的，還是數(shù)據(jù)安全問題。這雖然是全球性的問題，比如 Cursor 在應(yīng)用內(nèi)直接提供了隱私選項，可以保證代碼不存儲在云端，也不作為訓(xùn)練數(shù)據(jù)。而國內(nèi)的情況有所不同。”

“ 為什么國內(nèi)公司不太愿意把編程工具換成國內(nèi)大廠的 AI Coding 產(chǎn)品？這不僅僅是技術(shù)問題，更是更復(fù)雜的商業(yè)考量，即擔(dān)心自己的代碼泄漏或被這些編程產(chǎn)品廠商獲取。”

“很多公司非常注重自己的知識產(chǎn)權(quán)保護。使用這種需要掃描全量代碼的 AI IDE，用戶心理上會感到害怕。目前大家確實有在討論這個產(chǎn)品可能會有數(shù)據(jù)的回傳，如果是一些金融科技類的公司，擔(dān)憂會更加強烈。”

“ 那么使用國內(nèi)產(chǎn)品時如何應(yīng)對這個風(fēng)險呢？面上和實際操作不一樣。面上的話，企業(yè)可以跟模型廠商簽合同，表明廠商不可以把用戶數(shù)據(jù)用于自己的模型訓(xùn)練，此外模型廠商需要做出所謂“ memory in read committed ”的技術(shù)記憶清除承諾。但是讓企業(yè)跟國內(nèi)大廠簽，企業(yè)會放心嗎？各種商業(yè)瑕疵、實際丑聞讓這事變得幾乎無意義。我們的商業(yè)環(huán)境不足以支撐這個信任度。”

“ 所以，公司跟供應(yīng)商去談數(shù)據(jù)安全承諾沒用，還是要回到公司內(nèi)部如何解決外部威脅的問題上。解決辦法就是在公司內(nèi)部做一個網(wǎng)關(guān)。通過這個網(wǎng)關(guān)去管控，明確哪些數(shù)據(jù)能夠流出，哪些不能。除此之外，其實沒有任何方式能夠真正約束這些供應(yīng)商。”

不僅是不敢用，面對發(fā)展迅猛的 AI Coding 技術(shù)，國內(nèi)企業(yè)的落地方式總是顯得更加保守。畢竟，創(chuàng)新用途也不是 Vibe Coding 的專屬，效率提升本來就會促進創(chuàng)新增長。

王威表示，“ 過去因為開發(fā)成本很高，我們需要盡可能把想法先想清楚，避免浪費，然后再進入交付管道。今天如果 AI Coding 帶來的交付成本足夠低，就可以做更多探索，產(chǎn)品交付的形式或者與客戶的交互節(jié)奏也可以更快。這里的成本主要指時間成本。”

“ 這其實給企業(yè)帶來了更多快速創(chuàng)新的可能，而不僅僅是幫助企業(yè)減員。”

“ 但今天很多行業(yè)，尤其在國內(nèi)，可能因為環(huán)境或競爭態(tài)勢，新需求并不多。大家不太愿意創(chuàng)新。”

“如果只是想著節(jié)省時間、減少人手，實際上并不能真正推動業(yè)務(wù)增長。減再多的人，也解決不了企業(yè)在市場上能否做得好的問題。”

即便有足夠強的動力，要利用好 AI Coding 也不是沒有門檻的，但有些企業(yè)的 Context 環(huán)境還夠不上讓 AI 正常發(fā)揮的下限，一大原因就是沒有挖掘出企業(yè)中的隱性知識，但又希望 AI 直接能理解。

王威表示，“ 要為 AI Coding 構(gòu)建一個好的 Context，需要先做企業(yè)知識提取和管理。其實這個方向并不新，從上世紀 70、80 年代起，很多企業(yè)包括一些咨詢公司甚至 IBM ，都在做企業(yè)知識管理，這是一個很專業(yè)的咨詢范疇。這個方向市場空間還很大，目前從行業(yè)來看，還沒有太好的解決辦法。”

“ 現(xiàn)在這個行業(yè)的做法有一些問題，大部分咨詢公司、產(chǎn)品公司、AI 公司仍然希望用 AI 暴力破解，相當(dāng)于大力出奇跡的方式，得到一個準確的結(jié)果，我不太看好這種方式。”

“AI 理解 Context 的能力雖然越來越好，但理解不了代碼背后蘊藏的隱性知識。它只能挖掘現(xiàn)有代碼的結(jié)構(gòu)，用自然語言解釋代碼在做什么，很難真正理解代碼為什么當(dāng)初要寫成這個樣子。”

“ 很多時候，代碼里一些比較麻煩或復(fù)雜的地方，之所以寫成那樣，是有背后的原因的，而這些原因顯然也是知識的一部分。”

“ 如果不了解背后的原因，僅僅按照一些標準建議去做，比如說 ‘ 這兩個代碼不應(yīng)該被拆開 ’，很可能就會觸發(fā)在五六年前已經(jīng)解決過的問題，又把它復(fù)現(xiàn)出來。”

“ 知識管理有一個很重要的原則，就是要區(qū)分哪些是大家有共識的標準，哪些只是偶然情況或不得不臨時處理的情況。有些企業(yè)雖然有代碼規(guī)范，但每個人寫代碼時都有自己的偏好。”

“ 規(guī)范性比較強的企業(yè)，在接入像 Glean 這樣的文檔生成工具，或者 DeepWiki 這樣的源碼分析工具時，效果就比較好。這樣的代碼容易被 AI 理解，輸出結(jié)果也更加準確。”

“ 我估計，在整個行業(yè)里，這樣的規(guī)范代碼庫最多占到 30% 到 40%，而在國內(nèi)可能最多只有 5%。”

“ 這當(dāng)然是老問題了。大部分代碼，大家戲稱為 ‘ 屎山代碼 ’，過去我們叫它遺留代碼、爛代碼。因為時間和各種壓力，開發(fā)者沒辦法把代碼寫得整齊，也沒時間去做重構(gòu)，這樣代碼就很難和業(yè)務(wù)語義保持一致，于是就需要在業(yè)務(wù)、技術(shù)、代碼之間不停做翻譯。”“ 這種情況下，其實就是 AI Coding 不太能發(fā)揮作用的地方，至少今天的基座模型不太能應(yīng)付。”

“ 我們通過自己的方案，在一些案例中，能把這項工作的耗時從一個月壓縮到 5 到 10 分鐘。但即便如此，有些企業(yè)可能受限于所在行業(yè)的發(fā)展，或者上下游供應(yīng)鏈的情況，缺乏創(chuàng)新或改變的動力。即便企業(yè)知識管理對他們有價值，優(yōu)先級也不高。當(dāng)然，隨著經(jīng)濟的恢復(fù)和發(fā)展，這類需求的優(yōu)先級應(yīng)該會被提高，并進一步促進 AI Coding 的落地。”

從企業(yè)知識管理到舊代碼重構(gòu)，都能為 AI Coding 提供良好的 Context。這個關(guān)系甚至能形成一個閉環(huán)，比如今年就有言論表示舊代碼重構(gòu)是 AI Coding 落地的投資回報率最高的場景。

陳玉兆表示，“ 舊代碼重構(gòu)本身是非常痛苦且耗時的，尤其對新人極不友好。現(xiàn)在行業(yè)離職率挺高，很多項目維護了十幾年，老員工相繼離職，招進來的應(yīng)屆生想要快速深入了解代碼并進行重構(gòu)非常困難。”

“如果能有一個 AI 工具，快速把基礎(chǔ)類的風(fēng)格統(tǒng)一、清除冗余方法，是一件非常好的事情。在此基礎(chǔ)之上再去重構(gòu)復(fù)雜功能，會節(jié)省大量時間。即便是平時開發(fā)中碰到舊代碼風(fēng)格不一致或?qū)崿F(xiàn)低效，把這些小的代碼片段交給 AI 重構(gòu)成更高效的實現(xiàn)，收益也很明顯。”

“ 如果是我的話，我有意愿去購買這種服務(wù)。”

“ 歸根結(jié)底，這個場景 ROI 最高的核心原因在于：現(xiàn)在的 AI 還沒那么智能，它能做的就是這種邏輯簡單但極其費時、瑣碎的事情。而這些事情恰恰又是程序員最不愿意做的。”

張森森則認為，基于 AI Coding 做舊代碼重構(gòu)是有場景限制的，“ 舊代碼重構(gòu)是 AI 編程中投資回報率最高的，這在邏輯上沒有問題。像銀行那樣的系統(tǒng)，代碼是經(jīng)過 10 年、20 年層層堆疊出來的，系統(tǒng)極其脆弱。越是復(fù)雜的場景，可能越是當(dāng)下迫切需要的功能，邏輯上它的 ROI 確實很高。當(dāng)然我不認為現(xiàn)在的 AI 水平能完全支撐把這件事真正落地。它本質(zhì)上解決的是業(yè)務(wù)價值判斷和避開 ‘ 局部最優(yōu)陷阱 ’ 的問題，而只有人才能判斷出哪里改起來快、哪里改起來慢，所以全局的洞察必須由人來把握。”

“ 那么，市場上到底有多少程序員擁有看透復(fù)雜邏輯并主導(dǎo)重構(gòu)的能力？我對這個人才儲備量是持懷疑態(tài)度的。”

生成、重構(gòu)的良性循環(huán)模式，或許能帶來一個希望。國內(nèi) SaaS 行業(yè)的老問題是各公司甚至各部門之間技術(shù)標準不統(tǒng)一、重復(fù)造輪子。以 AI 為效率驅(qū)動器，來推動舊代碼重構(gòu)和規(guī)范化，能解決這個老問題嗎？

對此，陳玉兆給出了完全否定的回答，“ 我覺得不能，國內(nèi)沒有任何希望，因為這是國內(nèi)的行業(yè)風(fēng)氣導(dǎo)致的，不是技術(shù)的問題。”

“ 不光是軟件領(lǐng)域，商業(yè)領(lǐng)域也是一樣，不管是短視頻平臺、外賣平臺，大家最后都是做電商。國內(nèi)的風(fēng)格就是什么賺錢快就先做什么，做大做強之后就什么都想做，想吃掉對方。”

“ 即便在技術(shù)行業(yè)，比如做數(shù)據(jù)庫也是一樣，功能越堆越多。國內(nèi)的風(fēng)格不是走 ‘ 垂直 ’ 路線，而是想把所有東西都塞進去：既想支持倒排索引、文檔功能，又想支持 AI 向量檢索，同時還想兼顧傳統(tǒng)的 OLTP 場景和 OLAP 場景。這種 ‘ 大雜燴 ’ 趨勢和國外完全不同。”

“ 國外的系統(tǒng)相對純粹很多，追求小而精、可擴展、可部署。尤其是在 AWS 等云廠商上對接時，他們傾向于把平臺做得盡量垂直。”

“ 由于這種根深蒂固的差異，想在國內(nèi)推技術(shù)標準，實在是太難太難。”

技術(shù)驅(qū)動讓位于行業(yè)風(fēng)氣，或許又從某種角度解釋了國內(nèi) ToB 企業(yè)為何創(chuàng)新動力不足。當(dāng)然 AI 確實能先激發(fā)企業(yè)的競爭焦慮，張森森表示，“ 為了在市場競爭和效率競爭中不掉隊，使用 AI Coding 這件事沒有回旋余地，必須 100% 推進。”

但若創(chuàng)新動力不足或無暇顧及，實際上在 AI Coding 浪潮下，很多傳統(tǒng) SaaS 公司將面臨更深刻的危機。

張森森表示，“很多 SaaS 公司現(xiàn)在其實活得 ‘ 戰(zhàn)戰(zhàn)兢兢 ’。因為有大量 SaaS 產(chǎn)品的程序和代碼質(zhì)量非常差，以前大家可能需要買他們的軟件，但現(xiàn)在利用 AI，可能幾天時間用戶就能自己做出一個類似的東西。對于這些 SaaS 公司來說，最大的風(fēng)險在于，他們系統(tǒng)所能提供的端到端解決問題的能力其實非常有限。一旦 AI 降低了開發(fā)門檻，他們原有的技術(shù)壁壘就會迅速瓦解。”

“ 具體而言，這些公司可以分為兩種：第一種是 SaaS 化產(chǎn)品做得非常復(fù)雜的公司。這種產(chǎn)品的邏輯 AI 是無法簡單復(fù)刻的，這類公司可以考慮利用 AI 來優(yōu)化代碼或提升內(nèi)部流程。第二種是做小工具的公司。比如以前上架到 App Store 的番茄鐘，這種東西現(xiàn)在人人都能自己做一個。在 AI 輔助下，通過 Cursor 之類的工具 ‘ 咔咔一下 ’ 就出來了。那現(xiàn)在的番茄鐘還能賣錢嗎？”

番茄鐘或許門檻太低，但有一類 SaaS 產(chǎn)品門檻不低，卻因為和 AI Coding 定位太過于接近，正面臨最大生存危機。

王威表示，“ 原來的低代碼、零代碼平臺效果其實都不好。以我們過去做咨詢的經(jīng)驗來看，這類低代碼平臺對企業(yè)來說，并不是最佳投資策略。低代碼最終只能實現(xiàn)一些排列組合式的功能，難以滿足真正個性化的需求。如果你想做一個軟件產(chǎn)品，最核心的是理解用戶需求和邏輯（ 他們的 journey 是怎樣的 ）。真正理解這些的時候，你就會發(fā)現(xiàn)低代碼平臺要么封裝顆粒度太大，不夠靈活，要么顆粒度太小，又需要花大量時間去做編排，還不如自己寫代碼。”

“ 另外，我個人看過的低代碼平臺普遍存在一個問題：可測性不夠好，尤其是單元測試和模塊間的集成測試，復(fù)雜度反而上去了。”

“ 而今天有了 AI，你可以特別快地生成原型。只需要告訴 AI 我想要什么樣的 App，用戶習(xí)慣大概如何，界面大概長什么樣，原型就出來了。所以在 AI 時代，低代碼的優(yōu)勢可能會被 AI 的快速原型和高度定制化能力所取代。

張森森的觀點基本一致，“低代碼平臺很有可能被 AI 取代。低代碼平臺最大的問題，和現(xiàn)在的 Agent 是一樣的，就是一幫程序員自我感動想出來的東西。他們希望搞一個平臺，讓業(yè)務(wù)人員通過拖拉拽就能搞出 Agent 或者頁面。”

“ 但實際上，沒有一個業(yè)務(wù)人員真的愿意用這種工具去拖拉拽出一個端到端的結(jié)果。大家都是迫于公司需要，或者沒人幫忙干，才只能自己干。但凡業(yè)務(wù)人員能找到研發(fā)人員來干活，都不會自己動手的。”

“實際上，這個需求存在了很多年，因為這個故事講得很通順：通過業(yè)務(wù)人員拖拉拽生成頁面來減少開發(fā)人員。資本市場認可這個故事，在公司內(nèi)部只要瘋狂推行、壓迫業(yè)務(wù)人員去用，最終也會有人用。”

“ 但大部分情況下，都變成了一種尷尬境地：業(yè)務(wù)人員真的不想用，覺得拖拉拽太扯淡、太惡心。即便是實現(xiàn)一些簡單的邏輯，它可能能幫你做，但做完之后又實現(xiàn)不了真正的業(yè)務(wù)目標，業(yè)務(wù)人員就卡在一個兩難之間了。”

“ 最重要的是，拖拉拽操作是有學(xué)習(xí)成本的，業(yè)務(wù)人員為什么要學(xué)呢？對于一個計算機小白，這等于瘋狂地學(xué)一樣新東西。但有些業(yè)務(wù)人員說不定連學(xué) Excel 都覺得費勁，精通 Excel 的人本來也不多。拖拉拽在程序員或懂技術(shù)的人看來是很簡單的，但他們完全沒有站在真正用戶的角度看問題。”

“ 至于大模型和 AI Coding 出來后會不會替代它，要看低代碼平臺是否有動力對內(nèi)核進行升級，總之不能再以過去那種 ‘ 拖拉拽 ’ 的方式設(shè)計產(chǎn)品了。畢竟現(xiàn)在業(yè)務(wù)人員通過自然語言描述一下，AI 就能把拖拉拽的工作做好，把頁面生成好。所以這個邏輯依然會存在，但本質(zhì)上是真正解決了 ‘ 費勁 ’ 這個痛點。” 王威補充道，“在企業(yè)應(yīng)用或者軟件交付場景下，我們團隊一直不太推薦用低代碼平臺。這也引出了一個問題：在 AI 時代，它會變成什么樣？”

“ 與其在低代碼上做封裝，如果今天的低代碼平臺只是基于基座模型再封裝一層、變成一個 Agent，倒可能是可行的。這樣可能會讓整個軟件構(gòu)建過程最終變成一個 Agent，不再受原來模塊顆粒度高低的限制。”

進一步，在 AI Coding 快速吞噬低代碼平臺生存空間的當(dāng)下，軟件開發(fā)工具、平臺層面還有更多創(chuàng)新空間嗎？

王威認為是有的，但要建立在 AI Coding 的語境下，“ 在軟件研發(fā)的整個鏈路里，不管是需求分析、架構(gòu)設(shè)計、代碼編寫、測試用例的設(shè)計與執(zhí)行，還是配置管理、環(huán)境管理、DevOps 等，我們都應(yīng)該去思考：在每一個環(huán)節(jié)，AI 能幫我做什么？我怎么讓 AI 參與進來？”

“ 當(dāng)你先把 ‘ 如何讓 AI 融入我的日常工作流程’這件事想明白之后，下一步其實就是抽象與沉淀。也就是把你在工作中用得特別順的一些東西提煉出來，比如一個始終有效的 Prompt 結(jié)構(gòu)、一個特別清晰的問題框架、一個真正能提升效率的工作流、或者一套驗證過的最佳實踐。把這些東西從 ‘ 經(jīng)驗 ’ 變成 ‘ 工具 ’。”

“真正有價值的創(chuàng)新都來自一線，來自那些能解決企業(yè)真實問題的場景。所以當(dāng)你把這些工作中的好模式封裝出來、工具化、體系化，它不僅能讓你在企業(yè)內(nèi)部產(chǎn)生更大的價值，甚至可能在企業(yè)之外變成一門新生意、一個新產(chǎn)品。”

“ 今天的行業(yè)其實還沒有共識，大家對未來的形態(tài)也沒有統(tǒng)一答案。既然如此，不如把你手里最好的工具拿出來試試，把它產(chǎn)品化，把它武器化。”

另一方面，如果要在產(chǎn)品中深度結(jié)合 AI，作為非大模型廠商創(chuàng)業(yè)者，死磕模型不一定是好選擇。

比如 Cursor 推出了自研的編程模型 Composer 1，試圖從套殼 AI 應(yīng)用廠商升級為大模型廠商，但目前行業(yè)整體評價是比較一般的，比如一些 Reddit 網(wǎng)友反饋 Composer 1 非常快，但只是更擅長簡單而繁瑣的任務(wù)，智能上限不高，所以規(guī)劃能力不如頂尖模型，還有 Reddit 網(wǎng)友認為它應(yīng)該對標的是小模型比如 Grok Code Fast 1，甚至還不如后者。

張森森表示，“ Composer 1剛發(fā)布的時候我用過，個人體感是 ‘ 特別難用 ’。Cursor 之所以做這個事，是因為 Cursor 每年的盈利中，大部分錢是要交給那些大模型廠商的，我預(yù)計他們每年虧損得很嚴重。所以他們會想，與其把錢交給別人，不如自己做個模型，自己掙這個錢，這是它的商業(yè)考量。而且 Cursor 也是在跟資本講一個故事，說它能活到最后的目的，是以后能實現(xiàn) Vibe Coding，目前離真正盈利還早得很。”

相比傳統(tǒng)企業(yè)和創(chuàng)業(yè)公司，還有一個遠為更龐大的群體正受到 AI Coding 的劇烈沖擊，也就是程序員。那么在 AI Coding 時代，程序員如何更好地生存和發(fā)展呢？

首先明晰一點，程序員當(dāng)前確實存在一些職業(yè)危機，但不是全方位被覆蓋的。

陳玉兆認為需要按工種劃分，“做基礎(chǔ)測試的人更可能會面臨淘汰。目前來看，寫基礎(chǔ)測試代碼的工作確實可以由 AI 完成。”

“ 但稍微復(fù)雜一點、帶有業(yè)務(wù)邏輯的測試工作，目前 AI 還很難替換人的作用。”

王威持類似觀點，“ 有些公司可能會說，因為我有 AI 工具，就可以裁掉 60% 或 80% 的程序員，但我覺得今天很難有公司真的會做出這樣的操作。” 并且按從業(yè)經(jīng)驗進行了劃分，“ 相比安全感最高、能輕易駕馭 AI 的專家級別或資深程序員，中級程序員（ 工作年限大概在三到五年之間 ）的危機最大。”

“ 尤其在國內(nèi)，在過去十年互聯(lián)網(wǎng)熱潮中，很多外包團隊的程序員，因為企業(yè)對 IT 人員需求量大，通過速成方式進入了 IT 行業(yè)。這些人可能只能按客戶需求寫代碼，卻不了解客戶業(yè)務(wù)，也不了解技術(shù)底層邏輯。”

“對于這樣的同學(xué)，隨著年齡和工作年限增長，和 AI 相比，他們確實需要思考如何更好與 AI 共存、協(xié)作，思考自己的競爭力在哪里。”

“無論是中級程序員還是新手程序員，今天的最低門檻、最底線的要求是：學(xué)會和 AI 協(xié)作。”

張森森則認為關(guān)鍵在于長期積累的工作和思維習(xí)慣，“ 在 AI Coding 時代，程序員本身也要完成素質(zhì)上的提升和轉(zhuǎn)型。未來的程序員的生存之道是，不能只精通某一項語言（ 比如 Java 或 C ），而是要轉(zhuǎn)型為 ‘ 全棧 ’ 甚至 ‘ 全語言 ’ 掌控者。程序員或許不需要深入了解每種語言的所有細節(jié)，但必須能看懂 AI 生成的每一行代碼，并清楚它在整個程序架構(gòu)中發(fā)揮的作用。”

“ 未來的軟件開發(fā)不再需要 ‘ 代碼搬運工 ’。如果一個程序員只會寫一種語言，或者過去的工作習(xí)慣只是寫一些邊角余料，甚至是那種別人給好框架、只負責(zé)往里填邏輯的 ‘ 填充式編程 ’，這類程序員 100% 會被開掉。”

“這種工作模式已經(jīng)完全不符合技術(shù)發(fā)展的需要，在 AI 已經(jīng)能高效完成填充和補全工作的今天，這類程序員將不再被定義為 ‘ 程序員 ’。”

從另一個角度看，AI Coding 不一定是危機來源，也可以是新的自我提升和成長的機會，陳玉兆表示，“ 比如對于程序員的個人學(xué)習(xí)，用 AI 來做源碼分析是非常擅長且適合的。”

即便是對于新手程序員，只要建立正確的認知，就不用擔(dān)心過度依賴 AI，阻礙自身成長，陳玉兆表示，“ 現(xiàn)階段的 AI 編程并不具備資深工程師的全部技能，它相當(dāng)于是一個高中生或應(yīng)屆畢業(yè)生的水平。”

“ 它能幫助你的是那些容易量化、模塊化、模板化的重復(fù)性工作。它能幫你更高效地組織代碼，并用更接近人類自然語言的方式進行交互。它本質(zhì)上是對已有工具的集成和加速，而不是取代。如果新手能熟練運用這種新工具，反而更好。”

“ 時代是在發(fā)展的，程序員不可能永遠拿著文本編輯器編程，就像 IDE 也在發(fā)展，就像以前用 Photoshop 處理圖片超級復(fù)雜，現(xiàn)在用谷歌的 Nano Banana Pro 說幾句話就能處理。”

“ 當(dāng)然，如果想更深入地了解某個領(lǐng)域的行業(yè)經(jīng)驗、發(fā)展歷史等深層次內(nèi)容，還是需要和專業(yè)領(lǐng)域的人員進行深入的溝通，這些東西 AI 應(yīng)該是提供不了的。”

王威也持類似觀點，“對于新手程序員或剛從學(xué)校出來的年輕人，其實AI是機會。今天 AI 可以幫助新人迅速達到原來中級程序員的水平。”

“ 無論是通過 Prompt Engineer 還是 Context Engineer 構(gòu)建良好的和 AI 協(xié)作的模式，那么入職第一個月甚至前兩周，就能建立起和過去中級程序員相似的輸出能力。”

“我們經(jīng)常會和客戶反復(fù)強調(diào)，千萬不要裁掉年輕程序員。因為只有這些年輕人，隨著他們對業(yè)務(wù)的了解加深，隨著在企業(yè)的工作時間增長，才能逐漸成長為專家。”

“雖然理論上，中級程序員也可以培養(yǎng)成專家，但其實最合理的方式是在 AI 的加持下，讓年輕人快速成長為專家。因此，行業(yè)內(nèi)很多海內(nèi)外專家一直大力建議企業(yè)不要放松對畢業(yè)生的招聘。畢業(yè)生是有前途的一代，而專家這一層也不能拋棄。所以我才說最危險的是中間那一層程序員。”

這不只是預(yù)言，其實已經(jīng)體現(xiàn)在目前一些軟件公司的實際招聘需求變化上了，“ 根據(jù)一些統(tǒng)計報告，確實顯示過去一年尤其是最近半年，整個軟件行業(yè)開放的 Headcount 都比去年下降了。并且他們確實是會增加對略微資深程序員和校招的 Headcount。”

“ 但更坦白地說，如果預(yù)算有限，我們都會建議至少校招不能停。”

“ 因為從企業(yè)未來發(fā)展的角度，總要為未來儲備人才。年輕人需要在真實業(yè)務(wù)里慢慢培養(yǎng)、累積經(jīng)驗。如果完全不招新人，只靠外部招聘有經(jīng)驗的程序員，那么企業(yè)內(nèi)部的關(guān)鍵上下文和知識的傳承、人才梯隊，很可能會出現(xiàn)斷檔，長期來看對企業(yè)反而是更大的風(fēng)險。”

“這在今天可能還看不太出來，有些企業(yè)可能覺得與其招十個甚至一百個校招生，不如直接招兩三個專家程序員，看上去更省錢、更直接。但實際上，當(dāng)時間拉長到五年甚至更久的時候，都會出現(xiàn)明顯的問題。”

當(dāng)然，工種、經(jīng)驗等都是表面判據(jù)，任何程序員都不必然會因為這些因素被淘汰，“ 我會建議大家先問自己一個很本質(zhì)的問題：對這個行業(yè)到底有沒有真正的興趣？”

“ 我始終認為，真正能把一個人推向 ‘ 專家 ’ 層級的，從來不是日常的任務(wù)堆積，不是寫了多少行代碼，也不是做了多少 CRUD。 ”

“ 能讓一個人愿意深入理解每一項技術(shù)，愿意把技術(shù)棧往底層學(xué)，愿意去追根究底地研究 Java 的運行機制、JVM 的內(nèi)部結(jié)構(gòu)、Redis 的底層實現(xiàn)，這些動力絕對不是源于 ‘ 工作需要 ’，而是對計算機、對技術(shù)本身的熱愛。很多五十多歲的程序員對這個行業(yè)依然保持熱情，只要有新技術(shù)出來，他們都會第一時間去看資料、讀文檔、閱讀開源代碼，去看別人到底是怎么實現(xiàn)的。”

“ 這樣的人，無論是新手程序員、中級程序員，還是現(xiàn)在已經(jīng)是個專家，都是非常有前途的。”

“歷史也能證明，蒸汽機出現(xiàn)以后，很多手工作坊都消失了，但真正沒有被取代的，是那些老匠人、熱愛做事的人、把自己的作品看作藝術(shù)去鉆研的人，即使到了工廠，他們也能指導(dǎo)機器，通過改造流水線或零部件制造新的產(chǎn)品。這樣的人，在市場上永遠有價值。而因為鐵匠這個行業(yè)能掙很多錢所以去當(dāng)學(xué)徒打鐵的人，從歷史上看都會面臨比較大的危機。”

“ 所以，如果只是因為過去這個行業(yè)溢價很高，坦白講就是‘很容易賺錢’，比如學(xué)個 Java、學(xué)個 Python 就能進到大公司做程序員，可以思考一下，是否需要換一個賽道。”

使用 AI 寫代碼、與AI協(xié)作，已經(jīng)是大勢所趨。那么一個很關(guān)鍵的問題就是，如何與 AI 協(xié)作，才能最大化個人的產(chǎn)出，最大化對 AI 的利用，同時避免 AI 技術(shù)限制帶來的額外成本。

在具體執(zhí)行層面，核心是 Context 管理和人機交互模式的打磨。

王威表示，“ 這一年多，我們看到的是 LLM 的能力在逐漸趨于穩(wěn)定，接近一個 ‘ 可預(yù)期的上限 ’。也就是說，它主要的能力還是基于你給它的 Context，來做更精準的預(yù)測和生成。”

“ 圍繞這些已經(jīng)相對成熟的能力，每個程序員都應(yīng)該建立起自己的一套 ‘ 和 AI 協(xié)作的打法 ’。 比如：我如何與 AI 交互？我如何通過 Prompt 讓 AI 幫我生成原型？我如何讓 AI 幫我改代碼？我如何讓 AI 幫我整理數(shù)據(jù)、總結(jié)知識？這些其實都是今天軟件行業(yè)的從業(yè)者必須掌握的基本能力。”

在一些典型場景中這些原則可以體現(xiàn)得很明顯。比如 AI Coding 過程中由于模型的知識偏差和知識盲區(qū)，總會帶來一些很根本的不確定性，比如前者帶來對編程語言（ 比如 Python、Swift ）熟悉度的偏差，后者帶來幻覺的可能性，這就很依賴 Context 管理來解決。

陳玉兆表示，“ 就算存在比較嚴重的知識偏差，只要給它足夠的引用、上下文、參考文檔，并告訴它想生成的代碼風(fēng)格，基本不會出太大問題。”

張森森補充道，“ 關(guān)于 AI 編程模型在不同編程語言上的側(cè)重，這種現(xiàn)象肯定存在。國外的 AI 模型通常 React 寫得比較好，Vue 稍微差一點。這跟訓(xùn)練語料有直接關(guān)系，因為國外大部分前端軟件都是用 React 寫的，而國內(nèi)用 Vue 寫的更多。”

“ 針對這種不平衡，目前行業(yè)內(nèi)主要有兩種做法。首先是語料層優(yōu)化，在模型訓(xùn)練階段，針對性地增加特定語言（ 如 Vue 或 Flutter ）的語料權(quán)重。其次是邏輯轉(zhuǎn)換，采用 ‘ 先生成再轉(zhuǎn)換 ’ 的模式。比如先讓 AI 用它更擅長的 React 邏輯寫完，再通過特定的轉(zhuǎn)換工具或二次 Prompt，將其邏輯轉(zhuǎn)譯成 Vue 代碼。”

“ 關(guān)于這一點，Lovable 還有一個不太令人滿意的地方，就是它嚴重的技術(shù)棧綁定。國內(nèi)前端大部分習(xí)慣用 Vue，后端很多已經(jīng)用 Java 寫好了。像 Lovable 這種面向海外市場的工具，前端必須是 React，后端綁定了 Supabase。這導(dǎo)致國內(nèi)現(xiàn)有的企業(yè)級存量代碼根本沒法拿過來用。”

至于一些最令人頭疼和心累的問題，比如 “ 按下葫蘆浮起瓢 ”，想修改一個特定的 Bug，但 AI 在修改過程中造成了新的 Bug。陳玉兆認為，這種情況在良好的交互模式和開發(fā)實踐下，可能性不是很大，“ 這取決于你原來的測試集寫得是否全面。首先你得有一個自己的基礎(chǔ)測試集，系統(tǒng)的穩(wěn)定性和可用性首先應(yīng)該由你的基礎(chǔ)測試集來保證。不可能讓 AI 幫你寫所有的測試，那不太現(xiàn)實。”

當(dāng)然，其中也會存在一些 “ 是否必須用 AI ” 的權(quán)衡，“ 對于一些邏輯比較復(fù)雜的代碼塊，需要給它正確的引用，在搜集這些引用、提供足夠的 Context 以及反復(fù)糾正的過程中，它有一個回饋、撤回、再糾正的過程，如果這個過程花費的時間太長，反而有時還不如自己直接寫來得快。”

在原則層面，需要時刻記住 “ AI 在不斷發(fā)展，AI 永遠存在天花板 ”，張森森認為，與 AI 協(xié)作需要結(jié)合 AI 的發(fā)展現(xiàn)狀，才能發(fā)揮最好的效果，無論是程序員和企業(yè)管理者都需要建立這樣的認知，“雖然 AI 編程是必然趨勢，但 AI 的能力上限和天花板是隨著技術(shù)發(fā)展動態(tài)變化的。不能忽視這個天花板的存在，如果盲目追求效率而無限度地壓榨程序員，公司是無法進入良性發(fā)展軌道的。正確的做法應(yīng)該是，持續(xù)尋找合適的場景讓 AI 去替代那些重復(fù)、乏味的工作。”

“ 從原型開發(fā)到生產(chǎn)級、大型企業(yè)級項目的過渡中，如何將 AI 的利用率最大化？按目前現(xiàn)狀，可以參考幾個關(guān)鍵的比例分配經(jīng)驗。比如樣本代碼與文檔可以 100% 委托給 AI 生成，人工只需進行抽檢。單元測試 70%-80% 可以交給 AI 完成，但人工需要補充一些邊界條件。核心邏輯（ 算法實現(xiàn) ）最多只能給 AI 四成，因為涉及到復(fù)雜的架構(gòu)設(shè)計和異常處理，AI 目前完全做不了。安全審計 AI 可以負責(zé)初審和針對性的漏洞掃描，但這必須保證 Human-in-the-Loop，一定需要人工復(fù)核。”

對安全風(fēng)險把控的重要性再怎么強調(diào)也不為過，風(fēng)險包括 AI 幻覺和企業(yè)機密數(shù)據(jù)泄漏，應(yīng)對前者的核心原則是 “ 永遠要人工審查代碼 ”。

如果太依賴 AI 編程，可能會導(dǎo)致程序員記不住代碼的細節(jié)，當(dāng)真的出現(xiàn)高風(fēng)險事故時，安全風(fēng)險排查會變得比往常更加困難，陳玉兆表示，“程序員可以不寫這段代碼，但需要深入了解這段代碼是干嘛的。對于每一段 AI 生成的代碼，都要了解它的作用，而不是 ‘ 無腦 ’ 地直接合并。”

“ 如果長期看都不看就直接合并，一年兩年之后，程序員肯定不知道代碼里到底寫了什么，出了 Bug 也就修不了。但如果每次都站在 Reviewer 或項目維護者的角度仔細審查，追蹤代碼的時間線、迭代過程以及生成邏輯，是不存在這種風(fēng)險的。即便招一個真實的程序員來開發(fā)，也是同樣的流程。”

關(guān)于如何應(yīng)對企業(yè)機密數(shù)據(jù)泄漏風(fēng)險，以網(wǎng)站開發(fā)為例，張森森表示，“ 完全使用 AI 開發(fā)網(wǎng)站并部署到 Supabase這類平臺時，身份驗證、注冊系統(tǒng)及安全風(fēng)控可能是較難解決的痛點。AI 并非完全沒能力做，而是風(fēng)險極大。敏感數(shù)據(jù)絕不可以作為 AI 的上下文，否則一旦被外部獲取，會導(dǎo)致商業(yè)機密和公司安全風(fēng)險泄露。因此，簡單一些的比如鑒權(quán)系統(tǒng)的代碼 AI 可以寫，但若涉及數(shù)據(jù)庫的數(shù)據(jù)必須慎重考量，比如數(shù)據(jù)庫安全規(guī)則、權(quán)限規(guī)則等邏輯，AI 能提供方向或生成部分代碼，但具體的公司級業(yè)務(wù)邏輯是機密的，通常需要手工編寫。”

到這里，我們基本了解了 AI Coding 和 Vibe Coding 的區(qū)別和發(fā)展現(xiàn)狀，張森森總結(jié)道，“目前 AI Coding 的最佳實踐不是 ‘ 全自動生成 ’，而是 ‘ 部分生成+ 程序員修改 ’ 的模式。這種模式在短期內(nèi)不會被改變。AI Coding 的未來確實是Vibe Coding，但 Vibe Coding 也確實存在泡沫，完全是吹給老板和資本方聽的，他們聽了確實會很興奮，但行業(yè)內(nèi)真正的程序員對此非常困惑，因為大家心里清楚，全自動化的端到端開發(fā)在短時間內(nèi)根本做不到。”

對于非常激進、重度依賴 AI 編程來做產(chǎn)品的創(chuàng)業(yè)者，陳玉兆也建議道，“ 至少還是要招一個比較資深的程序員來控制項目的質(zhì)量。如果一個項目完全、一直由 AI 來生成，最后基本上會變得不可維護。”

那么決定未來的是哪些關(guān)鍵因素呢？

“大模型本身的 ‘ 幻覺 ’ 問題，是目前阻礙全自動化生成的最大屏障，短期內(nèi)很難完全消除。但隨著 Gemini 等模型能力的進化，大家在應(yīng)用生成（ 如 App 生成 ）上的實操經(jīng)驗越來越豐富，這種 ‘ 行不通 ’ 的固有印象正在慢慢改觀。目前行業(yè)正處于一個 ‘ 尋找平衡點 ’ 的階段。”張森森向知危說道。

“ 最終的目標一定是：不再需要專門的程序員，產(chǎn)品經(jīng)理一個人就能搞定從設(shè)計到交付的全過程。這個最終局面的到來，三年還是五年？沒人敢斷言。馬斯克的預(yù)測比較樂觀，但國內(nèi)可能相對悲觀一些，多少年都有可能。”

AI 編程模型要降低幻覺，自然需要吸收更多代碼數(shù)據(jù)，但當(dāng)前行業(yè)在數(shù)據(jù)供應(yīng)和質(zhì)量方面已經(jīng)存在一些不可忽視的潛在風(fēng)險，“ GitHub 現(xiàn)在已經(jīng)快變成 ‘ AI 代碼的天堂 ’ 了。這對普通使用者來說影響不大，因為大家只是把 AI 寫的項目放上去分享，只要能跑通，使用者其實并不介意。真正核心的問題在于未來模型訓(xùn)練的‘ 數(shù)據(jù)污染 ’ 風(fēng)險。當(dāng)我們再次使用 GitHub 上的數(shù)據(jù)去訓(xùn)練新一代 AI 模型時，要弄清楚如何從這些海量的 AI 生成內(nèi)容中，甄別并剔除出那些 ‘ 不干凈 ’ 的數(shù)據(jù)，會變得非常困難。”

“ 這種 ‘ 數(shù)據(jù)污染 ’ 不僅存在于編程界，在整個模型訓(xùn)練領(lǐng)域都是一個巨大挑戰(zhàn)。當(dāng) AI 開始學(xué)習(xí)由 AI 生成的內(nèi)容時，邏輯的退化和多樣性的喪失就不可避免。這就是為什么國家層面要強調(diào)建設(shè)高質(zhì)量數(shù)據(jù)集的原因。”

在 Context 理解能力層面，AI 也存在比較普遍意義上的局限性，可能未來還需要在技術(shù)上做出更多突破。

王威表示，“ 近期 Andrej Karpathy 在播客訪談中提到一個很有趣的現(xiàn)象：在 Claude Code 中，你會發(fā)現(xiàn)一開始 Context 不夠，AI 理解不全面導(dǎo)致生成不準。但到后來 Context 越多，生成反而也不準。” “ Andrej Karpathy 用了一個類比，如果把 Agent 或 AI 看作 ‘人’，那么人之所以能夠記住信息、學(xué)會技能、理解上下文并做出決策，很大程度上依賴于記憶。”

“ 但人不僅有記憶，還有 ‘ 睡覺 ’ 這個過程，‘ 睡覺 ’ 的本質(zhì)是一次信息的壓縮和重組。 此外，人的記憶有時候不只是存在腦子里，還存在外部。人會忘掉很多東西，但這些被遺忘的信息可以在特定時間、地點和環(huán)境下被觸發(fā)。比如你在北京，看到秋天飄落的銀杏葉，可能會突然想起二十年前經(jīng)歷的某個場景。如果不在當(dāng)時的環(huán)境下，你可能完全想不起來，以為自己已經(jīng)忘了。

“所以，人的大腦有這樣的能力：一是通過睡眠對信息進行壓縮和重組；二是通過環(huán)境觸發(fā)存儲在腦內(nèi)外的多模態(tài)記憶，從而喚起過去的經(jīng)驗。這些能力都能讓人的決策更加高效，大模型不具備這種能力。”

“這些問題可能不是 Context Engineering 能解決的，而是需要深入理解人是如何思考的，才能進一步推進。這意味著未來無論是 Agent 公司還是基礎(chǔ)模型公司，都是有機會的。誰能夠幫助大模型更好理解 Context，更像人一樣思考、構(gòu)建機制，誰就有機會開拓未來市場。”

除了模型本身，軟件行業(yè)也會有一個更核心的演變趨勢，張森森表示，“ 現(xiàn)在的 Vibe Coding 和 AI Coding 用的還是 JavaScript、Vue、React 或者 Java，但我相信在未來一到兩年之內(nèi)，一定會產(chǎn)生一種全新的編程語言。這種語言將直接把現(xiàn)有的傳統(tǒng)語言全部干掉，它是完全為了 AI 編程而生的。”

甚至更進一步，軟件工程的范式或許也需要徹底改寫，才能最大化 AI 帶來的價值。

王威表示，“ 要理解這個變革的必要性，需要回到場景本身：到底為什么要寫代碼？為什么要做軟件？原來人是怎么做軟件的？”

“ 在沒有大模型之前，我們做軟件其實有兩種不同的形態(tài)。第一種是個人獨立開發(fā)者。個人開發(fā)者需要不斷學(xué)習(xí)新的技術(shù)、工具、框架，比如從 C++ 換到 Go 再到 Rust，總是要跟上最新一波技術(shù)。”

“ 另外一種是企業(yè)場景。企業(yè)場景要解決的問題不僅僅是個人開發(fā)者的問題，更重要的是規(guī)模化的問題。也就是如何讓一群人一起高效地開發(fā)軟件。一個人高效相對簡單，而在團隊中，即使每個人都是非常優(yōu)秀的獨立開發(fā)者，也有可能出現(xiàn) 1 + 1 小于 2，甚至只有 1.1、1.2 左右。”

“ 所以過去的軟件工程，從早期的瀑布模型，到敏捷迭代，再到 DevOps，其實都在試圖解決同一個問題：一群人要怎么一起把軟件開發(fā)好。”

“ 而今天的 Code Generation 工具，本質(zhì)上仍然更多關(guān)注個人開發(fā)者。但要讓一群人在組織里更好、更高效地完成代碼生成或代碼編寫，把 Code Agent 真正帶入企業(yè)內(nèi)部，并讓它發(fā)揮真正的價值，還需要很長的時間。”

“ 這不僅在于技術(shù)層面，更重要的是人的層面。未來的開發(fā)者、產(chǎn)品經(jīng)理、測試人員，這些角色還存不存在？他們的技能會變成什么樣？這些都是問號。”

“ 如果回頭看，DevOps 、敏捷迭代之所以能在過去十到二十年里推得快和順利，主要原因還是當(dāng)年那些互聯(lián)網(wǎng)公司，比如 BAT、谷歌、亞馬遜，他們在行業(yè)還不成熟的時候就率先采用了新技術(shù)和新組織形態(tài)，去實踐最新的軟件研發(fā)模式，然后這種模式逐漸被傳統(tǒng)企業(yè)、金融、制造等行業(yè)接受。他們天生就在用這種模式做事，所以才會成功。”

“ 當(dāng)時國內(nèi)也想學(xué)國外的微服務(wù)，可見這種標桿效應(yīng)非常強。如果沒有這樣的標桿，現(xiàn)有組織的慣性就很大，在組織內(nèi)部很難推動這種變化。除非集團公司單獨投資搞一個 AI Native 公司，那才有可能。否則在現(xiàn)有業(yè)務(wù)里推動，先不說技術(shù)的慣性，人的慣性就足以讓迭代周期以十年計。十年后，國內(nèi)大廠內(nèi)部的模式才可能真正發(fā)生變化，這是很有可能的。”

“ 所以我不會認為現(xiàn)在的國內(nèi)大廠，會首先出現(xiàn)這一代新的實踐，更可能是類似 Winsurf、Perplexity 這樣的 AI Native 公司帶來新的變化。大家都說現(xiàn)在要講人效，其實創(chuàng)業(yè)公司最講人效。他們會用最少的人，用最新的技術(shù)，用看起來最省力的實踐模式，去打造完整的交付鏈條。AI Native 公司從一開始就不是在舊范式里改造，而是在新范式里長出來的，他們可能會率先實現(xiàn)真正完全依賴 AI 來生成代碼，而不是繼續(xù)手寫代碼，也許關(guān)鍵還是在于如何管理好 Context 。并且，這種模式是可復(fù)制、可復(fù)現(xiàn)的，那么AI才有可能推動整個行業(yè)去跟進。”

“目前國內(nèi)很多行業(yè)會議或?qū)＜以谥v AI 2.0、AI for SE、下一代軟件工程、下一代軟件研發(fā)模式，但其實這些論調(diào)太不成熟。因為當(dāng)下我完全沒有看到任何可復(fù)現(xiàn)的實踐模式。既然如此，就很難談所謂新的宣言或者最佳實踐。”

“就像當(dāng)年的敏捷宣言、Scrum那樣真正能被行業(yè)接受的技術(shù)實踐。敏捷宣言、Scrum 的第一篇論文是 1986 年寫的。而敏捷宣言是在 2001 年定下來的，也就是經(jīng)歷了 15 年時間。當(dāng)然今天時代發(fā)展更快了，可能不用 15 年，但 5 年、10 年仍然是需要的。”

“ 可能某一天，大家會忽然意識到： 原來未來的軟件工廠應(yīng)該是這么運轉(zhuǎn)的，原來自動化的流水線應(yīng)該是這樣搭起來的。到那個時候，新的行業(yè)范式就會逐漸清晰：什么是下一代的工廠，什么是 AI 驅(qū)動的軟件生產(chǎn)方式，什么才是自動化時代真正的 ‘ 基礎(chǔ)設(shè)施 ’。”