AI 領導力：像管理團隊一樣管理 AI

演講嘉賓｜揭光發

編輯｜Kitty

策劃｜QCon 全球軟件開發大會

在 AI 浪潮席卷各行各業的當下，我們正經歷一場前所未有的“原地升級”：AI 并非取代崗位，而是要求所有從業者，特別是身居管理和架構崗位的領導者，重新審視并升級其領導力范式。本文整理自騰訊專家工程師揭光發在 QCon 上海 2025 的演講 “AI 領導力：像管理團隊一樣管理 AI”。他深入介紹了如何以更高效的方式管理 AI，如同管理一支高效的團隊。

我們深知，對于架構師和高管而言，管理團隊、協調資源、驅動項目是日常核心。然而，傳統的人力管理往往伴隨著反饋延遲、過程不可控等挑戰。奇妙的是，“管理 AI ”恰能解決這一悖論。

AI 的即時反饋和高可控性，不僅能帶來巨大的管理杠桿效應，更提供了一種前所未有的高效管理模式，讓領導者能夠以更精準、更可控的方式，驅動“數字員工”完成目標，重拾作為“指揮官”的掌控感和成就感。

為實現這一目標，我們將探討“ AI 領導力”的四大核心支柱。這包括像管理團隊一樣知人善任地組建 AI 隊伍，高層級地設定目標，以及戰略性地管理過程和專家級地驗收成果。

AI 不會削弱技術領導者的價值，反而會將其無限放大。未來的優秀技術領導者，將是那些能夠高效管理和編排人機混合團隊，共同交付卓越成果的“超級指揮官”。

預告：將于 4 月 16 - 18 召開的 QCon 北京站設計了「AI 時代的“超級團隊”」專題，本專題不談模型技術本身，只談人與組織的進化。我們將揭秘小團隊創造大價值的邏輯，探討如何彌補人與 AI 的能力鴻溝，重構產品與技術的協作關系，并建立一套適應 AI 時代的全新管理與度量體系，打造高適應性、高產出的“超級團隊”。如果你也有相關方向案例想要分享，歡迎提交至：

https://jinshuju.com/f/Cu32l5

以下是演講實錄（經 InfoQ 進行不改變原意的編輯整理）。

今年年初 3 月，Manus 發布時，我便廣泛提及一個觀點：如今我們使用 AI，已不再將其僅僅視為工具，而是實實在在地將其當作能幫我們干活的人來使用。盡管 AI 本身沒有情緒，但管理人時所涉及的諸多要點，在管理 AI 時也一個都不能少，這是我今天想要表達的核心內容。

1 Vibe Coding ——"心流"在編碼中重現

首先，我們來談談 Vibe Coding。對于從事技術工作，尤其是擔任技術領導的人員來說，這是與 AI 直接相關且能顯著提升工作效率的領域。使用 AI 來編寫代碼，如今已司空見慣，且在近一兩年成為主流趨勢。我稍后會舉例說明，但可以說，我所編寫的代碼中，AI 的參與度幾乎達到了 100%。

Vibe Coding 的概念其實無需過多解釋。它主要是通過自然語言描述需求，然后讓 AI Agent 來實現代碼編寫、測試并運行。在這個過程中，你無需過多關注代碼的具體實現細節，只需不斷提供反饋，指出“這里還不行”，并告知下一步該怎么做。最終，通過與 AI 的協作，完成整個軟件的交付，這就是 Vibe Coding。這實際上是 AI 與工程師，乃至技術領導日常工作中頻繁涉及的一項活動。

介紹一下自己在 Vibe Coding 方面的經歷。2022 年 ChatGPT 發布后，我們發現除了與它對話聊天、觀看它寫代碼外，還能有更多應用。2023 年早期，我們開始在 ChatGPT 網頁上與其交流，讓它編寫一些代碼片段。當時大家開始覺得，AI 在這一波的發展中確實表現不錯。然而，真正大規模將 AI 應用于生產環節，是在 2023 年底 GitHub Copilot 插件推出之后。那時，我所編寫的代碼中，AI 的含量已經達到了 85%。說白了，2023 年 3 月我重新開始寫代碼，是因為我可以借助 AI 實現想法，而無需親自編寫代碼。這使得許多小型項目，尤其是工具類技術產品，開始通過 AI 逐漸誕生。到了去年 9 月，Cursor 出現后，我更加放開手腳，真正以 Agent 的方式編寫代碼，直至今日。如今，Claude Code 等各種智能代碼代理層出不窮，多到兩只手都數不過來。對我個人而言，目前幾乎 100% 的代碼都是由 AI 編寫的，除非我發現某行代碼可以刪除以節省 Token，否則我不會親自編寫。

在我的帶動下，我的團隊也積極投身于 AI Coding。目前，團隊中大約 50% 的代碼由 AI 編寫。之所以沒有達到 100%，原因有兩方面。一方面，對于一些前端項目，AI 還原度并不高。因為視覺模型與文本模型之間存在天然的差距，目前尚未得到很好的解決，視覺還原能力這一塊還存在不足，所以這部分工作仍需人工參與。另一方面，有些團隊成員不想讓 AI 完全包辦所有工作，他們希望保留一定的掌控感。他們會編寫大致的框架，然后讓 AI 填充細節。這樣一來，如果出現問題或故障，他們可以迅速自行修復，而無需再次求助于 AI。這種主動降低 AI 含量的做法，導致團隊中并非所有人都能達到 100% 的 AI 含量。

在我們團隊所在的公司，有一個名為 loki 的低代碼項目。2023 年，我帶領團隊搭建了一個跨語言的邏輯編排平臺，其中涵蓋了前端和后端三種語言的運行時環境，分別是 Golang、Python 和 Node.js。這個項目是我 2023 年開始重新編寫代碼時著手的，當時有一兩名同事在閑暇時間參與其中。此外，我們還在內部使用了一個 AI Agent 低代碼搭建平臺，這可能和 Coze 或 Dify 同期或更早，大約在 2023 年中后期到 2024 年早期，我就開始著手這個項目。當時我發現 AI Agent 即將興起，并且會有廣泛的應用，于是開始帶領剛加入團隊的實習生同學一起推進。在這個項目中，大部分后端代碼是在我的指導下由 AI 編寫的，其中 95% 以上的代碼都由 AI 生成。但我必須強調，盡管 AI 完成了大部分代碼編寫工作，但這并不意味著我沒有投入精力，稍后我會詳細說明這一點。

最近的一個案例是大型前端組件的重構遷移項目，我們將一個大型項目從 Angular 遷移到 React。大家都知道，Angular 在國內并不算特別流行，而且技術棧相對有些過時了。遷移過程中，我們需要深入理解原有代碼的邏輯，并進行大量測試以確保遷移的準確性。我們通過 AI 的方式來進行遷移，具體邏輯是：先在舊的組件代碼中編寫單元測試，完成單元測試后，將舊代碼轉換為新的組件代碼，并同步遷移單元測試。但這還不夠，我們還利用線上大量的數據（幾十萬條）作為回測數據進行測試。整個過程中，從代碼翻譯、測試編寫到測試運行，包括測試數據驗證腳本的編寫，幾乎都由 AI 完成。原本可能需要一兩個人花費半年以上時間完成的工作，我們通過 AI 協作壓縮到了一到兩個月。當然，在這個過程中，我們也會進行人工抽查，以確保遷移的準確性。

我想引入一個名為“心流”的概念。有一天，我和朋友聊天時提到，我很久沒有體驗到一種感覺了，但最近這種感覺又回來了——那就是我找到了心流。我想每位程序員都曾有過這樣的體驗：戴著耳機，全神貫注地敲代碼，不知不覺一個上午就過去了。在那個過程中，你沉浸于代碼世界，無人打擾，從編寫代碼到測試、運行，再到不斷調試，整個過程掌控感極強，時間也在不知不覺中流逝，這就是心流狀態。其實，所有創作者都會經歷這種狀態。但為什么我很久沒有體驗到這種感覺，卻又突然找回了呢？成為團隊領導后，你會發現管理團隊和編寫代碼是兩件完全不同的事情。當你安排團隊成員去做一件事時，你需要等待他們的反饋，這個過程往往漫長，中間還會有許多會議和溝通協調，整個流程并不順暢。因此，成為領導后，我在很長一段時間內都失去了這種心流的感覺。然而，通過 Vibe Coding，這種感覺又回來了。原本可能需要十多天才能完成的項目，現在通過 AI 協作，我下達指令后，可能一兩分鐘就能得到初步結果，然后我繼續給予反饋。這種反饋鏈條的閉環時間非常短，所以我又重新找回了那種在管理層面上的心流感覺。

在談到 Vibe Coding 時，我們也不得不提及 Software 3.0，因為當我們說要與 AI 共事時，這里的 AI 幾乎指的都是 Agent。而 Agent 的本質是一種軟件形式。無論是 Software 3.0 還是 Vibe Coding，都與 Karpathy 提出的概念有關，所以在這里一并提及。那么，1.0、2.0、3.0 這三種范式是如何演進的呢？

1.0 時代，我們手動編寫代碼，經過編譯后運行。代碼中的邏輯是明確寫好的。例如，要實現對一些詞語的情感判定，我們會用 if-else 語句來編寫邏輯：如果文本中包含“amazing”，就判定為褒義。

2.0 時代，出現了一種通過神經網絡或機器學習訓練出的小模型，比如一個純視覺識別模型。這種模型不是通過編寫代碼實現的，而是通過數據訓練得到的。對于情感判定，我們會用訓練好的神經網絡模型來預測詞語的情感傾向。

到了 3.0 時代，我們所看到的是基于大語言模型的衍生程序，也就是 agent。以情感判定為例，我們直接給 Agent 一段話，用自然語言與它交互，請求它判斷文本中單詞的傾向。Agent 會直接給出大語言模型的判定結果。Software 3.0 的本質是智能體系統，以自然語言為接口，讓 AI 能夠理解人類意圖并自主執行任務。

2 Vibe Working —"心流”延伸至所有工作

剛才我提到的主要是關于編程的內容，其實我們已經對它非常熟練了。現在我想進一步談談 Vibe Working，也就是“一切皆可 Vibe”的概念。如今，大家都在討論 AI 如何滲透到各個領域，我也想分享一些我在其他方面與 AI 協同工作的例子。

比如制作幻燈片 Vibe Sliding。從今年開始，我再也不為準備 PPT 而焦慮了。過去，我總是拖延到最后一兩天才開始制作幻燈片，因為雖然演講的內容我早已了然于心，但排版、繪制圖形、尋找圖片并進行排版這些繁瑣的工作讓我感到頭疼。我這份 PPT 完全是通過 AI 生成的，從風格上應該能看出來，理論上人工制作的 PPT 不會使用這么多顏色，但它的可讀性依然不錯，能夠清晰地傳達信息。整個 PPT 的制作過程就像編程一樣，通過 AI 完成，包括插入的 logo 等元素也都是通過 AI 添加的。而且由于 PPT 本質上是一個網頁，AI 在編寫網頁方面也早已駕輕就熟。現在，我再也無法回到手工制作 PPT 的時代了，基本上都是通過 AI 來完成這項工作。

還有 Vibe Writing，也就是寫作助手。現在大家看到的許多文檔或公眾號內容，基本上都是通過 AI 流水線式生成的。尤其是今年，AI 可以通過多 Agent 的方式拆分不同章節，讓不同的子 Agent 分別撰寫不同章節，這讓撰寫大型文檔變得輕而易舉，甚至撰寫論文、專利等也不在話下。我自己也用這種方式撰寫產品文檔、說明書，甚至 API 接口文檔也都是通過 AI 完成的。

閱讀論文曾經是一件痛苦的事，過去要讀完一篇長篇 PDF 并理解其中的所有內容，需要花費大量精力。現在，我們通常讓 AI 代讀。對于長篇公眾號文章或新發布的論文，我們首先會轉發給 AI 工具，比如騰訊元寶公眾號的機器人號，它會為你總結內容，這也是一個很好的 AI 使用案例。

還有一個有趣的應用場景，那就是學習新概念。比如我們學習大型語言模型的工作原理時，如果有動畫可視化展示其關鍵動作，我們會更直觀地理解。AI 在這方面可以大顯身手，比如它可以為我生成動畫，展示光速的測量方法，或者邁克爾遜干涉儀中不同顏色光條紋的影響。在學習層面，這讓我能夠與 AI 進行非常強的互動，生動地演示我想要了解的知識點。對我來說，我已經不需要再去翻閱厚重的書籍，而是直接向 AI 提問，它會為我提供答案。

再比如個人秘書，我也進行了多次迭代。最早的版本是基于 Gemini CLI，它幾乎是免費的，可以記錄我的日常工作、安排日程等，所有這些都可以通過命令行與它對話完成。這與我們常用的結構化 Todo List 完全不同，Todo List 需要你自己去查看和記錄，而這種秘書更像是真正的秘書，它會為你搭建一套數據存儲系統，但你需要提示它進行結構化存儲。現在，我已經升級到了第二版，加入了 Claude Code 和其他模型，功能更加強大。我還把它與我的企業微信打通，比如今天我要做演講，它會提前幾天提醒我準備，甚至處理各種出差事宜。它就像一個真正的秘書，只是它并非人類。AI 在我的工作和生活中，除了編程之外，還能在許多方面作為我能力的延伸，幫我完成許多不同的任務。

Vibe Working 的核心在于人與 AI 的協同合作。我們需要清晰地描述自己的需求，然后將任務交給 AI 去執行。在這個過程中，AI 會根據我們的指令完成相應的工作，并將結果反饋給我們。

3 AI 領導力——新范式下的核心四要素

回顧過往，當我們并非領導者，而是專注于具體事務時，我們總是親力親為。例如編寫代碼，我們一行行地寫，然后編譯、運行、發布。那時，我們直接參與具體的工作。然而，當我們將這些任務交給 AI 去完成時，情況就發生了變化。我們不再直接動手，而是開始指導 AI 去完成這些任務。

指導 AI 的過程是怎樣的呢？首先，我們需要為它設定明確的目標。但僅設定目標是不夠的，我們還需要管理整個過程，指導 AI 如何行動，當它出現錯誤時，我們要糾正它。最終，當 AI 交付成果時，我們需要進行驗收。如果驗收結果不理想，那么就需要返工，重復之前的過程。這個過程，難道不像是與下屬或隊友溝通協作的過程嗎？正是在這個過程中，我意識到，當我們開始使用 AI 時，我們其實已經從執行者變成了領導者。

你所領導的可能不是人，而是 AI。但本質上，這并沒有太大區別。未來，大家會逐漸發現這一點。AI 在某些方面甚至比人類更好管理，因為它更加穩定，不會給你穿小鞋或鬧情緒。但在一定程度上，管理 AI 的要求甚至比管理人更高。管理人時，你可以發脾氣，施加壓力，從而激勵他們更好地完成任務。但對 AI 來說，如果你的指令不清晰，它就無法執行任務，而且它也不會反抗。因此，在一定程度上，管理 AI 可能比管理人更具挑戰性。這實際上是溝通和認知傳遞能力的極致考驗，也是個人素質的體現。

我們來定義一下 AI 領導力。剛剛我已經提到，我們需要設定目標、管理過程、驗收結果。這其實也涉及到了“知人善任”的概念。不過，或許我們需要將其改為“知 AI 善任”。這四個關鍵要素可以概括為：設定目標、過程管理、結果驗收以及知人（AI）善任。

首先就是知人善任，了解你的“隊友”，選擇合適的 AI 模型、工具和代理。如果現有的工具不適合，你可能需要打造或打磨出適合自己的工具。這其實是在開始之前，組建團隊時需要考慮的事情。在人員管理中，我們講求選、育、用、留，而在 AI 領域，選也是至關重要的第一步。

按照應用場景來劃分，我們常用的場景主要有以下幾種：通用的大語言模型、代碼助手以及 AIGC 領域，包括圖片、音頻、視頻生成等。我們需要在這些領域中尋找行業內的頂尖模型，當然，這需要結合自身實際情況，因為有些模型可能成本較高。我在這里僅列舉了前兩種場景的選型或比較案例，供大家參考。

在 AI 編程工具的選型方面，目前 Claude Code 是我的首選。除了編程之外，我之前提到的個人秘書以及 PPT 制作等 Agent 工具，也都是基于 Claude Code 構建的。它的優點在于非常簡潔，其 Agent 也很簡單。它的特點是將對話中的所有內容都作為上下文傳回，這種“大力出奇跡”的方式使得它在處理上下文時表現得比其他工具更出色。例如 Cursor 等其他 IDE 需要進行上下文壓縮，而 Claude Code 則不需要。我們了解背后的邏輯，但也不會直接使用它的 API 付費方式，而是選擇它的套餐，比如 Pro 版本。不過，使用 Pro 版本很容易觸發 Token 的上限。即使你選擇了 20 美元的套餐，現在又增加了周上限，很容易就觸發了。

Cursor 在國內進行了限制，但當然有一些技巧可以繞過。即使在自動模式下，它也可能為你提供更好的模型，因為它需要保證效果。所以在這方面，我并不太擔心。不過，它的收費方式變成了不封頂，即 20 美元用完后會繼續計費。但我一直保留著 20 美元 500 次的計費方式，堅持不切換。到現在我發現，它的調用限制已經從 20 次增加到 200 次了。所以對我來說，這也是一個非常充足且性價比高的方案。目前，我優先使用 Claude Code，而 Cursor 則作為備份。

騰訊的 CodeBuddy IDE，它的特色在于貫穿了從設計到開發再到發布的完整鏈路。尤其是與 Figma 的深度整合，使得在界面還原方面表現出色。我們團隊也嘗試使用過這一功能，與直接使用 Cursor 搭配 Figma 的 MCP 相比，差異十分明顯，這一點值得大家關注。

接著是 V0.dev，這是 Vercel 團隊的另一款產品，專注于 Web 開發。在 V0 上進行開發的速度非常快，這也是它名字的由來——“V0”意味著“version 0”，即快速搭建原型和 Demo。雖然它的定位是用于快速原型開發，但實際上，用它來開發正式產品發布也并無太大問題，畢竟它背后有 Vercel 強大的底層支持。

再來說說 Gemini，這款模型如今可以說是厚積薄發。無論是圖片生成還是代碼編寫的能力，都呈現出越來越好的態勢。特別是它的 CLI，個人注冊后幾乎等同于免費使用。每分鐘限制 60 次調用，但一天有兩三千次的調用額度，對于日常使用來說，幾乎感受不到 API 調用的限制。

不得不提的是 GLM 4.6，在我的 Claude Code 20 美元額度受限之后，我基本都用它來作為替代。從產出效果來看，它能達到 Claude Code 大約 80% 的效果，這是我的個人體驗。目前我也大量使用這個 4.6 版本，不過有一點遺憾，國內模型的視覺能力相對較弱，4.6 本身并不擅長視覺處理，而是通過 MCP 的方式支持視覺功能，這種方式比較繞。我還是希望國內能盡快推出像 Sonnet 那樣的多模態模型。不過，GLM 4.6 的套餐性價比很高，但如果不定制套餐，Token 消耗會比較高。

Kimi K2 是我最近用的一個加速版，它的解題速度快，無論是在質量還是成本上都優于 GPT 5。而且 Vercel CEO 大贊 Kimi K2，他在 x 公開表示，在一項內部智能體真實場景基準測試中，來自中國的 Kimi K2 模型表現優于 GPT-5 和 Claude Sonnet 4.5。

最后是 DeepSeek 3.2，它的 Token 消耗非常低，價格也特別便宜。與 Kimi 或者 GLM 相比，我自己的感受是，使用 DeepSeek 的費用不到其他兩者的 1/4，甚至更低。DeepSeek 3.2 引入了稀疏注意力機制，本身就將 Token 價格降低了 75%，而且它對 Agent 的支持也非常好。有一段時間我因為 Sonnet 額度不夠，切換到 DeepSeek，用了很長時間才花一兩塊錢，這讓我非常驚訝。我覺得很多公司在評估后，如果真的要用 API，最終可能會選擇 DeepSeek。它在 Coding 層面與 GLM 相比可能稍遜一籌，但問題不大，當然與 Sonnet 相比還是有差距。

我用的這些工具，其實都是在 Claude Code 上驅動的。Claude Code 可以使用不同的模型，我所說的使用 GLM 4.6、DeepSeek、Kimi 2，都是在 Claude Code 上切換模型來驅動。所以，它們的程序 Agent 邏輯還是遵循 Claude Code 的邏輯，只是模型變了，但輸出質量都不錯，這也得益于 Claude Code 本身的 Agent 工程素養和上下文管理方式。我推薦了多個國內的模型，但這些模型都需要搭配在 Claude Code 中使用，效果會很好，這與工程化密切相關。我也建議大家可以嘗試一下這些工具，這就是我在編程層面工具選擇的體會。

在與 AI 協同工作的過程中，目標設定是至關重要的第一步。很多人會問，如何設定目標？其實，核心方式就是通過精確的表達來傳達需求。過去，在使用通用聊天機器人如 ChatGPT 時，我們常常需要通過復雜的提示詞框架來引導機器人完成特定任務，比如編寫代碼。那時的提示詞可能包含身份定位、角色設定以及各種指令，甚至有些奇奇怪怪的框架。然而，如今進入 Agent 時代，情況發生了變化。這是一個場景化協作的時代，需求表達變得更加直接和關鍵。我們不再依賴復雜的提示詞技巧，而是要清晰地表達自己的需求。

需求表達能力成為與 AI 協同工作的核心能力。為了讓 AI 理解并執行任務，我們需要非常精確地描述需求。這其實比管理人還要復雜，因為 AI 沒有情緒，但它需要清晰的指令。現在，為了讓 AI 完成任務，我需要詳細地寫出任務細節、想法和思路。如果 AI 不理解，我還需要繼續補充。有時，我輸入的內容可能多達幾百字，這是前所未有的。所以，管理 AI 并不比管理人輕松，你需要全方位地表達清楚，對業務場景有深刻的理解，知道領域的專業知識，并且對期望的成果有準確的預期。你不能不確定結果就隨意給出需求，否則 AI 給出的結果多半不符合你的期望。此外，你還需要設定約束條件，甚至需要對任務進行拆分，明確是讓 AI 一竿子插到底完成任務，還是分步驟執行。這些都需要在需求表達中體現出來。

關于是否使用提示詞，我在設計 AI Agent 時會用到提示詞來設定其功能，但在使用 AI Agent 時，關鍵在于清晰地表達需求。當你輸入的需求比較模糊，比如只有一句話時，AI 給出的結果往往是籠統的。在這種情況下，你可能覺得 AI 給出的 50 分或 60 分的結果已經很不錯了。但如果你想讓 AI 給出 80 分、90 分甚至滿分的結果，你就需要從不同角度、細分地描述你的需求，明確你希望的產出是什么。這不是提示詞技巧，而是深度挖掘你對目標的定義，具象化你的想法。

接下來是過程管理。當我們讓 AI 執行任務時，可以選擇讓它一竿子插到底，從下午 2 點開始工作，到 5 點回來驗收成果。這是一種方式。但另一種方式是將任務拆分成多個子目標，這涉及到所謂的粒度管理。當我們需要將任務拆分時，還需要考慮是通過串行還是并行的方式來實現。并行處理是常見的選擇，比如同時打開多個窗口讓 AI 完成不同任務。然而，在并行處理時，我們可能會遇到工作目錄污染的問題，尤其是在編寫代碼時，如何避免多個 feature 之間的相互干擾是一個挑戰。當所有 AI 任務完成后，我們如何驗收結果？人類是否能夠在短時間內切換多個上下文？這反過來挑戰了人類的上下文管理能力。這些就是過程管理中的一些核心挑戰。

在編程領域，我們并非總是采用“一竿子捅到底”的方式。事實上，軟件工程的思想一直存在，而這些思想同樣適用于 AI 編程。Kiro 提出了一個概念，即 Spec-Driven 的 AI 編程。這實際上是在 AI 編程領域的一種標準化或流程化方式。其過程通過幾份標準文檔來驅動整個任務的推進。首先，通過需求文檔與用戶梳理需求，然后根據需求文檔編寫設計文檔，設計文檔再驅動任務的拆分，最終由 AI Agent 根據這些任務逐步實現具體需求，從而完成整個項目。這并不是一氣呵成的方式，而是一個有規劃、有步驟推進任務的過程。

與此同時，社區還存在其他框架，例如 BMAD-METHOD。這種框架涉及多種角色，包括產品經理、設計師以及 Scrum Master，他們共同規劃項目目標。Scrum Master 負責用戶故事的切片，隨后進入敏捷循環開發、驗證和交付等環節，多個 Agent 協同完成整個項目。

在工作區隔離方面，常見的做法是讓 Agent 在本地工作，例如使用 Claude Code 處理本地事務。通常有兩種隔離方式：容器隔離和 Git Worktree 方式。我更推薦后者，因為它更輕量級，且是 Git 自帶的功能，可以直接在你的工作目錄下使用。

最后是驗收環節，驗收方式主要有兩種：自動化驗收和人工驗收。我們盡可能實現自動化驗收，但自動化驗收需要邏輯清晰，例如編寫和運行單元測試、編譯或格式檢查等，這些通常適用于明確的編程和數學場景。然而，人工驗收有時是不可避免的。人工驗收涉及多個方面，包括你在該行業的專業知識水平、審美能力以及對用戶體驗的感知能力等。這些都有一定的要求。因此，在驗收層面，我們應盡可能實現自動化，同時通過人工驗收來兜底。

我曾遇到一個例子，當時我在編寫一個 MCP 多節點傳輸功能。那時的 AI 還不理解 MCP 是什么，生成的代碼無法運行。如果我不了解背后的原理，就無法完成這個任務。因為如果 AI 生成的代碼無法運行，而我對這個領域一無所知，就會陷入死循環，項目也就無法繼續。這在一定程度上反映了，如果沒有專業知識，我們無法讓 AI 輸出我們想要的結果。后來，我通過閱讀文檔、理解原理，再反過來告訴 AI 應該如何設計和實現，最終才成功生成了可以運行的代碼。

這讓我得出一個結論：雖然大家都在使用 Claude 等 AI 工具，但不同人使用的結果卻千差萬別。這背后的原因在于我們對行業的認知、專業知識以及個人經驗的差異。例如，我之前舉辦的一些 Vibe Code 沙龍活動中，讓大家開發一個待辦管理應用。那些沒有任何技術背景的人，生成的應用可能只能達到 50～60 分，勉強可用。而有產品經理經驗的人，能夠清晰表達產品需求，生成的應用效果則大不相同；技術人員則會指定技術棧，提出具體的技術要求，他們的應用可能會更深入、更完善。

我很喜歡米開朗基羅的一個比喻：每塊大理石里都藏著一件作品，雕刻師只是將它找出來。在實踐中，我感覺 AI 就像人類知識的壓縮器或濃縮器，它本身蘊含著豐富的知識。關鍵在于我們這些使用者，如何通過語言這個“刻刀”去雕琢它，讓它將已知的知識或能力精確地輸出給我們。

4 行業影響————軟件世界的"板塊漂移"

無論是 Vibe Coding 還是 Vibe Working，AI 對我們行業的沖擊是顯著且深遠的。AI 的出現讓整個市場進入了一個增量的過程。這種增量并非憑空產生，而是源于原本就存在的需求。過去，許多需求因為技術門檻過高而被壓抑。例如，一些個人想要開發個性化的小工具，但由于不會編程，也沒有足夠的資金聘請開發者，這些需求一直未能得到滿足。然而，AI 的出現打破了這一局面，它降低了技術門檻，使得這些被壓抑的需求得以釋放。

這種需求的釋放也帶來了矛盾。盡管市場需求在增加，但與之相對應的工作崗位卻可能在收縮。這是因為 AI 能夠高效地完成許多任務，原本需要人力完成的工作現在被 AI 所取代。這種現象導致了人才結構的變化。未來，我們會看到大量非專業人士，甚至可以說是“小白”，借助通用的 AI 能力滿足中小規模的需求，這將成為市場的主流。而在頂端，會有少數專業人士結合 AI 的力量，處理更復雜、更高端的任務。無論在哪一層，AI 都將發揮重要作用。

這種變化意味著中間部分的人才將面臨分流。一部分人可能會努力提升自己，進入頂端的專業領域；而大部分人可能會下沉，與普通“小白”處于同一水平。這實際上是對行業格局的一次重新洗牌。在數字化行業尤其如此，未來人和組織都將朝著 AI Native 的方向發展，即人們會習慣于在工作中依賴 AI，這樣才能適應未來的趨勢。如果仍然單靠個人力量，不借助 AI，很快就會被時代拋棄。組織也是如此，傳統的組織架構將逐漸轉變為扁平化且 AI Native 的模式。未來，這將是一個超級個體崛起的時代。

演講嘉賓介紹

揭光發（Jeff）是騰訊云架構師聯盟社群管理主席，騰訊專家工程師。

20 年研發與團隊管理經驗，前騰訊云 TVP，現騰訊全棧技術專家，公司級低代項目負責人，是 IEEE 低代碼標準及大灣區企業低代碼標準的主撰寫人；大模型應用早期實踐者與布道師，是國內頂級行業 / 技術峰會相關話題優秀講師及出品人。在低代碼與 LLM 結合場景有深度的實踐，愿景是“人人能編程”。帶領團隊深度踐行 LLM 對研發提效、探索 Vibe Coding 在專業程序員與準開發者群體的落地，個人代碼全棧 AI 含量幾近 100%。

會議推薦

OpenClaw 出圈，“養蝦”潮狂熱，開年 Agentic AI 這把火燒得不可謂不旺。在這一熱潮下，自托管 Agent 形態迅速普及：多入口對話、持久記憶、Skills 工具鏈帶來強大生產力。但這背后也暴露了工程化落地的真實難題——權限邊界與隔離運行、Skills 供應鏈安全、可觀測與可追溯、記憶分層與跨場景污染、以及如何把 Agent 納入團隊研發 / 運維流程并形成穩定收益。

針對這一系列挑戰，在 4 月 16-18 日即將舉辦的 QCon 北京站上，我們特別策劃了「OpenClaw 生態實踐」專題，將聚焦一線實踐與踩坑復盤，分享企業如何構建私有 Skills、制定安全護欄、搭建審計與回放機制、建立質量 / 效率指標體系，最終把自托管 Agent 從可用的 Demo 升級為可靠的生產系統。