推 ayasedd: 最屌的還是看到開始有人做出了 H 奶 30kg，一邊單眼皮一 08/26 19:50
→ ayasedd: 邊雙眼皮，然後說因為看習慣 30cm，所以也要加上 30cm， 08/26 19:50
→ ayasedd: 變成一個每個細節都很屌，但整體不知道到底在幹嘛 08/26 19:50
推 newhandfun: 前面一堆叫罵聲勢浩大 08/26 20:16
→ newhandfun: 認真討論的文卻乏人問津 08/26 20:16
→ newhandfun: 好啦話說回來，我同意這篇文的部分觀點 08/26 20:20
→ newhandfun: 會出現很多冗餘的參數跟沒必要的流程 08/26 20:20
→ holebro: 完全不管code太理想 但不追求什麼良好設計這種方法倒是 08/26 21:46
→ holebro: 堪用了 08/26 21:46
→ ybite: 我自己也認為「AI要好維護前提是人也好維護」 08/26 22:29
→ ybite: 畢竟正如大家的觀察 Context大小就是很現實的技術極限 08/26 22:30
推 leonardo0917: 結論很讚 08/26 22:54
推 ikachann: 設計差 效能爛 實務上的確不是最重要的，能符合需求的產 08/27 01:00
→ ikachann: 出才是真正有價值的地方 08/27 01:00
效能的好壞在實務上是不是最重要的，這點我認為因場景還有階段而異。
我自己是做桌面應用程式+3D軟體出身的，你光是一個button按下去卡頓QA就要來靠北了
這個道理也同樣適用於後端，最後到商業上效能一樣是用戶體驗與成本的處方
推 viper9709: 看起來不如自己寫比較快... 08/27 01:14
我自己寫是不可能那麼快的，方方面面都是。
就算把AI犯的錯誤與修正指示、AI修改的時間算進去，還是遠比我一個人開發快。
你要當成你在帶好幾個有時會懶惰會犯錯的junior。
包含我自己與許多在網路上看到的感想，共同心得都是AI開發的瓶頸現在其實是在
人的量能不夠。我一天要測試、review的量，其實資訊量是遠比傳統開發高的。
我Max 5x時段內額度用盡，我通常也很疲勞了。
當然素人現在vibe coding很爽，是因為他們也看不出(或是說不在乎也不知道有哪
些問題)，加上他們的專案規模都小或說規格都很常見，所以不會發生問題，過程當
然也很輕鬆愉悅
推 sunsamy: 剛剛試了vibe coding，連最簡單的outlook 2007 pop3 08/27 01:32
→ sunsamy: 同步刪掉Gmail的信件都在胡說八道， 08/27 01:33
→ sunsamy: 浪費我的時間，這是怎麼vibe coding啦 08/27 01:33
→ sunsamy: 話說有人懂嗎？我Gmail已經爆了,現在來跟你們vibe coding 08/27 01:35
→ sunsamy: 可能比較靠譜 08/27 01:35
推 sunsamy: 感覺vibe coding這詞跟敏捷這詞一樣是個唬爛的同意詞 08/27 01:37
※ 編輯: SkankHunt42 (146.70.205.188 日本), 08/27/2025 02:07:40
→ saladim: 蠻贊同這篇的過程跟感想的 對於有生命期的產品vibe codin 08/27 02:28
→ saladim: 終究會帶來不可承受的負擔 更別說要規格業務邏輯的一致性 08/27 02:30
→ saladim: 不過有人說要換個想法 對於每次功能的變動 乾脆直接重新 08/27 02:31
→ saladim: 全部重頭產生程式碼 這也不大合理 最多只能部分codebase 08/27 02:33
→ saladim: 讓AI完全重新產生碼出來 但是就我的實際經驗連個稍微長一 08/27 02:34
→ saladim: 點的演算法或是處理程序 都沒辦法一次'功能'到位 覺得 08/27 02:35
→ saladim: vibe coding只能用在小型專案上面 我現在也只是拿來產生 08/27 02:36
→ saladim: script跟很簡單的工作上的資料pipeline 08/27 02:37
推 strlen: vibe coding這詞也才出來半年多 當然現主時沒辦法完全不看 08/27 02:56
→ strlen: code很正常R 你給他再5年試試看 08/27 02:56
→ strlen: 中大型專案隨著context window越來越大 遲早能整個吞下去 08/27 02:57
我不對還沒發生的改變做評論。
就跟Steam玩家不會因為你DLC、免費更新大餅畫得很飽滿就給你為了財報數字趕工上
架的半成品好評一樣。
我拋磚引玉期望的是大神跳上來打臉我說：
「你根本不會用AI，用下面幾個流程與方法我能達到完全不看程式碼又穩健的開發」
這種交流才是對開發社群有助益的實質討論。
推 qqqlll666: Llm目前就是當外部顧問 臨時工用 他沒辦法了解專案或 08/27 05:32
→ qqqlll666: 團隊文化等等隱性知識 就像請一個外部技術專家來 也不 08/27 05:32
→ qqqlll666: 可能三言兩語就上手完成任務 所以別期待AI可以幫你完 08/27 05:32
→ qqqlll666: 成一切 08/27 05:32
→ qqqlll666: 理想情況是在請他做事時一邊建立文件 建立測試 把隱形 08/27 05:32
→ qqqlll666: 知識轉成顯性 但這就像帶新人一樣 短期沒回報 長期也 08/27 05:32
→ qqqlll666: 不一定利己 最後說不定是讓自己失業 08/27 05:32
他寫文件跟測試是真的很方便。我現在連commit message都懶得自己寫。
→ Ekmund: 多少還是需要祖傳md 08/27 09:23
我的觀察，claude偶爾會做太high忘記CLAUDE.md的規則。
※ 編輯: SkankHunt42 (146.70.205.92 日本), 08/27/2025 10:45:26
推 ZSZ1210: 推！很贊同這篇的過程和想法 最近剛好也一直在玩這塊 08/27 10:43
→ ZSZ1210: 目前在想透過micro service+DDD開發手法，每個領域都用 08/27 10:44
→ ZSZ1210: repository切開，減少AI每次需要學習和需要記憶的量 08/27 10:46
→ ZSZ1210: 目前是每個repository底下都放一個md在試試看～ 08/27 10:47
→ ZSZ1210: 請問大大是用claude還是gemini啊？ 08/27 10:47
推 yamakazi: YT搜尋Claude就好，已經開始有一堆人講解怎麼用。我用起 08/27 11:26
→ yamakazi: 來效率乘十倍不誇張 08/27 11:26
推 brucetu: 十倍 哈哈哈 你三天就做完以前一個月的專案進度了嗎 08/27 11:42
→ brucetu: 還是寫扣的速度快了十倍但寫扣只佔工作的一小部分 其實 08/27 11:44
→ brucetu: 整體產出根本也沒提升多少 同時每天大量review AI的產出 08/27 11:44
→ brucetu: 還消耗了不少腦力導致整體產出倒退 08/27 11:44
推 jamesho8743: 十倍是扯了點 那丟給你五人份的工作你應該非常輕鬆 08/27 11:46
→ jamesho8743: 還可以偷懶囉? 08/27 11:46
→ brucetu: 已經很多人發現使用AI反而造成整體產出下降 你越仰賴 vib 08/27 11:48
→ brucetu: e coding 你對專案程式碼的熟悉度就會越來越低 甚至你不 08/27 11:48
→ brucetu: 會記得最近三天新加入的函數有哪些 你會感覺有個公用函 08/27 11:48
→ brucetu: 數好像之前才寫過但你不確定放在哪個檔案 你跟AI一樣有 08/27 11:48
→ brucetu: 失憶現象最後造成專案裡類似功能的函數到處都是 08/27 11:48
我沒有做量化分析，加上樣本數只有我自己，所以我也無意討論到底是幾倍，這都是
體感問題。
我原文的焦點其實只有一個問題「在現階段是否可以完全忽略程式碼進行開發」
如果你本身是一個經驗豐富的工程師，當然可以透過各種工作流與指令的設計、對
codebase的理解加以推進這個過程。但我認為這並不符合宣傳中所謂「理想中的vibe
coding」的模式
推 Kasima: cursor+gpt5+大量project rules+FP應該算是目前vibe codi 08/27 12:17
→ Kasima: ng的最頂級combo，便宜好用又不會亂寫 08/27 12:17
推 yamakazi: Claude現在還可以幫你執行命令，看build error，下gdb， 08/27 13:18
→ yamakazi: callstack直接看，log印成檔案後直接看檔案，確實不太需 08/27 13:18
→ yamakazi: 要review AI產生的代碼了。真要review再新開一個task叫A 08/27 13:18
→ yamakazi: I review 08/27 13:18
→ yamakazi: 要預防失憶現象，要寫MD檔，甚至AI改完code後可以叫他改 08/27 13:19
→ yamakazi: 寫MD檔兩邊align 08/27 13:19
推 yamakazi: 直接改檔案直接跑，你只要按確認就好，連複製貼上都不用 08/27 13:23
你說的似乎沒有超出我的認知。
推 duitub: 推實驗精神 08/27 13:23
→ yamakazi: 「類似功能的函數到處都是」 這是一個很大的問題嗎？如 08/27 13:25
→ yamakazi: 果不影響專案進行，這問題根本沒差。利大於弊，除非嵌入 08/27 13:25
→ yamakazi: 式斤斤計較空間，但嵌入式通常repo不會很大，AI更容易處 08/27 13:25
→ yamakazi: 理 08/27 13:25
→ Suleika: 可以在研究一下context engineering，啟用一個agent去審 08/27 13:28
→ Suleika: 有模板貨文檔，也不會有風格偏差太大的問題 08/27 13:29
你跟yamakazi說的方法其實我都試過，甚至寫在內文。
這原則上就是指定AI去閱讀某份module或文件，不管是全自動還是手動命令的形式。
AI自動循環更新文件→改程式→更新文件的模式我當也試過。
這種方法在一定規模內有用，但一旦內容太多對AI就會變成一種干擾。
當然如果你token額度很大可以整個context都塞進去也沒問題。
推 yamakazi: 要寫README.md，寫了就不太會失憶了 08/27 13:31
→ strlen: 其實你這樣的需求也不明確 也沒定義清楚 雖然說中大型 要 08/27 13:33
→ strlen: 多大才叫中大型？ 現在小型專案確實已經可以完全不看程式 08/27 13:34
→ strlen: 碼完成整個產品 但小型是多小型？會不會過陣子 其實已經可 08/27 13:34
推 yamakazi: 十倍當然不誇張啊，原本一小時才能解完的bug，五分鐘AI 08/27 13:34
→ yamakazi: 就解完了？那不就十倍？ 08/27 13:34
→ strlen: 以做到完全不看程式碼開發一整個電商系統 但又會抱怨電商 08/27 13:35
→ strlen: 根本就中小型專案 難道AI能讓我Vibe Coding出google搜尋引 08/27 13:35
→ strlen: 擎或整個臉書嗎？我覺得喇 怎麼樣都可以打臉的理由 沒有討 08/27 13:36
→ strlen: 論的價值 08/27 13:36
→ strlen: 等到哪天真的能vibe出一個搜尋引擎 又會說 啊是能讓我vibe 08/27 13:36
→ strlen: 出一個ChatGPT嗎？如果不定義標準 AI永遠不可能滿足 08/27 13:37
推 yamakazi: AI都拿了諾貝爾化學獎和數奧金牌了，寫程式真的小菜一碟 08/27 13:38
→ strlen: 專案的性質也差很多 vibe一個部落格 跟vibe一個3D遊戲引擎 08/27 13:40
→ strlen: 或跟vibe一個給客戶用的SDK 是完全不一樣的事 每一種類型 08/27 13:40
→ strlen: 也都可大可小 不定義清楚很難說vibe沒什麼用 08/27 13:41
歡迎你根據自己的定義、使用經驗與觀察與回文。
我可以補充一些我專案的數據：
程式碼行數不含CSS一共有21000行，其中8700行是test。
commit數量110個。
專案是DSL專用的WYSIWYG風格的編輯器。
而對vibe的定義我在開頭也引述了Wiki的寫法。
→ strlen: 實際上我就親身遇過業主沒有任何背景程式 vibe出一個演算 08/27 13:41
→ strlen: 法系統來幫忙處理公司內數據 他一行程式碼都看不懂 程式碼 08/27 13:42
→ strlen: 也沒給任何工程師審查過 就他自己做的工具 但運作非常好 08/27 13:43
推 yamakazi: 看不懂沒差啦，llm的開發人員也說過他們也看不懂現在llm 08/27 13:43
→ yamakazi: 的程式碼了 08/27 13:43
→ strlen: 整個系統大概一萬多行 這算大 還是小 08/27 13:43
→ yamakazi: AI開發者自己對AI模型都無法掌握了，看不懂正常 08/27 13:46
→ brucetu: 不可解釋性以及深度學習領域很多新方法難以解釋，這跟你 08/27 14:13
→ brucetu: 做資訊系統但不懂其中的程式碼那是完全兩回事 08/27 14:13
→ brucetu: vibe coding 在你只需要一個蛋糕的時候沒有任何問題，他 08/27 14:16
→ brucetu: 是一個蛋糕而且還不錯，當你的客戶說我的蛋糕這邊那邊一 08/27 14:16
→ brucetu: 定要如何如何的時候，就開始有問題了 08/27 14:16
推 yamakazi: 其實我看不懂你的蛋糕比喻XD 08/27 14:24
推 yamakazi: 「這邊一定要如何如何」這對AI來說很難嗎？ 08/27 14:25
→ brucetu: 很難，因為你沒辦法在不提供明確指令的情況下讓AI滿足你 08/27 14:26
→ brucetu: ，而你如果明確的給出所有需求，那你只是在換個語言codin 08/27 14:26
→ brucetu: g 08/27 14:26
推 yamakazi: www 08/27 14:28
→ strlen: 程式的確就是對於現實的事物或概念進行描述 要越細緻 就要 08/27 15:08
→ strlen: 描述的越仔細 自然語言本身是很模糊的 要細節那自然語言也 08/27 15:09
→ strlen: 要跟著寫到很細 那還是在寫程式 只是程式語言變成英文？ 08/27 15:10
※ 編輯: SkankHunt42 (154.47.23.114 日本), 08/27/2025 15:56:53
推 NDark: 就像關鍵字 let 一樣。就是個很英文式的程式語法 08/27 15:52
→ NDark: foreach a in group 這個演化也很英文 08/27 15:53
※ 編輯: SkankHunt42 (154.47.23.114 日本), 08/27/2025 16:07:52
推 viper9709: AI開發者都對AI無法掌握喔@@ 08/27 16:25
→ brucetu: 給樓上, 模型研發並不像資訊系統, 你把需求跟規格列出來 08/27 16:35
→ brucetu: 我們照著開發就會有進展 08/27 16:35
→ brucetu: 就算你去讀了論文告訴你 OO 機制有什麼效果 你也無法預期 08/27 16:36
→ brucetu: 引入那個機制對你的模型表現能提升多少 甚至未必是提升 08/27 16:36
→ brucetu: 當模型產出你不要的結果, 你沒辦法印出熱力圖然後就說 08/27 16:38
→ brucetu: 啊, 這就是因為怎樣怎樣 所以我們只要這樣改就可以解決 08/27 16:38
→ brucetu: 不 沒有辦法 所以才需要每年燒數十億美金但你不知道 08/27 16:39
→ brucetu: 我們會不會有造出AGI的一天 你只能相信再給他幾年他會 08/27 16:40
→ brucetu: 更好 08/27 16:40
→ Suleika: 要完全符合vibe那肯定沒辦法，現在搞的東西就是context 08/27 19:38
→ Suleika: window太小，要用程式去另外解決，可以參考: 08/27 19:39
→ Suleika: www.anthropic.com/engineering/multi-agent-research-sy 08/27 19:41
→ Suleika: stem，可以參考 08/27 19:42
推 Suleika: anthropic的做法，說實話也不是給小白去vibe 08/27 19:45
推 jej: 可以理解現在的業主會想移除軟體建置成本 08/27 20:22
→ jej: 讓AI自動生成，聽起來快又有效 08/27 20:22
→ jej: 但是就是那個但是 08/27 20:22
→ jej: 沒有程式背景的人根本分不出來AI唬爛 08/27 20:22
→ jej: 所以.....就這樣 08/27 20:22
→ jej: 而到時候軟體工程師早就進化成另類馴獸師 08/27 20:24
→ jej: 變成只會有更多的馴獸師要養 08/27 20:24
推 crazwade: 對我來說就是可以專注在邏輯和結構，末梢程式碼可以快 08/27 20:51
→ crazwade: 速tab解 08/27 20:51
推 viper9709: 推jej 08/28 00:56
推 nashmvp: 推 08/28 06:12
推 cjtv: 推 08/28 09:12
噓 nacy204327: 前面都蠻正常的 最後一段的比喻很噁 08/28 09:34
推 gofigure: 最大的問題是記憶力 過了幾個問題就會忘了前面一些細節 08/28 10:28
→ gofigure: 偏偏細節錯人要花更多時間找出來 08/28 10:28
→ gofigure: 當工具用可以 當夥伴用你會累死 08/28 10:29
推 gino0717: 還好我同事的記憶力比AI還差 08/28 11:11
→ hobnob: 你講那麼多，那些外行一樣看熱鬧啦 08/28 13:18
推 s9041200: 跟我使用github copilot的感想一致，推 08/28 17:10
推 darkMood: 推。 08/28 17:44
推 tzouandy2818: 最後一段很到位了 08/28 18:16
推 dani1992: 問題不是context window大小，而是context大了會有回彈 08/28 19:06
推 inte629l: 推 08/28 21:37
→ molopo: 拆分小小的 一步一步慢慢完成 08/29 05:19
推 awenracious: ai 生成不確定可以多問幾個比較 甚至把回答貼給另一 08/29 12:43
→ awenracious: 個問 08/29 12:43
