新智元報道

編輯：傾傾

【新智元導(dǎo)讀】寫代碼的規(guī)則，正在被悄悄改寫！不再是「人+AI一起盯屏幕」，而是一次性放出十幾個任務(wù)，讓代理們各自跑。真正的門檻，也不再是你能寫多少行代碼，而是你能不能寫清楚需求、明確地拆分任務(wù)、快速瀏覽結(jié)果。

在過去，寫代碼靠的是程序員盯著屏幕，一行行打字。

即便有Copilot，也只是多了個聰明的鍵盤，大部分內(nèi)容還是要人來做。

但當(dāng)并行代理出現(xiàn)后，一個程序員能同時調(diào)用十幾個AI，修bug、做測試通通不在話下。

程序員不再是「碼農(nóng)」，而是掌控全局的指揮官。

從補(bǔ)全到并行：AI進(jìn)化的快捷鍵

用AI寫代碼的第一步，是用Copilot的自動補(bǔ)全功能。

它能讓程序員少打幾行代碼，但本質(zhì)上還是「人寫一句，AI寫一句」。

后來出現(xiàn)了Cursor、Windsurf這樣的AI編輯器，它能理解整個代碼庫，幫助程序員重構(gòu)、檢查bug。

但它們更像是一個會聊天的搭檔，還是需要人來盯著它們運(yùn)行。

再后來，vibe coding出現(xiàn)了，只需要一句話：「寫一個帶Google、GitHub、Microsoft 登錄的注冊頁」，AI就能完整實(shí)現(xiàn)。

Andrej Karpathy把它形容為「順著感覺寫代碼」，工程師也是第一次感受到「描述即開發(fā)」。

但這些都還停留在「單線程思維」：人和AI一起寫，效率提高，卻始終受限于線性工作方式。

真正的轉(zhuǎn)折點(diǎn)，是并行代理——多個AI可以同時運(yùn)行。

以一當(dāng)十：工程師的全新戰(zhàn)場

并行代理讓工程師不再守著屏幕，而是一次性放出十幾個任務(wù)，讓AI自己各就各位。

在輸入指令之后，只需要等到結(jié)果返回，再逐個檢查、取舍。

這也意味著人的思維方式要徹底翻轉(zhuǎn)：從線性推進(jìn)到批量調(diào)度，從即時反饋到異步等待。

不需要糾結(jié)每一行代碼，而是提前把需求寫清，像排兵布陣一樣丟給不同的代理，幾十分鐘后再回來檢查成果。

那么，具體該如何使用呢？

首先，要確保每個GitHub問題都包含足夠的上下文，以便代理了解需要構(gòu)建的內(nèi)容。

其次，將問題分配給AI代理（如copilot），可以一次性分配多個問題，允許代理并行工作。

第三，在代理完成任務(wù)后，用戶查看生成的內(nèi)容，并對其發(fā)表反饋，代理將繼續(xù)完善方案。

最后，根據(jù)需要進(jìn)行審查、測試和反饋——無需等待一個代理完成，而是可以在不同代理之間切換。

程序員實(shí)測

當(dāng)然，結(jié)果并不總是完美。

一位程序員在編寫代碼時發(fā)現(xiàn)，只有10%的問題被完全解決：

有的任務(wù)一次到位，可以直接上線；有的只差臨門一腳，花幾分鐘修修就好；更多的則需要你跳進(jìn)來補(bǔ)全上下文，甚至干脆砍掉重來。

可即便如此，整體節(jié)奏依舊比過去快得多。

同時，也程序員也注意到，它在修 bug、寫后臺邏輯、數(shù)據(jù)庫遷移，這些小而明確的任務(wù)，跑得飛快；

但遇到需要實(shí)時視覺反饋的UI，或者要做復(fù)雜架構(gòu)決策，代理就顯得力不從心。

久而久之，寫代碼更像在下一盤棋：前期布好局，后期盯復(fù)盤。

寫代碼，不再是盯著一行行字母，而是統(tǒng)籌整個戰(zhàn)場。

寫得越清楚，代碼越準(zhǔn)確

在能絲滑使用代理寫代碼之前，我們要知道：并行代理擅長什么？

并行代理擅長小型、定義明確的任務(wù)，比如修復(fù)bug、轉(zhuǎn)換代碼。

而如UI開發(fā)等需要實(shí)時視覺反饋，或者需要復(fù)雜決策的大型任務(wù)，并行代理并不擅長。

這也給人們帶來了一個意外發(fā)現(xiàn)：工程師的核心價值，開始從「寫代碼」轉(zhuǎn)移到「寫清楚需求」。

代理并不會自己推理上下文，它只能依賴用戶在指令里留下的描述。

因此，問題分解成為了一項(xiàng)很關(guān)鍵的技能。

寫得含糊，它就給你產(chǎn)出含糊的結(jié)果；寫得具體，它就能把任務(wù)推進(jìn)得更遠(yuǎn)。

「代理的輸出質(zhì)量，完全取決于你在指令里寫得有多清晰、多詳細(xì)。指令越具體、越有結(jié)構(gòu)，結(jié)果就越準(zhǔn)確?！?/p>

這也意味著，問題拆解成了必備能力。

因?yàn)?，它無法處理大而籠統(tǒng)的需求；但如果能切分成小而明確的任務(wù)，它們就能各自獨(dú)立并行。

一些開發(fā)者說，AI 最好被用作解決編程問題的溝通方式，他們稱之為「橡皮鴨調(diào)試」（源自他們與桌上玩具交談的習(xí)慣）

與此同時，QA和Code Review變得前所未有的重要。

因?yàn)槠款i已經(jīng)不在產(chǎn)出代碼，而在「快速驗(yàn)證結(jié)果」。

「用并行代理時，關(guān)鍵在于優(yōu)化審閱速度。你可以同時開 50 個任務(wù)，但最終都要逐一審核、理解、驗(yàn)證。加快審閱周期（最好在10秒內(nèi)進(jìn)行檢出、重建和測試）對整個工作流程至關(guān)重要」

久而久之，編程慢慢向「描述」傾斜。

寫清楚需求、拆分好任務(wù)、快速做出判斷，遠(yuǎn)比自己多敲幾行代碼更有價值。

打好地基，重新定義工程師

并行代理要想真正落地，離不開一整套工程環(huán)境。

首先，CI/CD要足夠快。測試、構(gòu)建、部署一旦拖沓，再聰明的代理也沒用。

自動化和一鍵回歸，是把結(jié)果接到生產(chǎn)里的關(guān)鍵。

其次是文檔和架構(gòu)要清晰。

代理需要知道代碼放在哪、組件怎么交互、遵循哪些約定已經(jīng)不同系統(tǒng)如何集成。

有據(jù)可查的API、架構(gòu)決策、編碼標(biāo)準(zhǔn)和系統(tǒng)邊界可以幫助代理做出更好的決策，并且能減少手動更正的需要。

也就是說，寫得越規(guī)整，它就越少犯錯。

第三，測試環(huán)境也要穩(wěn)定。

因?yàn)榇硎钱惒焦ぷ鞯模@就需要一個一致的位置去承接產(chǎn)出，并且不會影響生產(chǎn)系統(tǒng)。

最后，還有monorepo架構(gòu)的優(yōu)勢。

在單一代碼庫里，代理能看見全局，前后端一起改，不容易出集成bug。

要是散落在不同倉庫，就常常各寫各的，最后拼不起來。

至于工具，現(xiàn)在也有不少選擇：

GitHub Agents：集成度最高，直接在issue上分配任務(wù)，產(chǎn)出PR，體驗(yàn)最成熟。

Cursor：正在內(nèi)測并行代理，延續(xù)vibe coding的特色，適合已有用戶。

OpenAI Codex CLI：支持在云端跑代理，解放本地環(huán)境，適合需要大規(guī)模并行的人。

說到底，并行代理能跑多遠(yuǎn)，不看概念有多炫酷，而看「地基」打得有多牢。

當(dāng)CI/CD、文檔、staging、monorepo這些地基都鋪好，代理就能真正跑起來。

那時會發(fā)現(xiàn)，會寫代碼這件事已經(jīng)不是核心競爭力了。

真正決定價值的，是能不能拆清任務(wù)、寫明需求、快速審核結(jié)果。

未來的工程師，不是「碼農(nóng)」，而是指揮官。

參考資料：

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