Copilot 讓舊 AMD GPU 活下來

我拆 Copilot 怎麼幫 Linux 維護者清理 R600 驅動，讓 HD 2000 到 HD 6000 這批老 AMD 顯卡繼續可用。

我用老硬體跑 Linux 很久了，最熟的感受就是：系統能開、桌面能進，但總有一個小地方提醒你，這東西其實早就該退休了。老 AMD 顯卡特別明顯。驅動還在，編譯也過，偏偏每次修補都像在搬一間快塌掉的老屋裡的碗盤。我看到這則案例時，第一反應不是「AI 好神」，而是終於有一個比較像樣的用途：不是拿 Copilot 亂寫新產品，而是拿它去整理那些沒人想碰、但又不能死掉的舊碼。

這次把我拉進來的來源是 Tom’s Hardware 的這篇 Linux developers are using AI vibe coding to keep vintage AMD GPUs alive，作者是 Aaron Klotz。文中再指到 Phoronix 的相關報導與 Gert Wollny 的提交紀錄，重點是他在整理 R600 Gallium3D driver 時用了 GitHub Copilot auto mode。這不是 AI 取代驅動開發，而是 AI 幫一個維護者把舊子系統從「快變化石」的狀態拉回來。

Copilot 沒有寫驅動，它只是幫忙收拾爛攤子

“GitHub Copilot was used to clean up code pertaining to vintage AMD R600 Linux graphics drivers, helping keep the driver relevant for people still using these late 2000s-era GPUs.”

這句話翻成白話就是：Copilot 不是在從零生出一個驅動，它是在做重構、整理、去重複、縮邏輯。也就是那種最沒戲劇性、但最吃人耐性的工作。對驅動來說，這類整理通常發生在 shader compiler code、分支邏輯、重複判斷、命名不一致這些地方。看起來都很小，累積起來就是未來少一堆 bug。

我其實很討厭 AI coding 常被講成兩種極端：一邊把模型吹成永遠不累的資深工程師，另一邊把任何 AI 參與都講成道德淪喪。老驅動維護剛好卡在中間。你如果盯著一段只有少數人看得懂的 C/C++，我寧可讓工具先提議一版清理方案，也不要自己一個人對著三層巢狀 if 硬磨三小時，最後還是改得很醜。

實操上，我會把 AI 的角色縮到很小：幫我找重複、幫我改命名、幫我把機械性改動先做一輪。然後我自己再看每個 diff。這種用法很無聊，但很對。你在 driver、kernel、compiler 這種地方要的不是「靈感」，是可控。

• 把 AI 用在 refactor，不是用在把關 correctness。
• 一次只做一種改動，別一口氣讓它重構整個模組。
• 把每個輸出都當成「很熱心但沒上下文的實習生」看。

所謂 vibe coding，在這裡其實是 maintenance coding

Tom’s Hardware 用了「AI vibe coding」這個詞，聽起來很潮，但我看下來覺得它真正的意思很樸素：不是叫模型幫你做一個 app，而是幫你把一個活了快二十年的舊 driver 收拾乾淨。這裡的 vibe 不是衝刺，是維護。

文中提到 Gert Wollny 為了清理 shader compiler code 做了 59 個 commits，而且 commit note 還有提到 Copilot auto mode。這種資訊很重要，因為它透露的不是「按一下就出神作」，而是反覆迭代：看程式、叫工具做一輪清理、人工檢查、跑測試、再修。這才像真實世界，不像 demo。

我以前碰過一段舊 infra code，功能沒錯，但讀起來像在翻一本沒有標點的手寫筆記。那時候最有價值的不是大翻修，而是一連串低風險、可驗證的小整理。AI 在這裡真的有用，因為它擅長處理重複模式、機械改寫、格式一致化，剛好把人從最煩的部分解放出來。

• 先挑一個小範圍，像是一個 function、一組重複判斷、一段命名不一致的 code path。
• 每次只問一種變更，別讓模型同時碰架構和行為。
• 如果它開始「很有創意」，通常代表你問太大了。

實操寫法很簡單：你可以直接對 AI 說「把這段重複邏輯合併，但不要改輸出行為」、「把這些變數命名統一，但別動 public interface」。這種 prompt 雖然不性感，但很適合舊 code。

老 AMD GPU 之所以重要，是因為它們真的還在被用

R600 驅動涵蓋 AMD/ATI HD 2000 到 HD 6000 系列，時間大概落在 2007 到 2010 年。這些卡在 GPU 世界裡早就算古董了，可是它們還活在家用主機、實驗室、工控機、老電腦裡。Tom’s Hardware 也提到其中一些卡快 20 年了。這不是懷舊，這是安裝基數。

Linux 一直有個很奇怪但很實際的優勢：它常常比原廠更願意讓舊硬體繼續能用。原因有時候是社群維護，有時候是沒有別人接手驅動路徑。不管原因是什麼，使用者得到的結果都一樣：硬體還能再撐一陣子。你如果碰過「看起來支援、實際上快壞光」的 GPU，就知道這有多煩。比起明確不支援，半死不活的驅動更討厭，因為它會讓人誤以為自己還安全。

所以這種維護工作沒有什麼光環，但很值錢。R600 不是最新遊戲堆疊，不是什麼大新聞主角，它做的事很單純：別讓一批老卡在 Mesa 改動後直接變成磚。

實操上，如果你也在維護 library、plugin、driver，或任何還有老使用者的東西，我會建議你固定留一點時間做「不加功能」的整理。舊碼不是因為沒人愛才需要維護，而是因為它還在被用。

Copilot 在這裡有用，因為瓶頸根本是人的注意力

這篇文章也提到 Linux 社群在維護老驅動時，常常只有少數人，甚至只剩一個人還在動。這句話我看得很有感。問題從來不是 CPU 不夠快，也不是磁碟不夠大，而是人腦的注意力不夠。

一個 subsystem 如果只剩一個 maintainer，每次改動都很貴。你要記得歷史包袱、相容性、罕見分支、那些從來沒寫進文件的假設。AI 最適合的地方，就是幫你把這種重複性工作壓縮掉，讓你把腦力留給真正要判斷的部分。它不是專家，它是加速器。

我喜歡這個案例，因為它很誠實地講出 Copilot 能做什麼、不能做什麼。它可以幫你找 pattern、提議 cleanup、做機械式調整；它不能理解 kernel 維護的社會契約，也不能替你判斷一個 patch 上 stable branch 之後會不會炸。最後還是人說了算。

• 讓 AI 提案，不要讓它批准。
• 測試要貼著改動走，尤其是老 driver。
• 不要假設工具懂歷史脈絡，除非你有先餵給它。

實操寫法：如果你是那個唯一還在碰舊子系統的人，先把不變條件寫出來，再讓 AI 幫你整理周邊的機械改動。它很會搬東西，不太會理解為什麼這些東西不能亂搬。

Linus 的態度很直接：你可以用，但責任還是你的

文章也提到 Linus Torvalds 對 AI 使用並不是完全封殺；Linux 開發可以接受適當的 AI 輔助，但提交時要標註，出問題的人還是要對測試與 bug 負責。這個規則我覺得很正常，甚至可以說是唯一合理的做法。

重點不是「AI 可以免費代工」，而是「你可以用工具，但你要扛結果」。這句話很重要，因為它把責任鏈講清楚了。patch 壞掉，不會因為你旁邊有個模型就飄去雲端。責任還是在送 patch 的人身上。這件事不只適用 kernel，任何嚴肅軟體都該這樣。

我看過不少團隊一旦能產生看起來像樣的 code，就開始偷懶。解法不是禁用工具，而是把 ownership 說死。你要速度，可以；你要方便，可以；但你也要承擔 review、測試、回滾。這樣才健康。

實操上，如果你的團隊真的在用 AI 寫 code，我會建議 commit 或 PR 裡直接註明 AI 參與，並且把測試、benchmark、rollback plan 都歸到作者名下。不要遮，也不要把責任稀釋掉。

我會盯 Amber2，因為它很像真正的維護思路

文章最後提到 Linux 開發者正在討論一個叫「Amber2」的 legacy branch，目標是把 R600 這類舊支援從 Mesa 主線切出去，避免新工作一直踩到老路徑。這種想法我很買單，因為它承認一件事：舊相容性永遠會變成主線負擔。

如果你把「持續演進」和「不能改行為」硬塞在同一棵樹上，最後就是每次新功能都可能順手把老東西弄壞。拆分主線和維護線不會解決一切，但至少能讓舊碼有一個比較安全的地方待著。這比一直把歷史包袱丟回主線乾淨多了。

我在 app backend、SDK、內部 library 都看過這種狀況。只要把「一直在變」和「絕對不能變」混在一起，回歸測試就會越來越痛。分開管理很麻煩，但長期便宜很多。

• 如果你在維護舊 API，考慮獨立 maintenance branch。
• 如果你有老硬體路徑，考慮 compatibility package 或隔離模組。
• 不要讓 mainline 永遠背所有歷史債務。

可抄的模板

# Legacy code cleanup with AI assistance: 可直接套用版

## 目標
用 AI 幫忙整理舊 code，但不改行為。

## 原則
- 人類負責 correctness、測試、合併。
- AI 只負責提議 refactor、命名整理、去重複、機械式修改。
- 不要讓 AI 單獨決定架構或政策。
- 每次改動都要跑 build、test、必要時手動驗證。
- 如果有用 AI，commit 或 PR 要寫清楚。

## 工作流程
1. 先選一個很小的範圍。
   - 一個 function
   - 一組重複判斷
   - 一段命名不一致的邏輯

2. 先寫不變條件。
   - 哪些輸出不能變？
   - 哪些相容性不能壞？
   - 哪些歷史行為要保留？

3. 只叫 AI 做一種變更。
   - 「把這段重複邏輯合併，但不要改行為」
   - 「把這些變數命名統一，但不要改 semantics」
   - 「簡化這個 function 的分支，但保留所有輸出」

4. 逐行 review diff。
   - 任何你沒要求的行為變更都退回
   - 任何更難解釋的 code 都退回

5. 立刻測試。
   - build
   - unit tests
   - subsystem-specific checks
   - 如果是 driver/kernel，盡量上實機

6. commit 時寫清楚。
   - 哪裡用了 AI
   - 哪些地方已驗證
   - 哪些風險你已經看過

## Prompt 模板
你正在幫我重構 legacy code。

限制：
- 不要改行為
- 不要引入不必要的新抽象
- 保留所有 public interface 與相容性
- 優先做小而機械的修改，不要花俏重寫

任務：
請把下面的 code 做可讀性與維護性整理，但行為必須完全一致。

Code:
PASTE_CODE_HERE

輸出：
- 整理後的 code
- 變更摘要
- 我需要手動檢查的風險點

## Commit message 模板
refactor: clean up legacy code with no behavior change

- Simplify repeated logic in the subsystem
- Improve readability of old code paths
- Verified with build/tests/manual inspection
- AI-assisted cleanup reviewed and approved by human maintainer

## PR checklist
- [ ] Scope 小而可 review
- [ ] 行為沒有變
- [ ] Tests 有過
- [ ] 相容性有保住
- [ ] AI 參與有被人工 review
- [ ] PR 說明有寫清楚為什麼要做這次 cleanup

這段就是我會真的拿去用的版本。它不是在吹 AI 多厲害，而是在限制 AI 能做的事，讓它只負責那些最適合它的整理工作。對老驅動、老 library、老 subsystem 來說，這種用法才算有腦。

來源我主要拆的是 Tom’s Hardware 這篇 文章，並參照 Phoronix 的相關脈絡與 Linux kernel、Mesa 的維護背景。上面的模板段落是我自己整理出的可複製版本，不是原文照抄。