隨著技術的飛速發展，AI 浪潮正在重塑行業格局，工程師們站在變革前沿，機遇與挑戰並存。一方面，強大的 AI 正在衝擊著工程師的傳統工作領域；另一方面，AI 又給很多工作帶來了新的可能。那麼，如何讓 AI 成為自己發展的“助力”而非“阻力”呢？

近日 InfoQ《極客有約》X QCon 直播欄目特別邀請了美團研究員丁雪豐擔任主持人，和華為雲計算服務產品部軟體專家張建飛、正馬軟體 CTO 沈淦 一起，在 QCon 全球軟體開發大會 2025 北京站即將召開之際，共同探討 AI 時代下工程師的應對法則。

部分精彩觀點如下：

丁雪豐： 首先我們來個熱身話題，說說現在行業的一些情況。今年剛開年的時候，扎克伯格就宣佈 Meta 今年要用 AI 取代中級軟體工程師，同時，Salesforce 方面也表示今年不再招聘軟體工程師，這些林林總總的訊息，似乎都在進一步透露出“AI 將取代很多軟體工程師”的未來，於是，在技術圈，這波因為 AI 大幅提升生產力的興奮之下，也不免充斥著一些焦慮。

從各位近期的觀感來看，關於“AI 取代工程師”的話題，真的有那麼讓人焦慮嗎？AI 的引入對初級和中級工程師的就業來說具體有什麼影響？

沈淦： 一線同事關注提高效率，而管理者則更看重整體的投資回報率（ROI）。舉例來說，使用 AI 輔助一個全新的系統效果明顯，因為它不依賴外部呼叫，功能直接。例如，簡單的增刪改查應用效率提升非常快。但在老舊系統中，修補和調整的工作更多，這對新手來說，使用 AI 輔助的挑戰較大。而管理者的職責是準確劃分任務，明確封閉性和開放性問題。

張建飛： 事實上，很多科技公司目前都在控制人力成本，這與是否能被 AI 取代沒有直接關係。特別是 Salesforce，一直專注於 SaaS 業務，產品成熟後，確實不需要那麼多工程師。短期內，尤其是在生成式 AI 尚未成熟之前，軟體工程師很難被取代，通用人工智慧的實現還需要很長時間。

AI 可以生成一些簡單的程式碼，但這通常是一次性生成，除非不再修改，否則後續的維護和改動仍然需要人工干預，你無法透過 AI 自動生成和維護一個複雜的軟體系統。軟體開發的大頭並不在首次編寫程式碼，而是把 80% 的精力都放在後期的維護、修 Bug。根據現有的程式設計正規化，我還沒有看到 AI 能夠很好地承擔後期維護工作。當然，AI 作為一個提高效率的工具，用於輔助程式設計是沒有問題的。

丁雪豐： 以前我和別人討論過一個故事：兩個人在森林裡遇到了一隻老虎，一個人轉身就跑，另一個人問他：“我們跑不過它，你跑什麼？”他說：“只要跑得比你快就行。”其實，與其擔心是否會被 AI 取代，不如想想，最終打敗我們的可能不是 AI，而是身邊那些更會使用 AI 的人。我們可以看到身邊的同事在使用 AI 時，能夠提供更好的提示詞和輸入，清楚地拆解任務，然後藉助 AI 完成工作。相比之下，剛剛進入這個行業、仍在處理簡單任務的人，可能會感受到 AI 帶來的生產力差異。

如果一項工作很容易被 AI 取代，那麼你應該反思一下，可能這項工作本來就不是你的強項。我認為 AI 並不是要取代軟體工程師，而是幫助提升大家的生產力。越有經驗的人，越能更好地利用 AI。而對於初級程式設計師，AI 也能幫助提升他們的工作效率和質量。因此，我們可以將 AI 視為一個輔助工具，像夥伴一樣合作。

張建飛： 軟體開發不僅僅是寫程式碼，這只是其中的一小部分。它還涉及到權衡、思考、設計、架構，特別是在複雜場景下的解決方案，甚至包括協作和溝通等因素。

丁雪豐： 毫無疑問，AI 的迅速發展能讓工程師的效率大幅提升，提升生產力。拋開對於被取代的焦慮和討論，其實對於工程師來說，享受這些 AI 帶來的好處，享受當下、利用好 AI 或許才更實際。那麼，AI 對軟體開發流程是否有明顯的“重塑”？以及工程師在其中可以怎麼利用好 AI 快速推進專案、同時自己也能從中獲益 / 有所提升？

張建飛： 在華為，我們有一個叫 Code Submit 的工具，類似的工具在我們的編碼過程中會結合程式碼的上下文，即時給出提示，並且隨著使用，工具的最佳化使得它能猜測你接下來要寫的內容，這提高了工作效率。另外，我現在也經常使用程式碼審查工具。我會先讓 AI 掃描程式碼，然後檢視它認為較為關鍵的問題，這可以在審查時節省大量時間。

還有一個最近的故事，我妻子在一家設計公司工作，最近他們接到一個絲綢公司的專案。設計公司本來是透過手繪進行設計，但這個專案要求不僅僅是圖片，還要將圖片轉化為絲綢織物，這就需要程式設計來實現。她的老闆知道我從事這一行業，便問我是否能幫助實現。實際上，我對計算機繪圖並不熟悉。於是，我拿著他們的樣例圖片去詢問豆包和 DeepSeek，經過幾天，我成功開發出了一款基於貝塞爾曲線的計算機繪圖工具，滿足了他們的需求。對於不熟悉的領域，AI 對我幫助非常大，否則我以前可能會依賴百度或 Google，但效果並不如意。

沈淦： 在我們具體的專案應用中，大多數專案不是純粹的 AI 專案，而是把 AI 能力以外掛形式整合到現有工作環境中，我們的做法主要是將 AI 與現在的工程體系及整個開發流程（pipeline）結合。

在敏捷開發的過程中，很多環節看起來設計得很好，但實際操作起來並不容易，例如程式碼審查環節，雖然我們推行過一定的標準，但實際執行效果有限。不過，隨著 AI 的介入，這些環節變得更加紮實，尤其在敏捷開發過程中，它對整體推進有很大的幫助。

另外，AI 對開發過程中的“左移”也有很大幫助。例如，介面開發和測試的左移，AI 輔助的效果尤為明顯。我們鼓勵每個開發者提交併使用 AI 工具，並透過統計使用率來評估效果，而不是僅僅關注最終的確認率。這樣，我們可以在關鍵環節透過 AI 工具實現敏捷開發中的常見做法，並將其做得更紮實。這對團隊幫助很大，特別是一些做得比較好的團隊，他們將從需求開始到釋出的整個過程基於使用者故事進行管理。過去這些環節依賴人工，工作量很大，而有了 AI 的幫助，效率和效果都顯著提升。

丁雪豐： 美團也有內部的工具。在我們的工作中，有些介面程式碼是自動生成的，AI 的幫助使得很多專案的程式碼生成更加高效，尤其是對於新專案，AI 可以透過無程式碼的方式直接幫助我們生成整個專案。效果整體來看不錯，日常編碼中，大約有 30% 的程式碼可以直接透過 AI 輔助生成。

我寫 Python 程式碼時，AI 可以根據我的需求自動生成專案結構和程式碼檔案，包括確認所需的庫和版本，這對於日常瑣碎任務的效率提升非常顯著。如果是一個正式的工程專案，AI 也能根據需求自動生成和修改程式碼。在除錯時，以前我們可能需要在 Google 上搜索問題，最終到 StackOverflow 複製貼上程式碼，但現在直接右鍵點選，AI 就可以為我們提供解決方案，極大地簡化了除錯過程。

張建飛： 在整個開發流程中，程式碼審查非常重要。谷歌提出了程式碼可讀性的審查標準，要求程式碼必須透過審查才能合併到庫中。華為也借鑑了這一思想。在提交 MR（合併請求）時，我們有自己的 Git 分支，原則上程式碼需要由提交者或程式碼倉庫的負責人進行稽核。通常，至少需要兩個人確認程式碼無誤，才能合併。

我們之前的流程是：在審查過程中，發現問題直接評論，並要求開發者修正。只有在問題解決後，才能點選合併。現在，我們將 AI 工具整合到這個環節中，使用 CodeMat 工具進行自動化審查。該工具會自動標出潛在問題，我會先檢視這些問題，若有效則直接接受，否則繼續手動審查。

丁雪豐： 接下來，我們來討論今天的第三個話題——工程師核心競爭力的再定義。現在矽谷也興起了新型開發模式“Vibe Coding”，所謂氛圍編碼或隨性編碼，由 OpenAI 聯合創始人 Andrej Karpathy 所提出，Vibe Coding 基於對話和反饋迴圈，會更注重開發者和 AI 的互動。但也有觀點認為，過度依賴 AI 可能導致對系統架構的理解不足，也會引入許多問題。所以，在各位看來，在 AI 的輔助下，工程師應重點培養哪些核心能力以保持競爭力？如何看待“**VibeC**oding”對傳統程式設計正規化的衝擊？

沈淦：Vibe Coding 的方式對於那些有創意但程式設計能力不強的人幫助很大，對於有較強程式設計能力的人來說也是有效的。我最近在做一個研究專案，涉及到一個複雜的前端介面模擬。雖然我不是前端工程師，但透過 AI 工具，我只需簡單描述，工具就能快速生成前端介面，這讓我驗證其他部分想法時更加高效。對於有一定工程素養的人來說，描述清楚後，AI 可以在半小時到一小時內完成整個介面的生成，這種方式對探索新事物和創意實現非常方便。

丁雪豐： 關鍵在於抓住使用者痛點，程式設計不再是障礙。

沈淦： 簡單應用是可行的，但複雜應用，尤其是邏輯複雜的，仍然有門檻。

張建飛： 低程式碼和 Vibe Coding 讓我想起了之前被廣泛討論的 Codeless。雖然低程式碼有其應用場景，但當複雜度達到一定程度時，低程式碼其實只是更復雜的程式碼，它並沒有真正簡化開發流程。因此，對於複雜應用，AI 目前還難以處理端到端的功能，尤其是商業級複雜系統。Vibe Coding，其實類似於 Prompt Engineering，和 AI 輔助程式設計並沒有本質區別，都是基於意圖的程式設計。

沈淦：Vibe Coding 指的是完全透過口語描述來實現程式設計，幾乎不需要寫程式碼。

張建飛： 這是目前無法實現的，就像低程式碼一樣，複雜系統無法透過這種方式完成。

丁雪豐：Vibe Coding 的應用場景，包括非技術人員參與、快速原型開發和教育協作。但對於複雜業務需求，AI 生成的內容仍然有限，特別是當需求沒有明確時，AI 生成的東西往往無法滿足真正的需求。

張建飛： 這確實是一個挑戰，尤其是產品經理自己都不清楚需求時，AI 無法提供有效幫助。

丁雪豐： 除此之外，AI 無法替代我們承擔責任。它不能簽字，出了問題，更不能找 AI 來背鍋。按這個邏輯，大概程式設計師永遠不會被取代吧。

張建飛： 軟體工程其實就是一個“草臺班子”，看起來很工程化，實際上充滿混亂和無序。需求不清楚時，AI 無法幫助生成準確的程式碼。

丁雪豐：程式設計師和 AI 的區別在於，我們能更好地理解需求背後的意圖。往往需求本身並不完全是問題所在，我們透過理解背後的真正意圖，可以找到更有效的解決方案。

張建飛：AI 可以幫助我們梳理需求，它能夠考慮我們可能忽視的點並提供反饋，尤其是在深度思考和需求解析方面。

沈淦： 大多數被取代的可能是那些依賴經驗的初級程式設計師，因為這些人更多的是處理非工程類的工作。隨著 AI 的發展，這些工作可能會逐漸被自動化。我對 AI 的看法比較積極，認為它會對軟體行業帶來巨大的價值。AI 能夠將我們之前的“草臺班子”式的工作方式逐步轉向更加工程化的方向。就像工業革命一樣，AI 為我們的工程化能力提供了強大的支援，這使得我們能夠朝著更高效的生產力和規模化方向發展，特別是敏捷之前不容易做到的環節現在藉助 AI 來推動的話，門檻變低了很多。

所以我認為，AI 不會取代所有程式設計師，尤其是那些有經驗、擅長處理複雜問題的程式設計師。反而，隨著工程化的提升，這些程式設計師會變得更加重要。AI 的到來將解放更多的人的工作，使得整體工作效率大大提高。

丁雪豐：AI 確實提高了效率，但提效不意味著工作快速完成後就可以休息。反而是 AI 提高了生產力，本來一天能完成一個需求，現在可以完成兩個需求。

回到前面討論的 Vibe Coding，假設需求依舊如常，但如果我們再往前想一步，假設這個需求也是由 AI 生成的。那麼，是否可能是產品經理透過 AI 生成需求，程式設計師只需討論或者甚至不需要介入，產品經理直接讓 AI 實現需求？這就可能帶來一種不同的場景，和我們現在討論的有所不同。也許每個工程師的角色會轉變成，如何讓 AI 理解並執行 AI 生成的需求，這可能是未來的一種新情況。

沈淦： 效率優先的環節將逐步被 AI 接管，最終有可能完全由 AI 掌控，而人類則只會出現在那些效率優先環節無法滿足的任務中。

丁雪豐： 現在我們還在用傳統軟體開發流程思考這個問題，但未來，流程也許會變得不同，可能會變成一個面向 AI 的、AI 原生的流程。現在應該已經有一些開發 Agent 或者軟體相關的研究正在嘗試這個方向。這不一定是顛覆性的，而是新的嘗試或工作方式。隨著新一代同學進入職場，他們從學習階段就接觸 AI，因此他們的思考方式和工作方式會和我們現在大不相同。那時，可能連 Vibe Coding 都不再是主流，生產方式和模型可能會完全不同。

張建飛：我剛才提到的程式設計正規化，確實是基於我們這一代人的思維和幾十年前圖靈機的基礎。但不排除有一天，程式設計不再需要理解程式碼，出現全新的正規化。

沈淦： 我們常說“一次編寫，到處執行”，AI 也有類似的嘗試，被稱之為“再生式程式設計”，就是每次都根據功能需要重新生成完整的程式碼，甩開對遺留程式碼的依賴，認為完備的功能描述才是關鍵，程式碼本身並不重要。他們每次只需要透過提示詞，就能生成全新的應用，而不再需要像現在一樣進行迭代或重構。每次生成全新應用的好處在於，如果效率足夠高，重新生成比修補原有程式碼更高效。雖然現在我們不敢完全採用這種方式，因為重新寫程式碼太費力，但如果效率提升到一定程度，完全可以考慮這種方法。

張建飛： 我不確定這種方法現在的發展情況如何，但我之前提到過，生成一個簡單的專案可能沒問題，但對於稍微複雜的應用就難度很大了。就像我們做電商一樣，每當你在頁面上點選一個請求，背後涉及的路徑和技術點是非常多的。如果能夠做到每次生成這些複雜的內容且不重複，那的確是一個突破。

張建飛： 前幾天我面試了一位來自美國特斯拉的工程師，特斯拉是埃隆·馬斯克的公司，而我對馬斯克的工程文化非常感興趣。當馬斯克收購推特時，他裁員了 85%，只留下寫程式碼的員工，並要求所有人一個月內必須有程式碼產出，否則就會被裁掉。我認為，馬斯克是一個非常看重工程師文化的人。我面試特斯拉員工時，基本沒問技術問題，而是問了很多關於軟體工程文化的問題。我問他怎麼評價特斯拉的程式碼，他說了一些優點，也提到了一些不足。給我印象最深的是，他提到，特斯拉發展非常快，這也意味著程式碼更新很快，常常攢出來的程式碼不一定是最最佳化的。從我接觸的全球公司來看，包括國內外的大廠，如 Google 等，似乎沒有一個能做到完美的軟體開發。

張建飛： 我看到有同學提到一個問題，說現在很多大公司只招具有 AI 能力的工程師，感覺很多職位都與 AI 相關。我認為，AI 工程師和有 AI 能力的工程師是兩類人。例如，AI 相關的工作可能包括大模型的開發、底層計算相關的工作，或者模型微調等。這一波 AI 技術，尤其是 RNNs 的應用，肯定會帶來需求的增長，隨著 AI 技術的廣泛應用，對 AI 工程師的需求會進一步增加。

但對於我們更多的系統工程師或應用開發工程師來說，我認為具備 AI 能力並不像大家想象的那麼難。如今，AI 輔助工具已經幫助我們提升了工作效率。無論是程式碼生成、編寫單元測試，還是程式碼審查等工作，都可以藉助 AI 工具來完成，這並不困難。我們可以讓 AI 來幫助我們提高效率，這一點應該不算難。使用 AI 工具並不難，關鍵是找到合適的工具來幫助提升效率。大多數公司，尤其是 90% 的公司，實際上都已經在使用這些工具，大家每天都在使用 AI 技術，我相信這個趨勢會持續發展。

沈淦：AI 對所有人來說都是新鮮的技術。第一步是儘快投入使用 AI，先用簡單有效的方式應用。第二步，想成為更強的工程師，就要理解 AI 的邏輯，尤其是與傳統程式設計的不同之處。

我建議大家要多強迫自己和 AI 對話，少埋頭寫程式碼。透過與 AI 互動，逐漸理解它的程式設計方式。舉個例子，AI 可能會按照標準格式修改程式碼，如異常處理。但每個公司有自己的邏輯，按照 AI 的標準格式可能會出現問題。所以，想更好利用 AI，就要主動與 AI 互動，作為輔助工具，而非完全依賴它。

張建飛： 另外，鑑別任務也很重要。你要判斷 AI 生成的內容是否正確，還要評估其生成的結果是否有益。這種鑑別能力來源於什麼呢？歸根結底，還是我們的工程能力和程式設計能力。因此，作為軟體工程師，紮實的基本功永遠是無可替代的。

丁雪豐： 美團入職培訓時的老師曾經對我們說過一句話，甚至這句話現在還經常會被提到：“我不會，但我可以學。”現在，藉助 AI、搜尋引擎和網際網路，學習已經不再是難事，但有些人卻不願意去學。最核心的，還是要提高主動學習的意願和能力。未來的價值不在於你已經掌握了什麼，而在於面對未知時，你的適應能力和靈敏度有多快。優秀的工程師，尤其是那些對技術充滿熱情的人，一定會是最早跟上去的，可能是第一批，也可能是第二批。

目前，AI 給出的結果不一定是對的，但我們不能排除未來幾年它會變得更準確。你要知道它是否對，這種判斷能力非常重要。我想起英國科幻作家道格拉斯·亞當斯曾說過：“所有在我出生之前發明出來的東西都是理所當然的；所有在我 15–35 歲之間發明的東西註定是要改變世界的；所有在我 35 歲之後的發明都是反人類的。”但現在，我們認為 AI 並不是反人類的，它會造福世界、造福我們的生活。只要保持學習的動力和勇於嘗試的心態，這才是最重要的。至於我現在使用的是 GPT 4.0、DeepSeek 還是 Claude 3.7，我並不關心，只要能有效利用它們，達到目標就好。

張建飛： 直到目前為止，我們這個群體是 AI 熱潮中受益最明顯的群體之一。作為技術人員，我們本就常接觸網際網路和新興技術。身處這個行業，就註定要不斷學習。所以，我們這一群體本身已經走在前面，不存在說我們需要去對抗 AI 的情況。

其次，接受了 AI 後，如何有效使用它是關鍵。隨著技術的發展，AI 將變得越來越成熟、易用。但歸根結底，工程師自身的能力，尤其是基本功，才是最重要的。比如，你原本程式碼寫得不好，AI 可以幫助你快速生成一些程式碼，但這並不意味著你的編碼水平會因此提高。所以，我建議大家還是要把精力集中在基礎能力上——編碼能力和設計能力。這些能力，即使在 AI 尚未取代我們的工作時，依然不會讓你失望。如果你想在這個行業長久發展，打好基礎是至關重要的。

丁雪豐： 除了基本的技術能力，還需要具備溝通能力和理解他人意圖的能力。儘管 AI 能夠幫助我們解決技術問題，但我們能夠解決提出問題的人所帶來的情緒價值，這也是一種重要的價值。

沈淦： 真正的學習能力不僅僅是學習，還包括求證的習慣。現在資訊量太大，真假難辨，因此，在學習自己感興趣的領域之後，必須具備快速驗證的動手能力，這樣才能真正發揮學習的作用。例如，我們提到的 DeepSeek，很多人可能只是在群裡聽到了一些“秘笈”或“訣竅”，並沒有自己動手去驗證。就像在討論某個提示詞的反饋時，有些人顯然沒有親自試過，只是重複別人說過的話。

丁雪豐： 在現在這個資訊環境中，AI 生成的內容有時可能充滿“幻覺”，有時看似一本正經，但其實是胡說八道，我們要能一眼識別出來。

張建飛： 是的，通用人工智慧距離我們還很遠。生成式人工智慧只是通用人工智慧的初級階段。機器的知識可以超過人類，但要產生和人類一樣的意識和智慧，這仍然很難實現。

沈淦： 尤其是情感，真的是非常困難。

張建飛： 是的，有些人認為這是不可能實現的，也有人說最樂觀的預測可能是 20 到 30 年，而一般的看法是需要 100 年。

沈淦： 我還是希望能短一些，最好能在我們有生之年體驗到。

張建飛： 但人類的意識是如何產生的，這個問題至今未解。即便我們透過模仿人類大腦的神經元來進行機器學習，但如何產生人類的意識和理解呢？有可能當引數達到一定程度時，意識自然湧現。

沈淦： 我個人覺得，如果只是口水話那無所謂，但如果是嚴肅討論，必須對“智慧”有一個明確的定義。有些場景下，智慧的定義其實很簡單。比如，當一個系統基於自己的獨立探索，產生大機率正確的結果時，就可以認為它具備某種智慧的雛形。現在有些模型已經具備了這樣的能力，它們不是基於人類的經驗和知識，而是透過自己的探索得出正確答案。

丁雪豐： 或者說，如果它能透過圖靈測試，我們也可以認為它具備智慧。

沈淦： 如果能夠透過圖靈測試，那就更簡單了，但現在很多模型都能透過圖靈測試。我覺得，討論智慧必須有明確的定義，而不能僅僅說“沒有定義”。如果沒有定義，就不能簡單地說它沒有智慧。和人類相比，當然目前的技術遠遠不如人類，但這不值得討論。

沈淦： 就目前而言，AI 還沒有成為數字化轉型中的核心部分，儘管它的熱度很大，但實際應用還有限。例如，一些較大的客戶，IT 預算每年接近 1 億，但用於 AI 相關的部分，可能連 500 萬都沒有，這表明他們仍然將 AI 視為一種探索性的技術。然而，我認為今年，尤其是透過 AI 技術的突破，可能會大大加速這一領域的發展，這是一個積極的訊號。

第二個感受是，之前很多企業已經投入大量資源，做了類似資料中心和資料倉庫的建設，他們非常重視資料資產。然而，對於當前這種依賴大模型的方式，企業對於將大量內部資料提交給外部模型還是有顧慮的。我們目前的做法是與像阿里這樣的電商平臺合作，透過專業的資料服務來解決這個問題。

丁雪豐： 記得 DeepSeek 推出後，很多產品和功能都紛紛加上“DeepSeek”標籤，似乎一切都和 DeepSeek 相關。甚至有說法稱 DeepSeek 只是一個“功能”，而非獨立產品。

沈淦： 我們主要做企業數字化相關的工作，而 DeepSeek 在這方面的應用還需要找到合適的場景。因為在企業的實際操作中，作業系統是執行系統，光是思考幾秒鐘的延遲就讓人難以接受。所以，我覺得大家對於 AI 的熱情有些過度，過於依賴 AI 思考。實際上，我們不可能將所有工作都交給 AI 來處理，過度依賴反而可能導致問題。

丁雪豐： 其實，我最擔心的還是資料安全問題。前段時間 AI 大神 Andrej Karpathy 做了個通俗易懂的人工智慧課程，當講到 DeepSeek 時，他特別提到，這是家中國公司，部署的伺服器在中國境內，所以使用時可以考慮選擇部署在美國公司的伺服器上的服務。外國人也會擔心資料安全，特別是在使用像 ChatGPT 或 Claude 時，資料會被如何處理。尤其是對於那些涉及國家安全、金融、軍工等核心領域的行業，他們的顧慮更為明顯。如果跟使用者說，“我會拿你的資料去訓練模型”，我覺得很多人可能會反感和反對。所以，這確實是一個隱私和資料安全的問題。

一些公司已經開始推出 DeepSeek 一體機，使用者只需要支付一定的費用，買回去的機器已經預裝好了大模型。這種做法也是為了更好地管理資料和支援大規模的服務。我覺得，資料問題是一方面，另一方面，當資料量變得很大時，如何更好地支援這些服務，也是一個需要考慮的挑戰。

沈淦： 對於大多數應用來說，很多資料量還沒達到，更多的還是集中在如何做好應用，尤其是那些非功能性的場景，體驗還比較少。一旦量起來，可能會出現很多新的問題。比如，過去我們說的重試機制、避免雪崩等，現在如果是 AI 驅動，這些方法可能就沒效了。現在的瓶頸可能是在於大模型的卡點，前面的最佳化方法就顯得沒那麼有效。比如，之前我們做快取的最佳化，雖然現在有一些對話快取技術，但命中率就像我們 SQL 快取一樣，命中率很低，只有完全一致的情況才可能命中。

丁雪豐：現在確實還在找場景，怎麼才能更好地利用 AI。說到特別大的困難，像 DeepSeek 真正火起來那段時間，很多服務都無法使用。用不了就是我們的困難，曾經我們在用 DeepSeek 處理一些任務時，它無法正常執行，直接影響了進度。

張建飛： 而且不穩定，之前伺服器經常出問題。

丁雪豐： 對，所以現在很多公司都在推私有化部署，各大廠商都在提供自己的私有化方案。

沈淦： 私有化部署一旦起量，也會面臨各種挑戰。這個是一個過程，現在沒有現成的經驗可以借鑑，只能透過不斷摸索和實踐來解決問題。

丁雪豐： 我記得有些專案，比如 MetaGPT，還有一些類似的嘗試，似乎是在嘗試讓幾個 Agent 相互之間對話。還有類似於讓 DeepSeek 分析，讓 Claude 去寫程式碼，再換一個 Agent 去評分，類似這樣的應用。

沈淦： 你說的是 AI 小鎮嗎？它是一個模擬環境，不是真正的應用。它是用於模擬和探索，而不是實際的生產環境。

丁雪豐： 我記得有類似的 MetaGPT 的嘗試，模擬大家的互動。將來可能會有更多這樣的嘗試，像我們之前討論的 AI 自己提出需求、分析需求、實現需求。這類應用應該會逐漸出現，但可能短期內大家還看不到特別成熟的應用落地，但它的確帶來了新的嘗試和探索的方向，未來可能會成為一個重要的趨勢。

張建飛： 從使用的角度來看，如何“用好”AI 應用其實是很難度量的。首先，我們不排斥這些新技術，我們能夠接受它們；其次，我們不僅接受，還會積極擁抱它們，藉助這些工具提升我們的效率，輔助我們的工程工作，無論是編碼、還是整個工程 Pipeline，AI 都會成為我們得力的助手。但至於如何真正“用好”它，我個人認為這個是很難量化的。

丁雪豐： 現在我們很多時候都用指標來衡量工作效能。我有時候也會拿過去的自己、現在的自己和未來的自己做對比。舉個簡單的例子，比如說我做一件事情，過去可能要兩天時間，而現在有了更高效的工具，半天就能完成。如果這種變化給我帶來了正向的收益，那就說明我確實使用得很好。其實，“用好”和“用了”之間的差異，只是在於度量的標準不同，或者是心理上、心態上的變化。部分改變是可以透過一些指標來度量的，比如可控輸入指標和輸出指標。

沈淦： 無論是外掛形式還是 AI IDE 的形式，“用好”最直觀的表現就是，你至少要非常熟悉主流工具，尤其是裡面的一些 AI 操作。例如，像左邊複製、右邊互動的方式，或者確認提交、多檔案處理等操作。如果你能熟練掌握這些工具的互動方式，並能高效地運用它們，這就是“用好”的體現。