最近一周沒怎么寫文章，因為忙著用 OpenAI 剛發(fā)布的 Codex 3 xHigh 糊東西。趁著雙倍額度，我把 200 刀的配額幾乎用完了，讓它在 Pigsty 的十幾個子項目上并行出活——主項目、中英文文檔、博客、包管理器、擴展目錄、基礎設施包、RPM/DEB 構建 Spec、pg_exporter 監(jiān)控采集器……

目前 Codex 已經(jīng)成了我的主力工具，Claude Code 作為備用，GLM 作為額度打爆之后的替補。正好今天有點時間，聊聊感想。直接口述，我就不用 AI 生成潤色了，比較隨意。

Codex 5.3：到底能不能打？

兩個字：能打。之前我不喜歡用 Codex 的一個主要原因就是太磨嘰——做一個簡單的活也要拖很長時間。到了 5.3 版本，不知道是用了 Cerebras 大緩存 SRAM 推理芯片，還是別的技術改進，體感上快了不少。而且這個客戶端做的挺不錯，我同時開 8 - 10 個左右的 Session，配合 ，體驗非常好，就像指揮官一樣。

但速度只是體驗層面的改善，真正讓我刮目相看的是靠譜程度。在合理的指揮和提示下，它已經(jīng)能扮演一個稱職的中級程序員了。具體來說以 Code Review 為例，找 Bug 大概 20 個里面只有一個需要我來人工糾正—— 粗略估計整體準確率在 95% 左右。

不過關于模型能力，老馮從來都不看什么榜單，只相信它們在自己場景上的真實效果。我有一個簡單粗暴的評估方法：交叉掃描。

，我曾經(jīng)用 Claude Code 對代碼倉庫進行了連續(xù)兩三周的密集掃描——逐日掃描、逐個修復、標記誤報，直到它再也掃不出新問題。然后 Opus 4.5 和 Codex 5.3 同時發(fā)布，我讓兩個模型再次掃描同一個倉庫：

結果 Codex 5.3 xHigh 又給我揪出了二三十個問題。而 Claude Opus 4.6：表現(xiàn)平平，沒能發(fā)現(xiàn)更多問題，這就是一種很直觀的模型能力對比。

不過 Claude 也有自己的長處，Claude 的優(yōu)勢在于寫碼速度快、溝通風格直接不諂媚；但在 “代碼質(zhì)量” 這件事上，特別是 Code Review —— Codex 5.3 xHigh 有明顯優(yōu)勢。

我用 Codex / Claude 做什么？

現(xiàn)在有很不少同行以每天燒了多少 Token 為榮，有一種攀比的風氣，老馮是懶得玩這種數(shù)豆子的無聊游戲 —— 反正我每周基本上都能把 Claude Code / Codex 的額度燒光，主要都用在了 Pigsty 里面的幾個項目上。但非要一個量化指標的話，大概每天平均產(chǎn)出在四千行代碼左右 —— 基本上達到了正常自己寫幾十倍的速度，我的體感大約在 20 倍速左右。

最近我在主要折騰的是 pig 命令行工具，我準備把它作為一個 Agent Native CLI 的樣板來實現(xiàn) —— 包裝 PostgreSQL，Patroni，Pgbouncer，Pgbackrest 管理能力 —— 主動為 Agent 提供上下文與能力地圖，以 yaml/json 格式化輸出。然后也加了很多功能，大概 5 天時間，新增了四萬行左右的 Go 代碼。

當然還有其他很多項目都在并行推進，但其中 Pigsty 是最有代表性的一個。

在改進的全程中，我只在開始時進行了幾次頭腦風暴，給出了項目的整體改進思路。在系統(tǒng)自動循環(huán)運轉(zhuǎn)了四天之后，我來進行驗收并做了一個冒煙測試，接著將生成的能力提取出來。最后在幾輪優(yōu)化之后，項目就完工了。

整個過程我只是“出嘴”確認幾個關鍵問題，然后不斷機械地循環(huán)執(zhí)行以下四輪流程：CreateStory ?? DevStory ?? CodeReview ?? FixThis

就這樣把活兒給干出來了。在這個過程中，我沒有寫過一行具體的代碼。

當寫代碼一文不值，什么才值錢？

很多人 Vibe Coding 都是在寫 Demo——糊出一個看起來能用的東西很簡單，糊出一個質(zhì)量可靠的東西相當難。

我的看法是：當"寫代碼"本身不再稀缺，剩下最有價值的東西只有兩樣——

1.你能提出有品位的設計。2.你能進行可靠的工程驗收。

我在實踐中總結了兩個核心方法。

設計：中心法則——從意圖到代碼的信息級聯(lián)

這個名字借自分子生物學的中心法則：DNA → RNA → 蛋白質(zhì)。在軟件工程中，對應關系是：

具體的工作流是 BMAD 方法論，當然實踐中我就簡化為 BMA 三個縮寫了：

1.Brainstorm：頭腦風暴，討論要做什么。2.Map：根據(jù)頭腦風暴產(chǎn)出 PRD，拆解為 EPIC 和 Story。3.Act：循環(huán)處理這些 EPIC 和 Story。

這套流程的關鍵在于：你不能憑感覺寫代碼。不能這里糊一錘子、那里敲一下。你得先有總體綱領（DNA），然后再出設計規(guī)格（RNA），再由規(guī)格生成代碼（蛋白質(zhì)）。這樣產(chǎn)出的代碼是可追溯的、可驗證的——每一行代碼都能回溯到它對應的 Story，每個 Story 都能回溯到 PRD，PRD 能回溯到最初的意圖。

沒有這條信息鏈，就不是在做工程，而是在做手工藝。每次用小錘子東敲敲西敲敲，做點小型手工軟件也沒啥問題，但是復雜度一旦上來就完蛋了。

驗收：Agent 對抗——讓 AI 互相找茬

只用一個 Agent 來開發(fā)加 Code Review，質(zhì)量是不夠的。最佳實踐是讓不同的 Agent 各司其職，彼此制衡。

我的做法是：Claude Code 做原型與粗活，負責創(chuàng)建和開發(fā) Story，快速出初版代碼。Codex 5.3 做 Code Review 審查未提交的修改，逐條提出 P0/P1/P2 級別的問題。在這個過程中，需要人類的判斷力介入，判斷 Codex 哪些問題要修，哪些是誤報。

?真實問題：確認是 Bug，直接讓它修。?誤判：你認為這是 Feature 而非 Bug，或者錯誤理解了你的設計意圖，就讓它寫清楚注釋，更新設計文檔，防止以后重復誤報。

Codex Review 完成之后，就進入來回打鐵的環(huán)節(jié)。讓 Claude 來 Review Codex 的修改，評價它的 Review 結果。然后不斷反復，如有分歧，繼續(xù)對抗，直到達成共識。

本質(zhì)上這是管理術中的制衡機制。假設你是一個不懂技術的領導，如何確保技術團隊不偷懶、不犯傻？一個簡單的辦法：讓他們互相找茬。經(jīng)過充分辯論后達成的共識，大概率是靠譜的。

把這個邏輯套到 AI Agent 上同樣成立——兩個不同架構、不同訓練數(shù)據(jù)的模型，犯同一個錯誤的概率遠低于單個模型。這不是什么高深理論，就是樸素的交叉驗證。

實際操作中，一個 Story 我一般會跑 3 到 8 輪 Review/修復循環(huán)。如果幾輪下來兩個 Agent 還是無法達成共識，我就人工介入仲裁。

當然，最后還是要有一個人工驗收的環(huán)節(jié)。你可以事先寫好測試用例，定義好邊界。如果你很懶的話，另一個取巧的辦法就是讓 Agent 自己去拉 Docker 設計一個測試環(huán)境并設計各種測試用例，然后反復測試。這里面其實就是一個樸素的技巧：你讓它來回重復測。每次測完換個角度、換一個測試的焦點，有時候它就能發(fā)現(xiàn)一些問題，大力出奇跡。

當然，最后還是要有一個人工驗收的環(huán)節(jié)。你可以事先寫好測試用例，定義好邊界。如果你很懶的話，另一個取巧的辦法就是讓 Agent 自己去拉 Docker 設計一個測試環(huán)境并設計各種測試用例，然后反復測試。這里面其實就是一個樸素的技巧：你讓它來回重復測。每次測完換個角度、換一個測試的焦點，有時候它就能發(fā)現(xiàn)一些問題，大力出奇跡。當然最后像 pigsty ，我還是得自己來做冒煙測試。但是前面的很多輪拉扯，基本上都已經(jīng)把各種問題都提前發(fā)現(xiàn)并處理好了。

當然，其實還有很多軟件工程的小技巧。比如說，你要及時地去處理技術債：做幾個 EPIC 就定期重構，做一次整體的瘦身與代碼優(yōu)化。把降低復雜度當作一個首要的設計與實現(xiàn)目標，及時移除死代碼；充分利用級聯(lián)文檔和注釋來提高理解的精準程度。這些就不詳細展開介紹了。

行業(yè)會怎么變？

上面兩個方法的共同指向是：質(zhì)量控制的核心已經(jīng)從 “寫代碼” 轉(zhuǎn)移到了 “設計 + 驗收”。既然寫代碼這件事可以被 Agent 批量完成，行業(yè)格局也會跟著變。

我的判斷是：AI 替代中級程序員，已經(jīng)沒有任何懸念了。

半年前的狀態(tài)是替代初級程序員毫無懸念。到了 2026 年當下，Codex 這個質(zhì)量水平，批量規(guī)?；娲屑壋绦騿T已經(jīng)是現(xiàn)實，至于高級程序員，我感覺也是時間問題。以后可能不會再有"程序員"這個職業(yè)，只有"軟件工程師"。區(qū)別在于：

程序員（碼農(nóng)）工作的核心是寫代碼。而 軟件工程師是用工程方法解決 “寫什么代碼、為什么寫、怎么驗收” 的工程問題。

軟件行業(yè)作為"高科技行業(yè)"的時代可能要結束了。我們正處于它向傳統(tǒng)行業(yè)回歸的進程中?；ヂ?lián)網(wǎng)/軟件行業(yè)可能有超過一半的技術崗位會被直接消滅——而溢出的程序員會涌入各行各業(yè)，把技術能力擴散出去，進而推高全行業(yè)的失業(yè)率，也就是這兩年的事情。

誰受益，誰受損？

以前軟件行業(yè)是"紡錘型"結構——頂尖專家少，中間骨干多，底層新人多?，F(xiàn)在 AI 的沖擊主要集中在中間層。在大廠里，畢業(yè)三五年、P6/P7 這個群體受到的沖擊最大。而資深專家進入一個超級紅利期 —— 這個窗口至少還有兩年。再往后說不定超級智能都出來了，現(xiàn)在討論也沒太大意義。

反直覺的是：聰明的應屆生反而大有機會——工資低、學習快、對舊工具沒有路徑依賴。我推斷，未來一兩年軟件工程的最佳實踐會收斂為 10 人以下的精煉團隊：1-3 個核心專家，配 6-7 個實習生，人均配備 2-3 個 AI Agent 輔助出活。

如果是頂尖專家，一個人也能通過指揮一堆 Agent 干出了不起的項目——"One Person Company" 會大量涌現(xiàn)。我自己一個人搞出了 Pigsty 這么大的項目，沒有 AI 是不可能的。

老馮沒興趣也沒時間到處鼓吹 Vibe Coding ，俗話說，悶聲大發(fā)財是最好的。不過今天正好有空，就口述篇文章聊一聊，把一些實踐和判斷分享出來。

同行朋友們 —— 時代真的變了，早做打算吧。

數(shù)據(jù)庫老司機

點一個關注 ??，精彩不迷路

對 PostgreSQL， Pigsty，下云 感興趣的朋友

歡迎加入 PGSQL x Pigsty 交流群 QQ 619377403