Vibe Coding：AI 編程時代的認知重構

如果像看其他雜書一樣看完書評再來確定值不值的去看，那我就錯過了。 很多書友覺得這本書說的太空，沒有實操，但正如作者說的，如果是看“術”的，不會去看書，書的時效性太差，網上的文章視頻纔是真正的打開方式，vibe coding用一日千里來說都不過分，我作爲每天的重度用戶，深有同感，我正是帶着想探究vibe coding的代際迭代的底層邏輯的想法在找書的。閱讀本書的過程頗有點之前讀《浪潮之巔》《芯片戰爭》等科技史書之感，對於才幾年的一個概念，卻已像歷經滄桑 作者作爲這項技術的參與者，使用者，其中的感悟自然是要比我這種只是使用的人更多的多，帶着這種想法翻了這書，以前面說到的這項技術的發展速度，這書也是得趁熱翻，涼了效果可能就打折了，外面可能已經換了天地 在書中很多點都會與內容產生共鳴，比如由此產生的產業人才結構的變化等 讀着讀着，就會開小差，比如現在與ai協同寫代碼，就像自己剛成爲一名小組長時候帶着小夥伴寫，爲了不至於失控，至少我是把框架整好，然後就看各自發揮，如果時間不允許就只能從結果上去看是否符合預期了。再後來，就要管理一個研發團隊，這時候拆分的就不是某個需求的任務了，而是整個技術線，這不正是多agent方式嗎。以後考驗ai協同能力，對人的要求就拔升到leader層面了。類似的小差其實蠻多，想了蠻多 一直看書都不寫書評，但還是希望對這個概念感興趣的書友們，不要錯過一本還行的書，可以翻翻

說實話，這本書不行。 爲啥這樣說呢，我看你這本書就是想要了解vibe coding的原理和實踐的，要學習vibe coding的。 但是整本書下來不斷的講原理和理論還有方法，連一個具體實踐案例都沒有。 vibe coding作爲一個新生事物，還在不斷的發展過程中，你說你進行很系統的理論研究並作爲指導，這是一件不太現實的問題。 但是這本書就想做這件事，因此書中反覆講理論，做論證，做預測，和傳統的編程邏輯對比。而且同樣的內容反覆出現，並做了vibe coding的影響，對社會，個人充滿了人文關懷等等。 但最重要的，教會你的讀者使用vibe coding這個最重要的事情，你沒有做到，甚至做的很差，一個具體案例和實踐沒有。 所以我評價本書是本末倒置的典型。

《Vibe Coding》並非一本教你如何寫代碼的“術”書，而是一本教你如何“不寫代碼”的“道”書。作者以其在阿里雲通義靈碼的實戰經驗，精準預言了AI編程時代的核心悖論：代碼越寫越少，但工程思維必須越來越深。 書中指出，當AI能秒級生成代碼時，程序員的核心競爭力已從“編碼能力”轉向“代碼品位”與“技術責任感”。真正的Vibe Coding不是隨意“瞎聊”，而是在嚴謹的Spec（規範）與隨性的Vibe（氛圍）之間找到平衡，讓AI成爲你大腦的“外掛”，而非簡單的“打字員”。這本書最大的啓發在於：AI時代，最稀缺的不是會寫代碼的人，而是能駕馭AI、定義架構的“系統設計師”。

代碼設計或優化原則： 1. 確保代碼的可維護性和可擴展性。 2. 避免代碼重複。 3. 保持簡單和直接。 4. 拒絕過度設計。 模型的上下文窗口大小包括輸入和輸出，要使模型正常地使用，需要爲輸出預留token數量。 精確表達需求的能力，無論是對人還是對AI，都是開發者的核心技能，只是在 Vibe Coding 時代更加重要和關鍵。從提示詞工程到上下文工程，與模型的協作溝通能力，直接決定了我們能否適應AI時代的軟件工程研發。 Context engineering is the delicate art and science of filling the context window with just the right information for the next step. --Andrej Karpathy AI本質上是基於上下文理解生成高概率token序列的工具，而操作它的人類纔是應該對AI生成質量負主要責任的主體。 AI 的真正價值不在於模仿人類，而在於憑藉自身的超人類特質，成爲人類的高效協作夥伴。 Vibe Coding 核心是 Coding 的能力和 Vibe 的心態。 經驗豐富的工程師往往推崇奧卡姆剃刀原則：如無必要，勿增實體。 AI Coding 時不要玩手機！！！並不是勞逸結合不好，而是我們要保持在線的狀態。 TDD（測試驅動開發）：先寫測試，再寫實現代碼，遵循"紅→綠→重構"循環。 PDCA 工作流：持續改進循環模型——Plan（計劃）→ Do（執行）→ Check（檢查）→ Act（處理）。 BMad 工作流：基於多 AI Agent 角色（產品經理、架構師、開發者等）協作完成軟件開發的框架。 ANP 協議：AI Agent 間通信協作的網絡協議，用於 Agent 發現、信息交換和任務協調。 A2A 協議：Google 提出的 Agent 間互操作協議，讓不同廠商的 Agent 能無縫協作。 flake8：Python 代碼風格與邏輯錯誤檢查工具（整合 PyFlakes + pycodestyle + McCabe）。 mypy：Python 靜態類型檢查工具，通過類型註解在運行前發現類型錯誤。 bandit：Python 安全漏洞靜態分析工具，掃描危險函數、硬編碼密碼等安全問題。 pytest：Python 最流行的測試框架，語法簡潔，插件生態豐富。 投機解碼：用小模型快速生成候選 token，大模型並行驗證，加速 LLM 推理。 search-replace：AI 編程中只輸出"搜索-替換"指令來修改代碼，減少 token 消耗、降低出錯率。

總體評價“空洞”，不具備相應的價值核心，跟記流水賬一樣，我從兩個方面說下感受。 一是實踐。這本書沒有任何實踐例子，甚至連作者自身使用vibe coding時具體案例也沒有，閱讀起來就跟觀衆在臺下看演員自顧自擺動作，很難有什麼聯繫。雖說作者反覆強調本書沒有例子，可對於軟件工程來說，很多技術本就基於某些概念組合而成，同樣vibe coding也同樣能以一個實際項目去作爲概念論證纔對，操作步驟中的問題與思考纔是具有價值的部分。 二是理論。理論屬於網上普遍流傳的一套，對於有過技術落地到實際業務中的人都能輕鬆感受，而作者也只是泛泛而談，沒有提煉出自身的觀點去做出核心表達，也可能是作者本人就在這波漩渦之中難以抽離思維去理解。同樣ai屬於新事物，對於未知不敢去描述是人之常情，但讀到後面全都是湊字數的猜想，都不與實際生活的能源、領域、基礎設施等一同去考慮，在知識面上顯得狹隘。 整本書屬於，有技術落地經驗或者實際vibe coding過的人不用看，書中內容在日常刷論壇和項目過程中都能體會；好奇ai技術的小白看了也等於沒看，整體概念缺少實際支點忘的很快，不如直接跟着網上教學視頻實操印象更深。

AI的發展正在改變程序員的編程方式，在面對Vibe Coding時代，程序員的核心能力不再是單純的代碼編寫，更加側重於一下三點： 1.需求拆解能力：將模糊的商業想法轉化爲清晰、AI可執行的"產品需求提示詞"（PRP） 。 2.產品審美與系統思維：具備理解用戶需求與業務場景的能力，而非僅關注技術實現細節 。 3.結果校驗能力：能夠快速評估AI生成方案的優劣，關注需求本質而非固定實現路徑

AI對編程領域的影響是革命性的，不單單是工作方法的改變、工作效率的提升，更是對編程的認知產生顛覆性的變化。Vibe Coding 概念上不復雜，關注這方面的人主要還是希望更好的用好工具。本書的寫作角度是蠻高級的，但要有耐心閱讀下去並不容易。

從最開始的機器語言，到彙編語言，到高級語言C語言，到JAVA、Python編程語言，其發展都是越來越符合人的使用習慣，直到現在Vibe Coding，僅憑自然語言描述需求就能生成代碼。這一路非常符合人的使用的發展過程。 Vibe Coding依託人工智能，大幅降低了編程門檻，讓編程不再是專業人士的專屬技能，極大提升了開發效率。但與此同時，我更加堅信：AI只是高效的編程工具，唯有知其所以然，深耕計算機底層知識、建立核心編程思維，才能真正掌握編程能力。 很多人藉助Vibe Coding完成編程任務，卻完全不懂代碼底層邏輯、運行原理和漏洞成因，只會機械套用AI代碼。這種沒有底層認知的編程方式，只能應對簡單固定的場景。一旦遇到程序報錯、場景適配異常、複雜邏輯優化等問題，使用者便會束手無策。我們要主動鑽研底層知識、錘鍊編程思維，用紮實的技術功底駕馭AI工具，而非被動依賴工具。 技術工具不斷迭代，但計算機底層邏輯與核心思維永恆不變。Vibe Coding重構了編程形式，卻沒有改變“知其所以然”的技術本質。未來，唯有深耕底層、拒絕淺層依賴、以思維駕馭工具，才能在AI編程時代實現真正的技術成長，站穩技術根基。

這是一本抽象的書，所謂抽象就是脫離具體情境，萃取出事物核心共性特徵的過程。脫離情境就讓很多人產生抗拒了，因爲沒有具體案例學習理論是很違背認知規律的，首先認知負荷太大，無法將理論和已有經驗聯繫起來，無法形成組塊，工作記憶容量很快耗盡，人就迷糊了，進而放棄閱讀。比如你的背景知識中沒有軟件工程的概念，那麼讀到瀑布模型，讀到敏捷開發，讀到測試驅動開發（TDD） 就會雲裏霧裏。在再如你沒有過實際使用 AI 編程工具的經驗，你也很難感受到作者所說的 vibe coding 中的真正痛點：如何讓 AI 在一個真實的項目中發揮作用，而不是從 0 到 1 單輪對話做出一個看似牛逼的玩具。作者真正在意的是如何讓 AI 完成從 1 到100 在真實項目中的落地。所以很多通過書名找書想要快速入門 VibeCoding 的讀者可能有點失望了！ 但爲什麼作者要把這本書寫得這麼抽象呢？其實從面向對象的角度來看，抽象的目的就是用更通用的接口去適配更廣泛的場景。作者將講 VibeCoding 的方法論，因爲這些方法論是從各種 VibeCoding 工具、案例、經驗、技巧抽象而來的，可以應用於 VibeCoding 的各種場景。因爲 VibeCoding 甚至於在更大範疇 Harnees Engineering 中時效性作爲一個關鍵變量讓我們不得不通過抽象來應對這種從過眼雲煙般轉瞬即逝的時間軸上抓取值得沉澱下來的精髓。 那麼 VibeCoding 到底是什麼？氛圍編程？個人的一句話總結就是：用嘴編程！當然打字也算。 學習 VibeCoding 需要具備哪些能力？會說話就行，這是入門門檻，別以爲這很簡單，其實會說話也是一門技術活，如何讓你說的話 AI 聽得懂，還能遵照執行，而且還要剛好滿足你的需求。這就不是技術了，而是藝術！ 說話的技術首先體現在你要懂你說的話的意思，其次你還要知道你說的話 AI 能不能聽得懂？所以其實這是一個雙向奔赴的過程。這個過程中一方面大模型越來越聰明，越來越懂你，另一方面作爲人類的你也要不斷學習，才能說出高質量的話。 作爲人類應該學什麼？作者建議是全棧工程師，前端、後端、數據庫、運維、測試、產品、營銷、UI 等等 本書中作者偶有的金句引用，博古通今，很有文化底蘊。 部分段落 AI 味較濃。 關於 Vibecoding 的未來，不確定性的本質是不可預測的，所以看看就好，但如果無法壓抑對確定性的偏好，一定要做點什麼，心理纔會舒服的話遵照執行也無妨！ 一句話推薦：本書適合有 Vibe coding 經驗的讀者作爲沉澱方法論的讀物！

用 Claude Code 已經有一段時間了，"vibe coding" 這個詞也反覆聽到，但一直沒弄清楚它具體指什麼。於是找來這本書，想系統地瞭解一下。讀完之後，真正留在腦子裏的倒不是 vibe coding 的定義本身，而是作者引出的兩個問題：設計模式還有沒有存在的必要，以及工程師這個職業還能走多遠。 ➡️設計模式，是爲人腦的侷限而生的 作者對軟件工程的理解很深——不只停留在編碼層面，而是看到了編程的本質：用軟件工程的方式解決現實問題。書中有個觀點讓我印象很深：軟件工程領域沉澱下來的設計模式，本質上是人類自身侷限性的產物。人腦能處理的複雜度有限，"上下文窗口"也非常小，設計模式正是爲了彌補這些短板才被髮明出來的。 這就引出一個值得琢磨的問題：如果未來的軟件都由模型來理解、由模型來維護，這些專爲人類量身定製的設計模式，還有必要遵循嗎？我覺得這裏確實要打一個問號。 ➡️上下文工程，解決的是模型的"暫時性缺陷" 作者在書的結尾提出一個判斷：99% 的程序員會失業。對此我深有同感。 我最近在做一個 agent 項目，核心就是上下文工程。但如果追問一句——上下文工程到底在解決什麼問題？答案其實是模型自身的缺陷：目前上下文最高只有 1M 的限制。這個限制主要來自兩個方面：一是 1M 上下文背後對應的 KV cache 高達幾十到幾百 GB；二是上下文過長之後，模型很難從海量信息中準確定位真正需要的內容。 假如有一天模型的上下文達到 500M，上下文工程幾乎就不再被需要了——團隊的全部信息可以一次性交給大模型，只有實時數據才需要通過外部接口獲取。換句話說，今天我們精心構建的這一整套東西，解決的可能只是一個過渡期的問題。 ➡️當限制被突破，高級工程師還剩下什麼 按我目前的理解，高級工程師的核心價值在於架構決策、技術選型和方案設計。我平時工作中，這些事情往往需要和模型反覆對話才能敲定；有時模型堅持錯誤的方向，還得由我來拍板。但仔細想想，很多時候並不是模型沒有能力理解，而只是它的上下文有限，缺乏足夠的環境信息。 Claude Code 和 Cursor 的出現，已經能夠頂替初級工程師了。等到上下文的限制被突破、模型能力進一步進化，高級工程師大概率也會被頂替。作者說 99% 的程序員會失業，讀之前我可能會覺得誇張，讀完再對照自己每天的工作，反而覺得這個判斷並不遙遠。