對於許多 .NET 開發者來說，剛開始使用 GitHub Copilot 時，最容易陷入的誤區是試圖學習所有功能，或者將其僅僅視為一個強大的「自動補全」工具。事實上，Copilot 的真正價值不在於幫你寫幾行 C# 程式碼，而是在於如何根據你目前面對的任務，選擇正確的互動模式。
從簡單的 Inline Completions（行內補全）到 Chat（對話模式），再到 Agentic Workflows（代理人工作流），這三者解決的問題層級完全不同。
理解三種互動模式的差異
首先是行內補全，這適合處理重複性高且單純的任務，例如撰寫 LINQ 表達式、定義 DTO（資料傳輸物件，用於在不同層級間傳遞數據）或快速搭建 Minimal API 的端點。
接著是對話模式，這是一種「推理」過程。當你需要理解複雜的舊代碼、比較兩種實作方案、或是規劃重構步驟時，Chat 是最佳選擇。它能幫你分析現有 codebase（代碼庫）的脈絡，而不是盲目地生成新代碼。
最後是代理人工作流，這是目前最高階的運用方式。它不再僅僅是給你答案，而是要求 Copilot 「執行一項工作」。這類任務通常具有明確的範圍、定義好的完成標準，且結果可以透過 Diff（差異比對）來審核。
選擇正確的工具場景
Copilot 提供了多種介面，每種介面在 .NET 開發中的適用場景不同，開發者應根據任務而非工具來決定使用對象。
Visual Studio 適合深耕於方案內部。當你面對一個擁有大量依賴項的舊版 ASP.NET Core 服務，需要分析業務邏輯與基礎設施層的區分，或者在既有的方案結構下規劃重構時，Visual Studio 的整合環境能提供最強的上下文支持。
VS Code 適合跨領域的變更。在 .NET 開發中，經常需要同時修改 C# 代碼、OpenAPI 描述檔、部署設定（如 Bicep 模板）以及 GitHub Actions 工作流。VS Code 處理這種跨文件、跨語言的任務時更加靈活。
Copilot CLI 適合處理終端機任務。當 dotnet build 或 dotnet test 失敗時，錯誤訊息就在終端機中。直接在 CLI 中詢問 Copilot 為什麼構建失敗，並請它建議接下來要執行的除錯指令，比將錯誤訊息複製到搜尋引擎更高效。
雲端編碼代理人則適合委派邊界清晰的背景任務。例如在整個 API 與背景工作管線中加入 Correlation ID（關聯 ID，用於追蹤跨服務的請求流向），這類任務範圍廣但目標明確，適合讓代理人在背景完成後，再由開發者進行 PR（拉取請求）審核。
實務中的 Prompt 撰寫技巧
要讓 Copilot 產出高品質的工程結果，Prompt（提示詞）不能太模糊。一個專業的 .NET 工程提示詞應包含四個要素：目標、上下文（代碼或錯誤輸出）、限制條件以及預期的輸出格式。
錯誤範例：請優化這段代碼。 正確範例：請重構這個背景工作處理程序，使重試策略更容易被測試。請保持公開行為不變，保留結構化日誌記錄，並列出我應該增加的測試案例。
將提示詞寫得像「代碼審查評論」或「工程任務單」，Copilot 給出的答案才會具備工程實務的價值。
如何決定使用 Chat 還是 Agentic 工作流
對於 Junior 工程師來說，最簡單的判斷標準是：你想要的是「建議」還是「結果」。
如果你需要理解、比較、概述或起草方案，請使用 Chat。例如：請解釋這個服務的職責並建議重構方向。
如果你需要變更、驗證、更新或交付一個可審核的結果，請使用 Agentic 工作流。例如：請執行該重構，更新相關單元測試，並確保公開接口（Public Contract）不變。
只要你能定義清楚什麼叫作完成（Definition of Done），且你願意像審核同事的代碼一樣審核 AI 的產出，這項任務就適合委派給代理人。
總結
Copilot 的核心價值在於協助開發者進行推理，並在範圍明確時承接部分重複性工作。建議從後端待辦清單中的真實任務開始嘗試：分析一個複雜服務、為邊緣案例補齊單元測試、或是修正一個構建錯誤。當你不再把它當成翻譯機，而是當成一名可以協作的工程夥伴時，開發效率才會真正提升。
來源：devblogs.microsoft.com - Doing More with GitHub Copilot as a .NET Developer
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。