顯示廣告
隱藏 ✕
回列表(←)
Disp BBS guest 註冊 登入(i)
首頁(home) 上頁(↑) 下頁(↓) 末頁(end)
※ 本文轉寄自 ptt.cc 更新時間: 2025-08-27 23:00:05
看板 Soft_Job
作者 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
推 ayasedd: 最屌的還是看到開始有人做出了 H 奶 30kg，一邊單眼皮一1F 08/26 19:50
→ ayasedd: 邊雙眼皮，然後說因為看習慣 30cm，所以也要加上 30cm，
→ ayasedd: 變成一個每個細節都很屌，但整體不知道到底在幹嘛
推 newhandfun: 前面一堆叫罵聲勢浩大4F 08/26 20:16
→ newhandfun: 認真討論的文卻乏人問津
→ newhandfun: 好啦話說回來，我同意這篇文的部分觀點
→ newhandfun: 會出現很多冗餘的參數跟沒必要的流程
→ holebro: 完全不管code太理想 但不追求什麼良好設計這種方法倒是8F 08/26 21:46
→ holebro: 堪用了
→ ybite: 我自己也認為「AI要好維護前提是人也好維護」10F 08/26 22:29
→ ybite: 畢竟正如大家的觀察 Context大小就是很現實的技術極限
推 leonardo0917: 結論很讚12F 08/26 22:54
推 ikachann: 設計差 效能爛 實務上的確不是最重要的，能符合需求的產13F 08/27 01:00
→ ikachann: 出才是真正有價值的地方

效能的好壞在實務上是不是最重要的，這點我認為因場景還有階段而異。
我自己是做桌面應用程式+3D軟體出身的，你光是一個button按下去卡頓QA就要來靠北了
這個道理也同樣適用於後端，最後到商業上效能一樣是用戶體驗與成本的處方

推 viper9709: 看起來不如自己寫比較快...15F 08/27 01:14

我自己寫是不可能那麼快的，方方面面都是。
就算把AI犯的錯誤與修正指示、AI修改的時間算進去，還是遠比我一個人開發快。
你要當成你在帶好幾個有時會懶惰會犯錯的junior。

包含我自己與許多在網路上看到的感想，共同心得都是AI開發的瓶頸現在其實是在
人的量能不夠。我一天要測試、review的量，其實資訊量是遠比傳統開發高的。
我Max 5x時段內額度用盡，我通常也很疲勞了。

當然素人現在vibe coding很爽，是因為他們也看不出(或是說不在乎也不知道有哪
些問題)，加上他們的專案規模都小或說規格都很常見，所以不會發生問題，過程當
然也很輕鬆愉悅

推 sunsamy: 剛剛試了vibe coding，連最簡單的outlook 2007 pop316F 08/27 01:32
→ sunsamy: 同步刪掉Gmail的信件都在胡說八道，
→ sunsamy: 浪費我的時間，這是怎麼vibe coding啦
→ sunsamy: 話說有人懂嗎？我Gmail已經爆了,現在來跟你們vibe coding
→ sunsamy: 可能比較靠譜
推 sunsamy: 感覺vibe coding這詞跟敏捷這詞一樣是個唬爛的同意詞
※ 編輯: SkankHunt42 (146.70.205.188 日本), 08/27/2025 02:07:40
→ saladim: 蠻贊同這篇的過程跟感想的 對於有生命期的產品vibe codin22F 08/27 02:28
→ saladim: 終究會帶來不可承受的負擔 更別說要規格業務邏輯的一致性
→ saladim: 不過有人說要換個想法 對於每次功能的變動 乾脆直接重新
→ saladim: 全部重頭產生程式碼 這也不大合理 最多只能部分codebase
→ saladim: 讓AI完全重新產生碼出來 但是就我的實際經驗連個稍微長一
→ saladim: 點的演算法或是處理程序 都沒辦法一次'功能'到位 覺得
→ saladim: vibe coding只能用在小型專案上面  我現在也只是拿來產生
→ saladim: script跟很簡單的工作上的資料pipeline
推 strlen: vibe coding這詞也才出來半年多 當然現主時沒辦法完全不看30F 08/27 02:56
→ strlen: code很正常R 你給他再5年試試看
→ strlen: 中大型專案隨著context window越來越大 遲早能整個吞下去

我不對還沒發生的改變做評論。
就跟Steam玩家不會因為你DLC、免費更新大餅畫得很飽滿就給你為了財報數字趕工上
架的半成品好評一樣。

我拋磚引玉期望的是大神跳上來打臉我說：
「你根本不會用AI，用下面幾個流程與方法我能達到完全不看程式碼又穩健的開發」
這種交流才是對開發社群有助益的實質討論。

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

他寫文件跟測試是真的很方便。我現在連commit message都懶得自己寫。

→ Ekmund: 多少還是需要祖傳md40F 08/27 09:23

我的觀察，claude偶爾會做太high忘記CLAUDE.md的規則。
※ 編輯: SkankHunt42 (146.70.205.92 日本), 08/27/2025 10:45:26
推 ZSZ1210: 推！很贊同這篇的過程和想法 最近剛好也一直在玩這塊41F 08/27 10:43
→ ZSZ1210: 目前在想透過micro service+DDD開發手法，每個領域都用
→ ZSZ1210: repository切開，減少AI每次需要學習和需要記憶的量
→ ZSZ1210: 目前是每個repository底下都放一個md在試試看～
→ ZSZ1210: 請問大大是用claude還是gemini啊？
推 yamakazi: YT搜尋Claude就好，已經開始有一堆人講解怎麼用。我用起46F 08/27 11:26
→ yamakazi: 來效率乘十倍不誇張
推 brucetu: 十倍 哈哈哈 你三天就做完以前一個月的專案進度了嗎48F 08/27 11:42
→ brucetu: 還是寫扣的速度快了十倍但寫扣只佔工作的一小部分 其實
→ brucetu: 整體產出根本也沒提升多少 同時每天大量review AI的產出
→ brucetu: 還消耗了不少腦力導致整體產出倒退
推 jamesho8743: 十倍是扯了點 那丟給你五人份的工作你應該非常輕鬆52F 08/27 11:46
→ jamesho8743: 還可以偷懶囉?
→ brucetu: 已經很多人發現使用AI反而造成整體產出下降 你越仰賴 vib54F 08/27 11:48
→ brucetu: e coding 你對專案程式碼的熟悉度就會越來越低 甚至你不
→ brucetu: 會記得最近三天新加入的函數有哪些 你會感覺有個公用函
→ brucetu: 數好像之前才寫過但你不確定放在哪個檔案 你跟AI一樣有
→ brucetu: 失憶現象最後造成專案裡類似功能的函數到處都是

我沒有做量化分析，加上樣本數只有我自己，所以我也無意討論到底是幾倍，這都是

體感問題。

我原文的焦點其實只有一個問題「在現階段是否可以完全忽略程式碼進行開發」

如果你本身是一個經驗豐富的工程師，當然可以透過各種工作流與指令的設計、對

codebase的理解加以推進這個過程。但我認為這並不符合宣傳中所謂「理想中的vibe

coding」的模式

推 Kasima: cursor+gpt5+大量project rules+FP應該算是目前vibe codi59F 08/27 12:17
→ Kasima: ng的最頂級combo，便宜好用又不會亂寫
推 yamakazi: Claude現在還可以幫你執行命令，看build error，下gdb，61F 08/27 13:18
→ yamakazi: callstack直接看，log印成檔案後直接看檔案，確實不太需
→ yamakazi: 要review AI產生的代碼了。真要review再新開一個task叫A
→ yamakazi: I review
→ yamakazi: 要預防失憶現象，要寫MD檔，甚至AI改完code後可以叫他改
→ yamakazi: 寫MD檔兩邊align
推 yamakazi: 直接改檔案直接跑，你只要按確認就好，連複製貼上都不用

你說的似乎沒有超出我的認知。

推 duitub: 推實驗精神68F 08/27 13:23
→ yamakazi: 「類似功能的函數到處都是」 這是一個很大的問題嗎？如69F 08/27 13:25
→ yamakazi: 果不影響專案進行，這問題根本沒差。利大於弊，除非嵌入
→ yamakazi: 式斤斤計較空間，但嵌入式通常repo不會很大，AI更容易處
→ yamakazi: 理
→ Suleika: 可以在研究一下context engineering，啟用一個agent去審73F 08/27 13:28
→ Suleika: 有模板貨文檔，也不會有風格偏差太大的問題

你跟yamakazi說的方法其實我都試過，甚至寫在內文。

這原則上就是指定AI去閱讀某份module或文件，不管是全自動還是手動命令的形式。

AI自動循環更新文件→改程式→更新文件的模式我當也試過。

這種方法在一定規模內有用，但一旦內容太多對AI就會變成一種干擾。

當然如果你token額度很大可以整個context都塞進去也沒問題。

推 yamakazi: 要寫README.md，寫了就不太會失憶了75F 08/27 13:31
→ yamakazi: https://youtu.be/sOvi9Iu1Dq8?si=ajHBx8JZe-eLYZ7_
→ strlen: 其實你這樣的需求也不明確 也沒定義清楚 雖然說中大型 要77F 08/27 13:33
→ strlen: 多大才叫中大型？ 現在小型專案確實已經可以完全不看程式
→ strlen: 碼完成整個產品 但小型是多小型？會不會過陣子 其實已經可
推 yamakazi: 十倍當然不誇張啊，原本一小時才能解完的bug，五分鐘AI80F 08/27 13:34
→ yamakazi: 就解完了？那不就十倍？
→ strlen: 以做到完全不看程式碼開發一整個電商系統 但又會抱怨電商82F 08/27 13:35
→ strlen: 根本就中小型專案 難道AI能讓我Vibe Coding出google搜尋引
→ strlen: 擎或整個臉書嗎？我覺得喇 怎麼樣都可以打臉的理由 沒有討
→ strlen: 論的價值
→ strlen: 等到哪天真的能vibe出一個搜尋引擎 又會說 啊是能讓我vibe
→ strlen: 出一個ChatGPT嗎？如果不定義標準 AI永遠不可能滿足
推 yamakazi: AI都拿了諾貝爾化學獎和數奧金牌了，寫程式真的小菜一碟88F 08/27 13:38
→ strlen: 專案的性質也差很多 vibe一個部落格 跟vibe一個3D遊戲引擎89F 08/27 13:40
→ strlen: 或跟vibe一個給客戶用的SDK 是完全不一樣的事 每一種類型
→ strlen: 也都可大可小 不定義清楚很難說vibe沒什麼用

歡迎你根據自己的定義、使用經驗與觀察與回文。

我可以補充一些我專案的數據：

程式碼行數不含CSS一共有21000行，其中8700行是test。

commit數量110個。

專案是DSL專用的WYSIWYG風格的編輯器。

而對vibe的定義我在開頭也引述了Wiki的寫法。

→ strlen: 實際上我就親身遇過業主沒有任何背景程式 vibe出一個演算92F 08/27 13:41
→ strlen: 法系統來幫忙處理公司內數據 他一行程式碼都看不懂 程式碼
→ strlen: 也沒給任何工程師審查過 就他自己做的工具 但運作非常好
推 yamakazi: 看不懂沒差啦，llm的開發人員也說過他們也看不懂現在llm95F 08/27 13:43
→ yamakazi: 的程式碼了
→ strlen: 整個系統大概一萬多行 這算大 還是小97F 08/27 13:43
推 yamakazi: https://i.imgur.com/JTbzC9p.jpeg98F 08/27 13:45
→ yamakazi: AI開發者自己對AI模型都無法掌握了，看不懂正常
[圖]
→ brucetu: 不可解釋性以及深度學習領域很多新方法難以解釋，這跟你100F 08/27 14:13
→ brucetu: 做資訊系統但不懂其中的程式碼那是完全兩回事
→ brucetu: vibe coding 在你只需要一個蛋糕的時候沒有任何問題，他
→ brucetu: 是一個蛋糕而且還不錯，當你的客戶說我的蛋糕這邊那邊一
→ brucetu: 定要如何如何的時候，就開始有問題了
推 yamakazi: 其實我看不懂你的蛋糕比喻XD105F 08/27 14:24
推 yamakazi: 「這邊一定要如何如何」這對AI來說很難嗎？
→ brucetu: 很難，因為你沒辦法在不提供明確指令的情況下讓AI滿足你107F 08/27 14:26
→ brucetu: ，而你如果明確的給出所有需求，那你只是在換個語言codin
→ brucetu: g
推 yamakazi: www110F 08/27 14:28
→ strlen: 程式的確就是對於現實的事物或概念進行描述 要越細緻 就要111F 08/27 15:08
→ strlen: 描述的越仔細 自然語言本身是很模糊的 要細節那自然語言也
→ strlen: 要跟著寫到很細 那還是在寫程式 只是程式語言變成英文？
※ 編輯: SkankHunt42 (154.47.23.114 日本), 08/27/2025 15:56:53
推 NDark: 就像關鍵字 let 一樣。就是個很英文式的程式語法114F 08/27 15:52
→ NDark: foreach a in group 這個演化也很英文
※ 編輯: SkankHunt42 (154.47.23.114 日本), 08/27/2025 16:07:52
推 viper9709: AI開發者都對AI無法掌握喔@@116F 08/27 16:25
→ brucetu: 給樓上, 模型研發並不像資訊系統, 你把需求跟規格列出來117F 08/27 16:35
→ brucetu: 我們照著開發就會有進展
→ brucetu: 就算你去讀了論文告訴你 OO 機制有什麼效果 你也無法預期
→ brucetu: 引入那個機制對你的模型表現能提升多少 甚至未必是提升
→ brucetu: 當模型產出你不要的結果, 你沒辦法印出熱力圖然後就說
→ brucetu: 啊, 這就是因為怎樣怎樣 所以我們只要這樣改就可以解決
→ brucetu: 不 沒有辦法 所以才需要每年燒數十億美金但你不知道
→ brucetu: 我們會不會有造出AGI的一天 你只能相信再給他幾年他會
→ brucetu: 更好
→ Suleika: 要完全符合vibe那肯定沒辦法，現在搞的東西就是context126F 08/27 19:38
→ Suleika: window太小，要用程式去另外解決，可以參考:
→ Suleika: www.anthropic.com/engineering/multi-agent-research-sy
→ Suleika: stem，可以參考
推 Suleika: anthropic的做法，說實話也不是給小白去vibe
推 jej: 可以理解現在的業主會想移除軟體建置成本131F 08/27 20:22
→ jej: 讓AI自動生成，聽起來快又有效
→ jej: 但是就是那個但是
→ jej: 沒有程式背景的人根本分不出來AI唬爛
→ jej: 所以.....就這樣
→ jej: 而到時候軟體工程師早就進化成另類馴獸師
→ jej: 變成只會有更多的馴獸師要養
推 crazwade: 對我來說就是可以專注在邏輯和結構，末梢程式碼可以快138F 08/27 20:51
→ crazwade: 速tab解

--
※ 看板: Soft_Job　文章推薦值: 0 目前人氣: 7 累積人氣: 1267　
作者 SkankHunt42 的最新發文:
點此顯示更多發文記錄
分享網址: 複製 已複製
→
guest
x)推文 r)回覆 e)編輯 d)刪除 M)收藏 ^x)轉錄 同主題: =)首篇 [)上篇 ])下篇