寫代碼一文不值的時(shí)代，什么才值錢？

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

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

Codex 5.3：到底能不能打？

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

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

不過關(guān)于模型能力，老馮從來都不看什么榜單，只相信它們?cè)谧约簣?chǎng)景上的真實(shí)效果。我有一個(gè)簡(jiǎn)單粗暴的評(píng)估方法：交叉掃描。

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

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

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

我用 Codex / Claude 做什么？

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

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

當(dāng)然還有其他很多項(xiàng)目都在并行推進(jìn)，但其中 Pigsty 是最有代表性的一個(gè)。

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

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

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

當(dāng)寫代碼一文不值，什么才值錢？

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

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

1.你能提出有品位的設(shè)計(jì)。2.你能進(jìn)行可靠的工程驗(yàn)收。

我在實(shí)踐中總結(jié)了兩個(gè)核心方法。

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

這個(gè)名字借自分子生物學(xué)的中心法則：DNA → RNA → 蛋白質(zhì)。在軟件工程中，對(duì)應(yīng)關(guān)系是：

具體的工作流是 BMAD 方法論，當(dāng)然實(shí)踐中我就簡(jiǎn)化為 BMA 三個(gè)縮寫了：

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

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

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

驗(yàn)收：Agent 對(duì)抗——讓 AI 互相找茬

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

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

?真實(shí)問題：確認(rèn)是 Bug，直接讓它修。?誤判：你認(rèn)為這是 Feature 而非 Bug，或者錯(cuò)誤理解了你的設(shè)計(jì)意圖，就讓它寫清楚注釋，更新設(shè)計(jì)文檔，防止以后重復(fù)誤報(bào)。

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

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

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

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

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

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

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

行業(yè)會(huì)怎么變？

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

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

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

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

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

誰(shuí)受益，誰(shuí)受損？

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

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

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

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

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

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

點(diǎn)一個(gè)關(guān)注 ??，精彩不迷路

對(duì) PostgreSQL， Pigsty，下云 感興趣的朋友

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