如果您曾經使用過 GitHub Copilot 來編寫多個快速樣板程式碼片段，您可能會有這樣的感覺：它很棒……直到它變得不再出色。

前一刻，它還能自動補全你所需的內容。下一刻，它就會自信地產生一堆亂碼，或是加倍使用你程式碼庫中最糟糕的程式碼模式。你瞬間就從「這太神奇了」變成了「我自己寫得更快」 。

問題在於：我們大多數人把 Copilot 當作一個無所不知的助手——一種應該總是「一針見血」的編程神諭。但真正的軟體團隊並非如此。在實際專案中，你不會指望一個開發人員收集需求、設計架構、編寫每一行程式碼、除錯棘手的部分，然後審查自己的工作。那樣只會讓人精疲力竭（並產生 bug）。

那麼我們為什麼期望 Copilot 能夠做到這一點呢？

經過幾個月的試驗，我找到了更好的方法：不再將 Copilot 視為一個助手，而是開始將其視為一個團隊。

就像一個真正的軟體團隊有產品經理、架構師、工程師和審閱者一樣，我建立了一個流程，讓 Copilot 透過角色扮演這些角色。結合堅實的repo 防護措施（類似於 Copilot 的入職文件的說明），Copilot 從一個「不確定的初級開發人員」變成了一個值得信賴的生產程式碼合作夥伴。

在本文中，我將分享我的特定流程，從設定 repo 指令，到定義角色，再到在 Visual Studio Code 聊天模式中切換它們。

🛠️ 為什麼指示很重要

想像一下將一位全新的高級開發人員加入您的倉庫。

你會不會說：

“嘿，這是程式碼庫——祝你好運！”

當然不是。你需要花時間解釋專案的目的、特性、架構模式以及應該避免的「陷阱」。如果沒有這些背景知識，即使是最優秀的開發人員也會陷入程式碼庫中最糟糕的習慣。

GitHub Copilot 的工作原理也正是如此。如果你把它直接放進你的專案中，它會很樂意鏡像它能找到的最醜陋的程式碼——而且它做得非常自信。

這就是repo 指令的作用所在。你可以把它們想像成Copilot 的入門指南。 Copilot無需猜測，就能獲得以下資訊的清晰描述：

• 該專案的內容

• 遵循哪些模式

• 要避免哪些模式

• 倉庫中的內容

📄 我的設定： copilot-instructions.md

我總是先在一個空資料夾中建立一個copilot-instructions.md檔案來啟動一個新專案。這個文件將成為 Copilot 的劇本——護欄 + 快速上下文。

以下是我的Teams Status Manager專案的摘錄：

## Project Overview
**Teams Status Manager**: Create/Edit/Delete reusable Teams status templates, apply on demand, and schedule updates.

**Stack**: .NET 9 Minimal API • React (TypeScript, Vite) • SQL Server • Microsoft Graph SDK • Quartz.NET
**Auth Flow**: SPA → API (custom scope) → On-Behalf-Of (OBO) → Microsoft Graph (`Presence.ReadWrite`)

## Architecture Patterns

### Backend (.NET 9 Minimal API)
- **Endpoints**: Located in `src/backend/TeamsStatusManager.Api/Endpoints/` - separate files per feature
- **Services**: Interface/implementation pattern in `Services/` folder
- **Validation**: FluentValidation validators in `Validators/` folder
- **Jobs**: Quartz.NET jobs in `Jobs/` folder with SQL job store
- **Data**: EF Core entities in `TeamsStatusManager.Data/Entities/`

### Frontend (React + TypeScript)
- **Auth**: MSAL React in `src/auth/` with `AuthProvider.tsx` wrapper
- **Data Fetching**: TanStack Query hooks in `src/hooks/` (co-located with features)
- **Forms**: react-hook-form + zod schemas
- **Components**: Feature-based folders in `src/components/`

這個檔案告訴 Copilot我們在這裡如何建構事物。它不是隨機產生程式碼，而是遵循每個隊友都會遵循的相同架構規則。

⚡ 工作流程

1. 我建立了copilot-instructions.md檔案。

2. 我使用Claude Sonnet 4和/new命令來根據這些護欄建造專案支架。

3. 然後我要求 Copilot 產生用於啟動解決方案的 VS Code 任務。

👥 第二步：像角色團隊一樣工作

即使有可靠的 repo 說明，我意識到我仍然犯了同樣的錯誤：將 Copilot 視為一個可以做所有事情的開發人員——收集需求、設計解決方案、實現它，然後除錯它。

真正的團隊並非如此運作。在真實的專案中，你會：

• 產品經理明確需求

• 設計解決方案的建築師

• 編寫程式碼的工程師

• 審核人員確保所有內容符合規範

• 當然，當東西不可避免地壞了的時候，有人會來修理

那麼為什麼不以同樣的方式與 Copilot 合作呢？

從那時起，我轉向了基於角色的方法。現在，我不再只使用一個 Copilot，而是擁有多個專門的 Copilot 角色，可以根據我所處的開發階段「切換」。

核心人物角色

• 產品經理→收集需求、撰寫使用者故事並明確驗收標準。

• 軟體架構師→制定技術規格（逐步計劃，無程式碼）。

• 工程師→依照規範實作程式碼。

🔧 特別的人

• 問題解決者（狼先生🐺） →除錯棘手的問題並提出解決方案。

• 技術規格審閱者→檢視架構的可擴展性、效能和邊緣情況。

• 實施審查員→依規範審查實際實施情況。

每個角色都有自己的提示（我將在本文後面分享我的提示）和自己的優勢。

💬 在 VS Code 中加入聊天模式

現在最棒的是：你不必每次切換角色時都複製貼上提示。 Visual Studio Code 允許你新增自訂聊天模式，只需點擊一下即可直接進入「產品經理模式」或「狼先生模式」。

設定方法如下：

1. 在 VS Code 中開啟Copilot Chat面板。

2. 點選聊天模式旁邊的“+”按鈕。

3. 給你的模式一個清晰的名字（例如， Software Architect ）。

4. 將您的角色提示貼到配置中。

5. 保存。

現在，無論您何時想讓 Copilot 充當您的架構師、產品經理或問題解決者，只需切換模式即可。無需重複提示，也不會忘記上下文。

例子：

• 我正在收集需求→我轉為產品經理。

• 設計系統→我切換到建築師。

• 除錯一個奇怪的非同步問題→我請來了狼先生。

這感覺不像是與「人工智慧」對話，而更像是在 IDE 內領導專家團隊。

⚙️ 步驟 3：工作流程

有了 repo 指令和使用者角色準備就緒，開發過程不再像是在催促 AI，更像是在協調一個小型開發團隊。每個階段都有各自的“負責人”，Copilot 能夠保持專注，而不是陷入隨機猜測。

以下是我的工作流程在實務上的樣子：

1. 收集需求（產品經理角色）

我從產品經理角色開始，將模糊的功能想法轉化為明確的產品需求。

• 它編寫具有驗收標準的使用者故事。

• 它迫使我澄清邊緣情況。

• 如果缺少細節，它會像真正的 PM 一樣提出問題。

對於每個功能，產品經理在 docs 資料夾內建立一個 PRD 檔案（例如docs/save-data-prd.md ）

這一步可以防止我在真正知道「完成」是什麼樣子之前就倉促實施。

2. 設計解決方案（軟體架構師角色）

一旦確定了需求，我就會切換到軟體架構師角色。

• 它建立了一個技術規格：有關如何實現該功能的逐步說明。

• 它不編寫程式碼——相反，它準確地記錄了變化的位置以及元件應該如何互動。

• 如果有什麼不清楚的地方，它會被標記出來以便澄清。

對於每個功能，軟體架構師在 docs 資料夾內建立技術規格文件（例如docs/save-data-techspec.md ）

此時，Copilot 停止猜測並開始根據具體計劃開展工作。

3. 實現功能（工程師角色）

現在我引進工程師角色。

• 它一步步遵循技術規格。

• 如果它跳過了某些內容，我會提示它檢查自己的工作並填補空白。

• 由於它在 repo 說明 + 技術規範的保護範圍內工作，因此程式碼從一開始就與我的架構保持一致。

這就是生產力提升真正體現的地方：Copilot 編寫程式碼，但它是在我已經定義的框架內進行的。

4. 除錯和測試（特殊角色）

不可避免的是，有些事情沒有如預期進行。這時我就會切換到特殊角色：

• 狼先生（問題解決者） → 就像《低俗小說》裡的修復者一樣，一旦出現問題，他就會立即介入。範例提示：

> “The homepage isn’t updating the user’s status after login. It should show the profile photo in the header. Fix it.”

> 

• 技術規格審閱者→實施前仔細檢查架構。

- Looks for scalability issues, missing edge cases, or race conditions.

• 實施審查員→驗證程式碼是否符合規範。

- Lists issues in order of severity.

- Suggests fixes without rewriting everything.

這些角色使我免於「產生→測試→嘆息→調整→重複」的無限循環。相反，Copilot 成為了我的 QA 安全網。

透過這些階段，我不僅僅是「要求 Copilot 編寫程式碼」。我正在領導一個結構化的過程，其中 AI 扮演著具有特定職責的不同團隊成員的角色。

結果如何？程式碼更可靠，彎路更少，工作流程感覺就像與真正的團隊合作，而不是與自動完成功能作鬥爭。

🧩範例：Teams Status Manager 專案

為了使其不那麼抽象，讓我們來看看如何將此流程應用到實際專案中： Teams Status Manager 。

從紙上看，目標很簡單：

建立、編輯和刪除可重複使用的 Teams 狀態範本。按需應用或安排自動更新。

但正如每位開發者都知道的那樣，「紙上談兵」往往隱藏著許多變數。以下是如何運用基於角色的方法 + 程式碼庫說明來實現的。

📝 步驟 1：Repo 說明

我從copilot-instructions.md檔案開始。

它概述了該專案的目的、堆疊和架構護欄。

這意味著 Copilot 事先知道：

• 後端是.NET 9 最小 API，而不是 MVC。

• 驗證存在於 FluentValidation 類別中。

• 作業使用 Quartz.NET 和 SQL 作業儲存。

• 前端身份驗證流經 MSAL React。

• 資料擷取透過 TanStack Query 進行。

如果沒有這個，Copilot 可能會很隨意地混用各種模式、建立新的資料夾，或是把邏輯塞到錯誤的地方。有了這些說明，它已經感覺自己在我的專案上「受過訓練」了。

🧑‍💼 第二步：角色行動

• 產品經理：將「包含調度的狀態範本」轉換為包含驗收標準的使用者故事。例如：

- *As a user, I can schedule a status change so that my Teams presence updates automatically during a meeting.*

• 軟體架構師：設計流程：

1. Store templates in SQL via EF Core entities.

2. Use Quartz.NET jobs for scheduling.

3. Trigger Microsoft Graph `Presence.ReadWrite` calls through an OBO flow.

• 工程師：依照計畫實作 API 端點和 React 鉤子。

• Wolf先生：除錯了一個棘手的bug，導致伺服器重新啟動後排程作業無法觸發。 Copilot最後建議為Quartz.NET提供一個SQL支援的作業儲存－這個問題就解決了。

• 審查者：根據要求仔細檢查規格和程式碼，發現一些邊緣情況，例如：如果兩個工作重疊會發生什麼？

⚡ 結果

Copilot 並不像真正的開發團隊那樣產生「它認為正確的東西」：

• PM 角色保持需求清晰。

• 建築師的角色使設計保持一致。

• 無需自由職業即可實現工程師角色。

• Wolf 先生和審閱者在問題進入生產之前就發現了它們。

最後，我不僅擁有了可以編譯的程式碼，還擁有了與我的架構一致且可供實際使用者使用的解決方案。

🌟 角色方法的好處

經過幾個月的試驗，這種基於角色的方法徹底改變了我使用 GitHub Copilot 的方式。它不再是“時而精彩，時而令人沮喪”，而是成為了我在實際專案中值得信賴的穩定合作夥伴。

這就是為什麼這種方法如此有效：

✅ 1. 結構戰勝混亂

如果沒有使用者畫像，Copilot 會試圖一次完成所有事情——需求、設計、程式碼、除錯——而且通常會偷工減料。透過分配角色，你可以為互動帶來結構化。 Copilot 就像人類隊友一樣，知道自己的工作。

✅ 2. 回購護欄 = 一致性

copilot-instructions.md檔案是每個接觸該程式碼庫的 AI 助理的入門文件。無論模型如何，架構都保持一致。這減少了「為什麼現在會有一個隨機的 utils 資料夾？」之類的問題。

✅ 3. 更快的迭代，更少的挫折感

當 Copilot 偏離軌道時，您無需與其搏鬥，只需切換角色即可。

• 需要更清楚的說明嗎？那就去找產品經理吧。

• 設計？轉而從事建築師行業。

• 偵錯?叫狼先生來。

這節省了數小時的上下文切換和重新提示的時間。

✅ 4. 內建品質控制

大多數開發人員不會要求 Copilot審查其自身的輸出。借助技術規格審查器和實施審查器，您將獲得一個內建的安全網。它們不僅僅是橡皮圖章——它們會在可擴展性問題、競爭條件和遺漏的步驟影響到您的程式碼之前就將其捕獲。

✅ 5. 隨複雜性擴展

對於一個小功能，也許你只需要專案經理 → 架構師 → 工程師。對於複雜的企業流程，你可以引入審閱者和問題解決者。此模型的擴展性與團隊類似：隨著專案的發展，可以增加更多專家。

總結

GitHub Copilot 經常被宣傳為“AI 結對程式設計師”，但如果你期望它成為一個全知全能的程式夥伴，最終會感到沮喪。真正的突破在於，你不再將 Copilot 視為一個助手，而是將其視為一個團隊。

透過結合：

• Repo 說明→ 你的專案的入門文件和防護措施

• 角色→負責需求、設計、實施、除錯和審查的專門角色

• VS Code 中的聊天模式→ 快速切換角色，無需重新提示

……Copilot 從一個通配符轉變為一個結構化、可靠的合作者。

對我來說，這種方法將 Copilot 從「我有時會與之鬥爭的工具」變成了「我領導的開發團隊」。

👉 不要照搬我的角色－創造你自己的角色。你的 Copilot 團隊會有哪些角色？安全審查員？性能優化員？文件編寫員？

您可以在我建立的這些要點中找到我的所有角色，以便與客戶和社群分享。

{% 嵌入 https://gist.github.com/kasuken/d68d3cabfb22ff75a44b8bd538d5a7ec %}

🔖 維持領先地位

我為 Web 開發人員建立了一個精選 RSS 提要包——一個精心挑選的網路上最佳開發部落格和網站的 OPML 文件。

💡 只需下載，匯入您最喜歡的 RSS 閱讀器（如 Feedly 或 NetNewsWire），即可每天享受新鮮的見解。

👉在 Gumroad 上購買— 保持敏銳，不受噪音幹擾。

原文出處：https://dev.to/this-is-learning/github-copilot-a-persona-based-approach-to-real-world-development-56ee