DeepSeek 的橫空出世，在全球範圍內掀起了新一輪的 AI 熱潮。驚豔的程式碼生成能力，對複雜演算法的深刻理解……AI 驅動的程式設計時代，是否已經悄然來臨？AI 程式設計助手，究竟能幫我們到什麼程度？AI“程式設計師”能突破人類思維的侷限嗎？

近日 InfoQ《極客有約》X QCon 直播欄目特別邀請了 字節跳動豆包 MarsCode IDE 研發負責人馬翀 擔任主持人，和 字節跳動豆包 MarsCode IDE 架構師段瀟涵、網易低程式碼業務中心技術負責人姜天意 一起，在 Qcon 全球軟體開發大會2025 北京站 即將召開之際，共同探討 AI 在程式設計領域的最新進展。

部分精彩觀點如下：

檢視大會日程解鎖更多精彩內容：https://qcon.infoq.cn/2025/beijing/track

馬翀：首先我們從在內部使用 AI 輔助程式設計的進展說起，比如在實際工作中使用 AI 輔助程式設計主要解決哪些痛點？最常用的工具和場景是什麼？有沒有統計過對開發效率帶來多大提升？ 我先來談談我的看法。

我們團隊在這一領域涉足較早。部分聽眾可能知道，2023 年底，在杭州舉辦了一場 AI 沙龍。在圓桌討論環節，我也有參與並建議對 AI 有想法的企業和個人儘早擁抱並嘗試這一技術。我們團隊在字節跳動主要負責 AI Coding 領域的建設，致力於提升工程生產力，目前已對外發布的產品包括 MarsCode、Trae IDE 等，這些產品在技術沉澱和實踐應用方面取得了顯著進展，我們還在 Trae 中推出了對標 Cursor 的 Composer 功能。

去年，AI 對研發的影響尚不太明顯，許多人仍處於嚐鮮階段，模型、工程技術能力也需要提升。而現在，短短一年的時間，變化已翻天覆地。我們團隊日常開發均使用前述的自研 AI Coding 工具，這些在效率、體驗以及減少重複性工作方面都表現出顯著優勢。

姜天意： 網易公司高層對 AI 技術非常重視，甚至可以說是強力推動。公司內部舉辦了多次 AI 分享會、設立了相關獎項，並組織了培訓和考試，高層每天都會轉發大量 AI 相關的文章給我們。2023 年，我和團隊主要使用 GitHub Copilot。當時市場上已經出現了一些智慧體產品，如 Devin、Meta GPT 和 Auto GPT，但經過評估，這些產品的效果並不理想，因此並未在實際工作中採用。

2024 年中下旬，我從 Cursor 轉向了 Windsurf，兩款工具我都深度使用過。相比 Cursor，Windsurf 在大型專案的智慧化支援方面表現更為出色。Windsurf 採用了一項名為 Cortex 的 RIG 技術，能夠有效處理程式碼庫的向量化，因此它在程式碼搜尋、修改以及上下文識別方面表現出色。我們曾使用過 Windsurf 進行效能最佳化，詢問其對元件和程式碼的最佳化建議，效果顯著。此外，團隊中的服務端開發人員對測試用例生成功能非常滿意。編寫測試用例對開發者來說通常是一項繁瑣的任務，但網易內部開發的工具結合 GPT 技術，能夠透過簡單的命令快速生成當前檔案的測試用例，極大提高了效率。

我個人深度使用的一個平臺是 Bot.New，我自行部署了一套，並定製了許多功能，使用體驗非常震撼。目前，一些小型網站甚至複雜模組已經能夠透過對話式生成實現。前段時間，我們嘗試復現一個名為“小貓補光燈”的專案，僅通過幾句話就成功用自然語言實現了該功能，展現了強大的 AI 能力。

此外，我們產品本身是一個低程式碼平臺，團隊中的教練團隊負責產品交付。我們的產品具備多項 AI 能力，包括自然語言程式設計、程式碼補全推薦等，這些功能透過微調業內程式碼生成模型和多模態模型實現，例如利用多模態模型進行設計稿識別。

最後，我個人也有一些使用 AI 的習慣。由於經常出差，我需要在路上處理一些材料，因此我在本地使用 LM Studio 部署了一些模型，用於文章總結、文件編寫、程式碼補全、SQL 生成和程式碼轉換等任務。我認為，本地的小引數模型已經能夠很好地滿足這些需求。

段瀟涵： 我們團隊由於專注於 AI 與程式設計結合的專案，接觸相關技術較早。大約一兩年前，大家開始嘗試使用 Copilot，包括後來的 Copilot Chat，當時普遍的感受是對這些工具缺乏信任。經過這一兩年的發展，我們自己也開發了相關產品，並使用這些工具進行程式碼開發，團隊的信任度有了顯著提升。

從行業產品來看，Cursor 已經存在多年，大家對 AI 在程式設計中的應用看法也發生了巨大轉變。尤其是去年年底，Windsurf 的推出帶來了極佳的體驗，社群對此討論熱烈。由於我們從事相關產品的開發，使用頻率較高，正如天意提到的，這些產品逐漸從小規模程式碼補全擴充套件到更大專案的應用。例如，Bolt.new 在新專案生成方面體驗較好，而 Windsurf 和 Cursor 則能夠處理歷史專案的分析和拆解，效果逐漸提升。

我認為有兩點值得關注：首先，AI 在工程中的落地方式逐漸成熟，工程實踐得到了提升；其次，隨著模型的進步，去年 Cloud 的推出和今年 DeepSeek 的火爆，極大地推動了 AI 與程式設計結合的應用，大家普遍認為 AI 生成的程式碼能夠服務於實際生產。

我個人也有類似的感受。AI 不僅提升了程式碼生成的生產力，還改變了我們的研發流程。過去，我們通常需要分析需求、設計架構，然後進行編碼。而現在，AI 在各個階段都提供了輔助，包括需求分析、文件生成和架構設計，顯著提高了效率。在程式碼編寫方面，我傾向於讓 AI 完成大部分工作，然後進行 review。目前，AI 生成的程式碼佔比大約在六七成到七八成之間，極大地提升了開發效率。

段瀟涵： 我正好可以分享一下我們最近接入 DeepSeek 的體驗。從我的程式設計場景來看，DeepSeek 的表現非常接近國外的主流模型，比如大家常提到的 GPT 和 Claude 3.5。不過，DeepSeek 在實際使用中有一個與其他模型不同的特點，即它對 prompt 的敏感度較高，或者說對噪音的容忍度較低。因此，我們在使用 DeepSeek 時，會更加關注提示詞的精準性，這一點在其他模型上可能沒有那麼重要。

DeepSeek 的優勢也非常明顯。首先，它的響應速度非常快。這可能有兩個原因：一是我們位於中國區，DeepSeek 作為開源模型，可以利用更好的資源和硬體，同時藉助就近的網路優勢，提供更快的速度。其次，從一些評測來看，DeepSeek 的生成速度確實更快，資源佔用也更少。特別是在程式碼生成方面，它的邏輯性表現非常出色。我們在使用中沒有發現它比 Claude 或 GPT 遜色很多，甚至在某些方面表現更好。因此，DeepSeek 迅速走紅，甚至出圈了。

我身邊很多朋友，即使不是程式設計領域的從業者，甚至不是程式設計師，也在關注 DeepSeek。朋友圈裡經常看到相關轉發，確實非常火熱。接下來，我們會進一步研究 DeepSeek 在程式設計領域的深度應用，比如在 Agent 規劃和複雜任務拆解方面的表現。

姜天意： 網易算是較早接觸 DeepSeek 的團隊之一。早年我們在做程式碼大模型微調時，選擇了 DeepSeek 的 Deep Coder 33B 作為基座模型，當時它是我們使用過的最好的開原始碼生成模型之一。而且，這家公司最初是做投資和量化的，這讓我們感到非常驚訝。

目前，我們主要在做兩件事：一是藉助 DeepSeek R1 進行模型資料合成和效果評測，二是探索其在程式碼生成中的應用。舉個例子，我們在微調模型時需要生成大量訓練資料，尤其是針對資料查詢生成 DSL（領域特定語言）。我們發現，DeepSeek 生成的效果已經接近 4O Mini，而且 R1 在多輪對話中表現出色，能夠透過深度思考檢查和修正結果。因此，我們認為透過最佳化提示詞和增加呼叫次數，它的潛力會更大。不過，我們也遇到了一些問題。例如，在進行任務拆解和程式碼生成時，推理結果非常準確，但實際生成的程式碼與推理結果存在偏差。我們猜測可能是思考過程佔據了較多上下文，導致輸出時未能充分啟用模型引數，或者 DeepSeek 對提示詞的敏感性不足。

此外 GPT-4 在 Agent 任務中的表現略優於 DeepSeek，但我相信 DeepSeek 後續會針對這些問題進行最佳化。目前，我的建議是將 DeepSeek 用於邏輯推理和任務拆解，比如使用者意圖識別和邏輯推理，而將程式碼生成交給更成熟的下游模型，例如 Claude 3.5 Sonnet 或 Channel Coder。單純依賴 R1 進行深度思考和程式碼生成可能不是最佳選擇，採用多 Agent 協同的方式會更有效。

馬翀： 大約一年多以前，我們在杭州多次討論了 AI 程式設計的未來發展方向。當時的一個深刻印象是，國內模型的起步時間與國外相比存在一定的滯後性。當時我們感到困擾的是，許多設想的 AI-first 時代的互動和產品功能形態，由於當時國內模型能力的限制，還難以實現。當時，我很期待大模型能在以下四個方面實現突破：

首先，是多模態能力的提升。多模態能力，意味著輸入和輸出的顛覆性變化，不同的互動方式會帶來全新的互動變革，從而對產品功能產生實質性的影響。

其次，是端到端延遲的極大提升。我記得一年多前，我們的第一版產品當時的端到端延遲最初高達十秒，後來逐漸最佳化縮短到幾秒，再到幾百毫秒。當時我們就在討論，如果延遲能降到 300 毫秒甚至百毫秒以內，AI 將給人感覺是從被動變為了主動，能夠即時響應使用者輸入，甚至對使用者後面的動作產生預判，這將極大提升使用者體驗。

第三，是從單輪到多輪對話的演進，多輪下保持輸出的穩定性。最初，AI 互動主要是單輪對話，像程式碼補全，是靜態的文字互動。如果能實現多輪對話，並處理好上下文的穩定性和生成的一致性，不是每次都重新生成，而是基於之前的對話進行增量式生成，這將為互動式 Agent 提供堅實的基礎。

第四，是成本的極大降低，幾個指數級的降低。如對比最初的大模型呼叫成本，模型側及工程側共同作用提升，成本起碼需要降低 1000 倍，否則高昂的成本將限制其廣泛應用。

如果當時能夠在這四個方面取得質的突破，那麼 AI 程式設計時代的顛覆性產品應該會很快到來。我們看到，國外的大模型，每隔幾個月就更新一次，交替領先。最先是 ChatGPT，接著是 Claude，之後是 Gemini，再如馬斯克的 Grok，彼此之間的競爭在加劇。當時我有種感覺，國內和國外的差距似乎在逐漸拉大。然而，令人欣喜的是，2024 年下半年越發明顯，無論是位元組的豆包，還是阿里的通義，以及最近行業矚目的 DeepSeek，都讓人感到國內大模型的能力，和國外頭部產品的差距在明顯縮拉近，拉近的速度越來越快，甚至區域性有超越。這個變化意味著我們在國內也能夠很快做出與國際水平全面接近的大模型，以前受限於模型能力無法實現的服務會獲得堅實基礎，這給我們這些從業者帶來了更多的信心。

姜天意： 在正常的業務開發中使用 Copilot 不用過多贅述，大家都在用。除此之外，我還有一些實踐經驗。首先，在進行測試時，我們嘗試將 AI 接入，效果還不錯。還有 AI 審查和 AI 掃描，早期的過程中，我們使用像 SonarQube 這樣的工具進行掃描，這個過程相對繁瑣，因為這些掃描工具會檢測出很多 code style 問題，但意義不大。後來，我們接入了 AI 審查的能力，它將 M2DIFF 內容和原始檔案交給大模型，然後生成一些非常有價值的建議，比如函式命名規範、哪些函式可以封裝，或者某些元件在初始化時沒有銷燬，可能會導致記憶體洩漏等問題。

AI 審查比一般的靜態掃描工具更強大，因此我們現在也在推動團隊使用 AI 審查，並根據團隊的實際情況新增一些規則。此外，由於我們是做 ToB 的，難免會涉及到 oncall 問題。因此，我們也在用 AI 進行臺賬和日誌解讀，它能夠幫助我們解析使用者執行時的報錯，並給出 AI 解讀。比如，一些配置問題或程式碼翻譯問題，AI 可以清晰地告訴使用者問題所在，使用者也能知道如何處理。

此外，我們還發現 AI 在掃描慢 SQL 時效果非常顯著。我們已經將這一功能整合到產品中，幫助使用者快速識別和定位慢 SQL 問題。現在，我們還在嘗試 ChatOps，與監控團隊合作。以前，分析或預警監控資料是個比較麻煩的事情。接入 AI 後，我們發現它在異常分析和變動分析上具有優勢，尤其是某些情況下機器的毛刺、水位異常等問題，AI 無需我們編寫規則就能有效處理。

最後，我想提一個我自己覺得非常好用的工具，我們正在使用 AI 工具進行程式碼最佳化和重構。早在 2020 年，我在阿里時，我們團隊開發了一個表格元件，這個元件在 GitHub 上有相當多的使用者。去年，我請求 Windsurf 幫我最佳化該元件的多維表格計算效能，結果它給出了幾千字的最佳化建議，令我非常驚訝。我測試了一些建議，確實有效地提高了效率。

段瀟涵： 首先，在公司內部，我們可以看到 AI 逐漸滲透到 DevOps 的各個環節。例如，在 Git 管理平臺上，最初是出現了 AI 對 commit message 的總結，或者是有機器人幫你進行程式碼審查。隨著時間的推移，基於大規模程式碼庫和索引，Git 平臺會逐步分析程式碼中是否存在變數命名問題、是否存在碎片化的函式等問題，這些功能也逐漸得到實現。我認為 Git 相關的演進還是非常迅速的，因為編碼與 AI 的結合，確實是大家探索的一個重點方向。

第二個方面是，在文件整理和架構設計時，我和團隊成員會使用一些 AI 工具。過去我們可能更傾向於使用 C4 模型和 Plant UML 來畫圖，但這些圖其實可以透過文字表達出來。很多時候，只需要清楚地表達需求，AI 就能快速生成相應的圖形。如果手動繪製，這個過程非常耗時，且需要考慮佈局和連線的問題。而透過程式碼轉化為影像，再結合 AI，可以大幅提升效率。還有，我們內部使用的飛書工具也包含了非常實用的 AI 功能，尤其是在多維表格和文件處理方面。過去我會自己整理對比表格，處理表格的寬度、高度和單元格合併等細節。而現在，我只需使用無序列表，完成後可以一鍵整理成表格，效率非常高。AI 還能幫助設定表格的寬度與最長的對齊，自動合併同類項，這對雲端文件非常有幫助。

回到我自己負責的 AI 與編碼相關的工作，我們在 IDE 中更多地考慮如何將 AI 能力整合到開發者的日常工作中。大家常見的就是聊天側邊欄功能，比如 Windsurf 和 Cursor 等工具，它們透過對話生成內容。除此之外，IDE 的基礎功能也可以與 AI 結合，比如在編輯器中，當出現 lint 類錯誤時，AI 可以快速聯動到聊天視窗，或者直接在原地更新程式碼。比如，使用 VSCode 或 JetBrains 等 IDE 時，AI 可以幫助分析語法錯誤，處理自定義的 lint 報錯，甚至檢測出程式碼中的潛在問題，在終端中除錯和檢視報錯時，AI 可以幫助我們快速判斷問題是出在程式碼還是環境配置上，這些都能透過 AI 提高開發效率。搜尋功能方面，AI 可以更好地理解自然語言，幫助開發者快速找到需要的內容。可以預見，在傳統 IDE 功能的基礎上，AI 將會為各個環節提供更深層次的支援。

姜天意： 我暫時把這個問題拆成兩個維度來討論。首先是生態位的維度，高程式碼開發者通常使用 Cursor、Windsurf、Trae 這樣的工具，而普通的產品經理現在可以使用 Bolt.new 或 Replit Agent 這類工具。其實，這中間缺少一個生態位，專門用於方便二次修改和編輯的位置。目前業內透過對話式工具或其他方式去做，難以達到精細控制的效果。我認為低程式碼正好填補了這個空白，它可以幫助非專業開發者，提升他們在二次修改和精細控制方面的能力。

另一個問題是，什麼樣的語言能夠與大模型真正有效地互動？從輸入的角度來看，使用自然語言與大模型進行互動不一定高效。很多公司嘗試用自然語言輸入，但常常需要輸入大量內容。例如，要生成一個採購表單，如果這個表單有 200 個欄位，如何逐個輸入？這就非常困難。所以，很多公司開始嘗試使用類似“PRD to code”這樣的功能，說明自然語言本身存在侷限性，比較模糊，效率並不高。

因此，我們正在探索一個方向，即建立一個新的語言體系，將多個技術棧融合起來，作為傳統程式語言與大模型之間的橋樑。我們開發了一個叫做 NASL 的低程式碼 DSL（領域特定語言），它將頁面流程、邏輯、資料查詢等進行了高階抽象。當我們與 AI 互動時，它首先生成一個與技術棧無關的部分，然後根據使用者的技術棧，像是 Spring Boot 2、React、Vue 等，再將其翻譯成對應的程式碼。

低程式碼為什麼適合這一方向呢？因為它天然具有抽象能力。無論是我們開發的 NASL，還是百度的 AMS、阿里的 Local Engine、位元組的星圖，它們其實都有 DSL 的概念。DSL 概念天然對 AI 友好，因為它不像傳統的程式語言那樣包含大量的技術棧，也不像自然語言那樣模糊，它是一種較為精確的中間語言。因此，我認為低程式碼是一個很好的機會，可以創造一種與 AI 互動的中間語言，從而實現高效生成。

馬翀：處於 AI 時代，我們面對的生產力提升和新的生產關係，會給我們自己帶來什麼機遇？瀟涵你們團隊本身也在進行前沿的實踐探索，在這方面有沒有一些經驗或建議可以分享？

段瀟涵： 我認為在我們團隊內部，AI 給同學們帶來的機遇主要是拓寬了大家的能力邊界。過去，各個職能的分工非常明確，但是隨著 AI 的出現，很多工作，尤其是一些不需要非常深入的任務，跨職能的界限變得模糊了。很多時候，一個服務端開發人員負責的模組，正常情況下需要前端開發人員配合，但有了 AI，很多時候他們可以獨立完成一些小需求。這種職能邊界的模糊以及能力的拓展，實際上也對業務節奏產生了正向的推動作用。

不過，這也帶來了一些挑戰，因為 AI 雖然能拓展能力，但它本身仍然具有不確定性，這就要求同學們學會審視 AI 生成的程式碼。當 AI 生成程式碼時，大家需要結合搜尋引擎、其他文件以及官方文件來判斷這些程式碼是否可用，只有確認可用後才能採納，讓大家從單一職能逐步向交叉職能過渡。在過去，跨職能的學習其實是非常困難的。但有了 AI，藉助 AI 提供的一些思路和方案，作為切入點，大家可以更容易地深入到新的領域，而不再覺得學習的過程那麼痛苦。

馬翀： 我們這兩年都有聽到一些聲音，討論某些職能是否逐漸失去重要性。例如，我最近還和主編開玩笑，提到今年 QCon 的大前端主題叫做“越挫越勇的大前端”。好不容易這些年大家已經差不多忘記了“前端已死”這個梗，快沒人提了，結果又來了這麼一個專題。雖然這是個玩笑，但確實最近可以看到一些職能的同學，比如前端工程師或者 QA（Quality Assurance，質量保證），開始討論這些職能是否會逐漸變得不那麼重要。尤其是當業務進入平臺期之後，0 到 1 的創新機會在變少，工程化進入穩定階段，複雜度和業務支撐體系呈現一定的固化趨勢。工程化的穩定，職能如前端的很多技術複雜度會被成熟的工程化方案封裝起來，那麼機會是不是變少了？

我覺得不是，工程化是技術建模，而 AI 的發展能為技術職能如前端等帶來更多賦能業務建模的機會。比如，在之前的業務，從事 B 端的前端開發者在晉升方面可能相對處於劣勢。與 C 端相比，B 端的業務量級通常較小，不如 C 端業務規模大更能夠提供放大效應。和基礎工程的比，B 端的技術複雜度又往往比不上做基礎架構的。B 端開發者在職業發展上可能會面臨更多挑戰。

但如前面所言，在 AI 時代，很多嗅覺敏銳、動手能力強的工程師，尤其是前端工程師，會看到很多新的機會。最近我觀察到，一些 B 端前端開發者由於具備直接的平臺開發能力，能夠直接對接 AI 模型並呼叫大模型的 API 介面，在不需要服務端強配合的情況下，也可以直接與模型進行互動，包括調參、訓練以及 Prompt Engineering 等工作。只要他們能夠結合業務需求提出創新想法，就有機會推動一些具有實際價值的能力落地。

舉例來說，B 端都是平臺化產品，各種表單、流程系統等，產品文案常常被使用者批評為“不說人話”，尤其是在表單欄位的設計上。許多欄位需要額外新增說明（如小問號圖示），因為使用者難以理解其含義。無論是入駐流程還是消費場景，不同使用者群體都可能遇到理解障礙。最近我注意到一個案例：有開發者利用 AI 技術檢查文案的有效性，識別潛在的歧義或合規風險，甚至實現了巡檢功能（包括前置和後置檢查）。這些能力可以基於 AI 模型快速搭建，且無需跨職能團隊的廣泛參與，前端開發者可以獨立完成閉環。這為 B 端開發者帶來了新的機遇。

對於 B 端開發者而言，AI 的結合為業務帶來了新的可能性。這種機遇甚至可能比以往從 0 到 1 的新業務更具潛力。但關鍵在於，開發者是否能夠洞察當前業務階段及其未來演進方向，識別業務痛點，並圍繞這些痛點提出技術驅動的解決方案。如果開發者對業務有足夠的敏感度，那麼在 AI 時代，他們將迎來更多的發展機會。

馬翀： 剛剛聊了不少關於 AI 如何驅動程式設計能力的內容，接著咱們聊聊“方法論的升級”，比如 團隊協作上，如何把個人使用 AI 工具的零散行為或經驗，上升到團隊協同的標準化流程？再比如，針對不同框架、老舊系統或新興技術，團隊是否需要定製化的 AI 策略？

姜天意： 我認為在 AI 時代，“AI 友好”（AI Friendly）是一個非常重要的概念。首先，我們需要善於發現 AI 擅長的事情，而不是為了使用 AI 而強行應用。以我的經驗為例，2022 年我們在騰訊雲落地 AI 專案時發現，AI 在生成 Swagger 程式碼或 HTTP 介面時表現較為吃力，但在生成 GraphQL 程式碼時效果卻非常好。這讓我們意識到，大模型對 GraphQL 這類結構化資料的理解可能比業務程式碼更清晰。此外，我們還發現，AI 在生成 Next.js 或 Tailwind CSS 等技術棧的程式碼時表現優異，但在生成 Element 或 Ant Design 的程式碼時效果則大打折扣。因此，選擇 AI 擅長的領域進行程式碼生成或訓練，遠比強行套用 AI 更為重要。

第二點是我對團隊內部的要求：將 AI 視為團隊的一員，確保程式碼具備“AI 友好”特性。大家都知道 RAG 的概念，程式碼 Colipot 工具在理解或搜尋程式碼時，需要透過 RAG 的方式尋找合適的程式碼片段。如果 API 設計清晰、註釋完整、型別明確，AI 很容易引用這些程式碼。但如果程式碼結構複雜、介面命名混亂，AI 補全或生成的難度就會大大增加。因此，讓 AI 理解程式碼就像讓人理解程式碼一樣，必須確保程式碼易於閱讀和分析，這樣才能更好地支援 AI 的補全和分析功能，這也是 AI 時代帶來的一個重要變化。

段瀟涵： 過去，開發者更多關注如何編寫程式碼、如何使程式碼更優雅、架構更合理。而在 AI 時代，開發者需要更多地思考如何將問題想清楚、描述清楚，因為 AI 的效力在很大程度上取決於我們是否能夠清晰地定義問題。只有當我們對問題有清晰的理解時，AI 才能更好地執行任務，從而發揮其最大價值。正如前面提到的，有些任務適合 AI 處理，而有些則不適合。AI 並不會完全取代開發者，而是作為開發者的補充或輔助工具，最終的效果仍然取決於開發者自身的技能水平以及對問題的分析能力。因此，開發者的關注點正在從單純的編碼轉向如何梳理問題、設計架構。當我們能夠清晰地定義任務並將其交給 AI 時，AI 的執行效果會非常好。這也解釋了為什麼開發者對 AI 的態度存在分歧：一部分人認為 AI 能顯著提升效率，而另一部分人則認為 AI 生成的程式碼需要大量最佳化和調整，反而不如自己編寫，這種差異實際上反映了開發者與 AI 互動時的表達能力。未來，如何更精準地編寫 Prompt 將成為一項重要技能。

另一個挑戰在於程式碼審查。AI 生成的程式碼是否可信？目前還沒有一種特別有效的手段能夠自動化地判斷 AI 生成的程式碼是否可以直接採納。傳統的程式碼審查更多依賴於對同事的信任，因為長期合作讓我們瞭解某些同事在特定領域的專業性。然而，AI 並不具備這種背景。目前，我和團隊內的成員更多采取一種“預設不信任”的態度，以挑剔的眼光審視 AI 生成的程式碼。但隨著 AI 技術的進一步發展，大規模生成程式碼將成為常態。為了提升效率，我們必須找到一種自動化評估程式碼可信度的方法。這不僅對開發者是一個挑戰，對後續的 QA 團隊也是如此。現在，QA 團隊的工作已經不再侷限於功能測試，一些新型團隊（如效果評測團隊）正在興起，專門針對大模型生成的內容進行評估。

段瀟涵： 我們團隊原本是一個常規的工程研發團隊，在轉向 AI 領域時確實經歷了一段調整期。對於從 NLP（Natural Language Processing，自然語言處理）領域轉型過來的同學來說，他們在模型訓練，尤其是大模型訓練方面有一定的積累，這為他們理解和使用 AI 技術奠定了良好的基礎。此外，AI 領域的一些關鍵技術概念也是普通研發團隊在轉型過程中必須掌握的內容，這些都需要逐步補充。不過，我們並不是純粹的演算法團隊，因此對技術深度的要求相對適中，不需要深入掌握各種神經網路的知識，但至少需要了解大語言模型的基本構建方式，以便更好地輔助團隊使用 AI 技術。從團隊成員的視角來看，大家對 AI 的興奮感遠大於轉型的陣痛。AI 技術確實帶來了非常積極的影響，大家對它充滿期待，也覺得它非常有趣。因此，我們是在不斷摸索中逐步轉型，並逐漸掌握瞭如何在 AI 領域進行工程實踐。

姜天意： 我有一個很強烈的感受：跨界並不一定是壞事。特別是在早期，很多前端工程師開始嘗試調大模型時，演算法團隊通常更關注演算法的準確性，即生成的內容是否精準。然而，前端工程師則更傾向於透過工程手段解決問題。例如，內容的過濾、重組和計算，演算法團隊可能希望一步到位，透過一個 prompt 就能生成 100% 準確的內容。 但前端或工程團隊的同學會採用一些工程化的思路，比如透過 fixer、checker 或多輪對比、打分等方式來最佳化結果，這種工程化的解決思路與演算法並不衝突。尤其是在去年，當 AI 能力還不夠強大時，我們面對多模態模型時，就採用了規則加多模態識別的方式。

因此，我認為純工程師的跨界轉型反而可能成為一種優勢。過去，演算法工作被視為門檻極高，演算法工程師的薪資和學歷要求通常也是最高的。但隨著技術的發展，演算法的門檻逐漸降低，普通研發工程師也能夠透過結合自身的工程能力，低成本地呼叫演算法能力。比如，擅長前後端開發的工程師，如果能夠輔以一定的 AI 演算法能力（如動態識別、程式碼生成、文字生成等），將會顯著提升工作效率，加速任務的完成。

段瀟涵： 我的看法可能更積極一些：AI 目前更多是輔助工程師的角色。在開發過程中，我們常常感受到時間緊迫和排期壓力，這通常源於從技術分析到實現、測試再到上線的整個流程中有大量工作需要完成。在這個過程中，如果開發者能將一些輔助性、重複性的工作交給 AI 來完成，自己更專注於核心鏈路的設計，效率提升會非常明顯。我不確定未來幾年，模型能否做到僅透過一句自然語言指令就能完美分析並完成任務。如果真的到了那個時代，討論 AI 是否替代人類可能會更合適。

我們現在做的很多事情都是在為模型的輸出“擦屁股”，因為模型的輸出具有很大的不確定性，尤其是在結構化任務方面。儘管最近一年隨著 Claude 3.5、GPT-4o 等技術的出現，情況有所改善，但仍然無法完全避免問題。因此，我們的大部分工程工作都集中在這些方面。如果 AI 模型的能力逐步提升，趨近於百分百的準確性，那麼開發者的精力將得到釋放，開發 AI 型應用的成本也會進一步降低。有編碼經驗的人可以藉助 AI 開發出更好用、更炫酷的軟體。同時，基於 AI 的生產工具（如 IDE）和低程式碼平臺，非研發人員也能參與到程式碼生成中。

舉個例子，我的一位保險代理人最近在使用線上的 AI 平臺來幫助他規劃客戶關係網狀圖，分析客戶在特定週期內需要更新的稅務規劃。這非常有趣，因為他完全不屬於編碼行業。我認為 AI 的積極作用在於幫助人們拓展編碼能力：不會編碼的人可以用它來編碼，而會編碼的人則可以更高效地開發出更有意義的工具。除非未來某天模型具備了“自主意識”或超高的“智商”，否則 AI 更多是輔助工具，而非完全替代人類。

馬翀： 最後我們來聊一下產品表達，互動正規化，這也是我最近想的比較多的方向。雖然低程式碼平臺在垂直領域的一些環節做了最佳化和標準化，但它並沒有完全打破傳統工程時期的互動流程。在生產力工具範疇，無論是 MarsCode、Trae IDE，還是 Cursor、Windsurf、Copilot 等工具，它們也多是在目前工具產品的基礎上在做加法及輔助性改進，而並未顛覆過去十幾年工程時代形成的以人編碼為核心的互動方式。如果我們展望未來 10 年，AI 驅動的時代，在 AI-first 視角，是否會出現以 AI 為核心的新的互動正規化和產品表達？

姜天意： 我們認為，早期做需求時採用的是列舉式策略，也就是分支式策略。產品需要為不同使用者預留不同的 Landing Page 來承接流程。例如，如果你有一個 SOP（標準操作流程），就需要一個專門的 SOP 頁面來承載整個流程，這導致系統變得非常臃腫。 而在 AI 領域，第一個可能帶來的變化是從列舉式系統轉向動態式系統。未來的入口可能是一個超級 Agent，整個介面會根據使用者的需求動態生成。例如，當你提出“我要下一個採購單”時，系統不會使用預置的採購介面，而是根據你的 prompt 和需求動態生成一個互動介面。這種變化可能會徹底改變 ToB 系統的互動方式。比如，CRM 領域的 Agent Force 就在做類似的事情。他們已經掌握了各種場景、資料、業務流程和介面，只需要構建一個 Headless 系統，能夠分析使用者意圖並動態生成介面即可。因此，我認為這可能會對傳統互動方式帶來變革。

此外，AI 在計算機操作能力方面也有顯著優勢。去年我們在做自然語言生成 SQL 時，我認為這個方向並不理想，因為自然語言過於冗餘，生成的介面效率未必比 GUI 高。我認為，能夠透過自然語言輸入的系統早已存在，比如 Siri，我們沒有必要為了某個功能再專門開發一個 LUI（語言使用者介面）。然而，一旦計算機操作能力出現，情況就會改變。大模型對外界的互動能力將從傳統的 Function Call，提升到對介面、世界甚至介面的理解。

例如，Claude 團隊提出了 MCP（Model Ccontext Protocol）的概念。未來，所有的服務介面、資料庫或操作指令都可以變成一個 FM（Function Module），並透過 MCP 協議被大模型呼叫。這將徹底改變產品的互動形態。所有的入口和處理路由都集中在大模型側，開發者只需提供各種服務並暴露 MCP 介面，大模型就可以呼叫它們。這將形成一個網狀、離散的“用完即走”的生態系統，超級 APP 的概念也將不復存在。

段瀟涵： 關於 MCP，雖然 Claude 提出了這種互動理念，但歷史上類似的事情並不少見。回想移動網際網路時代，最初大家各自為戰，後來出現了 APP link 等協議，實現了 APP 之間的互跳，甚至逐漸完善了許可權控制。我認為，在 AI 時代類似的情況可能會重新上演。AI 的互動方式將迎來變革，甚至未來可能不再需要 GUI。雖然短期內可能還無法實現，但從長遠來看，GUI 可能不再是一個強需求。目前，除了 MCP 這類協議，還有一些更前沿的嘗試，比如為 AI 時代開發的作業系統，這些變革可能會深入到技術底層。作為開發者，我們需要持續關注這些變化，思考如何在這樣的時代背景下提升自己的工程能力和編碼能力，以適應未來的技術演進。