Linus 撐 AI 入 Linux，但 Sashiko 命中五成唔代表可以放任 vibe coding

Linus Torvalds 今次講得好硬：Linux 冇打算變成反 AI 項目，接受唔到嘅人可以 fork，亦可以離開。淨係抽呢句做標題，好易睇成 Linus 全面放行 AI 寫 kernel。睇返 mailing list 脈絡，佢撐嘅係開發者有權用 AI 工具，判斷準則仍然係技術質素；佢同時承認 AI 會增加 maintainer 工作量，亦可能交出錯誤答案。

爭議由 Sashiko 自動審查開始

今次討論圍繞 Sashiko 展開。呢套開源系統會監察 Linux Kernel Mailing List，用 Gemini 3.1 Pro 審查提交上去嘅 patch。佢唔只問模型一句「有冇 bug」，而係用多階段流程，叫唔同角色由架構、安全、資源管理、同時處理等角度逐輪檢查，再用各個 kernel subsystem 專用嘅 prompt 補背景。運算資源由 Google 提供，項目本身交咗畀 Linux Foundation，程式碼用 Apache 2.0 授權。

呢種用法同叫 coding agent 自己寫 patch，再由人望兩眼就提交，相差好遠。Sashiko 擺喺 review 階段，工作係挑出可疑位置，最後仍由開發者同 maintainer 判斷。AI 生成 bug report、AI 輔助 code review、AI 寫程式碼，三者帶嚟嘅責任同噪音都唔同；將佢哋一律叫做 vibe coding，只會令討論失焦。

圖片：Wikimedia Commons — ChatGPT（Public domain）

53.6% 命中率要睇清楚點計

Sashiko 團隊用 1,000 個近期 upstream commit 測試，樣本靠 Fixes: tag 找出已經有後續修正嘅問題，再叫系統回頭審查原本嗰次改動。項目方聲稱 Gemini 3.1 Pro 能夠找出當中 53.6% 嘅 bug。呢個結果值得留意，因為嗰批問題當初通過咗真人 review；不過測試答案本身已知，反映嘅係模型重現歷史 bug 嘅能力，唔足以證明佢面對全新 patch 都有同一命中率。

樣本仲有另一個限制：Fixes: tag 只覆蓋最後俾人發現、修正兼正確標記嘅問題。仍然藏喺 kernel 入面、冇修正，或者修正時冇加 tag 嘅 bug，全部唔喺測試範圍。部分 build failure、效能退步同硬件相關問題，本身亦未必可以單靠睇 patch 找到。所以 53.6% 比較適合當作回溯測試成績，暫時未係完整嘅實際工作環境準確率。

約 20% 誤報先係 maintainer 最頭痛嗰筆數

項目方話誤報率「大致低過 20%」，但亦清楚承認呢個數只係來自有限人工檢查，而且好多結果處於灰色地帶：技術上未算錯，價值又低，可能只係吹毛求疵。呢個分別好重要。對模型嚟講，一個低風險疑點都算發現；對每日處理大量 patch 嘅 maintainer 嚟講，每個疑點都要花時間理解、重現、回覆，最後確認冇事一樣要埋單。

假設系統一次列出十個問題，八個有道理、兩個誤報，表面成績幾好。不過 maintainer 無法預先知道邊兩個係錯，仍然要檢查足十個。當 AI review 大量進入 mailing list，成本仲包括重複報告、欠缺背景嘅安全警告，同埋提交者自己都解釋唔到嘅修正。Sashiko 團隊亦話要有一批經人手確認、真正冇問題嘅 commit，先可以建立可靠嘅 false-positive benchmark；即係而家嗰個約 20% 仍屬初步估算。

Linux 接受工具，同時將責任鎖返落真人度

Linux kernel 最新指引已經畫出實際界線。AI agent 唔可以自行加具法律意義嘅 Signed-off-by；真人提交者要審查所有生成內容、確認授權相容、理解整份提交，同埋承擔責任。用 AI 參與開發時，提交亦應加入 Assisted-by tag，交代工具同模型版本。至於大量由工具生成嘅內容，個別 maintainer 可以加強審查、降低優先次序，甚至直接拒絕。

呢套規矩反映 kernel 社群真正關心嘅係信任鏈。用 sparse、Coccinelle、編譯器警告或者 LLM 找 bug，都可以係正常工程工具；提交者一旦將輸出原封不動拋入 mailing list，驗證成本就由佢自己轉嫁畀 maintainer。Linus 接受 AI，冇免除呢筆人手成本，仲冇替低質素提交開綠燈。

Sashiko 要證明嘅係能否減少總工作量

Sashiko 最有價值嘅位置，可能係正式 review 前做第一輪篩選：先找出鎖、記憶體生命週期、錯誤路徑同 subsystem 慣例等可疑位，畀作者修好再交上去。咁樣用，AI 有機會縮短來回修改時間。相反，如果系統把每個低信心猜測都公開寄去 mailing list，五成命中率仍可能製造大量噪音，拖慢本身已經缺人嘅 review 流程。

所以之後最值得睇嘅數據，包括每個有效發現要處理幾多誤報、maintainer 實際慳到幾多時間，同埋離開歷史 Fixes: 樣本後仲有幾準。Sashiko 初步顯示 LLM 可以搵到真人漏咗嘅 kernel 問題，但係咪適合長期加入開發流程，仲要睇更完整嘅盲測同實際工作量數據。

參考來源

• Ars Technica — Linus Torvalds to critics of AI coding in Linux: "Fork it. Or just walk away." — original report
• Linus Torvalds：Re: Linking Patchwork with Sashiko? — Linus 完整回覆，確認佢對 AI 工具、maintainer 負擔同技術判斷嘅原意。
• Introduce Sashiko (agentic review of Linux kernel changes) — Sashiko 開發者 Roman Gushchin 公開介紹系統架構、測試樣本同測量限制。
• Sashiko 官方網站 — 確認系統用途、審查範圍、項目歸屬、授權同 Google 提供運算資源。
• Linux Kernel：AI Coding Assistants — Linux kernel 官方 AI 輔助開發指引，包括 Signed-off-by、Assisted-by 同真人責任。
• Linux Kernel：Kernel Guidelines for Tool-Generated Content — 官方工具生成內容規則，交代透明度要求同 maintainer 可採取嘅處理方式。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。