新智元報(bào)道

編輯：傾傾

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

程序員實(shí)測(cè)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

要是散落在不同倉(cāng)庫(kù)，就常常各寫各的，最后拼不起來。

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

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

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

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

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

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

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

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

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

參考資料：

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