氛圍編程常被當成一種告解。有人承認自己沒讀過模型寫的任何一行程式碼就打造出一個能運作的應用，現場的反應就好像他們剛承認跳過了安全檢查一樣。以下是我想為之辯護的主張：這種反應大致上是錯的。不打字寫語法，並不等於不知道自己在做什麼——這只是把你的判斷力分配到不同的地方，而對於人們建構的絕大多數東西來說，這才是正確的分配方式。
「氛圍編程」這個詞才問世幾年，卻已經被過度使用。它被用來指稱兩種從外部看起來很像、實際上完全不同的行為：
- 有人仔細描述自己想要什麼，用真實標準檢驗結果，然後才發布上線。
- 有人貼上一個模糊的想法，瞄一眼截圖，就抱著僥倖心態推上正式環境。
批評氛圍編程的人，通常公平地說，是在描述第二種人。但他們談論這件事的方式，卻好像第一種人根本不存在，或者這兩種人其實在同一條光譜上，差別只在懶惰程度。他們根本不在同一條光譜上。一個是工作流程，另一個則是完全沒有工作流程。
舊技能真正的用途是什麼
逐行讀程式碼、把一個堆疊追蹤（stack trace）追回三個檔案外的空指標——這從來都不是目的本身。這只是達成某個從未改變的目標所使用的唯一可用方法：這東西是否符合我的需求、是否安全、而且我明天還能不能信任它。三十年來，回答這個問題的唯一方式，就是精通該語言到足以直接檢視機制內部。於是「精通程度」變成了「能力」的代理指標，最終這個代理指標被誤認為目的本身。人們開始把「能讀懂 diff」當成一種道德美德，而不是達成目的的手段。
一旦驗證不再需要那種精通程度——一旦一次建構本身就能產生測試了什麼、通過了什麼、審查代理標記出什麼問題的紀錄——那個代理指標就不再必要了。你又回到真正的問題本身：它有沒有用？我能不能信任它？我們特意把驗證紀錄內建到每次建構中，正是因為這個問題需要一個不必透過「有沒有人讀過原始碼」來回答的答案——因為對大多數建構者來說，不管有沒有提示詞，這件事本來就不會發生。也沒人會去讀他們 WordPress 外掛裡的 PHP 程式碼。
那項技能實際上跑去哪了
它轉移到了規格撰寫上，而規格撰寫比聽起來難得多。觀察某人寫出一則真正優秀的建構提示詞，你會看到跟資深工程師寫設計文件時一樣的紀律：
- 驗收標準是什麼？
- 明確排除在範圍之外的是什麼？
- 結帳時購物車是空的這種邊界情況會發生什麼事？
- 誰能看到這筆資料，誰不能？
模糊的提示詞會產生模糊的應用，原因跟模糊的工單會產生模糊的合併請求一樣——垃圾約束條件產生垃圾輸出，這跟有沒有牽涉到模型無關。用 AI 工具做得好的人，並沒有省略思考，他們只是把思考提前了，從第一則錯誤訊息出現後的兩小時，移到第一則訊息送出前的十五分鐘。
移轉後的其餘技能，是審查層級的判斷力，這看起來不太像讀程式碼，反而更像是閱讀一次建構的摘要與其驗證紀錄，然後問出正確的、帶點懷疑態度的問題。「支援退款」這句話，實際上有沒有涵蓋退款進行到一半失敗的情況？它測試的是空狀態，還是只測了順利路徑？這是一項真正的技能，而且是可以教會的，方式跟「學會讀 Python」不同——後者只有一小部分有時間和天分的人學得會。我曾見過一位完全沒有程式背景的店主，對自己的庫存應用問出比不少工程師對他們沒寫過的程式碼還要更犀利的驗證問題，因為他懂自己的生意，也清楚知道對他來說「出問題」代表什麼。這不是一項次等技能來頂替真正的技能。對他的建構專案來說，這項技能比語法能力更貼切。
真正證實那些嘲諷有道理的故事
現在該讓步了，因為批評者並非憑空捏造。氛圍編程確實有一種真正糟糕的版本，而且常見到足以讓那些嘲諷有明確的目標：
- 有人打造了一套登入系統，看到綠色打勾就上線，卻從沒問過這套登入系統能存取哪些資料，或是在沒帶任何權杖的請求進來時會發生什麼事。
- 把一段用自然語言提示詞產生的資料庫查詢直接上線，卻沒檢查使用者輸入是否未經轉義就傳到了查詢裡。
驗證紀錄能告訴你建構有跑過、測試有通過。但它無法告訴你那些測試涵蓋的是不是對的東西，如果你不去看它，它也不會阻止你照樣部署。
這就是無論工具再怎麼進步都不會改變的底線：你仍然要為你的特定建構專案定義「完成」該是什麼意思負責，也仍然要真正去讀那份紀錄，而不是盲目相信那個打勾記號。
跳過品質把關並不是一種新型的能力表現，而是舊式的粗心大意換了一件新外衣，也因此招致它應得的名聲。批評者常犯的錯誤，是以為這就是唯一可能的模式——以為既然失敗的案例存在，嚴謹的做法就不可能存在。但事實並非如此。它只是不再長得像過去所理解的那種嚴謹，而那些只用語法熟練度來衡量能力的人，目前還沒有辦法看見它。
再過幾年，這個詞大概也會像「駭客」一樣，從「聰明的動手實作者」窄化成更嚇人的意思，然後再慢慢鬆綁回來。留下來的，會是真正重要的那個區別——一直以來都重要的那個：仔細規格化並檢查成果的建構者，與不這麼做的建構者。他們用什麼工具走到那一步，從來都不是重點。
