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 编程真正危险的地方，不是它会写错代码，而是它让很多人第一次拥有了把不安全应用快速发布到公网的能力。写得快不是问题，把密钥、数据和权限一起交出去才是问题。