編者按： 當 AI 不僅能寫代碼，還能同時處理多個開發任務，軟件工程師這一角色是否正面臨根本性的重塑？

我們今天為大家帶來的文章，作者的核心觀點是：並行智能體是將深刻改變軟件開發模式的革命性技術。

作者從 AI 編程工具的演進談起，揭示了從 Copilot 的代碼補全到“氛圍編程”的自然語言生成，再到當前的範式突破 —— 並行智能體。作者還坦誠分享了實際應用中的成功率分佈，指出了智能體擅長與不擅長的任務類型，並強調了全棧技術、問題拆解和代碼審查等技能在新工作流中的核心地位。最後，文章提出了支持並行智能體的工程實踐，包括快速 CI/CD、完善文檔和單體倉庫架構等關鍵要素。

作者 | Igor Šarčević

編譯 | 嶽揚

我在這個行業摸爬滾打多年，目睹各種技術浪潮翻涌又退去。見過人們對新框架的熱烈追捧，聽過革命性工具許下的承諾，也見識過那些聲稱要“顛覆一切”的誇張預言。但大多數時候，這些技術最終不過是營銷話術包裝下的漸進式改進。

但並行智能體（parallel agents）呢？這次完全不同。這是我從業以來第一次能夠毫不誇張地説，我們正在見證一種將深刻重塑軟件開發模式的技術。

01 發展歷程

要理解當下，我們需要回溯 AI 編程輔助工具的完整演變過程。這一歷程的起點是 GitHub Copilot，它首次將 AI 結對編程的概念帶入現實。這款工具能在你鍵入時自動補全代碼 —— 推薦函數功能、完善實現邏輯、協助處理重複性任務。

隨後出現的 Windsurf 和 Cursor 等這類 AI 驅動的編輯器，將這一理念推向新高度。它們將 AI 深度集成至開發環境中，不再侷限於自動補全，而是允許開發者與 AI 直接對話：討論代碼邏輯、尋求重構方案、獲取調試建議。此時的 AI 已能理解整個代碼庫，提供真正貼合上下文的輔助。

今年，我們進入了所謂的“氛圍編程”（vibe coding）時代 —— 只需使用自然語言描述需求，AI 工具就能從零生成完整函數、類或整個實現方案。當你説出“創建支持谷歌登錄、GitHub 登錄和微軟登錄的註冊表單”，它便能輸出符合預期“氛圍”的可運行代碼。

“氛圍編程”這一術語由安德烈·卡帕西（Andrej Karpathy）在下列這段推文中首次提到，它精準地捕捉了這種編程新範式的使用體驗：

有一種編程新範式我稱之為“氛圍編程” —— 開發者只需沉浸於“氛圍”之中，擁抱 AI 輔助編程工具所帶來的指數級效能提升，甚至無需在意代碼本身。這之所以成為可能，是因為 LLM（例如搭載 Sonnet 的 Cursor Composer）已強大得超乎想象。我現在甚至直接通過 SuperWhisper 與Composer 對話...

— 安德烈·卡帕西 (@karpathy) 2025 年 2 月 2 日[1]

這種突破無疑是革命性的。突然間，生成樣板代碼、構建簡單函數、創建 UI 組件乃至處理複雜的代碼實現，都只需通過語言描述即可完成。 許多工程師使用這些工具後，發現它們在處理特定類型的工作時展現出超乎想象的實用價值。

這項技術已經成熟到足以改變我們許多人的編程工作方式：開發者不再需要從零開始搭建代碼框架，而是直接基於 AI 生成的可用代碼雛形進行迭代優化。這使得原型設計可以更快完成，減少了重複編碼的枯燥勞動，為高效開發開闢了全新可能。

02 並行運行智能體

現在的突破在於：你可以同時運行多個 AI 智能體，讓它們各自處理不同任務。無需等待一個智能體完成工作後再啓動下一個，您可以同時運行多個智能體 —— 一個構建用户界面，另一個編寫 API 接口，第三個創建數據庫模型。

其核心優勢很簡單：實現真正的多任務並行處理。這並非源於更聰明的 AI 或更優的算法，而是並行化能力的突破。使用的仍是之前的氛圍編程工具，只是現在能同時運行多個實例。

首個提供成熟解決方案的是 GitHub 推出的運行在雲端的 GitHub Co-Pilots。你只需在 Github 代碼庫中創建 issue 並描述需求。當你確認需求描述都已準備就緒，足以清晰定義該功能時，就可以將其分配給 Co-Pilot，然後等待處理結果。

在實際應用中，這意味着你可以遍歷現有的 issue，判斷其是否具備交由 AI 處理的完整上下文。之後只需等待系統發送通知並對結果進行審核就行了。

這徹底改變了我們的編碼方式。我們不再糾結於具體實現步驟，而是扮演起資深工程師的角色，為多個正在代碼庫中實現具體功能的智能體提供指導和所需的上下文。 工程師的工作職責現在轉變為審查代碼的正確性、確保架構決策合理、驗證實現的功能符合用户預期，並保證代碼滿足所有必需的安全與合規標準。

但智能體本身仍存在與氛圍編程相同的侷限性，它們同樣可能產生錯誤、缺乏足夠的上下文或無法理解代碼邏輯。但此時工程師（某種程度上還兼具產品負責人和設計師的角色）需要引導整個系統為你實現目標。

03 如何運用並行智能體工作

並行智能體正在重塑工程師的工作方式。現在你無需逐項處理任務，而是可以協調多個智能體同時開發不同功能或修復各類缺陷。你需要主動管理多個開發流程，在智能體完成每項工作時進行代碼審查與反饋指導。

採用這種方法後，我能同時管理 10-20 個開啓狀態的拉取請求（pull requests），每個都由專屬智能體負責處理。

以下是一些可遵循的實踐步驟：

1. 準備具有充分上下文信息的 issues

首先確保每個 GitHub issue 都包含足夠的上下文信息，讓智能體理解需要構建的內容及其與系統的集成關係。這可能涉及功能行為描述、文件路徑、數據庫結構等細節，或諸如顯示特定字段、處理邊界情況等具體要求。

2. 將 issues 批量分配給智能體

準備就緒後，將 issues 分配給 AI 智能體（例如 @copilot）。每次分配通常會新建一個拉取請求，智能體將在此制定實施計劃、創建檢查清單並開始執行。支持批量分配多個 issues，實現智能體並行工作。每個智能體通常需要 5-20 分鐘完成其工作。

3. 在本地審查並不斷迭代

智能體完成任務後，請在本地環境審查生成的拉取請求（PR）。必須進行功能測試與正確性驗證。若需要調整，可在拉取請求中留下注釋或反饋，智能體會持續優化解決方案。

4. 保持審核流程暢通

與傳統工作流程不同，並行智能體的調度機制能讓工程師始終保持高度專注的狀態。現在無需等待單個智能體完成任務，即可在多個活躍的拉取請求之間靈活切換 —— 根據需求隨時進行代碼審查、功能測試與反饋指導。這種工作模式讓我們能在多個任務上同步推進，且不產生過重的心智負擔。

04 對並行智能體的合理預期

使用並行智能體需要完全區別於傳統編程或氛圍編程的思維模式。這一轉變的重要性，不亞於最初從傳統編程轉向 AI 輔助開發。

4.1 思維模式轉變

控制方式從精確操控轉向全局調度。 你不再需要掌控每一行代碼，而是同時管理多個任務。要以系統工程師管理 Kubernetes Pod 的思維來運作 —— 每個任務都是可替代、可重啓的單元，而非需要精心呵護的獨立服務器。

所有操作轉為異步模式。 與需要實時等待反饋的氛圍編程不同，並行智能體默認是異步工作的。此刻輸入的上下文將決定半小時後的產出結果，你無法像過去那樣隨意給出模糊指令再中途修正 —— 因為每次調整都要等待一小時才能收到反饋。

批量處理思維替代線性處理思維。 不必從待辦清單內精挑細選某一個“完美任務”，而應找出一天內能協同推進的多個問題。推薦採用“2+5”模式：集中精力攻克 2 項關鍵任務的同時，並行處理 5-10 個後台小任務 —— 諸如文案調整、界面優化、解決次要 Bugs 這類可以在你專注核心工作時自動處理的事項。

4.2 實際成功率

別指望 100% 的成功率。根據我使用並行智能體進行編碼時的個人觀察，成功率分佈如下：

• 10%：一次生成完美方案，可直接交付。
• 20%：接近完成，僅需約 10 分鐘的本地微調。
• 40%：需要人工介入修正。
• 20%：完全偏離方向，需關閉 issue 並記錄經驗教訓。
• 10%：產品方案本身存在缺陷。

即便只有 10% 的任務被智能體完美解決，這個過程依然極具價值。智能體可靠地承擔了基礎工作 —— 定位文件、編寫樣板代碼、添加測試用例。當你進行審查時，大量基礎工作已完成，使你能專注於排查和修復特定問題。

當工程師對編碼智能體應有何種表現沒有合理預期時，挫敗感便會油然而生。有些工程師若得不到完美的解決方案便會直接放棄。我認為應該突破這種思維侷限，學會提取智能體的有效產出，並在需要時運用工程知識介入修正。

4.3 優勢與短板

並行智能體擅長處理：

• Bugs 的修復與競態條件問題的處理
• 後端邏輯、控制器模塊（譯者注：負責接收前端請求、協調不同服務組件並返回響應的代碼模塊。）與驗證邏輯
• 數據庫變更與遷移腳本
• 依賴包版本升級與代碼結構轉換
• 目標明確的小型任務

它們處理以下情況則比較困難：

• 全新的 UI 開發（通常需要實時視覺內容反饋）
• 需實時視覺內容反饋的任務
• 為已存在的 PR 補充未明確寫入文檔的需求或隱含邏輯
• 需要綜合考量超出 issue 範圍的上下文內容才能完成的複雜架構決策

4.4 在新的編程範式下，重要性提升的技能

在並行智能體環境中，這些傳統技能價值倍增：

全棧理解能力非常重要。 若你僅精通前端或後端，將會很快遇到瓶頸。智能體通常需要跨越整個技術棧的指導 —— 從數據庫遷移到 UI 更新，貫通前後端才能確保協作順暢與產出質量。

問題拆解能力成為一項核心技能。 龐大複雜的問題難以被智能體有效處理。將大問題分解為定義清晰的小任務，可使智能體獨立並行工作，從而提升整體產出效率，同時也讓代碼審查與集成工作變得更輕鬆順暢。

書面表達能力變得很重要。 智能體依賴你清晰詳細的 issue 描述來產出準確的結果。請避免使用模糊的語言、不必要的術語或模稜兩可的需求。指令越具體有條理，智能體的輸出質量越高。

質量保證和代碼審查技能在此工作流中佔據核心地位。 由於審查週期是主要瓶頸，快速評估代碼質量、發現缺陷及驗證需求是否實現的能力變得尤為關鍵。高效的測試與驗證能確保並行開發不會堆積未審查或存在故障的代碼。

使用並行智能體工作時，必須優化審查速度。 你可以同時啓動 50 個任務，但仍需逐一審查、理解與驗證。讓審查週期變得快速（理想情況下能在 10 秒內完成檢出、重構與測試）已成為整個工作流的關鍵所在。

05 實現並行智能體的工程實踐

要有效運用並行智能體，需要一個架構良好、能支持快速迭代與審查的工程環境。

5.1 快速的 CI/CD Pipeline

穩健的 CI/CD 流程能輕鬆驗證產出結果。當智能體完成工作後，你需要快速驗證這些代碼變更是否正確生效，同時避免人工部署帶來的額外負擔。自動化測試、快速構建和無縫部署流程能有效消除審查環節的阻力。若缺乏這些基礎支撐，瓶頸就會從智能體的生成效率，轉移至部署和測試階段。

5.2 系統文檔

當多個智能體在代碼庫的不同部分同時工作時，系統架構文檔就變得至關重要了。智能體需要理解組件間的交互方式、文件存放路徑、遵循的規範標準以及系統間的集成關係。完善的 API 文檔、架構決策記錄、編碼規範與系統職責範圍説明，能幫助智能體做出更準確的判斷，減少人工修正需求。

5.3 預覽與預發佈環境

需要可靠的預發佈環境用於人工測試智能體實現的功能。由於智能體採用異步工作模式，必須有一個穩定的預發佈環境來驗證其輸出，且不影響生產系統。該環境應貼近生產環境配置，支持快速部署，並允許輕鬆測試多個併發的代碼變更。為不同分支或拉取請求（PR）快速創建獨立環境的能力，能極大優化並行審查流程。

5.4 單體倉庫（monorepo）架構優勢

採用單體倉庫（monorepo）架構存放關聯服務與組件，更適配並行智能體的工作模式。這種架構讓智能體在單一代碼庫中即可獲得整個系統的上下文。

當智能體需要跨多個代碼庫操作時，它們會失去對服務間交互、共享庫與依賴關係的上下文認知，這將導致生成的解決方案在獨立環境中可以運行，卻會破壞系統間的集成接口。而單體倉庫使智能體能通覽完整的變更範圍 —— 在同一 PR 中同步更新 API 的規範定義、調整客户端代碼、修改可複用的工具類代碼。

統一的視角有助於做出更好的架構決策。智能體可參照現有的設計模式、複用通用的組件，並確保整個系統的一致性。代碼審查也變得更加有效，因為所有相關的代碼變更都集中在一處可見，便於驗證智能體是否引入了集成部署時才會出現的問題。

對於並行開發，單體倉庫簡化了部署與測試流程。我們無需跨多個倉庫協調發布，就能整體測試系統變更並實現原子化地部署。當需要跨越多服務邊界，去管理多個由智能體並行產生的代碼變更時，這種（單體倉庫）做法能有效降低複雜度。

06 支持並行智能體的工具

目前已有數款開發工具支持運行並行智能體，它們各具特色，成熟度也各不相同。

GitHub Agents 提供最成熟、最完善的體驗。它們直接集成在 GitHub Issues 中，並與 VSCode 無縫協作。只需將任務指派給 @copilot，智能體便會創建可供本地審查的 PR。雖然仍存在部分待優化的細節，但 GitHub 正通過持續迭代逐步解決這些問題。

Cursor 目前正通過測試計劃探索並行智能體的支持。該團隊已邀請部分用户體驗此功能，初期反饋顯示其實現方案頗具潛力。若你已使用 Cursor 進行氛圍編程，待其更廣泛地開放訪問權限後，不妨關注一下他們的並行智能體。

OpenAI 的 Codex CLI 同樣支持在雲端運行智能體，從而實現此類並行開發工作流。該命令行工具可啓動持續在遠程運行的智能體，使您能夠管理多個併發編碼任務，而無需佔用本地環境資源。

每款工具對並行執行的實現思路略有差異，最佳選擇取決於你現有的開發流程與工具偏好。

07 總結與展望

我使用並行智能體已有數週，它徹底改變了我的開發模式。能夠同步處理多個問題而非依次解決，實實在在地提升了生產效率。

這項技術目前並不完美 —— 我們仍需花費時間審查與修正智能體生成的代碼。 但當我們能同時啓動十項任務，且其中大部分無需直接干預便能推進時，它便為我們騰出了寶貴的精力，讓我們能專注於那些真正需要人類判斷的問題。

如果你對嘗試這種方法感到好奇，建議從待辦清單中挑選小型的、定義明確的任務開始。編寫清晰的描述文檔然後觀察運行結果。最壞的情況不過花費幾分鐘審查未達到預期的代碼，而最好的情況則是你或許將找到契合自身風格的全新工作範式。

END

本期互動內容 🍻

❓文章提到，工程師的角色正從“編碼者”轉向“調度與審查者”。在你的工作中，是否已經感受到了這種變化？

文中鏈接

[1]https://twitter.com/karpathy/status/1886192184808149383?ref_s...

本文經原作者授權，由 Baihai IDP 編譯。如需轉載譯文，請聯繫獲取授權。

原文鏈接：

https://morningcoffee.io/parallel-ai-agents-are-a-game-change...