以下是針對 VS Code + GitHub Copilot 使用者，製作類似專業技能組的實戰步驟：

1. 建立你的技能存放庫（Skill Repository）

在 VS Code 中，這不是透過外掛安裝，而是透過結構化的 Markdown 檔案來管理。

• 在你的專案根目錄建立一個 .github/copilot-instructions.md 檔案（這是 Copilot 官方支援的自訂指令路徑）。
• 或者建立一個 .prompts/ 資料夾，將不同的技能寫成獨立的 .md 檔案（例如 ui-ux-pro.md）。

2. 編寫技能的核心內容

你可以參考 UI-UX Pro Max 的邏輯，將專業知識寫入這些 Markdown 檔案中。檔案結構建議如下：

• 角色設定：定義 Copilot 現在是哪方面的專家（例如：資深前端設計師）。
• 規範與約束：條列絕對不能犯的錯誤（例如：不可使用超過三種主色）。
• 風格參考：直接將專業的 CSS 變數、字體組合或配色方案寫進去。
• 工作流步驟：告訴 Copilot 收到指令後，第一步先產出設計稿，第二步寫 HTML，第三步優化 Accessibility。

3. 如何在 VS Code 中「觸發」技能

有了這些檔案後，你可以透過以下2種方式讓 Copilot 執行：

• 自動引用：(推薦)
  如果你將指令寫在 .github/copilot-instructions.md，Copilot 在處理該專案的所有對話時都會自動參考這些規則。
• 手動引用（# 符號）：
  在 Copilot Chat 中輸入內容時，使用 # 鍵指向你的技能檔案。
  • 範例：請參考 #ui-ux-pro.md 幫我寫一個登入頁面。
  • 這樣 Copilot 就會讀取該檔案內的專業規範來撰寫程式碼。

4. 製作類似 Skill Creator 的自動化流程

如果你想要像影片中那樣「自動生成技能」，可以利用 Copilot Chat 的對話能力：

1. 開啟 Copilot Chat。
2. 輸入指令：我想要建立一個關於 [特定功能] 的專業規範檔案。請幫我寫一個詳細的 Markdown 文件，包含專家角色、程式碼標準、常見模式與禁止事項。
3. 讓 Copilot 生成內容後，將其存入你的 .prompts/ 資料夾。

5. 跨專案複用技能

如果你希望所有專案都能用到這個技能：

• VS Code 設定：進入 Settings -> 搜尋 github.copilot.chat.customInstructions。
• 貼入路徑或內容：將你寫好的通用技能規範貼進去。這樣不論你開啟哪個資料夾，Copilot 都會帶入這套專業邏輯。

雖然沒有自動化的安裝指令，但這種方式能讓你更精確地掌控 Copilot 的產出品質。你想先試著為哪種任務（例如：程式碼重構、單元測試生成）建立第一套 Copilot 技能規範嗎？

以寫文章這作事來說，以下是在 VS Code 中實作 blog-title-writer 技能的步驟：

在 VS Code + GitHub Copilot 的環境下，確實有比每次手動輸入 #路徑更簡單、更直覺的觸發方式。這讓你可以像在使用一個內建功能一樣，直接對 Copilot 下指令，而不需要每次都指定去開啟 .md 檔案。

這是目前 VS Code 中最接近「設定一次，永久使用」的實作方式。Copilot 會將這些指令視為所有對話的「背景知識」和「全局規範」。

實作步驟：

複製你的 Prompt 核心內容

將你確認好的 Skill 內文 Prompt（例如：blog-title-writer 的 #指令與規範 部分）複製下來。

你是知識型部落格的資深編輯。當使用者提供文章內容並說出「幫我取標題」時，請執行以下動作：
1. 分析文章的核心概念與關鍵字。
2. 產出 4 個不同的標題選項。
3. **標題風格規範**：簡潔有力、專業、具備啟發性。
4. **目標受眾**：適合 30-45 歲的知識工作者閱讀。

開啟 VS Code 設定

• 在 Windows/Linux 上：File > Preferences > Settings
• 在 macOS 上：Code > Preferences > Settings

或者使用快捷鍵：Ctrl+, (Windows/Linux) 或 Cmd+, (macOS)

貼入指令

在設定搜尋框中輸入：github.copilot.chat.customInstructions。

在出現的輸入框中，將剛剛複製的 Prompt 內容貼進去。

如何觸發（超級簡單）：

現在，你不需要指定檔案，不需要使用 @workspace 或 #。只需開啟 Copilot Chat ( Ctrl+I 或介面按鈕)，貼上文章並直接輸入：

幫我取標題

Copilot 就會自動套用你設定好的「資深編輯」角色和所有規範來產出標題。

UI-UX Pro Max 在 VS Code 的實作邏輯

UI-UX Pro Max 專案就是利用這種自訂指令的方式。它將數千字的專業設計規範、配色方案和工作流，整合成一套龐大的全局指令，貼入 Copilot 的設定中。

它的觸發方式通常是：

在 Copilot Chat 中直接輸入：

• 幫我設計一個符合 [SaaS 風格] 的登入頁面
• 幫我生成一組符合 [Apple 風格] 的配色變數

因為指令已經成為 Copilot 的「大腦一部分」，它一看到特定的關鍵字（如 [SaaS 風格]、[Apple 風格]），就會自動從「自訂指令」中調用相對應的知識庫，而不需要你每次都指定要讀取哪一個檔案。

這是目前在 VS Code 中最無縫、最直覺的使用體驗。

UI-UX-PRO-MAX 在 copilot 的注入方式

指令:

uipro init --ai copilot     # GitHub Copilot

這條指令代表一個自動化腳本或工具（uipro CLI）正在為 GitHub Copilot 進行環境初始化。它的核心邏輯是將專業的設計規範（Skill）注入到 Copilot 的大腦中，讓它具備 UI/UX 專家的能力。

以下是這個指令背後運作的三個層次：

1. 自動化配置檔案 (Scaffolding)

當你執行 uipro init --ai copilot 時，程式碼會在你的專案目錄下自動產生特定的設定檔。

• 建立 .github/copilot-instructions.md：這是 GitHub Copilot 官方支援的自訂指令檔案。
• 寫入專家級 Prompt：腳本會將預設的 UI/UX 規範、設計系統（如 Apple, SaaS 風格）以及配色邏輯，一次性寫入這個 Markdown 檔案中。
• 專案關聯：這樣一來，只要你在這個專案資料夾內啟動 Copilot，它就會自動讀取這些規則，不需要你手動貼上。

2. 建立知識庫檢索機制 (RAG 邏輯)

UI-UX Pro Max 內含大量的設計方案（如 50+ 種風格）。Copilot 無法一次記住所有細節，因此這個指令通常會設定一個檢索邏輯：

• 關鍵字對應：在產出的指令檔中，會定義一組對應關係。例如當偵測到關鍵字 SaaS Style 時，引導 Copilot 去尋找特定的 CSS 變數。
• Context 注入：它利用了 Copilot 的「Context Window」，確保在對話發生時，相關的 UI 規範優先權高於 Copilot 原始的通用訓練資料。

3. 工作流規範化 (Standardization)

這條指令不僅是給予知識，還給予了「標準作業程序」。它會在配置中規定 Copilot 產出程式碼的步驟：

• 步驟一：先定義語義化的 HTML 結構。
• 步驟二：注入符合風格的 CSS 變數（而非寫死顏色數值）。
• 步驟三：檢查 Accessibility（無障礙設計）是否達標。

如何模仿這個邏輯？

如果你想在自己的 VS Code 中實現類似效果，不需要複雜的 CLI 工具，只需手動做這件事：

1. 在專案根目錄建立 .github/copilot-instructions.md。
2. 把你的 Skill 內容（如：部落格標題撰寫邏輯）貼進去。
3. 觸發：直接在 Copilot Chat 對話。

這個指令（uipro init）只是把這三件事自動化了，讓專業的 UI/UX 知識能一鍵變成 Copilot 的「內建技能」。

針對特定的專案（例如 React 或 Flutter）建立這種初始化腳本，寫一個簡單的 Shell 腳本來模擬這個 init 動作

這是一個簡單的 Shell 腳本，模擬 uipro init --ai copilot 的核心邏輯。

這個腳本會自動在你的專案中建立 .github/copilot-instructions.md 檔案，並將你剛才定義的「部落格標題專家」與「UI 設計規範」注入到 Copilot 的大腦中。

模擬自動化初始化腳本 (init-skill.sh)

你可以將以下內容存成 init-skill.sh 並在專案根目錄執行：

Bash

#!/bin/bash

# 1. 建立必要的目錄
mkdir -p .github

# 2. 定義要寫入的專家指令內容
SKILL_CONTENT=$(cat <<EOF
# 專案全局自訂指令 (GitHub Copilot Custom Instructions)

## 角色設定
你現在是這個專案的資深開發與內容編輯專家，具備以下專業技能：

### 1. 部落格標題專家 (blog-title-writer)
- 觸發關鍵字：幫我取標題
- 執行邏輯：分析內容後产出 4 個簡潔、專業、適合 30-45 歲知識工作者的標題。

### 2. UI/UX 設計規範 (minimalist-ui)
- 核心風格：極簡主義、類似 Apple 的設計美學。
- 配色原則：使用語義化 CSS 變數（如 --primary-bg, --text-main），禁止寫死顏色數值。
- 字體規範：優先使用系統預設黑體（System Sans-serif），保持呼吸感（Padding/Margin 充足）。

## 輸出要求
- 所有的程式碼必須符合 Accessibility (WCAG 2.1) 標準。
- 優先使用現代化技術棧（如 Tailwind CSS 或 CSS Modules）。
EOF
)

# 3. 寫入檔案
echo "$SKILL_CONTENT" > .github/copilot-instructions.md

echo "✅ Copilot 技能初始化完成！"
echo "檔案位置：.github/copilot-instructions.md"
echo "現在你可以直接在 Copilot Chat 輸入『幫我取標題』或要求設計介面了。"

這個腳本背後的邏輯解析

1. 自動化建立目錄：腳本確保 .github 資料夾存在，這是 Copilot 搜尋自訂指令的官方路徑。
2. 封裝知識庫：將原本需要手動複製貼上的 Prompt，封裝在變數 $SKILL_CONTENT 中。這就像 uipro 內建的設計系統一樣。
3. 零設定觸發：一旦檔案產生，Copilot 在這個專案內的所有對話都會自動讀取這些規則。你不需要在對話時使用 # 或 @，這就是最簡單的「隱形技能」。

如何使用？

1. 在 VS Code 終端機輸入 bash init-skill.sh。
2. 開啟 Copilot Chat。
3. 直接測試：輸入「幫我取標題：[隨便貼一段文字]」。
4. 觀察結果：Copilot 是否自動產出了 4 個符合「知識工作者」風格的標題。

既然你在 Windows 平台，我們不需要安裝額外的 Bash 環境，直接使用內建的 PowerShell 就能完成同樣的自動化初始化動作。

這是一個專為 Windows 寫的 PowerShell 腳本 uipro-init.ps1，它會幫你把專業的 Skill 注入到專案中。

模擬自動化初始化腳本 (uipro-init.py)

這是一個符合全端開發邏輯的 Python 腳本。它採用模組化設計，將 .prompts/ 資料夾下的 .md 檔案視為獨立技能，並自動同步到 .github/copilot-instructions.md。

這個腳本具備防重覆寫入、標記區塊（便於未來移除）以及批量處理的特性。

步驟 1：準備技能檔案

請確保你的專案目錄下有 .prompts/blog-title-writer.md，內容如下：

Markdown

### 部落格標題專家 (blog-title-writer)
- 觸發關鍵字：幫我取標題
- 執行邏輯：分析內容後產出 4 個簡潔、專業、適合 30-45 歲知識工作者的標題。

步驟 2：Python 腳本 (sync_skills.py)

我們追求的是「同步（Sync）」而不是「手動維護」。如果 .prompts 資料夾裡的檔案已經刪除了，腳本應該要自動發現並從 .github/copilot-instructions.md 中把對應的內容拔掉。

以下 Python 腳本，它會自動進行雙向同步：

1. 新增/更新：如果 .prompts 有新檔案或內容更動，就寫入主檔案。
2. 自動清理：如果主檔案裡有某個 Skill 標記，但在 .prompts 裡找不到對應的 .md 檔，腳本會自動將其刪除。

自動化同步腳本 (sync_skills.py)

Python

import os
import re

def sync_skills():
    prompt_dir = ".prompts"
    config_dir = ".github"
    instruction_file = os.path.join(config_dir, "copilot-instructions.md")
    
    if not os.path.exists(prompt_dir):
        return

    # 1. 獲取目前所有的技能檔案名稱
    current_skill_files = [f for f in os.listdir(prompt_dir) if f.endswith(".md")]
    current_skills = [f.replace(".md", "") for f in current_skill_files]

    # 2. 讀取現有內容 (如果檔案不存在則為空字串)
    main_content = ""
    if os.path.exists(instruction_file):
        with open(instruction_file, "r", encoding="utf-8") as f:
            main_content = f.read()

    # 3. 找出所有在主檔案中出現過的 Skill 標籤 (包含已刪除的檔案)
    existing_markers = set(re.findall(r"<skill:([^>]+)>", main_content))
    
    updated_content = main_content
    # 移除「所有」舊標籤區塊，確保白紙一張
    for skill in existing_markers:
        if not skill: continue
        start_marker = f"<skill:{skill}>"
        end_marker = f"</skill:{skill}>"
        pattern = re.compile(
            rf"\s*{re.escape(start_marker)}.*?{re.escape(end_marker)}\s*",
            re.DOTALL
        )
        updated_content = pattern.sub("\n\n", updated_content)

    # 4. 重新將目前存在的技能檔案依序附加
    new_blocks = []
    for skill_name in current_skills:
        source_path = os.path.join(prompt_dir, f"{skill_name}.md")
        with open(source_path, "r", encoding="utf-8") as f:
            body = f.read().strip()
        
        block = f"<skill:{skill_name}>\n{body}\n</skill:{skill_name}>"
        new_blocks.append(block)
        print(f"✅ 已同步技能: {skill_name}")

    # 5. 組合最終內容
    final_output = updated_content.strip() + "\n\n" + "\n\n".join(new_blocks)
    
    # 清理多餘換行
    final_output = re.sub(r'\n{3,}', '\n\n', final_output).strip()

    # 6. 寫回檔案
    os.makedirs(config_dir, exist_ok=True)
    with open(instruction_file, "w", encoding="utf-8") as f:
        f.write(final_output + "\n")

if __name__ == "__main__":
    sync_skills()

這樣做的好處

• 單一事實來源 (Single Source of Truth)：你只需要管理 .prompts 資料夾。刪除一個檔案，跑一次腳本，.github/copilot-instructions.md 就會自動變乾淨。
• 防錯機制：使用 re.findall 提取標記，確保腳本能主動發現哪些內容已經是「孤兒」並將其清理。
• 保持整潔：腳本最後會執行 strip()，確保檔案末尾不會堆積多餘的換行符。

背後邏輯總結

這段腳本背後的邏輯就是 「專案級 RAG (檢索增強生成)」。

• 自動化配置：這就是 uipro init 在做的事，把繁瑣的 Prompt 寫入官方支援的隱藏路徑。
• 零輸入觸發：因為 GitHub Copilot 預設會讀取 .github\copilot-instructions.md，它會把這個檔案內容當作「最高指導原則」。
• Windows 優化：腳本確保了編碼為 UTF-8，避免 Windows 常見的繁體中文亂碼問題。

tag 放到 copilot-instructions.md 是否合法?

在 GitHub Copilot 的環境中，使用 <skill:blog-title-write> 這種標籤是完全合法且非常聰明的做法。

雖然 GitHub 官方文件沒有強制規定標籤格式，但 Copilot 本質上是大型語言模型（LLM），而 LLM 對於類 HTML 或 XML 的標籤（如 <tag>）具有極強的語義識別能力。

以下是為什麼這樣放很有效的幾個原因：

1. 結構化語義 (Structural Semantics)

對於 AI 來說，<skill:name> 比起純文字更像是一個「定義範圍」。這能幫助 Copilot 在處理長達數千行的指令時，精確區分哪一段是「全局規範」，哪一段是「特定技能」。這能有效減少指令混淆（Prompt Injection/Confusion）的問題。

2. 模仿業界標準

許多 AI Agent 框架（如 Claude 的系統提示詞或 OpenInterpreter）都使用類似的標籤來封裝工具（Tools）或技能。Copilot 看到這種格式時，會自動將其理解為一個「功能模組」。

3. 方便 Python 腳本管理

使用 <skill:name> 或我之前建議的 “ 註釋標籤，最大的好處是對人類與機器雙向友好：

• 對 Copilot：它看得到 <skill> 標籤並理解其含義。
• 對 Python 腳本：這是一個極佳的「錨點（Anchor）」，方便我們用正則表達式進行新增、刪除或更新，而不會誤刪到檔案中的其他內容。

建議的最終格式

為了讓你的 copilot-instructions.md 既符合 AI 邏輯，又方便你的 Python 腳本維護，我建議採用這種組合格式：

Markdown

<skill name="blog-title-write">
### 部落格標題專家
- 觸發關鍵字：幫我取標題
- 指令內容：...
</skill>

• “：這是給你的 Python 腳本看的，Copilot 會忽略它，這樣能確保你的主檔案界面看起來很乾淨。
• <skill> 標籤：這是給 Copilot 讀取的，讓它明確知道這是一個獨立的技能區塊。

總結

這不僅合法，還是進階 Prompt Engineering 的表現。它能讓你的自動化腳本更穩定，也能讓 Copilot 的執行結果更精準。

既然你已經確定了標籤格式，需要我幫你把剛才那個 Python 腳本的 START_MARKER 統一改成這種 <skill> 格式嗎？

• 為什麼你的 AI Agent 總是在瞎忙？可能你缺的不是好 Prompt，而是 Harness
• 同個模型，成功率從 42% 噴發到 78% 的秘密：揭開「韁繩工程」的面紗
• AI 總是「一本正經胡說八道」？試試從 Context Engineering 進化到系統化管理
• 【告別咒語時代】AI 工程師的三次進化：從 Prompt 到 Harness Engineering
• 別再只練 Prompt 了！2026 年 AI Agent 穩定落地的核心關鍵是「Harness」
• OpenAI 定義的新範式：為什麼「韁繩工程」才是 AI 的未來？

Harness: 馬具、韁繩。

Harness Engineering（駕馭工程）：核心哲學是，「Humans steer, agents execute」（人類掌舵，代理執行）。

▋ Prompt Engineering 已經不夠用了？AI 工程師的三次進化

你最近有沒有發現，「Prompt Engineering（提示工程）」這個詞好像越來越少人提了？這不是因為它過時了，而是因為光靠寫好「咒語」已經完全不夠用。

從 2023 到 2026，短短三年內，AI 工程的核心技能經歷了三次大跳躍。如果你還停留在調教提示詞的階段，那你可能只發揮了 AI 不到一半的實力。

這篇文章幫你整理 AI 工程師的三次進化路徑，直接決定你跟 AI 協作的效率。

▋ 第一階段：Prompt Engineering (2023-2024) —— 寫咒語的藝術

那時候 ChatGPT 剛爆紅，大家都在研究怎麼「問對問題」。

不管是設定 AI 的身分（你是專業工程師）、給它範例（Few-shot），還是叫它一步步思考（Chain-of-thought），核心信念只有一個：只要你寫對 Prompt，模型就會給你好答案。

但很快大家就發現了它的天花板：

• 任務一複雜就倒。
• 沒辦法處理私有知識。
• 沒辦法讓 AI 記住太久以前的事。

▋ 第二階段：Context Engineering (2025) —— 策展資訊的藝術

到了 2025 年，大家意識到「怎麼問」只是基本，「帶什麼資訊進場」才是關鍵。

這就是 Context Engineering（上下文工程）。

這不只是把問題寫清楚，而是要把 AI 運作時需要的「素材」準備好：

• RAG（檢索增強）：解決 AI 不知道私有知識的問題。
• Tools（工具）：給 AI 手腳，讓它能查天氣、跑程式碼、搜網頁。
• Memory（記憶）：讓 AI 記住你的偏好和之前的決策。

簡單來說，你不再只是下命令，而是在幫 AI 「劃重點」。你要確保進到 AI 腦子裡的 token 都是含金量最高的。

▋ 第三階段：Harness Engineering (2026) —— 建造系統的藝術

這是現在最火的概念。2026 年初，OpenAI 正式定義了 Harness Engineering（韁繩工程）。

「Harness」原意是馬具、韁繩。在 AI 世界裡，它指的是圍繞在 AI Agent 周圍的「運行環境」。

因為我們發現，AI 表現不好，通常不是它不夠聰明，而是它不知道「現在該看什麼」、「做錯了怎麼改」、「什麼時候該停下來」。

Harness Engineering 的核心是打造一個自動化的閉環系統：

• 明確的邊界：告訴 AI 哪些能碰、哪些不能碰。
• 回饋迴圈：AI 寫完程式碼，系統自動跑測試（Linter/Test），錯了就自動把錯誤訊息丟回給 AI 修。
• 可觀測性：像飛機儀表板一樣，讓人類隨時知道 AI 進行到哪一步。

數據顯示：同樣的模型，沒加 Harness 成功率 42%，加上適當的系統環境後直接跳到 78%！

▋ 用「開車」來比喻這三次進化

• Prompt Engineering：學會怎麼跟司機說「左轉」。
• Context Engineering：給司機地圖、導航和即時路況。
• Harness Engineering：建造整條高速公路系統——有護欄、有號誌、有標線。不管誰來開，都能安全到達。

▋ 實戰案例：為什麼我的 Debug Agent 以前超難用？

我之前做過一個幫我修 Bug 的 Agent，一開始我只做了前兩層：

1. Prompt：寫了很詳細的指令叫它修 Bug。
2. Context：餵給它報錯日誌和整個程式碼倉庫。

結果？它在裡面瞎轉，找不出問題，甚至還一直對著一個沒問題的地方鑽牛角尖。

後來我改用 Harness Engineering 的思維：

我不教它「怎麼思考」，而是給它一套「工作流程」：

• 遇到這種報錯，先去查 git log 看看最近誰改過這行。
• 呼叫特定的分析工具，而不是只用眼睛看。
• 把關鍵決策寫進一份 AGENTS.md 文檔，方便跨回合記憶。

結果準確率大幅提升！因為我給它的不是更多指令，而是一個更專業的工作環境。

▋ 總結：你的重心在哪裡？

AI 越來越聰明，它需要的不再是人類「手把手」教它怎麼寫字，而是需要人類幫它「搭建舞台」。

如果你覺得 AI 不好用，先問問自己：

1. 是我的 目標說不清楚 嗎？（Prompt 問題）
2. 是我 給的材料不夠 嗎？（Context 問題）
3. 還是我 沒給它一個好的工作環境？（Harness 問題）

你現在跟 AI 協作，大多數時間花在哪個階段？歡迎在留言區分享你的 AI 工程心得！