GitHub on KnightLi的博客

GitHub Spec Kit 是什麼？用規格驅動開發約束 AI 編程

Mon, 25 May 2026 00:19:14 +0800

GitHub 的 Spec Kit 是一個面向 AI 編程的新工具包，目標是幫助開發者實踐 Spec-Driven Development，也就是規格驅動開發。

它解決的問題很直接：現在很多 AI 編程工作流太像「邊聊邊寫」。人類給一個大概想法，Agent 立刻開始改代碼，短期看很快，但需求邊界、驗收標準、技術取捨和任務拆分往往沒有沉澱下來。項目稍微複雜一點，就容易變成一次性的 vibe coding。

Spec Kit 的思路是反過來：先把規格寫清楚，再進入計劃、任務和實作。代碼不再是第一步，規格才是第一步。

Spec Kit 是什麼？

Spec Kit 是 GitHub 開源的規格驅動開發工具包。它提供 specify CLI、模板、腳本和面向 AI coding agent 的命令，讓團隊可以圍繞同一套結構化產物推進開發。

它強調的不是「讓 AI 少問問題」，而是讓 AI 在寫代碼前先生成並完善這些內容：

項目原則：團隊對品質、測試、體驗、性能等方面的約束；
功能規格：要做什麼、為什麼做、使用者故事和功能需求；
技術計劃：使用什麼技術棧、如何落地、有哪些架構決策；
任務清單：把計劃拆成可執行步驟；
實作過程：按任務逐步修改代碼，而不是一次性亂改。

這套流程讓 AI 編程更像工程協作，而不是一次提示詞表演。

基本使用流程

官方 README 給出的入門流程大致是這樣：

1
2
3

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
specify init my-project --integration copilot
cd my-project

初始化後，項目裡會生成 .specify 目錄、模板、腳本和與 Agent 整合的命令。隨後在支援的 AI coding agent 中使用 /speckit.* 命令推進開發。

典型順序是：

/speckit.constitution
/speckit.specify
/speckit.clarify
/speckit.plan
/speckit.tasks
/speckit.implement

其中 /speckit.constitution 用來建立項目原則，/speckit.specify 描述產品需求，/speckit.clarify 補齊模糊點，/speckit.plan 生成技術計劃，/speckit.tasks 拆任務，最後由 /speckit.implement 執行實作。

這和直接對 Agent 說「幫我做一個應用」差別很大。Spec Kit 要求你把「做什麼」和「怎麼驗收」先說清楚，再讓 Agent 動手。

它改變了 AI 編程的入口

傳統 AI 編程經常從代碼開始：

`1`	`我想做一個任務管理應用，幫我寫出來。`

Spec Kit 更像這樣：

先定義這個任務管理應用的使用者、場景、功能邊界、驗收標準和非目標；
再根據這些規格選擇技術方案；
然後拆成任務；
最後逐步實作。

這個變化很重要。因為 AI 最擅長根據上下文執行，但如果上下文本身是鬆散的，執行速度越快，偏離方向也可能越快。Spec Kit 把上下文變成文件和模板，讓需求、計劃和任務都能被 review、修改和版本管理。

換句話說，它不是讓 AI 更「自由」，而是讓 AI 在更清晰的工程軌道上自由發揮。

核心命令怎麼理解？

`/speckit.constitution`

這是項目的「憲法」。它會生成或更新 .specify/memory/constitution.md，用於記錄項目長期遵守的原則，例如代碼品質、測試標準、使用者體驗一致性、性能要求和技術決策規則。

這一步適合寫團隊共識，而不是單個功能需求。

`/speckit.specify`

這是功能規格階段。你需要描述要構建什麼、使用者是誰、解決什麼問題、有哪些核心流程。

官方特別強調：這一階段不要過早關注技術棧。先把 what 和 why 寫清楚，再討論 how。

`/speckit.clarify`

這是補問題的階段。很多需求第一次寫出來都會有空洞：權限怎麼處理？異常狀態是什麼？數據是否持久化？邊界條件如何驗收？

/speckit.clarify 的價值，是讓 Agent 主動發現規格中的不確定點，並把回答記錄回規格文件，減少後面返工。

`/speckit.plan`

這是技術計劃階段。到了這裡，才開始明確框架、數據庫、架構、API、測試策略和約束。

如果說 /speckit.specify 是產品語言，/speckit.plan 就是工程語言。

`/speckit.tasks`

這一步把計劃拆成可執行任務。好的任務清單應該能讓 Agent 逐步推進，也能讓人類看懂每一步的目的。

`/speckit.implement`

最後才進入實作。Agent 根據前面沉澱的規格、計劃和任務修改代碼。這時它不再是憑一段大 prompt 猜需求，而是在一組結構化文件裡執行。

為什麼它適合 AI 編程？

Spec Kit 的價值不在於某個神奇命令，而在於它把 AI 編程中最容易缺失的東西補了回來：

需求可審查；
計劃可討論；
任務可追蹤；
決策有上下文；
產物可以進入 Git 歷史；
團隊可以複用模板和原則；
Agent 的實作不再只依賴一次性聊天記錄。

這對複雜項目尤其有用。越是多人協作、長期維護、品質要求高的項目，越不能只靠臨時 prompt 驅動開發。

擴展和 Preset

Spec Kit 還提供了兩類自訂能力：

Extensions：增加新命令、新模板或外部工具整合；
Presets：改變現有規格、計劃、任務模板的格式和術語。

簡單理解：如果要新增能力，用 Extension；如果要改造工作流風格，用 Preset。

例如，團隊可以透過 Preset 強制加入安全審查、合規追蹤、領域術語或測試優先規則；也可以透過 Extension 增加 Jira 整合、代碼審查、項目健康檢查等新階段。

這說明 Spec Kit 並不想把所有團隊鎖進同一種流程，而是提供一個可擴展的規格驅動骨架。

適合誰用？

Spec Kit 適合這些場景：

用 AI coding agent 做新項目原型；
想把 vibe coding 變成可複盤流程；
團隊希望統一 AI 生成代碼前的需求和計劃格式；
項目需要明確驗收標準和測試要求；
希望把需求、計劃、任務和實作過程都納入版本管理；
正在探索 GitHub Copilot、Claude Code、Codex CLI 等工具的團隊化用法。

它不一定適合非常小的一次性腳本。對於幾行代碼能解決的問題，完整規格流程可能顯得重。但只要任務開始涉及多個頁面、多個模組、狀態管理、權限、數據模型或長期維護，Spec Kit 的結構化收益就會變明顯。

我的理解

Spec Kit 代表的是 AI 編程工具的一種重要轉向：從「讓 Agent 更快寫代碼」，轉向「讓 Agent 更可靠地參與軟件工程」。

過去的 AI 編程關注提示詞和模型能力，Spec Kit 更關注流程、產物和約束。它提醒我們：AI 寫代碼越快，規格、計劃和驗收就越不能省。

如果你已經習慣讓 AI 直接實作功能，可以嘗試用 Spec Kit 改變起手式：

先讓 AI 幫你把需求寫成規格，再讓它寫代碼。

這一步看似變慢，實際是在減少後面「代碼寫完了，但不是我想要的」的返工。

參考連結

github/spec-kit

oh-my-pi 是什麼？一個把終端機、IDE 和除錯器打通的 AI 程式設計助手

Sat, 23 May 2026 19:02:20 +0800

oh-my-pi 是一個面向終端機和編輯器的 AI Coding Agent。它來自 Mario Zechner 的 Pi 專案分支，由 can1357 繼續擴展，目標不是只做一個命令列聊天介面，而是把檔案讀取、程式碼搜尋、結構化編輯、LSP、除錯器、瀏覽器、子代理和多模型提供商接到同一個編程工作流裡。

從專案 README 來看，它更像一套 AI 編程工具底座：終端機裡可以直接互動，編輯器可以透過 ACP 接入，Node 專案也可以透過 SDK 嵌入。對已經在用 Claude Code、Codex CLI、Cline、Cursor 或其他 Agent 工具的人來說，oh-my-pi 值得關注的地方在於它把很多原本分散在外部工具裡的能力做成了內建工具面。

它主要解決什麼問題

很多 AI 編程工具的短板不在模型本身，而在工具介面。模型想改程式碼時，如果只能拿到粗糙的全文、脆弱的字串替換和一次性的 shell，失敗率就會被工具鏈放大。

oh-my-pi 的思路是把這些常見摩擦點壓低：

讀取檔案時優先給結構化摘要，而不是把整份檔案塞進上下文。
搜尋、glob、find、語法高亮、token 計數等能力盡量放進原生實作，減少對外部命令的依賴。
寫程式碼時接入 LSP，讓重新命名、引用查找、檔案移動更接近 IDE 行為。
除錯時接入 lldb、dlv、debugpy 等 DAP 工具，而不是只靠日誌和猜測。
複雜任務可以拆給子代理，並用結構化結果返回。
對編輯操作使用內容錨點和預覽機制，降低錯誤 patch 直接落盤的機率。

這些設計說明它關注的不是「模型會不會回答」，而是「模型能不能穩定完成一次真實程式碼修改」。

安裝方式

專案提供了幾種安裝入口。macOS 和 Linux 可以使用安裝腳本：

`1`	`curl -fsSL https://omp.sh/install \| sh`

如果使用 Bun，官方推薦全域安裝 npm 套件：

`1`	`bun install -g @oh-my-pi/pi-coding-agent`

Windows PowerShell 可以使用：

`1`	`irm https://omp.sh/install.ps1 \| iex`

專案 README 還提到可以透過 mise 固定版本：

`1`	`mise use -g github:can1357/oh-my-pi`

安裝前要注意 Bun 版本要求。README 中標註的平台範圍包括 macOS、Linux、Windows，並要求 bun >= 1.3.14。

值得關注的能力

1. 工具呼叫不只停留在 shell

oh-my-pi 內建了檔案讀取、搜尋、寫入、編輯、AST 編輯、瀏覽器、任務拆分、除錯、LSP 等工具。README 中提到它有 32 個內建工具、13 個 LSP 操作和 27 個 DAP 操作。

這意味著 Agent 不必把所有事情都包裝成命令列輸出。比如查引用可以走 LSP，讀 PR 或 issue 可以走統一的檔案式介面，網頁和 PDF 可以被轉換成帶連結結構的 Markdown，再交給模型處理。

2. LSP 接入更適合真實程式碼庫

對大型專案來說，重新命名和移動檔案最怕漏掉 re-export、別名匯入、barrel file 或跨目錄引用。oh-my-pi 的 README 特別強調寫入路徑會接入 LSP，例如檔案重新命名會經過 workspace/willRenameFiles，讓編輯更接近 IDE 的語意操作。

這類能力適合 TypeScript、Rust、Go、Python 等專案裡的日常重構，尤其是那些「手動改能改，但很容易漏一個引用」的場景。

3. 除錯器是一級工具

很多 AI 編程流程遇到崩潰時，仍然停留在加日誌、重新執行、再讀輸出。oh-my-pi 把 DAP 除錯器接入工具面，README 裡舉了 C 程式用 lldb、Go 服務用 dlv、Python 行程用 debugpy 的例子。

這會改變 Agent 處理 bug 的方式：它可以暫停行程、查看堆疊框架、讀局部變數，再決定下一步，而不是只靠錯誤文字猜測。

4. Hashline 編輯降低 patch 失敗率

專案強調的 Hashline 是一種基於內容錨點的編輯方式。它的目標是讓模型指向要修改的內容錨點，而不是反覆輸出大段 diff。這樣做的好處是減少空格、上下文過期、字串匹配失敗造成的編輯錯誤。

對 Agent 工具來說，這類機制很重要。模型能力再強，如果寫入介面經常失敗，最終體驗仍然會變成反覆重試。

5. 子代理和工作區隔離

README 中介紹了 task 子代理能力：一個任務可以拆給多個隔離 worker，結果再以結構化物件返回。專案還包含工作區隔離相關實作，用來支援並行任務、分支探索和避免互相覆蓋。

這適合程式碼審查、遷移、批量修復、測試定位等任務。真正的價值不只是「並行更快」，而是讓不同探索路徑之間的上下文和檔案改動更清楚。

6. 相容已有規則和配置

oh-my-pi 首次執行時會讀取已有工具留下的規則和配置，包括 .claude、.cursor、.windsurf、.gemini、.codex、.cline、.github/copilot 和 .vscode 等目錄。

這點很實用。很多團隊已經為不同 AI 工具寫過規則，如果每換一個工具都要遷移一遍，成本會很高。oh-my-pi 的做法是盡量直接繼承已有上下文。

四種入口

專案提供了四類使用入口：

互動式 TUI：在終端機裡直接執行 omp。
一次性命令：用 omp -p 發送單次 prompt。
Node SDK：透過 @oh-my-pi/pi-coding-agent 嵌入到 Node 或 TypeScript 專案。
RPC / ACP：透過 stdio 或 Agent Client Protocol 接入其他程式和編輯器。

這說明它不只面向個人終端使用者，也給 IDE、插件、自動化平台和內部工具留了整合空間。

適合誰嘗試

oh-my-pi 比較適合這幾類使用者：

經常在終端機裡做程式碼修改、除錯和審查的人。
已經在使用 AI Coding Agent，但覺得檔案讀取、patch、搜尋或除錯鏈路不夠穩的人。
想把 Agent 接入編輯器、RPC 或 Node 服務的開發者。
需要在一個工具裡切換多模型和多提供商的人。
對 LSP、DAP、AST 編輯和子代理這些底層能力感興趣的工具開發者。

如果只是想要一個開箱即用的聊天式程式碼助手，學習成本可能會偏高。它更適合願意理解工具鏈，並把 Agent 當成可配置開發環境的人。

使用時要注意什麼

第一，oh-my-pi 仍然是快速演進中的開源專案。倉庫提交頻繁，issue 和 PR 數量也不少，安裝和使用時要預期到變化。

第二，它的能力邊界和本地環境強相關。LSP、除錯器、Bun、模型提供商認證、終端環境、Windows 或 Unix 差異都會影響體驗。

第三，內建工具多不等於每個場景都應該全開。實際使用時更適合按任務啟用需要的工具，把規則、權限和工作區邊界配置清楚。

第四，AI Agent 能寫程式碼，也能誤改程式碼。即使有預覽和錨點編輯機制，重要專案仍然要保留版本控制、測試和人工審查。

小結

oh-my-pi 的亮點不在於又做了一個 AI 終端殼，而在於它把 AI 編程中最容易拖後腿的工具層重新整理了一遍：檔案讀取、搜尋、編輯、LSP、除錯、瀏覽器、子代理和 SDK 都被放進同一個 Agent 工作流。

它適合關注 AI 編程基礎設施的人，也適合想比較不同 Coding Agent 路線的開發者。當前 AI 編程工具的競爭，已經不只是模型回答品質的競爭，也是在比誰能把模型穩定接入真實程式碼庫、真實除錯流程和真實團隊規則。oh-my-pi 正是在這個方向上給出了一套很激進的開源實作。

參考資料：

GitHub 專案：https://github.com/can1357/oh-my-pi
官方站點：https://omp.sh/
SDK 文件：https://omp.sh/docs/sdk

poc-lab 補丁驗證：確認你的系統中近期高危漏洞是否已修復，涵蓋 Chrome CSSFontFeatureValuesMap UAF、NGINX Rift、Dirty Frag、Fragnesia

Fri, 22 May 2026 23:13:24 +0800

poc-lab 是一個面向近期高嚴重性漏洞的 PoC 與復現腳本倉庫，重點收集新披露、有影響力的 CVE 復現材料。專案覆蓋範圍包括 Linux 核心、Windows、macOS、容器、服務元件和瀏覽器相關漏洞。

從倉庫定位看，它更像是一個安全研究資料庫，而不是面向普通使用者的一鍵工具合集。每個漏洞目錄通常會包含 PoC 腳本、建置檔案和說明文件，用來幫助研究人員理解漏洞影響、復現條件和參考資料。

專案主要內容

倉庫目前按照漏洞編號或漏洞名稱組織目錄。已經列出的完整漏洞名稱包括：

CVE-2026-2441：Chrome CSSFontFeatureValuesMap use-after-free，簡稱 Chrome CSSFontFeatureValuesMap UAF。
CVE-2026-27623：Pre-Authentication Denial of Service from malformed RESP request，即畸形 RESP 請求導致的預認證拒絕服務漏洞。
CVE-2026-31429：Slab Cross-Cache，Linux 核心 slab 跨快取利用方向漏洞。
CVE-2026-31431：Copy Fail，Linux 核心相關漏洞。
CVE-2026-31635：DirtyDecrypt，系統安全邊界相關漏洞。
CVE-2026-42945：NGINX Rift，NGINX 相關高危漏洞。
CVE-2026-43284：Dirty Frag，Linux 核心相關漏洞。
CVE-2026-43494：PinTheft，權限或憑證安全邊界相關漏洞。
CVE-2026-43500：Dirty Frag，Linux 核心相關漏洞。
CVE-2026-46300：Fragnesia，Linux 核心相關漏洞。
CVE-2026-46333：SSH Keysign pwn，SSH keysign 安全邊界相關漏洞。

這些名稱可以看出，專案關注的不只是單一平台，而是橫跨瀏覽器、Linux 核心、服務端元件和系統安全邊界。對做漏洞分析、補丁驗證、偵測規則編寫和安全課程實驗的人來說，這類資料有一定參考價值。

目錄結構

專案 README 中說明，每個漏洞目錄會盡量保持一致結構。常見檔案包括：

exploit.py 或 exploit.sh：PoC 腳本
README.md：漏洞資訊、受影響版本、復現步驟和參考資料
build 或相關建置檔案：用於編譯或準備復現環境

倉庫結構大致如下：

poc-lab/
├── CVE-2026-XXXXX/
│   ├── exploit
│   ├── build
│   └── README.md
├── VULN-NAME/
│   ├── exploit.sh
│   └── README.md
└── ...

如果漏洞已經分配 CVE 編號，目錄會優先使用 CVE 命名；如果還沒有 CVE，則可能使用公開漏洞名稱。

適合哪些場景

這類倉庫更適合以下用途：

安全研究人員復現漏洞觸發條件。
企業安全團隊驗證補丁是否生效。
偵測工程師編寫 IDS、EDR、WAF 或日誌偵測規則。
安全課程或內部培訓中建構隔離實驗環境。
研究人員對比不同漏洞的利用前提和防護思路。

它不適合直接用於生產環境掃描，也不應該用於未授權系統。PoC 的價值在於幫助理解風險和驗證防護，而不是擴大攻擊面。

使用時需要注意什麼

第一，必須在隔離環境中測試。漏洞復現可能觸發崩潰、權限變化、檔案損壞或服務不可用，不應在辦公機、生產伺服器或第三方系統上直接運行。

第二，要先閱讀每個漏洞目錄內的 README.md。不同 PoC 的依賴、目標版本、觸發條件和風險不同，只看根目錄說明遠遠不夠。

第三，要確認授權邊界。即便只是運行公開 PoC，只要目標系統不屬於自己或沒有明確授權，就可能帶來法律和合規風險。

第四，復現完成後應回到防護層面。包括確認補丁版本、補充偵測規則、檢查暴露面、更新資產清單和沉澱應急流程。

為什麼這類倉庫值得關注

近年來，高危漏洞從披露到出現公開利用細節的時間越來越短。對防守方來說，只有安全公告和 CVE 描述通常不夠，還需要理解漏洞在真實環境中的觸發條件、利用限制和偵測訊號。

poc-lab 這類倉庫的意義在於，把分散的高危漏洞復現材料按目錄整理起來，讓研究者能更快完成風險驗證。它不替代官方公告、廠商補丁和安全基線，但可以作為補丁驗證和偵測工程的補充資料。

不過也要看到風險：公開 PoC 會降低復現門檻。如果組織內部沒有及時補丁管理和資產梳理能力，公開復現材料可能會放大暴露窗口。因此，對企業安全團隊來說，關注這類專案的同時，更重要的是建立快速評估和修復流程。

小結

poc-lab 是一個近期高危漏洞 PoC 與復現腳本集合，覆蓋 Linux 核心、瀏覽器、服務元件和系統安全相關問題。它適合安全研究、補丁驗證和偵測規則開發，但必須放在授權、隔離和負責任披露的邊界內使用。

對普通讀者來說，關注這類專案的重點不是「怎麼運行 PoC」，而是理解一個事實：高危漏洞公開後的驗證和利用節奏正在加快，安全團隊需要更快完成資產識別、補丁評估、偵測補充和風險閉環。

參考資料：

GitHub 專案：https://github.com/Unclecheng-li/poc-lab/tree/main
中文 README：https://github.com/Unclecheng-li/poc-lab/blob/main/README.zh-CN.md

GitHub AI 開源專案分類整理：從 Coding Agent 到 RAG 知識庫

Thu, 21 May 2026 08:53:13 +0800

這裡按應用方向列出 GitHub AI 專案，覆蓋 AI 程式設計與 Coding Agent、Agent 技能與工作流、RAG 與知識庫、多模態創作、本地模型與推理、垂直應用與自動化、AI 應用開發基礎設施等方向。後續新增專案時，也可以繼續按這個結構補充。

分類合計

分類	專案數	適合先看的人
AI程式設計與 Coding Agent	22	經常使用 Claude Code、Codex、Cursor、終端 Agent 或程式碼庫自動化的人
Agent 技能與工作流	7	想把 AI 程式設計、科研、創作流程標準化的人
RAG、知識庫與記憶	7	需要文件檢索、知識庫、長期記憶、網頁抓取和結構化抽取的人
垂直應用與自動化	7	想看金融、交易、閒魚監控、桌面操作、瀏覽器自動化等落地場景的人
多模態與內容創作	5	做圖片、影片、語音轉寫、提示詞庫和內容分發的人
AI 應用開發基礎設施	5	構建 AI 應用、瀏覽器自動化、Prompt/MCP 工具鏈的人
本地模型與推理	1	關心本地 DeepSeek、推理引擎和硬體適配的人

這個分佈可以看出當前 AI 開源專案的幾個高頻方向：AI 程式設計工具明顯最多，其次是 Agent 工作流、RAG 知識庫和具體應用場景。純模型推理專案數量不多，因為很多本地部署內容並不是單獨介紹某個 GitHub 專案，而是圍繞模型、顯示卡或部署方案展開。

AI程式設計與 Coding Agent

這一類聚焦程式碼理解、程式碼修改、工程流程和終端 Agent，是數量最多的一組。共 22 個專案。

專案	文章	GitHub	核心用途	適合人群
Ralph	Ralph 是什麼：把 Claude Code 和 Amp 變成可迴圈執行的自主開發流程	snarktank/ralph	讓 Claude Code / Amp 按 PRD、計劃、執行、評審迴圈推進任務	想把 Agent 程式設計流程拉直的人
Claude-Mem	Claude-Mem：給 Claude Code 加上跨會話長期記憶	thedotmack/claude-mem	為 Claude Code 增加跨會話記憶	高頻使用 Claude Code 的開發者
Claude Code Hooks Mastery	Claude Code Hooks Mastery：13 個 Hooks 生命週期與自動化控制入門	disler/claude-code-hooks-mastery	學習 Claude Code Hooks 生命週期和自動化控制	想定製 Claude Code 流程的人
Compound Engineering Plugin	Compound Engineering Plugin：把 AI 程式設計變成計劃、執行、評審的工程迴圈	EveryInc/compound-engineering-plugin	把 AI 程式設計拆成計劃、執行、評審迴圈	關注工程化 AI 程式設計的人
free-claude-code	free-claude-code：用代理把 Claude Code 接到 OpenRouter、DeepSeek 和本地模型	Alishahryar1/free-claude-code	透過代理把 Claude Code 接到不同模型後端	想降低 Claude Code 使用成本的人
Hermes Agent	Hermes Agent 是什麼：簡介、優點、快速上手與 OpenClaw 對比	NousResearch/hermes-agent	本地 Agent 框架，支援工具呼叫和任務執行	想跑本地 Agent 的使用者
OpenHarness	OpenHarness 是什麼：這個開源 Agent Harness 能做什麼	HKUDS/OpenHarness	Agent Harness 與多 Agent 執行框架	研究 Agent 編排的人
CodexBridge	Codex 怎麼接入國產大模型？OpenAI 相容介面與 CodexBridge 使用思路	begonia599/CodexBridge	幫 Codex 接入 OpenAI 相容模型介面	想把 Codex 接到國產模型的人
ccx	Codex 怎麼接入國產大模型？用 CCX 統一管理 OpenAI 相容 API	BenedictKing/ccx	統一管理 Claude、Codex、Gemini 等 API 代理	多模型切換使用者
cc-haha	cc-haha 是什麼？一個把 Claude Code 做成桌面工作臺的專案	NanmiCoder/cc-haha	Claude Code 桌面工作臺與 Computer Use 入口	喜歡圖形介面的 Claude Code 使用者
DeepSeek-TUI	DeepSeek-TUI：把 DeepSeek V4 變成終端裡的程式設計智慧體	Hmbown/DeepSeek-TUI	在終端裡執行 DeepSeek 程式設計 Agent	DeepSeek 與命令列使用者
Open Design	Open Design 專案解析：把 Claude Code、Codex 變成 AI 設計工具	nexu-io/open-design	讓 Claude Code / Codex 參與設計生成	想用 Agent 做設計原型的人
agentmemory	agentmemory 專案解析：給 Claude Code、Codex 和 Cursor 加持久記憶	rohitg00/agentmemory	給 Coding Agent 增加持久記憶層	長期維護專案的開發者
Graphify	Graphify 解決 Claude Code 最大侷限：把程式碼庫變成 AI 可查詢知識圖譜	safishamsi/graphify	把程式碼庫轉成知識圖譜，降低 Agent 重複讀檔案成本	大型程式碼庫使用者
oh-my-pi	oh-my-pi 是什麼？一個把終端、IDE 和偵錯器打通的 AI 編程助手	can1357/oh-my-pi	把終端、IDE、LSP 和偵錯器連接起來，作為本機 AI 編程控制台	想把命令列和 IDE 工作流打通的開發者
Claude Plugins Official	Claude Code 也有外掛市場了：能裝什麼、怎麼裝、要注意什麼	anthropics/claude-plugins-official	Claude Code 官方外掛目錄和安裝入口	想給 Claude Code 擴展能力的使用者
CodeGraph	CodeGraph 是什麼？給 Claude Code、Codex 和 Cursor 加一個本機程式碼地圖	colbymchenry/codegraph	為程式碼庫生成本機索引和關係圖，幫助 Coding Agent 理解專案	維護中大型程式碼庫的開發者
CC Switch	CC Switch：一個桌面工具統一管理 Claude Code、Codex、Gemini CLI 和 OpenClaw	farion1231/cc-switch	管理多個 AI CLI 工具和賬號/配置切換	同時使用多套 CLI 的人
Warp	Warp 開源：從終端到 Agentic Development Environment	warpdotdev/warp	Agentic 終端與開發環境	終端重度使用者
opencode	opencode、Claude Code、Codex 有什麼區別？開源 AI 程式設計工具使用指南	anomalyco/opencode	開源 AI 程式設計 Agent	想找 Claude Code / Codex 替代品的人
9Router	9Router：把 Claude Code、Codex、Cursor 接到同一個 AI 路由器	decolua/9router	AI 程式設計模型路由與 token 成本控制	多工具、多模型使用者
goose	goose：桌面端、CLI 和 API 一體的開源 AI Agent	aaif-goose/goose	桌面、CLI、API 一體的開源 Agent	想要通用 Agent 工作臺的人

Agent 技能與工作流

這一類更關注把 AI 能力固化成可重複的技能、流程和規格。共 7 個專案。

專案	文章	GitHub	核心用途	適合人群
mattpocock/skills	拒絕 Vibe Coding：Matt Pocock 的 skills 倉庫給 AI 程式設計補上工程約束	mattpocock/skills	用 Skills 約束 AI 程式設計流程	想給 Agent 加工程規範的人
Superpowers	Superpowers：把 Coding Agent 拉回工程流程的技能框架	obra/superpowers	Agentic skills framework 與軟體開發方法論	想系統化使用 Coding Agent 的人
Prompt-Vault	Prompt-Vault：一個適合測試 AI 程式設計能力的 Prompt 規格庫	w512/Prompt-Vault	收集可測試 AI 程式設計能力的 prompt 規格	做模型/工具評測的人
web-video-presentation	web-video-presentation：把文章做成可錄屏網頁影片的 Agent Skill	ConardLi/garden-skills	把文章轉成可錄屏網頁影片的 Skill	內容創作者和自動化製作使用者
nuwa-skill	nuwa-skill：把“蒸餾一個人”從靈感變成可執行流程	alchaincyf/nuwa-skill	用 Skill 復刻人物表達和思維流程	做風格化 Agent 的人
Scientific Agent Skills	Scientific Agent Skills：把科研工作流交給 AI Agent 的技能庫	K-Dense-AI/scientific-agent-skills	科研工作流 Skill 集合	科研、資料分析和技術寫作使用者
easy-vibe	easy-vibe：給 Vibe Coding 初學者的一張學習地圖	datawhalechina/easy-vibe	Vibe Coding 入門學習地圖	AI 程式設計新手

RAG、知識庫與記憶

這一類主要解決文件檢索、知識庫構建、長期記憶和結構化抽取問題。共 7 個專案。

專案	文章	GitHub	核心用途	適合人群
LangExtract	Google LangExtract：用 LLM 從長文字里抽取結構化資料	google/langextract	從長文字中抽取結構化資訊	做資訊抽取和資料處理的人
qmd	qmd：給 AI Agent 使用的本地 Markdown 文件搜尋工具	tobi/qmd	本地 Markdown 文件搜尋	用 Markdown 管理知識庫的人
Firecrawl	Firecrawl 專案整理：給 AI Agent 用的網頁搜尋、抓取與互動 API	firecrawl/firecrawl	網頁抓取、搜尋和結構化資料入口	做 RAG 和 Agent 資料入口的人
RAGFlow	RAGFlow 專案整理：開源 RAG 引擎的功能與使用方法	infiniflow/ragflow	開源 RAG 引擎	企業知識庫和文件問答使用者
OpenHuman	OpenHuman 速讀：開源個人 AI Agent 的桌面化路線	tinyhumansai/openhuman	本地優先的個人 AI Agent 與記憶層	想整合個人資料的人
OpenKB	OpenKB：把文件編譯成可持續更新的 LLM 知識庫	VectifyAI/OpenKB	把文件編譯成可更新知識庫	文件知識庫維護者
PageIndex	PageIndex 是什麼？不用向量庫的推理式 RAG 文件索引解析	VectifyAI/PageIndex	不依賴向量庫的推理式文件索引	關注 RAG 新路線的人

多模態與內容創作

這一類面向圖片、影片、語音轉寫和內容分發等創作場景。共 5 個專案。

專案	文章	GitHub	核心用途	適合人群
rembg	rembg 專案整理：本地圖片背景移除工具	danielgatis/rembg	本地圖片背景移除	電商、美工和圖片處理使用者
awesome-gpt-image-2-prompts	GPT-Image 2 提示詞寶庫：電商、海報、人像、UI 全收錄	EvoLinkAI/awesome-gpt-image-2-prompts	GPT-Image 2 提示詞和案例庫	AI 繪圖和提示詞使用者
faster-whisper	faster-whisper：更快的 Whisper 轉寫引擎	SYSTRAN/faster-whisper	高效能語音轉文字	做字幕、轉寫和語音處理的人
Pixelle-Video	Pixelle-Video：一句主題生成短影片的開源 AI 引擎	AIDC-AI/Pixelle-Video	一句話生成短影片工作流	短影片和 AIGC 內容創作者
AiToEarn	內容發太多平臺太累？AiToEarn 想用 AI Agent 幫創作者省點事	yikart/AiToEarn	多平臺內容分發與創作者自動化	內容運營和創作者

本地模型與推理

這一類關注本地模型執行和推理實驗，當前數量較少。共 1 個專案。

專案	文章	GitHub	核心用途	適合人群
ds4	本地執行 DeepSeek 4：Antirez ds4 在 Apple Silicon Mac 上的嘗試	antirez/ds4	在 Apple Silicon 上嘗試執行 DeepSeek 4	本地模型和推理實驗使用者

垂直應用與自動化

這一類是把 Agent 或 AI 能力落到金融、交易、瀏覽器、桌面和電商監控等具體場景。共 7 個專案。

專案	文章	GitHub	核心用途	適合人群
TradingAgents-CN	TradingAgents-CN：面向中文使用者的多智慧體金融交易研究框架	hsliuping/TradingAgents-CN	多智慧體金融交易研究框架	量化、金融和 Agent 研究者
FinceptTerminal	FinceptTerminal：開源金融終端、量化研究和 AI Agent 工作臺	Fincept-Corporation/FinceptTerminal	金融終端、量化研究和 AI Agent 工作臺	金融分析和量化使用者
Anthropic financial-services	Anthropic financial-services：把金融 Agent 場景做成可複用模板	anthropics/financial-services	金融服務 Agent 模板	做金融 AI 方案的人
ai-goofish-monitor	ai-goofish-monitor：用 AI 自動盯閒魚商品的開源監控系統	Usagi-org/ai-goofish-monitor	AI 商品監控和閒魚自動化	二手交易監控使用者
CloakBrowser	CloakBrowser 是什麼？給 Playwright 和 Puppeteer 換一個更像真實使用者的瀏覽器	CloakHQ/CloakBrowser	更像真實使用者的瀏覽器自動化環境	瀏覽器自動化和 Agent 操作場景
UI-TARS-desktop	讓 AI 自己操作電腦？UI-TARS-desktop 把桌面、瀏覽器和工具都接了起來	bytedance/UI-TARS-desktop	桌面、瀏覽器和工具操作 Agent	想讓 AI 操作電腦的人
AI-Trader	AI-Trader 是什麼？一個讓 AI Agent 釋出交易訊號、做模擬交易的平臺	HKUDS/AI-Trader	AI Agent 交易訊號和模擬交易平臺	金融 Agent 與交易研究使用者

AI 應用開發基礎設施

這一類提供構建 AI 應用和 Agent 工具鏈所需的基礎元件。共 5 個專案。

專案	文章	GitHub	核心用途	適合人群
Prompt Optimizer	Prompt Optimizer：開源提示詞最佳化、測試與 MCP 工具	linshenkx/prompt-optimizer	提示詞最佳化、測試和 MCP 工具	做 prompt 工程和應用調參的人
Playwright CLI	Playwright CLI 使用入門：安裝、Skills、會話管理與常用命令	microsoft/playwright-cli	面向 coding agent 的瀏覽器自動化 CLI	需要瀏覽器操作能力的 Agent 使用者
Vercel AI SDK	Vercel AI SDK 是什麼？TypeScript 開發者構建 AI 應用的統一工具包	vercel/ai	TypeScript AI 應用開發 SDK	前端和全棧開發者
CLIProxyAPI	CLIProxyAPI：把 Codex、Claude Code、Gemini CLI 統一封裝成 API	router-for-me/CLIProxyAPI	把多個 AI CLI 和 OAuth 登入狀態封裝成相容 API	想統一接入 Codex、Claude Code、Gemini CLI 的使用者
CLIProxyAPI Management Center	CLIProxyAPI Management Center：給 CLIProxyAPI 配一個視覺化管理後台	router-for-me/Cli-Proxy-API-Management-Center	CLIProxyAPI 的 Web 管理介面，管理設定、帳號、日誌和 OAuth	把 CLIProxyAPI 當團隊閘道或帳號池使用的人

別把 API Key 推上 GitHub：AI 寫程式時代的密鑰外洩防坑指南

Sat, 16 May 2026 16:26:50 +0800

AI 寫程式降低了動手門檻，也把很多原本只會發生在工程團隊裡的安全問題，帶到了新手和非工程使用者面前。

最常見的一類事故，是把 API Key、Secret、Token、資料庫連線字串或 .env 設定檔一起推到公開倉庫。對本機專案來說，這些檔案只是「能讓程式跑起來的設定」；一旦進了 GitHub 公開倉庫，它們就變成了可以被自動掃描、自動呼叫、自動濫用的憑證。

密鑰外洩不是小機率事件。GitGuardian 的 2026 年度報告提到，2025 年公共 GitHub 提交裡出現了約 2865 萬個新增硬編碼憑證，AI 服務相關憑證外洩同比成長 81%。這說明問題不只是「有人粗心」，而是 AI 編程、快速原型和公開託管疊加後，外洩規模正在被放大。

為什麼新手更容易外洩 Key

很多 AI Agent 或小工具都有兩套「倉庫」：一套在本機硬碟裡，另一套在 GitHub 上。問題在於，新手經常沒有意識到兩者的邊界。

本機執行時，config.json、.env、settings.yaml 裡放著 API Key，好像只是開發習慣；執行 git add .、git commit、git push 之後，這些檔案就可能被完整上傳。倉庫一旦公開，掃描機器人不需要理解你的業務，只要匹配到密鑰格式，就能把它抓走。

AI 編程還會放大這個問題：

AI 生成範例程式碼時，可能直接把 OPENAI_API_KEY = "sk-..." 這類寫法放進原始碼。
新手為了「先跑起來」，容易把密鑰硬編碼在前端、腳本或設定檔裡。
很多 vibe coding 平台可以直接部署應用，不一定經過 GitHub 的推送保護流程。
使用者可能不知道 AI 生成的專案裡到底有哪些檔案、哪些介面、哪些預設權限。

換句話說，AI 可以幫你更快寫出能跑的東西，但不會自動替你承擔安全責任。

`.gitignore` 不是裝飾

Git 負責版本管理，GitHub 負責託管程式碼，.gitignore 則是告訴 Git 哪些檔案不要納入版本歷史。

一個最基本的 AI 專案，至少應該把這些內容排除掉：

.env
.env.*
*.key
*.pem
config.local.*
secrets.*
credentials.*

但只寫 .gitignore 還不夠。它只能阻止「尚未被 Git 追蹤」的檔案繼續進入提交。如果某個密鑰檔案已經被提交過，後來再把它寫進 .gitignore，並不能把歷史記錄裡的密鑰抹掉。

更穩妥的習慣是：

新專案一開始就建立 .gitignore。
API Key 只放在環境變數或本機設定裡。
範例檔案只提供 .env.example，裡面寫佔位符，不寫真實密鑰。
提交前執行一次密鑰掃描工具，比如 gitleaks、trufflehog 或 GitHub Secret Scanning。

Key 推上去以後，刪除檔案不等於安全

如果密鑰已經推到公開倉庫，第一反應不應該是「刪掉檔案再提交一次」，而應該是立刻吊銷或輪換密鑰。

原因很簡單：Git 記錄的是歷史。即使你在最新提交裡刪除了檔案，舊提交、fork、clone、快取和掃描系統裡仍可能保留那段內容。GitHub 官方文件也明確建議：如果外洩的是密碼、Token 或憑證，第一步應該撤銷或輪換。

處理順序建議這樣做：

立即去服務商後台吊銷舊 Key，生成新 Key。
檢查帳單、呼叫日誌、異常 IP 和異常用量。
從程式碼中移除硬編碼密鑰，改用環境變數或密鑰管理服務。
用 git filter-repo 或 BFG 清理倉庫歷史中的敏感檔案。
開啟 GitHub Secret Scanning 和 Push Protection。
檢查 CI/CD、部署平台、雲函式、前端建置產物裡是否也包含舊 Key。

對於 OpenAI、Anthropic、DeepSeek、雲廠商、支付、郵件、資料庫等服務，外洩 Key 的後果可能不只是被刷額度，還可能包含資料讀取、服務濫用、供應鏈污染或業務帳號封禁。

前端程式碼裡不能放真正的密鑰

很多新手以為「只要頁面能跑就行」，於是把 API Key 寫進前端 JavaScript：

`1`	`const apiKey = "sk-xxxxxxxx";`

這基本等於公開。瀏覽器裡的程式碼、網路請求、Source Map、建置產物都可以被查看。只要是真正需要保密的 Key，就不應該出現在客戶端。

正確做法是讓前端請求自己的後端介面，由後端讀取環境變數並呼叫第三方 API：

// frontend
await fetch("/api/chat", {
  method: "POST",
  body: JSON.stringify({ message })
});

後端再使用環境變數：

1
2

// server
const apiKey = process.env.OPENAI_API_KEY;

這樣做不是為了形式好看，而是為了把密鑰留在伺服器環境裡，避免直接暴露給所有訪問頁面的人。

Vibe Coding 的安全責任不會自動消失

vibe coding 的問題不只是 GitHub 外洩。很多應用直接從 AI 編程平台發布到公網，跳過傳統程式碼審查、倉庫掃描和安全測試。

RedAccess 近期披露的研究顯示，公開網路上可以找到大量由 AI 編程工具生成或託管的應用資產，其中一部分暴露了企業資料、個人資訊或內部檔案。它提醒的是同一件事：當「能上線」變得太容易，「是否應該上線」「是否只該內網訪問」「是否有權限控制」就更容易被忽略。

如果你用 AI 生成應用，至少要在發布前問自己幾個問題：

這個應用是否真的需要公開訪問？
是否有登入、鑑權和權限隔離？
是否把資料庫、API Key、Token、Webhook 地址暴露在前端？
是否限制了第三方 API 的額度、網域、權限和有效期？
是否能在發現異常後快速停用密鑰和回滾部署？

AI 寫出來的程式碼也需要安全審查。越是「我一行程式碼都沒寫」，越不能假設它天然安全。

現在就該做的檢查

可以先從自己的 GitHub 帳號查起。搜尋使用者名稱加上這些關鍵字：

API_KEY
SECRET
TOKEN
OPENAI_API_KEY
ANTHROPIC_API_KEY
DEEPSEEK_API_KEY
.env
config
credentials

如果發現真實密鑰，不要猶豫：先輪換，再清理。只要它進過公開倉庫，就按已經外洩處理。

以後新建 AI 專案時，也建議固定一套流程：

先寫 .gitignore，再寫業務程式碼。
用 .env.example 說明需要哪些變數。
所有密鑰放環境變數，不寫進原始碼。
給 API Key 設定最小權限、額度限制和過期時間。
開啟 GitHub Secret Scanning 和 Push Protection。
發布前讓 AI 再幫你做一次安全檢查，但不要只相信 AI 的結論。

AI 編程真正危險的地方，不是它會寫錯程式碼，而是它讓很多人第一次擁有了把不安全應用快速發布到公網的能力。寫得快不是問題，把密鑰、資料和權限一起交出去才是問題。