Andrej Karpathy為何說AI能力像鋸齒？vibe coding、RLVR與可驗證程式碼

Andrej Karpathy談AI時，最值得留下的重點在兩個實際提醒：模型可以在難題上表現驚人，也會在簡單問題上失手；AI能加快寫程式，卻不會替團隊承擔規格、測試與維護，而非預言口號。從vibe coding到RLVR，真正改變的是人和程式碼的分工。

2025年，大型語言模型開始更常被放進寫程式、研究、文件整理與產品原型的流程裡。這讓人很容易把幾個令人驚訝的展示，直接推論成「AI已經會思考」或「程式設計即將消失」。Karpathy的幾個說法之所以值得回看，正因為它們沒有要求我們把模型當成人，而是要求使用者承認：這是一種能力分布很不均勻、需要被安排在合適工作裡的新工具。

• 「鋸齒狀智力」描述的是模型能力不平均：它可能解出複雜問題，也可能在看似基礎的判斷上出錯。
• vibe coding降低了製作原型與一次性工具的門檻，但不等於把生產系統交給模型後就不必理解、測試或維護。
• 程式碼確實可能更常被快速生成、修改與丟棄；長期服務、金流、權限與安全相關系統仍需要可讀性、版本控制與責任歸屬。
• RLVR能在答案可被驗證的任務中提供訓練訊號，例如數學、程式測試或明確規則遊戲；它不保證模型因此獲得通用判斷力。
• AI協作時，人類的價值會更集中在定義問題、提供背景、驗證結果、處理例外與決定哪些錯誤不能接受。

先講結論：Andrej Karpathy談AI時，值得留下的重點在兩個實際提醒：模型可以在難題上表現驚人，也會在簡單問題上失手；AI能加快寫程式，卻不會替團隊承擔規格、測試與維護，而非預言口號。從vibe coding到RLVR，真正改變的是人和程式碼的分工。

這篇文章主要在談什麼？ Andrej Karpathy談AI時，值得留下的重點在兩個實際提醒：模型可以在難題上表現驚人，也會在簡單問題上失手；AI能加快寫程式，卻不會替團隊承擔規格、測試與維護，而非預言口號。從vibe coding到RLVR，真正改變的是人和程式碼的分工。

讀者首先要掌握哪個重點？ Andrej Karpathy談AI時，值得留下的重點在兩個實際提醒：模型可以在難題上表現驚人，也會在簡單問題上失手；AI能加快寫程式，卻不會替團隊承擔規格、測試與維護，而非預言口號。從vibe coding到RLVR，真正改變的是人和程式碼的分工。先抓住這個主軸，再閱讀後續細節。

標題中的關鍵對象有哪些？ Andrej Karpathy為何說AI能力像鋸齒？vibe coding、RLVR與可驗證程式碼；文中依此整理相關人物、作品、事件或概念。

本文整理了哪些背景或脈絡？ 文章從「Andrej Karpathy 鋸齒狀智力 vibe coding」出發，補上形成背景、發展脈絡與讀者最容易混淆的重點。

這個主題的核心差異或看點是什麼？ 核心看點在於把「Andrej Karpathy 鋸齒狀智力 vibe coding」放回具體例子與前後關係中比較，而不是只列出名詞。

讀者可以從文中得到哪些實用資訊？ 文中依序整理關鍵名詞、人物／作品或事件，以及相關時間、地點、規格或觀察角度；細節以本文段落與引用來源為準。

這篇內容適合哪些搜尋需求？ 適合想快速了解「Andrej Karpathy 鋸齒狀智力 vibe coding」定義、背景、差異與延伸脈絡的讀者。

閱讀與查證時應注意什麼？ 若涉及活動、票價、上映、產品或時程，資訊可能更新，請以文中列出的官方或原始來源最新公告核對。

一句話怎麼總結？ Andrej Karpathy談AI時，值得留下的重點在兩個實際提醒：模型可以在難題上表現驚人，也會在簡單問題上失手；AI能加快寫程式，卻不會替團隊承擔規格、測試與維護，而非預言口號。從vibe coding到RLVR，真正改變的是人和程式碼的分工。 YOLO LAB 將資訊整理成可快速理解與延伸查證的架構。

文章實體化：Andrej Karpathy為何說AI能力像鋸齒？vibe coding、RLVR與可驗證程式碼

本文以「Andrej Karpathy為何說AI能力像鋸齒？vibe coding、RLVR與可驗證程式碼」為主線，補回模型／工具、輸入輸出、版本、成本、測試與使用邊界，讓技術名詞回到可執行的工作流程。

• 核心元件：把標題中的模型、工具、格式、企業或協定對應到實際輸入、輸出與依賴。
• 驗證方法：記錄版本、資料、環境、基準、錯誤案例與人工檢查，避免只引用功能宣稱。
• 治理邊界：說明權限、資料保存、成本、失敗回復與何時需要人工介入。

涉及版本、價格、企業資料或 API 行為時，以文章原始資料與供應商／公司最新文件核對。

「鋸齒狀智力」提醒我們：會解難題，不代表每件事都可靠

人們很容易用單一分數或單次展示判斷AI到底「聰不聰明」。Karpathy提出的「鋸齒狀智力」（Jagged Intelligence）提供了更合適的視角：前沿模型可能在數學、程式、翻譯或特定知識任務上做得很強，卻又會在計數、常識、格式要求或細小條件上犯下令人意外的錯。

這種現象不只是模型還不夠大，也不是一句「它會幻覺」就能帶過。使用模型的人必須接受，能力不是沿著一條平滑的曲線增加。某些任務很適合交給AI，因為答案可以被快速檢查；有些任務一旦出錯就很難察覺，或牽涉價值判斷、法律責任、個人資料與真實風險，便不適合把模型當成最後決策者。

因此，最成熟的用法重點在問「這個任務的錯誤能不能被發現與修正」，而非問「模型有沒有比人聰明」。如果答案能用測試、資料比對、程式執行或人工複核確認，AI往往很有價值；如果錯誤會被包裝成流暢答案，又沒有可靠的驗證方法，就應提高人類介入的比例。

vibe coding改變的是工作分工，不是把程式責任交給模型

Karpathy在2025年提出vibe coding一詞，用來描述一種高度依賴自然語言指令與AI生成程式碼的寫法。使用者不必逐行手寫，而是先說明想做什麼，觀察結果，再要求模型修正。這種方式特別適合快速原型、資料整理、個人小工具、一次性分析頁面，或還在探索需求的產品早期階段。

它帶來的改變很實際：會描述問題的人，能更快把想法做成可操作的東西；工程師也能把部分重複工作交給代理工具，將時間放在架構、測試與例外處理。但vibe coding不等於「不需要懂程式」。當AI產生的程式進入付款、帳號、資料庫、醫療、內部權限或對外服務，問題就不再只是畫面能不能跑，而是程式是否安全、能否追查、出了錯誰能修。

研究者對vibe coding的觀察也支持這種區分。開發者會在提示、檢查結果、手動修改與再請模型修正之間反覆切換；AI沒有讓工程判斷消失，而是把工作重心推向需求釐清、快速驗證與何時不該相信模型的判斷。把生成程式碼視為第一版草稿，比把它視為不需審閱的最終產品，更符合實務。

程式碼可以更短命，產品責任不會因此消失

Karpathy在年末回顧裡談到，AI生成的程式可能更「短命」、更容易修改，也更可能在一次任務完成後就被放棄。這個判斷用在個人腳本、臨時儀表板、活動頁面或原型時相當合理：生成成本變低後，不必每個小工具都被當成要維護十年的資產。

但短命程式碼有清楚的邊界。只要一段程式開始碰觸真實使用者、持續資料、金流、個資、帳號權限或公司營運，它就不再只是用完即丟的工具。此時可讀性、測試覆蓋、監控、紀錄、版本控制與安全審查，仍是產品責任的一部分。AI讓寫出第一版更容易，卻也可能讓未經驗證的程式更快進入不該進入的地方。

較健康的做法是先替程式分類。一次性使用、可隔離、錯誤成本低的工具，可以採取較快的生成與試錯；需要長期維運或高可靠性的系統，則應保留明確工程流程。把兩種工作混在同一套標準裡，通常不是太慢，就是太危險。

RLVR有用的前提，是「對錯」真的能被驗證

RLVR是Reinforcement Learning with Verifiable Rewards的縮寫，指在模型輸出能被明確驗證的情境裡，利用獎勵訊號進行強化學習。數學題有標準答案、程式能跑單元測試、棋類或規則任務有清楚的輸贏條件，都是相對適合的情境。模型可以嘗試多條路徑，再從結果知道哪些方向較有效。

這類訓練方法對推理能力的進展很重要，但它不該被翻譯成「模型已經學會像人一樣思考」。可驗證任務之所以有效，正是因為環境能提供清楚回饋；到了需求模糊、資料不完整、答案涉及倫理或偏好、成功標準由人協商的工作裡，獎勵訊號很難同樣乾淨。近期研究也顯示，RLVR在不同任務與基礎能力條件下的泛化效果並不一致。

對產品與工程團隊而言，最實際的啟示是：先把可驗證的部分交給模型。讓AI產生測試案例、比對資料格式、執行重複性檢查、草擬程式或整理已知規則，通常比叫它獨自替公司做策略判斷更可靠。AI的價值不只在回答，而在於它能否被放進一個讓錯誤容易露出的流程。

從「寫程式」到「安排驗證」：人類工作正移往上下文與責任

AI協作不會讓程式設計只剩下下指令。反而因為生成速度變快，前後兩端的重要性更高。前端是上下文：你能否把目標、限制、資料格式、既有架構與不可碰觸的規則說清楚；後端是驗證：你能否判斷輸出是否正確、是否安全、是否符合使用者真正需求。

這也解釋了為什麼經驗不一定會被AI消除。熟悉系統的人知道哪些欄位不能覆寫、哪些資料不能外傳、哪些看似合理的修改會破壞舊流程；這些知識未必會完整寫在提示詞裡，卻決定了生成內容能不能被安全使用。AI可以擴大個人的執行能力，但不能自動取得組織多年累積的責任邊界。

不同工作，應該用不同程度的AI協作

• 探索與原型：可把AI當成快速搭建者。重點放在是否能更快看見想法，而不是一開始就追求完美架構。
• 資料與內容整理：可讓AI做初步分類、摘要與格式轉換，但要保留來源、版本與人工抽查。
• 正式產品功能：需要規格、測試、程式審查、權限設計與監控。AI可以協助，不能跳過流程。
• 高風險決策：涉及法律、財務、健康、安全或人事時，模型的建議應被視為輸入之一，不能取代可追責的判斷。

對台灣團隊來說，最重要的不是追上每個AI名詞

台灣團隊現在最常見的兩種極端，一種是把AI當成展示用的聊天功能，另一種是急著把每一段流程都交給代理。Karpathy的討論提供了比較務實的第三條路：先辨認哪裡可以被驗證、哪裡錯了能回復、哪裡需要人類承擔責任，再決定AI介入多深。

真正有競爭力的團隊，不會只比誰接了更多模型，而是比誰更清楚自己的資料、流程與例外情況。當AI能快速做出十個方案時，關鍵就變成團隊能否快速淘汰九個錯的方案，並知道最後一個是否值得被放進真實世界。

讀者常問

Andrej Karpathy所說的「鋸齒狀智力」是什麼？

它指的是大型語言模型的能力分布不平均：模型可能完成高難度數學或程式任務，也可能在簡單計數、常識或條件理解上失手。使用時應依任務是否能被驗證來安排人類審查，而非只看模型整體看起來有多聰明。

vibe coding是什麼？

vibe coding是以自然語言指示AI產生程式，再透過觀察、測試與反覆要求修正來完成工作的方式。它適合快速原型、一次性工具與探索需求；若程式要長期服務使用者，仍需要理解架構、測試與維護責任。

AI生成程式碼可以直接上線嗎？

不應把「能跑」當成「可以上線」。只要程式處理個資、帳號、付款、權限或長期資料，就應經過測試、程式審查、安全檢查與監控。AI產生的內容可加速第一版，但責任仍由發布它的人與團隊承擔。

RLVR和一般強化學習有什麼不同？

RLVR強調使用可明確驗證的獎勵，例如數學答案對錯、程式測試是否通過或規則任務是否完成。它在回饋清楚的任務裡特別有用，但不代表模型在模糊、主觀或高風險問題上就能自行做出可靠判斷。

資料來源與延伸閱讀

• Andrej Karpathy：vibe coding原始貼文
• Andrej Karpathy：2025 LLM Year in Review
• Vox：推理模型與「鋸齒狀智力」
• 研究論文：Vibe coding: programming through conversation with artificial intelligence
• 更多AI與科技解析

把 Karpathy 的提醒放回可執行的工程流程

Andrej Karpathy 在官方 X 貼文中提出「vibe coding」與對模型能力不均的觀察；另一篇 2025 年回顧則談到 jagged intelligence、RLVR 與程式碼工作方式的變化。這些原始貼文適合用來核對概念來源，但不應被讀成「AI 已經可以獨立承擔所有工程責任」。更精確的問題是：哪些任務可以快速生成，哪些結果能被驗證，哪些錯誤又必須由人類在發布前攔下。

本文原有的技術分析可再加上一個實務分層：把 AI 產生的程式視為候選實作，把測試、資料比對、權限檢查和回滾視為交付流程。這樣既保留 vibe coding 對原型速度的價值，也不會把「看起來能跑」誤認成「可以安全長期維護」。

「鋸齒狀智力」的工程含義，是設計錯誤會露出的流程

如果模型在複雜程式問題上表現很好，卻在格式、邊界條件或簡單計數上失手，最佳回應不是再問一次「它到底聰不聰明」，而是讓任務本身具備可觀察的檢查點。輸出先通過 schema、型別、單元測試、快照比對或人工抽查，再進入下一步；沒有驗證方法的流暢答案，就不能直接進入正式資料或服務。

這種設計也能降低團隊對單一模型的依賴。當錯誤可以被測試捕捉，模型可以快速提出多個方案；當錯誤只能在真實使用者身上暴露，則需要更小的發布範圍、清楚的監控與可回復版本。能力不平均並不代表 AI 沒有價值，而是代表流程不能把所有風險押在一次生成上。

RLVR 能處理清楚的回饋，不能替代模糊的責任判斷

RLVR 的重點是可驗證獎勵：數學答案是否正確、程式測試是否通過、規則任務是否完成，都能提供相對明確的回饋。這使模型在某些推理與程式任務上更容易獲得改善。但產品需求、法律風險、使用者感受與組織優先順序，往往沒有一個單一且客觀的答案，不能把 RLVR 的成功直接外推成通用可靠性。

因此，團隊可以先把「可驗證部分」交給模型，把「不可逆或高風險部分」保留給人類。AI 可以產生測試、整理失敗案例、比較輸出或提出修正；人類仍需決定什麼錯誤不能接受，以及是否有足夠證據讓變更進入正式環境。

一次性程式與長期服務，應採用不同標準

快速腳本、臨時分析頁和探索性原型可以接受較短的生命週期，前提是它們被隔離、資料範圍有限，錯誤成本也能被控制。付款、帳號、權限、個資、資料庫和持續營運服務則不同：即使第一版由 AI 生成，也需要版本控制、測試、審查、監控、紀錄與回滾。程式碼可以短命，責任不能短命。

這是 vibe coding 最值得保留的界線。它讓更多人能把想法變成可操作原型，也讓工程師減少重複輸入；但一旦原型開始被真實使用者依賴，團隊就必須重新分類它的風險，補上可讀性、測試與維護流程。生成速度不是交付標準，能否被驗證與修復才是。

一個可實作的 AI 協作檢查表

1. 先寫清楚輸入、輸出、限制、資料來源與不能觸碰的欄位。
2. 要求模型先說明假設，再生成最小可驗證版本。
3. 用測試、執行結果、schema 或人工比對檢查輸出，不只看語氣是否流暢。
4. 將一次性工具與長期服務分開，依資料、權限和錯誤成本調整審查強度。
5. 保留版本、變更原因與回滾路徑，讓團隊能在模型出錯時追查責任。

資料來源：Andrej Karpathy 官方 vibe coding 貼文、Andrej Karpathy 官方 2025 LLM 回顧。官方貼文用於核對概念來源；本文對驗證流程、風險分層與工程責任的部分屬於編輯分析。

延伸閱讀：AI 能寫出一段程式，不代表它理解整個系統

「鋸齒狀能力」最值得注意的地方，是模型可能在某個局部任務表現很好，卻在相鄰的推理、除錯、需求理解或邊界條件上突然失準。vibe coding 因此不應被理解成完全放手，而是把自然語言生成放進有測試、有版本控制、可回退的工程流程。

可驗證程式碼的重點，也不只是讓模型產出更多檔案，而是讓人能快速知道它做了什麼、哪裡可能錯、如何重現結果。使用 AI 寫程式時，最重要的能力不是相信或拒絕模型，而是把任務拆小、建立檢查點，並保留對安全、資料與長期維護的責任。

增量：AI 能力像鋸齒，產品設計就要接受不均勻可靠

「鋸齒狀能力」提醒我們，模型可能在某類推理、程式碼或工具操作上很強，卻在相鄰任務突然失手。vibe coding、RLVR 與可驗證程式碼的共同問題，是如何把模糊創意轉成可測試的中間結果與驗收條件。

• 拆任務：把大目標拆成小步驟，每步都留下輸入、輸出與可驗證狀態。
• 驗證：用測試、型別檢查、執行結果與人工審查交叉確認，不把流暢文字當成正確性。
• 邊界：標出模型在哪些任務不可靠，讓人類接手成為設計，而不是臨時補洞。

這個框架能讓 vibe coding 保留探索速度，同時把程式碼品質、權限與回歸測試放回工程流程；真正的效率是少返工，而不只是更快產生第一版。