提示詞寫法

Prompt 不是越長越好，而是要讓 Copilot 明確知道：你要什麼、它能看什麼、不能碰什麼、怎麼判斷完成。GitHub 官方 prompt engineering 頁給出的策略可以收斂成一條主線：先給目標，再補上下文、例子和約束，最後迭代——這條主線對中英文 prompt 都一樣適用，但中文教程裡的示例會給出中文版。

這頁面向真實工程專案，不寫“萬能咒語”。每個 prompt 都應該能回到 diff、test、reference 或 review，而不是隻看回答是否順眼。

閱讀目標：讀完本章，你應該能把一句“幫我最佳化一下”改成可審查、可執行、可驗收的 Copilot prompt。

1. 官方策略地圖

GitHub 官方頁面列出的核心策略包括：

Start general, then get specific：先給總體目標，再列具體要求。
Give examples：給輸入、輸出、實現風格或測試示例。
Break complex tasks into simpler tasks：複雜任務拆成小任務逐步完成。
Avoid ambiguity：不要用含混的 “this”；明確函式、檔案或上一次回答。
Indicate relevant code：開啟相關檔案、選中程式碼，或用 @workspace、@project 等上下文入口。
Experiment and iterate：結果不對就迭代，不要把第一版當終稿。
Keep history relevant：新任務開新 thread，刪除無關歷史。
Follow good coding practices：程式碼本身要清晰、有測試、有一致風格。

flowchart TD
    Goal["總體目標"] --> Details["具體要求"]
    Details --> Context["相關程式碼 / 檔案 / 選區"]
    Context --> Examples["輸入輸出 / 測試 / 示例"]
    Examples --> Constraints["邊界 / 禁止事項"]
    Constraints --> Review["驗收標準"]
    Review --> Iterate{"結果是否滿足?"}
    Iterate -->|否| Refine["補上下文或縮小任務"]
    Refine --> Context
    Iterate -->|是| Apply["進入 diff / test / review"]

    style Context fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style Review fill:#dcfce7,stroke:#16a34a,stroke-width:2px

2. 一個可用結構

推薦把工程 prompt 寫成 5 塊：

目标：
修复登录失败时的错误提示

上下文：
只看 auth 模块和当前测试

限制：
不要改数据库 schema
不要新增依赖

输出：
先给计划
再改代码

验收：
运行 auth 测试
说明 diff 摘要

這不是固定模板，而是檢查清單。缺一塊時，Copilot 可能仍會回答，但你會更難判斷它為什麼這樣回答。

3. 例子和測試是高質量上下文

官方頁面強調 examples。工程裡最有價值的例子通常不是自然語言，而是：

現有相似函式。
現有測試風格。
輸入輸出樣例。
錯誤堆疊中最小必要片段。
API contract 或 schema 摘要。
你希望保留的命名和錯誤處理方式。

單元測試也可以反過來當例子：先讓 Copilot 寫測試，再讓它按測試實現。這樣輸出會更容易驗收。

4. 複雜任務先拆

不要讓 Copilot 一口氣“重構整個系統”。官方建議把複雜任務拆成小任務。商業專案裡可以這樣拆：

先讓它解釋當前模組職責。
再讓它找測試入口和風險點。
再讓它給 plan，不改檔案。
再讓它只改一個小範圍。
最後執行測試並總結 diff。

如果任務已經超過 Chat 能安全完成的範圍，切到 Plan mode 或 Agent mode，但仍然保留同樣的邊界和驗收。

5. 避免含混詞

低質量 prompt：

这段代码做什么？

更穩的 prompt：

解释 src/auth/user.ts 里的 createUser 函数。
重点说明：
1. 它的输入参数和返回值
2. 它会产生哪些副作用（数据库写入、外部 API 调用等）
3. 修改时我应该运行哪些测试

“this”“that”“最佳化一下”“修一下”都會讓 Copilot 猜上下文。能命名函式就命名函式，能給檔案就給檔案，能貼錯誤就貼最小錯誤。

6. 保持歷史乾淨

Copilot Chat 會使用 chat history 作為上下文。歷史上下文越亂，回答越可能把舊任務、舊約束或舊檔案帶進來。

建議：

新任務開新 thread。
同一 thread 只保留同一問題鏈。
失敗的 prompt 不要無限堆疊，必要時重新開始。
不要在同一 conversation 裡混用無關專案。

深讀：為什麼 prompt 質量和程式碼質量互相影響

官方頁面提醒：如果程式碼本身命名混亂、結構過長、缺測試，Copilot 更難生成好結果。Prompt 不是補償爛上下文的萬能手段。

更現實的做法是雙向改進：用 Copilot 幫你補註釋、拆函式、補測試，同時讓程式碼庫越來越適合 AI 和人類共同閱讀。

本章自檢

完成本章後，用這 4 個問題檢查：

Prompt 是否有明確目標，而不是一句泛泛請求？
是否給了必要程式碼、檔案、選區、錯誤或測試上下文？
是否寫了邊界：不能改哪裡、不能新增什麼、不能執行什麼？
是否寫了驗收：diff、測試、型別檢查、引用或 PR review？

透過標準：別人看到你的 prompt，也能判斷 Copilot 的輸出該如何驗收。

官方來源

Prompt engineering for GitHub Copilot Chat —— 官方 prompting 策略頁，覆蓋目標、例子、拆解、消歧、上下文、迭代和歷史管理。
Asking GitHub Copilot questions in your IDE —— 官方 IDE Chat 頁面，用於核對 @、/、#、Plan mode 和 Agent mode。
Responsible use of GitHub Copilot Chat in your IDE —— 官方 responsible use 頁面，用於核對輸出審查風險。

接下來去哪

響應定製

把反覆出現的規則沉澱進 instructions，不要每次 prompt 重寫。

VS Code Agent mode

任務需要多步驟執行時，繼續學習 agent 的計劃、工具和驗收。

提示詞寫法

響應定製

VS Code Agent mode

本頁目錄