當(dāng)前關(guān)于 Vibe Engineering 的所有認(rèn)知都會(huì)在 1 個(gè)月內(nèi)嚴(yán)重過(guò)時(shí)

作者 | 黃東旭

過(guò)去幾周，我對(duì)于 Vibe Engineering 的實(shí)踐有了更多的體會(huì), 今天再次總結(jié)一下。其實(shí)也能看出來(lái)我避免使用 Vibe Coding 這個(gè)詞，是因?yàn)楫?dāng)下的重點(diǎn)已經(jīng)不再是代碼，而是一些更高維度的東西。另外，本文的 AI 含量我會(huì)盡量控制在 5% 內(nèi)，可以放心閱讀。

之前我提到的我開始的 TiDB Postgres 重寫項(xiàng)目已經(jīng)不再在是個(gè)玩具。在前幾天出差的路上, 因?yàn)殚L(zhǎng)途飛行沒(méi)有網(wǎng)絡(luò), 我仔細(xì) review 了一下這個(gè)項(xiàng)目的代碼, 雖然一些地方略有瑕疵, 但是總體質(zhì)量已經(jīng)很高, 我認(rèn)為已經(jīng)是接近生產(chǎn)水平的 rust 代碼，和以前我理解中的早期原型的定義很不一樣。

順便提一句, 我認(rèn)為這個(gè)項(xiàng)目從一開始就選擇 rust 是一個(gè)無(wú)比正確的決定, rust 的嚴(yán)謹(jǐn)性讓 AI 能寫出更接近 bug free 的 infra code (對(duì)比我另一個(gè)項(xiàng)目 agfs 的 shell 和它自帶的腳本語(yǔ)言 ascript，由于這項(xiàng)目使用 python，項(xiàng)目變大后，可維護(hù)性就大大降低，但此時(shí)重寫已經(jīng)很困難，只能捏著鼻子慢慢重構(gòu))，所以現(xiàn)在已經(jīng)是 2026 年了， 如果你要再啟動(dòng)一個(gè)新的 backend infra 項(xiàng)目, rust 應(yīng)該是你的第一選擇。

TiDB PostgreSQL Cloud

驗(yàn)證差不多后，我也邀請(qǐng)了幾位我團(tuán)隊(duì)內(nèi)的幾個(gè)頂尖的 vibe coder 加入項(xiàng)目, 看看 100% 的 AI Native 研發(fā)模式能在多快把這個(gè)項(xiàng)目推進(jìn)到何種程度，無(wú)論如何都很想看看，應(yīng)該會(huì)很有意思。

下面說(shuō)說(shuō)自己最近的一些感受。

1 當(dāng)前關(guān)于 Vibe Engineering 的所有的認(rèn)知都會(huì)在 1 個(gè)月內(nèi)嚴(yán)重過(guò)時(shí)

并非危言聳聽，哪怕我正在寫的這篇文章，如果你是 2026 年 2 月看到，那么很遺憾，本文聊到的東西很可能已經(jīng)過(guò)時(shí)，這個(gè)領(lǐng)域發(fā)展的太快，很多今天的 SOTA 也許下個(gè)月就過(guò)時(shí)了。而且很有意思，過(guò)去很多對(duì) Vibe Coding 嗤之以鼻的大佬，例如 DHH，Linus，Antirez 等，在 2025.12 月開始紛紛改口，我覺得這是相當(dāng)正常的，去年 12 月開始，AI 編程工具和頭部的模型突然有一個(gè)跳躍式的進(jìn)步，突然對(duì)于復(fù)雜任務(wù)和大型項(xiàng)目的理解，以及寫出代碼的正確率有了極大的提升。這進(jìn)步大概來(lái)自于兩個(gè)方面：

一方面頭部模型在長(zhǎng)上下文（>256K) 的支持，尤其是關(guān)鍵信息的召回率提升驚人

例如上面是 GPT-5.2 在長(zhǎng)上下文的召回表現(xiàn)和 GPT-5.1 對(duì)比很明顯，要知道對(duì)于 Agent Coding 的場(chǎng)景來(lái)說(shuō)，通常是多輪次推理 + 長(zhǎng)上下文（因?yàn)橐鸥嗟拇a和中間推理結(jié)果）才能更好的有大局觀，大局觀的正確是對(duì)于復(fù)雜項(xiàng)目起到?jīng)Q定性因素。在這種場(chǎng)景下，你可以做一個(gè)簡(jiǎn)單的計(jì)算，一個(gè)模型（類似 GPT-5.1) 每輪的召回率 50%，大概 3 輪后，正確的召回率就會(huì)降低到 12.5%, 而 GPT-5.2 仍然能保持 70% 以上。

另外一個(gè)進(jìn)步是主流的 Vibe Coding 工具的 Context Engineer 實(shí)踐日益成熟，例如 Claude Code / Codex / OpenCode。從用戶體驗(yàn)到最佳實(shí)踐，肉眼可見的越來(lái)越好，例如對(duì)于 Bash 的使用，Subagent 等，這方面越來(lái)越多的資深 Engineer 的重度使用和經(jīng)驗(yàn)分享會(huì)對(duì)這些工具的進(jìn)化提供數(shù)據(jù)飛輪，尤其是 AI 也在深度的開發(fā)這些工具，迭代速度只會(huì)更快。

其實(shí)這個(gè)進(jìn)步也并不是去年 12 月那個(gè)時(shí)間點(diǎn)的突然什么黑科技爆發(fā)，其實(shí)前幾個(gè)月一直在進(jìn)步，不過(guò)還不能長(zhǎng)時(shí)間離開人工干預(yù)，更像是那個(gè)時(shí)間點(diǎn)，主流 Coding Agent 的質(zhì)量超過(guò)了一個(gè)臨界點(diǎn)：100% 的無(wú)人工干預(yù)下完成長(zhǎng)時(shí)間的 Agentic Loop 成為可能。

2 Hire the best (model)，否則就是在浪費(fèi)生命

上面所有提到的進(jìn)步，我個(gè)人感覺只反映在了最頂尖的閉源頭部模型中。我聽到很多朋友和我反饋到：“我感覺 AI 編程還是很傻啊？并沒(méi)有你提到那么聰明”，我首先會(huì)反問(wèn)，你是不是只是用著 $20 一個(gè)月那種入門模型？如果是的話，那先去用一陣 $200 以上的 Pro Max 檔次的，也許有驚喜。

我個(gè)人認(rèn)為，目前主流的模型，即使并非頭部那檔，作為 chatbot 處理大多數(shù)普通人的短上下文的日常工作是完全足夠的，哪怕是 GPT-4 在和你講人生道理的時(shí)候也已經(jīng)足夠把你說(shuō)得一愣一愣了。

作為人來(lái)說(shuō)，我們的直覺或者是一些簡(jiǎn)單的 CRUD Demo 已經(jīng)無(wú)法評(píng)估這些模型之間的智商差距了。但是在復(fù)雜的項(xiàng)目的開發(fā)中，這個(gè)差距是極端明顯的。

根據(jù)我個(gè)人的實(shí)踐來(lái)說(shuō)，當(dāng)下能用來(lái)進(jìn)行大型 Infra 項(xiàng)目（數(shù)據(jù)庫(kù)，操作系統(tǒng)，編譯器等）開發(fā)的模型大概就兩個(gè)：GPT-5.2 (xhigh) + Opus 4.5，還有半個(gè)算是 Gemini 3 Pro。

大概上個(gè)月我主要用著 opencode + oh-my-opencode + Opus 4.5 但是最近兩周轉(zhuǎn)向到了 codex + gpt-5.2 的組合，下面分析一下這幾個(gè)模型的一些脾氣和調(diào)性，僅僅是個(gè)人感受，而且是在后端 Infra 軟件開發(fā)這個(gè)領(lǐng)域，僅供參考。

Opus 4.5 的風(fēng)格是速度很快，是個(gè)話嘮，由于 Sonnet 4 有嚴(yán)重 reward hacking 問(wèn)題，例如是在解決不了 bug 的時(shí)候會(huì)偷偷的構(gòu)造作弊的測(cè)試然后糊弄過(guò)去，所以導(dǎo)致很長(zhǎng)一段時(shí)間我都不太敢用 Sonnet 系列模型干復(fù)雜的事情，但是這點(diǎn)在 Opus 4.5 中解決得很好，即使在模型冥思苦各種嘗試想都搞不定的情況下也沒(méi)有選擇作弊，讓我放心不少，但是 Opus 的問(wèn)題是 reasoning 和做 investigation 的時(shí)間太少，動(dòng)手太快，以至于發(fā)現(xiàn)不對(duì)的時(shí)候，又返回頭確認(rèn)假設(shè)和研究，這樣的特性催生了像 ralph-loop 這樣的奇技淫巧。比方說(shuō)，同樣的一個(gè) prompt 在 Claude Code 結(jié)束后又通過(guò) stop hook 重新調(diào)用，再完整走一遍流程，不斷地逼近最終的結(jié)果。

相比之下，GPT-5.2 更像是一個(gè)更加小心謹(jǐn)慎、話不多的角色。我最開始用 Codex 的體驗(yàn)其實(shí)不算太好，因?yàn)槲乙恢庇X得它有點(diǎn)太慢了。主要是因?yàn)槲伊?xí)慣用它的 xhigh 深度思考模式，在真正開始寫代碼之前，它會(huì)花很長(zhǎng)時(shí)間去瀏覽項(xiàng)目里的各種文件和文檔，做很多準(zhǔn)備工作。可能也是因?yàn)?Codex 的客戶端不會(huì)告訴你它的計(jì)劃和大概需要多久，所以就顯得過(guò)程特別長(zhǎng)。有時(shí)候一些復(fù)雜的任務(wù)，它前期的調(diào)查可能就要花上一到兩個(gè)小時(shí)。但是經(jīng)過(guò)長(zhǎng)時(shí)間思考后它完成的效果通常是更好的，尤其是在一個(gè)項(xiàng)目的大體框架已經(jīng)穩(wěn)定，Codex 考慮得更周全，最終也體現(xiàn)出更少的 bug 和更好的穩(wěn)定性。

對(duì)于第三個(gè)頂級(jí)模型，也就是 Gemini 3 Pro。雖然我也知道它的多模態(tài)能力非常吸引人，但就復(fù)雜任務(wù)的 Coding 場(chǎng)景而言，至少?gòu)奈覀€(gè)人的體驗(yàn)來(lái)看，它的表現(xiàn)并沒(méi)有 Opus 4.5 和 GPT-5.2 那么強(qiáng)。不過(guò)它確實(shí)針對(duì)一些快速的前端項(xiàng)目 Demo 和原型制作做了一些優(yōu)化，再加上它的 Playground 模式，讓你在需要一些炫酷的小 Demo 或前端項(xiàng)目時(shí)能更快實(shí)現(xiàn)。

其實(shí)一個(gè)比較反直覺的事情是，過(guò)去我們經(jīng)常說(shuō) Vibe Coding 只能搞一些比較簡(jiǎn)單的事情，比如上面那些小 Demo 或 CRUD 項(xiàng)目，你會(huì)看到網(wǎng)上各種各樣的 KOL 其實(shí)都在做這種小原型，反而大家覺得對(duì)于一些像后端這種核心的基礎(chǔ)設(shè)施代碼，當(dāng)前 AI 還是搞不定的。我以前也這么想，但從去年 12 月份開始，這個(gè)結(jié)論可能需要修正了。這里面的原因是，其實(shí)這類基礎(chǔ)設(shè)施的代碼通常是由頂級(jí)工程師長(zhǎng)期精雕細(xì)琢而成，它們有清晰的抽象、良好的測(cè)試，甚至代碼本身經(jīng)過(guò)多輪重構(gòu)后也相當(dāng)精煉。所以當(dāng) AI 具備足夠的上下文空間 + 更好的推理能力 + 更成熟的 Agentic Loop + 高效的工具調(diào)用時(shí)，這類 Infra 代碼的開發(fā)和維護(hù)反而是能最有效地利用這些頂尖大模型的智商的場(chǎng)景。

在實(shí)際的工作中，我經(jīng)常會(huì)讓多個(gè) Agent 互相協(xié)作，或者使用一些復(fù)雜的工作流來(lái)把它們編排在一起，并不會(huì)讓一個(gè)模型來(lái)完成所有的事情。后面我會(huì)再分享一些我自己實(shí)踐中的具體例子。

3 人在什么時(shí)候進(jìn)入？扮演什么角色？

上面提到了，這些頂級(jí)模型再配合主流的 Vibe Coding 工具，基本上已經(jīng)能超越大多數(shù)資深工程師的水平了。這不僅體現(xiàn)在能寫出更少 bug 的代碼，也體現(xiàn)在在 review 中能發(fā)現(xiàn)更多人類工程師可能看不到的問(wèn)題，畢竟 AI 真的會(huì)一行一行仔細(xì)看。

所以人在這個(gè)過(guò)程中扮演什么樣的角色，哪些階段只有人才能做？根據(jù)我自己的實(shí)踐來(lái)說(shuō)，第一當(dāng)然是提出需求，畢竟只有你才知道你想要啥，這很顯然，但是有時(shí)確實(shí)也挺難的，畢竟人很難從一開始就準(zhǔn)確描述自己想要什么，這時(shí)候我會(huì)用一個(gè)偷懶的辦法：讓 AI 來(lái)角色扮演，比方說(shuō)，我在開發(fā) PostgreSQL 版本的 TiDB 時(shí)，我就讓 AI 假設(shè)自己是一個(gè)資深的 Postgres 用戶，從開發(fā)者的視角告訴我有哪些特性是非常重要、一定要實(shí)現(xiàn)而且 ROI 比較高的，讓它列出 N 個(gè)這樣的功能點(diǎn)，然后 AI 就會(huì)根據(jù)它的理解生成一個(gè)需求列表，接下來(lái)你再和 AI 對(duì)這些需求逐個(gè)打磨，這其實(shí)是一個(gè)高效冷啟動(dòng)的方法。

第二是在需求提出后，現(xiàn)在的 Coding Agent 大多都會(huì)和你有一個(gè)規(guī)劃階段（Planning），會(huì)反復(fù)確認(rèn)你的需求。在這個(gè)過(guò)程中其實(shí)有一些技巧，比如不要給 AI 太具體的方案，而是讓 AI 來(lái)生成方案，你只需要關(guān)注最終你想要的結(jié)果；提前告訴 AI 有哪些基礎(chǔ)設(shè)施和環(huán)境的問(wèn)題，讓它少走彎路。

另外，我通常會(huì)在提出需求的第一階段就要求 Agent 做的一些關(guān)鍵動(dòng)作。比如無(wú)論接下來(lái)做什么，都要把計(jì)劃和 todo 列表放在一個(gè) work.md 或 todo.md 這類文件里。還有，每完成一個(gè)階段的工作，就把上一階段的經(jīng)驗(yàn)教訓(xùn)更新到 agents.md 里。第三點(diǎn)是當(dāng)一個(gè)計(jì)劃完成并且代碼合并后，把這個(gè)工作的設(shè)計(jì)文檔添加到項(xiàng)目的知識(shí)庫(kù)中（.codex/knowledge）。這些都是我會(huì)在一開始提需求時(shí)就放進(jìn)去的內(nèi)容。

第二個(gè)階段就是漫長(zhǎng)的調(diào)查、研究和分析的階段。這個(gè)階段其實(shí)基本上不需要人做什么事情，而且 Agent 的效率比人高得多，你只需要等著就好。唯一需要注意的就是在 Research 的過(guò)程中，我通常會(huì)告訴模型它擁有無(wú)限的預(yù)算和時(shí)間，盡可能充分地進(jìn)行調(diào)研。另外，如果你的模型有推理深度的參數(shù)的話，我建議在這個(gè)階段把它們?nèi)空{(diào)到 xhigh 的級(jí)別。雖然這會(huì)讓過(guò)程變慢，但在這個(gè)階段多燒一些 token、做好更好的規(guī)劃、了解更多上下文，對(duì)后續(xù)的實(shí)現(xiàn)階段會(huì)更有幫助。

實(shí)現(xiàn)階段沒(méi)什么特別好說(shuō)的，反正我現(xiàn)在基本不會(huì)一行行去看 AI 的代碼。我覺得在實(shí)現(xiàn)階段唯一要注意的就是，要么你就讓 AI 完全去做，要么你就完全自己做，千萬(wàn)別混著來(lái)，我目前是傾向于完全零人工干預(yù)的模式效果更好。

第四個(gè)階段人就變得非常重要了，那就是測(cè)試和驗(yàn)收結(jié)果的階段。其實(shí)在我個(gè)人和 AI 開發(fā)項(xiàng)目的過(guò)程中，我 90% 的時(shí)間和精力都花在了這個(gè)階段：也就是如何評(píng)估 AI 的工作成果，我覺得在 Vibe Coding 時(shí)：There's a test, there's a feature，你只要知道如何評(píng)估和測(cè)試你要的東西，AI 就一定能把東西給你做出來(lái)。另外值得注意的是，AI 在實(shí)現(xiàn)過(guò)程中會(huì)自動(dòng)幫你添加很多單元測(cè)試，但說(shuō)實(shí)話，這些單元測(cè)試在微觀層面基本都能通過(guò)，畢竟 AI 寫這種局部代碼時(shí)已經(jīng)很難出 bug。但 AI 不擅長(zhǎng)的是集成測(cè)試、端到端測(cè)試。比如在開發(fā)一個(gè) SQL 數(shù)據(jù)庫(kù)時(shí)，哪怕每個(gè)細(xì)節(jié)的單元測(cè)試都沒(méi)問(wèn)題，但整合到一起時(shí)集成測(cè)試可能會(huì)出錯(cuò)。所以我在完成大目標(biāo)前，我一定會(huì)先和 AI 一起做一個(gè)方便的集成測(cè)試框架，并提前準(zhǔn)備好測(cè)試的基礎(chǔ)設(shè)施，收集和生成一些現(xiàn)成集成測(cè)試的用例，盡量一鍵能運(yùn)行那種，這樣在開發(fā)階段就能事半功倍，而且關(guān)于如何使用這些測(cè)試的基礎(chǔ)設(shè)施的信息，我都會(huì)在正式開始前就固化在 agents.md 里，這樣就不用每次溝通的時(shí)候都再告訴它該怎么測(cè)試了。關(guān)于測(cè)試從哪來(lái)的問(wèn)題，我自己的經(jīng)驗(yàn)是你可以讓 AI 幫你生成，但一定要告訴它一些生成的邏輯，標(biāo)準(zhǔn)和目的，另外就是千萬(wàn)不要把生成測(cè)試的 Context 和實(shí)際進(jìn)行開發(fā)工作的 Agent 的 Context 混在一起。

第五個(gè)階段是重構(gòu)和拆分。我發(fā)現(xiàn)當(dāng)前的 Coding Agent 在面對(duì)單一模塊復(fù)雜度超過(guò)大約 5 萬(wàn)行代碼之后，就開始很難在 1-shot 里把問(wèn)題一次性解決掉（但反過(guò)來(lái)這也意味著，只要任務(wù)復(fù)雜度控制在這個(gè)閾值之下，在一個(gè)足夠好的 first prompt 驅(qū)動(dòng)下，很多事情確實(shí)可以做到 1-shot AC），Agent 通常不會(huì)主動(dòng)去做項(xiàng)目結(jié)構(gòu)和模塊邊界的治理，你要它把功能做出來(lái)，它恨不得把所有東西都寫進(jìn)幾個(gè)幾萬(wàn)行的大文件里，短期看似很快，長(zhǎng)期就是債務(wù)爆炸。我自己在這個(gè)階段的做法通常是先停下來(lái)，用自己的經(jīng)驗(yàn)進(jìn)行模塊拆分，然后在新的架構(gòu)下進(jìn)行 1～2 輪的重構(gòu)，之后又可以高并發(fā)度的進(jìn)行開發(fā)了。

4 多 Agent 協(xié)同編程的一些實(shí)踐

前面提到我現(xiàn)在使用 Coding Agent 的時(shí)候，通常不會(huì)只用一個(gè)，我自己的工作流會(huì)盡量讓多個(gè) Coding Agent 同時(shí)工作。這也是為什么有時(shí)候在一些項(xiàng)目上會(huì)花掉好幾千美金，因?yàn)槟惚仨毎巡l(fā)跑起來(lái)。當(dāng)然，并發(fā)和吞吐是一方面，但另一方面我覺得讓不同的 Agent 在不共享上下文的前提下互相 Review 工作，其實(shí)能顯著提高質(zhì)量。這就像在管理研發(fā)團(tuán)隊(duì)時(shí)，你不會(huì)讓同一個(gè)人既當(dāng)運(yùn)動(dòng)員又當(dāng)裁判。相當(dāng)于 Agent A 寫的代碼交給 Agent B 來(lái) Review，往往能發(fā)現(xiàn)一些 A 看不到的問(wèn)題。通過(guò)這樣的循環(huán)往復(fù)，你就會(huì)更有信心。

例如，我在實(shí)際工作中現(xiàn)在用得比較好的一個(gè)工作流是這樣的：首先讓 GPT-5.2 在 Codex 下生成多個(gè)功能的設(shè)計(jì)文檔，做出詳細(xì)的設(shè)計(jì)和規(guī)劃，第一階段把這些規(guī)劃文檔都保存下來(lái)。然后在第二階段，依然用 Codex 根據(jù)這些需求文檔一個(gè)一個(gè)去實(shí)現(xiàn)功能。在實(shí)現(xiàn)的過(guò)程中，就像我前面提到的那樣，記錄 To-Do、經(jīng)驗(yàn)教訓(xùn)，并在接近完成的時(shí)候，在代碼通過(guò)測(cè)試并準(zhǔn)備提交之前停下，把當(dāng)前的工作區(qū)交給另一個(gè) ClaudeCode 或 OpenCode，在不提供上下文的情況下，讓 ClaudeCode 來(lái) Review 當(dāng)前還未提交的代碼，根據(jù)設(shè)計(jì)提出修改建議。然后再把這些建議發(fā)回給 Codex，讓 Codex 來(lái)評(píng)論這些建議，如果有道理就修改代碼。改完之后，再讓 ClaudeCode (Opus 4.5) 那邊再次 Review，直到雙方都覺得代碼已經(jīng)寫得很不錯(cuò)了，再提交到 Git 上，標(biāo)記這個(gè)任務(wù)完成，更新知識(shí)庫(kù)，然后進(jìn)入下一個(gè)功能的開發(fā)。

另外在一個(gè)大型項(xiàng)目中我會(huì)同時(shí)開多個(gè) Agent (in different Tmux) 并行開發(fā)多個(gè)功能，但我盡量讓它們負(fù)責(zé)完全不同的模塊。比如一個(gè) Agent 修改內(nèi)核代碼，另一個(gè) Agent 做前端界面，這樣就能分開進(jìn)行，如果你需要在一份代碼上做一些彼此不太相關(guān)的工作時(shí)，可以利用 git 的 worktree 讓多個(gè) Agent 在不同的 git 分支上各自工作，這樣也能快速提升吞吐量。

5 未來(lái)的軟件公司和組織形態(tài)

未來(lái)的軟件公司會(huì)是什么形態(tài)呢？反正從我自己的實(shí)踐和與一些朋友的交流來(lái)看，至少在當(dāng)下，團(tuán)隊(duì)中用 Coding Agent 的 token 的消耗呈現(xiàn)出一個(gè)非常符合二八定律的分布，也就是說(shuō)，最頭部的用 AI 用得最好的工程師，他們消耗的 token 可能比剩下 80% 的工程師加起來(lái)還要多，而且 Coding Agent 對(duì)于不同工程師產(chǎn)出（質(zhì)量，吞吐）的增益是不一樣的，這個(gè)方差非常大，也就是對(duì)于用的最好的一群人，他們的增幅可能是 10x，但是普通人可能也就是 10%，而且唯一的瓶頸是人工的 code review 和一些無(wú)法被自動(dòng)化的線上運(yùn)維工作（我覺得也很快了）而且這樣的特點(diǎn)能夠讓這些頭部的工程師在 AI 的協(xié)助下可以無(wú)邊界的工作，也就是會(huì)有越來(lái)越多的 one-man army 出現(xiàn)，只是目前我認(rèn)為和 token 消耗是正相關(guān)的，你能花掉多少 token，大致代表你能做的多好。

另外我發(fā)現(xiàn)一個(gè)很有趣的現(xiàn)象，同樣是 10x 的工程師，他們各自的 Vibe Coding 工作流和最佳實(shí)踐其實(shí)并不相同。也就意味著，兩個(gè)頂尖的 Vibe Coder 是很難在一個(gè)項(xiàng)目中（的同一個(gè)模塊）協(xié)作。這種工作方式更像是頭狼帶著一群狼群（Agents），在一片自己的領(lǐng)地里面耕耘，但是同一片領(lǐng)地里很難容納兩匹頭狼，會(huì)造成 1+1 < 2。

在這樣的組織形態(tài)下，我覺得傳統(tǒng)意義上的“團(tuán)隊(duì)協(xié)作方式”會(huì)被重新定義。過(guò)去我們強(qiáng)調(diào)的是多人在同一個(gè)代碼庫(kù)、同一個(gè)模塊里高頻協(xié)作，通過(guò)評(píng)審、討論、同步來(lái)達(dá)成共識(shí)；但在 Vibe Engineering 這種模式下，更有效的方式反而可能是強(qiáng)解耦的并行。管理者要做的是把問(wèn)題切分成足夠清晰、邊界明確的“領(lǐng)地”，讓每一個(gè)頭部工程師帶著自己的 Agent 群，在各自的領(lǐng)域里做到極致。

從管理的角度看，這其實(shí)是一個(gè)挺大的挑戰(zhàn)。因?yàn)槟悴荒茉儆媒y(tǒng)一流程、統(tǒng)一節(jié)奏去約束所有人。對(duì)頂尖的 Vibe Coder 來(lái)說(shuō)，過(guò)多的流程和同步反而會(huì)顯著拉低效率，甚至抵消 AI 帶來(lái)的增益。管理者更像是在做“資源調(diào)度”和“沖突隔離”：確保不同頭狼之間盡量少互相干擾，同時(shí)在必要的時(shí)候，能夠通過(guò)清晰的接口、契約和測(cè)試來(lái)完成協(xié)作。

因?yàn)樯厦娴姆N種，AI-Native 的研發(fā)組織其實(shí)很難自底向上從一個(gè)非 AI-Native 的組織中生長(zhǎng)出來(lái)，因?yàn)榇蠖鄶?shù)開發(fā)者面對(duì)變革的時(shí)候的第一反應(yīng)其實(shí)并不是擁抱，而是回避和抵觸，但是時(shí)代的進(jìn)步不會(huì)因?yàn)閭€(gè)人的意志轉(zhuǎn)移，只有主動(dòng)擁抱和被動(dòng)擁抱的區(qū)別。

大概就寫到這里吧，總的來(lái)說(shuō)，在這樣一個(gè)大環(huán)境下，對(duì)個(gè)人而言意味著一場(chǎng)深刻的轉(zhuǎn)變，就像我之前在朋友圈里提到的，我身邊最好的工程師們有一些已經(jīng)陷入了或多或少的存在主義危機(jī)。

但是作為具體的 Builder 的我來(lái)說(shuō)是興奮的，因?yàn)樵煳铮诋?dāng)下，門檻變低了許多，如果你能從造物中能獲得成就感和找到人生的意義，那恭喜你，你活在一個(gè)最好的時(shí)代。但反過(guò)來(lái)，作為一個(gè)抽象的 “人” 來(lái)說(shuō)，我又是悲觀的，人類是否準(zhǔn)備好面對(duì)這樣的工具？以及這樣工具帶來(lái)的對(duì)于社會(huì)和整個(gè)人類文明的沖擊？

我不知道。

會(huì)議推薦

InfoQ 2026 全年會(huì)議規(guī)劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產(chǎn)業(yè)落地，從技術(shù)前沿到行業(yè)應(yīng)用，全面覆蓋 AI 與軟件開發(fā)核心賽道！集結(jié)全球技術(shù)先鋒，拆解真實(shí)生產(chǎn)案例、深挖技術(shù)與產(chǎn)業(yè)落地痛點(diǎn)，探索前沿領(lǐng)域、聚焦產(chǎn)業(yè)賦能，獲取實(shí)戰(zhàn)落地方案與前瞻產(chǎn)業(yè)洞察，高效實(shí)現(xiàn)技術(shù)價(jià)值轉(zhuǎn)化。把握行業(yè)變革關(guān)鍵節(jié)點(diǎn)，搶占 2026 智能升級(jí)發(fā)展先機(jī)！