從「AI神話」回到現實世界的工作場景

近年來，生成式 AI 在各種研究基準（knowledge & reasoning benchmarks）上屢創佳績，但這些多為「受控環境下的學術題」—但實際進入真實工作環境後，並模擬真實工作任務的表現如何呢?
於是，2025 年由 Center for AI Safety 及 Scale AI 等多機構發表的研究中，提出了 RLI 基準：從自由職業實際市場出發，衡量 AI 在真實、端到端、具有經濟價值的工作任務上的自動化能力。
研究結果顯示：目前最強的 AI 模型在這些任務上的自動化率僅約 2.5%。

RLI 是什麼？真實世界的 AI「工作實測」

為何要建立新的基準？

過去的 AI 評測往往聚焦于快速解題、知識推理、或受限任務（如問答、摘要、程式修正），但真實遠端工作往往複雜得多：跨領域、長時間、多階段交付並含有互動、視覺、音頻等要素。論文指出：「AI 在研究型基準上進步神速，但仍不清楚這些進步如何轉化為經濟價值與真正的自動化。」
因此，RLI 的設計目標就是從真實商業自由職業案件中抽樣，涵蓋遊戲開發、產品設計、建築、資料分析、動畫製作等多個領域。研究指出：「這些專案的成本甚至超過 US$10,000，完成時間超過 100 小時。」

RLI 規模與構成

• 專案總工作量超過 6,000 小時，總商業價值逾 US$140,000。
• 涵蓋多達 23 個不同工作類別，來自真實自由職業平台的案件。
• 所有案件皆具備「專案簡報（brief）」「輸入檔案（input files）」「人類提交成果（human deliverable）」。
  這樣的設計讓 RLI 比過去許多偏「軟體／文字」的基準更加貼近真實市場。

RLI 資料集的建立流程：從 64 領域篩選到 240 個真實專案

研究團隊首先在 64 個職業領域中初步挑選，經篩選後鎖定 43 個符合條件的領域。
接著，他們招募了 358 名經驗豐富的自由職業者，這些受測者在 Upwork 平台平均工作時數已達 2,341 小時、完成專案數平均為 89 件，平均收入約為 US$23,364。
最終，從初始 550 件專案中篩選出 240 件符合標準的 RLI 專案。

評估 AI 的四大指標

RLI 不僅收集真實專案，也制定了「可量化」的評估指標：

1. 自動化率（Automation Rate）：AI 成功完成、達到人類交付標準的專案比例。
2. Elo 評分：採「配對比較」方式，AI 模型間相對勝負的量化分數，將人類基準設定為 1,000 點。
3. 專案收益（Dollars Earned）：AI 成功完成專案所代表的貨幣價值。
4. 自動化通縮（Autoflation）：若 AI 可替代人力，專案成本下降的比例。

為了衡量交付品質，研究人員還設計了手動評估平台，評估者從「合理客戶視角」檢驗 AI 成果是否符合專案 brief，並採三點量表檢判。

結果：AI 的真實表現只有 2.5%

研究對六款邊緣 AI 智能體進行測試，包括 GPT‑5、Claude Sonnet 4.5、Grok 4、Gemini 2.5 Pro、Manus 等。

• 最高自動化率為 Manus 約 2.5%。
• 其他模型如 Grok 4／Sonnet 4.5 約 2.1%；GPT-5 約 1.7%；ChatGPT Agent 約 1.3%；Gemini 2.5 Pro 約 0.8%。

換句話說，即使是最前緣的 AI，也只能完全獨立完成不到 3% 的真實自由職業專案。
Elo 評分雖然顯示模型間有進步，但「絕對完成專案」的能力仍然遠低於人類基準。

為什麼 AI 仍然未達「高度自動化及高工作完成度呢」？

透過對大約 400 份交付評估樣本的質性分析，論文指出主要原因包括：

1. 技術與檔案完整性問題：生成損毀檔案、格式錯誤、無法使用。
2. 交付成果不完整或關鍵缺漏：如缺少素材、影片截斷、未提供源檔。
3. 品質不足達專業水準：即便完成檔案，其細節粗糙、不能達客戶預期。
4. 一致性差：多檔案專案中，風格或結果間前後不一致。

這些皆反映了 AI 在「世界知識校驗」「記憶與持續性」「視覺／音頻互動驗證」等方面的不足——特別是在建築設計、遊戲開發與網站建構這類需強調交互、視覺、音頻驗證的專案中，瓶頸尤為明顯。

哪些領域 AI 表現較為亮眼？

雖然整體自動化率極低，但論文指出，AI 在創意性較強或工具化較好的任務中已展現相對優勢，如：

• 圖像／音頻生成任務：AI 工具生成宣傳素材、圖像或音頻型作品。
• 寫作、資料檢索／網頁爬蟲任務：AI 在文字與資訊檢索領域效率較高。
  這與模型目前在視覺生成、語言生成上較成熟的事實一致。例如，Sonnet 4.5 在簡單 Web 視覺化任務上的成果甚至被評為優於人類交付。
• 例如: GPT-5在閱讀/寫作/數學/知識也超越GPT-4模型

結論：AI 還遠不能100%完成人類的複雜工作

RLI 的研究為我們提供了一個「可量化」且貼近真實工作的基準。其結論清晰：即使是當前最先進的 AI，也僅能完成極少數具經濟價值的真實專案。
儘管 AI 在研究基準上的躍進迅速，但進入真實遠端工作市場後，依然存在明顯差距。主要障礙在於：自我校正能力弱、跨模態（視覺／音頻／互動）理解薄弱、長篇／多階段專案管理能力不佳。
因此，目前更合理的策略是將 AI 視為「強化人類能力」的工具，而非完全替代人類專業人士。

未來趨勢與實務建議

1. AI 作為「協作夥伴」而非替代者：專業人士與企業應聚焦在 AI 能提升效率、輔助創作、改善流程的場景，並非單純追求全面替代。
2. 強化資料真實性、驗證能力將成為關鍵突破點：未來若 AI 能夠自動偵測錯誤、修正檔案格式、跨模態驗證影片／互動效果，其於真實工作場景的應用才有機會大規模擴展。

參考資料

• Remote Labor Index 原始論文：https://www.remotelabor.ai/paper.pdf

原文：Han Lee – Claude Agent Skills: A First Principles Deep Dive

上篇我們理解了 Skill 的結構與撰寫方式；篇將以工程視角拆解 Skill 作為「Meta-tool」 的設計、兩段訊息注入機制、API 請求結構，以及從「發現 → 授權 → 注入 → 執行」的完整生命週期。讀完後，你將能以第一性原理理解為何 Skills 能做到「不執行程式碼、卻改變模型行為」。

內部架構：Skill 作為 Meta-tool

Skill（大寫 S） 是 Claude 的「元工具（Meta-tool）」。
它的任務是動態生成所有可用技能清單，再交給模型自行匹配。

核心特徵

• prompt 為動態生成：列出所有 skill 名稱與描述。
• 無外部分類器：由模型自行推論何時使用。
• Token 預算限制：每次清單上限約 15,000 字元，逼迫 skill 描述精簡。
• 獨立於 system prompt：存在於 tools 陣列中，而非全域系統指令。

Skills 物件設計：不是「直接執行」，而是「注入與改寫」

傳統工具（如 Read、Bash、Write）會直接執行並回傳結果；Skills 則不直接執行，而是做兩件事：

1. 將專用指示注入對話歷史（conversation context），透過完整提示改寫模型接下來的推理方式。
2. 動態修改執行環境（execution context），例如開放工具權限、切換模型、調整思考 token 參數等。

這個過程透過兩則使用者訊息完成：

• 一則是給使用者看的中繼資訊（可見、極短）。
• 另一則是給模型看的完整 skill 提示（隱藏於 UI）。

Normal Tool vs Skill Tool：設計差異

Skill 工具結構與動態描述生成

Pd = {
  name: "Skill",  // 工具名稱常數

  inputSchema: {
    command: string  // 例如 "pdf", "skill-creator"
  },

  outputSchema: {
    success: boolean,
    commandName: string
  },

  // 🔑 關鍵：動態產生 skills 列表（而非固定字串）
  prompt: async () => fN2(),

  // 驗證與執行
  validateInput: async (input, context) => { /* 五種錯誤碼 */ },
  checkPermissions: async (input, context) => { /* allow/deny/ask */ },
  call: async *(input, context) => { /* 產出訊息 + 修改執行上下文 */ }
}

為什麼要動態 prompt？

與固定描述的工具不同，Skill 工具會在執行時聚合所有 skills 的「名稱＋描述」，組成 <available_skills> 清單供模型判斷是否要呼叫某個 skill。
這就是漸進式揭露（Progressive Disclosure）：先提供最少的技能中繼資料，只有當模型選擇某個 skill 後，才載入其完整提示，避免上下文暴漲、同時維持可探索性。

async function fN2() {
  let A = await atA(),
    { modeCommands: B, limitedRegularCommands: Q } = vN2(A),
    G = [...B, ...Q].map((W) => W.userFacingName()).join(", ");
  l(`Skills and commands included in Skill tool: ${G}`);
  let Z = A.length - B.length,
    Y = nS6(B),
    J = aS6(Q, Z);
  return `Execute a skill within the main conversation

<skills_instructions>
...（使用說明與注意事項）
</skills_instructions>

<available_skills>
${Y}${J}
</available_skills>
`;
}

為何不放在 System Prompt？

有些系統（如某些助理）會把工具定義放在 system prompt。但 Claude 的 Skills 不這麼做，理由是：

• system prompt 具全域與持久影響，一旦放入就會「長駐」整段對話。
• Skills 需要暫時、具任務範疇（scoped）的行為。

因此，Skills 以 tools 陣列中的 Skill 工具描述出現；個別 skill 的名稱則是 Skill 的 input_schema.command 的取值。

API 請求實例

{
  "model": "claude-sonnet-4-5-20250929",
  "system": "You are Claude Code, Anthropic's official CLI...",
  "messages": [
    {"role": "user", "content": "Help me create a new skill"}
  ],
  "tools": [
    {
      "name": "Skill",
      "description": "Execute a skill...\n\n<skills_instructions>...\n\n<available_skills>\n...",
      "input_schema": {
        "type": "object",
        "properties": {
          "command": {
            "type": "string",
            "description": "The skill name (no arguments)"
          }
        }
      }
    },
    { "name": "Bash", "description": "Execute bash commands..." },
    { "name": "Read" }
  ]
}

<available_skills> 每次請求都重新生成，通常有約 15,000 字元的預算上限，迫使技能描述精煉、避免擠爆上下文。

兩段訊息注入設計：透明度 × 可讀性

為什麼需要兩段訊息？

• 若全部可見，UI 會被上千字的內部指令淹沒。
• 若全部隱藏，使用者又看不到系統正在做什麼。

解法：注入兩則訊息，各司其職——

1. 可見的中繼訊息（短、機器可解析的 XML），2) 不可見的完整提示（長、只送 API）。

可見的中繼訊息（isMeta: false）

let metadata = [
  `<command-message>${statusMessage}</command-message>`,
  `<command-name>${skillName}</command-name>`,
  args ? `<command-args>${args}</command-args>` : null
].filter(Boolean).join('\n');

messages.push({
  content: metadata,
  autocheckpoint: checkpointFlag
});

使用者會看到類似：

<command-message>The "pdf" skill is loading</command-message>
<command-name>pdf</command-name>
<command-args>report.pdf</command-args>

通常 50–200 字元，讓前端以特殊樣式呈現與審計紀錄。

隱藏的完整提示（isMeta: true）

let skillPrompt = await skill.getPromptForCommand(args, context);

let fullPrompt = prependContent.length || appendContent.length
  ? [...prependContent, ...appendContent, ...skillPrompt]
  : skillPrompt;

messages.push({
  content: fullPrompt,
  isMeta: true  // 隱藏於 UI，僅送 API
});

典型內容（500–5,000 字）：任務背景、流程步驟、可用工具、輸出格式、環境路徑等（如 PDF 專家流程）。

👉 圖片建議：左右對照圖「左＝簡短 XML 狀態」「右＝Markdown 長提示（標註 isMeta:true）」。

為何不能合併成一則？

兩者受眾不同、目的不同、處理管線不同：

• 可見訊息：給人看、要極簡、要能被 UI 解析。
• 隱藏訊息：給模型看、可冗長、免經 UI 驗證。
  合併會違反單一職責原則並汙染 UI／上下文。

訊息組合的擴充：附件與權限

除了兩段核心訊息，有時還會加入**附件（attachments）與權限設定（command_permissions）**訊息：

let allMessages = [
  createMessage({ content: metadata, autocheckpoint: flag }),   // 1. 可見中繼
  createMessage({ content: skillPrompt, isMeta: true }),        // 2. 隱藏長提示
  ...attachmentMessages,                                        // 3.（條件式）附件
  ...(allowedTools.length || skill.model ? [
    createPermissionsMessage({                                  // 4.（條件式）權限/模型
      type: "command_permissions",
      allowedTools: allowedTools,
      model: skill.useSmallFastModel ? getFastModel() : skill.model
    })
  ] : [])
];

• 附件：診斷資訊、檔案參考或補充上下文。
• 權限：當 frontmatter 指定 allowed-tools 或要求切換 model 時，才加入。
• 可視性：依需求決定是否顯示於 UI，但通常屬於機制性訊息。

案例：技能執行生命週期（以 pdf skill 為例）

Phase 1｜發現與載入（啟動時）

系統啟動會掃描所有來源的 skills，解析 SKILL.md 的 frontmatter 與內容，建立技能物件。

async function getAllCommands() {
  let [userCommands, skillsAndPlugins, pluginCommands, builtins] =
    await Promise.all([
      loadUserCommands(),
      loadSkills(),
      loadPluginCommands(),
      getBuiltinCommands()
    ]);
  return [...userCommands, ...skillsAndPlugins, ...pluginCommands, ...builtins]
    .filter(cmd => cmd.isEnabled());
}

針對外掛型 skills 的載入（略）後，會形成類似：

{
  "type": "prompt",
  "name": "pdf",
  "description": "Extract text from PDF documents (plugin:document-tools)",
  "whenToUse": "When user wants to extract or process text from PDF files",
  "allowedTools": ["Bash(pdftotext:*)", "Read", "Write"],
  "model": null,
  "isSkill": true,
  "disableModelInvocation": false,
  "promptContent": "You are a PDF processing specialist..."
}

Phase 2｜第 1 回合：使用者請求與 skill 選擇

使用者：「Extract text from report.pdf」。
系統先過濾可供 Skill 工具列出的 skills（需有 description 或 when_to_use）：

async function getSkillsForSkillTool() {
  const all = await getAllCommands();
  return all.filter(cmd =>
    cmd.type === "prompt" &&
    cmd.isSkill === true &&
    !cmd.disableModelInvocation &&
    (cmd.source !== "builtin" || cmd.isModeCommand === true) &&
    (cmd.hasUserSpecifiedDescription || cmd.whenToUse)
  );
}

接著格式化清單為 <available_skills>，模型讀取後以語義推論判斷 pdf 符合需求，於是呼叫 Skill 工具：

{
  "type": "tool_use",
  "name": "Skill",
  "input": { "command": "pdf" }
}

關鍵：沒有任何外部演算法在做分類／意圖偵測；純 LLM 推論。

Phase 3｜Skill 工具執行

1. 輸入驗證（是否存在、可否自動啟動、型別是否為 prompt 等）。
2. 權限檢查（deny/allow 規則；預設 ask 由使用者確認）。
3. 載入 Skill 檔並產生兩段訊息；必要時加入權限／模型覆寫。
4. 回傳 contextModifier，在後續回合自動預核准工具或切換模型。

yield {
  type: "result",
  data: { success: true, commandName: skillName },
  newMessages: messages,
  contextModifier(context) {
    // 預先開放 allowedTools
    // 覆蓋 mainLoopModel（若指定）
    return modified;
  }
};

Phase 4｜送交 API（第 1 回合完成）

{
  "model": "claude-sonnet-4-5-20250929",
  "messages": [
    { "role": "user", "content": "Extract text from report.pdf" },
    { "role": "assistant", "content": [{ "type": "tool_use", "name": "Skill", "input": { "command": "pdf" } }]},
    { "role": "user", "content": "<command-message>The \"pdf\" skill is loading</command-message>\n<command-name>pdf</command-name>" },
    { "role": "user", "content": "You are a PDF processing specialist...\n## Process\n1. Validate PDF exists\n2. Run pdftotext...", "isMeta": true },
    { "role": "user", "content": { "type": "command_permissions", "allowedTools": ["Bash(pdftotext:*)", "Read", "Write"], "model": null } }
  ]
}

此時，對話上下文（長提示）與執行上下文（工具白名單／模型）都已就緒，但尚未真正做事。

Phase 5｜工具執行（在 skill 上下文中）

Claude 於下一回合依據已注入的提示執行：

1. 檢查 report.pdf 是否存在
2. 呼叫 Bash：pdftotext report.pdf output.txt
3. 用 Read 讀取 output.txt
4. 將結果呈現給使用者

{
  "type": "tool_use",
  "name": "Bash",
  "input": {
    "command": "pdftotext report.pdf output.txt",
    "description": "Extract text from PDF using pdftotext"
  }
}

差別在於：Bash、Read、Write 已被預先允許，不需再次徵求同意，流程順暢完成。

心智模型回顧（Key Takeaways）

• Skills 是 SKILL.md 的提示模板，不是可執行程式。
• Skill（大寫 S）是 tools 陣列裡的 Meta-tool，不是 system prompt 的一部分。
• 對話上下文透過 isMeta:true 的訊息注入；執行上下文則調整工具許可與模型選擇。
• 選擇使用哪個 skill，由 LLM 讀描述後自行推論，非演算法匹配。
• 工具權限具範疇性：在技能執行期間預先允許，任務後環境恢復。
• 兩段訊息同時滿足透明度（人類可見）與可操作性（模型可用）。

結語：以「提示×權限」取代「程式×函式」

將專業知識「提示化」並以一則 Meta-tool 管理其範疇化的權限與模型，讓 Claude 得以在安全、可控、可組合的框架下完成複雜任務。
這種設計避免了工具爆炸與系統提示臃腫，同時保留 LLM 的語義彈性——這，就是 Agent Skills 的優雅之處。

參考資料

• 原文：Han Lee – Claude Agent Skills: A First Principles Deep Dive

原文：Han Lee – Claude Agent Skills: A First Principles Deep Dive

在大型語言模型（LLM）的快速演進中，Anthropic 的 Claude 系列以強調安全性與可控性著稱。而在 Claude 的整個架構中，「Agent Skills 系統」是最值得技術人員深入研究的一環。它並非傳統意義上的外掛（plugin）或工具呼叫，而是一種以提示（prompt）為核心的元工具機制，能讓模型在不同任務中切換「思考模式」，達到專業化與模組化的效果。

本文將從第一性原理出發，完整解析 Claude 的 Agent Skills 架構與運作邏輯，並以實際案例（如 skill-creator 與 internal-comms）說明技能的建立、載入、與決策過程。

什麼是 Claude Agent Skills

Skills 是什麼？
它不是函式呼叫、不是伺服器、也不是可執行程式。Skill 是一個結構化的提示模板，在被呼叫時會把 領域專屬的指示 注入到對話上下文中，並可同時改變執行上下文（如：開啟哪些工具權限、切換模型）。

Skill 的存放位置
Skill 以資料夾為單位，內含 SKILL.md（核心提示）、以及可選的 scripts/、references/、assets/。它們不會被硬寫進系統提示（system prompt），而是透過一個名為 Skill（大寫 S） 的「元工具（meta-tool）」動態管理。

誰做決策？
不是外部程式碼在做意圖分類，也沒有 embeddings 或關鍵字比對。是 LLM 本身在閱讀 Skill 列表的文字描述後，用語言理解自行決定是否要用哪個 Skill。這一切都發生在模型的前向推論之中。

Skills 與傳統工具的差異：

重點心智模型：
工具會「做事」，Skills會「讓模型準備好、以專家方法來做事」。Skills 調整的是模型的行為策略與權限環境。

從實例看 Skill 的構成：以 skill-creator 為例

關鍵洞見：
Skill = 提示模板 + 對話上下文注入 + 執行上下文修改 +（可選）資料與腳本

Skill 會被 Claude Code 從多處載入：使用者設定（~/.config/claude/skills/）、專案資料夾（.claude/skills/）、外掛提供的 skills、以及內建 skills。以 Claude Desktop，也可直接上傳自訂 Skill。

漸進式揭露（Progressive Disclosure）是核心設計哲學

1. 先只曝光前言（frontmatter）：名稱與描述足夠讓 LLM 決定是否選用。
2. 選中後再展開 SKILL.md：提供完整但聚焦的指示。
3. 需要時才載入腳本與參考資料：把冗長內容拆到外部檔案，避免上下文暴漲。

🔍 沒有 /references 或 /assets 目錄，顯示該技能以提示為主體、腳本為輔。

SKILL.md：前言區（Frontmatter）與提示內容（Content）

SKILL.md 由兩部分組成：

Frontmatter

• name（必填）：Skill 名稱，也是 Skill 工具的 command。
• description（必填）：最關鍵訊號，LLM 靠它判斷何時使用此 Skill。建議用動作導向語言（「當使用者想要…時使用」）。
• license（選填）：授權說明。
• allowed-tools（選填）：預先開放的工具白名單。可用萬用字元或限定子命令。務必最小化權限。
  • 範例：
    • allowed-tools: "Read,Write,Bash,Glob,Grep,Edit"（skill-creator）
    • allowed-tools: "Bash(git status:*),Bash(git diff:*),Read,Grep"
    • ✅ 僅列必要工具；❌ 不要貪心全開，破壞安全模型。
• model（選填）：可指定特定模型，預設 inherit（沿用當前會話）。
• version（選填）：純記錄用途。
• disable-model-invocation（選填）：若 true，不會被自動列入給 LLM 的可用清單，只能用手動指令（如 /skill-name）啟動。
• mode（選填）：若 true，此 Skill 被視為「模式指令」，會在清單上方以「Mode Commands」區塊凸顯（如 debug-mode、expert-mode）。

關於 when_to_use（未文件化、可能已棄用或尚未公開）

程式碼中可見 when_to_use 被附加到 description 後方以加強語意，但 官方未文件化，行為可能變動。實務建議：把使用時機直接寫進 description，避免依賴未公布欄位。

SKILL.md提示內容

實務守則

• 盡量小於 5,000 字，避免淹沒上下文。
• 用 祈使句（「分析…」、「執行…」），不要用「你應該…」。
• 把冗長清單、範例、模板拆到外部檔案，用 {baseDir} 引用路徑，不要寫死絕對路徑。
  • ✅ Read {baseDir}/config.json
  • ❌ Read /home/user/project/config.json

與資源打包：scripts/／references/／assets

專案結構建議：

my-skill/
├── SKILL.md
├── scripts/      # 可執行腳本（Python/Bash）
├── references/   # 文字型參考資料（會讀入上下文）
└── assets/       # 模板與二進位資源（僅路徑引用，不讀入）

• scripts/：交給 Bash 工具執行的自動化腳本（如 init_skill.py）。適合多步驟、決定性邏輯或資料處理。
• references/：會被 Read 載入上下文的文件（規範、樣式指南、Schema 等）。
• assets/：只用路徑引用、不讀入上下文（HTML 模板、圖片、字型）。避免浪費 token。

常見設計樣式（Patterns）與進階工作流

Pattern 1：Script Automation（腳本自動化）

使用場景：需要多個指令或確定性邏輯的複雜操作。
這種模式將計算任務卸載到scripts/目錄中的 Python 或 Bash 腳本中。技能提示符號指示 Claude 執行腳本並處理其輸出。

SKILL.md 例：

Run scripts/analyzer.py on the target directory:

`python {baseDir}/scripts/analyzer.py --path "$USER_PATH" --output report.json`

Parse the generated `report.json` and present findings.

所需工具：

allowed-tools: "Bash(python {baseDir}/scripts/*:*), Read, Write"

Pattern 2：Read – Process – Write

情境：檔案轉換、格式清理、報表輸出。
最簡單的模式－讀取輸入，依照指令轉換，寫入輸出。適用於格式轉換、資料清理或報告產生。

SKILL.md 例：

## Processing Workflow
1. Read input file using Read tool
2. Parse content according to format
3. Transform data following specifications
4. Write output using Write tool
5. Report completion with summary

所需工具：

allowed-tools: "Read, Write"

Pattern 3：Search – Analyze – Report

情境：程式碼安全檢查、巨量資料模式搜尋。
使用 Grep 在程式碼庫中搜尋模式，讀取符合的檔案以取得上下文，分析結果，並產生結構化報告。或者，在企業數據儲存中搜尋數據，分析檢索到的數據以獲取信息，並產生結構化報告。

SKILL.md 例：

## Analysis Process
1. Use Grep to find relevant code patterns
2. Read each matched file
3. Analyze for vulnerabilities
4. Generate structured report

所需工具：

allowed-tools: "Grep, Read"

Pattern 4：Command Chain Execution

情境：具有依賴關係的多步驟操作。
執行一系列命令，其中每一步都依賴前一步的成功。這在類似 CI/CD 的工作流程中很常見。

SKILL.md 例：

Execute analysis pipeline:
npm install && npm run lint && npm test

Report results from each stage.

所需工具：

allowed-tools: "Bash(npm install:*), Bash(npm run:*), Read"

進階工作流

Wizard-style 多步驟嚮導

使用場景：每步驟向使用者確認後再前進。

SKILL.md 例：

## Workflow

### Step 1: Initial Setup
1. Ask user for project type
2. Validate prerequisites exist
3. Create base configuration
Wait for user confirmation before proceeding.

### Step 2: Configuration
1. Present configuration options
2. Ask user to choose settings
3. Generate config file
Wait for user confirmation before proceeding.

### Step 3: Initialization
1. Run initialization scripts
2. Verify setup successful
3. Report results

Template-based 產生

使用場景：從 assets/ 讀模板、填入欄位、輸出成品。

SKILL.md 例：

## Generation Process
1. Read template from {baseDir}/assets/template.html
2. Parse user requirements
3. Fill template placeholders:
   -  → user-provided name
   -  → generated summary
   -  → current date
4. Write filled template to output file
5. Report completion

Iterative Refinement

使用場景：先廣掃後深挖，再產出修正建議與工時估計。

SKILL.md 例：

## Iterative Analysis

### Pass 1: Broad Scan
1. Search entire codebase for patterns
2. Identify high-level issues
3. Categorize findings

### Pass 2: Deep Analysis
For each high-level issue:
1. Read full file context
2. Analyze root cause
3. Determine severity

### Pass 3: Recommendation
For each finding:
1. Research best practices
2. Generate specific fix
3. Estimate effort

Present final report with all findings and recommendations.

Context Aggregation

使用場景：聚合多來源（README、package、git、grep）成整體視圖。

SKILL.md 例：

## Context Gathering
1. Read project README.md for overview
2. Analyze package.json for dependencies
3. Grep codebase for specific patterns
4. Check git history for recent changes
5. Synthesize findings into coherent summary

到這裡，我們已了解 Skills 是如何被設計、撰寫與打包的：
它不是外部程式，而是能讓 Claude 暫時「切換人格」的提示容器。
由於原文資料太多可以分享我們將分成上下兩篇來介紹，在下一篇中，我們將深入探討 Skills 在內部如何被載入、解析與執行——包括 Skill 工具（meta-tool）的 API 結構、兩段訊息注入設計，以及完整的執行生命週期，對原文有興趣也可前往原文觀看，我們下次見~~

參考資料

• 原文：Han Lee – Claude Agent Skills: A First Principles Deep Dive

AI 正從「單體巨腦」邁向「專家協作網路」

初次與 GPT-5 對話時，許多開發者都會察覺到一個微妙的變化——它不只是回答問題，而是在選擇如何回答。
在 GPT-5 背後，運行著一個名為 Router（路由器） 的智慧調度核心。這個模組會根據任務性質與需求，將請求分派給最合適的「大腦」：

• 輕量核心模型：處理快速事實查詢與摘要任務。
• Thinking 思考推理模型：專責邏輯推理與複雜問題。
• 工具整合層：當需要計算或檢索外部資料時，路由器會自動呼叫相關工具。

這項變革的意義不僅在於效能提升，更代表 AI 架構正從「單一模型」邁向「多智能體協同」的新典範。

一、為什麼路由機制成為 GPT-5 的關鍵？

在 GPT-4 時代，無論使用者要寫詩、除錯或查拼字，系統都必須啟動同一個大型模型——這就像用火箭引擎烤麵包。雖然可行，但既耗能又不必要。

GPT-5 引入的路由機制徹底改變這種模式。它會在收到請求後即時分析內容，根據任務性質選擇合適模型：

如此一來，AI 不再為簡單任務動用龐大模型，提升效率並降低資源浪費。

二、GPT-5 路由決策的四大支柱

GPT-5 的路由器在決定使用哪個模型時，主要根據以下四個因素運作：

1️⃣ 對話類型（Conversation Type）

系統會先判斷任務屬性——是閒聊、程式審查、數學推導，還是故事撰寫？
例如：

• 「週末要去哪玩？」→ 啟動快速模式。
• 「請逐步推導這個定理」→ 切換至深度思考模式。

2️⃣ 任務複雜度（Task Complexity）

路由器能解析提示詞的難度信號。若問題包含多步邏輯或抽象概念，會自動啟用高推理模型。
根據 AIMultiple 的分析，GPT-5 採用混合多模型架構，根據提示複雜度與反應需求動態分派運算資源。

3️⃣ 工具需求（Tool Needs）

出現「計算」、「查詢」、「寫信」等指令時，路由器會調用內建工具或 API 模型。
不同於早期 ChatGPT 插件需手動啟用，如今這些過程已完全自動化。測試顯示，GPT-5 的工具誤調率較 GPT-4 減少近 50%。

4️⃣ 使用者意圖（Explicit Intent）

GPT-5 能讀懂語意細節——輸入「請深入分析」時，系統會自動切換到 Thinking 模式；輸入「請快速總結」則啟用快速模式。
這種「軟指令層（Soft Instruction Layer）」讓自然語言成為模型決策的一部分。

三、超越 Toolformer 與傳統插件：動態決策的時代

2023 年的 Toolformer 模型曾讓 LLM 學會在訓練中自行調用外部工具，但這仍是靜態學習。
GPT-5 的路由機制則屬於動態決策引擎：它能在運行時即時判斷是否啟用工具。

同樣，ChatGPT 舊版插件需要手動開啟，GPT-5 則以策略層取代手動操作，讓工具調用在背景自動完成。
因此，GPT-5 可被視為 Toolformer 的自主性 + ChatGPT 插件的生態系 + 即時路由指揮官 的融合體。

四、GPT-5 路由架構的四大優勢

效率與速度

• 輕量模型處理日常任務，節省大量算力。
• 在多項基準測試中，GPT-5 的回應速度比 GPT-4 Turbo 快 2–3 倍。
• 當負載過高時，mini 模型會自動接手低優先任務。

模組化與可解釋性

• 每個子模型功能明確，可獨立升級。
• 錯誤診斷更清晰：是路由選錯，還是推理出錯。
• 架構類似微服務（Microservice），更易維護與擴充。

專業化輸出

• 子模型針對特定任務優化（如 reasoning、summarization）。
• 支援對話中無縫切換模式，體驗更流暢。

彈性控制

• 使用者可手動切換「Fast / Thinking」模式，兼顧效率與深度。

五、潛在挑戰與技術瓶頸

• 除錯困難：需追蹤多層決策紀錄，類似分散式系統除錯。
• 延遲疊加：多層推理鏈會增加反應時間。
• 成本與能耗：多個小模型並行可能比單一大模型耗資更多。
• 語氣一致性問題：不同子模型風格需透過人格濾鏡統一。
• 路由誤判風險：分派錯誤會導致回答深度不符。

緩解方式包括：平行執行（Parallel Calls）、結果快取（Caching） 與 強化學習式路由訓練。

六、AI 的新方向：從單體智能到多智能體協作

GPT-5 的「Router + Multi-Model」架構揭示了 AI 正在邁向 模組化與多智能體化（Agentic AI）。
未來的 AI 不再依賴單一模型，而是由多個專家模型組成的協作網路。

部分研究團隊已在測試「百專家模型（100-Expert LLMs）」，以中央控制器協調數十個子模型。
隨著硬體演進，這種協作成本將不斷下降，並最終取代傳統「一體式模型」設計。

結語：AI 的「協作智能」時代正式啟動

GPT-5 的即時路由機制讓 AI 從「孤立天才」轉變為「專家合奏」。
它帶來效率與精度的雙重提升，也提出新的挑戰：如何讓所有模組協同一致、維持對話流暢。

從技術角度看，這不僅是一項工程創新，更是一場設計哲學革命。
未來的 AI 將學會「如何選擇思考方式」，而非僅僅「思考本身」。

專業建議與趨勢

1. 導入智能路由概念
   新創團隊在設計 LLM 應用時，應先規劃任務分類與分派邏輯，而非單純追求更大模型。
2. 強化可觀測性（Observability）
   建立清晰的決策追蹤鏈（Decision Trace），方便除錯與模型監控。
3. 保持人格一致性
   為多模型協作系統設計統一語氣與風格層，確保使用者體驗連貫。

原文：https://bhavishyapandit9.substack.com/p/gpt5-router-a-deep-dive

AI 不再只是工具，而是你的「夥伴」

2025 年 10 月 23 日，微軟正式發表 Copilot 秋季更新（Fall Release），宣告旗下 AI 助手平台邁入全新階段。這次更新不僅是功能升級，更代表微軟在人機互動與生成式 AI 的戰略轉型：讓人工智慧從「被動協助」走向「主動理解與共感」。
其中最令人矚目的亮點，莫過於全新虛擬角色——Mico。這個能表達情緒、回應語氣、甚至「呼吸」的 AI 形象，被外界形容為「繼 Clippy、Cortana 之後，微軟最擬人化的 AI 夥伴」。

一、以人為本的 AI：微軟 Copilot 的新定位

微軟 AI 業務負責人 Mustafa Suleyman 在官方部落格指出，本次更新以「Human-Centered AI（以人為本的人工智慧）」為核心理念。他強調：「科技應該服務於人，而不是讓人去適應科技。」

本次更新圍繞三大關鍵詞展開：

• 協作（Together）：讓人與 AI、團隊之間的互動更自然；
• 個性化（Personalised）：讓 Copilot 理解使用者的習慣與需求；
• 連結（Connected）：打通跨平台資料與服務。

這意味著 Copilot 已不再只是 Office 插件，而是進化為跨設備、跨場景的「情境式 AI 基礎架構」。

二、Copilot 秋季版的 12 項核心功能亮點

此次更新帶來 12 項關鍵功能，涵蓋從協作、學習到健康領域：

1. Groups（小組協作）

允許最多 32 人共享 Copilot 會議，支援即時頭腦風暴、決策摘要、任務分解與追蹤。

2. Imagine（AI 創作中心）

支援多名使用者共同創作與 remix AI 內容，如行銷素材、訓練教材等。

3. Mico（全新虛擬角色）

新登場的 AI 形象，以圓形、會變色的動畫角色呈現，能透過表情反映情緒，是此次更新的最大亮點。

4. Real Talk（真實對話模式）

摒棄過度討好式回答，改以蘇格拉底式問答與邏輯挑戰協助使用者思考。

5. 記憶與個性化

讓 Copilot 記住使用者偏好、專案與日期等長期資訊，提供個人化建議。

6. Connectors（跨平台整合）

支援 OneDrive、Google Drive、Outlook、Gmail、Google 日曆等多平台資料檢索。

7. Active Actions（主動建議）

根據使用者的上下文與歷史操作，主動提出「下一步建議」。

8. Copilot for Health（健康助手）

整合 Harvard Health 等權威資料庫，提供臨床級健康建議與醫師比較功能。

9. Live Learning（即時互動學習）

結合語音、白板、圖像與問答的蘇格拉底式教學體驗。

10. Copilot Mode in Edge（Edge 瀏覽器 AI 模式）

讓 Edge 成為 AI 瀏覽器，可透過語音總結內容、比較資料或執行網頁任務。

11. Copilot in Windows（Windows 系統整合）

支援「Hey Copilot」語音喚醒、視覺辨識（Copilot Vision）與應用快速操作。

12. Copilot Pages 與 Copilot Search

將 AI 生成內容與傳統搜尋結果結合，提供更全面的檢索體驗。

三、從 Clippy 到 Mico：微軟 AI 擬人化的三十年演進

回顧 Clippy：微軟的第一代虛擬助理

1997 年，Office 97 推出「大眼夾（Clippy）」，它象徵著微軟對「擬人化電腦助理」的早期想像。
由於互動體驗簡單，Clippy 最終在 2001 年退役，但它留下了「電腦應該更懂人」的理念。

Cortana：語音時代的短暫嘗試

2014 年，微軟推出語音助手 Cortana，希望讓裝置能「聽懂人話」。Cortana 最終從 Windows 11 退役。

Mico：AI 夥伴的新世代

隨著生成式 AI 與多模態技術成熟，微軟在 2025 年推出了 Mico —— 一個能「呼吸」、能表情互動的虛擬 AI。它不只是語音介面，更是具情緒、具記憶的對話夥伴。
微軟產品副總裁 Jacob Andreou 表示：「Clippy 幫我們邁出第一步，而 Mico 則讓這條路真正延續下去。」

四、Mico：讓 AI 擁有情緒與共感

Mico 透過 Copilot 的記憶系統，能理解使用者語境與情緒。例如當使用者談及悲傷話題時，Mico 的表情也會即時反映出關懷或沉靜。
它還支援「Learn Live」模式，能像導師一樣透過提問引導思考，而非單向給答案。

Suleyman 表示，Mico 將成為「AI 的人格化界面」，擁有固定形象與成長能力。這標誌著微軟正式邁入「AI 共生體驗」時代。

五、社群回饋：懷舊與期待並存

Mico 登場後在社群平台 X 上掀起熱議：

• 有人稱讚微軟「為嚴肅的 AI 開發注入樂趣與人性」；
• 也有使用者發現小彩蛋：「連點幾下 Mico，它會變身成 Clippy！」；

六、從工具到夥伴：微軟的 AI 哲學

Mico 象徵著微軟從「生產力軟體公司」邁向「人本智慧平台」(Human-centered AI)的關鍵一步。
它讓人與電腦的互動從指令轉為對話，從操作轉為理解。
這不只是科技升級，更是人機關係的重新定義。

趨勢與建議

1. AI 情感介面將成為人機互動新主流：未來專業應用（如教育、醫療、客服）可結合情緒感知強化用戶體驗。
2. 個人化 AI 服務將深化隱私與倫理討論：企業導入 Copilot 時應重視資料治理與 AI 透明性。

參考資料

• Microsoft 官方部落格：Human-Centered AI 發表文
• TechCrunch：Microsoft’s Mico is a Clippy for the AI Era
• The Verge：Copilot 秋季更新功能解析

2025 年 10 月，Anthropic 推出了一項令人耳目一新的創新——Claude Skills。這不只是給 AI 增加功能的新方法，更可能徹底改變我們與大型語言模型（LLM）互動的方式。許多專家甚至認為，這項技術的影響力將超越去年轟動一時的 Model Context Protocol（MCP）。

當「外掛」變成「技能」

長久以來，AI 模型的擴充方式多依賴複雜協定（如 MCP）或插件機制。然而，這些方法常常伴隨高昂的 token 成本與開發維護門檻。

而 Claude Skills 則走上了完全不同的道路——以極度簡潔的架構，實現極高的靈活性。
每個 Skill 就是一個資料夾，裡面包含：

• 一個描述如何執行任務的 Markdown 文件；
• 一些可選的 腳本與資源；
• 以及前置 YAML 中繼資料（metadata），用來提供 Skill 簡介與載入條件。

Claude 僅在任務相關時才會載入 Skill，並透過這些指令學會如何完成特定任務——像是製作 Excel 報表、生成品牌手冊、或創建 PDF 文件。

Skills 是如何運作的？

在每次啟動對話時，Claude 的運行環境會掃描可用的 Skill 檔案，並從 YAML 前言區讀取簡短說明。
這項設計非常高效：每個 Skill 僅需佔用數十個 token 的描述，只有當任務確實需要時，Claude 才會載入完整內容。

舉例來說，Anthropic 官方釋出的 slack-gif-creator Skill 就是一個創意十足的案例。它能讓 Claude 自動生成符合 Slack 規格的 GIF 動圖：

“幫我做一個 Slack 用的動圖，主題是 Skills 比 MCP 酷得多。”

Claude 隨即生成了一個動圖（雖然結果不算完美），但重點是——Skill 容易被改進與迭代。
開發者可直接修改 Markdown 或 Python 腳本，再次測試即可。

# 首先將技能（skill）的目錄加入 Python 路徑
import sys
sys.path.insert(0, '/mnt/skills/examples/slack-gif-creator')

from PIL import Image, ImageDraw, ImageFont
# 這個類別位於技能的 core/ 目錄中
from core.gif_builder import GIFBuilder

# ... 用於建立 GIF 的程式碼 ...

# 將結果儲存到磁碟：
info = builder.save('/mnt/user-data/outputs/skills_vs_mcps.gif', 
                    num_colors=128, 
                    optimize_for_emoji=False)

print(f"GIF 建立成功！")
print(f"大小：{info['size_kb']:.1f} KB ({info['size_mb']:.2f} MB)")
print(f"幀數：{info['frame_count']}")
print(f"播放時間：{info['duration_seconds']:.1f} 秒")

# 使用 check_slack_size() 函式確認檔案是否足夠小，可用於 Slack：
passes, check_info = check_slack_size('/mnt/user-data/outputs/skills_vs_mcps.gif', is_emoji=False)
if passes:
    print("✓ 可上傳至 Slack！")
else:
    print(f"⚠ 檔案大小：{check_info['size_kb']:.1f} KB（限制：{check_info['limit_kb']} KB）")

Skills 與程式環境：LLM 的新能力邊界

要讓 Skills 發揮作用，Claude 必須具備：

• 檔案系統（filesystem）存取權；
• 能在其中執行指令與操作檔案；
• 並擁有安全的執行環境。

這正是近年 LLM 工具的主流模式：
自 2023 年 ChatGPT 的 Code Interpreter 問世後，這類「具程式執行能力的模型」迅速成為標準配置，後續的 Cursor、Claude Code、Codex CLI、Gemini CLI 皆沿用此概念。

換言之，Skills 的出現，不只是「讓模型更懂事」，而是正式讓 LLM 具備「自主操作電腦」的基礎。

Claude Code：從程式助手到通用智能體（General Agent）

作者 Simon Willison 曾經預測 2025 年的「智能體熱潮」終將破滅，但事實證明——他錯了。
Claude Code 不只是程式撰寫工具，而是一個能自動化電腦操作的「通用代理」。

任何可用命令完成的電腦任務，都能交由 Claude Code 透過 Skills 自動執行。
例如：

• 一個 Skill 負責下載人口普查資料；
• 另一個 Skill 將資料轉成 SQLite；
• 第三個 Skill 用 D3.js 建立互動式圖表；
• 最後一個 Skill 將分析結果上傳到 Datasette Cloud。

這樣就形成了一個「資料新聞智能體（Data Journalism Agent）」，完全由 Markdown + Python 腳本構成。

Skills vs MCP：輕量、直覺，且更聰明

雖然 MCP 曾被視為 AI 擴充協定的標竿，但其局限性逐漸浮現：

1. Token 消耗過高 —— GitHub 官方 MCP 本身就佔用數萬 token。
2. 協定過於複雜 —— 涵蓋主機、伺服器、資源、提示詞、HTTP/SSE 傳輸等。

相比之下，Skills 幾乎零成本。
不僅能以自然語言描述任務，還可選擇性地附加腳本，讓模型自動完成工作，無需再為每個功能開發獨立 CLI 工具。

Skills 生態系的崛起

Skills 的最大優勢之一是「可輕鬆共享與跨平台使用」。
它們可以：

• 以單檔或資料夾形式分發；
• 被不同模型（Claude、Gemini、Codex）共用；
• 不依賴專屬 API 或 SDK。

只需讓模型「讀取 SKILL.md 並執行描述」，即能完成任務。這種開放性預示著——我們將迎來一場 Skills 生態的大爆發。

簡單，才是力量所在

有人批評 Skills「太簡單」——僅僅是一個 Markdown 檔案與 YAML 註解。
但正如 Willison 所言，這種簡潔正是它的革命之處。

MCP 的複雜協定代表傳統軟體工程思維；而 Skills 回歸 LLM 的本質——「給我文字，我自己想辦法」。

它讓大模型自己處理複雜邏輯，而開發者僅需提供任務描述與必要的環境支持。這種以「文字即邏輯」為核心的理念，極可能成為未來 AI 開發的標準模式。

專業觀點與未來趨勢

1. 企業自動化平台的新基石
   Skills 將成為打造內部 AI 工具的關鍵技術，讓企業能快速建立內部助手（如報表生成、知識庫查詢、品牌文案工具）。
2. 跨模型互通的標準化機制
   由於 Skills 結構簡單，未來可能成為不同 AI 模型間的「通用技能語言」。
3. 安全與治理成為重點
   Skills 能執行代碼，意味著安全沙箱化（Sandboxing）與權限控管將是接下來 AI 工程界的重要研究課題。

📚 延伸閱讀與參考資料

• Claude Skills Cookbook（GitHub）
• 原文：Claude Skills are awesome, maybe a bigger deal than MCP

產品資訊及報價

依貴單位之使用情境 (是否需要 AI 繪圖 / AI 修圖) 及人數/帳號數 (可依公司/團隊使用人數/帳號數的比例來估算 ; 例如: 3人共用1組帳號)估算，再請來信諮詢，謝謝您。(因預算因素較難為每位員工皆購買，我司產品帳號可多人共用也可以同時使用，也可以搭配市面上消費者版本之 ChatGPT Plus、或Google Gemini AI 一起採購，如此效益CP值更好 ; 除了OpenAI ChatGPT模型外、若有其它模型版本需求也可填寫，如: Google Gemini, Claude, Google AI Pro for Education 教育版)
客服信箱- contact@build-school.com

產品簡介 – 適合中小企業/團隊多人共用，同時登入也可以使用，更超值

1. 好消息:即日起GPT/Gemini/Claude各廠模型全面開放與功能升級 – 左上角下拉選單可依個人喜好選擇各廠模型]提供予GPT-5/Gemini/Claude含AI繪圖修圖方案訂閱，不同情境選擇適合的模型輸出品質更好! 我們將持續提供產品新功能/模型升級，以提供更好的使用體驗
2. 多廠模型可使用CP值效益高:  本產品完整版含: OpenAI GPT + Gemini + Claude 對話模型 + Gemini 3 Banana Pro 繪圖/修圖模型(熱門!支援中文/解說圖/教材圖等，適合老師備課與教案設計用) + Gamma AI 簡報整合 + OpenAI GPT 4.1系列 + 我司 AI Art 藝術創作產品
3. ChatGPT 類似操作介面無需額外學習 – 提供與 ChatGPT Plus 付費版相近功能與AI模型，生成速度快及效果品質一致，支援文字生成、圖片辨別讀取與生成、上網搜尋、文件上傳與知識庫、對話釘選及分享、常用提示詞、團隊/班級工作區等功能，方便教學及班級使用。
4. 可開立台灣統一發票，從 5個帳號到 30個帳號版，適合想使用 ChatGPT Plus付費版之公司/企業/團體單位，皆能同時多人使用，1個工作天即可開通 – 訂閱期1年起彈性選擇。
5. 方便的對話管理功能 – 常用對話釘選及分享、並可將對話下載為 Word、PowerPoint、Excel、Markdown 檔案(方便匯入Notion等筆記軟體)方便後續編輯
6. AI 繪圖 / AI 修圖生成品質佳(需額外採購) – 可加購 AI 繪圖模型 Dall-E /OpenAI Image / Gemini Flash或 Flux，Flux 模型圖片生成品質與 Midjourney 看齊。(原方案AI 繪圖為文字生成圖片功能，2025/7月新產品方案額外增加並提供「AI 修圖 – 最新AI 圖像編輯模型」(如:上傳圖片換風格)，支援上傳圖像風格轉換(例如:轉為日式/美式動畫風格)、修圖(圖片中增加或修改物件，例如:衣服顏色/帶眼鏡/帽子)、多圖風格融合(例如:背包圖+人物圖=該人物背著這個背包)。支援各種圖像生成與編輯功能 – 包括教材插畫設計、貼圖生成、人物相片風格轉換、物品材質參考與置換、多圖風格或物品結合、圖片物品增修、Logo與海報/卡片設計、商品場景融合、室內設計風格轉換、服裝替換等各種進階的圖像編輯應用情境)
7. 公司/團體使用範例(多人登入皆可同時使用): 例如有10組帳號，可每個部門或同一專案提供其中一組帳號，建立該部門或團隊常用的對話資料夾 ; 每一組帳號皆可以多位共用，若同一帳號多人同時登入仍可使用，對話記錄會彼此交錯，建議作法可建立個別人員的對話資料夾用來保留各自對話，有助於對話/文件保存，或登出前將對話記錄刪除，或可使用「臨時對話」功能將不會儲存對話記錄 (適合若多人共用某一帳號時，「臨時對話」將不保留對話/也不會出現在左側對話清單它人看不到)
8. 彈性選購 OpenAI ChatGPT系列模型 – 可搭配GPT-5/ o4 系列的推理模型適合進階程式設計/軟體開發/資料分析並彈性使用 ; 若有其它模型需求 Gemini、Claude 也可額外選購
9. 使用微軟 Azure OpenAI 雲端服務，與 ChatGPT Plus 付費版相同的 AI 模型，包括最新的 gpt-5模型，生成速度快及效果品質一致 – 雲端服務建置於微軟 Azure 資料中心，高規格的資訊安全等級及資料保護。(請參考 – https://azure.microsoft.com/zh-tw/products/ai-services/openai-service )
10. 內建 Azure OpenAI 服務的預設安全原則，用來偵測並防止有害內容 – 利用內容篩選功能 (Content Filter) 及負責任 AI (Responsible AI) 準則，確保無法使用不合規及不適當文字。(請參考 – https://learn.microsoft.com/zh-tw/azure/ai-services/openai/concepts/default-safety-policies )
11. 使用常見的瀏覽器 Browser 版本，支援響應式網頁 RWD 適合各種裝置與載具及常見作業系統 (Windows/ Mac / Linux / iOS / Android)，從桌上型電腦、筆記型電腦、平板、手機等
12. 新增管理功能 「群組帳號管理」(因帳號可多人共用，為方便控管帳號權限，用來重置單位中某一帳號之密碼，僅單位帳號管理員專用。若已是產品訂閱用戶需要開通此功能，歡迎來信，謝謝您)

[好消息]OpenAI GPT/Google Gemini/Claude各廠模型全面開放 + Gamma AI 簡報 + Banana Pro 中文繪圖🔥依喜好及情境選擇不同的模型輸出效果更好

產品功能及操作影片

常用情境: 日常工作情境

• 文章解析 / 摘要 / 翻譯 / 文案撰寫
• 出題 / 解題 / 評量 / 中英文寫作評量
• 報告 / 研究 – 結合搜尋/檔案內容學習
• 學習計畫制定 – 行事曆及每日讀書進度
• 繪圖及圖片解析

2. 良好的提問法 – 提示詞工程 Prompt Engineering

• 範例學習
• 拆解工作流程
• 格式化輸入與格式化輸出 – excel / 表格 / markdown / 心智圖 / 甘特圖
• 角色設定

3. 進階使用技巧

• 外部工具(搜尋 / 爬取網頁 / 檔案上傳 / 知識庫) 強化能力
• 對話管理 – 目錄 / 釘選 / 分享 / 匯入匯出 / 臨時對話 (每次對話前可自行開啟，該次對話將不會出現在左側對話清單，也不會保留對話記錄其它人也看不到)
• 資料夾管理 – 依設定的「系統提示詞」(初始角色/回覆風格/要求格式等的提示詞)及上傳的文件(PDF/Word…)來回答

示範影片 – 學習資訊圖表網站(一頁式教材)與深入研究，一鍵生成線上高互動及美觀網頁，方便展示與教學

示範影片 -「互動式線上測驗題一鍵生成(類似Kahoot互動式答題)」，建立線上互動的隨堂小測驗，遊戲互動並增進樂趣

示範影片 – AI 修圖及進階圖像編輯 (上傳圖更改風格/物品等…)

對話介面進行修圖及圖像編輯

(請觀看) 更便利的操作介面及功能「 AI 藝術創作- AI Art Creative」上線了! 提供給2025/8月起新方案規格中含「AI 繪圖與AI 修圖」模型之訂閱用戶使用。操作便利性比原先在對話中進行修圖/風格轉換更方便，也新增了各種進階AI 修圖/多圖融合功能，包括: 風格轉換 / 貼圖製作 / 服裝與人物 / 人物與場景融合 / 商品攝影場景 / 物品/材質修改 / 室內裝修 / Logo設計 / 手稿/老照片上色修復 / 改比例/擴圖/去背 / 創意與趣味風格等進階圖像編輯功能

產品更新日誌

• 🔥熱門2026/1/18 – 好消息:即日起GPT/Gemini/Claude各廠模型全面開放與功能升級 – 左上角下拉選單可依個人喜好選擇各廠模型]提供予GPT-5/Gemini/Claude含AI繪圖修圖完整版訂閱，不同情境選擇適合的模型輸出品質更好! 我們將持續提供產品新功能/模型升級，以提供更好的使用體驗，謝謝您
• 🔥2026/1/12 – 開放[研究與程式專用-Gemini-DeepThinking] 的模型供全產品方案訂閱者使用; 適合軟體開發/數理運算/資料分析/議題研究，先思考後再執行，尤其網頁程式速度快又品質佳!

• 🔥熱門 2025/11/21 – Gamma AI簡報製作工具整合試用上線(為目前市面上頂尖的AI簡報工具)，初期提供 GPT-5.1/5 / Gemini / Claude 版的用戶使用，將逐步更新陸續開放，效果預覽如下!

• 🔥熱門 2025/11/19 – 最新全功能 GPT-5.1-自動優化模型上線 (比GPT-5速度更快,回覆較有人味) : 速度最快，自動依任務複雜度決定思考長度，強化回覆擬人化與情商, 能自動搜尋; 適合長文/資料分析/推理/程式，能力與知識全面超越 4.1/4o。

• 2025/11/18 – 新增管理功能 「群組帳號管理」(因帳號可多人共用，為方便控管帳號權限，用來重置單位中某一帳號之密碼，僅單位帳號管理員專用。若已是產品訂閱用戶需要開通此功能，歡迎來信，謝謝您)
• 2025/9/5 – 更新「對話資料夾」及 「臨時對話」功能(教學影片)，方便多人共用帳號及管理。建立專屬對話資料夾(從左側”對話”選單”+”)，在這個資料夾中新增對話時，將依你設定的「系統提示詞」(初始角色/回覆風格/要求格式等的提示詞)及上傳的文件(PDF/Word…)來回答。可搭配「臨時對話」功能(每次對話前可自行開啟，該次對話將不會出現在左側對話清單，也不會保留對話記錄其它人也看不到)

• 2025/9/5 – 新增工具列功能「輸出至數位白板」，可將對話結果帶入線上數位白板網頁中，也可自由的書寫、編輯、畫圖、適合展示與教學，若使用平板展示白板會更方便。

• 2025/8/28 – 學習資訊圖表網站(一頁式教材)與深入研究，可一鍵生成線上高互動及美觀網頁，方便展示與教學。

• 2025/8/13 – 更方便的操作介面「 AI 藝術創作- AI Art Creative」上線了! 提供給2025/8月起新方案規格中含「AI 繪圖與AI 修圖」模型之訂閱用戶使用。操作便利性原先在對話中進行修圖/風格轉換更方便，也新增了各種進階AI 修圖/多圖融合功能，包括: 風格轉換 / 貼圖製作 / 服裝與人物 / 人物與場景融合 / 商品攝影場景 / 物品/材質修改 / 室內裝修 / Logo設計 / 手稿/老照片上色修復 / 改比例/擴圖/去背 / 創意與趣味風格等進階圖像編輯功能。

• 2025/8/9 – [提供試用]最新全功能GPT-5系列模型-OpenAI 於2025/8/8 發佈全功能模型, 速度飛快且能力與知識全面超越GPT-4o系列模型
• 2025/7/9 – 提供「深入研究與報告-DeepResearch」模型功能給GPT-4.1後的新方案用戶，先思考推理擬出策略及執行步驟，再輸出結果;適合教材設計、寫報告與議題研究並附上參考來源，一次輸出可達3,000字以上，類似 ChatGPT DeepResearch及Perplexity 功能

• 2025/7/3 – 即日起正式提供「AI 修圖 – 最新AI 圖像編輯模型」(如:上傳圖片換風格)，支援上傳圖像風格轉換(例如:轉為日式/美式動畫風格)、修圖(圖片中增加或修改物件，例如:衣服顏色/帶眼鏡/帽子)、多圖風格融合(例如:背包圖+人物圖=該人物背著這個背包)。支援各種圖像生成與編輯功能 – 包括教材插畫設計、貼圖生成、人物相片風格轉換、物品材質參考與置換、多圖風格或物品結合、圖片物品增修、Logo與海報/卡片設計、商品場景融合、室內設計風格轉換、服裝替換等各種進階的圖像編輯應用情境。

• 各種風格變化及物品元素修改 (上傳1張圖 + 提示詞: 改為某某風格 / 加減或修改照片中物品元素 / 變換背景及場景)

• Logo 生成並用自然語言描述

• 有趣的玩具包裝 (上傳寫實全身照 + 提示詞控制出現的物品)

• 商品宣傳照結合與修圖 (上傳1至2張照片，如: 1張人物 + 1 張產品 + 提示詞: 讓這位主角手拿著商品，場景為居家/浴室/戶外等…)

• 室內裝潢風格及傢俱擺設示意 (上傳1張你的房間 + 提示詞: 將這個空間以”波西米亞風格”來設計)

• 2025/6/27 – 即日起正式提供 GPT-4.1 系列新模型供使用，其效能優於GPT-4o，包括 GPT-4.1, GPT-4.1-mini, GPT-4.1-nano 等模型，GPT-4.1 模型效能評估報告請參考 – https://learn.build-school.com/zh-hant/gpt4-1-openai-eval-report/
• 2025/6/19 – 增加 Excel 檔案下載，可將回覆對話中的區塊(例如 CSV 逗號分格之格式) 下載成 Excel 檔

• 2025/5/21 – (觀看示範影片) 增加「互動式線上測驗題一鍵生成」功能，建立線上互動的隨堂小測驗，類似Kahoot互動式答題，遊戲互動並增進樂趣。

• 2025/5/5 – 透過對話即可畫圓餅圖(pie chart) 及時間線圖(timeline)並直接顯示，如下

• 2025/5/1 – 增加 o4-mini推理模型 (適用情境: 進階程式設計/數理運算邏輯推理) ;  用於程式設計時，若為 HTML/JavaScript 網頁程式，也會自動將網頁結果展示在右側，如下圖 ; Python 程式碼可直接線上執行觀看結果。

• 2025/5/1 – 增加心智圖、甘特圖於對話中直接顯示，如下圖

• 2025/4/26 – 增加 PowerPoint下載，方便直接將對話轉為PPTX檔供後續編輯，並能保留標題、表格及圖示樣式。

• 2025/4/24 – 增加 Word 下載及 Markdown 下載，方便直接將對話轉為Word檔供後續編修、或轉為Xmind心智圖，如下圖

下載 Word檔後，從Xmind軟體匯入後如下的完好的「心智圖」，

其它模型版本及AI工具:

• Google Gemini 版本 – Gemini 2.5 Flash (一般文字工作情境) / 2.5 Pro (含推理功能用於進階程式設計/數理運算)
• Claude 模型版本 – Claude 3.5 / 3.7 / 4.0 適合進階軟體開發/程式設計/資料分析
• 各原廠 AI 工具: 我司也銷售各種AI工具，從ChatGPT、Gemini、Copilot、Azure等，提供台灣統一發票及統編方便B2B付款

隨著大型語言模型（LLM）的進步，我們已經不再只靠「提示詞設計」來追求效果，而是必須思考如何在有限的上下文視窗裡，選擇最重要的資訊。這就是所謂的 上下文工程（Context Engineering）。本文以 Anthropic 的最新研究為基礎，整理實務上的上下文管理方法，並加入適合團隊落地的檢核清單與量化指標，幫助專業讀者更有效地打造高效且穩定的 AI 智慧代理。

為何需要「上下文工程」：注意力預算與上下文退化

• 上下文是有限資源：當 Token 數量增加，模型的推理成本提高，同時準確回憶關鍵資訊的能力會逐步下降，這種現象被稱為 上下文退化（context rot）。可以把 LLM 想像成一個有「注意力預算」的系統，每多加入一個 Token，都會稀釋模型的專注度。
• 技術原因：Transformer 架構會讓每個 Token 嘗試關注所有其他 Token，導致關聯數近似 n² 成長。雖然有位置編碼延伸（RoPE scaling 等技術）可以處理較長序列，但對長距依存的精準度仍可能下降。

上下文工程 vs. 提示詞工程：從單次設計到持續管理

• 提示詞工程：主要是設計單次輸入的系統提示詞，偏重「寫出最佳指令」。
• 上下文工程：則是每一次推理前，都要決定「要讓模型看到什麼」，不只是提示詞，還包括工具、上下文協定、外部資料、訊息歷史等，是一個持續策展（curation）的過程。

打造高品質上下文：三個關鍵要素

1) System Prompt：抓住「恰到好處的高度」

• 避免兩個極端：
  • 過度硬編 if–else（脆弱、難維護）；
  • 指令過於籠統（假設了不存在的共享脈絡）。
• 做法：用清楚、直白的語言，搭配結構化段落（例如 <background_information>、<instructions>、## Tool guidance、## Output description 等），追求「最小但完整」的行為定義。

2) 工具設計：少而精、用途明確

• 工具是代理與外部世界的介面規範，需同時促進Token 效率與行為效率。
• 功能應該獨立、不重疊，參數清楚易懂，且能在錯誤時恢復。
• 如果連工程師自己都難以判斷該用哪個工具，就代表設計過度複雜。

3) 示例（Few-shot）：「代表性」比「完整性」重要

• 不要塞滿所有 edge cases 。
• 備少量但多樣化的代表性示例（可包含反例），讓模型能學到一般化的決策模式。

運行時策略：即時上下文（Just-in-Time Context）

• 與其一開始就把所有可能用到的資料放進上下文，不如只保留輕量的識別子（檔案路徑、查詢、連結），需要時再即時載入。
• 案例：Claude Code 使用 Bash、grep 等工具動態讀取檔案，而不是一次性塞進完整資料。
• 優勢：節省 Token、降低干擾；同時，**metadata（檔名、路徑、時間戳）**本身就能作為有用的提示。

長時程任務的三板斧：壓縮、結構化筆記、子代理架構

A. 壓縮（Compaction）

• 概念：對話接近視窗上限就總結重啟，只帶入高保真摘要＋最近關鍵片段（例如最近 5 個存取檔案）。
• 訣竅：先求高召回，再逐步提精確度；優先清理冗長的工具原始輸出（「工具結果清除」在 Claude 開發者平台已有功能支援）。

B. 結構化筆記（Structured Notes / Agent Memory）

• 概念：把進度、決策、未解問題寫到上下文外的持久存儲（如 NOTES.md），需要時再拉回；在非程式領域也能顯著提升長時程一致性。
• 產品上下文：Anthropic 在 Sonnet 4.5 發布時，同步釋出記憶工具公測，提供檔案型記憶介面，便於跨工作階段維持狀態。

C. 子代理架構（Sub-agent / Multi-agent）

• 概念：主代理負責規劃與彙總，專職子代理在乾淨視窗中各自深入探索，最後只回傳1–2k Token 的精煉摘要與關鍵附件。
• 效益：關注點分離，長而雜的搜尋上下文被隔離在子代理，不污染主線；在複雜研究任務上，相較單代理有顯著改善。

工程檢核清單與 KPI

設計與上下文密度

• System Prompt 最小但完整（原則 + 驗收準則）。
• 工具集去重疊、參數自描述、錯誤可恢復。
• 示例集 3–7 個「典型多樣」＋ 1–2 個反例；嚴禁「規則百科」。

檢索與即時載入

• Metadata 導航（路徑/命名/時間）與停損啟發式（避免深搜失控）。
• 關鍵檔預置上下文；其餘即時載入。

長時程穩定度

• 週期性壓縮觸發條件與「保留/丟棄」規則。
• NOTES.md / DECISIONS.md 模板化、持久化。
• 子代理輸入/輸出契約（結構化摘要上限、附件規格）。

建議 KPI

• Context Density：關鍵片段 Token／總 Token（越高越好）。
• Retrieval P/R：針對內部標準集做 needle-in-a-haystack 測試。
• Tool Efficiency：成功輸出平均工具次數、平均回傳 Token。
• Continuity Score：跨壓縮/重啟後，目標延續率與錯誤回歸率。
• Cost × Latency Budget：在 SLA 內達標的比例。

常見失敗模式與修正

• 工具過多且重疊 → 合併功能、明確邊界；下架低使用率工具。
• 示例塞滿邊界 → 改為「典型多樣」。
• 上下文愈塞愈長 → 先做密度盤點；導入即時載入與週期性壓縮。
• 缺少持久筆記 → 導入 NOTES.md / DECISIONS.md；重啟後先讀筆記再行動。
• 子代理回傳原始巨量資料 → 強制結構化摘要（字數上限＋結構化欄位）。

結語

上下文工程代表了我們構建 LLM 應用方式的思維轉變：重點不在追求更長的上下文，而是更聰明的選擇。不論是設計 Token-高效率的工具、採用即時上下文載入，或在長時程任務中使用壓縮／結構化筆記／子代理，透過系統化的上下文管理，工程師能讓代理在成本、延遲與品質間維持最佳平衡。

未來趨勢與建議

1. 上下文治理與可觀測性標準化：建立從來源 → 檢索 → 壓縮 → 輸出的可追蹤鏈路（含事件/工具日誌），把上下文變更與輸出品質綁定，支援合規與審計。
2. 更智能的即時上下文：隨模型變聰明，人工策展比重下降，但即時載入與子代理並行探索將成主流，並以最小人為規則的設計原則持續演進。

參考資料

主文來源：Anthropic — Effective context engineering for AI agents（發佈：2025-09-29）。

AI 助理的價值，不只在於回答，而在於「記得你是誰」。
自從 OpenAI 在 2024 年推出記憶功能以來，ChatGPT 不再只是個聊天工具，而逐漸變成一個能理解、學習並記住使用者的智慧夥伴。

然而，這項功能的底層機制一直神秘。直到近日，有位研究者解析了 ChatGPT 的記憶系統，揭露了它如何在沒有使用 RAG（Retrieval-Augmented Generation）、沒有知識圖譜、也沒有向量資料庫的情況下，達成近乎人類式的記憶能力。

一、ChatGPT 為什麼需要記憶？

一個能協助學習、編程、諮詢、甚至心理對話的超級助理，如果每次都要重新認識你，將無法建立真實信任。記憶不僅讓使用體驗更自然，也帶來產品黏性：每一段對話，都在強化使用者與平台的關係。這正是 Sam Altman 稱為他「最喜歡的功能」的原因。

二、ChatGPT 記憶架構的四大核心組件

研究者透過觀察系統提示（System Prompt）與實驗操作，發現 ChatGPT 的記憶由四個模組組成：

1. 交互元資料（Interaction Metadata）
2. 最近對話內容（Recent Conversation Context）
3. 模型設定上下文（Model Set Context）
4. 使用者知識記憶（User Knowledge Memories）

接下來逐一解析這四層如何構成 ChatGPT 的「數位記憶大腦」。

1. 交互元資料（Interaction Metadata）：環境與使用習慣的感知層

這是 ChatGPT 記憶系統中最基礎、但也最具啟發性的部分。
系統自動收集你的操作環境與使用模式，包括：

• 裝置資訊（螢幕尺寸、亮暗模式、瀏覽器版本、作業系統）
• 使用習慣（平均訊息長度、主題比例、活躍天數、模型偏好）
• 平台差異（App 與網頁版收集的資料不同）

這些資料雖然看似中性，但卻微妙地影響模型行為。
例如，當你問「我的相機壞了怎麼辦？」時，ChatGPT 可能直接給出 iPhone 修復步驟，因為它知道你在使用 iOS 裝置。這層資訊就像人類的「直覺」，讓 AI 對環境有感知。

2. 最近對話內容（Recent Conversation Context）：延續性的記憶軌跡

ChatGPT 會保留你最近約 40 次對話的使用者訊息（不包含 AI 回覆），並附上時間戳與主題。
這層相當於「短期工作記憶」，幫助模型在多次分開的對話中保持上下文連貫。

例如：
若你先前查詢東京機票、飯店與簽證資訊，再問「三月那邊天氣怎樣？」——
ChatGPT 會自動理解「那邊」指的就是東京。

只保存使用者訊息能節省大量 token，同時提供足夠語境。這是一種高效的記憶設計。

3. 模型設定上下文（Model Set Context）：可控的顯性記憶層

這是使用者能直接操作的記憶模組。
當你告訴 ChatGPT：「我對海鮮過敏」、「請記住我是一位行銷顧問」，這些資訊會被儲存為短句，並在每次對話時載入。

使用者可透過設定介面查看、修改或刪除這些記憶。
一旦與其他模組資訊衝突，它擁有最高優先權——因為使用者明確陳述的資訊，永遠比系統推斷更準確。

4. 使用者知識記憶（User Knowledge Memories）：隱藏的「壓縮人格」

這是最具突破性的部分。OpenAI 會定期自動生成一組「摘要式知識記憶」，將你過去數百次對話濃縮成數段文字。
例如：

「你是一位熱衷旅行與規劃的人，經常撰寫詳細的多日行程與預算。你曾規劃巴里島、舊金山、優勝美地、即將前往日本與尼泊爾的旅行……並偏好使用 Sony 相機與 Osprey 背包。」

這些記憶不可見、不可直接修改，但展現了 AI 如何從行為中推斷「你是誰」。
更驚人的是，這些摘要有明確的結構：

• 前段聚焦職業與技術背景
• 後段則描述你與 ChatGPT 的互動風格

不過，這些記憶並非實時更新，有時會持續數天甚至數週未刷新。
若你取消旅行，系統並不會自動察覺，除非你主動告訴它。

三、四層記憶如何協作：一個類神經式的「記憶模型」

作者將 ChatGPT 記憶系統比喻成人類學習的結構，非常貼切：

這樣的層級化設計，讓 OpenAI 能在不重訓模型的前提下，持續讓 ChatGPT「記得你、理解你、並跟著你成長」。

四、OpenAI 的「苦澀教訓」：少即是多

真正讓這篇研究震撼業界的，是作者發現——ChatGPT 的記憶架構沒有 RAG、沒有向量資料庫、沒有知識圖譜。
它只是把所有記憶打包，一次性放進系統提示裡。這看似粗暴，但背後是深思熟慮的設計哲學：

1. 模型愈強，就能自動忽略不相關資訊。
   ChatGPT 不需要檢索系統來過濾上下文，它能在大量 token 中自行找出重點。
2. 上下文視窗愈來愈大，成本愈來愈低。
   今天看似浪費的記憶包裝，未來可能幾乎免費。

這正呼應 AI 領域的經典理論——「最終決定 AI 成敗的，不是聰明的工程技巧，而是更強的模型與更大的算力。」
—— The Bitter Lesson

五、下一步挑戰：從靜態記憶走向即時學習

未來最重要的課題將是「記憶更新頻率」與「事實驗證」。
當使用者的生活變化時，AI 要如何：

• 偵測過期資訊？
• 驗證記憶是否仍正確？
• 捕捉那些使用者沒說出口的變化？

這些問題無法僅靠算力解決，而需要重新思考「記憶與對話的關係」—— AI 應該只是工具？還是成為理解使用者的長期夥伴？

未來趨勢

1. 個人化 AI 將主導下一波競爭
   能記住使用者偏好與背景的 AI，將讓「助理型產品」成為個人化服務的核心。
2. 資料透明與可控性成為新標準
   開放記憶檢視與刪除功能，將是 AI 產品能否被企業與專業人士採用的關鍵。
3. 即時記憶更新與跨應用整合是未來方向
   若 OpenAI 將記憶系統 API 化，讓第三方應用能共享「個人知識摘要」，將開啟全新生態。

參考資料

• 原文： ChatGPT Memory and the Bitter Lesson

什麼提示設計比以往更重要？

AI 模型越強，提示詞（Prompt） 的影響力就越大。
在 GPT-5 時代，你不只是在「問問題」，而是在「設計一段對話協議」，引導模型與你協作。

根據 OpenAI 官方 GPT-5 Prompting Guide，GPT-5 的特點包括：

• 更強的推理與多步操作能力
• 在工具使用與程式生成上更穩定
• 能精準控制語氣、細節與主動程度

換句話說，GPT-5 是一位「可訓練的專家助手」 —— 而提示設計，就是訓練它的語言。

一、認識 GPT-5 的提示新思維

在實際設計提示時，你可以從以下維度思考：

二、實作技巧：如何寫出高品質提示

下面是幾個具體、可操作的技巧與範例，讓你在 prompt 設計上更得心應手。

1. 明確列出計畫或步驟

在提示最前面，就寫出你要模型做什麼、順序是什麼。像是：

「請先幫我拆解這個任務，列出三個子任務；接著每個子任務按步驟執行，並在最後做總結。」

這樣模型內部就有「路線圖」，不會亂跑。

2. 使用工具前導提示（Tool Preambles）

如果模型有能力呼叫工具（例如查資料、改檔案、執行程式等），你可以在 prompt 裡定義「工具呼叫風格」：

• 要不要在每步驟前說明呼叫什麼工具？
• 要不要中途回報進度？
• 欲採用多詳盡的解釋／旁白？

例如，OpenAI 建議：

「先重新表述使用者的目標 → 接著列出結構化計畫 → 執行時每步敘述 → 最後總結」

3. 控制模型的「主動性」與「冗長度」

GPT-5 新增了幾個提示可控維度：

根據任務複雜度選擇適合的組合。

4. 提示自我反思 / 提示優化（Meta-Prompting）

一個有趣的策略是讓模型幫你優化提示本身。你可以問：

「這個提示我給 GPT-5，它有什麼可能跑偏？請建議幾個修正方向。」

指南中就有提到這類的「元提示 Meta-Prompting」用法可幫助你改良提示。

三、針對程式開發 / 多檔案專案的應用建議

由於 GPT-5 在程式碼層面有強化，這裏有一些專門對軟體工程流程有幫助的策略：

• 讓提示知曉專案結構與風格偏好
  在 prompt 裡簡述你的資料夾結構、命名風格、樣式／lint 規約等，讓模型輸出能跟現有 codebase 風格協調。
• 拆分任務 / 分段執行
  對於大型功能，讓模型先做整體設計、API 定義、再逐個模組實作。不要一次讓它接管全部。
• 避免 prompt 自身引導過度搜尋
  GPT-5 在理解與探索方面能力已強，過度提示 “maximize context gathering” → 反而可能讓它過度搜尋，浪費資源。Cursor 團隊就有這樣的觀察與調整。
• 善用版本控制與差異工具
  在做程式修改時，可以讓模型產出 diff／patch，而不是完整重寫。這樣更容易 review、整合。

四、常見陷阱與調整建議

在設計提示時，常見會踩到的坑，以及可以採取的補救策略：

五、範例提示（Prompt 示例）

下面是幾個示例 prompt，幫你感受實際「在 GPT-5 上用的提示」長什麼樣。

範例 A：解釋性問題（文字輸出）

「請用條列式說明 GPT-5 如何在 agentic 任務中控制主動性，並以簡單範例示意。全程不用呼叫工具。請回答中先給簡短概要，再逐點詳細闡述。」

範例 B：程式設計任務（有工具呼叫 / 多檔案）

你是專家程式設計助理。目標：為一個簡單的 REST API 專案，新增使用者驗證功能。
步驟：
1. 列出子模組規劃（routes, controllers, middleware, tests）  
2. 為每個模組撰寫主要功能骨架  
3. 在每個模組內產出具體程式碼（TypeScript / NestJS 為例）  
4. 請產出 diff／patch 格式，不要全部重寫  
在整個過程中，每一步都先說明你要做什麼再執行。若你需要呼叫工具查文件，請先回報「我要呼叫工具查 X」再呼叫。最終給我總結與下一步建議。

• 提示設計不是一次寫好就結束的流程，而是「迭代優化」的過程。
• 對於複雜任務（尤其程式開發、流程自動化等），你可以先寫粗略 prompt 試跑，觀察模型行為，然後調整：加明確條件、刪除矛盾、限定工具使用等。
• 若你願意，也可以讓 GPT-5 本身幫你「優化提示」。
• 最後，記住：GPT-5 的能力雖然強，但好的提示讓能力被真正釋放。

參考資料

原文：OpenAI 官方 Cookbook：GPT-5 Prompting Guide