3 位 Java Champion 如何運用 GitHub Copilot 提升生產力

AI 程式編寫工具可以快速生成程式碼，但單靠速度無法解決最棘手的軟件工程問題。開發人員仍須提供背景資訊、驗證結果、維護程式碼的可維護性，並為推出的產品負責。

為瞭解資深開發人員如何取得平衡，我們訪問了三位 Java Champions，他們都有十多年使用 Java 的經驗。他們分享了在正式環境和開源專案中使用 GitHub Copilot 的具體例子，以及將 AI 生成內容轉化為可靠軟件所採用的做法。

以下是他們分享的建議。

認識 Java Champions

• Vlad Mihalcea，Hypersistence 創辦人，以及《High-Performance Java Persistence》一書作者
• Patrick Baumgartner，42talents 軟件工藝師，擁有 20 多年 Java 經驗
• Frank Delporte，Azul 資深技術撰稿人及 Foojay.io 維護者，擁有 15 多年 Java 經驗

Vlad Mihalcea

GitHub 個人檔案：@vladmihalcea

GitHub Copilot 最近如何幫到你？

我一直使用它來分析、設計和實作 Hypersistence Utils 和 Hypersistence Optimizer 的各種功能。

例如，我一直想開發一個網頁應用程式，提供 Optimizer 事件歷程，讓我們瞭解提升效能的工作如何反映在應用程式效能上。在 AI 出現之前，我一直把這項工作擱置，因為開發起來需要數星期。但使用 Copilot 就像多了一名新隊員，因此我用它建立了一個應用程式，並會在 Hypersistence Optimizer 下一個版本推出。這項工作只花了兩天便完成實作，而不是數星期。

你通常如何使用？你會透過 IDE 外掛，還是 GitHub Copilot 應用程式使用 GitHub Copilot？

我在 IntelliJ IDEA 使用 GitHub Copilot，因為在檢視原始碼或進行偵錯工作階段時使用它很方便。

它作為程式碼助理非常實用，有助我加快調查問題，以及為需要驗證的功能建立原型。

我仍會審查 AI 生成的計劃和程式碼，因為它們的目的是提升我的工作效率，而不是完全取代我。AI 在很多情況下都能提供正確答案，但有時回應仍未如理想，需要我介入處理。

可以分享一些提示和最佳做法嗎？例如，你會使用哪些技能？

我建立了自己的技能，讓 Copilot 生成的任何文字都像是我親手寫的一樣。

這項技能根據我已發表的 65 篇文章，捕捉我的文風，因此生成的草稿讀起來像我的網誌文章，而不是語言模型寫的內容。這對為這個專案撰寫文件非常有用，因為它能讓 LLM 從我 12 年來撰寫網誌的經驗中學習，並提供符合相同原則的例子，例如表達力、可測試性和簡潔性。

在整個軟件工程師生涯中，我體會到，花在維護程式碼上的時間遠多於編寫程式碼。因此，考慮到維護和穩定性對現有產品至關重要，我開發了能協助 AI 模仿現有程式碼慣例的技能，並遵循最少驚訝原則。

其中一個建議是按工作類型更改模型類型。需要深入思考時，我會使用具有 1 million 上下文視窗的 Opus，並選用 Extra High 或 Max 推理。不過，處理較簡單的工作，例如撰寫報告、發行説明或核實文件時，我會使用消耗較少 token 的輕量模型。

Patrick Baumgartner

GitHub 個人檔案：@patbaumgartner

你的工作包括指導團隊。你會採取甚麼方式？

我的很多工作都是在日常業務仍須繼續運作的情況下進行。你不能停下所有工作半年來「轉型」。我們通常會先一起解決當前問題，瞭解團隊目前的狀況，訂明想達到的目標，以及如何判斷是否有所改善，然後一步一步朝目標前進。

視乎情況，這可能包括軟件工藝實踐，例如 TDD、重構、持續交付和 XP；運用 Spring Boot、Spring Modulith 進行架構設計及模組化；Spring Security；為容器環境最佳化 Java 和 Spring Boot 應用程式；或日益受到重視的 Agentic engineering。

對我來説，重要的是我會與團隊一起工作。我們共同作出決定。我不希望團隊變得依賴我。理想的情況是，過了一段時間後，除非需要我作為討論夥伴，否則他們不再需要我。

或許這也解釋了為甚麼我覺得這一代新 AI 工具如此有趣：我喜歡與人合作、學習、實驗和解決問題。AI 為我們提供了另一種非常強大的工具，讓我們可以正正做到這些事情。

可以分享一個 GitHub Copilot 最近如何幫上忙的好例子嗎？

其實有三個截然不同的例子，改變了我對使用 GitHub Copilot 的看法。

先説第一個例子。

其中一個例子，是把 15 份簡報中約 900 張教學投影片由 Reveal.js 遷移至 Marp。這些並非簡單的投影片。很多投影片包含程式碼、動畫，甚至互動範例，讓我可以在授課時即時修改 JavaScript。更重要的是，這些簡報已經在學生面前經過實戰考驗。整個流程行之有效。即使只遺失一個小細節，也可能破壞我在課堂上要講述的故事。

手動進行這次遷移，大概需要一星期或更久；説實在的，由於工作十分繁瑣，我可能乾脆不做。

使用 Copilot 時，我採取了不同的做法。我們先分析現有素材、訂明目標、制定遷移計劃、設定限制條件、提供範例，並界定哪些內容必須保持不變。然後由整體結構變更開始，逐步處理細節。

真正重要的部分是核實。

我們為 Reveal.js 和 Marp 版本產生螢幕截圖，再以視覺方式和演算法進行比較。我們製作了一個小型應用程式，讓我可以並排執行兩套投影片，手動核對動畫。我們甚至比較了產生的 PDF。

這表示 Agent 不只是説「遷移完成」，我們還有證據。

整個遷移過程大約花了我 8 至 10 小時。內容、教學目的，以及每項有意義的變更，仍由我負責。Copilot 可以自動修正錯字，但如果內容、版本、日期或意思有所改動，就需要先討論。

對我來説，這次經驗再次印證一項重要原則：委派執行工作，不委派責任。結果由我負責。

可以分享第二個例子嗎？

另一個例子是使用 Tamboui 建立終端機 UI 應用程式。它最初在 WSL 的 Linux 環境中運作完美，而我完全忘記了有人可能會直接在 Windows CMD 或 PowerShell 中執行它。

後來真的有用戶這樣做了。

他們發現，在某些表單中，按下 Enter 鍵完全沒有反應。這也體現了我深信的一個原則：盡早推出軟件，因為你會從用戶實際使用軟件的方式中學到東西。

我們使用 Copilot 把這些意見轉化為可重現的 UI 測試。在 Linux 上，Copilot 透過 tmux 操作應用程式。與它合作期間，我認識了 psmux，因此也能在 PowerShell 中執行類似的流程。我們重現了問題、建立本機修正，並追查到問題實際出在 Tamboui。我把修正提交到上游，之後獲得合併。

在這項工作中，測試描述本身變得太長，超出可用的上下文容量。因此，我請 Copilot 協助重新設計測試的表示方式。它沒有採用包含識別碼、名稱和重複描述的冗長表格，而是提出精簡得多的箭頭表示法：步驟 → 步驟 → 輸入，只在關鍵之處補充資料。

這令我感到意外。我們不只是在利用 AI 執行資訊，也是在一起探討資訊應如何表示，才能供執行之用。這種表示方式不必以方便人類閲讀為首要目標，但必須保留語義，同時讓 Agent 高效處理。

第三個例子又如何？

第三個例子又完全不同。

一位與我親近的人需要練習數學，我便想：不如我們開發一個小型學習應用程式？

它涵蓋一至四年級的加法、減法、乘法、除法和有餘數的除法。但我不想再開發一個簡單的問答遊戲應用程式。我們與 Copilot 一起研究了間隔重複、即時回饋、自適應難度、激勵方式、合作學習，以及不採用暗黑模式的遊戲化設計等學習方法。

有趣的是，在研究期間，Copilot 質疑了我最初的一個假設。我原本想把應用程式設計成適用於世界各地兒童的通用版本。研究令我們轉而關注實際的學校課程。我意識到，各地引入課題的次序、運算種類和數字範圍都有足夠大的差異，因此沒有必要一開始就把應用程式做成「通用」版本。

因此我們先聚焦瑞士，並據此調整學習進度。由於瑞士是多語言國家，應用程式提供德文、法文、意大利文和英文版本。

應用程式也設有合作及競賽雙人模式。有人答錯時，應用程式會解釋一種解題方法，並透過間隔重複再次提供類似題目。

我刻意選用不設後端的架構。我沒有理由在伺服器收集兒童的個人資料，因此數據會留在裝置上，而應用程式只需託管於 GitHub Pages。

最初只是一項小實驗，現在已在朋友之間使用和分享。它意外地成了一個小產品。

這次經驗讓我看到 Copilot 的另一種用法：不要只用它來實作你的解決方案，也要在開始建置之前，把它當作思辨夥伴，拓展並挑戰解決方案的可能範圍。

你通常如何使用 Copilot？

其實我已不再使用傳統的 Copilot 自動完成體驗。

我的工作幾乎已完全轉向 Agent 式工作流程。

需要緊密的視覺回饋循環時，我會使用 VS Code——例如想仔細查看文件、程式碼、簡報或中間成果，並在過程中按需要調整做法。

處理較大型、以執行為主的任務時，我通常會在終端機使用編碼 Agent。這種情況下，我比較習慣把一部分工作交給它，讓它執行，然後再檢視完整結果。我選用哪種介面，主要取決於我需要哪種回饋循環。

前往 JavaLand 途中，我透過 GitHub 使用編碼 Agent 工作流程，也有一次很有趣的體驗。我當時開始探索一個構想：製作 Maven 外掛程式，最佳化載入哪些 Spring Boot 自動設定。在大約四小時的行程中，我一直用手機引導 Agent：交代任務、檢視它完成的工作、思考下一步，然後發送下一項指示。

抵達時，我已經有一個可運作的 Maven 外掛程式、一條 CI 管線、一套以示例應用程式進行的效能測試，以及能展示最佳化是否確實奏效的報告。

那是我第一次以這種方式工作。我很驚訝它竟然真的可行。我並不是想用手機編寫 Java。我是在 Agent 執行工作的同時，檢視、作出決定並引導它。

如果 MCP 伺服器能提供實用功能或脈絡，我也會使用。例如，我用過 Context7 查閲文件、整合我的 Logseq 知識庫，也試用過 Adobe Premiere Pro 的 MCP 整合。

但我不會只因為可以使用 MCP 就用。如果有好用的 CLI，我通常會選擇 CLI，因為對我來説它更直接、更快捷。

在我的認知中，Agent 也不是「初級開發人員」。我更把它視為切磋夥伴。不過，就像任何加入專案的人一樣，它首先需要熟悉專案情況。

上下文為王。

你可以分享一些技巧和最佳做法嗎？

我最想建議的一點是：不要再採用一次性提示詞。

對於任何較複雜的工作，我都希望在開始執行前先了解問題。我經常會明確要求 Agent 先跟我進行訪談，藉此找出仍未明確説出的假設和期望。

優秀的 Agent 可以極快地執行錯誤的構想，但這不代表繞路的成本會更低。

我在開發 Spring Boot 自動設定最佳化工具時，就親身體會過這一點。起初，我想同時支援 Spring Boot 3.5 和 4.x。由於兩者在架構上有差異，我們便實作了兩種方案。後來我發現已不再需要支援 3.5，移除相關方案卻相當費力。

教訓很簡單：繞路的代價很高。加快進度之前，先確認需求正確。

意圖明確後，我會要求制定計劃。檢視計劃時，我尤其在意四件事：假設是否清楚列明、是否已訂定驗證關卡、做法是否符合架構，以及有沒有避免不必要的工作？

第二項原則是為每項任務訂定專屬的驗證關卡。

「完成」不應只代表模型説已經完成。

重構工作的驗證關卡可以包括：測試通過、確認所有目標檔案均已處理、更新文件，以及沒有遺留 TODO。至於簡報遷移工作，驗證關卡則包括截圖、視覺差異比較、動畫、PDF 輸出，以及內容完整性。

閘門取決於任務，但原則不變：Agent 應能提供證據，證明工作符合完成標準。

我最近接觸到一項名為 unlazy 的技能，理念相近：設定明確的關卡，按步驟逐一完成，並證明每個關卡都已完成，而不是走捷徑。

第三項原則是把經驗轉化為可重用的技能。

我開始撰寫和維護自己的 Agent Skills。每當我從一次執行中學到新東西，例如 Agent 誤解了某項慣例、缺少實用的檢查，或我找到更好的任務處理方法，我便會更新技能。

下次執行同一項任務時，相關經驗已經融入其中。

其中一個例子是我稱為 maintainer-audit 的技能，靈感來自開放的 Agent Skills 社羣。我會在自己的不同程式碼庫中使用它。它會檢查並在適當情況下修正我認為一個持續維護的專案應具備的項目：程式碼庫文件、CI 流程、Dependabot 設定、CodeQL、一致的清理工作，以及其他專案標準。

目標不是再產生一份審核報告讓我閲讀，而是自動讓程式碼庫回到我期望的基準。這令我的專案更加一致，也更容易維護。

我把這些技能視為持續演進的工程知識，而不是靜態提示詞。

第四項原則是在機率模型周圍配備確定性的工程工具。

我有一套自己的品質檢查框架，會整合 Checkstyle、PMD 和 Spring Modulith 架構檢查等工具，並產生 Agent 可讀取的綜合報告。我可以透過 hooks 執行這套框架，讓 Agent 反覆迭代：

修改 → 執行檢查 → 閲讀檢查結果 → 修正 → 再次執行。

它會持續執行，直至沒有任何檢查結果為止。

這不代表我不再檢視軟件。我仍會執行應用程式，與它互動，並判斷它的行為和外觀是否符合預期。有時我會刻意逐項實作功能，因為這樣的回饋循環緊密得多。

我明白到，因為「AI 做得到」便要求它一次過完成所有事情，通常不是好主意。大型而籠統的規格會產生大型而籠統的實作，之後整理它們，可能比循序漸進地正確建構更困難。

更廣泛而言，我認為開發者需要多談談如何使用這些工具。分享成功的實驗，也分享失敗的嘗試。彼此借鑑想法，並按自己的情境加以調整，而不是尋找一套通用的 AI 開發流程。

這也是我喜歡把 AI 視為切磋夥伴的原因。星期五晚上，當我想試驗某些東西，卻找不到人一起結對時，我突然有某個人——或某種東西——可以一起探討想法、檢視做法，或充當一隻非常高階的橡皮鴨。

不過，我仍會把這些想法帶回去和真人交流。人類的回饋、對產品的理解，以及現實世界的背景資訊，仍然不可或缺。

你認為 AI 正如何改變我們的專業？

我認為軟件工程學生不應主要以成為產生程式碼的機器為志向，而應成為出色的問題解決者。他們需要了解用戶和持份者，找出需求背後的真正問題，質疑假設，理解產品和市場，權衡架構取捨，保持批判思考，以有條理的方式工作，並把有用的解決方案由一種情境應用到另一種情境。

這個模型在提出各種可能方案和執行工作方面表現出色。但作為人類，我通常更瞭解實際情況，包括那些從未有人記錄下來的事情。

因此，我希望繼續掌握解決方案的設計方向，並讓 Agent 接手更多執行工作。

從這個角度來説，我認為AI 正讓工程重新回歸軟件工程。

我很喜歡這一點。

Frank Delporte

GitHub 個人檔案：@FDelporte

你是如何踏入科技界的？

我 11 歲時收到 Commodore 64，從此對電腦著迷。離校後，我曾轉向影片製作和電視工作，繞了一些路，後來又回到程式編寫，因為當時需要把影片製作成 DVD，而且首批網站也開始出現……沒錯，我已經這麼老了 ;-).

GitHub Copilot 最近如何幫到你？

它是評估 Pull Request 和調查錯誤報告的完美助手。

有一個值得一提的例子，是Pi4J 程式庫。它讓你可以建立 Java 應用程式，與 Raspberry Pi 上的電子元件互動。2026 年 2 月，我們發布了 V4，當中有一個使用 Foreign Function & Memory API 的新外掛程式。發布前，我們已進行全面測試，但發布後不久，仍有人回報使用 5 個輸入按鈕時運作未如預期。按下已設定的頭四個按鈕之一，會如預期觸發程式碼執行，但按下第五個按鈕則毫無反應。

這種回報是最不想收到的。表面上看不出任何故障。沒有例外，也沒有日誌警告；第五個按鈕只是毫無反應。情況還更糟：使用舊版 gpiod 外掛程式時，完全相同的硬件和應用程式卻運作正常。因此，問題出在我們新的 FFM 程式碼。這部分建基於 Linux 核心的 GPIO 字元裝置，並透過原生呼叫與其通訊。你不會預期能在程式碼庫的這個部分迅速找到答案。

於是，我把問題指派給 Copilot coding agent，並提供兩個檔案路徑作為起點：provider 類別和 FFMDigitalInput。大約半小時後，就出現了一個 Pull Request，當中附有一個我完全沒料到的解釋。

每個輸入都會執行一個事件監察器，在原生 poll() 呼叫中阻塞，等待核心回報其 GPIO 線路上的變化。這些監察器在虛擬執行緒中執行。虛擬執行緒若在原生呼叫內阻塞，便無法從其載體執行緒卸載；在整個呼叫期間，它都會固定在該執行緒上。Raspberry Pi 4 配備四個核心，因此虛擬執行緒排程器有四個載體執行緒。註冊四個輸入後，四個載體執行緒便會永遠停泊在 poll() 中。第五個監察器雖然建立了，卻永遠不會獲得排程。這正是回報的錯誤：不是「事件時有時無」，而是「第五個完全沒有反應」。

我最欣賞的不是程式碼差異，而是審查過程中接下來的對話。我留言請 Copilot 詳細解釋這一點：

我以為虛擬執行緒的目標正是擺脱平台執行緒數量限制？那麼，四個虛擬執行緒阻塞 Raspberry Pi 這類四核心處理器上的四個執行緒，為甚麼會構成問題？

查看Pull Request，瞭解完整對話。Copilot 成功將配備四個 CPU 核心的 Raspberry Pi 與回報的問題連繫起來。它提出了簡單的修正方法，並額外提出調查期間發現的一些改進。

可以分享一些提示和最佳做法嗎？

• 告訴它要查看的位置：處理 Pi4J 問題 #622 時，我加入了兩個檔案路徑。這只需花一點點工夫，卻能省下在大型程式碼庫中大量搜尋的時間。即使你完全不知道錯誤在哪裏，通常也會大概知道問題可能在哪個範圍。把這些資訊提供給工具，它就不用檢查整個程式碼庫。
• 要求提供佐證和測試：「新增單元測試以驗證這項修改」是我最近經常提出的要求。更準確地説，是以前經常這樣要求，因為這已經成為我指示檔中的一條規則。這也能避免診斷錯誤的情況，因為在舊程式碼上，測試不會失敗。
• 追問原因：如果你不明白某項修正，就直説並提出問題。説明也是交付成果，應加入專案文件，或寫在工單或 pull request 內，讓日後閲讀相關資訊的人都能從中學到東西。例如，這也令 Pi4J 團隊進一步討論原生呼叫中的虛擬執行緒固定問題。
• 保持掌控：Pi4J 的所有這些 pull request 在合併前，都經過維護者審查和批准。這是最適合這個專案的模式：由 Agent 負責調查，人類則對最終發布的內容負責。不過，在其他專案中，我也總會審查工具生成的程式碼。我始終希望程式碼易於閲讀和維護。工具經常建立重複的方法，或重新建立其他地方已有、原本應該整合的內容。這是你的責任。如今透過 AI 輔助編碼，你可以大幅加快速度，也意味着你很快就可能把程式碼弄得一團糟。不要這樣做，保持程式碼易於管理；日後同事或未來的自己需要調查錯誤或作出改進時，都會感謝你。

開始使用 GitHub Copilot >

文章3 位 Java Champions 如何使用 GitHub Copilot 提高生產力最初刊載於The GitHub Blog。