Re: [討論] Linus決定Linux專案不反對AI

看板Soft_Job作者 (小犬/小B)時間9小時前 (2026/07/28 03:02), 編輯推噓6(6推 0噓 23→)
留言29則, 5人參與, 25分鐘前最新討論串3/3 (看更多)
全文吃光光 關於 Linus 對 AI 的看法，可以看他今年的Keynote 對談 應該是五月中在溫哥華的Linux基金會北美開源峰會 先說我認為，軟體工程而言 AI工具=Agent=LLM+工具調度 https://youtu.be/fi29pfLcW4I
我的YouTube App 跳了 Gemini 提問 於是我問了一下摘要 https://i.imgur.com/hf727S9.jpeg
還有媒體常下標的「聽到99%用AI寫會生氣」 https://i.imgur.com/xRG4za6.jpeg
回到 Linus 七月在郵件清單的回應： * AI工具可以提升程式設計的生產力，但並非完美 * 因此會製造大量問題，但不應該掩耳盜鈴不去面對 而是確保LLM工具可以幫助維護者而非製造困境 * Linux Kernel 一向技術本位，開源是為了更好的技術 因此不會反對使用AI（不強制用 但會無視反對使用的意見） --- 在近半年，特別是 Opus 4.5 黑船入港之下 開源/自由軟體社群對於 AI 使用可說是炒成一片 反對的理由大致上是 - 審核負擔無解問題 - 產出程式碼的著作權、專利、授權混雜污染問題 有些更左的反對理由稱不上主流就不列了 作為另外一個極端，德國的Codeberg（開源世界的GitHub替代站） 就在近期宣布禁止絕大部分以AI寫的專案與禁止內容用於訓練 我自己的立場認為這就是一個工具跟技能放大器 過度的吹捧跟過度的反對其實都是有害的 這東西已經註定不會消失，就看世人如何面對 至於科學領域 至少有一件事我很肯定 「有了AI以後，暴力推導就能求證反證的問題都不是問題」 「也許」一億倍的無限猴子也有機會打出前所未見的證明 但那些東西只要還是基於語言模型，都稱不上是一種智慧 最後，那個Keynote裡也有提到他認為Sashiko（這次討論的開端） 雖然偶爾審核結果不夠好，但確實能幫助到人 看了一下他們預設接Gemini，喔喔，確實確實（？） ----- Sent from JPTT on my iPhone -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.229.73.42 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1785178924.A.B2B.html
推
07/28 06:22, 6小時前 , 1F
跟gemini關係不大。現在llm tooling最大的問題還是一堆錯
07/28 06:22, 1F
→
07/28 06:27, 6小時前 , 2F
需要人來檢查。但llm產能高，人跟不上。現在很多Projects
07/28 06:27, 2F
→
07/28 06:29, 6小時前 , 3F
禁止ai就是沒有人力處理slop。Linus是很懂得適當使用ai，
07/28 06:29, 3F
→
07/28 06:32, 6小時前 , 4F
但現在就是一堆程度差的濫用ai累死maintainers。
07/28 06:32, 4F
推
07/28 06:40, 5小時前 , 5F
Sashiko這個案例就是，它確實有幫助，但也常常錯誤，浪費
07/28 06:40, 5F
→
07/28 06:41, 5小時前 , 6F
人力。整體來講是有幫助,而且以後應該會是錯誤減少。但
07/28 06:41, 6F
→
07/28 06:45, 5小時前 , 7F
Linus沒考慮到的是，我們又多一個程序，要更多時間去處理
07/28 06:45, 7F
→
07/28 06:48, 5小時前 , 8F
llm可恨的地方就是，有幫助但花更多時間，現在靜下來思考
07/28 06:48, 8F
→
07/28 06:49, 5小時前 , 9F
時間都沒有。tasks一直來，但真的產能有提昇？
07/28 06:49, 9F
推
07/28 09:07, 3小時前 , 10F
現在不是貢獻者用ai ddos維護者，然後linus就想引入ai做
07/28 09:07, 10F
→
07/28 09:07, 3小時前 , 11F
篩選，減輕維護者的工作量嗎？
07/28 09:07, 11F
推
07/28 09:11, 3小時前 , 12F
ai時代，貢獻者不稀缺了，反而維護者是專案寶貴的資源，
07/28 09:11, 12F
→
07/28 09:11, 3小時前 , 13F
比起消耗維護者的精力，更傾向用ai去打槍提交
07/28 09:11, 13F
推
07/28 11:05, 1小時前 , 14F
可恨XD，有這麼氣喔
07/28 11:05, 14F
→
07/28 11:06, 1小時前 , 15F
第一次看到有人用可恨描述AI
07/28 11:06, 15F
推
07/28 11:36, 58分鐘前 , 16F
AI只會持續進步 你回到過去 你會跟裁縫師說趕快去恨
07/28 11:36, 16F
→
07/28 11:36, 58分鐘前 , 17F
成衣廠嗎
07/28 11:36, 17F
→
07/28 11:37, 57分鐘前 , 18F
人再怎麼厲害 也會百密一疏 要不然軟體的bug從哪裡來的
07/28 11:37, 18F
→
07/28 11:38, 56分鐘前 , 19F
說AI會產生BUG 你寫程式可以保證100%沒BUG?
07/28 11:38, 19F
→
07/28 12:01, 33分鐘前 , 20F
我會覺得 第一個 LLM確實也會出錯 但重點是「視模型（跟工
07/28 12:01, 20F
→
07/28 12:01, 33分鐘前 , 21F
具調度）能力決定人爲介入的程度」小模型連語法都常寫錯 但
07/28 12:01, 21F
→
07/28 12:01, 33分鐘前 , 22F
前段模型而言 後面執行完驗證後 錯幾乎只會出在需求或解法
07/28 12:01, 22F
→
07/28 12:01, 33分鐘前 , 23F
沒有確實對齊這種中高階問題上
07/28 12:01, 23F
→
07/28 12:02, 32分鐘前 , 24F
（每天工作看Opus瞎掰註解就飽了）
07/28 12:02, 24F
→
07/28 12:06, 28分鐘前 , 25F
第二個 審核而言 LLM簡單的問題抓很快 硬燒Token燒出沒注意
07/28 12:06, 25F
→
07/28 12:06, 28分鐘前 , 26F
的細節很常見 我認為導入一定有幫助 問題反而在不是大家都
07/28 12:06, 26F
→
07/28 12:06, 28分鐘前 , 27F
有充足的預算
07/28 12:06, 27F
→
07/28 12:08, 26分鐘前 , 28F
但老實話 適應工具能力的過程極為痛苦
07/28 12:08, 28F
→
07/28 12:09, 25分鐘前 , 29F
我是支持用人去看去對 而不是硬燒燒到好就是了
07/28 12:09, 29F
‣ 更多 ybite 的文章
文章代碼(AID): #1gPwiiih (Soft_Job)
‣ 更多 ybite 的文章
文章代碼(AID): #1gPwiiih (Soft_Job)