目錄

• 介紹

- [AI Is Awesome](#ai-is-awesome)

- [Failing Code and a Cold Bus](#failing-code-and-a-cold-bus)

• 「但是」來了

- [The Name Itself](#the-name-itself)

- [The Actual Vibe](#the-actual-vibe)

- [Journey is More Important than Destination](#journey-is-more-important-than-destination)

- [Let's Go Back in Time](#lets-go-back-in-time)

- [Abstraction Over Abstraction?](#abstraction-over-abstraction)

- [Now, What Happens if You Trust the AI Too Much?](#now-what-happens-if-you-trust-the-ai-too-much)

- [Security Risks](#security-risks)

- [Unless You're Building a Very Simple App, You'll Eventually Need to Talk to a Real Engineer](#unless-youre-building-a-very-simple-app-youll-eventually-need-to-talk-to-a-real-engineer)

- [And Last but Not Least — Sustainability](#and-last-but-not-least--sustainability)

• 當我們走向終點時，讓我們轉向積極的基調

- [Boilerplate Projects / Code](#boilerplate-projects--code)

- [Demo Projects](#demo-projects)

- [Bridging the Gap Between Engineers and Managers](#bridging-the-gap-between-engineers-and-managers)

- [Dipping Toes in Creating Products](#dipping-toes-in-creating-products)

- [To Sum Everything Up](#to-sum-everything-up)

介紹

人工智慧真棒

正如我在標題中提到的，我非常支持人工智慧。我認為這是計算機科學進化的合理下一步。我們一直致力於建立更智慧的系統，並盡可能實現自動化——這是人類天性的一部分。人類渴望便捷、有效率和簡單。我們越能輕鬆地建立和管理複雜的系統，就越好，這絕對沒有錯。

大型語言模型 (LLM) 已成為這項進步的基石。如今，幾乎每位軟體工程師都以某種方式依賴它們（或至少絕大多數人都依賴它們）。早在 2017 年，我以初級軟體工程師的身份受聘，開啟了我的職業軟體工程之旅。那時，情況截然不同。花一整天時間在網路上搜尋有時幾乎找不到的解決方案並不罕見。如果當時我可以使用 ChatGPT，我可以在 10 分鐘內產生一個解決方案，進行分析，並根據我的特定用例進行調整。

程式碼失敗和總線冷卻

當時，我們能使用的最好的平台就是 StackOverflow——說實話，它常常感覺像是網路上最毒的地方之一。我記得自己在一個很少使用的平台上工作，文件糟糕透頂，幾乎沒有社群支持。無奈之下，我決定在 StackOverflow 上發個問題。你知道發生了什麼事嗎？什麼也沒有。沒有回复，沒有點贊，也沒有踩踩——只有沉默。我又發了幾個問題（哦，我甚至因此獲得了徽章——我可沒騙你。）最後，不知何故，有人踩了我的問題，導致我的帳戶被鎖定。沒錯，就是那樣。被鎖定，不是因為發送垃圾訊息或惡意攻擊，而是因為問了一些沒人知道該如何回答的合理問題（這真是開啟軟體工程師職業生涯的好方法，對吧？）。如果我擁有像今天這樣的人工智慧工具，我職業生涯的那段時間就不會那麼痛苦了。我就能找到那些答案，不用在晚上 10 點回家的路上，坐在冰冷空曠的公車上，給自己壓力，思考我的職業選擇。

我分享這一切是為了明確一點：我非常支持人工智慧、機器學習、深度學習——整個領域。就連我的博士研究也專注於資料探勘和人工智慧。我曾與一些對這項技術持懷疑態度的人進行過專業辯論，說實話，我不明白他們為何抱持敵意。為什麼我要拒絕一個能幫助我更聰明地工作、更快學習、更有效率的工具呢？

「但是」來了

然而，這並不意味著我們應該以最糟糕的方式利用任何工具的潛力。某樣東西很強大，並不代表應該肆意使用。包括人工智慧在內的工具旨在幫助我們，而不是取代我們。這一點至關重要。

這讓我想到了我最關心的核心問題：氛圍編碼。

我對這種趨勢有根本性的質疑。它讓我感覺很不舒服。事實上，它在很多層面上都感覺不對勁，我甚至可能無法在一篇文章中全部闡述清楚。但讓我們先從最基礎的問題──那些根本性的問題──開始，然後再逐步探討更複雜的問題。

名字本身

即使氛圍編碼背後的概念很棒，但它仍然是最糟糕的名字。我認為它沒有經過深思熟慮。讓我們先分解一下，先定義一下這個術語的兩個部分：

氛圍：一個地方、情況、人等的心情以及它們給你的感覺（dictionary.cambridge.org）

編碼：編寫電腦可執行任務的指令序列（稱為程式）。它涉及設計和實作演算法，即使用一種或多種程式語言編寫程式碼，逐步規範程式。 (wikipedia.org)

現在我們已經定義了這兩個術語，我還有兩個非常愚蠢但誠實的問題：

1. 這一切的氛圍究竟在哪裡？

2. 這一切中編碼到底在哪裡？

我認為情況完全相反。

真實的氛圍

對我來說，程式設計的良好氛圍源自於學習——真正的學習。當你深入學習一門新語言，嘗試一個全新的函式庫，探索一種新的設計模式或架構風格時，這種氛圍就會出現。你會嘗試理解它，運用它，將它融入專案中——甚至可能只是為了看看它是如何運作的，而開始一個全新的專案。

然後，你不可避免地會失敗。你會碰壁。因為如果你不這樣做，你就真的不夠努力。你會花上幾個小時去弄清楚哪裡出了問題。在這個過程中，你會學到更多。最終，事情豁然開朗。你成功了。你甚至可能會和別人分享你學到的東西——就這樣，你成長了。你比剛開始的時候更優秀了。

這就是氛圍。整個旅程——好奇心、失敗、堅持、突破、情感。這賦予了編碼能量和意義。

我花了無數個小時修復頑固的 bug——當然，這在當時並不總是那麼有趣。有時它令人沮喪、精疲力竭，甚至令人沮喪。但當我找到解決方案的那一刻，一切都煥然一新。突然間，世界變得五彩繽紛。我甚至能清楚記得當時聽的是什麼音樂、當時幾點鐘、天氣如何、喝的是什麼咖啡——每一個細微的細節。

後來，當我聽到同樣的音樂時，一切都回來了。我又回到了那裡，再次體驗那些感覺。那種情感之旅，那種成就感，讓我對真正的程式有了意義。那才是真正的感覺。它不僅關乎結果，更關乎那段讓你成長的旅程。

旅程比目的地更重要

在我職涯剛起步的時候，我完全專注於目標——最終的結果、產出、「最終產品」。但是，我錯了。隨著時間的推移，我意識到，旅程才是真正重要的。

沒有終點——只有前進道路上的里程碑。這條路充滿挑戰、教訓，最重要的是，充滿感動。

這正是我最初成為軟體工程師的初衷。高中時，我常常想像自己未來的自己能夠深入理解複雜系統，能夠運用一套精準且得來不易的技能來解決問題。這個想像啟發了我。這正是這份工作如此酷炫的原因。

對我來說，這才是真正的氛圍——程式設計時經歷的情緒過山車。有起有落，有挫折也有突破。當你沉浸在問題中，慢慢地自己解決問題時，你的情緒也會跟著改變。我覺得沒有比這更好的氛圍了。

我實在無法理解，怎麼會有人把這個過程稱為“氛圍感十足”，因為你只需要告訴一個LLMs該做什麼，它就會幫你產生程式碼。我並不是說這完全不好，以後我會再談，但我覺得自己短期內不會這麼做。

讓我們回到過去

讓我們想像一下 20 世紀 80 年代的氛圍編碼會是什麼樣子——當時，以我們今天的水平來看，人工智慧還只是科幻小說。

你是一名電腦科學專業的學生，正在努力支付大學學費。你打開當地報紙，看到一個不尋常的招募訊息：

HELP WANTED: VIBE CODER
80sCoolVibes, Inc.
Venice Beach, California – Est. 1981

Are you looking for a coding job that doesn't require any actual coding knowledge?
Can you explain something in plain English?

Then congratulations — this job is for you.

... and the rest of the text ...

薪水不高，但剛好夠支付你的學費。於是，你申請了——出乎意料的是，你得到了這份工作。

這是你上班的第一天，你興奮不已。你終於踏入科技世界，正值史上最具代表性的十年之一——20世紀80年代。計算機正在起飛。未來正在即時書寫，而你渴望成為其中的一部分。

辦公室裡有個叫 Marcus 的傢伙——公司裡唯一真正的軟體工程師。他思維敏捷，程式碼寫得很棒。但問題在於：他不做決策，不設計系統。他只是坐在那裡，等著別人──你──告訴他該做什麼。

你的工作？告訴馬庫斯你想要什麼。等他完成。檢查結果。告訴他需要調整的地方。重複。

然後你開始意識到有些事情不對勁。

你正處於科技史上最活躍的時代。你想成為一名建設者、創新者，一個能夠徹底理解系統的人。但你卻只是用鍵盤打電話。你不是在寫程式碼——你只是在批准它、引導它、催促它。

你不是程式設計師。你只是告訴程式碼產生器該做什麼——無論生成器是人還是機器。核心概念是一樣的。

我不知道你是怎麼想的，但在那一刻，我會開始認真質疑我的決定和求職技巧——或者我只是認為我會成為新《黑鏡》劇集中的角色，這聽起來更可怕。

抽象勝過抽象？

程式語言正變得越來越容易學習。現代語言傾向於互相學習優秀的理念，力求使其語法更簡潔、更直覺、更易學。當然，總會有例外，但總的來說，如果你正在建立一種面向未來且被廣泛採用的語言，那麼擁抱這些進步不再是可有可無的，而是至關重要的。

現在，你可能會爭辯說，像 PHP 這樣的語言仍然被廣泛使用，或者幾乎整個美國銀行系統都在執行 COBOL。你說得對——但這些完全是另一回事。我指的不是那些用來建構大規模遺留系統的語言，這些系統幾乎不可能（或極度危險）重寫。

以航空業為例。如果一架飛機的機載軟體是用 C 語言編寫的，那麼沒人願意將其遷移到「更優秀」的語言——這完全有理由。你肯定不希望在 35,000 英尺的高空出現意想不到的 bug。同樣，如果一個銀行核心系統已經使用 COBOL 語言執行了幾十年，通常最好還是不要管它。這個系統如此龐大，如此關鍵，即使是一個微小的改變也可能造成重大中斷。在這種情況下，穩定性永遠比優雅更重要。

但對於新專案——那些剛設計或試圖獲得關注的專案——情況就不同了。如果你的語言讀起來、寫起來、推理起來都不容易，而且沒有其他突破性的優勢，那麼它將很難獲得廣泛的採用。開發者的體驗現在比以往任何時候都更重要。

我想強調的是，現代高階程式語言已經變得極為直觀。以 Python 為例——它幾乎可以像普通英語一樣讀懂，這本身就很好。任何人只需學習幾分鐘的基礎知識，就能用 Python 建立一個簡單的計算器應用程式。這就是易理解語法的力量——它賦予人們創造的能力，而不僅僅是快速的回應。

你無需讓 AI 模型為你編寫整個程式。你可以自己寫，用自己的語言，而且仍然完全掌控。你是飛行員－坐在左側，雙手握住操縱桿。當你遇到瓶頸或需要幫助記住某個語法時，你可以求助於你的副駕駛（AI）。你獲取訊息，對其進行改進，使其適應你的特定需求，然後將其整合到你的程式碼庫中。你不是盲目地抄襲——你仍然在駕駛你的飛機。

氛圍編碼的作用是在已經抽象的概念之上再引入一層抽象，但這次，抽象的可預測性要低得多。像 C# 這樣的程式語言本身就很高級，並且是從機器碼中抽象化出來的，但它們仍然精確可靠。如果你寫的程式碼違反了 C# 的語法規則，它將無法編譯。就這麼簡單。如果你知道如何用 C# 寫程式碼，你就能掌控一切。你可以記錄錯誤、除錯關鍵程式碼、分析效能、編寫簡潔易維護的程式碼——換句話說，你就是操控者。你了解系統在背景運作的機制。即使它是抽象的，它仍然是一致且確定的。

但氛圍編碼改變了這一點。它引入的抽象與託管程式碼的抽像不同——它更加模糊。例如，C# 編譯器總是會為同一段原始碼產生相同的中間語言和字節碼。而 AI 工具則可能根據上下文、隨機性或提示語，為相同請求產生完全不同的輸出。這使得這一新的抽象層可靠性大大降低——至少目前是如此。

那麼，如果你過度信任人工智慧會發生什麼事呢？

我不確定人工智慧的未來會怎樣，我也不會假裝預測它——但現在，如果你在編碼時過於信任人工智慧，事情可能很快就會變得非常糟糕。

需要說明的是，我指的不是那種向AI求助、審核輸出、進行調整，然後精心整合到專案中的工作流程。那樣就好了，效率很高。這就是一個好的副駕駛的職責所在。我指的是成熟的氛圍式編碼——你給一些模糊的提示，甚至都不看程式碼，就直接交付生產。已經有許多例子表明，這種做法可能有多糟糕。

以如今聲名狼藉的 Cursor 所建構的 SaaS 專案為例。計畫作者曾自豪地在推特上宣稱，該計畫「零手寫程式碼」。兩天後？他又發了一條推文——這次是關於 API 金鑰被用完、用戶繞過訂閱以及隨機垃圾資料被轉儲到資料庫中。用他們自己的話來說，「各種奇奇怪怪的事情發生了」。

那不是軟體工程。那隻是碰運氣，然後就稱之為開發。

我仍然真心地為那個人感到難過——你以為自己創造了一個了不起的東西，卻眼睜睜地看著別人濫用它，鑽空子，榨乾它的所有價值，這真是令人沮喪。但我們都需要接受一個事實：通往永續成功沒有捷徑。

即使你很幸運，不用付出太多努力就能迅速取得成就，但這些捷徑通常都會留下漏洞，而漏洞很容易被利用。

人們會注意到你為成功所採取的捷徑——有些人會故意沿著同樣的路徑設置陷阱，等待有人失誤。

是的，利用別人的失敗是不對的。但世界並不公平──網路當然也不公平。總有人在積極尋找可以利用的弱點。這就是為什麼無論你是在開發產品、創業或學習新技能，最好的心態都很簡單：「抱持最好的希望，做最壞的打算」。這不是悲觀主義，而是有備而來。

安全風險

現在我們已經了解了氛圍編碼的 SaaS 範例，讓我們簡要討論一下這種方法帶來的安全風險。

當你為公司開發軟體時，安全性並非可有可無，而是重中之重。你肯定不希望你的秘密 API 金鑰出現在 GitHub 倉庫中，或者更糟的是，被公開。你希望憑證、令牌和敏感配置能夠安全儲存、加密，並進行合理的範圍限定。

但是，AI 工具本身並不能理解應用程式中的敏感資訊。它們不知道哪些變數是機密訊息，哪些資料永遠不應該被記錄，也不知道哪些安全最佳實踐適用於你的用例。當然，你可能知道這些，並告訴 AI——因為你是一位經驗豐富的開發人員，以前遇到過這些問題。但是，對於那些從未遇到這些問題的人呢？那些將 AI 用作輔助工具，卻從未從頭開始建立安全系統的人呢？他們可能會在不知情的情況下將機密資訊提交到版本控制中，以明文形式記錄使用者密碼，暴露內部端點，或打開巨大的攻擊面——所有這些都是因為程式碼「看起來沒問題」。

這就是氛圍編碼的真正危險：它可能會跳過你甚至不知道應該關心的部分。

除非你正在開發一個非常簡單的應用程式，否則你最終需要與真正的工程師交談

軟體很快就會變得非常複雜——尤其是在企業環境中。如果你的應用程式完全由人工智慧模型建置，而你最終在嘗試修改一些非常具體的內容時遇到了瓶頸，那麼人工智慧很可能無能為力。有一次，我正在自訂我的個人 .NET 專案範本應用程式。我需要以一種非常具體的方式調整 .NET 專案範本的template.json文件，即使經過多次嘗試，人工智慧也無法產生可行的解決方案。最終，我在 GitHub 的一個討論貼文中找到了解決方案。

這時候，你需要一位真正的軟體工程師──能夠閱讀、理解並精準更新程式碼的人。或者，他甚至知道如何找到AI無法找到的解決方案。但問題在於：這樣的人很可能不會喜歡AI生成的程式碼。事實上，僅僅加入一個功能、修復一個錯誤，甚至理解現有的結構，都可能需要付出巨大的努力。從頭重構程式碼庫？那可能是一場惡夢。

Vibe 編碼建構速度很快，但也可能悄無聲息、無形而迅速地累積大量技術債。

最後但同樣重要的一點——可持續性

當被問及人們對 ChatGPT 說「請」和「謝謝」之類的話給 OpenAI 帶來多大損失時，Sam Altman 在 X 上做出了著名的回答：

“數千萬美元花得值——誰知道呢。”

這還只是一些禮貌的回應——例如「沒問題」或「不客氣」。如果這些細微的互動要花費數千萬美元，我們就能大致了解幕後消耗了多少能源。

現在縮小並單獨查看 ChatGPT 的完整尺寸：

• 每日活躍用戶約 1.22 億

• 每週活躍用戶約 4 億

• 每天處理約 10 億則訊息

• 每天消耗約 1 吉瓦時的電力——大約相當於每天為 33,000 個美國家庭供電

對於一種產品來說，消耗的能量是驚人的。

軟體工程的核心原則之一始終是效率——這不僅體現在效能或架構上，也體現在我們如何消耗資源。然而，透過氛圍編碼，我們卻反其道而行：將能源消耗推向了前所未有的水平。偶爾在靜態網頁上尋找資訊是一回事，而讓 AI 模型全天生成、重新生成並重新表述整個程式碼庫則是另一回事。

如今，全球有數千萬軟體工程師。而氛圍編碼——就其本質而言——比實際的工程設計更容易。因此，不難想像，未來氛圍編碼員的數量將遠遠超過傳統開發人員。

如果發生這種情況，軟體開發的能源足跡可能會激增——帶來碳排放的大幅增加，以及我們尚未準備好應對的永續性危機。

這不再只是一個技術問題，這也是一個環境問題──我們遲早要解決這個問題。

當我們走向終點時，讓我們轉向積極的基調

那麼氛圍編碼其實有何意義呢？

樣板專案/程式碼

首先，快速產生樣板專案是一個很好的用例。人工智慧工具可以顯著簡化這一過程——尤其是在您尚未建立模板系統的情況下。當然，如果您已經投入時間建立自己的自訂模板，那么生成樣板就像執行一個 CLI 命令一樣簡單。但如果您還沒有呢？人工智慧可以很好地填補這一空白。

示範專案

氛圍編碼的另一個亮點是為客戶建立演示專案。有時，你不需要一個功能齊全的產品——你只需要一些可以展示的東西。一個可行的概念。一個粗略的想法證明。與其花數小時拼湊一個一次性的演示，不如讓人工智慧來處理。快速建置，展示你的願景，之後可以將其丟棄，也可以將其作為原型保留，以便日後改進。

彌合工程師與管理人員之間的差距

這種方法對於非技術利害關係人（例如專案經理或產品負責人）也非常有用。借助人工智慧工具，他們可以快速建立原型，以直觀和功能性的方式向開發團隊傳達他們的願景。他們無需編寫冗長的需求文件，只需產生一個他們心中產品的粗略版本，就能更清晰地了解他們的目標。這種快速原型設計可以減少誤解，並幫助開發人員更快、更準確地交付預期成果。

嘗試創造產品

它還可以在新開發者入職或幫助人們探索該領域方面發揮重要作用。透過嘗試 AI 產生的程式碼，初學者可以了解不同領域的編碼方式。他們可以產生 Web 應用、桌面工具、行動應用程式和遊戲，並探索自己感興趣的領域。雖然氛圍編碼無法取代深度學習和實際經驗，但它可以成為通往真正軟體工程的大門。

總結一下

氛圍編碼本身並非壞事——但如果用在錯誤的環境中，它可能會造成滑坡效應。就像生活中幾乎所有事物一樣，它是一種工具。而且，就像任何工具一樣，它可以為你帶來好處，也可以變成負擔。這完全取決於你如何使用它，以及何時使用它。

我很快就能用上氛圍編程了嗎？可能不會。我仍然想成為駕駛艙裡的主駕駛員——完全掌控一切，完全了解引擎蓋下發生的一切。現在還不是我和人工智慧交換座位、把控制權交給人工智慧當副駕駛的好時機。

但一旦它成為標準，我肯定會做出改變。 ——從長遠來看，我仍然相信這是未來。

如果其他人在這種工作流程中找到了活力和創造力？如果他們對以這種方式建置充滿熱情？那就讓他們去嘗試吧。沒有人有權利阻止別人探索新的工作流程或工具。我只要求他們睜大眼睛，充分意識到其中的風險和局限性，尤其是在他們還缺乏發現危險信號的技術經驗的情況下。

說到底，我們都是同一個開發者社群的一份子。無論你是老派還是新派，是親自動手還是聽從語音指令——最重要的是，我們尊重彼此的發展路徑，並幫助彼此成長。

這才是真實的氛圍！

原文出處：https://dev.to/georgekobaidze/im-all-in-on-ai-but-we-need-to-talk-about-vibe-coding-the-new-slippery-slope-2k6p