停招初級工程師！大廠樣板無實戰價值、軟件黑燈工廠死路一條，三位AI 編程老炮：AI越罵越靈！

策劃 | 褚杏娟、Tina

對話 | 王一鵬

編輯 | 宇琪

在 2026 年初突然刷屏的 Clawdbot 又給 AI 編程的火爆添了一把柴。根據項目創始人 Peter Steinberger 的說法，他一個人完全用 AI 寫出了這個超級 AI 助手。

AI Coding 高速演進，有人借助它如虎添翼，效率和能力被成倍放大；也有人一上手就頻頻踩雷，代碼質量、系統風險反而被放大。但如今企業紛紛擁抱 AI Coing，代碼已經是“cheap”，技術從業者現在面臨的問題已經成為“如何與編程 Agent 相處”，無論是工作還是生活中。

近日，在 InfoQ 技術編輯組策劃的《2025 年度盤點與趨勢洞察》直播節目中，Kreditz Al Orchestrater 馬工、資深 AI 產品專家松子（李博源）、資深獨立咨詢師 &Al Coding 資深實踐者張漢東一起，分享了他們的 AI 編程工具使用經驗和過對行業的觀察，他們三人都去年大量使用 AI 編程，并在組織層面進行了一些探索。

在訪談中，三位專家都表示，徹底回不去之前的手工 coding 時代了，AI 已深度接管開發者的主觀能動性，成為工作的核心環節。人類在 AI 時代的核心價值不是寫代碼，而是需求表達、方案判斷、架構設計的能力，這是 AI 目前無法替代的 “最后護城河”。

根據使用經驗，現在 AI 編程的成本遠低于人力成本，其產出效率相當于數人團隊，哪怕訂閱制有額度限制，也是極高性價比的選擇。AI 編程并非降低行業門檻，而是入門門檻降低、精通門檻拉高、天花板抬升，靠手速和熟練度生存的中間層工程師正被快速替代，其成長路徑被直接掐斷。當前，AI 無法真正理解 “優雅的架構”，這是人類的審美問題而非技術問題，也不該指望 AI 把控，架構設計本就是人類的核心職責，因此真正具備架構能力的人因 AI 變得更稀缺，

他們評價現在對 AI Coding 工具好壞與否的唯一標準是能否在真實生產系統落地交付，大廠未經過實戰的全套 AI 方案毫無價值。專家指出，全自動 AI 程序員（如 Devin）現階段完全行不通，易出現需求理解偏差、架構不一致、交付質量不穩定等問題，未來 3-5 年人機協作是企業級開發主流，長期 Agent 才是發展方向。當前，開發工作的核心已從 “怎么寫” 轉向 “寫什么”，從關注代碼細節轉向業務邏輯、邊界條件、異常處理；思考必須更清晰，才能讓 AI 準確理解需求。

他們預計，2026 年 AI 編程將成為行業標配，“一人公司” 會成批出現；創業的技術門檻被拉平，核心競爭力轉向商業模式、業務理解和業務架構。linker、compiler、操作系統未來或向 AI 友好形態升級，這背后存在大量創業機會。

而對于年輕人來說，AI 消除了信息差紅利，讓其能與行業專家站在同一起跑線；現階段是有野心的年輕人成為軟件工程思想領軍人物的最佳窗口期，核心是獲取一手信息、親自實踐并主動輸出觀點。

專家們提醒，不應將 AI 當作全知全能的神，而應讓其批判性思考、挑戰自身觀點，避免強化認知偏見；AI 的核心價值是成為既支持又挑戰人類的協作對象。

以下內容基于直播速記整理，InfoQ 在不改變原意基礎上進行了刪減。完整直播回放可查看：

1“回不去手工 coding 的時代了”

王一鵬：如果用一個詞形容你過去一年的 AI 體驗，你會選什么？

張漢東：加速。

馬工：革命。

松子：上癮

王一鵬：對比使用 AI 工具之前的情況，你的工作流程是否都變了？

松子：最顯著的特點就是變化快、跨度大。過去做一個需求，通常是查文檔、寫 PPT、畫原型圖，畫完之后就等著技術去實現。現在則完全不同了，有想法就直接和 AI 進行頭腦風暴，看著 AI 寫代碼，指揮 AI 去執行，拿到結果后再和技術團隊一起評審，由他們來做加固和優化。

馬工：工作流程上，我刻意把團隊規模設計得非常小，通常只有兩三個人，盡量避免大團隊溝通，因為有些人跟不上節奏，反而會拖慢效率。另一方面是我個人的工作流，核心是我和 AI 的持續對話，由我來設計、引導它。

張漢東：以前我會非常關注代碼細節，比如優雅性和精細化的質量控制。使用 AI 之后，我更多是站在更高的抽象層面思考問題，從架構層進行設計，甚至可以同時開多個分支并行推進開發流程。另外，在代碼評審上也大量使用 AI，先由 AI 生成一份 review 報告，再進行人工檢查，實現并行評審。

王一鵬：你第一次感到“AI 有點可怕或厲害”的瞬間是什么？

馬工：5 月份開始用 Claude Code 之后，我才真正意識到這東西“成了”。在此之前，我一直認為 AI 只是輔助工具，給一些建議，但每個回答都需要仔細核查。Claude Code 不一樣，它已經能夠獨立完成一些顆粒度較小的任務，而且不需要人在旁邊全程跟著。這一點在我看來是革命性的。有了這種基礎能力，再疊加我們的工程經驗，就可以做很多以前做不了的事情。

松子：害怕我還真沒有，更多的是興奮，甚至有一種自己年輕了二十多歲的感覺。那種感覺就是，終于可以自己動手了，不再需要依賴技術團隊幫我實現想法。尤其是在面對模糊需求時，AI 不僅能幫我糾正表達，還能幫我梳理邊界條件，直接把代碼寫出來，把我的思路整理得非常清晰、有條理。

張漢東：我最早是從 Claude Code 3.7 版本開始用的，那時體驗還不算好。等到 4.0 出來之后，我明顯感覺到它變得非常強。再到最近，大家在網上討論 Claude 的 Skill 能力，我也試了一下，最終的效果是我在 20 分鐘內就做出了一個不算復雜、但支持跨平臺的 AI 應用。

王一鵬：你現在寫的代碼，有多少比例是：在沒有 AI 的情況下，你依然確信自己能完整寫出來的？

張漢東：可以的，畢竟我有接近 20 年的項目和編程經驗，手寫代碼本身沒有問題。但最大的問題在于，我已經不想手寫了。現在基本是 AI First，AI 已經在很大程度上接管了我的主觀能動性，這是我感受到的最大變化。

松子：如果沒有 AI，我幾乎一行代碼都寫不出來。但我認為我的價值并不在于是否能逐行寫代碼，而在于：第一，我清楚自己要做什么；第二，我能夠判斷 AI 給出的方案是否可靠；第三，我能把需求描述清楚。這三種能力，是 AI 目前無法替代的。

馬工：從理論上講，我當然也可以手寫所有代碼，但從工程角度來看，這并不現實。AI 寫代碼的速度是我的十幾倍甚至二十倍。比如我在圣誕節和新年假期完成的那個項目，如果沒有 AI，可能需要一年時間才能做完。從工程管理角度來說，老板也不可能批準這樣的周期，所以在現實中幾乎不具備可行性。

王一鵬：過去一年里，有沒有一個瞬間你意識到：“我已經回不去不用 AI 的狀態了。”那一刻發生了什么？

馬工：我從來沒有想過要回到過去。就好比以前是科舉制度，后來進了新學堂，你讓我再回去參加科舉？不可能的。我現在玩得很開心，也非常適應這種狀態。

松子：跨年的那幾天，大家都在干什么？我那幾天連續使用的 Token 量都破億，別人在倒計時，我卻在給 AI 寫代碼。那一刻我非常清楚地意識到，我已經和 AI 形成了一種共生關系。后來有一天幾乎完全沒用 AI，但那一天我是真的很累，想給自己放一天假。結果第二天開始工作時，我發現自己竟然不知道該如何開始了。打開編輯器的第一反應，還是想先讓 AI 幫我做點什么。回頭再看這兩個對比，我很確定自己已經回不到沒有 AI 的時代了。

松子的 token 用量統計

張漢東：我意識到自己回不去，是在某一天突然發現自己寫代碼時已經不再使用編輯器了。我寫了十幾年代碼，從來離不開編輯器。但在使用 Claude Code 四五個月之后，我發現很多時候根本不需要編輯器了。那一刻我意識到，自己已經徹底顛覆了過去的工作方式，也不可能再回到原來的狀態了。

2把 AI 當成一個同事，結果為王

王一鵬：從去年開始，我們就關注 AI 給不同技術崗位帶來的影響和變化，今年是更深入的一年。那先請各位根據自己的使用體驗，銳評下現在的國內外的 AI Coding 工具，在使用中各有什么優缺點？有哪些看起來很先進，但在實踐中很快暴露出問題？

馬工：我并不把 AI 當作一個工具，而是把它當作一個同事。我和朋友一起探索出了一套理論，叫作 AI 管理學。傳統管理里有人力資源管理，而現在我認為還需要一套面向 AI 的管理體系。管理的核心從來不在于工具本身，而在于流程和思路，也不存在所謂“最優解”。對我來說，更重要的是探索出一套適合自己的 AI 管理方法，并與我的工具組合在一起，形成最適合產品的方式。

也正因為如此，我現在比較反感一些大廠的做法，聲稱做出了一整套方案，要求別人直接照著用。但我仔細看過之后發現，他們自己甚至沒有用這些工具真正做出一個在生產環境中運行、處理真實業務的系統。所以我現在評估工具，只看一件事：有沒有在真實生產系統中、處理過真金白銀的案例。如果沒有，我基本不相信。在這一點上，我甚至更相信自己，因為我是實實在在把公司的業務跑在這些系統上的，是真正經過實戰檢驗的。

張漢東：從產品經理背景轉過來的用戶，使用 Vibe Coding 時，往往并不太關心底層代碼質量，更關注功能是否完整、是否可用。像我這種程序員出身的人，會不可避免地帶著一些工程習慣，更在意代碼質量、可維護性。因此在使用這種對話式代碼生成工具時，我需要對整體生成邏輯進行把控。

即便我可能不會逐行檢查代碼細節，但必須在腦中建立一個清晰的心智模型，并通過對話與 Claude Code 建立穩定的協作關系。即便如此，它生成的代碼質量也未必如想象中那么高，仍然需要人類進行驗證和 review。通常還要結合一些 skill、prompt 以及自動檢查和優化工具來兜底，才能保證整體質量。所以我認為，Vibe Coding 和相關工具的使用，至少可以分成兩類人、兩種路徑來理解。

王一鵬：如果我并不是特別在意代碼是否優雅、質量是否很高，只要能跑、能用，這種情況下不去 review 代碼也沒問題嗎？還是說如果完全不 review，代碼在運行層面本身就可能會出問題？

張漢東：一般來說，一個產品上線之后，后續一定涉及維護。如果形成的是一個“AI 生成代碼、AI 修 bug”的閉環，短期內是可以工作的。但隨著用戶規模和代碼規模不斷擴大，很容易陷入不可控狀態，最終變成一次性應用，用完即棄。對于一些關鍵領域，比如基礎設施或操作系統，使用 Vibe Coding 時，你需要的是鋼鐵般穩定的結構；而在一些不那么關鍵的上層應用場景中，可以接受“用完即棄”，我更愿意把這種代碼形態比作海綿結構，內部存在不少空隙和不確定性。最終可能呈現的是一種“海綿包裹鋼鐵”的混合結構。

松子：就我個人而言，評價工具的標準很簡單，尤其是對非科班出身的人來說，真正能交付成果的，才是好工具。我用過不少國內和國外的工具，主要集中在應用層，而不是系統層。像匯編、C 或 C++ 這種底層語言，大模型目前顯然還勝任不了。我更多使用的是 Python 加后端相關的應用開發。對我來說，谷歌的模型配合 Claude Code，已經足以覆蓋日常工作需求。國內工具并不是不努力，但整體來看，底層模型能力仍然存在一定差距。面對復雜需求時，它們雖然很認真地寫代碼，但錯誤率偏高，往往需要我花大量時間去做復雜調整。

實際使用中，我在企業內部更多是用 AI 生成 demo 和高保真原型，而對外項目則是一個純交付過程。做 demo 時，兩三天就能完成一個高保真版本；但如果是用 Claude Code 寫一個可交付的應用級項目，通常需要三到四周的時間。

以去年為例，從 9 月、10 月開始，我每個月新增的代碼量在 10 萬到 14 萬行之間，12 月我做了一次大規模重構，直接刪掉了 90% 以上的代碼。到了今年 1 月份才正式進入交付階段。那時我加了很多自己整理的 Skill 和規則，按照以往的工程習慣去做可用性檢查、漏洞檢查、代碼復用檢查等，再交給 AI 進行修復和優化。

王一鵬：是不是存在某些編程語言天生更適合 AI Coding？

馬工：我相信語言、工具，甚至整個軟件棧都需要被重新設計，變得對 AI 更友好。Rust 在我看來就是一種非常 AI 友好的語言，因為它可以在編譯階段完成大量驗證，只要能通過編譯，代碼質量就已經明顯高于很多語言，這對 AI 非常有利，可以極大降低迭代成本。除此之外，我認為 linker、compiler，甚至操作系統，未來都可能需要重構為 AI 友好的形態。因為現有工具幾乎都是為人類設計的，而 AI 的思維方式與人類差異很大，這里面我反而看到了很多潛在的創業機會。

張漢東：Rust 對 AI 友好，很大程度上源于它強大的編譯器體系，這為 AI 提供了一個清晰的驗證反饋回路。更關鍵的是，Rust 是以類型系統為核心的語言，而類型系統本質上可以理解為一種邏輯證明。當 Rust 程序編譯通過時，意味著它在邏輯層面已經被“證明”過了。

我之前有一個實踐案例，讓 Claude Code 幫我排查一個運行時才會暴露的問題，編譯階段是發現不了的。這個 bug 我自己沒找到，但它大概花了五分鐘就精準定位出來了。事后我反思，可能正是因為 Rust 的類型系統和強邏輯性，使得 AI 在推理時能夠發現這些潛在問題。

當然，Rust 也有不足，比如缺乏像 Lua 這樣的動態語言能力。我們團隊也在思考，為 Rust 引入一種可以無縫交互的動態語言，語法接近 GS 這類大模型更擅長的語言形式。安全、穩定的核心部分由 Rust 承擔，而快速迭代的業務邏輯則交給動態語言來實現，這也是我們正在探索的一種方向。

3 編程老手們，都怎么用 AI 工具？

王一鵬：大家有沒有自己的“AI 工具棧”，幾個工具協作使用？實際中，有沒有遇到過 AI 工具讓你“返工成本比人工更高”的情況？程序員是否需要刻意訓練自己更好地與 AI 協作？

松子：我確實有一套自己長期使用的 AI 技術棧，包括多 AI 協同寫作，我甚至為此給自己設計并實現了幾個協作型智能體。回顧 2025 年 3 月到 5 月那段時間，我剛開始深入大模型編程，可能也受到當時模型基礎能力的限制，踩了非常多的坑。幾乎每天只有 10% 的時間在生成代碼，剩下 90% 都花在調 bug 上。那段時期反而是我從非技術背景跨入技術領域、學習速度最快的階段。8 月之后，尤其是 Claude Code 3.5 版本出來以后，返工成本高于人工成本的情況基本就很少再出現了。

馬工：我實際上是在搭建一個團隊，為不同的 AI 賦予不同的人格和職責，有的負責頭腦風暴，有的負責架構設計，有的負責編碼，有的做測試，有的做質量控制，最后還有一個負責部署。我用 Claude Code 的 sub-agents 來實現這些角色，同時又設計了一個項目經理角色，負責協調整個流程，形成完整的工作流。

這套工作流目前相對固定，但我正在嘗試把它做成更具彈性的形態，盡量用 AI 去模擬一個真實的人類團隊。整體使用下來我已經非常熟練，也并不覺得返工成本是問題，因為返工本身也是由 AI 來完成，而不是我親自返工。這套流程我在公司內部的生產環境中已經跑得很順。

同時，在個人項目中，我還有另一套流程和角色，用于寫文章，比如公眾號內容創作。我的主要工作，其實就是組織這些“AI 同事”完成任務。

至于具體用哪個模型、哪個工具，在我的理論體系里并不是關鍵問題。我可以隨時切換到其他大模型，最多只是質量稍差一些，或者返工次數多一些。這也是我和很多朋友共同追求的目標：構建一套盡量與具體大模型解耦、依賴度很低的 AI 團隊體系。

如果打個比方，就像開一家真實的公司，能招到清華畢業生當然最好，招不到就招 985，再不行還有其他學校，但公司依然可以運轉。你不能因為招不到最頂尖的人，就干脆不開公司了，那這個思路本身就是有問題的。

張漢東：通常我會用 Claude Code 做規劃，用 Codex 做 review，完成后再回到 Claude Code 去實現。我的工作并不只有開發，還包括代碼評審、社區工作，以及與出版社相關的寫作任務，因此我也為自己打造了一套完整的 workflow。

這套 workflow 的靈感部分來自 Shopify 開源的一套工具，是用 Ruby 寫的。我用 Vibe Coding 把它改成了 Rust 版本，并加入了一些結合我自身工作經驗的流程設計。比如出版社給我一份大約 178 頁的英文翻譯稿，我基于 Claude Code SDK，把任務拆分成五個部分并行處理，大概一個小時就完成了包含格式、內部鏈接在內的完整中文版。

除此之外，我也用這套 workflow 來做代碼 review，以及其他流程固定、但相對瑣碎的工作，統一交給 AI 處理。還有一個例子是現在比較流行的上下文 MCP 項目，它是開源的，我同樣用 Vibe Coding 把它改成了 Rust 實現，并整合了 Rust 的工具鏈。這樣在做 Rust 代碼 review 時，就可以把編輯器之外的各種工具一起納入進來。

整體來看，這些已經構成了我個人的 AI 工具體系。最近我還在嘗試把團隊過去兩年的經驗沉淀成 Skill，正好趕上 Skill 這個概念流行，就把我們在 Rust UI 方向的經驗整理成一個 Skill，作為團隊共用的 AI 編程基礎設施，形成一個共享的工具庫。

張漢東制作的 nana banana workflow

王一鵬：Vibe Coding 圈有兩種玩法：Lovable/Bolt 那種快速出 Demo 給客戶看，和 Claude Code 直接交付生產代碼（即 Lovable 模式 vs Coding 模式 ）。你們公司是哪種？有沒有兩種混用出問題的？

松子：Lovable 是我去年剛開始用大模型編程時常用的工具，現在回頭看，那其實就是當時的階段性選擇。去年 4 月我做了第一個 demo，到 8 月和客戶溝通時，我嘗試用一種“邊喝咖啡邊聊需求、現場出 demo”的方式交流。這種模式下原型生成速度非常快，客戶可以迅速看到大概的形態。

但我當時犯了一個很大的錯誤，就是在 live demo 之后，直接嘗試把 demo 代碼演進成生產級代碼，結果掉進了一個非常深的坑。后來我逐漸形成了一種方法：live demo 結束后，先進入“包頭”狀態，對代碼做一次完整重構。把 demo 代碼直接拿去改成生產級，幾乎就是一場災難。demo 能跑、能看，但架構往往一塌糊涂，在其基礎上繼續加功能，重構成本甚至比重寫還高。所以我的原則是，demo 用完即棄，屬于日拋型產物，只用于表達和驗證想法。

馬工：過去和客戶的交互往往需要研發團隊支持，現在有了這些非專業編程工具，銷售可以自己完成，整體效率提升非常明顯。所以我并不完全同意“Lovable 不能用于生產”這種說法。比如銷售做一個 demo，本身就是生產，它在業務上的價值，可能比我寫一個非常復雜、可擴展的系統還要高。它能夠直接促成訂單，那為什么不能算生產呢？

當然，它是日拋型的，但依然是生產的一部分，關鍵是要把這兩類場景區分開。你不能一邊期望低門檻快速出成果，一邊又要求給你一個完美架構。這本質上是期望管理的問題。很多人之所以對 AI 失望，往往是因為在錯誤的場景里，期待了錯誤的結果。

張漢東：在做 AI 工具選型時，確實要明確邊界。像 Lovable，從名字就能看出來，更偏向于“讓人喜歡”的 demo 型工具，適合給非技術決策者或客戶展示，比如銷售場景下讓客戶點頭認可。它并不關注代碼質量，而關注是否能促成決策。如果目標是專業開發，那就需要像 Claude Code 這樣的工具，這是兩個不同的領域。我雖然沒有深度使用過 Lovable，但研究過他們官網開源的 prompt，寫得非常好。它解決的正是非技術用戶的痛點。就像我前面說的，即便是“海綿式”的代碼，它依然能很好地表達意圖，在和客戶溝通時，往往比文字、圖片甚至視頻更有效，因為它是可交互的。

王一鵬：幾位老師現在是用 AI 幫你們寫 prompt，還是主要自己來寫？

松子：我是自己寫。

王一鵬：為什么不用 AI 寫呢？

松子：我試過，但總覺得 AI 寫出來的 prompt 太機械，不如自己寫得有感情，更有韻味。

馬工：我是大量用 AI 寫，而且還專門設置了一個角色，把它當作公司的人力資源負責人。當項目遇到困難，或者到了關鍵里程碑時，我會讓這個“人力資源專員”回顧我們的聊天記錄，總結可以吸取的經驗和教訓，并把這些經驗嵌入到各個角色的 cloud MD 中。這樣每完成一個項目，我的各個 AI 角色都會在能力上有所提升，這是我對人類組織運作方式的一種模擬。

現實中的公司都會在項目結束后做復盤，決定哪些經驗要保留，哪些問題下次要避免。在傳統組織中，這些通常通過郵件或會議傳遞。而在 AI 場景里，我是通過固定的 prompt 把這些經驗沉淀下來。

王一鵬：聽起來馬工已經觸及到 AI 的本質了，本質上還是仿生學。

馬工：對，本質就是模仿人類。很多 AI 技術上的難題，人類其實早就通過管理學和工程學的方法解決過了，我只是把這些方法原樣遷移過來，用在 AI 身上。

張漢東：我也是偏向 AI 寫 prompt，我的原則是盡量 AI First。但我會對 prompt 做把控，判斷哪些是好的、哪些是無效的。如果需要比較專業的 prompt，我會先去網上找成熟案例，再結合 AI 一起改造成適合自己場景的版本。如果效果不好，就當成一次 debug，不斷迭代，直到形成一個真正有用的 prompt。

王一鵬：Karpathy 說 AI 在“可驗證任務”（如代碼、數學）上可能超越人類專家，但在“不可驗證任務”（如架構設計、戰略決策）上進展緩慢。你們覺得 AI 什么時候能真正理解什么是“優雅的架構”？還是永遠不能？

馬工：作為工程師，我的核心目標只有一個，就是把問題解決掉。這個問題是用 AI 來解決，還是讓同事解決，或者交給軟件系統解決，對我來說本質上都只是工具選擇而已。我不會為了用 AI 而用 AI，更不會執著于“一定要用 AI 把問題做到世界第一”。如果某個問題 AI 解決不了，那我就直接插入人工。我也認為，去預測三年后的 AI 會發展成什么樣并沒有太大意義，因為三年內會發生太多變化。更重要的是用好當下的工具和模型，盡快把問題解決，交付一個能夠在生產環境中穩定運行的系統，這是我目前最關注的事情。

馬工和同事在 coding

松子：以我自己為例，技術團隊寫完代碼后，我再用 AI 或反編譯工具去做 review，確實可以發現并修復大量 bug，很多時候甚至重寫代碼的效果會更好。但在架構設計和戰略決策層面，AI 可以給你一百種“正確”的方案，卻無法告訴你哪一種才是最合適、最優的選擇。這種取舍判斷，我認為仍然是人類最后的護城河。所謂“優雅”，在我看來并不是一個技術問題，而更像是一個審美問題。就像“情人眼里出西施”，我看這些大模型，各有各的美感，但在審美判斷上，AI 目前確實還不行，它還需要更多訓練。

張漢東：首先是 AI 能否理解“優雅的架構”。我以前在編程時，會直接要求 Claude Code 把代碼寫得更優雅、架構更清晰，它給我的回復基本是：抱歉，我理解不了“優雅”，我只能進行模式匹配，本質上是在模仿人類。也就是說，它并不真正理解人類的審美。

其次，我們本身就不應該指望 AI 去理解什么是“優雅架構”，這本來就應該由人來把控。就像 Anthropic 去年在官網推出的一套課程，其中有一門叫“4D 人機協作”，屬于 AI 素養教育，核心是教人如何更優雅地進行人機協作。其中第一個 “D” 叫 Description，強調在向 AI 描述需求時，要明確哪些事情由人來做，哪些交給 AI。我認為這一點非常重要，有些問題本身就不該交給 AI 去理解。

4 用 AI 編程，到底貴不貴？

王一鵬：去年，以 Claude Code 為代表，AI 編程工具的計費邏輯發生調整：從獨立 API 計費，到訂閱制 + 使用量控制。這些調整背后的動機是什么？另外，這些變化對開發者來說，使用成本是更高還是更低了？支付高額的費用，值不值呢？你用這些工具的時候，會主動關注 Token、調用量或費用上限嗎？

馬工：我并不認同“Claude Code 很貴”這種說法，這完全取決于你的參照系。我是把它當作一個“人”來看待的。你花 200 美元，根本不可能在任何地方請到一個能穩定寫代碼的人。從這個角度看，它便宜得不可思議。

目前 Anthropic 的問題在于，Max Plan 在法律上不能用于公司場景，我們公司只能使用 Team Plan，而 Team Plan 的額度又低于 Max Plan，超出部分只能走 API 計費，價格大概貴十倍，這確實帶來了一些挑戰，只能通過一些變通方式解決。但總體來看，這筆賬其實不用算，只要你用得上，它能替代好幾個員工。

松子：我個人一直更偏好訂閱制。以我自己的真實數據來看，從元旦往前推的一個月內，我大概用了接近 28 億個 token。如果按 API 計費，那成本會非常夸張；但用 100 美元的 Pro 訂閱，對我來說反而是極其劃算的。

如果按 API 算，這個工作量可能要幾萬美元。實際上，這相當于一個五人團隊的產出，比如兩個前端、兩個后端，再加一個產品經理。按月薪 3 萬計算，三個月就是 45 萬的人力成本，而我用 Claude 只花了 100 美元。

張漢東：在 Code 訂閱模式出來之前，我也只能用 API，確實非常貴，有時候只是打開項目又關掉，也會被計費，感覺很不可思議。后來轉向訂閱模式，哪怕有周限額，只要不是同時推進太多項目，其實是完全夠用的。我有一段時間同時做了好幾個項目，每天熬到兩三點，一個月幾乎沒怎么睡，甚至還注冊了多個賬號并行使用，多少有點“薅羊毛”和數據蒸餾的嫌疑，后來我自己也意識到這樣不太對，就收斂了，只把精力放在真正重要的項目上。我的建議是，要用就用最好的模型，無論是工作還是學習，否則你用一些中轉服務，甚至都無法確認模型是真是假，很容易被摻假。

5全自動 AI 程序員，目前行不通

王一鵬：你們如何看待去年 Devin 這種全自動 AI 程序員的出現？與 Cursor 等人機協作工具相比，各位認為哪一個才是未來企業級開發的主流？你覺得現在的 Agent Coding，是在制造“可演進系統”，還是在制造“未來無人能接手的黑箱”？

馬工：關于“無人軟件工廠”或“軟件黑燈工廠”，我幾個月前在公司內部親自嘗試過，結果是非常慘痛的失敗。除了 Devin，還有 OpenSWE、NonSmith 等一系列類似的全自動方案，基本沒有真正成功的商業案例，更多是自我宣傳，沒有客戶愿意用真金白銀為其背書。在我看來，這條路線至少在現階段沒有必要：既然我已經用 AI 替代了 90% 的成本，剩下 10% 插入人工又有什么問題？我們的目標是解決問題，而不是證明“AI 無人工廠”的學術可行性。

王一鵬：當時這個“工廠”失敗的具體原因是什么？

馬工：第一，AI 在需求理解上極易產生偏差，無論需求文檔寫得多詳細，都無法完全避免。第二，在系統架構上缺乏一致性，不同任務往往采用不同實現方式，即便用規則或 promise 約束，也仍然會出現不遵從的情況。第三，在最終交付質量上，人類能夠理解質量是一個光譜，而不是 0 或 1，知道什么時候可以放松、什么時候必須嚴格，但 AI 缺乏這種上下文感知，表現非常不穩定，難以真正滿足客戶需求。

這些問題疊加后，你會發現交付結果始終達不到預期。相比之下，在工作流中插入少量人工控制節點，問題就能有效解決，而且成本并不會大幅上升，因為人只負責把控關鍵節點，而不需要親自完成大量工作。

松子：我認為全自動 Agent Coding 目前存在下面幾個致命問題。第一是沒人 review，Agent 自己寫、自己測、自己合并，最終誰來負責？第二是上下文嚴重丟失，十個月后再看代碼，可能連 Agent 自己都解釋不清楚，黑箱疊加黑箱，已經不是“屎山”，而是“黑洞”。屎山還能慢慢重構，黑洞則只能推倒重來。人寫的代碼再爛，至少還有責任人；Agent 堆出來的代碼，一旦出問題，根本不知道該找誰。

像 Devin 這樣的產品，發布時非常驚艷，但真正用起來卻是一地雞毛。簡單任務尚可，稍微復雜就開始跑偏，上下文理解和調試能力甚至不如人類工程師，更像是一個需要人時刻盯著的 AI 實習生。從 ToB 企業的角度看，真正合理的形態一定是人機協作：關鍵節點可控、可維護、可追溯。AI 應該是副駕駛，而不是司機，方向盤必須掌握在人手里。

張漢東：未來三到五年內，人機協作一定是主流，但長期來看，Agent 會成為主流。我之所以這樣判斷，是因為 Anthropic 推出了系統化的 4D 人機協作課程，這說明在短期內，他們并不認為模型本身會出現足以徹底替代人的突破，否則沒必要投入如此多精力去教人如何協作。

但從長期看，Agent 的方向依然非常明確。以 Claude 推出的 Skill 為例，它并不僅僅是 Prompt，而是把人類的能力和經驗更精準地沉淀并交給 AI。隨著 Skill 的積累和熱加載能力的增強，Agent 在特定團隊和場景中，已經具備成為主流生產力的潛力，未來甚至可能走向跨行業的通用化。

此外，Anthropic 收購了前端打包工具 Bun，也明確提出“下一代軟件基礎設施”的概念。結合谷歌、馬斯克等公司的動向，可以看到未來的軟件形態，很可能是面向 Agent 而非人類 UI 的。這些信號都在指向一個結論：短期內要解決黑箱問題、強調人機協作，但長期演進方向，仍然是 Agent。

王一鵬：有個比較極端的問題，你現在交付的東西，如果有一天 AI 不在了：你自己還接得住嗎？還是你已經默認“反正以后也會有更強的 AI”？

松子：如果 AI 突然不在了，我確實接不住，但我也沒打算硬接，我一定會去找下一個 AI。與其擔心 AI 會不會消失，不如擔心自己是否跟得上 AI 的進化速度。對我來說，一個很明顯的狀態就是每天都在學習新詞、新玩法。每天至少兩次瀏覽不同的 AI 網站和論壇，看看大家在討論什么，從而不斷更新自己的認知。

張漢東：首先，我認為 AI 不可能“不在”。從能源、算力以及各國的投入來看，無論是美國、日本還是中國，未來電力和算力只會越來越充沛，因此我并不太擔心 AI 會整體消失。更重要的其實是你如何看待 AI，以及你對 AI 的依賴程度。在使用 AI 時，我們必須保留自己的判斷能力，同時具備對 AI 輸出結果的驗證能力。如果 AI 不在了，大不了重新學習，但關鍵在于：你之前用 AI 寫出來的系統和架構，你自己能不能 hold 住？你是否知道該從哪里重新接手？這取決于你在使用 AI 的過程中，是否建立起清晰的心智模型。如果你只是把 AI 當成一個黑箱，那一旦 AI 不可用，你肯定是接不住的。

而且現實中，AI 不可用的情況并不少見，比如賬號被封。Claude 封號并不罕見，如果在一周內你的賬號被封，而你手頭的工作又有 deadline，這時該怎么辦？找不到替代 AI，就只能自己頂上。因此，在日常與 AI 交互時，就必須提前做好這種心理和能力上的準備。

馬工：AI 本身不會消失，但 AI 在你所在國家或地區的可用性，確實可能成為問題。比如 Anthropic 目前就不向中國提供服務，未來隨著地緣政治變化，也不排除出現更極端的情況，你所依賴的某個服務突然完全不可用。

從企業供應鏈安全的角度來看，通常有兩個對策。第一是準備 Plan B，比如智譜目前就主打作為 Claude 或 Anthropic 的替代方案，性能可能只有 80%，但價格只有十分之一。第二是在使用過程中，盡量降低對單一模型的強依賴，讓工作流具備足夠的韌性，即便切換模型也能完成任務，只是效率略低一些當然，在條件允許的情況下，比如我現在能用 Anthropic，我還是會直接用它，而不愿意花時間去適應那些便宜但體驗不佳的模型。

王一鵬：有人說和 AI 多花時間頭腦風暴是被嚴重低估的技巧，“簡單功能少聊，復雜功能多聊”。但這不就是產品經理的老本行嗎？程序員寫代碼的時間是不是正在被“和 AI 聊天”取代？另外，當 AI 工具成為習慣后，個人的思維方式需要跟著發生什么變化？順便給大家一些使用 AI 編程的建議？

松子：簡單功能少聊，復雜功能多聊，這本來也是產品經理的基本功。現在的模式是，產品經理先和 AI 深度討論需求，再與技術團隊協作，用 AI 寫代碼，最后由產品和技術一起審核，協作方式從“溝通產出”變成了“協作產出”。

在技術實現能力上，AI 確實在拉平差距，很多工程師的實現能力被 AI 顯著拉近了。但需求表達能力反而成了一種稀缺資源。我們合作的一家央企，原來的“技術團隊”已經改名為“需求經理”，他們大約 50% 的時間在和 AI 對話，30% 的時間審查 AI 生成的代碼，剩下 20% 用于調試。這并不是降級，而是一種升級，從寫代碼轉向架構和產品思維。

從“怎么寫”轉向“寫什么”，從一次性完成轉向迭代逼近。過去關注的是語法、API 和實現細節，現在關注的是業務邏輯、邊界條件和異常處理。以前追求完美，現在更強調先讓 AI 跑起來，再逐步修正。同時，還有一個明顯變化：以前自己想明白就夠了，現在必須讓 AI 也想明白，這反而倒逼自己的思考更加清晰。在我看來，AI 時代最核心的能力不是寫代碼，而是把需求說清楚；說不清楚，AI 就會用一堆 bug 來“教育你”。

王一鵬：很像數學學習的過程。早期更多是學習計算方法，比如三角函數，而真正進入數學研究后，重點變成了提出問題、證明定理，并把推理過程表達得清晰、可驗證、可被他人理解。現在的開發工作也類似，基礎計算可以交給 AI，人只需要關注更高層次的問題。

馬工：和 AI 聊天本身并不難，任何人都可以做到，但真正的挑戰在于能否形成習慣。你只要有問題就去找 AI 聊，幾乎只會有收益，不會有壞處。

我有個朋友，任何事情看到一句話，都會第一時間丟給 AI。我認為這會顯著提升你的知識密度和深度，因為 AI 本身就是最“博學”的存在。我也在刻意培養這個習慣。前幾天我修洗碗機，就是在 AI 的指導下完成的。我現在也還在思考，AI 在我生活中究竟扮演什么角色：有時是員工，有時是秘書，有時是導師。它并非上帝，但如果你養成這種與 AI 持續互動的習慣，你能從中獲得的價值會非常巨大。關鍵在于，你要主動去找它，把它當作自己的“貴人”。

王一鵬：這其實和大家對 AI 的期望有關。有些人只進行幾輪對話，得到不滿意的結果就放棄了；有些人愿意聊二三十輪，得到一個 60 分的結果，再自己補到 80 分。但馬工對 AI 的期望顯然更高，是希望通過多輪對話，最終交付一個接近 90 分的結果。

馬工：我在 ChatGPT 里做了定制化設置，明確要求它進行批判性思考、挑戰我的觀點、不清楚就不要回答，所有結論都必須有來源。我甚至在“塑造”AI 的性格，因為 AI 很容易順著用戶說話，而我刻意要求它不要強化我的偏見，而是幫助我識別并修正偏見。你不能把 AI 當成一個全知全能的神來崇拜，否則一旦結果不符合預期，就會迅速失望并轉而尋找“下一個神”。

你之所以向 AI 求助，本身就說明你的認知是有限的，如果 AI 只是順著你說，只會加固你的局限。你真正需要的是一個既支持你、又挑戰你的對象，讓你意識到自己可能是錯的，甚至從根本上重新審視需求或架構。這也是為什么產品經理往往更適合使用 AI，因為他們從職業生涯一開始就習慣被挑戰，而程序員往往不習慣被質疑設計。

張漢東：至于“程序員是否會被 AI 聊天取代”，我并不認同這種說法。實際上，即便在沒有 AI 的時代，程序員在寫代碼前也要先對需求進行內化、建模，這是一個與自己對話的過程，現在只是把這個過程外化為與 AI 對話。過去當我把方案完全想清楚時，往往已經不太想寫代碼了，因為后面更多是體力勞動；現在有了 AI，我只需要把思路說清楚，代碼就可以交給它完成，反而節省了大量時間。

松子：Claude Code 有一個全局配置文檔，我在去年 10 月對它做過一次升級。配置中，我為它設定了明確的用戶關系和協作角色，并且根據不同關鍵詞加載不同的檔案，與 Skill 結合完成不同類型的工作。效果在于，不同工作場景下可以快速切換不同角色和協作模式，比如寫書、寫文章、處理工作問題或生活問題，都能調用不同的“人格”和配置，提高整體效率。

張漢東：我覺得人格設定本身是有價值的，至少能提醒自己把 AI 當作伙伴。如果我也這么設定，可能就不會動不動罵 AI 了。

馬工：我有個朋友正好反過來，給 AI 設定了一個“暴躁老哥”的人格，每次寫完代碼就讓它來罵一遍，效果反而很好。有些場景下并不需要所有人都溫和友善，有時確實需要一個“壞人”來提高整體質量。所以這完全取決于你自己真正需要什么。與其照搬別人的設定，不如把你在現實生活中渴望的那種角色，直接寫成 prompt，交給 AI。

6“只招會用 AI 的實習生”

王一鵬：AI 生成的代碼通常'能跑'，但鑒別它是否'優雅'或'可維護'，反而需要更高的能力。這是不是說明 AI 編程其實提高了門檻而不是降低？導致現在用 AI coding 最爽的是更資深的開發者？

張漢東：我覺得和年齡沒有關系，即便把 AI 交給一個三歲小孩，只要他具備語言能力、能夠表達自己，就同樣可以使用 AI。小孩子的一個顯著特點是不斷追問“為什么”，本質上就是能夠提出真實的問題、表達真實的困惑。這在我看來，是使用 AI 最核心、甚至唯一的重要能力。無論是在個人成長、工作還是職場中，關鍵都在于你能否覺察到自己真正遇到了什么問題，并把它清晰地表達出來。這聽起來或許有些雞湯，但所謂“活在當下”，本質就是對自身處境保持覺察，并將問題說清楚。

馬工：以我個人的經驗來看，我們公司已經不再招聘初級工程師，只需要資深工程師。原因其實很簡單：從企業角度看，我不再需要能力處在“及格線”的工程師，因為他的水平可能與 AI 相當，甚至低于 AI，而 AI 在編程語言上的覆蓋面遠遠超過個人。企業為此還需要支付較高的薪酬，自然缺乏招聘初級工程師的動力。

之所以我們這些“老登”還能處在第二層，是因為我們的能力確實比 AI 略高，至少可以指導 AI 工作。對企業而言，這種能力是有價值的，而且這種價值會被 AI 成倍放大。但如果每個企業都基于同樣的邏輯做決策，就會有大量年輕人長期找不到工作，這將是一個非常嚴重的社會問題。

松子：入門門檻確實被大幅降低了，同時精通的門檻也被拉低，但天花板卻被抬得更高了。現在入門可能只需要十分鐘，就能做出一個看起來不錯的 Demo 網站，但從“能跑”到“能用”之間仍然存在明顯差距，無論是安全性、性能還是可維護性，都還有大量提升空間。

另一個重要變化是中間層的塌陷。過去依靠手速和熟練度生存的那一層工程師，正在被 AI 快速替代。入門者可以借助 AI 很快學會寫代碼，而中間層卻被壓縮消失。反而是依靠架構能力和判斷力的資深工程師，在 AI 時代變得更加稀缺。AI 拉平了“會寫代碼”的價值，卻顯著放大了“判斷代碼好壞”的價值。因此，我認為 AI 時代最危險的并不是不懂代碼，而是以為自己已經懂了。

王一鵬：有人說 AI 不但不會讓架構師變多，反而會讓架構師更稀缺：不是因為更難，而是“成長路徑和回報同時塌陷”，你們同意嗎？如果新人都用 AI 跳過基礎訓練，10 年后誰來當架構師？

松子：AI 并不是讓架構師或產品架構、業務架構變得更多，而是讓真正具備架構能力的人更加稀缺。這種稀缺性非常反直覺，并非因為事情變難了，而是因為成長路徑發生了塌陷。一個行業中專家的數量，往往取決于兩個因素：是否存在清晰的成長路徑，以及是否有明確且足夠的經濟回報。像醫生、律師這些職業雖然門檻高，但路徑清晰、回報明確，因此仍然吸引大量人才。

而 AI 的出現，在一定程度上削弱了這兩個條件。新人練手的機會變少了，如果直接依賴 AI 生成代碼，就會跳過“如何設計才是最優”的思考過程。這就像計算器普及后，心算能力逐漸退化一樣。未來十年，也許并不缺會使用 AI 的人，真正稀缺的是懂得如何教 AI 正確工作的那類人。

馬工：現有的職務和頭銜體系，可能在未來幾年內會被重構，取而代之的是一套新的角色和職稱體系。我加入公司時是 leader engineer，但后來我和老板溝通，直接把頭銜改成了“AI orchestrator”，工作內容也從傳統工程轉向管理 AI agents。我相信未來幾年會不斷涌現新的頭銜，而年輕人反而可能更有優勢，因為他們沒有歷史包袱，可以用更 AI 原生的方式去思考。

但在新的體系真正成型之前，會有一個相當艱難的過渡期。年輕人確實會在這幾年里大規模地面臨就業困難，看不到清晰的上升路徑，企業也缺乏培養他們的意愿。以我現在的團隊為例，三個人就能完成過去幾十人團隊的工作，而且效率更高。這實際上意味著，我們無意中減少了大量崗位。如果沒有經濟層面的重大增長，這種壓力在短期內很難緩解。

王一鵬：現在寫代碼變得簡單，難點在于理解代碼的現有內容、意義以及修改后可能導致的問題。這會對初級開發者的成長路徑產生什么致命影響？AI 是不是正在直接“掐斷”初級開發者本該經歷的那條成長路徑？如果公司都在裁高級工程師、只留應屆生 +AI，誰來教新人識別 AI 的坑？"

馬工：年輕人探索新路徑幾乎是必然的，歷史上也反復出現過類似情況。比如傳統零售行業，過去需要從管理培訓生、門店員工一步步做到店長、區域經理。電商興起后，很多畢業生直接進入平臺做“店小二”，反而成長為行業核心力量，并沒有走傳統路徑。我相信軟件行業中也一定會出現類似的新路徑，只是目前還在探索階段。

張漢東：從趨勢判斷上看，短期內人機協作仍然會是主流。在這一階段，經驗豐富的人依然是被需要的。同時，也會有一些年輕人抓住機會創業，他們往往會雇傭具備經驗的老工程師。但從更長期來看，如果三到五年后以 Agent 為主流的模式真正成熟，職業結構可能會發生更根本的變化。

今天的架構師主要面向代碼，參與人機協作；但未來的架構師，可能不再直接面向代碼，而是面向多 Agent、多模態系統，負責整體調度和協同。這種能力并不一定依賴寫代碼，而更多依賴行業理解、領域知識和一線經驗。架構本身并不局限于技術領域，任何行業只要具備架構能力的人，都有可能勝任 Agent 架構的工作。

王一鵬：現在張老師和松子老師所在的團隊，還在招聘初級工程師嗎？

張漢東：之前我們確實還在招聘初級工程師和實習生，但今年開始，團隊的負責人已經明確要求全面推進 AI coding。如果現在還有新人崗位，也必須具備使用 AI 的能力。因為我們的 AI 工作流已經在團隊中全面鋪開，如果你進來卻不會用 AI，基本無法融入工作。現在大家都是 AI 在干活，沒有精力再進行傳統意義上的手把手教學，有問題直接去問 AI。通過 workflow 和技能體系，整個團隊已經高度 AI 化，新人必須跟上這個節奏。

松子：過去新人進來還會有人帶，現在幾乎沒人再教，都是直接跟著 AI 學。另一方面，以前一個項目需要兩名技術人員協作完成，現在往往是一個人加 AI 就能獨立完成，形成一種“超級個體”的工作模式。新人需要自己負責一個完整方向的產品，并借助 AI 實現。

當前很多年輕人選擇創業，背后有幾個原因。首先，信息差紅利基本消失了。過去創業需要長期積累和信息優勢，而現在通過 AI 工具，幾乎可以瞬間獲得大量信息。其次，創業門檻被大幅拉低。大模型出現后的這兩三年，低代碼、AI 工具和云服務顯著降低了 MVP 的實現成本，使得創業的技術門檻幾乎被拉平。在這種背景下，真正的關鍵反而轉向商業模式、業務理解和業務架構。

7 “一人公司”成批出現，年輕人最好的時代

王一鵬：展望 2026，各位認為，今年最確定會發生的三個變化是什么？程序員的哪些能力會進一步被 AI 重塑？ 技術人未來最應該開始學習或加強的能力是什么？

張漢東：過去這一年帶來的變化，幾乎相當于以往十年的迭代速度，很多事情已經無法預測，任何可能性都有可能發生。不過我仍然堅持一個判斷：在未來三到五年內，人機協作依然會存在明確的窗口期。

在這段時間里，我對學生的建議是，首先一定要跟上 AI 的發展，最基本的是你得會用 AI。更重要的是，你要獲取第一手信息，必須持續關注 AI 最前沿的動態，并基于這些信息去判斷趨勢。

其次，你一定要盡量掌握當前最好的 AI 工具，同時建立屬于自己的 AI 工作流和學習路徑。只有這樣，才能順利銜接后續以 Agent 為主流的發展階段，知道如何指揮 Agent 工作，并在過程中持續積累行業經驗。

馬工：我的態度既樂觀也悲觀。悲觀的一面在于，我認為 AI 取代大部分勞動力、引發大規模失業幾乎是不可避免的，這一點個人無法改變，社會是否能夠適應，這是政治和制度層面的問題。但從樂觀的角度看，如果有一些年輕人足夠有野心，想真正做出點東西，現在反而是最好的時代。以 AI coding 為例，我并不認為現階段的工具已經達到了“世界一流”，它們只是暫時領先了半圈，而這是一場馬拉松，領先優勢隨時可能被反超。在這個行業里，我不認為存在真正的權威。年輕人與所謂的世界一流專家，本質上站在同一起跑線上。

我現在特別想做的一件事，是重新構建一套話語體系。比如，為什么一定要有“架構師”這個角色？也許我們會創造出新的頭銜和新的定義，年輕人同樣可以參與其中。我甚至會認為自己是世界一流的 AI coding 專家，并不是因為我一定最強，而是因為我沒有看到明顯比我強很多的人。

如果一個年輕人有足夠的膽量，想成為新時代的軟件工程思想領軍人物，現在就是最合適的窗口期，可能只有一到兩年，必須立刻行動。一定要獲取一手信息，不要只看公眾號，不要只接受別人咀嚼過的結論。親自動手的成本其實很低，只要你自己去實踐，就會獲得與他人完全不同的體驗，通過不斷對比，你才能逐漸和別人站在同一水平線上。如果你只是跟著某位名人說什么就做什么，那永遠都會慢一步。更何況，很多觀點本身也帶有立場和商業目的。

另外，如果你真的想探索這個方向，不要只輸入、不停地聽，還要輸出、去表達。講對講錯并不重要，也不存在標準答案。只要你的觀點足夠有邏輯，就能吸引到志同道合的人，甚至走向創業。我認為，對于真正有目標、有野心的年輕人來說，這是一個極好的時代。

松子：AI 編程正在成為標配，已經不再是加分項，而是基礎能力。中間層開發者正在大規模轉行或被淘汰，“一人公司”會成批出現，這種趨勢已經在現實中開始顯現。在這樣的背景下，最大的挑戰在于學會如何與 AI 協作，并把更多時間投入到業務理解上。真正理解業務的人，才能告訴 AI 應該做什么。

歸結為一句話，就是要放下對手工寫代碼的執念，從“敲鍵盤”轉向“拿指揮棒”。在 2026 年，真正具備競爭力的，不是單純寫代碼的人，而是能夠指揮 AI 寫代碼、并把握方向的人。

會議推薦

InfoQ 2026 全年會議規劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產業落地，從技術前沿到行業應用，全面覆蓋 AI 與軟件開發核心賽道！集結全球技術先鋒，拆解真實生產案例、深挖技術與產業落地痛點，探索前沿領域、聚焦產業賦能，獲取實戰落地方案與前瞻產業洞察，高效實現技術價值轉化。把握行業變革關鍵節點，搶占 2026 智能升級發展先機！