GitHub 技能庫把 AI 寫程式變流程

我把 GitHub 趨勢報告拆成一套可直接複製的 AI 寫程式流程，重點是把提示詞變成技能與規則。

我用 AI 寫程式工具一陣子了，老實說，最煩的不是它不會寫，是它太會亂寫。你叫它先補測試，它說好；你叫它別亂動 production 相關檔案，它也說好；你叫它照團隊規範走，它還是會在你沒注意時自己發明一套。前幾分鐘看起來很像會做事，十分鐘後就開始像一個拿到 root 權限的實習生，還很有自信。這次我看到 GitHub 趨勢報告後，才比較確定問題在哪裡：不是模型不夠強，是我們一直用聊天方式在管流程，當然會失控。

這份洞察的起點是 DEV Community 上的 GitHub Weekly Trending Repositories Report，資料來源還串了 star-history.com。我不是要把它吹成什麼神作，但它很直接地點出一件事：大家正在把 AI coding 從「會講話」推向「會照規則做事」。

我看到的不是熱度，是大家終於受不了亂跑的代理人

AI agent skills frameworks have taken over the open-source ecosystem.

翻譯一下就是：開源社群現在不太想再跟 AI 玩即興表演了。大家要的是重複得出來的行為，不是每次都靠運氣。這句話我很有感，因為我自己最常踩的坑，就是同一個工具在不同專案裡表現完全兩樣。今天在 A repo 很乖，明天到 B repo 就開始亂補架構、亂改檔名、亂猜需求。

我之前真的有一段時間以為，只要 prompt 寫得夠完整，模型就會自動變穩。結果不是。只要對話一長、上下文一多，它就開始忘記前面講過的限制。你越想靠一句話把事情講清楚，它越容易在後面自己發揮。

實操寫法很簡單：把你每週都會重複講的規則，從聊天框搬到檔案裡。不要再每次都臨時打字。改成 repo 裡有一份固定的規則文件，讓 AI 每次都先讀。這樣做看起來很土，但真的比你每次重講一次有效。

• 把重複出現的要求寫成檔案，不要只放在對話裡。
• 每個規則只管一件事，別一份文件塞十種人格。
• 先管住危險行為，再談效率。

mattpocock/skills 會紅，不是因為會吹，是因為夠像真實工作

報告裡最醒目的專案是 mattpocock/skills。作者把它描述成「來自 .claude 目錄的技能」。這句話我覺得很誠實，因為它不是在賣概念，是直接把平常真的會用到的規則攤開來。

這裡的重點不是「技能」這個詞聽起來很潮，而是它把 AI 的行為拆成可重用的模組。像是測試優先、除錯步驟、危險指令停下來確認、特定語言的慣例，這些都不是靈感，是工作規則。你如果還在用一大段大雜燴 prompt 去管所有情境，效果通常都不太行。

我自己以前也很愛寫長 prompt，覺得自己像在做提示工程。後來才發現，那比較像在寫一封很累的信。真正有用的是把規則做成小塊，讓工具可以每次都照著走。你不用期待它變聰明，你只要讓它不要一直犯同一種蠢就好。

實操寫法：

• 把常用任務拆成小技能，例如測試、除錯、重構、安全操作。
• 每個技能都要有「好輸出」跟「壞輸出」範例。
• 技能名稱要像命令，不要像論文標題。
• 如果團隊每週都在抱怨同一件事，那就是你該寫技能的地方。

Claude Code 周邊爆出來，代表大家在補工具洞

報告裡不只一個 repo 在講 Claude Code，還有像 cc-switch、everything-claude-code、addyosmani/agent-skills，甚至 anthropics/skills 也在做同一件事。這不是巧合，這是生態開始長出周邊了。

白話講，工具只要真的進入日常工作，就不會只剩主產品本身。你一定會開始需要環境切換、規則管理、範本、教學、整合方式。這些東西看起來不性感，但它們才是讓工具能不能落地的差別。

我自己最有感的是，很多 AI 工具 demo 的時候都超順，一到真實專案就卡。不是因為模型不行，是因為你還沒把周邊補齊。專案規範、權限、測試流程、部署風險，這些東西才是日常。你不把它們包進去，AI 就只會在最理想的狀況下表現正常。

實操寫法：

• 先補環境切換與專案初始化流程。
• 把常見規則集中成一個入口，不要散在 Slack、Notion、腦袋裡。
• 讓團隊每個人用同一套起手式，別各自發明版本。

spec-kit 其實是在反對「憑感覺寫」

報告裡另一個我很在意的是 github/spec-kit。它走的是 spec-driven development，也就是先寫規格，再排計畫，再拆任務，最後才進實作。這條路線我很認同，因為它直接把很多 AI 寫 code 的毛病卡掉了。

翻譯一下就是：不要一開始就叫模型生 code。先叫它把需求講清楚，再叫它拆步驟，最後才動手。這樣做不是慢，是少走冤枉路。你如果直接讓它寫，八成會得到一坨看起來像樣、實際上很難 review 的東西。

我之前遇過一個很典型的狀況：我只想改一個 API 行為，結果 AI 幫我順手重構三個檔案，還很開心地說這樣更乾淨。問題是我根本沒要求它這樣做。這就是沒有規格的後果，工具會自己補完故事，而且通常補得很爛。

實操寫法很直接：

• 先要求 AI 產出需求摘要。
• 再要它列限制條件與假設。
• 接著拆成可 review 的任務清單。
• 最後才允許它寫程式。

Hermes Agent 提醒我：記憶比嘴砲重要

報告也提到 NousResearch/hermes-agent，它主打會跟著你一起成長，還提到自我改善記憶、Python 架構、MIT 授權。這種方向我其實不意外，因為大家早晚都會碰到同一個問題：AI 每次都從零開始，真的很煩。

如果一個代理人沒有記憶，它就只能在每次對話裡重跑一次新手教學。這對問答還行，對軟體工作就很差。因為軟體工作有很多固定偏好、團隊規範、歷史決策，這些都不該每次重講。你講一次、兩次、三次，最後還是會懷疑是不是自己在跟失憶症工具共事。

我現在比較相信的做法不是等模型自己學會，而是把記憶外掛在專案裡。決策紀錄、除錯筆記、團隊規則、風險提醒，這些都應該留在 repo，不要只留在某個人的腦袋。這樣就算工具換了，流程還在。

實操寫法：

• 建立決策紀錄檔，記下為什麼這樣做。
• 把常見錯誤與修正方式寫成可查的筆記。
• 如果工具支援持久記憶，就只存專案層級資訊。

技能庫其實是文件，只是更能被執行

我覺得這波最值得注意的地方，不是某個 repo 多紅，而是大家開始把知識做成可執行文件。像 multica-ai/andrej-karpathy-skills、anthropics/financial-services 這類例子，說穿了就是把領域知識包成 AI 看得懂的規則。

這件事的價值很務實。以前很多團隊的流程都藏在老鳥腦中，新人只能靠問。現在如果你把規則寫成技能，AI 可以先幫你守第一層，新人也能照著做，不會每次都從零摸索。這不是偷懶，是把隱性知識變成明文規則。

我自己的經驗是，只要團隊沒寫下來，AI 幫忙的品質就會非常飄。每個人餵它的方式不同，結果就會長得很不一致。你以為是模型不穩，其實是輸入來源根本沒統一。

實操寫法：

• 把常見流程寫成 living docs，不要寫完就放生。
• 每次出現新失敗模式，就補進技能文件。
• 有合規、資安、部署限制的領域，直接寫進規則，不要靠口頭提醒。

可抄的模板

# AI Agent 技能包模板（繁中版）

這份模板可以直接放進你的 repo，給 Claude Code、Cursor、Codex 或任何會讀專案檔案的 AI 助手用。

## 1) agent-instructions.md

# Agent 操作規則

在這個 repo 裡工作時，請先讀取對應技能檔案，再開始產出內容。

## 基本規則
- 先確認需求，再開始寫 code。
- 先寫測試，再做實作。
- 有危險指令時先停下來確認。
- 變更要小，方便 review。
- 如果需求不清楚，只問一個最關鍵的問題。
- 如果任務太大，先拆成步驟。

## 2) repo-skills/tdd.md

# 技能：測試優先

當你要新增或修改行為時：
1. 先找出最小的失敗測試。
2. 先寫測試。
3. 再做最小實作讓測試通過。
4. 測試通過後才考慮重構。
5. 除非使用者明講，否則不要跳過測試步驟。

## 3) repo-skills/debugging.md

# 技能：結構化除錯

當東西壞掉時：
1. 先重述症狀。
2. 列出最可能的原因。
3. 先查成本最低的原因。
4. 一次只改一個變數。
5. 記錄哪些原因已經排除。

你要回報：
- 哪裡壞了
- 你檢查了什麼
- 你改了什麼
- 為什麼這個修正合理

## 4) repo-skills/safety.md

# 技能：安全與防呆

在執行危險指令前，先停下來請求確認。

危險指令範例：
- git push --force
- rm -rf
- 生產環境資料庫 migration
- 任何會刪資料或覆蓋工作的操作

如果有人要求危險指令，請回覆：
「這個指令可能造成資料遺失或覆蓋既有工作，請先確認後我再執行。」

## 5) repo-skills/spec-driven-workflow.md

# 技能：規格驅動開發

在開始實作前，先產出：
1. 簡短規格摘要
2. 限制條件
3. 假設
4. 任務拆解
5. 實作計畫

工作流程：
- Spec：先講要做什麼、為什麼做
- Plan：再講怎麼做
- Tasks：拆成可 review 的小步驟
- Implementation：確認後才開始

## 6) repo-skills/stack-specific.md

# 技能：技術棧慣例

把你團隊的慣例寫進來。

範例：
- TypeScript：公開函式盡量保留明確型別
- Python：函式保持短小、好測試
- React：避免不必要的 state
- API：加上 request / response 範例

## 7) 範例起手式

請使用這份 repo 的技能檔案，並遵守 spec-driven-workflow.md。
這次任務請先：
- 重述目標
- 列出假設
- 提出任務拆解
- 等我確認後再開始實作

## 8) 操作原則

- 如果 AI 開始自作主張，先停。
- 如果 AI 跳過測試，叫它回去補。
- 如果 AI 輸出危險指令，先要求確認。
- 如果 AI 說不出計畫，就不要讓它直接寫 code。

這份模板不花俏，因為我本來就不想要花俏。我想要的是一套能直接塞進 repo 的東西，讓 AI 別再自由發揮。這也是我從這份報告裡真正學到的事：大家不是在追一個更會聊天的工具，而是在找一種更穩的工作方式。

如果你現在也被 AI 寫程式搞到有點火大，我會建議你不要先追新模型，先把技能文件補起來。挑一個最常出包的場景，先寫一份規則。寫完後你會很快發現，很多問題不是模型太笨，是你根本沒把邊界講清楚。

來源網址：DEV Community 的原始文章、star-history.com、mattpocock/skills、github/spec-kit。上面前半段是我根據原始報告整理的拆解，模板段落是我依照這些模式重新寫成可直接使用的版本。