Skills on KnightLi的博客

市面上主流 AI PPT 工具大盤點：自動生成、網頁簡報、PPTX 和圖像路線怎麼選

Mon, 18 May 2026 22:29:43 +0800

AI 做 PPT 已經不只是「輸入標題，套一個模板」。在 Claude Code、Codex、Cursor 這類 AI 編程環境裡，PPT 生成正在變成一組可安裝、可複用的 Agent Skill：有的輸出網頁簡報，有的生成真正可編輯的 .pptx，有的直接用圖像模型把每頁做成視覺稿，還有的透過 MCP 讓 AI 操作 PowerPoint 文件。

這次整理了一批主流 PPT 相關 Skill。真正有價值的地方不只是榜單，而是把這類工具按交付形態拆開來看。選工具前，先問一句：最終交付物到底要給誰改、在哪裡播放、是否需要繼續協作？

幾條路線

1. HTML 網頁簡報

代表項目包括 frontend-slides、guizang-ppt-skill、html-ppt-skill。

這條路線的優勢是視覺表現力強。CSS 動畫、Canvas、WebGL、響應式佈局都能用，瀏覽器打開即可展示，適合技術分享、產品發布、Demo Day 和個人風格強烈的演講。

代價也很明確：交付後不太適合讓客戶逐字改。客戶如果拿到的是 HTML，而不是 PowerPoint 文件，後續修改往往還要回到生成流程。

如果只看 HTML 簡報，frontend-slides 更像高星通用入口，guizang-ppt-skill 強在審美約束和主題風格，html-ppt-skill 則勝在主題數量、佈局數量和演講者模式。

2. 原生 PPTX

代表項目包括 mckinsey-pptx、ppt-agent-skills、claude-office-skills 和 ppt-master。

這是商業交付最穩的路線。只要客戶要求「能在 PowerPoint 裡改字、改圖、套公司模板」，最終就要落到 .pptx。

其中 ppt-master 很值得單獨關注。它的思路是先讓 LLM 生成 SVG，再轉成 PowerPoint 原生 DrawingML 物件，目標是讓文字框、形狀、圖表都能在 PPTX 裡繼續編輯。它還支援從 PDF、DOCX、URL、Markdown 生成 PPTX，並能做模板復刻、動畫、旁白和本地預覽。

這條路線適合諮詢交付、公司匯報、白皮書簡報、長報告壓縮成 PPT 等場景。缺點是視覺上限通常受 PowerPoint 本身限制，複雜效果不如 HTML 或圖像路線自由。

3. AI 圖像驅動

代表項目包括 NanoBanana-PPT-Skills、gpt_image_2_skill 和 ppt-image-first。

這條路線先把每一頁當成視覺圖來生成，再把圖片放進 PPTX 或其它容器裡。優點是完成度高，尤其適合封面、社群媒體圖、視覺提案、傳播型內容。

問題是可編輯性差。頁面本質上是一張圖，後面要改一個標題、換一段文案、挪一個圖標，可能就要重新生成。它適合「看起來要好」，不適合「客戶要反覆改」。

4. MCP / 協議層

代表項目包括 Office-PowerPoint-MCP-Server、PPTAgent。

這類工具不一定直接生成完整 PPT，而是給 AI 一個操作 PowerPoint 的介面。接入 MCP 後，模型可以讀、改、寫 .pptx 文件。

這條路線適合已經有 PPT 文件、需要 AI 輔助修改的工作流。比如批量改格式、根據回饋重排頁面、讓模型檢查每頁是否符合目標。PPTAgent 強調反思式生成，也就是每生成一頁後再回頭檢查，這個方向對減少「AI PPT 很粗糙」的問題有啟發。

5. 綜合設計平台

代表項目包括 open-design 和 docsagent。

這類項目已經超出 PPT 生成本身。open-design 更像本地優先的設計平台，可以生成原型、slides、images、videos，並支援多種匯出格式。docsagent 不是 PPT 工具，但能索引和對話本地文件，適合作為 PPT 生成前的資料整理層。

如果你的需求不是單次做 PPT，而是從資料、設計、原型到交付的一整套流程，這類平台更值得看。

Skill 元資訊

Star 數來自原文 2026-05-15 的抓取結果，只適合作為熱度參考，實際使用前建議再打開倉庫確認維護狀態、README 和 LICENSE。

Skill	作者	連結地址	Star	語言	路線
frontend-slides	@zarazhangrui	GitHub: zarazhangrui/frontend-slides	17,530	Shell	HTML 網頁簡報
guizang-ppt-skill	@op7418（歸藏）	站內文章: guizang-ppt-skill GitHub: op7418/guizang-ppt-skill	8,832	HTML	HTML 網頁簡報
html-ppt-skill	@lewislulu	GitHub: lewislulu/html-ppt-skill	3,834	HTML/CSS/JS	HTML 網頁簡報
mckinsey-pptx	@seulee26	GitHub: seulee26/mckinsey-pptx	426	Python	原生 PPTX
ppt-agent-skills	@sunbigfly	GitHub: sunbigfly/ppt-agent-skills	714	Python	原生 PPTX
claude-office-skills	@tfriedel	GitHub: tfriedel/claude-office-skills	631	Python	原生 PPTX
ppt-master	@hugohe3	GitHub: hugohe3/ppt-master	16,626	Python	原生 PPTX
NanoBanana-PPT-Skills	@op7418（歸藏）	GitHub: op7418/NanoBanana-PPT-Skills	2,668	Python	AI 圖像驅動
gpt_image_2_skill	@wuyoscar	GitHub: wuyoscar/gpt_image_2_skill	2,102	Python	AI 圖像驅動
ppt-image-first	@NyxTides	GitHub: NyxTides/ppt-image-first	799	Python	AI 圖像驅動
Office-PowerPoint-MCP-Server	@GongRzhe	GitHub: GongRzhe/Office-PowerPoint-MCP-Server	1,708	Python	MCP / 協議層
PPTAgent	@icip-cas	GitHub: icip-cas/PPTAgent	4,354	Python	MCP / 協議層
open-design	@nexu-io	站內文章: open-design GitHub: nexu-io/open-design	40,822	TypeScript	綜合設計平台
docsagent	@docsagent	GitHub: docsagent/docsagent	687	TypeScript	綜合設計平台

選型可以這樣判斷

如果客戶要繼續編輯，優先看原生 PPTX 路線，尤其是 ppt-master、mckinsey-pptx、ppt-agent-skills。

如果是自己演講，且視覺表現比後續編輯更重要，優先看 HTML 路線，尤其是 frontend-slides、guizang-ppt-skill、html-ppt-skill。

如果目標是海報感、封面感、傳播圖，優先看圖像路線，比如 ppt-image-first、gpt_image_2_skill、NanoBanana-PPT-Skills。

如果已經有 PPT 文件，只想讓 AI 幫你讀、改、重排，可以看 MCP 路線。

如果是學術、行銷、翻譯、長報告壓縮這類明確場景，也可以繼續找垂直 Skill，而不是拿通用 PPT 生成器硬做。

最後要注意的事

開源項目不能只看 Star。真正使用前還要確認三件事：

LICENSE 是否允許你的使用方式。
生成物是否滿足交付要求，尤其是可編輯性。
成本是否可接受，包括模型調用、圖像生成、大上下文模型和可能的雲服務費用。

這類工具變化很快，Star 數會變，項目維護狀態也會變。但選型邏輯相對穩定：先確定交付形態，再看具體工具。PPT 是給人講、給人改、還是給人看，這三個答案往往會把選擇範圍直接縮小一大半。

Claude Code 24 個使用技巧：計劃模式、回滾、CLAUDE.md、Skills、Agents 和插件

Fri, 08 May 2026 08:54:14 +0800

Claude Code 不只是一個聊天框。它更像一個能進入專案目錄、讀寫檔案、執行命令、維護上下文的編程 Agent。

如果只是把需求丟進去讓它生成程式碼，很快會遇到幾個問題：計劃不夠清楚、權限反覆確認、上下文越來越長、生成結果不滿意、不知道怎麼回滾，也不知道怎麼把專案規則長期保存下來。

下面整理一組常用操作，適合剛開始使用 Claude Code 的開發者快速建立工作流。

先在專案目錄啟動

Claude Code 最好在專案目錄裡啟動，而不是隨便打開一個終端就開始用。

可以先建立一個資料夾作為專案目錄，進入目錄後打開命令列，再啟動 Claude Code：

claude

首次進入專案時，如果 Claude Code 詢問是否信任目前資料夾，確認後再繼續。這樣它才能圍繞目前專案讀取檔案、建立檔案和執行後續操作。

一個簡單的練習方式是讓它建立一個攝影師個人網站。這個任務足夠直觀：能看到頁面效果，也能練習檔案生成、命令執行、回滾和後續重構。

計劃模式先把方向想清楚

Claude Code 在面對較複雜任務時會進入計劃模式。計劃模式的作用是先討論需求、拆解步驟，再讓使用者決定是否批准執行。

當它給出計劃後，通常會出現幾類選擇：

批准計劃，並允許後續自動使用編輯工具。
批准計劃，但後續編輯仍然需要手動確認。
暫停執行，繼續和 Claude Code 討論計劃。

如果任務比較明確，可以批准計劃並繼續。如果任務還不清楚，建議先讓它繼續補充方案，比如頁面風格、技術棧、目錄結構、互動效果和驗收標準。

計劃模式的好處是減少返工。直接讓 Agent 動手，可能很快生成一堆檔案；但如果方向錯了，後面越改越亂。

用 Shift + Tab 切換模式

在 Claude Code 中，可以用 Shift + Tab 在不同工作模式之間切換。常見用途是進入計劃模式，或者切換到自動同意編輯工具的模式。

建議的習慣是：

新專案、新功能、大改動：先進入計劃模式。
小改動、明確修復：可以直接執行。
涉及刪除、批量替換、安裝依賴：保持人工確認。

計劃模式下，Claude Code 可能會主動詢問專案細節。可以用方向鍵選擇選項，用回車確認。提交回饋後，它會根據你的選擇更新計劃。

權限確認不要一律放開

Claude Code 執行命令、編輯檔案或啟動程式時，可能會申請權限。

常見選擇包括：

只同意本次使用。
在目前會話中以後都同意同類命令。
拒絕或暫停。

如果只是啟動本地頁面、運行開發伺服器、查看檔案，可以根據需要允許。但不要為了省事長期使用「自動同意所有權限」的啟動方式。

全自動權限適合非常確定、風險很低、專案已經有 Git 備份的場景。日常使用中，涉及刪除檔案、覆蓋目錄、安裝依賴、聯網、提交程式碼、執行腳本時，最好保留人工確認。

用終端模式執行本地命令

Claude Code 裡可以進入終端命令模式，直接執行一些本地命令。

例如頁面生成後，可以用系統命令打開 HTML 檔案：

`1`	`start index.html`

這裡的 start 是 Windows 下打開檔案的命令，後面接檔名。這樣可以快速查看生成頁面，而不用手動去資源管理器裡找檔案。

終端模式適合執行這些輕量操作：

打開生成的頁面。
查看目錄內容。
啟動本地開發伺服器。
運行測試或構建命令。

但高風險命令仍然要謹慎，比如遞歸刪除、移動目錄、批量覆蓋和修改系統環境。

回滾：結果不滿意時及時退回

如果 Claude Code 做出的頁面或程式碼不是你想要的，而且越改越亂，就應該及時回滾。

回滾功能可以把對話或程式碼退回到某個節點。常見選項包括：

同時回滾程式碼和對話。
只回滾對話。
只回滾程式碼。
把某個節點之前的內容壓縮成摘要。
取消操作。

更推薦在明顯走偏時選擇「同時回滾程式碼和對話」。這樣可以讓上下文和檔案狀態一起回到較乾淨的位置。

需要注意：Claude Code 的回滾通常只能覆蓋它透過內建工具建立或修改的檔案。如果檔案是透過外部命令生成的，未必能完整回滾。因此重要專案仍然要配合 Git 使用。

長提示詞用編輯器寫

複雜需求不要全擠在一行輸入框裡。

如果系統支援在文字編輯器中編輯長提示詞，可以打開編輯器，把需求寫完整後保存，再發送給 Claude Code。

長提示詞裡建議寫清楚：

目標是什麼。
使用什麼技術棧。
不要做什麼。
需要保留哪些檔案。
完成後如何驗證。
頁面或功能的驗收標準。

例如讓 Claude Code 把一個普通 HTML 頁面重構成更現代的技術棧時，不要只寫「重構一下」。可以說明希望使用元件化結構、保留視覺內容、增加響應式布局，並要求它運行構建檢查。

退出後用歷史恢復會話

如果中途需要退出 Claude Code，可以正常退出。之後回到同一個專案目錄，再次啟動：

claude

如果發現前面的記錄沒有直接顯示，可以使用歷史相關命令查看最近會話，並載入之前的會話。

這個功能適合中斷後繼續工作。不過不要把會話歷史當成唯一記憶。專案規則、技術棧、常用命令和注意事項，最好寫進專案檔案裡。

用 CLAUDE.md 保存專案規則

CLAUDE.md 是 Claude Code 很重要的記憶檔案。它通常放在專案根目錄，用來告訴 Claude Code 專案規則、技術棧、目錄結構和協作約束。

可以讓 Claude Code 初始化這個檔案：

/init

CLAUDE.md 適合記錄：

專案目標。
技術棧。
常用啟動、測試、構建命令。
目錄說明。
程式碼風格。
不允許執行的操作。
提交和部署規則。

每次對話時，Claude Code 會把這類規則作為上下文的一部分使用。你可以把它理解成「專案說明書」。

一個簡單驗證方式是：在 CLAUDE.md 裡加入一條明顯規則，然後再向 Claude Code 提問。如果回答遵循了這條規則，就說明它確實讀到了專案記憶。

用 @ 引用檔案

在輸入框中使用 @，可以選擇檔案或 Agent，把指定內容加入目前對話上下文。

這適合幾類場景：

讓 Claude Code 閱讀某個配置檔案。
讓它修改某個指定頁面。
讓它根據 CLAUDE.md 或其他文件繼續工作。
明確告訴它「只看這個檔案，不要猜專案結構」。

相比把檔案內容複製到輸入框裡，@ 引用更清楚，也更不容易漏內容。

查看和壓縮上下文

長時間對話後，上下文會越來越大。上下文太長時，模型可能變慢，也可能開始忽略早期細節。

可以使用上下文查看命令了解目前占用情況：

`1`	`/context`

如果上下文已經很長，可以壓縮歷史：

`1`	`/compact`

如果壓縮後效果仍然不好，可以考慮清空目前上下文：

/clear

清空上下文後，Claude Code 仍然可以透過專案檔案、CLAUDE.md 和目前目錄重新理解一部分專案情況，但不會保留完整對話歷史。

實用建議是：一個任務完成後就開新會話；專案級規則寫進 CLAUDE.md；臨時討論不要無限堆在一個聊天裡。

Skills：把固定流程做成說明書

Skills 可以理解為 Claude Code 的工作說明書。它不是一次性提示詞，而是一套可複用的任務流程。

例如你經常要生成週報，就可以建立一個週報 Skill，裡面寫清楚：

輸入需要哪些資訊。
輸出格式是什麼。
語氣和結構怎麼控制。
哪些內容必須保留。
哪些內容不能編造。

Skills 通常由 name、description 和具體指令組成。安裝到全域 Skills 目錄後，Claude Code 在遇到相關任務時可以識別並載入。

這適合處理重複工作：

週報。
程式碼審查模板。
文件整理。
圖片批次處理。
固定格式文章。
專案初始化流程。

如果你發現自己反覆複製同一段提示詞，就可以考慮把它做成 Skill。

Agents：把子任務交給獨立助手

Agents 和 Skills 不一樣。

Skill 更像說明書，告訴 Claude Code 怎麼做某類任務；Agent 更像一個獨立助手，可以在目前主會話之外執行任務，完成後把結果返回。

Agents 的價值在於隔離上下文。比如做程式碼巡檢時，可以建立一個唯讀 Agent，讓它只讀取專案並輸出報告，不直接修改檔案。這樣不會污染主會話，也能降低誤操作風險。

建立 Agent 時通常要考慮：

是專案級 Agent，還是使用者級 Agent。
是否需要 Claude Code 幫你生成配置。
允許哪些工具權限。
使用哪個模型。
是否保存記憶。
Agent 的提示詞是否足夠明確。

對於程式碼巡檢類 Agent，建議只給讀取權限，不給寫入權限。先讓它輸出報告，再由主會話決定是否修改程式碼。

插件：打包 Skills、Agents、MCP 和 Hooks

插件可以理解為更完整的能力包。它可能同時包含：

Skills
Agents
MCP
Hooks

相比單獨安裝一個 Skill，插件更適合成套能力。例如前端設計插件可能會把頁面審美、布局規則、元件習慣和相關 Agent 一起打包。

安裝插件時通常會有幾個位置選項：

如果是個人常用能力，可以放在使用者目錄；如果是團隊專案約定，可以放進專案目錄；如果只是臨時測試，放本地專案目錄更穩。

插件能明顯改善特定任務效果

在前端頁面生成這類任務裡，插件往往比裸提示詞更穩定。

例如同樣是「製作一個攝影師個人網頁」，只用普通提示詞可能生成一個能看的頁面；如果明確使用前端設計插件，頁面結構、視覺層次、間距、配色和整體完成度通常會更好。

這並不意味著插件能替代人工審美。更合理的用法是：先讓插件生成一個更好的初稿，再由人做細節微調。

一套更穩的 Claude Code 工作流

把上面這些技巧組合起來，可以形成一套比較穩的流程：

在專案目錄啟動 claude。
先用計劃模式討論需求。
批准計劃前確認技術棧和驗收標準。
涉及高風險操作時保留手動確認。
用終端模式執行本地預覽和測試。
結果走偏時及時回滾。
把專案規則寫進 CLAUDE.md。
長對話定期查看和壓縮上下文。
重複流程沉澱成 Skills。
巡檢、研究、分析類任務交給唯讀 Agents。
特定領域任務優先用插件。
重要專案始終配合 Git 提交點。

這樣使用 Claude Code，會比單純「發一句需求等它生成」穩定得多。

小結

Claude Code 的效率不只來自模型能力，也來自工作流控制。

計劃模式決定方向，權限確認控制風險，回滾減少返工，CLAUDE.md 保存專案規則，/context、/compact 和 /clear 管理上下文，Skills 複用固定流程，Agents 隔離複雜子任務，插件則把成套能力打包進專案。

真正好用的 Claude Code 工作方式，是讓它在清楚邊界內持續推進任務，而不是把整個專案一次性交給它自由發揮。

Awesome Codex Skills：給 Codex CLI 擴充技能的社群清單

Thu, 07 May 2026 20:19:15 +0800

ComposioHQ 的 awesome-codex-skills 是一個面向 Codex CLI 的社群技能清單。它的價值不在於再寫一堆提示詞模板，而是把一類可重複的工作流程整理成可安裝、可重複使用、可維護的 Skill。

如果你已經把 Codex 當成日常開發搭檔，這類倉庫的意義會很直接：把經常重複說明的規則、命令、資料入口和操作步驟沉澱下來，下次只要呼叫對應技能，Codex 就能依同一套上下文繼續工作。

這個倉庫解決什麼問題

Codex Skills 可以理解成給 Codex CLI 增加「專門工作模式」的方式。普通提示詞適合臨時說明一次需求，Skill 更適合長期重複使用。

比如你經常需要：

依固定格式生成提交訊息；
查閱某類 API 文件；
執行特定專案的測試和部署命令；
依團隊規範重寫文章、翻譯文件或整理資料；
呼叫外部工具完成重複性的開發輔助任務。

這些內容如果每次都重新輸入，很快就會變成負擔。Skill 的思路是把這些規則放進一個獨立目錄裡，核心通常是一份 SKILL.md，必要時再配合腳本、模板、參考資料或素材檔。Codex 被觸發時會讀取這份說明，然後依照裡面定義的流程執行。

和普通提示詞有什麼不同

普通提示詞更像一次性指令，適合告訴模型「這次怎麼做」。Skill 更像一份小型操作手冊，適合告訴 Codex「以後遇到這類任務都照這個方式做」。

它的優勢主要有三個：

可重複使用：常用工作流不用反覆複製貼上。
可審查：技能檔案通常是本地 Markdown，可以直接打開、修改和版本管理。
可擴充：複雜技能可以帶腳本、模板和參考資料，不只是自然語言說明。

這也是 awesome-codex-skills 這類清單的價值所在：它幫你集中發現已經寫好的技能，再依自己的工作習慣挑選、安裝和改造。

如何安裝和使用

倉庫提供了安裝腳本，也支援手動安裝。典型流程是先 clone 倉庫，再執行安裝腳本：

1
2
3

git clone https://github.com/ComposioHQ/awesome-codex-skills.git
cd awesome-codex-skills
python install.py

如果你只想試用少數技能，建議先看清每個技能目錄裡的 SKILL.md，確認它會讀取哪些資料、執行哪些腳本、修改哪些檔案，再安裝到本地 Codex skills 目錄。

安裝之後，Codex 可以在合適的任務中自動匹配技能，也可以透過明確點名的方式呼叫。對長期使用者來說，更實用的方式往往是：先安裝一個社群技能，再把裡面的說明改成自己的專案規範。

適合關注哪些技能

這類倉庫裡最值得優先看的，不一定是名字最酷的技能，而是能穩定減少重複勞動的技能。

我會優先關注幾類：

開發流程類：程式碼審查、測試、提交、發布、依賴檢查。
文件處理類：重寫、翻譯、摘要、結構化整理。
工具整合類：把 Codex 和外部服務、API、命令列工具連接起來。
專案規範類：把團隊約定、目錄結構、命名規則、部署步驟寫進固定流程。

如果一個技能只是把一句提示詞包裝了一下，價值有限；如果它能把「查資料、判斷、執行、驗證、輸出」串成穩定流程，就值得長期保留。

使用時要注意什麼

社群技能雖然方便，但不要把它當成黑盒直接執行。尤其是帶腳本的 Skill，安裝前最好先檢查三件事：

SKILL.md 裡要求 Codex 做什麼；
是否包含會存取網路、讀寫檔案或呼叫外部服務的腳本；
預設路徑、命令和權限是否適合你的本地環境。

Skill 本質上是在擴大 Codex 的行動邊界。寫得好，它會讓 Codex 更像熟悉你專案的同事；寫得粗糙，它也可能把不適合你的規則帶進工作流。所以最理想的用法不是「裝很多」，而是「裝少數、改到順手、長期維護」。

我的判斷

awesome-codex-skills 值得收藏，尤其適合已經開始用 Codex CLI 做真實開發、文件或自動化任務的人。它不是官方能力本身，而是一個社群整理的技能入口：你可以從裡面找靈感，也可以把常用流程改造成自己的本地技能庫。

對重度使用者來說，Codex Skills 的重點不是讓 AI 多記一點東西，而是讓 AI 在同類任務中少走彎路。把規則寫成 Skill，等於把一次次臨時溝通沉澱成可重複使用的工作基礎設施。

CC Switch：一個桌面工具統一管理 Claude Code、Codex、Gemini CLI 和 OpenClaw

Wed, 06 May 2026 09:03:08 +0800

CC Switch 是一個面向 AI 程式設計重度使用者的桌面管理工具。它要解決的問題很直接：現在很多人同時使用 Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw，但每個工具都有自己的設定格式、Provider 寫法、MCP 設定和 Skills 管理方式。

當你只用一個工具時，手動改設定還能忍；一旦多個工具混用，再加上官方帳號、第三方 API、中轉服務、本地模型和團隊共享設定，手動編輯 JSON、TOML、.env 很快就會變成一件很煩的事。

CC Switch 的定位，就是把這些分散設定收進一個跨平台桌面應用裡。

它解決什麼問題

現代 AI 程式設計工具越來越像「命令列裡的開發同事」，但每個工具的生態還沒有完全統一。

常見痛點包括：

Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 設定格式不同。
切換 API Provider 時，要反覆改設定檔。
MCP server 在不同工具之間重複設定。
CLAUDE.md、AGENTS.md、GEMINI.md 這類提示檔案難以統一維護。
Skills 安裝、同步、備份和解除安裝缺少一個集中入口。
多個帳號、多個 relay、多個模型服務切換很容易搞混。
設定檔手動修改出錯後，排查成本很高。

CC Switch 的思路是：不要讓使用者記住每個工具的設定細節，而是用一個統一介面管理 Provider、MCP、Prompts、Skills、Sessions 和代理。

支援哪些工具

README 中列出的核心支援對象包括五類：

Claude Code
Codex
Gemini CLI
OpenCode
OpenClaw

這幾個工具本身定位相近，都是圍繞 AI 程式設計、Agent 工作流和命令列協作展開。但它們的設定體系不同，CC Switch 的價值就在於把這些差異包裝起來。

對經常比較不同 AI 程式設計工具的人來說，這比每次手動翻設定檔省心很多。

Provider 管理

CC Switch 的第一層能力是 Provider 管理。

它內建了 50 多個 Provider 預設，README 中提到的方向包括 AWS Bedrock、NVIDIA NIM，以及各種社群 relay。使用者可以複製 API key，一鍵匯入，然後在介面中切換。

實用點主要有幾個：

一鍵新增 Provider。
Provider 拖曳排序。
系統匣快速切換。
Provider 匯入和匯出。
部分通用 Provider 可同步到多個應用。

對很多人來說，這個功能已經足夠有吸引力。因為 AI 程式設計工具的日常使用，經常不是「模型不會用」，而是「今天這個 key 用哪個工具、哪個 endpoint、哪個帳號」容易亂。

本地代理與故障切換

除了寫設定檔，CC Switch 還提供本地代理模式。

這個能力的重點是：

熱切換 Provider。
格式轉換。
自動故障轉移。
熔斷器。
Provider 健康檢查。
請求修正。

簡單說，它不只是把設定寫進目標工具，還可以在中間加一層本地代理，讓不同工具透過代理存取模型服務。

這對多 Provider 使用者很有用：一個服務掛了，可以切到另一個；一個模型貴，可以換成更便宜的；某個請求格式不相容，也可以透過代理層做適配。

MCP、Prompts 和 Skills

CC Switch 比較重要的第二層能力，是統一管理 MCP、Prompts 和 Skills。

MCP

它提供統一 MCP 面板，可以在多個應用之間管理 MCP server，並支援雙向同步和 Deep Link 匯入。

這對正在用 MCP 的使用者很實用。因為 MCP server 一多，設定很容易分散在不同客戶端裡。統一面板可以減少重複設定，也方便遷移。

Prompts

Prompts 部分支援 Markdown 編輯，並且可以在不同工具之間同步對應檔案，例如：

CLAUDE.md
AGENTS.md
GEMINI.md

這些檔案本質上都是給 Agent 的專案說明書。統一管理後，可以更容易維護團隊規則、專案約定和全域提示。

Skills

Skills 支援從 GitHub 倉庫或 ZIP 檔案一鍵安裝，也支援自訂倉庫管理、符號連結和檔案複製。

如果你同時使用 Claude Code、Codex、OpenClaw 這類工具，Skills 很容易變成一堆散落在不同目錄的檔案。CC Switch 把它們集中起來，能降低維護成本。

會話與工作區

README 還提到 Session Manager 和 Workspace 相關能力。

它可以瀏覽、搜尋和恢復多個應用裡的會話歷史。對長期使用 AI 程式設計工具的人來說，會話管理其實很重要：很多有價值的上下文、除錯過程、方案比較，都埋在舊對話裡。

此外，它還為 OpenClaw 提供 Workspace editor，可以編輯 AGENTS.md、SOUL.md 等 agent 檔案，並帶 Markdown 預覽。

這說明 CC Switch 不只是一個「切換 key 的小工具」，而是在往 AI Agent 工作台方向擴展。

雲同步與資料儲存

CC Switch 支援透過 Dropbox、OneDrive、iCloud、NAS 或 WebDAV 同步 Provider 資料。

本地資料儲存方式也比較清楚：

資料庫：~/.cc-switch/cc-switch.db
本地設定：~/.cc-switch/settings.json
自動備份：~/.cc-switch/backups/
Skills：~/.cc-switch/skills/
Skill 備份：~/.cc-switch/skill-backups/

它使用 SQLite 作為主要資料源，並強調原子寫入和自動備份，目標是避免設定檔在切換或寫入時損壞。

這個設計對重度使用者很關鍵。因為一旦設定管理工具本身把設定寫壞，影響的是所有 AI 程式設計工具。

安裝方式

CC Switch 是跨平台桌面應用，基於 Tauri 2 建構。

系統要求大致如下：

Windows：Windows 10 及以上
macOS：macOS 12 Monterey 及以上
Linux：Ubuntu 22.04+、Debian 11+、Fedora 34+ 等主流發行版

Windows 使用者可以下載 .msi 安裝包或可攜版壓縮包。

macOS 使用者可以用 Homebrew：

1
2

brew tap farion1231/ccswitch
brew install --cask cc-switch

更新：

`1`	`brew upgrade --cask cc-switch`

Linux 使用者可以選擇 .deb、.rpm 或 AppImage。Arch Linux 使用者也可以透過 paru -S cc-switch-bin 安裝。

截至 2026 年 5 月 6 日，倉庫頁面顯示最新 release 為 CC Switch v3.14.1，發布時間是 2026 年 4 月 23 日。

技術棧

從倉庫結構看，CC Switch 是典型的 Tauri 桌面應用：

前端：React 18、TypeScript、Vite、TailwindCSS、TanStack Query、shadcn/ui
後端：Tauri 2、Rust、SQLite、Tokio
測試：Vitest、MSW、Testing Library

核心設計模式包括：

SQLite 作為 Single Source of Truth。
JSON 保存裝置級本地設定。
切換時寫入目標工具的 live config。
編輯當前 Provider 時從 live config 回填。
使用臨時檔案加 rename 的方式做原子寫入。
資料庫連線加鎖，避免並發寫入問題。

這類架構說明專案並不是簡單腳本，而是按長期桌面工具來設計的。

適合誰用

CC Switch 適合下面幾類使用者：

同時使用 Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw。
經常切換官方帳號、第三方 relay、本地模型或團隊 Provider。
已經開始大量使用 MCP。
想統一維護 CLAUDE.md、AGENTS.md、GEMINI.md。
經常安裝、測試和遷移 Skills。
想看不同工具的會話歷史和使用情況。

如果你只用一個 AI 程式設計工具，而且一直走官方登入，不怎麼折騰 Provider、MCP 和 Skills，那它的價值可能沒那麼明顯。

但如果你已經進入「多工具、多帳號、多 Provider、多專案」的狀態，它能省掉很多瑣碎設定工作。

需要注意什麼

這類工具很方便，但也要注意邊界。

第一，它會管理多個 AI CLI 的設定，因此要確認自己信任這個工具和它的寫入邏輯。

第二，API key、relay endpoint、MCP server 都屬於敏感設定。開啟雲同步前，要確認同步目錄和 WebDAV 服務本身安全可靠。

第三，切換 Provider 後，多數工具仍然需要重啟終端或 CLI 才能生效。README 中提到，Claude Code 對 Provider 資料支援熱切換，但其他工具通常仍需要重啟。

第四，切回官方登入時，最好按專案說明新增 official provider，再重新走對應工具的登入流程。

小結

CC Switch 的價值不在於又做了一個 AI 程式設計工具，而在於它承認了一個現實：AI 程式設計生態已經進入多工具並存階段。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 各有自己的設定系統，MCP、Skills、Prompts、Provider 又在快速擴展。繼續靠手動改設定，遲早會變成負擔。

CC Switch 把這些東西收進一個桌面應用裡，讓使用者可以更輕鬆地切換 Provider、同步 MCP、管理 Skills、維護提示檔案和查看會話。對重度 AI 程式設計使用者來說，這類工具很可能會從「可選小工具」變成「日常基礎設施」。

參考資料

farion1231/cc-switch

Codex App 保姆級上手：安裝、沙箱、並行任務、Skills 與 MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App 可以理解成一個面向 AI 編程的任務工作台。它不是傳統 IDE，也不是單純聊天視窗，而是把多任務、專案管理、沙箱權限、Git、雲端執行、外掛、Skills、MCP 和自動化集中到一個介面裡。

如果你已經在用 Codex CLI、Claude Code、Cursor 或其他 coding agent，Codex App 最值得關注的地方，是它把「多個 agent 並行幹活」做成了更清楚的桌面工作流。

Codex App 適合做什麼

Codex App 的核心價值不是讓 AI 回答問題，而是讓 AI 在專案目錄裡持續執行任務：

修改程式碼、執行命令、啟動開發服務。
管理多個專案和多個任務。
在本地或雲端執行長任務。
呼叫外掛、Skills 和 MCP 擴展能力。
透過 Git、worktree 和 PR 管理改動。

OpenAI 官方也把 Codex App 定位成一個用於管理多個 coding agent 的介面。它適合需要同時推進多個程式碼任務的人，尤其適合前端頁面、腳本工具、小型應用、文件整理和自動化工作流。

安裝前準備

使用 Codex App 前，建議先準備好三個基礎工具：

Git
Node.js
VS Code 或你常用的 IDE

Codex App 支援 macOS 和 Windows。安裝後使用 ChatGPT 帳號登入，首次進入時可以選擇主要使用場景，例如編程或日常工作。Codex 會根據選擇預裝一部分外掛和 Skills，後續也可以在設定和外掛市場裡調整。

Windows 和 macOS 的主要功能大體一致，但部分電腦自動化能力可能依賴具體平台和外掛支援，實際以你目前版本顯示為準。

介面結構：專案、任務和對話

Codex App 是典型的三欄布局：

左側：專案、任務、歷史對話、外掛和自動化入口。
中間：目前對話視窗。
右側：檔案、瀏覽器、終端機、執行結果等多功能區域。

一個專案通常對應一個本地資料夾。你可以在同一個專案裡開多個對話，也可以同時打開多個專案，讓不同 agent 並行執行任務。

任務列表會顯示不同狀態：

正在執行：agent 仍在執行。
等待批准：需要你確認權限、連網、安裝依賴或執行高風險操作。
已完成：任務已經結束，可以查看結果或繼續追問。

這比在多個終端視窗裡來回切換更直觀，也更適合同時管理多個 AI 任務。

沙箱與權限控制

Codex App 的權限體系圍繞沙箱展開。預設情況下，目前專案資料夾會成為 agent 的主要工作範圍。

常見權限邊界包括：

可以讀取和修改專案目錄內的檔案。
預設不能隨意修改專案外檔案。
預設會限制連網或高風險命令。
需要越權時，會向使用者申請批准。

比較實用的模式是「自動審查」：低風險操作由系統自動放行，高風險操作再交給使用者確認。這樣既能減少頻繁彈窗，又能避免 agent 在不知情的情況下執行危險操作。

「完全存取」要謹慎開啟。它適合你明確知道 agent 要做什麼，並且專案已經有 Git 備份、重要檔案也有額外備份的場景。日常使用不建議長期保持完全存取。

上下文、模型和額度

Codex App 會顯示目前對話的上下文使用情況。對話越長，歷史內容越多，模型需要處理的上下文也越大。

實用建議是：

一個任務完成後，優先開新對話。
長對話可以手動壓縮，但不要把壓縮當成萬能記憶。
複雜任務先寫清楚目標、邊界和驗收標準。
不要把大量無關日誌、報錯和檔案一次性塞進對話。

模型選擇上，可以根據任務複雜度調整思考強度。簡單修改、文案整理、重複任務不一定需要最高規格模型；架構遷移、疑難 bug、跨檔案重構則更適合使用更強模型。

如果介面裡有快速模式，也要注意它通常會帶來更高的額度消耗。趕時間時可以開，日常不必預設開啟。

圖片生成與多模態輸入

Codex App 可以接收圖片和檔案作為上下文，也可以在合適場景中呼叫圖像生成能力。

這對前端和內容類專案很有用。例如你可以讓 Codex：

根據截圖修正頁面樣式。
替換網頁中的不合適配圖。
生成產品圖、輪播圖或頁面素材。
根據 UI 截圖指出需要修改的位置。

更高效的用法是：不要只說「改好看一點」，而是結合截圖指出具體問題，例如「這個卡片間距太大」「這裡的圖和服務場景不匹配」「把地圖區域做得更清楚」。

Steer：任務執行中及時糾偏

Steer 可以理解成「執行中接管方向」。當 agent 已經開始執行，但你發現它理解錯了方向，不應該等它全部跑完再改。

這時可以使用引導功能，把新的指令插入目前執行流程，讓 Codex 及時修正路線。

適合使用 Steer 的場景包括：

agent 誤解了需求。
生成的頁面風格明顯不對。
正在執行的方案成本太高。
你臨時補充了關鍵約束。

一般建議保留預設排隊行為，只在確實需要干預時手動使用 Steer。這樣既不會打亂正常任務，也能在關鍵時刻把方向拉回來。

計劃模式和內建瀏覽器

複雜任務建議先開計劃模式。計劃模式下，Codex 不會馬上改程式碼，而是先輸出方案，必要時還會用卡片形式追問關鍵選擇。

適合開計劃模式的任務：

框架遷移，例如從普通 React 專案遷到 Next.js。
大範圍重構。
涉及資料庫、認證、部署的功能。
你還沒想清楚技術路線的需求。

Codex App 的右側區域可以打開內建瀏覽器，用來預覽本地開發服務。你可以在頁面上做批註，讓 Codex 按具體 UI 位置修改問題。這種「看頁面、點位置、讓 AI 改」的流程，比純文字描述更適合前端除錯。

Git、IDE 和程式碼回滾

Codex App 不是完整 IDE。它可以查看程式碼、批註程式碼，但真正的手寫編輯仍然更適合交給 VS Code、Cursor、Windsurf 等 IDE。

建議每個 Codex 專案都盡早初始化 Git：

讓 Codex 建立或檢查 .gitignore。
在完成一個可用狀態後提交一次。
每次大改前確保有乾淨提交點。
不滿意時用 Git 回滾程式碼。

如果只回滾對話歷史，程式碼不會自動跟著回滾。比較穩的做法是：對話層面回到合適節點，程式碼層面用 Git commit hash 回到對應狀態。

Worktree：並行開發多個方向

git worktree 是 Codex App 裡非常適合並行 agent 的能力。

它的本質是：基於同一個倉庫建立多個獨立工作目錄，每個目錄對應不同分支。這樣你可以讓不同 agent 在不同資料夾裡同時開發，不互相覆蓋。

典型用法：

一個 worktree 優化客戶評價元件。
一個 worktree 調整門店資訊和地圖布局。
兩個任務完成後分別合併回主幹。
合併完成後刪除臨時 worktree。

這比在同一個目錄裡讓多個 agent 同時改程式碼穩得多。遇到衝突時，也可以按正常 Git 流程 review 和合併。

雲端執行環境

Codex 不只能在本機工作，也可以把任務委託到雲端環境執行。

雲端執行適合這些場景：

出門在外，手邊只有手機。
希望 agent 在背景跑長任務。
程式碼已經同步到 GitHub，需要讓 Codex 基於遠端倉庫修改。
希望透過 PR 形式審查和合併改動。

典型流程是：先把本地程式碼推到 GitHub，再讓 Codex 在雲端環境中拉取倉庫、執行任務、生成改動，最後以 PR 或 diff 的方式交給你審核。

本地繼續開發時，要記得把遠端最新改動同步回來。

記憶系統：寫好 AGENTS.md

新對話預設沒有完整歷史記憶。專案一複雜，如果每次都重新解釋背景，會很浪費。

最通用的做法，是在專案根目錄維護 AGENTS.md。這個檔案可以記錄：

專案目標和主要技術棧。
常用命令。
目錄結構說明。
程式碼風格和命名約定。
禁止事項，例如不要批量刪除檔案。
測試、建置和部署規則。

你也可以讓 Codex 先通讀專案，再生成一版 AGENTS.md，然後人工審一遍。複雜專案裡，這個檔案非常值得維護。

全域規則也要謹慎。適合寫入所有專案都通用的安全約束，例如「不要遞迴刪除目錄」「執行破壞性操作前必須確認」。不要把某個專案的細節寫進全域規則，否則會污染其他專案。

外掛和自動化

外掛用於把外部服務接入 Codex，例如 GitHub、Gmail、Google Drive、資料庫、部署平台等。

外掛的價值在於減少複製貼上。比如你可以讓 Codex：

查看某個 GitHub 倉庫的 star 趨勢。
整理郵件內容並發給自己。
定期執行某個檢查任務。
把結果寫成摘要。

自動化則適合重複任務。例如每週五下午檢查一次倉庫資料，並發送郵件報告。簡單自動化任務通常不需要最高規格模型，選擇較輕量的模型即可。

Skills：把工作流變成可複用能力

Skills 是 Codex 的「專業說明書」。它不是單次提示詞，而是把某類任務的流程、規範、腳本和注意事項沉澱下來，讓 Codex 後續穩定複用。

常見來源有三類：

官方 Skills。
第三方 Skills。
自己編寫的 Skills。

適合做成 Skill 的工作：

把字幕整理成圖文筆記。
按公司規範寫週報。
批量處理圖片或文件。
固定格式的程式碼審查。
特定框架的專案初始化。

如果某個提示詞你已經複製貼上了很多次，就值得考慮把它做成 Skill。

MCP：接入外部工具和資料庫

MCP 可以理解成給大模型使用的標準化工具協議。透過 MCP，Codex 可以呼叫外部服務完成更具體的任務。

例如接入 Supabase 後，可以讓 Codex：

建立資料表。
讀取資料庫結構。
修改後端接口。
把前端表單提交到資料庫。
根據資料庫狀態除錯問題。

這類能力很強，但也要注意權限邊界。資料庫、生產環境、部署平台、郵件帳號都屬於高風險資源。第一次接入時，最好使用測試專案和低權限帳號。

部署外掛

部署平台外掛可以讓 Codex 直接完成建置和發布，例如把前端專案部署到 Netlify 一類平台。

這類外掛適合小型網站、原型頁面、內部工具和展示專案。實際使用時建議注意：

部署前先跑本地建置。
環境變數不要直接寫進程式碼。
發布後檢查頁面是否能正常訪問。
生產專案要保留人工 review。

AI 可以幫你打通發布流程，但發布權限仍然要謹慎管理。

電腦自動化

在支援的平台和外掛環境裡，Codex 還可以操作瀏覽器或桌面應用，完成更接近 RPA 的任務。

例如：

打開聊天軟體並準備一條訊息。
瀏覽專案看板，彙總任務狀態。
生成英文簡報。
在你確認後發送給指定對象。
把這套流程做成定時自動化。

這類功能很有想像力，但也最需要安全邊界。凡是涉及發訊息、發郵件、提交表單、付款、刪除資料的操作，都應該保留人工確認。

使用建議

Codex App 的正確打開方式，不是讓它一次性全自動接管一切，而是把任務拆清楚，讓它在受控環境裡高效執行。

推薦習慣：

每個專案先初始化 Git。
複雜任務先開計劃模式。
並行任務優先用 worktree。
專案規則寫進 AGENTS.md。
高風險操作保留人工確認。
重複流程沉澱成 Skill 或自動化。
外掛和 MCP 先在測試環境驗證。

參考資料

小結

Codex App 的重點不是「多一個 AI 聊天視窗」，而是把 AI 編程變成一個可管理的工作台：本地專案、雲端任務、Git、worktree、外掛、Skills、MCP 和自動化都能串起來。

真正用好它的關鍵，是在「放權」和「控制」之間找到平衡。小任務可以大膽交給 Codex，複雜任務先讓它計劃，高風險動作必須確認。這樣它才會從一個會寫程式碼的助手，變成可以長期協作的工程工具。

mattpocock/skills：給 AI 編程 Agent 準備的實用技能集合

Fri, 01 May 2026 03:43:20 +0800

mattpocock/skills 是 Matt Pocock 公開的一組 AI 編程 agent skills。

它不是一個完整的應用，也不是一個新的聊天客戶端，而是一套可以給 AI 編程助手使用的工作技能。它的思路很實用：把 AI 編程裡經常出現的問題拆成一個個小技能，讓 Agent 在合適的任務裡呼叫，而不是每次都靠一大段提示詞硬撐。

如果你經常使用 Claude Code、Codex、Cursor 或類似的 AI 編程工具，這類 skills 很值得關注。因為真正影響 AI 編程體驗的，往往不是「模型會不會寫程式碼」，而是它能不能按你的工作方式推進任務。

它解決什麼問題

AI 編程助手很強，但也很容易出問題。

常見情況包括：

還沒理解需求就開始改程式碼
一次性改太多檔案
輸出解釋很多，真正有用的行動很少
遇到錯誤後盲目嘗試
沒有及時執行測試或檢查
忽略專案裡已有模式
為了完成任務引入不必要的抽象
寫完程式碼後沒有真正 review 風險

這些問題不一定是模型能力不夠，而是工作流沒有被約束好。

mattpocock/skills 的價值在於，把這些常見失敗模式拆成可以複用的操作方式，讓 Agent 在不同場景下更像一個有經驗的工程協作者。

Skills 是什麼

在 AI Agent 語境裡，skill 可以理解成一段可複用的任務說明、工作方法或專業流程。

它不一定是程式碼插件，也不一定必須呼叫外部服務。很多時候，一個 skill 就是一套明確規則：

什麼時候使用
先做什麼
不要做什麼
需要輸出什麼
怎麼判斷任務完成

這和普通提示詞模板有點像，但粒度更接近「任務能力」。

普通提示詞模板通常是使用者每次臨時複製貼上；skills 則更適合作為 agent 工具箱的一部分，讓 Agent 根據任務選擇合適流程。

為什麼要小而可組合

README 中強調這些 skills 是小而可組合的。

這個方向很重要。

如果一個 skill 試圖包辦所有事情，它很快就會變成新的大提示詞：又長、又模糊、又難維護。小技能的優勢是邊界清楚。

比如一個 skill 專門負責：

先做計劃
修復 TypeScript 錯誤
執行測試並根據結果修復
做程式碼 review
總結專案約定
改進提示詞
清理無用抽象

這些技能可以按任務組合使用。簡單任務只用一個技能，複雜任務再串起來。

這更接近真實工程工作：你不會用同一套流程處理所有問題，而是根據問題選擇工具。

保留工程師控制權

這個倉庫的一個重要取向，是讓工程師仍然掌握控制權。

AI 編程很容易滑向兩種極端：

第一種是完全手動。AI 只是幫你寫幾行程式碼，所有上下文、計劃、驗證都靠你自己盯。

第二種是完全放手。你把任務丟給 Agent，讓它自己大改一通，最後再面對一堆難以審查的 diff。

skills 的作用是在中間找一個更穩的位置。

它讓 AI 承擔更多重複流程，但仍然用規則限制它：

先理解任務再動手
先閱讀相關檔案再改
修改範圍要可控
出現不確定時要回報
改完要驗證
不能為了炫技重構無關程式碼

這不是削弱 AI，而是讓 AI 的行動更容易被人類審查和接管。

對齊問題

AI 編程失敗的第一類問題通常是對齊失敗。

使用者想要的是一個很具體的改動，但 Agent 可能理解成一個更大的重構；使用者只想修 Bug，它卻順手改了樣式；使用者希望遵守現有架構，它卻引入新模式。

Skills 可以在任務開始階段幫助 Agent 做幾件事：

重述目標
找出影響範圍
識別已有實現模式
給出計劃
明確不做哪些事情

這一步很像工程師開工前的自檢。

如果 Agent 連任務邊界都沒說清楚，就直接寫程式碼，後面很容易越走越偏。

回饋循環問題

AI 寫程式碼不能只靠一次生成。

真實開發裡，回饋循環很重要：

改一小步
跑測試或型別檢查
看錯誤
修正
再驗證

很多 Agent 失敗，是因為它跳過了中間回饋。它一次性改很多內容，然後憑感覺總結「應該可以工作」。

Skills 可以把回饋循環顯式寫進流程裡。比如要求 Agent：

修改後執行相關檢查
如果檢查失敗，先讀錯誤訊息
不要盲目改無關檔案
每輪修復後重新驗證
最後報告驗證結果

這會讓 AI 編程更像真實除錯，而不是一次性作文。

架構控制問題

AI 很擅長生成抽象，也很擅長過度生成抽象。

為了完成一個小需求，它可能新建服務層、工具函式、配置物件、型別包裝、適配器，最後讓程式碼比需求本身複雜得多。

這類問題在大型專案裡尤其危險。因為 AI 生成的抽象看起來很「專業」，但它可能不符合專案已有風格，也可能增加維護成本。

好的 skills 會提醒 Agent：

優先沿用現有模式
不引入沒有必要的新抽象
不順手重構無關區域
修改要和任務規模匹配
先理解程式碼再設計結構

這能減少「看起來很工程化，實際上更難維護」的輸出。

Review 技能為什麼重要

寫程式碼和 review 程式碼是兩種不同狀態。

Agent 在寫程式碼時，通常會傾向於證明自己的實現成立。它會解釋為什麼這樣改可以工作，但不一定主動找風險。

Review skill 的意義，是讓 Agent 切換角色：

找潛在 Bug
找行為回歸
找遺漏測試
找邊界條件
找複雜度上升
找和現有約定不一致的地方

這對 AI 編程很重要。因為 AI 生成程式碼的速度很快，如果沒有 review，使用者很容易被大量 diff 淹沒。

一個好的 review 輸出應該優先列問題，而不是先誇實現。它要幫助工程師判斷這次改動能不能合併。

和普通 rules 檔案有什麼區別

很多 AI 編程工具都支援 rules、instructions 或 memory。

這些檔案通常記錄長期規則，比如：

專案技術棧
命名規範
測試命令
不要修改哪些目錄
回答風格偏好

Skills 更偏任務流程。

rules 告訴 Agent「長期應該怎麼做」，skills 告訴 Agent「面對某類任務時應該怎麼執行」。

兩者最好一起用。

比如 rules 裡寫專案用 pnpm test，review skill 裡要求改完後檢查測試覆蓋。這樣 Agent 不僅知道命令，也知道什麼時候該用。

適合什麼場景

mattpocock/skills 這類倉庫適合這些場景：

高頻使用 AI 編程工具
經常讓 Agent 處理真實程式碼庫
想減少 AI 越界修改
想讓 Agent 更主動地驗證結果
想把自己的工程習慣沉澱成技能
想學習別人如何設計 agent workflows
想把一堆臨時提示詞整理成可維護的技能集合

如果你只是偶爾讓 AI 寫一個小函式，可能不需要專門維護 skills。

但如果你已經把 AI 當成長期開發夥伴，skills 會逐漸變得重要。它們相當於給 Agent 配了一套可複用的工作方法。

怎麼借鑑這個倉庫

即使你不直接使用其中的每個 skill，也可以從這個倉庫學到幾件事。

第一，把失敗模式寫下來。

不要只在 AI 出錯時臨時抱怨。把它經常出錯的模式整理成規則，下一次讓 skill 提前防住。

第二，技能要短。

一個 skill 最好解決一個明確問題。越短越容易被正確呼叫，也越容易維護。

第三，輸出格式要清楚。

如果你希望 Agent 先列計劃、再執行、最後總結驗證結果，就把輸出結構寫清楚。模糊要求通常會得到模糊結果。

第四，保留人工接管點。

好的 skill 不應該讓 AI 獨自跑到很遠。遇到不確定、影響範圍擴大、測試失敗或需要產品判斷時，應該讓它停下來說明情況。

使用時要注意

第一，不要把所有事情都技能化。

太多 skills 會讓系統變複雜，Agent 也可能不知道該選哪個。先從最高頻、最痛的幾個場景開始。

第二，skills 需要迭代。

第一次寫出來的 skill 不一定好。看 AI 實際執行效果，再逐步刪減、補充和改寫。

第三，不要讓 skill 替代工程判斷。

Skill 可以改善流程，但不能保證實現正確。測試、review、構建檢查和人類判斷仍然重要。

第四，注意不同 Agent 的差異。

Claude Code、Codex、Cursor、Copilot 對 instructions、skills、rules 的支援方式不同。同一套思想可以複用，但具體格式要按工具調整。

參考

mattpocock/skills

最後一句

mattpocock/skills 值得關注的地方，不是裡面某一個神奇提示詞，而是它展示了一種更實用的 AI 編程思路：把工程經驗拆成小技能，再讓 Agent 按場景組合使用。

當 AI 編程從偶爾輔助變成日常工作流，skills 會成為約束 Agent、保留工程師控制權和提升回饋品質的重要工具。

Codex Skill 明明在目錄裡，為什麼就是不顯示？

Wed, 29 Apr 2026 11:18:00 +0800

這次遇到的問題很隱蔽：~/.codex/skills 裡明明已經放好了多個 skill，新開 Codex 執行緒之後，側邊欄卻還是只能看到少數幾個。

一開始看起來像是快取或索引問題，但實際原因更具體：幾個 SKILL.md 文件開頭帶了 UTF-8 BOM，Codex 0.111.0 的 skill loader 沒有跳過這個位元組，於是誤判文件沒有合法的 YAML front matter。

現象

本地目錄裡有這些 skill：

~/.codex/skills/git-commit-push/SKILL.md
~/.codex/skills/hugo-rsync-deploy/SKILL.md
~/.codex/skills/bilibili-speech-transcriber/SKILL.md
~/.codex/skills/product-cutout-normalize/SKILL.md

但新開執行緒時，實際暴露出來的只有：

1
2

bilibili-speech-transcriber
product-cutout-normalize

也就是說，文件存在不等於當前會話一定能載入成功。Codex 會先解析每個 SKILL.md 的 front matter，解析失敗的 skill 會直接被排除。

排查

用 codex exec 啟動一個新會話時，可以看到更直接的錯誤。在 VS Code 等 IDE 中，可能看不到這些 log：

1
2

failed to load skill C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md: missing YAML frontmatter delimited by ---
failed to load skill C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md: missing YAML frontmatter delimited by ---

這些文件肉眼看起來都有正常的開頭：

---
name: post-rewrite
description: ...
---

真正的問題在位元組層面。

失敗文件的開頭是：

`1`	`EF-BB-BF-2D-2D-2D`

能正常載入的文件開頭是：

`1`	`2D-2D-2D`

2D-2D-2D 就是 ---。前面的 EF-BB-BF 是 UTF-8 BOM。

原因

Codex 0.111.0 的 skill loader 目前要求 SKILL.md 文件第一個位元組就是 --- 的第一個 -。

如果文件前面帶了 UTF-8 BOM，那麼文件實際開頭就不再是 ---，而是：

`1`	`BOM + ---`

於是 loader 會認為它沒有以前置資料分隔符開頭，最後報：

`1`	`missing YAML frontmatter delimited by ---`

這不是 skill 內容寫錯了，也不是目錄放錯了，而是編碼細節讓解析器沒認出來。

修復

把出問題的 SKILL.md 轉成無 BOM 的 UTF-8 即可。

PowerShell 可以這樣處理：

$paths = @(
  'C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md',
  'C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md',
)

$utf8NoBom = New-Object System.Text.UTF8Encoding($false)

foreach ($p in $paths) {
  $text = [IO.File]::ReadAllText($p, [Text.Encoding]::UTF8)
  [IO.File]::WriteAllText($p, $text, $utf8NoBom)
}

處理後再檢查文件頭，應該從：

`1`	`EF-BB-BF-2D-2D-2D`

變成：

`1`	`2D-2D-2D`

驗證

重新啟動一個 Codex 會話後，可見 skill 恢復為：

git-commit-push-zh
hugo-rsync-deploy
bilibili-speech-transcriber
product-cutout-normalize

如果側邊欄仍然只顯示舊的列表，可以退出當前 Codex sidebar 或窗口，再重新打開專案。skill 列表通常在會話啟動時載入，中途改文件不一定會立刻刷新到當前執行緒。

最後一句

這類問題最容易誤判成「Codex 沒重新索引」或「skill 沒安裝好」。

實際排查時可以先看三件事：

SKILL.md 是否真的在正確目錄
文件頭部是否有合法的 --- front matter
文件是否是無 BOM 的 UTF-8

這次的關鍵就是第三點：文件看起來沒問題，但第一個位元組不是 -，Codex 就沒有把它當作一個有效 skill。

Codex 裡的 ~/.codex/skills 和專案/.codex/skills 有什麼差別

Wed, 29 Apr 2026 11:08:00 +0800

很多人整理 Codex skills 時，最容易卡住的問題就兩個：

~/.codex/skills 和 專案/.codex/skills 有什麼差別
為什麼 skill 明明在目錄裡，當前會話裡卻不一定顯示

這篇就直接說結論。

兩者的差別

先記最短版本：

~/.codex/skills 是你的全域技能庫
專案/.codex/skills 是這個倉庫的本地技能庫

`~/.codex/skills`

適合放：

你自己跨專案反覆會用的 skill
跟具體倉庫無關的通用流程
很明顯屬於你個人習慣的工作流

比如：

post-rewrite
post-translate
git-commit-push
hugo-rsync-deploy
bilibili-speech-transcriber

這類 skill 的特點就是：離開當前專案也還能用。

`專案/.codex/skills`

適合放：

只對這個倉庫成立的流程
跟當前專案目錄結構、腳本、模板綁定很深的規則
需要讓團隊一起共享的 skill

比如：

這個倉庫特有的發布流程
只能在這個專案裡用的生成模板
跟專案私有腳本強綁定的自動化步驟

這類 skill 的特點是：離開這個倉庫就沒意義。

什麼時候放全域，什麼時候放專案裡

直接這樣判斷就夠了：

跟你個人習慣有關，放 ~/.codex/skills
跟倉庫規則有關，放 專案/.codex/skills
能跨專案複用，優先放全域
要多人共享、跟倉庫一起演進，優先放專案裡

當前這個倉庫是什麼情況

按我現在看到的實際狀態：

你的本機裡有 ~/.codex/skills
當前倉庫裡沒有 .codex/skills

所以你現在主要依賴的是全域 skills。

也就是說，像 post-rewrite、post-translate、git-commit-push 這些流程，現在更多是你個人工作流的一部分，不是這個倉庫顯式自帶的一部分。

為什麼磁碟裡有，當前會話裡卻不一定顯示

這裡要分清兩件事：

磁碟存在：說明 skill 文件在本地目錄裡
會話暴露：說明當前會話把它註冊進了可用 skill 列表

這兩者不是一回事。

所以會出現這種情況：

~/.codex/skills 裡已經有 skill
但 / 後面的列表裡沒有顯示

這通常不代表 skill 壞了，更常見的原因是：當前會話沒有把它重新索引進去。

怎樣讓 skill 被當前會話暴露

最實用的步驟就這幾條：

1. 目錄放對

全域：

`1`	`~/.codex/skills/<skill-name>/SKILL.md`

專案級：

`1`	`專案/.codex/skills/<skill-name>/SKILL.md`

2. `SKILL.md` 頭部可識別

最少要有：

---
name: your-skill-name
description: 這個 skill 是做什麼的
---

3. 新建或修改後，開新會話

很多時候 skill 沒顯示，不是文件有問題，而是當前會話啟動時就已經把可用 skill 列表定下來了。

所以你中途新建 skill，磁碟裡雖然已經有了，這次會話也未必會重新認。

最穩的做法就是：

放好 skill
結束當前會話
重新進入專案
開一個新會話
再看 / 裡有沒有出現

4. 專案 skill 最好提前放好

如果你想讓 專案/.codex/skills 更穩定地被識別，最好在進入倉庫、啟動會話之前，就把這些 skill 放進專案裡。

最後一句

最短結論就是：

~/.codex/skills 是你的個人技能庫
專案/.codex/skills 是倉庫的本地規則庫
skill 在目錄裡，不等於當前會話一定會顯示
想讓它顯示，最常見的辦法就是放對目錄、寫好 SKILL.md，然後開新會話