轉載自：https://mp.weixin.qq.com/s/8kY6grrMrunTzmz1Oq5MSg（標題：Vibe Engineering in 2026.1）
作者：PingCAP 聯合創始人兼 CTO 黃東旭

其實在上一篇介紹 OpenCode 之後（重度使用 opencode 後引發的一些關於 agent 的感想）, 得到了很多朋友的關注和反饋, 而且這幾周過去我對於 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 研發模式能在多快把這個項目推進到何種程度，無論如何都很想看看，應該會很有意思。

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

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

並非危言聳聽，哪怕我正在寫的這篇文章，如果你是 2026 年 2 月看到，那麼很遺憾，本文聊到的東西很可能已經過時，這個領域發展的太快，很多今天的 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 也在深度的開發這些工具，迭代速度只會更快。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

多 Agent 協同編程的一些實踐

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

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

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

未來的軟件公司和組織形態

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

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

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

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

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

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

對了，這周 PingCAP 將舉行新品分享會，創始人全體出席：2026 平凱數據庫新品分享會，TiDB 創始人齊聚。