※ 引述《bxc (機率遊戲)》之銘言：
: 如題 軟體失業是遲早的事吧
: ㄧ堆都在流行vibe coding
: 最近都在玩這個
: 原本的技能樹不是前後端 有點概念而已
: 要弄個sample真的很快
: https://i.imgur.com/wVeBdCK.jpeg
先來定義什麼是vibe coding
Karpathy described it as "fully giving in to the vibes, embracing
exponentials, and forgetting that the code even exists".
"完全沉浸在氛圍中，擁抱指數級成長，甚至忘記程式碼的存在"
Wiki中的描述為:
Unlike traditional AI-assisted coding or pair programming, the human
developer avoids micromanaging the code, accepts AI-suggested completions
liberally, and focuses more on iterative experimentation than code
correctness or structure.
我自己透過七天的實驗，分享一下個人的心得。
# 注重迭代而非規格
我不贊同AI開發時所謂"規格"驅動開發，也就是先寫完整套規格，再請AI開發的模式
理由主要有兩個：
1. AI內部的接力機制，假如一個AI 99%正確，迭代22次後會變成80%
2. 即使AI能夠連續工作N小時最後完成整套規格，但若是涉及UI/UX相關的，會有許多
需要手動測試的地方
所以我認為Wiki對Vibe Coding的"重視迭代實驗"的敘述，是比較符合現實場景的。
# 個人方法
1. 要求AI建立單元與整合測試，UI/UX方面的手動測試則由我負責
2. 針對epic任務，讓AI自行建立文件紀錄說明與更新進度
3. 以我不親自更改程式碼為首要原則
4. 每次任務結束時都需要確保測試完全通過，並且通過我手動測試功能
5. 每一個階段都要進行lint與移除程式碼中的legacy code
# 歷程
雖然說一開始體驗確實是不錯，但我認為當產品迭代到某個階段時，會開始產生痛點
一般迭代的流程如下：
POC -> 逐步增加feature -> MVP -> feature的增減與規格變更 -> 實作
POC到MVP這段，是目前AI的強項，特別是POC；沙士比亞後再無新故事，軟體開發方
面其實99%的人都在做重複的事，只是不同的數據、不同的組合而已
所以AI對我來說，能夠非常快看到可以操作的POC，並且快速迭代到MVP
但在MVP後，軟體需要進入打磨與增減的階段，這時AI的問題就特別明顯
1. AI在每個Task結束後對他來說又是新的開始，所以之前的細節他不一定會記得
這導致AI的產出經常缺乏一致性，或是AI的注意力放在新功能的實現而忘記codebase
可能存在相應的模組可以承擔部分職責，解決方法：
a. 新增記憶 (但記憶過多無效)
b. 你必須主動提示AI必須參考哪些module或文件
2. AI會把達成任務放在首要需求，意味著AI會不擇手段並選擇阻力最小的途徑來
完成你的指示。這導致許多class過於臃腫，或function承擔了他原本不應該承
擔的職責，甚至是不停累積的legacy程式碼。而這些legacy的程式碼又會成為干
擾AI上下文的主因之一。
解決方法：
a. 指定AI建立特定的class並說明其職責
b. 在指示階段直接指導重構的方法
3. 靜默錯誤。 AI會為了確保程式碼能夠"成功"執行而非"正確"執行，經常會過度
地使用預設值、hardcode的數值作為回傳值，這導致一些層層包裝的模組在傳遞
數值時又會過度累積大量的hardcode數值，使得底層模組出現真正異常時往往無
法察覺
講到這裡，大家應該會發現，這些問題與問題的解決方法，都涉及程式碼的結構與正
確性。那若是放任這些問題不管，是否可行？也就是說「如果我們完全忘記程式碼」
這些問題是否可忽略，或是說程式碼根本一點都不重要
很多公司的程式碼也是爛到爆，說白了AI寫的程式碼可能還是某些公司的上限，那這
些公司還不是錢照賺、功能照加？但我沒有這個勇氣嘗試，因為token的帳是算在我身
上
我看到網路上有些文章，確實會將設計模式、程式碼的設計準則一併加入prompt中，但
這仍然是一種關注程式碼結構與正確性的行為之一。所以，vibe coding目前「忘記程式
碼的存在」、「不用再管程式碼的結構與正確性」這樣的體驗至少我自己還無法感受到
有些公司codebase爛，可是講的是一個產業know how、講的是一個本多忠勝，反正bug
硬幹、產品能跑就好，有潔癖的工程師要走請便，反正多的是其他工程師。
現在這些公司確實是有可能用轉蛋的方式砸token砸出一個可以run又不會被用戶弄出bug
賠錢的產品 (反正價格錯誤再反過來告消費者就好)
軟體開發就跟AV女優一樣，像我就覺得臉蛋漂亮很重要，奶小沒關係，像希島愛里這樣
有人就覺得奶大很重要、假奶沒關係，但一定要奶大，像楪可憐這樣
也有人堅持一定要真奶、不要人造人，這種人去看楪可憐就只會看到楪可憐的缺點
祝大家在喜歡的女優引退後都能找到自己喜歡的新人女優

最屌的還是看到開始有人做出了 H 奶 30kg，一邊單眼皮一邊雙眼皮，然後說因為看習慣 30cm，所以也要加上 30cm，變成一個每個細節都很屌，但整體不知道到底在幹嘛

前面一堆叫罵聲勢浩大認真討論的文卻乏人問津好啦話說回來，我同意這篇文的部分觀點會出現很多冗餘的參數跟沒必要的流程

完全不管code太理想 但不追求什麼良好設計這種方法倒是堪用了

我自己也認為「AI要好維護前提是人也好維護」畢竟正如大家的觀察 Context大小就是很現實的技術極限

結論很讚

設計差 效能爛 實務上的確不是最重要的，能符合需求的產出才是真正有價值的地方

看起來不如自己寫比較快...

剛剛試了vibe coding，連最簡單的outlook 2007 pop3同步刪掉Gmail的信件都在胡說八道，浪費我的時間，這是怎麼vibe coding啦話說有人懂嗎？我Gmail已經爆了,現在來跟你們vibe coding可能比較靠譜感覺vibe coding這詞跟敏捷這詞一樣是個唬爛的同意詞

蠻贊同這篇的過程跟感想的 對於有生命期的產品vibe codin終究會帶來不可承受的負擔 更別說要規格業務邏輯的一致性不過有人說要換個想法 對於每次功能的變動 乾脆直接重新全部重頭產生程式碼 這也不大合理 最多只能部分codebase讓AI完全重新產生碼出來 但是就我的實際經驗連個稍微長一點的演算法或是處理程序 都沒辦法一次'功能'到位 覺得vibe coding只能用在小型專案上面 我現在也只是拿來產生script跟很簡單的工作上的資料pipeline

vibe coding這詞也才出來半年多 當然現主時沒辦法完全不看code很正常R 你給他再5年試試看中大型專案隨著context window越來越大 遲早能整個吞下去

Llm目前就是當外部顧問 臨時工用 他沒辦法了解專案或團隊文化等等隱性知識 就像請一個外部技術專家來 也不可能三言兩語就上手完成任務 所以別期待AI可以幫你完成一切理想情況是在請他做事時一邊建立文件 建立測試 把隱形知識轉成顯性 但這就像帶新人一樣 短期沒回報 長期也不一定利己 最後說不定是讓自己失業

多少還是需要祖傳md

推！很贊同這篇的過程和想法 最近剛好也一直在玩這塊目前在想透過micro service+DDD開發手法，每個領域都用repository切開，減少AI每次需要學習和需要記憶的量目前是每個repository底下都放一個md在試試看～請問大大是用claude還是gemini啊？

YT搜尋Claude就好，已經開始有一堆人講解怎麼用。我用起來效率乘十倍不誇張

十倍 哈哈哈 你三天就做完以前一個月的專案進度了嗎還是寫扣的速度快了十倍但寫扣只佔工作的一小部分 其實整體產出根本也沒提升多少 同時每天大量review AI的產出還消耗了不少腦力導致整體產出倒退

十倍是扯了點 那丟給你五人份的工作你應該非常輕鬆還可以偷懶囉?

已經很多人發現使用AI反而造成整體產出下降 你越仰賴 vibe coding 你對專案程式碼的熟悉度就會越來越低 甚至你不會記得最近三天新加入的函數有哪些 你會感覺有個公用函數好像之前才寫過但你不確定放在哪個檔案 你跟AI一樣有失憶現象最後造成專案裡類似功能的函數到處都是

cursor+gpt5+大量project rules+FP應該算是目前vibe coding的最頂級combo，便宜好用又不會亂寫

Claude現在還可以幫你執行命令，看build error，下gdb，callstack直接看，log印成檔案後直接看檔案，確實不太需要review AI產生的代碼了。真要review再新開一個task叫AI review要預防失憶現象，要寫MD檔，甚至AI改完code後可以叫他改寫MD檔兩邊align

推實驗精神

「類似功能的函數到處都是」 這是一個很大的問題嗎？如果不影響專案進行，這問題根本沒差。利大於弊，除非嵌入式斤斤計較空間，但嵌入式通常repo不會很大，AI更容易處理

可以在研究一下context engineering，啟用一個agent去審有模板貨文檔，也不會有風格偏差太大的問題

要寫README.md，寫了就不太會失憶了https://youtu.be/sOvi9Iu1Dq8?si=ajHBx8JZe-eLYZ7_

其實你這樣的需求也不明確 也沒定義清楚 雖然說中大型 要多大才叫中大型？ 現在小型專案確實已經可以完全不看程式碼完成整個產品 但小型是多小型？會不會過陣子 其實已經可

十倍當然不誇張啊，原本一小時才能解完的bug，五分鐘AI就解完了？那不就十倍？

以做到完全不看程式碼開發一整個電商系統 但又會抱怨電商根本就中小型專案 難道AI能讓我Vibe Coding出google搜尋引擎或整個臉書嗎？我覺得喇 怎麼樣都可以打臉的理由 沒有討論的價值等到哪天真的能vibe出一個搜尋引擎 又會說 啊是能讓我vibe出一個ChatGPT嗎？如果不定義標準 AI永遠不可能滿足

AI都拿了諾貝爾化學獎和數奧金牌了，寫程式真的小菜一碟

專案的性質也差很多 vibe一個部落格 跟vibe一個3D遊戲引擎或跟vibe一個給客戶用的SDK 是完全不一樣的事 每一種類型也都可大可小 不定義清楚很難說vibe沒什麼用實際上我就親身遇過業主沒有任何背景程式 vibe出一個演算法系統來幫忙處理公司內數據 他一行程式碼都看不懂 程式碼也沒給任何工程師審查過 就他自己做的工具 但運作非常好

看不懂沒差啦，llm的開發人員也說過他們也看不懂現在llm的程式碼了

整個系統大概一萬多行 這算大 還是小

https://i.imgur.com/JTbzC9p.jpegAI開發者自己對AI模型都無法掌握了，看不懂正常

不可解釋性以及深度學習領域很多新方法難以解釋，這跟你做資訊系統但不懂其中的程式碼那是完全兩回事vibe coding 在你只需要一個蛋糕的時候沒有任何問題，他是一個蛋糕而且還不錯，當你的客戶說我的蛋糕這邊那邊一定要如何如何的時候，就開始有問題了

其實我看不懂你的蛋糕比喻XD「這邊一定要如何如何」這對AI來說很難嗎？

很難，因為你沒辦法在不提供明確指令的情況下讓AI滿足你，而你如果明確的給出所有需求，那你只是在換個語言coding

www

程式的確就是對於現實的事物或概念進行描述 要越細緻 就要描述的越仔細 自然語言本身是很模糊的 要細節那自然語言也要跟著寫到很細 那還是在寫程式 只是程式語言變成英文？

就像關鍵字 let 一樣。就是個很英文式的程式語法foreach a in group 這個演化也很英文

AI開發者都對AI無法掌握喔@@

給樓上, 模型研發並不像資訊系統, 你把需求跟規格列出來我們照著開發就會有進展就算你去讀了論文告訴你 OO 機制有什麼效果 你也無法預期引入那個機制對你的模型表現能提升多少 甚至未必是提升當模型產出你不要的結果, 你沒辦法印出熱力圖然後就說啊, 這就是因為怎樣怎樣 所以我們只要這樣改就可以解決不 沒有辦法 所以才需要每年燒數十億美金但你不知道我們會不會有造出AGI的一天 你只能相信再給他幾年他會更好

要完全符合vibe那肯定沒辦法，現在搞的東西就是contextwindow太小，要用程式去另外解決，可以參考:www.anthropic.com/engineering/multi-agent-research-system，可以參考anthropic的做法，說實話也不是給小白去vibe

可以理解現在的業主會想移除軟體建置成本讓AI自動生成，聽起來快又有效但是就是那個但是沒有程式背景的人根本分不出來AI唬爛所以.....就這樣而到時候軟體工程師早就進化成另類馴獸師變成只會有更多的馴獸師要養

對我來說就是可以專注在邏輯和結構，末梢程式碼可以快速tab解

推jej

推

推

前面都蠻正常的 最後一段的比喻很噁

最大的問題是記憶力 過了幾個問題就會忘了前面一些細節偏偏細節錯人要花更多時間找出來當工具用可以 當夥伴用你會累死

還好我同事的記憶力比AI還差

你講那麼多，那些外行一樣看熱鬧啦

跟我使用github copilot的感想一致，推

推。

最後一段很到位了

問題不是context window大小，而是context大了會有回彈

推

拆分小小的 一步一步慢慢完成

ai 生成不確定可以多問幾個比較 甚至把回答貼給另一個問

哇 這篇含金量真不錯

推