我們在之前的文章中討論過的vibe編碼所產生的問題非常嚴重，足以成為下一次重大計算機災難的起因。 現在是時候轉向人工智慧輔助程式設計了，這是一種更專業（風險更低）的方法。當您需要在對安全性和穩定性要求較高的場景下執行程式時，它是理想之選。
在本文中，我們將首先討論vibe編碼最常見的問題，以及為什麼儘管一些推廣者大肆宣傳，但它並不構成新的工業革命。 在接下來的章節中，我們將介紹在 Linux 系統中從 vibe 編碼過渡到 AI 輔助編程的過程。
氛圍編碼的問題
舉個例子：兩個人去一家高級餐廳。一個對烹飪一竅不通，另一個是烹飪高手。前者只知道自己想吃什麼，至多只能根據價格或自己未經訓練的味蕾來判斷菜色的品質。而後者則能分辨出食材是否新鮮，調味料用量是否恰當，以及是否被宰。
我們選擇以餐廳為例並非偶然。人工智慧專家安德烈·卡帕西是OpenAI的共同創辦人之一，也是特斯拉的人工智慧總監。 為了解決不知道點什麼菜的問題，他用Vibe程式開發了一個應用，該應用程式會顯示菜餚的照片。以下是他對自身經驗的描述：
“用 vibe coding 創建 MenuGen 作為本地演示很有趣，但作為真正的應用程序卻相當困難。構建一個現代應用程序就像組裝未來的宜家家具：大量的服務、API、配置、限制和價格。” 法學碩士們知識陳舊，容易犯一些不易察覺的錯誤，而且常常出現幻覺。 有趣的是，我幾乎沒花什麼時間寫程式碼，而是把時間都花在了配置瀏覽器服務上。所有這些內容，LLM（法學碩士）都無法存取。照這樣下去，我們怎麼可能在2027年之前實現所有功能的自動化呢？
讓我們更詳細地了解安德烈身上發生了什麼事，順便說一句，他 他不是網頁開發人員，這可能導致他把事情搞得比實際需要的更複雜。
“我使用了 Cursor + Claude 3.7，輸入了應用描述，它很快就用 React 編寫了所有前端組件，構建了一個漂亮的網站，使用了柔和的多色字體、小巧的 CSS 動畫、響應式設計等等，除了實際的後端功能。”
在應用程式設計中，前端和後端就像一枚硬幣的兩面。 前端是使用者互動的部分，而後端則負責資訊的處理和儲存。前端在本地運行，而後端通常在外部伺服器上開發。
至少在Vibe編碼的粉絲中，Claude是目前最偉大的模型語言。 造成這種情況的原因更多是意識形態上的，而非技術上的。開發該技術的安特羅派克公司曾因軍方未經監管地使用其模型而與五角大廈發生衝突。
Cursor 是一款程式碼編輯器，其中成熟的人工智慧模型充當了程式設計助理。 我們稍後會討論如何在Linux上安裝Cursor。
React 是一個用於建立動態圖形介面的函式庫。我對這個應用程式並不熟悉，所以無法判斷使用 React 是否合適，但根據我自己的 Vibe 編碼經驗，模型往往會使用函式庫來處理一些完全可以用純 HTML、CSS 和 JavaScript 實現的功能。
Karpathy 的問題開始變得複雜的地方在於後端部分。 他們的應用程式首先拍攝菜單照片，然後使用光學字元辨識技術搜尋每道菜的詳細資訊。讓我們來看看他們對整個過程的描述：
“問題就出在這裡。我需要調用 OpenAI API 對圖像中的選單項目進行 OCR 識別。我必須獲取 API 密鑰。還要瀏覽那些關於“項目”和詳細權限的略顯複雜的菜單。” Claude 對已棄用的 API、模型名稱以及最近更改的輸入/輸出約定感到驚訝。這確實令人困惑，但經過幾次複製貼上文件後最終解決了。 API 呼叫成功後，我立即遇到了非常嚴格的速率限制，每 10 分鐘只能進行幾次查詢。
這是模特兒慣用的伎倆——用大砲打蒼蠅——的典型例子。 選單圖像識別本可以使用像 Tesseract.js 這樣的本地庫來實現。
Tesseract.js 基於谷歌同名工具，支援 100 多種語言。它可以在瀏覽器中無縫使用，最重要的是，它不消耗令牌，不需要 API 金鑰，也沒有任何限制。
遺憾的是，對於使用已棄用的 API 和過時的文件而導致的幻覺，目前還沒有解決辦法。 除了學習程式設計和不使用自動化工具。
他在應用程式的第二部分也遇到了類似的問題：將每道菜的描述轉換為圖像。
“我註冊並取得了 Replicate API 金鑰，但遇到了類似的問題。查詢無法正常運作，因為 LLM 知識庫已過時，而且由於 API 最近進行了更改，這次就連官方文件也有些過時了。 它不再直接返回 JSON 數據，而是返回一個流式對象，我和 Claude 都無法完全理解。之後我又遇到了使用限制，這使得調試變得困難。後來我得知，這些是常見的反詐騙措施，但也使得創建合法的新帳戶變得更加困難。我還聽說 Replicate 正在遷移到預付費信用模式，這或許會有所幫助。
安德烈原本可以不用藉助影像產生器來解決這個問題。 有幾種工具可以搜尋菜餚的真實圖片（避免人工智慧可能造成的錯覺）。其中包括兩個食譜資料庫API：TheMealDB和Spoonacular Food API。
對我們這位氛圍程式設計師朋友來說，問題並沒有就此結束。 將應用程式上傳到 Vercel（一個允許從 GitHub 儲存庫部署和託管應用程式的平台）時，出現了本地未出現的錯誤。花了整整一個小時才意識到API金鑰沒有上傳到伺服器。經驗豐富的程式設計師應該早就知道這一點，從而省下這筆令牌費用。
作者的想法是收費使用這款應用程式（我很好奇誰會願意為一個可以透過詢問 Gemini 或 Siri 免費獲得的東西付費）。為此，他需要用戶身份驗證。在 Claude 的建議下，Karpathy 轉而使用另一個名為 Clerk 的雲端平台。 Clerk 負責處理註冊和存取所需的一切。我對這個決定沒有異議。
問題是 克勞德編寫了已棄用的 Clerk API 的程式碼，卻忘記告訴他，如果他想在生產環境中使用它，就需要擁有自己的網域。 不是Vercel提供的免費版本。他得自己購買和配置。
搭建支付平台時也遇到了一些問題。當他最終成功將平台上線後，他發現：
「所有處理都是實時進行的，沒有持久化存儲。如果耗時過長，就會失敗。如果刷新頁面，所有數據都會丟失。正確的解決方案應該是數據庫加上隊列系統。但這需要更多的服務（例如 Supabase、Upstash），更複雜的系統。太多了。我把它留到以後再考慮。」
其實，解決辦法要不是學習編程，就是聘請專業人士。下一篇文章，我們將開始探討如何學習程式設計。
