其實在上一篇介紹 OpenCode 之后, 得到了很多朋友的關注和反饋, 而且這幾周過去我對于 Vibe Engineering 的實踐有了更多的體會, 今天再次總結一下。其實也能看出來我避免使用 Vibe Coding 這個詞，是因為當下的重點已經不再是代碼，而是一些更高維度的東西。另外，本文的 AI 含量我會盡量控制在 5% 內，可以放心閱讀。

順便匯報下，上一篇提到我開始的 TiDB Postgres 重寫項目已經不再在是個玩具。在前幾天出差的路上, 因為長途飛行沒有網絡, 我仔細 review 了一下這個項目的代碼, 雖然一些地方略有瑕疵, 但是總體質量已經很高, 我認為已經是接近生產水平的 rust 代碼，和以前我理解中的早期原型的定義很不一樣。順便提一句, 我認為這個項目從一開始就選擇 rust 是一個無比正確的決定, rust 的嚴謹性讓 AI 能寫出更接近 bug free 的 infra code (對比我另一個項目 agfs 的 shell 和它自帶的腳本語言 ascript，由于這項目使用 python，項目變大后，可維護性就大大降低，但此時重寫已經很困難，只能捏著鼻子慢慢重構)，所以現在已經是 2026 年了， 如果你要再啟動一個新的 backend infra 項目, rust 應該是你的第一選擇。

TiDB PostgreSQL Cloud

驗證差不多后，我也邀請了幾位我團隊內的幾個頂尖的 vibe coder 加入項目, 看看 100% 的 AI Native 研發(fā)模式能在多快把這個項目推進到何種程度，無論如何都很想看看，應該會很有意思。

下面說說自己最近的一些感受。

當前關于 Vibe Engineering 的所有的認知都會在 1 個月內嚴重過時

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

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

例如上面是 GPT-5.2 在長上下文的召回表現和 GPT-5.1 對比很明顯，要知道對于 Agent Coding 的場景來說，通常是多輪次推理 + 長上下文（因為要放更多的代碼和中間推理結果）才能更好的有大局觀，大局觀的正確是對于復雜項目起到決定性因素。在這種場景下，你可以做一個簡單的計算，一個模型（類似 GPT-5.1) 每輪的召回率 50%，大概 3 輪后，正確的召回率就會降低到 12.5%, 而 GPT-5.2 仍然能保持 70% 以上。

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

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

Hire the best (model), 否則就是在浪費生命

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

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

作為人來說，我們的直覺或者是一些簡單的 CRUD Demo 已經無法評估這些模型之間的智商差距了。但是在復雜的項目的開發(fā)中，這個差距是極端明顯的。

根據我個人的實踐來說，當下能用來進行大型 Infra 項目（數據庫，操作系統(tǒng)，編譯器等）開發(fā)的模型大概就兩個：GPT-5.2 (xhigh) + Opus 4.5，還有半個算是 Gemini 3 Pro。

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

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

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

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

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

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

人在什么時候進入? 扮演什么角色?

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

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

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

另外，我通常會在提出需求的第一階段就要求 Agent 做的一些關鍵動作。比如無論接下來做什么，都要把計劃和 todo 列表放在一個 work.md 或 todo.md 這類文件里。還有，每完成一個階段的工作，就把上一階段的經驗教訓更新到 agents.md 里。第三點是當一個計劃完成并且代碼合并后，把這個工作的設計文檔添加到項目的知識庫中（.codex/knowledge）。這些都是我會在一開始提需求時就放進去的內容。

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

實現階段沒什么特別好說的，反正我現在基本不會一行行去看 AI 的代碼。我覺得在實現階段唯一要注意的就是，要么你就讓 AI 完全去做，要么你就完全自己做，千萬別混著來，我目前是傾向于完全零人工干預的模式效果更好。

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

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

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

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

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

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

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

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

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

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

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

因為上面的種種，AI-Native 的研發(fā)組織其實很難自底向上從一個非 AI-Native 的組織中生長出來，因為大多數開發(fā)者面對變革的時候的第一反應其實并不是擁抱，而是回避和抵觸，但是時代的進步不會因為個人的意志轉移，只有主動擁抱和被動擁抱的區(qū)別。

大概就寫到這里吧，總的來說，在這樣一個大環(huán)境下，對個人而言意味著一場深刻的轉變，就像我上周在朋友圈里提到的，我身邊最好的工程師們有一些已經陷入了或多或少的存在主義危機。但是作為具體的 Builder 的我來說是興奮的，因為造物，在當下，門檻變低了許多，如果你能從造物中能獲得成就感和找到人生的意義，那恭喜你，你活在一個最好的時代。但反過來，作為一個抽象的 “人” 來說，我又是悲觀的，人類是否準備好面對這樣的工具？以及這樣工具帶來的對于社會和整個人類文明的沖擊？我不知道。