作者 SkankHunt42 (凱子爸)標題 Re: [請益] 軟體失業是遲早的事吧時間 Tue Aug 26 19:43:34 2025
※ 引述《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女優一樣，像我就覺得臉蛋漂亮很重要，奶小沒關係，像希島愛里這樣
有人就覺得奶大很重要、假奶沒關係，但一定要奶大，像楪可憐這樣
也有人堅持一定要真奶、不要人造人，這種人去看楪可憐就只會看到楪可憐的缺點
祝大家在喜歡的女優引退後都能找到自己喜歡的新人女優
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 146.70.205.94 (日本)
※ 作者: SkankHunt42 2025-08-26 19:43:34
※ 文章代碼(AID): #1ehPteeE (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1756208616.A.A0E.html
※ 同主題文章:
Re: [請益] 軟體失業是遲早的事吧
08-26 19:43 SkankHunt42
推 ayasedd: 最屌的還是看到開始有人做出了 H 奶 30kg，一邊單眼皮一邊雙眼皮，然後說因為看習慣 30cm，所以也要加上 30cm，變成一個每個細節都很屌，但整體不知道到底在幹嘛1F 08/26 19:50
推 newhandfun: 前面一堆叫罵聲勢浩大
認真討論的文卻乏人問津
好啦話說回來，我同意這篇文的部分觀點
會出現很多冗餘的參數跟沒必要的流程4F 08/26 20:16
→ holebro: 完全不管code太理想 但不追求什麼良好設計這種方法倒是堪用了8F 08/26 21:46
→ ybite: 我自己也認為「AI要好維護前提是人也好維護」
畢竟正如大家的觀察 Context大小就是很現實的技術極限10F 08/26 22:29
推 ikachann: 設計差 效能爛 實務上的確不是最重要的，能符合需求的產出才是真正有價值的地方13F 08/27 01:00
效能的好壞在實務上是不是最重要的，這點我認為因場景還有階段而異。
我自己是做桌面應用程式+3D軟體出身的，你光是一個button按下去卡頓QA就要來靠北了
這個道理也同樣適用於後端，最後到商業上效能一樣是用戶體驗與成本的處方
我自己寫是不可能那麼快的，方方面面都是。
就算把AI犯的錯誤與修正指示、AI修改的時間算進去，還是遠比我一個人開發快。
你要當成你在帶好幾個有時會懶惰會犯錯的junior。
包含我自己與許多在網路上看到的感想，共同心得都是AI開發的瓶頸現在其實是在
人的量能不夠。我一天要測試、review的量，其實資訊量是遠比傳統開發高的。
我Max 5x時段內額度用盡，我通常也很疲勞了。
當然素人現在vibe coding很爽，是因為他們也看不出(或是說不在乎也不知道有哪
些問題)，加上他們的專案規模都小或說規格都很常見，所以不會發生問題，過程當
然也很輕鬆愉悅
推 sunsamy: 剛剛試了vibe coding，連最簡單的outlook 2007 pop3
同步刪掉Gmail的信件都在胡說八道，
浪費我的時間，這是怎麼vibe coding啦
話說有人懂嗎？我Gmail已經爆了,現在來跟你們vibe coding可能比較靠譜
感覺vibe coding這詞跟敏捷這詞一樣是個唬爛的同意詞16F 08/27 01:32
※ 編輯: SkankHunt42 (146.70.205.188 日本), 08/27/2025 02:07:40
→ saladim: 蠻贊同這篇的過程跟感想的 對於有生命期的產品vibe codin終究會帶來不可承受的負擔 更別說要規格業務邏輯的一致性不過有人說要換個想法 對於每次功能的變動 乾脆直接重新全部重頭產生程式碼 這也不大合理 最多只能部分codebase讓AI完全重新產生碼出來 但是就我的實際經驗連個稍微長一點的演算法或是處理程序 都沒辦法一次'功能'到位 覺得vibe coding只能用在小型專案上面 我現在也只是拿來產生script跟很簡單的工作上的資料pipeline22F 08/27 02:28
推 strlen: vibe coding這詞也才出來半年多 當然現主時沒辦法完全不看code很正常R 你給他再5年試試看
中大型專案隨著context window越來越大 遲早能整個吞下去30F 08/27 02:56
--