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

在正文開始之前，先說一個結論：AI Coding 和 Vibe Coding 不是一回事。AI Coding 大有可為，但 Vibe Coding 勸你先冷靜。前者面向專業開發者，后者面向非專業開發者。

近期，有非常多所謂 “ Vibe Coding 奇跡 ” 出現。

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

AI 編程產品王者 Claude Code 也頻創神話，比如 1 小時復現 Gemini API 負責人 Jaana Dogan 的團隊花費一年構思的分布式 Agent 編排器，10 天復刻 “ Manus ” 也就是 Cowork 。

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

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

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

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

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

專業程序員也都會時刻強調，寫代碼一直是開發中最不重要的一步，決定代碼質量上限的是 AI 尚不具備的深層業務理解和復雜架構設計能力。

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

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

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

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

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

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

• 什么是 AI Coding 和 Vibe Coding？
• 對 AI Coding 樂觀的本質
• 對 Vibe Coding 悲觀的本質
• 國內外差距依然存在
• 關鍵落地場景：舊代碼重構
• 對傳統 SaaS 市場的沖擊
• AI Coding 對程序員的影響
• 與 AI 協作之道
• 展望未來

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

專業的軟件開發不會滿足于完成一個可行的原型或較為簡單的測試場景，最終的目的是將原型重構為企業級、生產級代碼，AI Coding 在這一塊也展現出了很強的執行水平和協同能力。

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

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

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

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

比如在代碼重構場景下，通常涉及的項目規模會很龐大，那么AI模型目前的單次獨立執行復雜度上限是什么？

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

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

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

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

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

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

相對于代碼重構主要面向舊代碼的處理，新增功能則需要添加大量新的業務邏輯。

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

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

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

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

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

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

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

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

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

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

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

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

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

“ 但資本市場的思考邏輯完全不同。資本市場看重的是 ‘ 端到端 ’ 的愿景。在投資者眼中，這是未來必須發展的方向。就像現在大家談論大模型時，已經不再只談論模型本身，而是直接指向 AGI。資本市場對 AI 的熱望已經上升到了全新的層面，投資邏輯早已超越了簡單的代碼補全，到了讓 ‘ 具身智能 ’ 滿世界飛、滿世界跑的層面了。”

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

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

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

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

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

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

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

“ 而之所以這個游戲能玩下去，也是因為現在 AI 技術發展的速度確實已經基本上超過了想象。”

在理清 AI Coding 和 Vibe Coding 在工程和資本層面的本質之后，也要了解到，當前國內外 AI Coding 的差距仍然客觀存在。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“ 但今天很多行業，尤其在國內，可能因為環境或競爭態勢，新需求并不多。大家不太愿意創新。”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“如果能有一個 AI 工具，快速把基礎類的風格統一、清除冗余方法，是一件非常好的事情。在此基礎之上再去重構復雜功能，會節省大量時間。即便是平時開發中碰到舊代碼風格不一致或實現低效，把這些小的代碼片段交給 AI 重構成更高效的實現，收益也很明顯。”

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

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

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

“ 那么，市場上到底有多少程序員擁有看透復雜邏輯并主導重構的能力？我對這個人才儲備量是持懷疑態度的。”

生成、重構的良性循環模式，或許能帶來一個希望。國內 SaaS 行業的老問題是各公司甚至各部門之間技術標準不統一、重復造輪子。以 AI 為效率驅動器，來推動舊代碼重構和規范化，能解決這個老問題嗎？

對此，陳玉兆給出了完全否定的回答，“ 我覺得不能，國內沒有任何希望，因為這是國內的行業風氣導致的，不是技術的問題。”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

另一方面，如果要在產品中深度結合 AI，作為非大模型廠商創業者，死磕模型不一定是好選擇。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“ 當然，如果想更深入地了解某個領域的行業經驗、發展歷史等深層次內容，還是需要和專業領域的人員進行深入的溝通，這些東西 AI 應該是提供不了的。”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使用 AI 寫代碼、與AI協作，已經是大勢所趨。那么一個很關鍵的問題就是，如何與 AI 協作，才能最大化個人的產出，最大化對 AI 的利用，同時避免 AI 技術限制帶來的額外成本。

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

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

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

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

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

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

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

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

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

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

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

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

對安全風險把控的重要性再怎么強調也不為過，風險包括 AI 幻覺和企業機密數據泄漏，應對前者的核心原則是 “ 永遠要人工審查代碼 ”。

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

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

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

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

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

那么決定未來的是哪些關鍵因素呢？

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

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

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

“ 這種 ‘ 數據污染 ’ 不僅存在于編程界，在整個模型訓練領域都是一個巨大挑戰。當 AI 開始學習由 AI 生成的內容時，邏輯的退化和多樣性的喪失就不可避免。這就是為什么國家層面要強調建設高質量數據集的原因。”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“目前國內很多行業會議或專家在講 AI 2.0、AI for SE、下一代軟件工程、下一代軟件研發模式，但其實這些論調太不成熟。因為當下我完全沒有看到任何可復現的實踐模式。既然如此，就很難談所謂新的宣言或者最佳實踐。”

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

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