OpenAI Codex：個人開發者的生產力雙面刃？

本週，中國 AI 開發者社群中出現一股難以忽視的熱潮。一篇讚揚 OpenAI Codex 的文章在短時間內吸引了 432 則留言，作者形容那種感覺就像「一人指揮千軍萬馬」。

其中一位留言者分享，他利用本地的 Qwen 模型進行影格標記、DeepSeek 進行劇本重寫，並透過自訂的 AI 導演層來決定剪輯點，主要都是透過 Codex 打造出自動化的影片編輯流程。另一位則將整個部落格工作流程自動化，第三位則描述了熟悉的上手過程：最初的模組開發很痛苦，但隨後突然開竅，剩下的部分幾乎是自動生成。

這篇文章充滿了慶祝的氛圍，留言區也是如此。我一直在等待有人提及背後的代價，但沒有人這麼做，所以讓我來試著說明。

生產力提升確實存在，而這正是問題所在。我一直觀察到這種動態：Codex 在生成程式碼方面確實很快，而且這些程式碼看起來通常是正確的，至少在本地端是如此。

它能以驚人的速度處理樣板程式碼、專案架構和例行性的整合工作，感覺就像多了幾雙手。對於擁有清晰規格和明確範圍的個人開發者來說，專案的前三到四個模組幾乎可以說是毫無阻礙。

但「毫無阻礙」這個詞在這句話中承載了許多意義。

當你親自撰寫程式碼時，即使寫得慢或寫得不好，你腦中也會有一個心智模型。你知道在哪裡偷工減料，知道哪個變數名稱是個謊言，也知道哪個函式因為你太累而做了兩件事。

這些知識雖然令人尷尬，卻也至關重要：它讓你在凌晨兩點生產環境出問題時，能夠進行偵錯。當 Codex 撰寫程式碼時，你得到的是沒有「傷疤」的輸出。

程式碼看起來很乾淨，甚至可能真的很乾淨。但你對它的心智模型比表面上看起來更薄弱，因為你沒有經歷過掙扎才能產生它。

社群中沒有人提及的失敗模式，正是「大軍」這個比喻的破綻所在。軍隊可以自信地朝錯誤的方向前進。Codex 越流暢地執行規格，模糊或錯誤的規格所帶來的代價就越高昂。

回想那位描述 Codex 上手過程的留言者：前兩個模組很痛苦，充滿了冗餘的程式碼，需要不斷審查。然後第三個模組進展順利，接著第四和第五個模組幾乎是自動生成。

這種順暢是一種訊號，但它不一定是個好訊號。如果模組一中那些通過審查的冗餘程式碼現在變得至關重要怎麼辦？如果 Codex 在模組二中內化的模式包含了一個錯誤的假設，而它現在正自信且一致地將這個假設傳播到所有下游程式碼中怎麼辦？

你不會在程式碼審查中發現它，因為程式碼是符合慣例的。你也不會在測試中發現它，因為測試是由相同的模型帶著相同的假設生成的。你將在生產環境中看到它，以一種難以追溯的失敗模式呈現，因為你正在閱讀的程式碼並非由一個你可以盤問的心智所撰寫。

規格是瓶頸，而我們大多數人都不擅長撰寫規格。原始文章的作者提出了一個值得更多關注的觀點：「只要你的思維和需求足夠詳細，它就能為你建立另一個宇宙。」

這個條件句就是整個論點的關鍵。Codex 是你規格的倍增器。如果你的規格很好，輸出就會又好又快。如果你的規格模糊，輸出就會看起來合理但錯誤，而且速度很快。

大多數開發者，包括經驗豐富的開發者，都不是受過訓練的規格撰寫者。我們習慣於迭代開發：撰寫程式碼、執行、查看哪裡出錯、然後調整。這個循環是我們精進對問題理解的方式。

當 Codex 消除了這個循環中的摩擦時，它也移除了一些訊號。你不會發現自己不知道自己不知道的事情，因為程式碼從未以會告訴你的方式失敗。

影片流程的留言者可能擁有足夠的領域知識來察覺這些問題。他們建立了一個複雜的系統，並且顯然仔細思考了架構。

但在同一個討論串中，有位留言者真誠地問道，使用 Codex 是否需要懂得閱讀程式碼。他們得到的答案是模糊的。

真正的答案是：你不需要撰寫程式碼，但你需要能夠評估其輸出，而這需要你對問題有足夠的理解，才能辨識出解決方案何時是錯誤的。

這個討論串的重點其實不在於 Codex 的能力，而在於誰能夠交付軟體這件事的轉變。有幾則留言來自非專業開發者，他們利用 Codex 為自己的特定工作流程建立工具，例如影片編輯、內容自動化、部落格管理。

這種熱情是真實的。這些人以前無法建立這些東西，但現在卻可以了。然而，對話中幾乎沒有討論到維護、偵錯，或是六個月後當某個東西壞掉，而「建立」它的人卻無法閱讀程式碼時會發生什麼事。

這並不是停止使用 Codex 的理由，而是要審慎思考你用它來建立什麼，以及當這支「大軍」需要新指令而你卻不確定該如何指揮時，你是否有應對計畫。

人們描述的生產力數據是真實的。個人開發者在數小時內完成原本需要數天才能完成的模組，這並非誇大其詞：這些工具目前確實能達到這種水準。

但成本結構已經轉移，而非消失。過去你支付的是撰寫程式碼的時間，現在你支付的是規格的品質和偵錯的深度。如果你擅長撰寫規格，並且擅長閱讀不熟悉的程式碼，你就會佔上風。

如果你兩者皆不擅長，那麼你正在背負一筆尚未見過條款的債務。那位說 Codex 讓後續模組感覺像「作弊」的留言者可能說得沒錯。

問題是，當模組八出現一個隱藏錯誤，而這個錯誤可以追溯到模組二的一個假設時，他們是否還會有這種感覺。你曾處理過最糟糕的 Codex 失敗案例是什麼？你花了多久時間才找到實際的錯誤發生在哪裡？