![]()
新智元報道
編輯:傾傾
【新智元導讀】寫代碼的規則,正在被悄悄改寫!不再是「人+AI一起盯屏幕」,而是一次性放出十幾個任務,讓代理們各自跑。真正的門檻,也不再是你能寫多少行代碼,而是你能不能寫清楚需求、明確地拆分任務、快速瀏覽結果。
在過去,寫代碼靠的是程序員盯著屏幕,一行行打字。
即便有Copilot,也只是多了個聰明的鍵盤,大部分內容還是要人來做。
但當并行代理出現后,一個程序員能同時調用十幾個AI,修bug、做測試通通不在話下。
程序員不再是「碼農」,而是掌控全局的指揮官。
從補全到并行:AI進化的快捷鍵
用AI寫代碼的第一步,是用Copilot的自動補全功能。
它能讓程序員少打幾行代碼,但本質上還是「人寫一句,AI寫一句」。
后來出現了Cursor、Windsurf這樣的AI編輯器,它能理解整個代碼庫,幫助程序員重構、檢查bug。
但它們更像是一個會聊天的搭檔,還是需要人來盯著它們運行。
再后來,vibe coding出現了,只需要一句話:「寫一個帶Google、GitHub、Microsoft 登錄的注冊頁」,AI就能完整實現。
Andrej Karpathy把它形容為「順著感覺寫代碼」,工程師也是第一次感受到「描述即開發」。
![]()
但這些都還停留在「單線程思維」:人和AI一起寫,效率提高,卻始終受限于線性工作方式。
真正的轉折點,是并行代理——多個AI可以同時運行。
以一當十:工程師的全新戰場
并行代理讓工程師不再守著屏幕,而是一次性放出十幾個任務,讓AI自己各就各位。
在輸入指令之后,只需要等到結果返回,再逐個檢查、取舍。
這也意味著人的思維方式要徹底翻轉:從線性推進到批量調度,從即時反饋到異步等待。
不需要糾結每一行代碼,而是提前把需求寫清,像排兵布陣一樣丟給不同的代理,幾十分鐘后再回來檢查成果。
![]()
那么,具體該如何使用呢?
首先,要確保每個GitHub問題都包含足夠的上下文,以便代理了解需要構建的內容。
其次,將問題分配給AI代理(如copilot),可以一次性分配多個問題,允許代理并行工作。
第三,在代理完成任務后,用戶查看生成的內容,并對其發表反饋,代理將繼續完善方案。
最后,根據需要進行審查、測試和反饋——無需等待一個代理完成,而是可以在不同代理之間切換。
![]()
程序員實測
當然,結果并不總是完美。
一位程序員在編寫代碼時發現,只有10%的問題被完全解決:
![]()
有的任務一次到位,可以直接上線;有的只差臨門一腳,花幾分鐘修修就好;更多的則需要你跳進來補全上下文,甚至干脆砍掉重來。
可即便如此,整體節奏依舊比過去快得多。
同時,也程序員也注意到,它在修 bug、寫后臺邏輯、數據庫遷移,這些小而明確的任務,跑得飛快;
但遇到需要實時視覺反饋的UI,或者要做復雜架構決策,代理就顯得力不從心。
久而久之,寫代碼更像在下一盤棋:前期布好局,后期盯復盤。
寫代碼,不再是盯著一行行字母,而是統籌整個戰場。
寫得越清楚,代碼越準確
在能絲滑使用代理寫代碼之前,我們要知道:并行代理擅長什么?
并行代理擅長小型、定義明確的任務,比如修復bug、轉換代碼。
而如UI開發等需要實時視覺反饋,或者需要復雜決策的大型任務,并行代理并不擅長。
這也給人們帶來了一個意外發現:工程師的核心價值,開始從「寫代碼」轉移到「寫清楚需求」。
代理并不會自己推理上下文,它只能依賴用戶在指令里留下的描述。
因此,問題分解成為了一項很關鍵的技能。
寫得含糊,它就給你產出含糊的結果;寫得具體,它就能把任務推進得更遠。
「代理的輸出質量,完全取決于你在指令里寫得有多清晰、多詳細。指令越具體、越有結構,結果就越準確。」
這也意味著,問題拆解成了必備能力。
因為,它無法處理大而籠統的需求;但如果能切分成小而明確的任務,它們就能各自獨立并行。
![]()
一些開發者說,AI 最好被用作解決編程問題的溝通方式,他們稱之為「橡皮鴨調試」(源自他們與桌上玩具交談的習慣)
與此同時,QA和Code Review變得前所未有的重要。
因為瓶頸已經不在產出代碼,而在「快速驗證結果」。
「用并行代理時,關鍵在于優化審閱速度。你可以同時開 50 個任務,但最終都要逐一審核、理解、驗證。加快審閱周期(最好在10秒內進行檢出、重建和測試)對整個工作流程至關重要」
久而久之,編程慢慢向「描述」傾斜。
寫清楚需求、拆分好任務、快速做出判斷,遠比自己多敲幾行代碼更有價值。
打好地基,重新定義工程師
并行代理要想真正落地,離不開一整套工程環境。
首先,CI/CD要足夠快。測試、構建、部署一旦拖沓,再聰明的代理也沒用。
自動化和一鍵回歸,是把結果接到生產里的關鍵。
其次是文檔和架構要清晰。
代理需要知道代碼放在哪、組件怎么交互、遵循哪些約定已經不同系統如何集成。
有據可查的API、架構決策、編碼標準和系統邊界可以幫助代理做出更好的決策,并且能減少手動更正的需要。
也就是說,寫得越規整,它就越少犯錯。
第三,測試環境也要穩定。
因為代理是異步工作的,這就需要一個一致的位置去承接產出,并且不會影響生產系統。
最后,還有monorepo架構的優勢。
在單一代碼庫里,代理能看見全局,前后端一起改,不容易出集成bug。
要是散落在不同倉庫,就常常各寫各的,最后拼不起來。
至于工具,現在也有不少選擇:
GitHub Agents:集成度最高,直接在issue上分配任務,產出PR,體驗最成熟。
Cursor:正在內測并行代理,延續vibe coding的特色,適合已有用戶。
OpenAI Codex CLI:支持在云端跑代理,解放本地環境,適合需要大規模并行的人。
說到底,并行代理能跑多遠,不看概念有多炫酷,而看「地基」打得有多牢。
當CI/CD、文檔、staging、monorepo這些地基都鋪好,代理就能真正跑起來。
那時會發現,會寫代碼這件事已經不是核心競爭力了。
真正決定價值的,是能不能拆清任務、寫明需求、快速審核結果。
未來的工程師,不是「碼農」,而是指揮官。
參考資料:
https://morningcoffee.io/parallel-ai-agents-are-a-game-changer.html
![]()
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.