作者: Jerry Lin

不只是 Prompt！Agent Skills 正悄悄統一 AI 助理，成為跨平台的超能力標準

來源：NotebookLM
摘要影片：https://youtu.be/JzskVI-wsT4

當我們談論客製化 AI 助理時，大多數人的第一反應可能是「調整 Prompt」。然而，這種方法往往感覺像是隔靴搔癢，難以建立可重複、結構化的複雜工作流程。現在，一個名為「Agent Skills」（代理人技能）的強大標準正在改變這一切。它不僅提供了一種更結構化的方式來擴展 AI 的能力，更令人驚訝的是，它正迅速成為一個跨越不同公司和產品的通用語言。

1. 驚喜的跨平台開放標準：AI 界的「通用語言」

最令人意外的發現是：Agent Skills 並非某家公司的專有技術，而是一個開放標準，正被多家相互競爭的 AI 開發工具所採納。有趣的是，「Skills」這個名稱最初由 Anthropic 的 Claude 推廣，但其核心理念——一個可移植、結構化的能力封裝——正被各家以不同名稱採納，例如 Google Gemini 的「Extensions」或 OpenAI Codex 的 AGENTS.md 文件，但都遵循著相同的開放標準原則。這在當前 AI 領域各自為政的環境中，顯得尤為難得且影響深遠。

支持此標準的 AI 代理和工具橫跨了業界的主要參與者，包括：

GitHub Copilot (根據官方文件，支援其編碼代理、CLI 及 VS Code Insiders)
Anthropic 的 Claude (包含 Claude Code、Claude.ai 和 API)
Google 的 Gemini CLI (目前為實驗性功能)
Cursor
OpenAI Codex (作為早期支援該模式的工具之一)

這個開放標準的官方文檔位於 agentskills.io。更重要的是，一個蓬勃發展的跨平台社群生態系正在形成。例如，Hugging Face 的 skills 程式碼倉庫就明確指出其技能可與主流編碼代理工具互通，而 GitHub 自己的 github/awesome-copilot 專案也收錄了大量社群創建的技能。這種跨公司的標準化意味著開發者可以「一次編寫，到處使用」，為特定任務封裝的專業知識和工作流程將具備前所未有的可移植性。

2. 為你的 Context Window 減壓：高效的「漸進式揭露」

Agent Skills 的核心運作機制是一種稱為「漸進式揭露」(progressive disclosure) 的高效模式，它極大地節省了寶貴的 Context Window 空間。

其運作方式如下：當 AI 代理啟動時，它只會載入每個可用技能的輕量級元數據，也就是 name (名稱) 和 description (描述)。完整的技能指令集 (SKILL.md 的內容) 和相關資源並不會立即被載入。只有當用戶的請求與某個技能的描述相符，該技能被「啟動」時，其詳細內容才會被注入到當前的對話上下文中。

這與將所有客製化指令都塞進一個龐大的系統提示 (system prompt) 中的低效做法形成鮮明對比。根據 awesome-claude-skills 倉庫的資料，一個技能在被啟動前可能只佔用 30-50 個 token，這充分展示了其在管理上下文時的卓越效率。

3. 最關鍵的一行程式碼：`description` 欄位是你的魔法棒

在 SKILL.md 檔案中，最重要的部分出乎意料地不是指令本身，而是 YAML frontmatter 中的 description 欄位。這一行文字是決定你的技能能否在正確時機被觸發的關鍵。

AI 代理會自主分析用戶的請求，並將其與所有可用技能的 description 進行比對。如果匹配成功，代理就會決定使用該技能。這個過程在文檔中被稱為「隱式調用」(implicit invocation) 或「自動發現」(automatic discovery)。

這意味著，一個寫得精準、具體、包含用戶常用關鍵字的描述，遠比指令內容本身更能確保技能的成功啟動。例如，一個模糊的描述如「幫助處理文件」，遠不如「從 PDF 文件中提取文字和表格，填充表單，合併文檔」來得有效。對於任何想要打造自己技能的開發者來說，這是一個至關重要的洞見。

4. 各司其職：何時用 Skills，何時用自訂指令？

Agent Skills 和其他客製化方法，如「自訂指令」(例如 CLAUDE.md 或 GEMINI.md)，並非相互取代，而是各司其職。理解它們的區別是有效運用 AI 助理的關鍵。

根據源文件的定義，它們的用途涇渭分明：

自訂指令 (Custom Instructions): 用於設定持續性、全域性的規則和指導方針。這些指令在幾乎所有對話中都應該生效，例如整個專案的編碼標準、程式碼風格指南或固定的輸出格式。
Agent Skills: 用於提供特定任務、按需取用的專業知識和可重複的工作流程。這些技能只在處理特定任務時被觸發，例如一套標準化的除錯流程、一份 PR 審查清單，或一個資料庫遷移的工作流程。

一個簡單的比喻是：自訂指令就像是公司的「員工手冊」，為所有員工提供通用的行為準則；而 Agent Skills 則像是為特定專案聘請的「外部專家顧問」，只在需要其專業領域知識時才會介入。

5. 層層疊加的專業知識：強大的範圍與優先級系統

Agent Skills 的設計中包含一個強大的分層結構，允許技能在不同的「範圍」(scope) 內生效，並定義了明確的優先級規則。

技能可以被儲存在不同的位置，從而決定其適用範圍：

專案/工作區 (Project/Workspace) 技能: 儲存在專案目錄下 (例如 GitHub Copilot 的 .github/skills、Gemini 的 .gemini/skills 或 Claude 的 .claude/skills)，通常會納入版本控制，與團隊共享。
使用者/個人 (User/Personal) 技能: 儲存在使用者的家目錄下 (例如 ~/.copilot/skills 或 ~/.claude/skills)，適用於該使用者所有的專案。
系統/擴充功能 (System/Extension) 技能: 由 AI 工具本身或其擴充功能捆綁提供，適用範圍最廣。

當不同範圍中存在同名技能時，優先級規則確保了行為的可預測性：更具體的範圍會覆蓋更通用的範圍。例如，專案技能會覆蓋使用者技能，而使用者技能會覆蓋系統技能。

這個分層系統極具威力，它讓團隊可以建立標準化的工作流程 (專案技能)，同時又賦予個別開發者根據個人偏好進行客製化或擴展的靈活性 (使用者技能)。

結論

Agent Skills 代表了 AI 協作模式的一次重要演進，從簡單的提示工程邁向了一個更結構化、可重用且具備互通性的新範式。它不僅為開發者提供了前所未有的能力來「教導」AI 如何以標準化方式完成複雜任務，其跨平台的開放標準特性更有可能在未來催生出一個繁榮的技能生態系統。

隨著這個開放標準的發展，您會想打造什麼樣的專業技能來為您的工作流程賦能？

—

附上心智圖

—

同場加映

在 SKILL.md 的 YAML 前言（Frontmatter）中，雖然各工具都遵循基礎標準，但 Claude Code 提供最豐富的進階控制欄位。

Claude Code YAML 欄位定義

根據官方文件，Claude Code 的欄位配置如下：

欄位名稱	是否必填	說明與使用方式	範例
`name`	是	技能唯一標識符，僅限小寫字母、數字與連字號，上限 64 字元。	`name: pr-reviewer`
`description`	是	描述功能與觸發時機，上限 1024 字元。代理據此決定何時激活技能。	`description: 審查 PR 並檢查代碼規範。`
`allowed-tools`	否	限制代理在技能激活時可用的工具。若省略則不限制。	`allowed-tools: Read, Grep, Glob`
`model`	否	指定執行該技能時使用的特定 AI 模型。	`model: claude-sonnet-4-20250514`
`context`	否	設置為 `fork` 時，技能會在獨立的子代理上下文中執行，不影響主對話。	`context: fork`
`agent`	否	當 `context: fork` 時，可指定子代理類型（如 Explore, Plan）。	`agent: Plan`
`hooks`	否	定義技能生命週期中的自動化腳本（如 PreToolUse, PostToolUse）。	見下文說明
`user-invocable`	否	是否在斜線命令選單中顯示。預設為 `true`。	`user-invocable: false`
`disable-model-invocation`	否	設置為 `true` 可阻止代理自動發現並觸發此技能。	`disable-model-invocation: true`

其他 AI 工具的欄位差異與額外欄位

其他工具通常僅支援基礎欄位，但有少數獨特定義：

GitHub Copilot:
- license (選填)：用於描述該技能適用的授權條款。
OpenAI Codex:
- metadata (選填)：可在其下定義 short-description，作為面向使用者的簡短說明。
Cursor & Antigravity:
- name (選填)：這兩個工具中 name 並非必填。若省略，系統會自動使用父資料夾名稱作為技能名稱。
Gemini CLI:
- 主要遵循基礎標準（name 與 description），並無 Claude 特有的 hooks 或 fork 欄位。

共通的核心機制

儘管欄位略有不同，所有工具皆採用**漸進式披露（Progressive Disclosure）**機制：啟動時僅讀取 name 與 description 以節省 Token，只有當任務匹配時才會加載完整的指令與資源。

—

在撰寫 SKILL.md 的 YAML 前言時，VS Code (GitHub Copilot) 與 Claude Code 都遵循基礎標準，但 Claude Code 提供了更多進階的控制欄位。

VS Code (GitHub Copilot) 的 YAML 欄位

VS Code 的配置相對簡約，主要聚焦於識別與觸發：

name (必填)：唯一標識符，限小寫、數字與連字號，上限 64 字元。
description (必填)：定義技能功能與觸發時機（Copilot 據此決定何時加載），上限 1024 字元。
license (選填)：描述該技能適用的授權條款。

Claude Code 的進階 YAML 欄位

Claude Code 除了支援上述基礎欄位外，還增加了許多功能性控制：

allowed-tools：限制代理在技能激活時可使用的工具（例如只允許 Read、Grep），增加安全性。
context: fork：將技能放在獨立的「子代理」中執行，避免污染主對話歷史。
agent：配合 fork 使用，指定子代理類型（如 Explore 或 Plan）。
hooks：定義自動化腳本的觸發事件（如 PreToolUse 或 Stop）。
user-invocable：控制該技能是否顯示在 / 斜線命令選單中（預設為 true）。
disable-model-invocation：若設為 true，可阻止 Claude 自動發現並觸發此技能。

核心差異總結

特性	VS Code (Copilot)	Claude Code
主要定位	任務導向的指令擴充	高度自動化的工作流控制
工具限制	不支援限制工具	可透過 `allowed-tools` 精確限制
環境隔離	始終在當前對話中加載	可透過 `fork` 建立獨立執行環境
生命週期	無特定事件處理	可透過 `hooks` 執行前後置腳本

2026-01-14

臺灣的全民安全指引不只教你打包：5個你可能從沒想過的防災真相
這是一篇最近台灣政府發的小冊子《當危機來臨時：臺灣全民安全指引》下載連結心得，我把他丟到 NotebookLM 上，順道生成了一篇 blog ，就紀錄起來。

以下正文：

我檢查了我的緊急避難包三次，但讀完臺灣最新的《全民安全指引》後，我才發現自己錯過了最重要的一環。

當我們談到「防災準備」，許多人腦中浮現的第一個畫面，就是一個裝滿物資的背包。但這真的夠了嗎？這份官方指引揭示了一個遠比打包更深入、更現代的安全思維。它提出了一些真正發人深省的問題：如果手機和網路中斷，你和家人有約定好的集合地點嗎？如果提款機因停電而失靈，你有足夠的現金應急嗎？

這篇文章將從這份重要的官方手冊中，為你提煉出5個最令人驚訝、也最關鍵的防災真相，幫助你重新思考「準備」的真正意義。

—

1. 你的準備不是一個背包，而是一個系統 (Your Prep Isn’t a Bag, It’s a System)

在這裡，這份指引做出了一個與傳統思維 brilliantly different 的區別。許多人誤以為防災就是準備一個「緊急避難包」，但指引強調，你的準備應該是「一個為了『在家固守』，一個為了『緊急撤離』的雙軌系統」。

這套系統的核心在於「彈性」。單一的避難包只適用於撤離，但現代危機中，更有可能發生的情境是必須在家避難（例如大規模封鎖或基礎設施中斷）。因此，系統的第一部分是「日常的居家儲備」，指引建議至少要有一週的份量，涵蓋每人每日3公升的飲用水、食物、衛生用品和常備藥物。

為了讓儲備變得簡單，手冊推薦了一個聰明的「生活竅門」：採用「循環儲備」法。平時就購買儲備物資，在日常生活中優先使用它們，然後再定期補充。這個「先儲備、後使用、再補充」的循環，移除了防災準備的經濟與管理負擔，讓它成為人人都能輕鬆實踐的習慣。這個「居家儲備」加上「避難包」的雙重系統，遠比單純一個背包來得更具韌性，能應對更多元的危機情境。

—

2. 現代危機中，最大的斷點是「電」和「網路」 (In a Modern Crisis, the Biggest Failures are ‘Power’ and ‘Internet’)

這部分揭示了這份指引對現代社會運作方式的深刻理解。我們高度依賴的數位化社會，同時也極度脆弱。指引特別點出，大規模停電或網路中斷將引發一連串災難性的「骨牌效應」（cascading failures）。

這不僅僅是無法上網而已。手冊列舉了幾個你可能沒想過的第二、三層後果：
- 提款機（ATM）可能無法運作，讓你無法提領現金。
- 電子鎖、電動鐵捲門和電梯將會失效，可能讓你被困在室內或無法進入家中。
- 冰箱失去電力，儲存的食物會迅速腐敗。
- 使用加壓馬達供水的高樓層住戶，可能會在停電後不久就面臨停水。
面對這些高科技社會的脆弱點，指引提出的解決方案卻出奇地「低科技」且極具韌性：隨身備有少量現金、擁有一台可攜式的電池收音機，以及確保行動電源隨時充飽電。這提醒了我們，真正的準備不是追求更炫的科技裝備，而是要建立簡單、可靠、不會輕易失效的備援方案。

—

3. 真正的戰場也在你的手機裡 (The Real Battlefield is Also in Your Phone)

這份指引將資訊安全與辨識假訊息，提升到了國家安全的高度。手冊明確指出，在危機時期，敵人會利用網路散播假訊息，其目的在於「動搖民心與破壞社會穩定」。

為了應對資訊戰，指引提出了「3不1要」原則：不製造、不輕信、不轉傳來源不明的訊息，並且要查證。這不僅僅是媒體素養教育，指引將其視為一項核心的國民防衛技能——你的心智，也是戰場的一部分。在網路與通訊中斷時，手冊也指明了可靠的官方資訊管道，例如警廣與漢聲廣播電臺的特定頻率。

其中，手冊用最嚴肅的語氣強調了一條至關重要的原則：

倘若臺灣遭受軍事侵略，任何有關國家戰敗或政府宣布投降的訊息，都是假訊息！

這句話清楚地告訴我們，在最壞的情況下，保持資訊判斷力與心理上的堅定，和準備物資同等重要。

—

4. 急救不只是等救護車 (First Aid Isn’t Just Waiting for the Ambulance)

平時我們習慣遇到緊急狀況就撥打119，等待專業救護。但《全民安全指引》點出一個殘酷的現實：在重大危機中，消防和醫療系統將會不堪重負，無法像平時一樣即時回應每個人的需求。

這意味著，等待救援可能不再是選項。這是一種根本性的思維轉變——責任的「去中心化」。我們每個人都必須學會簡單的自救與互救能力，才能在救援抵達前的黃金時間內，保護自己與家人的生命。

手冊中涵蓋了基礎但極為重要的急救技巧，例如燒燙傷處理的「沖、脫、泡、蓋、送」五步驟、嚴重出血時的直接加壓法或止血帶使用，以及心肺復甦術（CPR）。這代表著從一個被動等待救援的受害者，轉變為能為自己、家人乃至社區提供第一時間援助的主動救援者。

—

5. 心理韌性和社區連結是你的終極裝備 (Mental Resilience and Community Ties are Your Ultimate Gear)

這份指引的思維是一以貫之的。如同它將急救的責任從專業人員下放到每一位公民，它也將社會安全網的重心，從大型機構延伸到了你我身邊的鄰居。這同樣是「去中心化」韌性的體現。

真正的安全準備，不僅僅是物質層面。《全民安全指引》花了相當的篇幅討論心理健康與社區支持系統，這兩者才是面對長期壓力與未知威脅的終極裝備。

手冊建議，當我們感到焦慮時，可以透過以下方式應對：
- 與家人、朋友談論感受，維持人際連結以降低孤獨感。
- 維持良好的飲食、睡眠與運動習慣。
- 減少過度閱讀新聞或網路資訊，避免資訊超載。
- 必要時尋求專業心理機構協助。
此外，手冊也特別指導家長如何與孩子討論危機，例如傾聽他們的恐懼，並邀請他們一起參與準備緊急避難包的過程，給予他們安全感。

在整份指引中，一個問題反覆出現：「你是否認識你的鄰居？」這並非隨口一提，而是整個去中心化韌性哲學的最終體現。在危機中，最有效、最即時的資源，往往就是你身邊的人。

—

Conclusion: Preparedness Is a Mindset, Not a Checklist

《全民安全指引》給我們最大的啟示是：真正的準備遠遠超越一份物品清單。它是一種全方位的思維模式，融合了充足的物資、可靠的低科技備援、敏銳的資訊判讀力、能拯救生命的急救技能，以及最重要的——強韌的心理素質與緊密的社群關係。

如同手冊不斷強調的座右銘：「有準備，更安全」。

這份指引不是要你恐慌，而是要賦予你力量。所以，今天就去做一件事：去跟你的鄰居打聲招呼，或是把幾張千元鈔票放進你的避難包。最小的準備，就是最強大的開始。
2025-11-23

VS Code 1.106 版本技術摘要：AI Agent 深度整合與核心編輯器開源

這是一份由 NotebookLM 生成的文章內容，介紹 VSCode V_106 升級的細節摘要。

簡介

本文件旨在為內部開發與產品團隊提供 Visual Studio Code 1.106 版本的深度技術解析。本次更新標誌著兩項重大的架構性演進：一是透過全新的「Agent HQ」實現 AI Agent 的深度整合與統一管理，這項變革提供了一個 AI 互動的統一控制平面，解決了以往 Agent 會話分散且難以追蹤的挑戰；二是將核心的「行內建議」功能開源，並整合至統一的 Copilot 擴充套件中，這是一項對平台開放性具有深遠影響的戰略舉措。本摘要將聚焦於這些變更的技術實現細節、對現有開發工作流程的影響，以及平台 API 的重要更新，以利團隊進行後續的技術評估與產品規劃。

——————————————————————————–

1. 核心架構演進：AI Agent 整合與管理 (Agent HQ)

VS Code 1.106 版本在 AI 整合方面最核心的架構性變革，是引入了一個統一的 Agent 管理中心——Agent HQ。本章節將深入分析 Agent HQ 的核心組件、新引入的 Agent 工作流程，以及跨環境整合的技術實現，解析這些變革如何為開發者提供更集中、更強大的 AI 協作能力。

1.1 Agent HQ 核心功能解析：Agent Sessions view

「Agent Sessions view」是管理所有 AI 互動的核心介面，其設計目標是提供一個單一入口，以監控和審查所有進行中的 Agent 會話。

集中式管理：此視圖整合了本地（在 VS Code 內部啟動的 Chat）與遠端背景執行的 Agent 會話，涵蓋了如 GitHub Copilot CLI、OpenAI’s Codex 等多種來源。
預設啟用與配置：該視圖現已預設啟用，開發者可透過 chat.agentSessionsViewLocation 設定進行客製化。值得注意的是，single-view 選項可將所有提供者的會話合併至單一視圖中，提供更緊湊的體驗。
高效搜尋：新增的搜尋功能 (⌥⌘F / Ctrl+Alt+F) 對於需要管理大量並行 AI 任務的開發者而言極其實用，能快速定位特定會話。

這種集中式模型是一次關鍵的架構轉變，它降低了開發者的認知負荷，並為未來編排複雜的多 Agent 工作流程提供了基礎層，超越了簡單的單次互動模式。

1.2 新增 Agent 類型與工作流程：Plan Agent

本次版本引入了一種全新的「Plan Agent」，其策略價值在於將 AI 的介入時機提前至程式碼撰寫之前，專注於任務的規劃與分解。

工作流程分析：此 Agent 首先透過一系列引導性問題來釐清複雜任務的需求，隨後生成一份詳細的實施計畫。該計畫必須經過開發者審批後，才會交由 Copilot 執行。
對開發流程的影響：這種「先規劃，後執行」的模式，有助於在專案初期就發現潛在的需求缺口或決策遺漏。這不僅能大幅減少後期的重工，更能從源頭上提升最終交付的程式碼品質。
可自訂性：團隊可透過「Configure Custom Agent」功能，複製內建的 Plan Agent 作為模板，量身打造符合團隊特定開發流程與工具鏈的規劃 Agent。一旦計畫被批准，Copilot 可以在 VS Code 本地執行，或透過雲端 Agent 來完成實施。

1.3 跨環境 Agent 整合

Agent HQ 的架構設計充分考慮了跨環境協作的需求，特別是在雲端與命令列工具的整合上。

Agent 類型	技術整合重點
Cloud Agents	Copilot coding agent 的核心整合邏輯已從 `GitHub Pull Request` 擴充套件遷移至 `Copilot Chat` 擴充套件。此項架構簡化提供了更原生的體驗，並為 VS Code 與 GitHub Mission Control 之間的無縫互動奠定基礎。
CLI Agents	本次版本實現了與 Copilot CLI 的初步整合。使用者現在可以直接在 VS Code 的聊天編輯器或整合式終端機中，建立或恢復 CLI Agent 的會話，實現了 GUI 與 CLI 工具鏈的無縫銜接。

1.4 術語統一與自訂 Agent 增強

為保持與其他開發環境術語的一致性，並增強自訂能力，平台進行了以下調整：

術語統一：「Chat modes」已在整個 VS Code 中正式更名為「Custom agents」。
定義檔案標準化：自訂 Agent 的定義檔案位置已統一至工作區的 .github/agents 目錄下，並使用 .agents.md 作為標準副檔名。系統為舊有的 .chatmode.md 檔案提供了平滑的遷移路徑。
元數據擴展：.agent.md 檔案的 frontmatter 中新增了多個關鍵屬性，以實現更精細的控制：
- target: 描述 Agent 的目標運行環境（例如 vscode, github-copilot）。
- name: 允許覆寫 Agent 在 UI 中顯示的標籤名稱。
- argument-hint: 在聊天輸入框中提供參數提示，引導使用者正確與 Agent 互動。
- handoffs: 允許將多個 Agent 串接起來，形成複雜的多步驟工作流程。handoffs 屬性尤其值得關注，它促成了可組合的 AI 工作流程。這使得我們能設計並串聯多個專責的、單一職責的 Agent，是建構複雜、企業級 AI 助理時更穩健、更易於維護的架構方法。

總結而言，Agent 架構的全面升級，從管理介面到工作流程，再到跨環境整合，為 AI 驅動的開發模式奠定了更為堅實與可擴展的基礎。接下來，我們將探討編輯器核心層面的重大演進。

——————————————————————————–

2. 編輯器核心開源與開發體驗優化

除了 AI Agent 的革新，1.106 版本在編輯器核心層面也進行了重大調整，特別是將關鍵的 AI 功能開源，這對平台的未來發展具有指標性意義。本章節將剖析「行內建議」功能的開源始末及其對 Copilot 擴充套件生態的影響，並介紹其他直接提升日常編碼效率的關鍵優化。

2.1 「行內建議」功能開源與擴充套件合併

此版本達成了一個重要的里程碑：將「行內建議 (Inline suggestions)」功能正式開源，並將其核心程式碼合併至 vscode-copilot-chat 儲存庫。

策略意圖分析：此舉的核心目標是將原先獨立的 GitHub Copilot 和 GitHub Copilot Chat 兩個擴充套件，合併為單一的整合式體驗。未來，將由 Copilot Chat 擴充套件統一提供所有行內建議、聊天及 Agent 功能。
棄用時程與行動：GitHub Copilot 擴充套件計畫將於 2026 年初被棄用，這是一個關鍵的時程節點。我們的團隊必須開始規劃，在所有標準開發環境中轉換至統一的 Copilot Chat 擴充套件，以避免未來的服務中斷。
回退機制：為確保平滑過渡，提供了一個 chat.extensionUnification.enabled 設定。若在遷移過程中遇到任何問題，使用者可暫時利用此設定恢復到舊的雙擴充套件行為模式。

2.2 差異比較 (Diff) 與程式碼導航功能強化

本次更新包含了多項針對開發者日常高頻操作的體驗優化。

Diff Editor 優化：在內嵌差異檢視 (inline diff view) 中，先前無法被選取的「已刪除程式碼區塊」現在已支援選取與複製操作。這項改進雖然細微，卻極大地提升了程式碼審查（Code Review）的便利性。
Go to Line 功能增強：「Go to Line」(⌃G / Ctrl+G) 命令的功能得到了顯著擴展。現在，它支援使用 :: 語法直接導航至檔案中的特定字元位置（例如 ::599 可跳轉至第 599 個字元，::-100 可跳轉至距檔案結尾 100 個字元處），這對於處理來自工具鏈的、基於字元偏移量的錯誤報告非常有用。同時，該功能對於超出範圍的行號與欄號處理也更加友好，簡化了跳轉至檔案或行首/尾的操作。

這些編輯器層面的優化直接提升了開發者的日常工作效率。接下來，我們將探討同樣重要的終端機與 Chat 工具鏈之間更深層次的整合。

——————————————————————————–

3. 終端機 (Terminal) 與 Chat 工具鏈深度整合

終端機作為開發者的核心工具，在 1.106 版本中與 AI Chat 的整合達到了新的高度。這些改進旨在將 AI 的智慧能力無縫注入到傳統的命令列工作流程中。本章節將分析 Terminal IntelliSense 的正式發布、Terminal Tool 內部解析器的重大升級，以及 Chat 與終端機之間實現的創新雙向互動。

3.1 Terminal IntelliSense 正式發布

經過長達 1.5 年的預覽階段，Terminal IntelliSense 功能現已正式發布，並將分階段向所有穩定版使用者預設啟用。

核心價值：此功能為 PowerShell、bash、zsh 和 fish 等主流 shell 提供了類似程式碼編輯器的智慧提示與自動補全體驗。
智慧提示來源：其補全建議來源多樣，具備高度上下文感知能力：
- 路徑補全：由 VS Code 核心提供，反應靈敏。
- 指令規格：能根據指令語義提供智慧建議，例如，在輸入 git 相關指令時，能自動提取當前的分支名稱作為補全選項。
- 新增支援：本次更新後，copilot 與 azd CLI 已被納入支援範圍，具備開箱即用的補全功能。
高度可配置：該功能提供了豐富的配置選項，開發者可透過 terminal.integrated.suggest.enabled 手動啟用，並進行細粒度的行為調整。

3.2 終端機工具 (Terminal Tool) 剖析

後端用於解析和執行終端機指令的 Terminal Tool 進行了底層升級，顯著提升了其安全性與可靠性。

解析器升級：在自動批准 (auto approve) 機制上，系統從過去簡單的字串分割邏輯，升級為整合了完整的 PowerShell 和 bash 文法解析器。
技術優勢：從粗糙的字串分割升級為正規的文法解析器，是對該工具可靠性與安全性的根本性增強，使我們能更自信地自動批准範圍更廣的複雜 shell 指令。例如，它能正確處理 echo "a|b|c" 這類包含在字串中的特殊字元，避免錯誤解析，並安全地支援括號、大括號等複雜語法。重要限制：需注意，此解析器基於 bash 文法，這意味著當 shell 語法與 bash 不同時（如 zsh 中的 ;），可能無法成功捕獲子命令。
基於新解析器的實驗性功能：
- 檔案寫入/重導向偵測：可透過 chat.tools.terminal.blockDetectedFileWrites 設定，有條件地阻止 AI Agent 執行可能覆蓋檔案的寫入操作，增強安全性。
- 禁用預設自動批准規則：chat.tools.terminal.ignoreDefaultAutoApproveRules 設定允許使用者完全自訂批准規則，實現更嚴格的權限控制。
Shell 特定提示：終端機工具現在能為 PowerShell、bash、zsh 和 fish 提供針對性的 shell 提示，這使得 AI Agent 建議的指令更加可靠，減少了因 shell 語法差異導致的執行失敗。

3.3 Chat 與終端機的雙向互動

新的工作流程打通了終端機與 Chat 之間的資訊壁壘，實現了雙向的上下文傳遞。

從終端機到 Chat：開發者現在可以從終端機命令裝飾器 (command decoration) 的右鍵選單中，將一條已執行的終端機命令作為上下文，直接附加到 Chat 會話中。
上下文完整性：附加的內容非常完整，包含了完整的指令、捕獲的標準輸出以及最終的結束代碼。這讓 AI Agent 能夠精確理解指令的執行情況，從而提供更具針對性的除錯建議或後續操作。
輸出內嵌顯示：實驗性的 chat.tools.terminal.outputLocation 設定，允許將終端機指令的輸出直接內嵌顯示在聊天視窗中。特別是在指令執行失敗時，輸出會自動展開，極大地簡化了除錯流程。

終端機與 AI 的無縫整合，極大地提升了命令列操作的智慧化程度與安全性。下一章節將轉向平台層面，探討為擴充套件開發者提供的最新 API 與能力。

——————————————————————————–

4. 平台擴充性與 API 更新

1.106 版本不僅增強了使用者功能，也為擴充套件生態系統的發展提供了更強大的底層支援。本章節將重點介紹針對企業級應用的 MCP 協議更新、擴充套件開發者可用的核心 API 變更，以及幾項前瞻性的提案中 API，這些更新為建構更深度整合的 VS Code 體驗開闢了新的可能性。

4.1 MCP (Model Context Protocol) 企業級支援與驗證更新

針對企業環境中的模型與工具管理，MCP 進行了多項關鍵升級：

企業級註冊中心：VS Code 現已支援透過 GitHub 組織策略來配置 MCP 註冊中心。企業可透過 chat.mcp.gallery.serviceUrl 和 chat.mcp.access 設定，自訂可供內部安裝和啟動的 MCP 伺服器列表，實現集中化管理。
工作區級別配置：安裝 MCP 伺服器時，新增了安裝到工作區配置 (.vscode/mcp.json) 的選項。這使得團隊成員可以輕鬆共享專案所需的特定 MCP 伺服器配置。
驗證流程升級：
- CIMD 支援：新增了對 Client ID Metadata Document (CIMD) 驗證流程的支援，這是一種更安全、可擴展性更強的 OAuth 驗證標準，提升了與現代授權伺服器整合的安全性。
- 動態權限提升：支援透過 WWW-Authenticate 標頭進行動態範圍 (scope) 提升。此機制遵循最小權限原則，允許應用程式僅在執行特定操作需要時才請求提升權限，而非在初始連接時便要求所有權限。

4.2 擴充套件作者 API 更新

本次釋出包含了多項穩定的 API 更新，為擴充套件開發帶來了新的能力：

AuthenticationSession 中的 idToken：AuthenticationSession 介面新增了一個可選的 idToken 屬性。這允許身份驗證提供者在返回 access token 的同時，也返回包含使用者身份聲明的 ID token，對於需要驗證使用者身份的場景非常有用。
Git Extension API：內建的 Git 擴充套件提供了一個新的 getRepositoryWorkspace API，可用於獲取與特定 Git 遠端儲存庫關聯的本地工作區資料夾，簡化了與 Git 相關的擴充套件開發。
Secondary Side Bar 視圖容器：擴充套件作者現在可以使用新增的 secondarySidebar 貢獻點，將自訂的視圖容器註冊到第二側邊欄中，使其擴充套件能更好地融入 VS Code 的雙側邊欄佈局。

4.3 提案中 API (Proposed APIs) 預覽

以下幾項重要的提案中 API 預示了平台未來的擴充方向：

Quick Pick & Quick Input 增強：提案中新增了對切換按鈕 (toggle buttons) 的支援，可在輸入框中添加互動元素。同時，也支援了提示文字 (prompt) 以及根據 resourceUri 自動顯示檔案類型圖示，豐富了快速選擇介面的互動性。
MarkdownString 支援：MarkdownString 新增 supportAlertSyntax 屬性，可用於渲染 GitHub 風格的警示框（如 NOTE, WARNING）。此外，TreeItem 的標籤現在也支援 MarkdownString，這意味著樹狀視圖的項目可以包含 codicons 圖示和豐富的文字格式。

平台 API 的持續演進為團隊自訂和擴展 VS Code 提供了強大工具。最後一章將關注專案的工程實踐與版本維護資訊。

——————————————————————————–

5. 工程實踐與重要修復

本次版本迭代不僅帶來了功能創新，也在開發流程和平台穩定性方面有所提升。本章節將簡要介紹一項用於改善 UI 變更審查流程的內部自動化探索，並列出本次更新中重要的平台支援變更與數個關鍵問題的修復。

5.1 內部工程流程改進：自動化 UX 測試

為提升 UI 變更的審查效率，團隊正在探索一項新的自動化工作流程。

流程概述：當一個 Pull Request (PR) 被標記上 ~copilot-video-please 標籤時，自動化程序將會啟動。它會自動建置該 PR 的分支版本，並利用 GitHub Copilot CLI 和 playwright-mcp 工具來模擬使用者操作，錄製一段操作影片。最終，這段影片連同 Playwright 追蹤檔案會被發佈為 PR 的一則留言。
評估價值：儘管此流程尚處於早期探索階段，但它有望顯著減少審查者手動下載、建置並驗證 UI 變更所需的工作量，特別是對於小型 UI 調整，能夠提供快速直觀的驗證結果。目前，這些影片僅供團隊成員存取。

5.2 平台支援變更與關鍵問題修復

平台支援：行動要求：VS Code 1.106 是支援 macOS 11.0 (Big Sur) 的最終版本。 所有開發團隊必須確保其設備在下一個發布週期前升級至相容的作業系統版本，以維持技術支援。
關鍵問題修復：本次更新解決了多個影響開發者體驗的問題，其中幾個較為重要的修復包括：
- vscode#258236: 為擴充套件安裝過程新增了請求超時設定，以應對網路不穩定的情況。
- vscode#272945: 修正了 Tasks 未能正確觸發 onDidStartTerminalShellExecution 事件的問題，恢復了任務相關擴充套件的正常運作。
- vscode#243584: 修正了在 PowerShell/conpty 環境下，第一個鍵盤輸入有時會被忽略的錯誤。
- vscode#274631: 網路層面：在 Windows 平台上，現在會正確加載中繼憑證授權單位，解決了部分企業網路環境下的連線問題。

2025-11-22

將 VSCode copilot 的 instructions 資料夾移動到外面
最近終於從孤獨的開發者轉到多人協作開發同一個 git repository 的工作環境中。於是開始想辦法把自己的舒適圈擴大到這個環境裡面。

最近想將 VSCode copilot 的 instructions 資料夾移動到外面。主要有幾個目的：
1. 方便管理，我可以將 instructions 資料夾作一個 git 管理，一次變更多處同步。
2. 基於各種原因，我不想將 git 中 .github/instructions 推進 git 版控中。
第二點原因有很多種，例如協作環境中，大家負責的項目不同，可能需要的規範/指南也不一樣。或是大家都 commit 自己的指南，容易衝突或是可能因為嘗試的狀態下，容易產生大量的變更，造成無關的 pr 的困擾（還需要整理有點累）。基於與一般協作管理 instructions 剛好相反的需求之下，也有一些既有限制：
1. git repo 內的環境設定相關檔案儘量不要動到
2. .github 已經在版控裡面了（不想把檔案更新上 git)
如果你也剛好有一樣的狀況，那麼恭喜，接下來設定很適合你。

如果你不知道 instructions 是什麼，可以先看這篇。簡單來說他是 AI 工具之一，他有提供使用 instructions 來作為提示詞的規範指南，可以參考這裡介紹。其中介紹中有說到的重點節錄如下：

VS Code 支援多種基於 Markdown 的指令檔。如果您的專案中存在多種類型的指令文件，VS Code 會將它們合併並添加到聊天上下文中，但不會保證特定的順序。
1. 單一.github/copilot-instructions.md文件
  - 自動套用於工作區中的所有聊天請求。
  - 儲存在工作區中
2. 一個或多個.instructions.md文件
  - 為特定任務或文件而創建
  - 使用a pplyTofrontmatter 定義指令應應用於哪些檔案。
  - 儲存在工作區或使用者設定檔中
3. 單一AGENTS.md文件（實驗性）
  - 如果您在工作空間中使用多個 AI 代理，這將非常有用。
  - 自動套用於工作區中的所有聊天請求。
  - 儲存在工作區的根目錄中。
指令之間的空格將被忽略，因此指令可以寫成一個段落，每條指令另起一行，或者為了方便閱讀，可以用空行分隔。

要在說明中引用特定上下文（例如文件或 URL），可以使用 Markdown 連結。

今天我們針對的就是第 1 點和第 2 點操作。

先講注意事項：
1. instructions 不是越多越好，請建立分類放好，不同工作區引用適合的 instructions 檔案。
2. 善用 applyTo 和 description 屬性，如果你不知道是啥，請參考這裡。
3. instructions 需要定期維護，自己更板不知道幾次了，這也是需要統一管理的好理由。
4. 指定路徑我是設定為絕對路徑，但這不利於同步使用者設定，所以如果你有多台電腦就要個別處理或想辦法整包同步的。
5. 我測試過在 .vscode/settings.json 裡面設定，沒理我。可能是因為 .code-workspace 放在別的路徑的關係。
好，操作開始：

首先，有一個從個人設定檔著手的方式，這目的是把他寫在個人設定之中。

請搜尋「chat.instructionsFilesLocations」設定，於「使用者」的 tab 中，把路徑複製打上去即可。

如果你不想讓整個使用者都用同樣的指南，畢竟有時要跑不同語言、不同專案，光是 README 就會用到不同屬性或樣板的指引。可以把設定改到「工作區」的 tab 中，分不同工作區當作不同專案使用即可。

除了這個設定之外，也有其他設定可以參考這裡。

另外有一個 .github/copilot-instructions.md 文件，他可以透過 vscode 自動解析專案生成（介紹），如果用 copilot 操作 AI Agent 時，強烈推薦可以先生成一個跑 agent 會稍微比較聰明一些。分類上我認為這個檔案會比較像是 for 專案用途，不太需要共用，建議可以建立工作區之後建立一個 .github 資料夾把他放進去。

如果不想要和目前 git 版控牽扯的話，建議可以把 repo 放到一個資料夾中，再外面資料夾把 .github/copilot-instructions.md 建好（甚至 .vscode 設定也行），要注意的是會有覆蓋的問題，我理解的是原則上覆蓋都會是由最近的資料夾設定優先，可以想像是 js 中 closest 方法的操作邏輯。結構大概會長這樣，這是目前 git-auto-push 這個自動化工具的專案目錄：

執行更新 README 指令會得到以下參考。參考的規範指南部分是我的另外一個 repo 內容。

紅色是把檔案路經遮起來，提醒一下檔案路徑儘量還是不要暴露出來比較保險。如果有看到也互相提醒一下比較好，資訊安全人人有責。

最後提醒一下，如果使用 sepc-kit 或 krio 作 SDD 的朋友，可能外層蓋一個資料夾的方式就不太可行，意味著 spec-kit 產生的 sh 或 py 檔案等要避開 git 版控又不動到 .gitignore 設定的機會滿小的，我個人目前偏向自己作一個 SDD 的工作流或是改現成的 SDD 陣法，畢竟魔法就是探索的過程中才有趣（中二），之後有遇到再說。
2025-11-01
《遊戲化實戰全書》心得筆記
先說這是一篇用 AI 產生的文。

主要是看了《遊戲化實戰全書：遊戲化大師教你把工作、教學、健身、行銷、產品設計……變遊戲，愈好玩就愈有吸引力！》這本書但是不知道怎麼寫心得，於是想試試看 NotebookLM 來處理。

以下心得與摘要：
1. 可以當作心經之類的內功心法，時不時回來看一下。
2. 應該要轉換成自己的語言：
  - 白帽和黑帽：可以理解為拉力（引誘）和推力（驅趕）
  - 左腦（外在）與右腦（內在）：可以理解為交換價值和體驗價值
3. 八個核心驅動力可以背起來。到時要應用也許能當作 check list 來用
  - 也要避免流於表面使用，這應該是最容易犯的錯誤。
4. 需要不斷的應用才能越做越通透理解。
5. 下面的文內摘要：
  - 人性化設計：真正的遊戲化不是積分、徽章或排行榜，而是圍繞人類內在動機的「人性化設計」，否則只會製造短暫表面刺激。
  - 白帽與黑帽動機：白帽驅動帶來使命感、成就與創造力，但缺乏急迫性；黑帽驅動（稀缺性、不確定性、損失恐懼）能激發短期行動卻令人疲憊。
  - 獎勵陷阱：外在獎勵（左腦驅動）容易削弱原本的內在熱情（右腦驅動），造成「過度辯證效應」。真正持久的動機往往來自活動本身的樂趣與意義。
  - 真實案例：遊戲化設計在巴西銀行與台灣統一發票中，分別帶來利潤提升與稅收激增。關鍵不在於獎品，而是激發不確定性、社交互動與成就感。
  - 人生即 RPG：把人生當作角色扮演遊戲，主動迎接挑戰、累積經驗與升級，讓內在動機（使命、成長、創造力）成為驅動力量。
  - 結論：遊戲化是一套理解人性驅動的框架，我們每天都在其中。問題是：你究竟在玩遊戲，還是被遊戲玩弄？
正文如下

戒掉一款遊戲，如何意外解鎖驅動15億人的動機奧秘

簡介：電子遊戲與現實世界動機的驚人連結

你是否曾想過，為什麼電子遊戲比工作、學習，甚至日常瑣事更能吸引我們？為什麼我們願意投入數千小時在《暗黑破壞神II》這樣的遊戲中，追求那些一旦關機就煙消雲散的虛擬成就，結束後卻只感到一陣空虛？

2003年，世界知名的遊戲化專家周郁凱（Yu-kai Chou）在戒掉《暗黑破壞神II》後，也感受到了同樣的空虛。但這種空虛感卻引發了他一生中最重要的頓悟：如果人生本身，也能像一場遊戲一樣玩呢？這個洞見徹底改變了他，從一位重度遊戲玩家，轉變為一位影響全球的先驅，為Google、特斯拉（Tesla）、Uber等頂尖企業提供諮詢。

本文將為你提煉周郁凱思想中五個最令人驚訝且影響深遠的觀點，揭示那些讓遊戲令人上癮的設計原則，如何能被用來讓我們的工作、學習和生活變得更加投入且充滿意義。

觀點一：真正的遊戲化不是積分或徽章——而是「人性化設計」

首先必須澄清，大多數人都誤解了「遊戲化」。它並非簡單地在無聊的任務上添加積分（Points）、徽章（Badges）和排行榜（Leaderboards），也就是所謂的PBL系統。

周郁凱的核心概念是「人性化設計」（Human-Focused Design），這種設計優先考慮人類的動機與感受，與只追求效率的「功能取向設計」（Function-Focused Design）形成鮮明對比。遊戲化的目標不是為任務套上一個「遊戲外殼」，而是要深入挖掘那些讓活動本身變得有回報的內在核心驅動力。

從某個遊戲變得不好玩的那⼀刻，玩家會離開遊戲去玩別的遊戲，或者去找別的事情來做。遊戲設計師必須花費數⼗年光陰，學會如何將玩家留在重複性活動循環之中，為了「沒有⽬的」的⽬標努⼒。

這是一個至關重要的區別。僅僅將表面的遊戲元素應用到一個設計糟糕的體驗上，就像在一輛拋錨的汽車上貼上賽車條紋一樣——它根本無法解決缺乏動力的根本問題。

觀點二：動機存在「黑暗面」，而且你每天都在體驗

周郁凱的「八角框架」（Octalysis Framework）中，一個極具洞察力的概念是「白帽」與「黑帽」核心驅動力的劃分。
- 白帽驅動力：這些是正向的激勵因子，如「重大使命感」、「發展與成就感」和「賦予創造力」。它們讓我們感覺良好、充滿力量且握有主導權。然而，它們缺乏急迫性。例如，為維基百科貢獻內容讓人覺得有意義，但你可以任何時候再做。
- 黑帽驅動力：這些是負向的激勵因子，如「稀缺性」、「不確定性」和「損失與避免」。它們能創造急迫感、痴迷，甚至上癮，但長期下來會讓我們感到被操控且不舒服。例如，「限時優惠」或訂房網站上顯示的「只剩最後1間房！」都屬於此類。
以Zynga的《開心農場》（Farmville）為例，它大量依賴黑帽機制來驅動玩家，雖然在短期內獲得了巨大的用戶參與度，但最終導致了用戶的普遍倦怠，因為玩家感覺自己被困住了，而不是被賦予了力量。

這個框架讓我們有了共通的語言，去理解為什麼某些活動（如滑社交媒體）讓人覺得無法自拔卻又空虛（黑帽驅動），而其他活動（如學習一項新技能）雖然感覺很好，卻總是一再拖延（白帽驅動）。

觀點三：獎勵陷阱——給予獎勵有時反而會扼殺動機

另一個反直覺的觀點，是關於「左腦」與「右腦」核心驅動力的區別。
- 左腦（外在）驅動力：由目標或獎勵驅動的動機。一旦獎勵到手，動機往往隨之消失。薪水和獎金就是典型的例子。
- 右腦（內在）驅動力：活動本身就是獎勵。例如創造、社交和好奇心。從事這些活動時，你不需要任何獎品來激勵自己。
這裡存在一個令人意外的心理學陷阱：當你為某人已經樂在其中的事情提供獎勵時，你可能無意中讓他感覺自己只是為了獎勵而做，從而扼殺了他最初的熱情。這個現象在心理學上稱為「過度辯證效應」（overjustification effect）。為一個本身就很有趣的內在（右腦）活動提供外在（左腦）獎勵，反而可能降低人們對這項活動的長期興趣。

周郁凱曾在他的工作坊中分享一個故事：他對比了兩種獎勵方式，一種是給予回答問題的學員一個「憤怒鳥娃娃」（外在獎品），另一種則是給予他們更多「磁鐵飛鏢」，讓他們在課程結束後能多玩幾次遊戲（內在獎品）。他觀察到，一位從不參與活動的史丹佛外科醫生，為了獲得更多玩遊戲的機會而變得極度投入。這有力地證明了內在動機的強大力量，即使獎勵本身只是一個「玩」的機會。

觀點四：真實世界的成果驚人

當遊戲化原則被正確應用時，其產生的效果是驚人的。以下是兩個來自真實世界的震撼案例：
- 價值十億美元的銀行：巴西一家銀行（周郁凱的學生所服務）將其遍布 4,500個據點 的八萬四千名員工的工作KPI遊戲化，設計成一套集換式卡牌遊戲。員工完成業績目標就能隨機獲得卡片，集滿一套即可兌換獎品。結果令人難以置信：在九個月內，該銀行的利潤增加了48%，相當於10.6億美元，使其從全國第二大銀行躍升為第一大。
- 提升近80%的稅收：台灣政府為了解決商家逃漏稅問題，想出了一個絕妙的辦法。他們將所有統一發票變成彩券，大大激勵了消費者向商家索取發票的意願。這個簡單的改變帶來了巨大的影響：隔年全國稅收增加了將近80%。
這些案例之所以成功，不僅僅是因為提供了獎勵。它們觸及了更強大的核心驅動力，例如不確定性（樂透）、社交影響力（交換卡牌）和成就感（集滿整套卡牌）。

最令人驚訝的是巴西銀行的後續觀察：有些員工在集滿卡片、兌換到價值200美元的無人機等實體獎品後，竟然主動要求退還獎品，只為了換回他們辛苦收集的卡片。為什麼？因為對他們而言，與同事交換卡牌、互相幫助的過程（右腦內在動機），比獲得獎品本身（左腦外在動機）更加快樂。這完美印證了「獎勵陷阱」的觀點——真正的動機，往往來自於體驗本身，而非最終的獎賞。

觀點五：你的人生就是終極的角色扮演遊戲（RPG）

讓我們回到周郁凱最初的頓悟：將自己的人生視為一場角色扮演遊戲（RPG）。如果自己是遊戲的主角，那麼他就不應該只是待在城鎮裡閒晃，而應該要出城去「打怪」、「累積經驗值」和「升級」。

這個比喻可以被轉化為實際的行動：「打怪」意味著去迎接挑戰；「累積經驗值」就是學習新技能或開創事業；而「升級」則是實現個人與職業的成長。

這種心態的核心，是主動為自己的人生進行設計，圍繞著使命感、成長和創造力等白帽、右腦（內在）的激勵因子，而不是被動地被黑帽、左腦（外在）的壓力所驅使。

結論：你正在玩，還是被玩弄？

遊戲化並非曇花一現的噱頭，而是一套深刻理解人類行為驅動力的框架。從我們手機上的應用程式到我們的工作環境，這些原則早已無所不在地運作著。

你早已是數十場遊戲的玩家，無論你是否知曉。唯一剩下的問題是：究竟是你在玩，還是你被玩弄？
2025-09-27
《喜劇的邏輯課：現場喜劇教父的脫口秀心法》心得筆記
先說這是一篇用 AI 產生的文。

主要是看了《喜劇的邏輯課：現場喜劇教父的脫口秀心法》這本書但是不知道怎麼寫心得，於是想試試看 NotebookLM 來處理。

以下重點摘要：
1. 喜劇的核心來自負面情緒，也就是悲傷、痛苦與尷尬；功能是直面痛苦並將之轉化為釋放。
2. 「無厘頭」也依賴嚴謹邏輯；先以 Setup（鋪梗）建立預期，再用 Punch（爆點）顛覆預期，沒有鋪梗就沒有有效笑點。
3. 脫口秀本質是販賣偏見；以個人偏執放大日常矛盾，結合舞台人格與集體情緒產生共鳴。
4. 好笑話同時說兩個相反故事；Setup 的假故事負責誤導，Punch 的真心負責揭露，關鍵在於對同一句話的重新詮釋。
5. 喜劇需要安全距離；距離包含時間與空間，距離不足容易成為冒犯，拿捏得宜才構成有效的地獄梗。
提要公式：笑點強度＝鋪陳品質 × 反差幅度 × 安全距離。

9/27 語音摘要首播影片：https://youtu.be/GPNMaAf7W0I

正文如下

搞笑的殘酷心法：關於喜劇，你可能一直都想錯的五個驚人真相

從社群媒體上的搞笑短片、迷因圖，到 Netflix 上的脫口秀專場，喜劇無疑是我們這個時代最受歡迎的娛樂形式。我們熱愛歡笑，渴望透過幽默來釋放日常生活的壓力。但你有沒有想過：究竟是什麼讓我們發笑？我們直覺地認為，笑聲來自於快樂、輕鬆與陽光，然而，喜劇背後的運作原理，可能比我們想像的更為深刻、精準，甚至……更為殘酷。

本文將揭示五個關於喜劇的驚人發現，這些觀點將徹底顛覆你對「搞笑」這門藝術的認知。準備好了嗎？讓我們一起潛入笑聲的深淵，探索那些隱藏在幽默背後的殘酷心法。

一、幽默的秘密源頭不是喜悅，而是悲傷

這個觀點或許與你的直覺完全相反：喜劇的核心動力，並非源自正面的喜悅或快樂，而是來自負面的情緒，也就是悲傷、痛苦與尷尬。正如美國文豪馬克・吐溫所言：「幽默的秘密源頭不是喜悅，而是悲傷，所以天堂裡是沒有幽默這回事的。」

這個概念解釋了為何能讓我們「大笑」而非僅僅「微笑」的，往往是那些帶有負面元素的情境。想想卓別林（Charlie Chaplin）電影中經典的流浪漢原型：那不是一個單純滑稽的小丑，而是一個在悲劇中展現人性光輝的縮影。在一個故事裡，這個流浪漢在失業與飢餓中好不容易湊錢買下一個麵包，正準備含淚咬下第一口時，卻撞見一個比他更可怜的小乞丐和一位賣花的盲女。於是，他將那份維繫生命的唯一希望，毅然決然地分成三份。這份在共同的悲慘境遇中迸發出的人性光輝，正是卓別林式悲喜劇的力量核心，它讓深陷經濟大蕭條的觀眾在角色的苦難中找到壓力的昇華與共鳴。

另一個更直白的例子：一個可愛的小孩在草地上奔跑，這畫面會讓你露出溫暖的「微笑」。但如果他突然一個踉蹌，一頭栽進旁邊的狗屎堆裡，你很可能會忍不住「大笑」出聲。為什麼？因為正面的事物帶來的是溫馨，而真正觸發爆笑的關鍵，卻是尷尬、丟臉、痛苦等負面元素。

理解這一點至關重要，因為它揭示了喜劇的真正力量：它不是逃避痛苦，而是直面痛苦，並將其轉化為一種釋放與療癒的能量。

二、看似「無厘頭」的搞笑，其實建立在超嚴謹的邏輯上

我們常用「無厘頭」來形容周星馳式的搞笑，認為它就是天馬行空、毫無邏輯的胡鬧。然而，一個顛覆性的真相是：「Logic is the soul of all comedy」（邏輯是所有喜劇的靈魂）。任何成功的搞笑，背後都有一套極其嚴謹的邏輯結構在支撐。

這個核心結構由兩個部分組成：Setup（鋪梗）與 Punch（爆點）。
- Setup（鋪梗）：建立一個符合常規邏輯的情境或角色設定，也就是「邏輯地基」。它的作用是引導觀眾進入一個預設的軌道，讓他們產生期待。
- Punch（爆點）：在觀眾毫無防備時，給出一個意想不到、甚至顛覆前面鋪陳的結果，製造出巨大的反差與荒謬感。
讓我們以周星馳的經典電影為例。在《喜劇之王》中，張柏芝飾演的酒店小姐柳飄飄，其「職業病」（用雙腿夾住男人）是貫穿全片的核心笑點。這個 Punch 之所以好笑，正是因為前面有嚴謹的 Setup：她的角色從一開始就被設定為一個俗艷、難改惡習的酒女。這個「邏輯地基」的精妙之處在於其反覆運用。當柳飄飄看似真情流露，溫柔地靠在尹天仇肩上時，觀眾被引入了一個感人至深的時刻，但鏡頭一拉開，她的雙腿再次騰空夾住對方。這個重複的 Punch，不僅強化了她的角色悲劇——無法擺脫的職業烙印，更徹底粉碎了觀眾唯一的溫情期待，將悲喜劇的反差推向極致。如果沒有這些鋪陳，單純的夾腿動作只會讓人感到困惑。

同樣，在《少林足球》中，貪吃的六師弟肥仔聰會去激吻滿嘴蛋汁的三師兄田雞，也是因為電影早已鋪陳好「肥仔聰對雞蛋有瘋狂熱愛」以及「田雞是個斯文的受害者」這兩個設定。

這些看似荒謬的橋段，絕非隨意的胡鬧，而是基於精密的邏輯計算。沒有成功的 Setup，Punch 就只是讓人摸不著頭緒的噪音。

三、脫口秀是一門「販賣偏見」的藝術

脫口秀演員站在台上，看似只是在分享個人生活，但其核心其實是在「販賣」一種極具個人色彩的東西——偏見。一個優秀的喜劇創作者，通常都帶有某種程度的「偏執」特質，他們善於從常人習以為常的事物中挖掘出「問題」，並將其放大。

正如書中所言：「脫口秀是一門偏見的藝術。」演員們將自己對世界的獨特觀察、不滿與質疑，轉化為一個個笑話。

美國喜劇大師戴夫・查普爾（Dave Chappelle）便是一位將個人偏執與舞台人格發揮到極致的藝術家。他的偏執之一，就是對抽菸的堅持。無論法規如何，他總要在台上點起一根菸，這不僅是個人習慣，更是他「無極限」舞台人格的宣示。這種人格設定，正是他經典段子《被劫持的公車》的完美引信。

段子的起點是一個極具張力的社會矛盾：查普爾在公車上抽菸（小惡），被正義魔人斥責；與此同時，車上另一名男子公然自慰（大惡），卻無人聞問。這種偽善的景象觸發了他的偏執，於是他將大眾對持槍劫案的恐懼，與眼前荒謬的自慰場景結合，創造出一個史無前例的「尻槍劫持」概念。這個段子之所以石破天驚，正在於查普爾巧妙地將他挑釁權威的舞台人格、對社會偽善的尖銳偏見，與觀眾的集體恐懼連結起來，最終將一個平庸的觀察，昇華為一則荒謬絕倫的傳世經典。

這種充滿偏見的藝術之所以能引發共鳴，是因為我們每個人內心深處，都存在著各式各樣的偏執。當喜劇演員勇敢地將他的偏見公諸於世，並用好笑的方式呈現時，觀眾彷彿找到了情緒的出口，在笑聲中得到釋放。

四、每個好笑話，都同時在說兩個完全相反的故事

一個看似簡單的單句笑話（One-liner），其內部結構卻極為精妙。根據喜劇教師葛瑞格・迪恩（Greg Dean）的理論，每個成功的笑話都在同時講述「兩個完全相反的故事」。

讓我們用黃子華的經典笑話來拆解這個結構：
- Setup：我年輕時很不懂事，看女生都只注重她們的臉蛋。
- Punchline：現在我知道了，原來身材也是很重要的。
這個笑話的巧妙之處在於，Setup 和 Punchline 分別引導觀眾走向兩個截然不同的故事：
- 故事一（由 Setup 建立）：一個懂得反省的正常人。他回顧年輕時的膚淺，暗示自己現在已經成長，更注重內涵。這是一個「假話」，一個用來誤導觀眾上鉤的陷阱。
- 故事二（由 Punchline 揭示）：一個變本加厲、更為膚淺的真實慾望。他非但沒有變得更有深度，反而將膚淺的標準擴展到了身材。這是一個「真話」，其驚人的誠實與故事一的偽善形成了巨大反差，製造了笑點。
這兩個相反的故事，透過一個被重新詮釋的「關鍵點」巧妙地連結起來。在此例中，關鍵點就是「不懂事」這句話。Setup 將「不懂事」框架為道德上的不成熟（只看臉是膚淺的）；而 Punchline 則將其重新詮釋為實踐上的無知（當年太蠢了，竟然不懂得「也」要看身材）。Setup 負責欺騙，而 Punchline 負責揭露殘酷的真心，兩者的猛烈碰撞，正是笑聲爆發的瞬間。

五、喜劇不是悲劇加時間，而是悲劇加「安全距離」

我們常聽到一句名言：「Comedy is tragedy plus time.（喜劇是悲劇加上時間）」這句話有其道理，但一個更精確的說法是：「Comedy is tragedy plus distance.（喜劇是有著安全距離的悲劇）」。

這裡的「距離」包含了時間與空間。當一場悲劇發生時，如果觀眾與事件的距離太近，他們只會感到痛苦、恐懼或同情，而無法發笑。只有當觀眾與悲劇之間存在足夠的「安全距離」，他們才能將痛苦轉化為幽默。

書中一個極具說服力的例子是，一位台灣表演者在美國校園槍擊案發生後不久，便在一個有許多美國觀眾的場合開了相關玩笑。結果，由於觀眾與這場悲劇的「距離」太近，情感上的創傷尚未平復，這個笑話非但沒有引發笑聲，反而讓現場氣氛瞬間凍結。

這個原則是區分「地獄梗」與「純粹冒犯」的關鍵。一個成功的地獄梗，必須精準地拿捏好觀眾與悲劇事件之間的心理距離，既要足夠近以保有刺激感，又要足夠遠以確保安全感。一旦距離失準，幽默就會變成殘忍的二次傷害。

從悲傷的源頭、嚴謹的邏輯，到販賣偏見的藝術、雙重故事的結構，再到對安全距離的精準計算，喜劇顯然是一門比表面看起來更深刻、更殘酷，也更精密的藝術。它不僅僅是為了逗樂，更是一種轉化痛苦、挑戰常規、釋放人性的強大工具。

下次當你為一個笑話捧腹大笑時，不妨停下來想一想：你是否能看見它背後那道由悲傷、邏輯與安全距離共同構築的精妙風景？
2025-09-20
Espanso 是一個「文字展開」工具
Espanso 是一款跨平台 文字展開器 (Text Expander)，可讓你輸入簡短的縮寫，自動替換成完整文字或片段。常用於輸入常見片語、程式碼片段、電子郵件範本，或快速插入日期、動態變數。

設定的部分有兩個詞彙需要了解：
1. replace 目標最終展開的詞彙
2. tigger 輸入這個詞彙將會觸發變更為 replace
先分享幾個個常用的設定：
```
- trigger: "cmd-gkeywords"
    replace: "請給我10個中英文關鍵字，英文逗號分隔。"
```
```
- trigger: "cmd-gsrt"
    replace: "這是一個在台灣看戲的心得聲音檔案，請幫我產生 srt 字幕檔，請使用繁體中文，且使用台灣詞彙用字。中英文請使用空格隔開。在前後 5 句的字幕後面補上「（字幕使用 Gemini Cli 生成）」內容註名。如果需要安裝套件，請幫我安裝。聲音檔案路徑： "
```
其實主要是因為 AI CLI 的工具要打提示詞很麻煩，往往一直重複打，所以我想有一個獨立於 AI 服務的工具，這樣我到哪都可以逍遙自在。於是找到這個 Espanso，有幾點注意：
1. Mac 上有時無法使用，可以看到圖示變成錯誤的狀態（參考），八成是有某個應用程式因為 Secure Input 啟動的關係，建議一個個關掉試試看。
2. Espanso 的設定編輯有些麻煩，但是其實只要確定位置，也可以用 AI CLI 工具來變更產生設定呢ＸＤ
3. 有些 AI CLI 工具上，無法用複製貼上 trigger 的方式，要用打字的比較好生成，所以 trigger 得設定的短又有辨識度。
4. 據悉，可以把設定檔案移動到雲端備份，這樣就可以達到分享與共用的目的。
以下介紹與安裝方法

特色：
- 跨平台：支援 Windows、macOS、Linux。
- YAML 設定檔：以 .yml 檔管理規則。
- 支援動態變數：可插入日期、剪貼簿內容、系統命令輸出等。
Ｍac 安裝方法：

Espanso 也可以透過流行的 macOS 套件管理器Homebrew進行安裝。
```
brew install espanso
```
其他平台安裝參考這裡。

編輯詞彙，請參考這裡：

Espanso 支援使用 CLI 編輯詞彙：
```
espanso edit
```
如果想要找到檔案，查詢設置路徑：
```
espanso path

Config: /Users/XXX/Library/Application Support/espanso
Packages: /Users/XXX/Library/Application Support/espanso/match/packages
Runtime: /Users/XXX/Library/Caches/espanso
```
用 Finder 打開 Config 資料夾，會看到兩個設定檔案的資料夾， match/base.yml 就是詞彙檔案了。

其他編輯請設定，參考這裡。
2025-09-05
受保護的內容: 這應該算是向宇宙下訂單吧？

This content is password-protected. To view it, please enter the password below.

密碼:

LLM 生成參數清單與說明

這是一篇關於 LLM 生成參數的清單/說明，由 ChatGPT 5 Auto 使用搜尋功能整理起來的，為了避免幻覺，將找到的參考網址利用索引編號的方式補上。

先附上同樣內容 Gist 文章，喜歡的可以點星星。

LLM 生成參數清單與說明

目的：快速對齊 OpenAI、Anthropic、Google Gemini、AWS Bedrock 等 API 常用生成參數，提供定義、取值範圍、適用情境與風險備註，便於跨平台設定一致化。

主要生成參數與應用

1) Temperature（溫度） [1][2]

定義：調整機率分布尖銳度以控制隨機性；值越高結果越發散，越低則越保守。
範圍：0.0–1.5（常用 0–1）。
建議：
低（0–0.3）：事實型回答、程式碼、規格文件、翻譯。
中（0.4–0.7）：一般敘事、適度創意。
高（0.8–1.2）：腦力激盪、創意文案、多樣性輸出。
風險：溫度升高會增加幻覺機率與降低一致性。

2) Top‑p（Nucleus Sampling，核採樣） [1][2][3]

定義：從累積機率 ≥ p 的詞集合中抽樣，動態限制候選集大小。
範圍：0.1–0.95。
建議：
低（0.1–0.4）：高精準度與集中度。
高（0.8–0.95）：創意與多樣性。
注意：與 Temperature 同時升高會放大隨機性，通常僅調整其中一項。

3) Top‑k [4][5]

定義：固定從機率最高的 k 個候選中抽樣。
範圍：20–200（依模型與平台而異；Bedrock 常見 0–500）。
適用：需要可控且穩定的生成，特別是批次處理或離線生成。

4) Max Tokens / Max Output Tokens（最大輸出 Token） [1][2][4][5]

定義：限制回應的最大 token 數。
建議：依任務長度設置，避免截斷長文或程式碼。
風險：值過小會截斷，過大則增加成本與跑題風險。

5) Stop / Stop Sequences（停止序列） [1][3][4][5]

定義：遇到指定字串即終止生成。
用途：模板化輸出、只取特定段落、避免越界內容。
注意：不同平台上限不同，常見最多 4 組。

6) Frequency Penalty（頻率懲罰） [1]

定義：降低重複詞出現機率，避免冗詞與重複句。
適用：摘要去重、對話減少重複表述。

7) Presence Penalty（出現懲罰 / 新詞誘導） [1]

定義：對已出現詞施加懲罰，鼓勵新話題與新詞彙。
適用：腦力激盪、多元化內容生成。

8) Candidate Count / n（多候選數） [2]

定義：一次產生多個候選，供後續篩選。
成本：成比例增加 token 消耗與計費。

9) Safety / Moderation（安全設定） [2][3]

定義：控制內容安全過濾的嚴格度與策略。
適用：開放式輸入、公共應用上線前防範不當內容。

10) JSON / Structured Output（結構化輸出） [1][2]

定義：要求輸出為 JSON 或特定結構格式，部分平台支援嚴格模式。
注意：仍可能違反格式，建議搭配 stop 序列與 schema 驗證。

主要供應商參數對照

供應商	溫度	Top‑p	Top‑k	最大輸出	停止序列	懲罰類	安全設定	備註
OpenAI [1]	`temperature`	`top_p`	（無通用）	`max_tokens`	`stop`	`frequency_penalty` / `presence_penalty`	模型內建審核 + Moderation API	Chat Completions / Responses / Realtime
Anthropic Claude [3]	`temperature`	（依通道）	（依平台）	`max_tokens`	`stop_sequences`	（無傳統兩懲罰）	平台側安全	`stop_reason` 報告終止原因
Google Gemini [2][6]	`temperature`	`topP`	`topK`	`maxOutputTokens`	`stopSequences`	（無傳統兩懲罰）	`safetySettings`	SDK 預設 Token 與安全策略
AWS Bedrock [4][5][7]	`temperature`	`topP`	`topK`	`maxTokens`	`stopSequences`	（依模型）	（依模型）	值域與預設視模型而定

註：實際參數與範圍以官方文件為準。

快速設定策略

嚴謹回覆：temperature=0–0.2，top_p=0.2–0.5，設定 stop 與足夠 max_tokens。
創意寫作：temperature=0.8–1.0，top_p=0.8–0.95；可搭配 presence_penalty。
程式碼 / SQL：temperature=0–0.3，top_p≤0.5；增加 max_tokens 避免截斷。
批次多樣化：提高 temperature 或使用 top_k，並啟用多候選 n。

範例設定

OpenAI（Responses API）

{
  "model": "gpt-4.1-mini",
  "input": "Summarize the following text...",
  "temperature": 0.3,
  "top_p": 0.6,
  "max_tokens": 400,
  "stop": ["\n\n"],
  "frequency_penalty": 0.2,
  "presence_penalty": 0.1
}

Anthropic Claude（Messages）

{
  "model": "claude-3.7-sonnet",
  "max_tokens": 400,
  "temperature": 0.2,
  "stop_sequences": ["\n\nHuman:"]
}

Google Gemini（GenerateContent）

{
  "model": "gemini-2.5-flash",
  "contents": "...",
  "generationConfig": {
    "temperature": 0.7,
    "topP": 0.9,
    "topK": 40,
    "maxOutputTokens": 512,
    "stopSequences": ["\nEND\n"]
  },
  "safetySettings": { "HATE": "BLOCK_ONLY_HIGH" }
}

AWS Bedrock（Converse 匯總介面）

{
  "modelId": "anthropic.claude-3-7-sonnet",
  "inferenceConfig": {
    "temperature": 0.2,
    "topP": 0.5,
    "topK": 50,
    "maxTokens": 400,
    "stopSequences": ["\n\nHuman:"]
  }
}

實務備註

temperature 與 top_p 同時升高會大幅增加隨機性，建議只調一項。
結構化輸出需：明確 schema → 設定 stop → 程式端驗證 JSON。
成本與延遲受 max_tokens 和候選數影響最大，應先設定上限再微調。
Token 長度定義跨平台略有差異，需預留緩衝。

參考資料

[1] OpenAI API 參考 — https://platform.openai.com/docs/api-reference/introduction
[2] Google Vertex AI / Gemini 參數 — https://cloud.google.com/vertex-ai/generative-ai/docs/multimodal/content-generation-parameters
[3] Anthropic Messages API — https://docs.anthropic.com/en/api/messages
[4] AWS Bedrock Inference 參數 — https://docs.aws.amazon.com/bedrock/latest/userguide/inference-parameters.html
[5] AWS Bedrock API InferenceConfiguration — https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InferenceConfiguration.html
[6] Google Vertex AI GenerationConfig — https://cloud.google.com/vertex-ai/generative-ai/docs/reference/rest/v1/GenerationConfig
[7] AWS Bedrock Converse API — https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_Converse.html

2025-08-15

使用 google 的 Gemini CLI 來製作字幕
這是一個利用 Gemini CLI 來產生字幕的方法教學，用在如果你下載了影片，應該怎麼做才能得到一個有時間軸的字幕檔案。滿足幾個需求：
1. 繁體中文，儘量使用台灣用語。
2. 符合時間軸，或者修改不用太多。
3. 採用 srt 字幕檔案格式，可用於上傳到 Youtube CC 字幕等用途。
首先聲明一下，下載影片屬於重製行為，請確保自己的版權問題。並且使用 Gemini CLI 製作會用到 API ，可能衍生費用，請注意使用費用變化。

什麼是 Gemini CLI 呢？
Gemini CLI 是一個基於命令行的 AI 工作流工具，連接到 Google 的 Gemini 模型，讓您能夠直接從終端進行對話式 AI 互動。

工具系統提供豐富的本地環境互動能力，包括文件系統操作、shell 命令執行、網頁抓取等功能。支持多種安裝方式，可通過 npm 全局安裝或使用 npx 直接執行。

Gemini CLI 不只是撰寫程式的工具（實際上也沒啥人會拿來寫程式），可以看作是用自然語言整合電腦操作系統指令的工具。

接下來我們介紹安裝方法和使用方法。

先給延伸閱讀，包括安裝和使用：
先給注意事項：
1. 以下文件以 MacOS 為主，使用終端機搭配 Finder 。
2. 建議一開始先把影片檔案/音訊檔案放在一個空的資料夾中動作，避免亂掉。
3. 執行命令等待時間可能會有點久，建議放著去喝杯咖啡。
4. 呼叫他執行 Shell 指令以前，請記得指定好資料夾路徑，避免提示詞下錯，變成電腦病毒自己攻擊自己。
5. 如果不想衍生費用，但是又怕不小心扣款的話，建議先登入一個沒有綁信用卡的帳號。
Gemini CL安裝方式

網路上有建議三種方法，我挑我認為推薦的避免文字太長，以 MacOS 為主。首先請先打開終端機 app

如果你是非 Mac 用戶，或是你想透過 npm 安裝

前置需求： 確保您已安裝 Node.js 20 版本或更高版本。

全域安裝：
```
   npm install -g @google/gemini-cli
```
然後可以在任何地方執行：
```
   gemini
```
如果你是 Mac 用戶，請使用 Homebrew

前置需求： 確保您已安裝 Homebrew。

安裝步驟：
```
brew install gemini-cli
```
然後可以在任何地方執行：
```
gemini
```
初始設定

安裝完成後，您需要進行以下設定：
1. 選擇顏色主題
2. 身份驗證： 使用您的個人 Google 帳戶登入，這將為您提供每分鐘最多 60 次模型請求和每天 1,000 次模型請求的免費額度（最新資訊請參考官網）
安裝完成以後，建議輸入 Gemini API 金鑰

使用 Gemini API 金鑰

如果您需要更高的使用限制，可以使用 Gemini API 金鑰：
1. 從 Google AI Studio 生成金鑰
2. 設定環境變數：
```
   export GEMINI_API_KEY="YOUR_API_KEY"
```
驗證安裝

您可以使用以下命令驗證安裝是否成功：
```
gemini --version
```
接下來使用上以 MacOS 為主。使用 cd 指令，進入放影片的資料夾。先打好 cd+空格，再把把資料夾拖曳到到終端機中即可自動補上路徑。大概像這樣：
```
cd /xxx/xxx/xxx/xxx/未命名檔案夾
```
請準備一個音訊檔案，如果是影片的話，有兩個方法可以轉成音訊：
1. 透過其他工具將影片音訊提取出來，例如這個。
2. 透過 Gemini CLI 將影片轉成音訊
使用 Gemini CLI 的提示詞如下：
```
 請幫我把影片轉成mp3 音訊檔案 @/路徑/影片檔案.mov 
```
在 @ 後面是檔案路徑，不用自己打，把檔案拖曳終端機內即可。

接下來他會下載/調用轉字幕工具 ffmpeg 操握，從截圖可以看到他詢問是否安裝，選擇第一個或第二個選項都可以。使用鍵盤上下選擇，Enter 送出。

就會得到「轉換成功！檔案已儲存為 xxxx」的訊息，打開資料夾就會看到對應的 mp3 檔案，也就是等會準備要利用的音訊檔案！

如果已經有了音訊檔案之後，在同一個 Gemini CLI 視窗之中，輸入以下提示詞並且帶入音訊檔案路徑，如下：
```
這是一個在 oooo 的聲音檔案，請幫我產生 srt 字幕檔，請使用繁體中文，且使用台灣詞彙用字。中英文請使用空格隔開。聲音檔案路徑 @xxx/xxx/xx.mp3
```
同樣的檔案路徑可以使用拖曳的方式帶入；有一個「 oooo 的聲音檔案」可以選擇不填寫，但是如果是專門的領域的話，建議將目的用途描述一下，讓文字使用可以針對該領域作最佳化調整。

同樣的，系統會選擇使用 whisper 工具搭配 AI 運作，相同也會詢問 Allow execution? 選擇允許以後繼續動作。這時依照檔案長度和電腦規格，可能會需要等久一些。

好了之後回頭看資料夾就有啦～
2025-08-10

作者: Jerry Lin

1. 驚喜的跨平台開放標準：AI 界的「通用語言」

2. 為你的 Context Window 減壓：高效的「漸進式揭露」

3. 最關鍵的一行程式碼：description 欄位是你的魔法棒

4. 各司其職：何時用 Skills，何時用自訂指令？

5. 層層疊加的專業知識：強大的範圍與優先級系統

結論

Claude Code YAML 欄位定義

其他 AI 工具的欄位差異與額外欄位

共通的核心機制

VS Code (GitHub Copilot) 的 YAML 欄位

Claude Code 的進階 YAML 欄位

核心差異總結

1. 你的準備不是一個背包，而是一個系統 (Your Prep Isn’t a Bag, It’s a System)

2. 現代危機中，最大的斷點是「電」和「網路」 (In a Modern Crisis, the Biggest Failures are ‘Power’ and ‘Internet’)

3. 真正的戰場也在你的手機裡 (The Real Battlefield is Also in Your Phone)

4. 急救不只是等救護車 (First Aid Isn’t Just Waiting for the Ambulance)

5. 心理韌性和社區連結是你的終極裝備 (Mental Resilience and Community Ties are Your Ultimate Gear)

Conclusion: Preparedness Is a Mindset, Not a Checklist

簡介

1. 核心架構演進：AI Agent 整合與管理 (Agent HQ)

1.1 Agent HQ 核心功能解析：Agent Sessions view

1.2 新增 Agent 類型與工作流程：Plan Agent

1.3 跨環境 Agent 整合

1.4 術語統一與自訂 Agent 增強

2. 編輯器核心開源與開發體驗優化

2.1 「行內建議」功能開源與擴充套件合併

2.2 差異比較 (Diff) 與程式碼導航功能強化

3. 終端機 (Terminal) 與 Chat 工具鏈深度整合

3.1 Terminal IntelliSense 正式發布

3.2 終端機工具 (Terminal Tool) 剖析

3.3 Chat 與終端機的雙向互動

4. 平台擴充性與 API 更新

4.1 MCP (Model Context Protocol) 企業級支援與驗證更新

4.2 擴充套件作者 API 更新

4.3 提案中 API (Proposed APIs) 預覽

5. 工程實踐與重要修復

5.1 內部工程流程改進：自動化 UX 測試

5.2 平台支援變更與關鍵問題修復

戒掉一款遊戲，如何意外解鎖驅動15億人的動機奧秘

簡介：電子遊戲與現實世界動機的驚人連結

觀點一：真正的遊戲化不是積分或徽章——而是「人性化設計」

觀點二：動機存在「黑暗面」，而且你每天都在體驗

觀點三：獎勵陷阱——給予獎勵有時反而會扼殺動機

觀點四：真實世界的成果驚人

觀點五：你的人生就是終極的角色扮演遊戲（RPG）

結論：你正在玩，還是被玩弄？

搞笑的殘酷心法：關於喜劇，你可能一直都想錯的五個驚人真相

一、幽默的秘密源頭不是喜悅，而是悲傷

二、看似「無厘頭」的搞笑，其實建立在超嚴謹的邏輯上

三、脫口秀是一門「販賣偏見」的藝術

四、每個好笑話，都同時在說兩個完全相反的故事

五、喜劇不是悲劇加時間，而是悲劇加「安全距離」

LLM 生成參數清單與說明

主要生成參數與應用

1) Temperature（溫度） [1][2]

2) Top‑p（Nucleus Sampling，核採樣） [1][2][3]

3) Top‑k [4][5]

4) Max Tokens / Max Output Tokens（最大輸出 Token） [1][2][4][5]

5) Stop / Stop Sequences（停止序列） [1][3][4][5]

6) Frequency Penalty（頻率懲罰） [1]

7) Presence Penalty（出現懲罰 / 新詞誘導） [1]

8) Candidate Count / n（多候選數） [2]

9) Safety / Moderation（安全設定） [2][3]

10) JSON / Structured Output（結構化輸出） [1][2]

主要供應商參數對照

快速設定策略

範例設定

實務備註

參考資料

Gemini CL安裝方式

如果你是非 Mac 用戶，或是你想透過 npm 安裝

如果你是 Mac 用戶，請使用 Homebrew

初始設定

安裝完成以後，建議輸入 Gemini API 金鑰

使用 Gemini API 金鑰

驗證安裝

3. 最關鍵的一行程式碼：`description` 欄位是你的魔法棒