VS Code 結對 GitHub Copilot：讓 AI 讀懂專案脈絡的進階設定指南
☰ 目錄 table-of-contents.md
VS Code + GitHub Copilot 的價值，不在「補全程式碼」，而在「重組你的工作流」
把 GitHub Copilot 從「自動補全工具」用成「AI 結對程式設計夥伴」，關鍵不是按更多 Tab，而是讓它讀懂你的專案脈絡，透過專案規範檔、上下文指令與註解驅動，把 AI 從亂猜變成穩定產出符合團隊規範的程式碼。
本文針對 WordPress / Laravel 開發者，拆解三件事：該打開哪些設定、怎麼用註解與 Inline Chat 驅動產出、怎麼用 @workspace 讓 AI 理解整個專案。讀完你會有一套可以照抄的「結對程式設計」流程，而不是又一篇喊口號的工具介紹。
我是 Eric，浪花科技的資深工程師。這幾年 AI 輔助開發工具（AI Coding Assistants）已經從「玩具」進化成日常生產工具。微軟與 GitHub 聯手的 VS Code + GitHub Copilot 組合，更像是一個坐在你旁邊、隨時懂你意圖的資深同事——這就是所謂的 AI 結對程式設計（AI Pair Programming）。
為什麼到了 2026 年還在談 VS Code + Copilot？
市面上有 Cursor、Antigravity 等強調「AI Native」的編輯器，但在企業級開發環境中，VS Code 憑藉龐大的擴充生態系與 GitHub Copilot 的深度整合，依然是主流選擇。重點從來不是工具多新，而是你如何建立「工作流」。
Copilot 的核心能力，也已經從單純的「猜下一行程式碼」延伸到「理解專案全貌」。這帶來三個實際差異：
- 上下文感知（Context Awareness）：它能參考你專案裡
functions.php與style.css之間的關聯，而不只是看當前游標那一行。 - 意圖預測（Intent Prediction）：當你開始寫一個 WooCommerce 的 Hook，它傾向補完整段邏輯，而非只補語法。
- 多模態互動：除了打字，語音指令與圖形化介面的整合也更成熟。
結對程式設計到底改變了什麼？
傳統結對程式設計（Pair Programming）有兩個角色：一個人「駕駛」（Driver）負責敲鍵盤，一個人「導航」（Navigator）負責思考方向與抓錯。AI 結對程式設計的本質，是讓 Copilot 接手大量「駕駛」的機械勞動，而你升格為全程「導航」——專注在定義問題、審查邏輯、把關品質。理解這個角色轉換，後面所有技巧才會有意義。
環境建置：怎麼讓 Copilot 讀懂你的心？
工欲善其事，必先利其器。別只是裝了擴充套件就以為大功告成，以下是幾個直接影響產出品質的關鍵設定。
1. 啟用並熟悉 GitHub Copilot Chat
現在的 Copilot Chat 已深度整合在 Sidebar 與 Inline 中。請確認設定中啟用了自動補全，並把喚醒 Inline Chat 的快速鍵變成肌肉記憶：
// settings.json
"github.copilot.editor.enableAutoCompletions": true- Inline Chat 喚醒鍵：Mac 為
Cmd+I，Windows 為Ctrl+I。 - 使用時機：當你想「就地」對某段程式碼下指令（重構、補測試、改寫），用 Inline Chat 比切到側邊欄更不打斷思路。
2. 設定 .github/copilot-instructions.md
這是讓團隊產出趨於一致的關鍵一步。你可以在專案根目錄放一個 Markdown 檔案，告訴 Copilot 這個專案的「開發規範」，它會在生成建議時把這些規則納入考量。
# Copilot Instructions for WordPress Project
- 使用 WordPress Coding Standards (WPCS)。
- 所有函式必須加上 PHPDoc。
- 優先使用 `get_posts()` 而非 `WP_Query`，除非有複雜查詢需求。
- 禁止直接在 Template 中寫商業邏輯，請使用 Hook。
- 安全性優先：所有輸出必須經過 `esc_html()`、`esc_url()` 等函式處理。加上這個檔案後，Copilot 吐出的程式碼會更傾向遵守你們公司的 Coding Style，比起在每一次 Prompt 裡反覆強調，這種「一次設定、全專案生效」的方式有效率得多。
實務建議：把
copilot-instructions.md一起納入版控（Git）。它本身就是團隊規範的一部分，新進成員 clone 專案下來，連同 AI 的行為準則都一起帶走了。
實戰演練：用 AI 結對流程開發一個 WordPress 短代碼
我們用一個真實場景示範：要為客戶開發一個「自訂短代碼（Shortcode）」[recent_posts]，用來顯示最近的文章。
傳統寫法 vs. AI Pair Programming
以前你可能得先去查文件、確認 add_shortcode() 的參數，再手刻迴圈。現在流程可以這樣走。
步驟一：用註解驅動開發（Comment Driven Development）
在 PHP 檔案中，先把你的「意圖」寫成註解。這一步的價值在於：你被迫先想清楚需求，AI 也拿到了明確的規格。
// 建立一個 shortcode [recent_posts]，顯示最新的 3 篇文章
// 參數：count (預設 3)、category (選填)
// 輸出格式：HTML ul > li，包含縮圖與標題
// 注意：需做 security escaping步驟二：用 Inline Chat 把意圖變成程式碼
按下 Cmd+I 喚醒 Inline Chat，給它一段明確的指令：
「寫一個 WordPress Shortcode，依照上方的註解需求，並使用 output buffering 來處理 HTML 輸出，確保符合 WordPress 安全規範。」
Copilot 生成的程式碼大致如下（已補上正確的迴圈與逐項輸出的跳脫處理）：
/**
* Shortcode [recent_posts] - 顯示最新文章列表。
*
* @param array $atts 短代碼屬性。
* @return string 已產生的 HTML。
*/
function roamer_recent_posts_shortcode( $atts ) {
$atts = shortcode_atts(
array(
'count' => 3,
'category' => '',
),
$atts,
'recent_posts'
);
$args = array(
'post_type' => 'post',
'posts_per_page' => intval( $atts['count'] ),
'post_status' => 'publish',
);
if ( ! empty( $atts['category'] ) ) {
$args['category_name'] = sanitize_text_field( $atts['category'] );
}
$query = new WP_Query( $args );
ob_start();
if ( $query->have_posts() ) {
echo '<ul class="roamer-recent-posts">';
while ( $query->have_posts() ) {
$query->the_post();
echo '<li>';
echo '<a href="' . esc_url( get_permalink() ) . '">';
if ( has_post_thumbnail() ) {
echo '<span class="post-thumbnail">' . get_the_post_thumbnail( get_the_ID(), 'thumbnail' ) . '</span>';
}
echo '<span class="post-title">' . esc_html( get_the_title() ) . '</span>';
echo '</a>';
echo '</li>';
}
echo '</ul>';
wp_reset_postdata();
} else {
echo '<p>' . esc_html__( '沒有相關文章。', 'roamer' ) . '</p>';
}
return ob_get_clean();
}
add_shortcode( 'recent_posts', 'roamer_recent_posts_shortcode' );重點不只是「它幫你寫好了」，而是它連 ob_start()、esc_url()、esc_html() 這些安全處理都顧到了。此刻你的角色就從「寫程式」轉成「Code Reviewer」：你要驗證的是邏輯與安全性，而不是糾結語法。
審查時要盯什麼？
AI 產出的程式碼能跑，不代表正確。把這幾點當成固定檢查清單：
- 所有輸出是否都經過跳脫？網址用
esc_url()、純文字用esc_html()，缺一個都是潛在 XSS。 - 使用者輸入是否清理？例如範例中對
category用了sanitize_text_field()。 - 是否呼叫了
wp_reset_postdata()？自訂WP_Query後忘記重置，會污染同頁面後續的主迴圈。 - 邊界情境是否成立？沒有文章、沒有縮圖時的輸出是否合理。
進階心法：用 @workspace 做「上下文工程」
使用 Copilot 最容易被低估的技巧，就是上下文工程（Context Engineering）。很多時候 AI 的答案很離譜，並不是它笨，而是它根本不知道你的專案長什麼樣。
在 VS Code 的 Chat 視窗中，善用 @workspace 把整個專案納入提問範圍，並用 #file 精準指定檔案：
@workspace 解釋這個專案的資料庫結構是如何定義的？@workspace /fix 這個函式為什麼抓不到 WooCommerce 的訂單資料？@workspace #file:functions.php 幫我檢查這支檔案有沒有潛在的 SQL Injection 風險。
透過指定範圍，你可以讓 AI 在數秒內讀完數十個檔案的關聯，這是人類大腦很難在短時間內做到的。一個實用原則是：問題愈聚焦，範圍就給得愈窄——能用 #file 指定單一檔案，就不要動用整個 @workspace，回答會更準、也更省脈絡。
工程師的提醒：AI 不是萬能丹
我很推崇 AI 結對程式設計，但仍要嘮叨幾句：不要把大腦完全外包給 AI。Copilot 偶爾還是會「一本正經地胡說八道」（也就是幻覺），尤其在處理很舊的 WordPress 函式、或很新的第三方 API 時特別明顯——因為這兩種情境的訓練資料都相對稀少。
保持懷疑，保持測試。 寫完功能後，順手叫 Copilot 幫你補測試，把驗證也納入流程：
「為剛剛的
roamer_recent_posts_shortcode函式撰寫 PHPUnit 測試案例，包含有縮圖和沒縮圖的情境。」
讓 AI 寫測試有個額外好處：你會被迫去思考「正確的行為應該是什麼」，而這正是 AI 無法替你決定的部分。
結論：從 Coder 進化為 Architect
VS Code + GitHub Copilot 的真正價值，是釋放你的大腦頻寬。當你不必再去記憶 WP_Query 的每一個參數，就能把精力投入到「系統架構設計」、「使用者體驗優化」與「商業邏輯」上。
說到底，這個時代的工程師，比拼的不再是打字速度，而是「定義問題」與「引導 AI」的能力。把本文的設定與流程套進你的日常，你會逐漸感受到那種行雲流水的開發節奏。
如果你對企業級的 WordPress 開發、AI 導入流程有任何疑問，或需要更深入的技術諮詢，歡迎隨時找我們聊聊。
延伸閱讀
常見問題
GitHub Copilot 最大的價值是程式碼自動補全嗎？
.github/copilot-instructions.md 檔案有什麼用？
AI 結對程式設計改變了開發者的角色嗎？
什麼是註解驅動開發（Comment Driven Development）？
審查 AI 生成的程式碼時應該重點檢查什麼？
訂閱免費電子報
把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧，整理成電子報寄給你。只寄精選內容、不灌垃圾信，一鍵就能退訂。