氛圍編碼 vs. 代理式工程

資料來源#

• Andrej Karpathy: From Vibe Coding to Agentic Engineering
• Boris Cherny: We Cut 80% of Claude Code's Prompt
• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501
• OpenAI Codex lead on the new shape of product work
• Thread by @AndrewYNg

摘要#

Andrej Karpathy 在 2025 年創造了「氛圍編碼」一詞，一年後又為它認真命名了接班概念：代理式工程。兩者的差別在於「移動的是哪一道標準」。氛圍編碼提高底線——現在人人都能打造軟體。代理式工程則在加快速度的同時，維持專業軟體的品質標準：「你不能因為氛圍編碼而引入漏洞；你仍須為自己的軟體負責，但能不能做得更快——又該如何妥善做到？」這是一門協調能力突出、容易出錯、具隨機性卻也強大的代理程式，同時不犧牲品質的工程學科。

兩道標準#

• 氛圍編碼——提高底線。 人人都能隨興編碼、打造任何東西。「驚人，令人難以置信。」這是民主化（參見 Printing Press Software Democratization）。重點不在品質，而在人人都能參與。
• 代理式工程——提高上限，同時維持品質。 保留專業軟體的責任（安全性、正確性、可維護性），並運用代理程式加快速度，同時不低於這道標準。「做好並做對，就是代理式工程的範疇。」

這是兩種不同活動，不是同一條線上的不同位置。一種降低入門成本；另一種則為原本就達到標準的人提高產出上限。

「10 倍不是速度提升的上限」#

Karpathy 明確表示，舊有的「10 倍工程師」說法已經太保守：「10 倍不是你能得到的速度提升……非常擅長這件事的人，巔峰表現遠超過 10 倍。」代理式工程能力的上限非常高，平庸從業者與 AI 原生從業者之間的差距會擴大，而不是縮小。（這呼應了 Harness Shrinkage as Models Improve：隨著模型進步，槓桿效益持續增加；真正的限制因素變成操作者的品味——參見 Outsource Your Thinking, Not Your Understanding。）

AI 原生從業者是什麼樣子#

有人請 Karpathy 比較平庸使用者與完全 AI 原生的 cloud code / codex / open claw 使用者，他的回答平實而重要：用心打造自己的設定，善用工具的所有功能。 就像最能發揮 Vim 或 VS Code 的工程師一樣——如今這套做法用在 Claude Code / Codex 上。精通的關鍵在於熟悉設定與功能，而不是掌握什麼祕密提示詞。

招聘方式必須改造#

實際的推論是：多數團隊仍沿用舊模式招聘（謎題、leetcode）。Karpathy 認為，代理式工程人才的招聘應該像是*「給我一個很大的專案，看人能不能把它做好」——例如，打造一個安全的 Twitter 仿製品供代理程式使用，再讓紅隊代理程式（「codex 5.4 xhigh」）試圖攻破它，結果辦不到*。招聘應測試可驗證、從頭到尾打造並防護系統的能力，而不是單獨解謎的本事。（參見 The Verifiability Thesis，了解為何「而且它攻不破」是不可或缺的另一半。）

人類仍要負責的部分#

即使能力上限很高，人類仍掌握規格、品味、判斷與監督——代理程式負責填補空白。他談到 MenuGen 的故事：代理程式用電子郵件地址配對 Stripe 與 Google 帳戶，而非持久的使用者 ID——「真是奇怪的做法」，正是 Jagged Intelligence (Ghosts, Not Animals) 所預測的那種錯誤。你必須設計規格（「這些必須是唯一的使用者 ID，我們會用它們串起所有資料」）並提供品味；代理程式則處理你早已不再背誦的 API 細節。

資深工程師的失誤模式：過度具體指示（Cherny）#

Boris Cherny 點出資深工程師使用現代模型時常犯的錯誤（YC 訪談，2026 年 7 月，practitioner-opinion）：「指示過度具體……你必須先做一，再做二，再做三，再做四。對現代模型來說，這真的不是合適的做法。」修正方法是把視角提高一層——描述任務、護欄與退出標準，接著「讓模型自由發揮」。 他將此視為一個去學習的問題：數十年來建構確定性系統的經驗，讓工程師習慣下達過度具體的指示；「當我看到那些寫了數十年程式的工程師，這真的是非常非常常見的失誤模式……這得花一段時間才能學會放下」——要把模型「當成同事看待。它現在的智慧程度就是如此。」這與 Karpathy 所說平庸者和 AI 原生者之間的操作者技能差距，談的是同一個面向，只是方向相反：拉大差距的不只是工具熟練度，還有是否願意放下過去被視為專業表現的先入之見。（這項建議取決於模型世代：「這件事六個月前還行不通，但今天行得通」——委派層級本身就是一個持續縮小的 harness調節鈕。）

不斷變動的標準：受監督與非受監督（Ambrosino）#

Andrew Ambrosino（OpenAI Codex）以標準不斷變動的觀察，重新表述同一個「移動的是哪一道標準」的區別，並將此變化視為進步的證據而樂見其成。有人問產品有多少比例由 AI 撰寫，他回答：「如果沿用去年的標準，我們的產品 100% 都是 AI 撰寫的程式碼。所以問題更像是——這些程式碼是在受監督還是非受監督的情況下撰寫？這是完全不同的事。我樂見標準移動，因為這代表我們正在進步。」如今關鍵不再是由人類還是 AI 撰寫（已成定局），而是撰寫過程仍需要多少人類監督——這正是代理式工程「維持品質標準、同時加快速度」的主張，換算成監督成本來衡量。

他也用**「寫程式就是引導 AI」來描述互動模式：衡量 AI 貢獻的誠實方式，不是問「我的程式碼有幾成是 AI 寫的」，而是問「我得引導它走上正確方向幾次」——這是運算分配者／引導者角色的另一種說法。至於前沿發展，他說：「迴圈已經是上週的事了。」領先者已從協調式迴圈轉向自主開發**與harness 工程——例如讓代理程式在夜間為程式碼庫做「垃圾回收」——不過他也指出技術尚未成熟（模型「通常會增加複雜度」，而且不擅長刪除程式碼）。這讓我們從 OpenAI 的角度，看到氛圍編碼到代理式工程的階梯：從業者如今要問的是受監督或非受監督，以及可以信任迴圈自主到什麼程度，而非模型能不能寫程式。

手藝派的異議：DHH 拒絕這套詞彙，重新劃定界線#

DHH——手工撰寫 Ruby 二十年，如今交付的程式碼 100% 由代理程式撰寫——在 Lex Fridman #501（2026-08-26，practitioner-opinion）直接回應本文的框架，並否定其中一半。

談術語。「代理式工程——喔，我他媽超討厭這個詞……首先，它現在已經淪為行銷垃圾話了。什麼東西都硬套上這個詞。我真希望有個不同的詞，單純表示 AI 在做事。」他也不喜歡另一個詞：氛圍編碼「聽起來跟 2000 年代初期那些只會照本宣科的小屁孩一模一樣。大家套用從網路上下載的 PHP 腳本，卻完全不懂自己在做什麼。」

談界線本身——另一種切法。 Karpathy 的區分談的是哪道標準移動（底線或上限）。DHH 關注的是實作是否可見，而且界線更明確，因為二分法很清楚：「如果我們在這裡這樣定義，氛圍編碼就是你叫代理程式替你打造軟體。你不查看實作內容。 對我來說，這就是氛圍編碼與程式設計，或說代理加速開發之間的分界。」他拒絕把這種成果稱為程式設計，理由是程式設計指的是理解基本元素——迴圈、條件、變數——而不是產出程式：「你可以說在代理式時代之前，嗯，你的執行長在寫程式……我不認為大多數人會稱那位執行長為程式設計師。」接著他又表示自己的工作同時符合這兩種標籤：他用氛圍編碼打造 Omawrite（一款 C++/Qt Markdown 編輯器，他刻意從未讀過其中任何一行，是「100% 的黑箱」），但仍會檢視 Omarchy 模型層的整體樣貌。

談專業可能反成負擔。 本文隱含的假設——AI 原生從業者是投入心力調整工具的優秀工程師——在這裡受到最直接的挑戰。有人問程式設計師是否有些問題會比非程式設計師做得更差，DHH 回答：「絕對有。」他的理由是：「很多程式設計師並不是很好的產品經理。軟體就是產品管理。 它該做什麼？該為誰而做？……在代理時代，你會讓代理程式負責實作，而你需要的就是這些技能。」他以自身經歷說明，而非提出理論：「我確實認為，有段時間我懂太多程式設計，反而讓自己吃虧，因為我會照自己的規定指示代理程式做事……下一個階段，任何人都能描述成果，而且比讓程式設計師指定做法還能得到更好的解決方案。」對照 Returns to Expertise in Agentic Coding——該研究測量的是相反方向：領域專業知識讓經驗證的成功率提高一倍——兩者的調和方式是，DHH 描述的是被錯用來指定做法的實作專業知識，而 Anthropic 的研究測量的是作為背景資訊提供的領域專業知識。

來自 Anthropic 之外的印證，呼應 Cherny 對過度具體指示的發現。 DHH 點名提及系統提示詞縮減 80% 一事：「Boris 在 Claude Code 工作時分享的一件事……他們隨 Opus 5 出貨的系統提示詞縮短了 80%，因為代理程式不只需要少得多的人類指示，還真的會被過度好為人師的人類拖累。」他用一個貼切的比喻讓人印象深刻：「任何遇過自以為是的老闆的程式設計師，都知道那是什麼感覺……如果有人強迫你做違背自身判斷的事，你就會寫出更差勁的程式碼。代理程式又為什麼會不一樣？」參見 Harness Shrinkage as Models Improve。

這套想法還有更早的脈絡。 他提出的正面建議不是「把提示詞寫好一點」，而是把敏捷開發的主張移植過來：先寫好完整規格的做法失敗了四十年，因為「沒有人在收到成品之前知道自己想要什麼。你得實際操作，才知道程式應該做什麼。所以在代理時代，你應該抗拒一開始就把要求寫得過度具體的誘惑。盡可能保持模糊，先做出一個雛形，再和它互動。」他指出，人類的貢獻在於比較評估——給一個人三個選項，直覺很快就能回答；給他二十二個，他就會陷入選擇困境。這為本文其他部分視為基本要素的「品味」，提供了具體形式。

延伸閱讀#

• Spec-Driven Development as the New Waterfall——同一領域裡另一場定義之爭：Matt Pocock 提議用持續保存作為提示與規格驅動開發的分界，而 Robert C. Martin 則拒絕將規格持續保存

• Is Persistence the Line Between Prompting and Spec-Driven Development?——以反對持續保存作結，並把 DHH 的界線並列：兩者都試圖用一項可觀察的測試（它在程式庫裡嗎？你讀過實作嗎？）來驗證一種實際上屬於行為傾向的特質

• DHH (David Heinemeier Hansson)——手藝派的異議：兩種術語都討厭，將界線劃在實作是否可見，並指出自己的程式設計專業曾一度成為負擔

• The Code-Quality Payoff Is Token-Indexed——DHH 背後的經濟論點：代理式工程應維持的品質標準，原本建立在人類修改程式碼很便宜的前提上，而他認為這個前提已經過時

• Open Source Under Agent Contributions——貢獻者的案例：一位從未讀過 C++ 的外掛作者，依照 DHH 自己的定義是在做氛圍編碼，而維護者樂見其成

• Building Is Cheap, Arguing Is Expensive——生成成本低，原型才能為技術辯論定案

• Andrej Karpathy——創造這兩個詞的人

• Software 3.0——這兩種活動所處的典範

• Jagged Intelligence (Ghosts, Not Animals)——說明代理式工程為何需要人類監督：代理程式會犯下奇特且能力參差的錯誤

• The Verifiability Thesis——這門工程學科仰賴可驗證的建構與防護任務

• Outsource Your Thinking, Not Your Understanding——品味、判斷與規格是這門工程學科所倚重的人類剩餘瓶頸

• Harness Shrinkage as Models Improve——隨模型進步而出現的「超過 10 倍且差距擴大」槓桿曲線

• Printing Press Software Democratization——提高底線的那一半，同樣是 Boris Cherny 所描述的民主化

• Claude Code Best Practices——代理式工程的具體實踐（探索→規劃→編碼，以驗證為導向）

• Verification as the New Bottleneck——Fiona Fung 對組織層面「維持品質標準、同時加快速度」的說明

• Claude Code——這些實踐發生的介面

• Acceleration Whiplash——反面案例：Faros AI 的產業遙測資料，顯示組織不採行代理式工程時，品質標準會如何下滑（每位開發者的錯誤增加 54%，每份 PR 的事故增加 242.7%）

• AI as Primary Author——「你仍須為自己的軟體負責」，是 Faros 大規模記錄作者身分與問責落差時，責任面向的核心

• Returns to Expertise in Agentic Coding——以數據衡量雙重標準論點：Anthropic 的 40 萬場工作階段研究發現，職業幾乎無關緊要（底線提高了——任何人都只比軟體工程師低 7 個百分點以內），而領域專業知識仍決定成敗（標準得以維持）

• Andrew Ambrosino——OpenAI 方面對「受監督與非受監督」、「寫程式就是引導」及「迴圈已經是上週的事了」的重新表述

• Compute Allocator——「寫程式就是引導 AI」指的是運算分配者的角色：衡量引導次數，而非程式碼行數

• Agentic Technical Debt——Ambrosino 所指出、阻礙迴圈完全自主運作的因素：模型會增加複雜度，而且不擅長刪除程式碼

• The Three Loops of AI-Native Building——Andrew Ng 發表迴圈分類的同一週，Ambrosino 說「迴圈已經是上週的事了」；只有把 harness 迴圈（已被能力吸收）與產品迴圈（具結構性，且沒有縮短）混為一談時，兩者才會互相矛盾

• Prototype Fidelity After Cheap Polish——HCI 領域對同一實踐的看法：氛圍編碼是「介於設計與開發之間的一項獨特專業技能」，應該納入教學；但該提案仍未區分本文所談的底線與品質標準

尚待解答的問題#

• Karpathy 暗示有一個對創辦人「非常[有價值]」的領域，但沒有透露是哪個（他不想「在台上發表模糊貼文」）。他指的是哪個可驗證的 RL 環境領域？
• 如果平庸者與 AI 原生者之間的差距持續擴大，團隊組成會如何改變——少數極端出色的人加上代理程式，還是廣泛配置中階人力？

資料來源#

• Andrej Karpathy: From Vibe Coding to Agentic Engineering
• OpenAI Codex lead on the new shape of product work — Ambrosino：「受監督與非受監督」；「寫程式就是引導 AI」；「迴圈已經是上週的事了」
• Thread by @AndrewYNg — Andrew Ng，The Batch（2026-06-30），practitioner-opinion：與「迴圈已經是上週的事了」同一週發表的三迴圈分類
• Boris Cherny: We Cut 80% of Claude Code's Prompt — Cherny，YC 訪談（2026-07-27，practitioner-opinion）：過度具體指示是資深工程師的失誤模式；應提供任務、護欄與退出標準，而不是步驟清單
• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501 — DHH，Lex Fridman #501（2026-08-26，practitioner-opinion）：拒絕這兩個術語；以實作是否可見定義氛圍編碼；「軟體就是產品管理」；程式設計師可能比非程式設計師更差；獨立印證過度具體指示的發現