AI 资源库 · 已整理 22 项
查看与GitHub相关的 AI 资讯、工具、Skill、工作流和开源项目。
在旧金山举行的 Universe ’26 大会上，GitHub 管理层回应了平台稳定性问题。他们表示已经增加 400 万核 CPU 和 160 PB 存储，并彻底重构后端基础设施。原因是 AI Agent 的访问方式和人类开发者差别很大，一些原本运行正常的服务出现了意外故障，因此不只是扩容，还要重写核心服务。对于前 CEO Thomas Dohmke 新创办的 GitHub 替代品 Entire，GitHub COO Kyle Daigle 说“世界不需要一个新的 GitHub”，开发者可能只是需要不同的工具。Dohmke 则回应称开发者显然需要新选择。这些投资和调整目前已经公布，但文章没有说明具体上线时间。
GitHub 的提交量涨得极快：2024 年平均每月约 6500 万次，今年 4 月 14 亿次，8 月 29 亿次，9 月已达到 74 亿次，公司称主要推手是 AI Agent 带来的自动化需求。这种增长也让服务频繁出故障，所以 GitHub 今年已增加 400 万个 CPU 核心（多数在 Azure 上）、160 PB 高速存储和 50 Tb/s 网络带宽，并加强 GitHub Actions 算力。同时它正把计算和存储拆开重新架构，内部测试写入吞吐最高提升 35 倍。对开发者的意义是：这轮扩容已在进行，目标是减少卡顿和宕机，但新架构的具体上线时间原文未说明。
GitHub 发布了 2026 年 Octoverse 报告，统计过去一年开发者共向 GitHub 推送代码 179 亿次，超过 2024 和 2025 两年总和；总提交 343 亿次，合并的拉取请求 13 亿个。报告发现，带 Agent 配置的新仓库平均提交次数是不带配置仓库的 8 倍，9 月已有超过 40% 的拉取请求由 Agent 发起（3 月为 17%）。61% 的 Copilot 用户会同时使用多个模型，医疗、农业、采矿、建筑等领域的公开仓库也在快速增长。报告还显示 GitHub 开发者已超 2.25 亿，过去一年活跃开发者平均已在 GitHub 上 36 个月，现在平均每人跨仓库数比一年前多 10%。对读者来说，这份报告描述的是开发者正把 Agent 从试用变成日常协作对象，但具体效果仍取决于各自项目实践。
GitHub 在年度大会 Universe 上宣布，要把 GitHub 打造成覆盖软件开发全流程的端到端平台。过去开发者主要写代码，现在则越来越多地让 AI 助手和 Agent 承担实现与验证工作，问题在于多模型、多工具、多仓库之间切换繁琐，代码变多后审查压力也增大。这次 GitHub 推出面向 Agent 的 Copilot 应用、能自动挑选和执行模型的 Copilot Fusion、可跨多个仓库并行运行的 Copilot projects，以及能在手机、VS Code、命令行和网页间接续的会话同步，还有能根据运行结果自我改进的自动化流程。此外，企业客户无需再单独购买 Copilot 订阅，按使用的 AI 额度付费即可。对普通开发者来说，这意味着可以把更多执行环节交给 Agent，自己专注于方向和决策。
GitHub 漏洞赏金团队在网络安全意识月采访了研究员 @r31n。他专门研究 GitHub Enterprise Server，多次发现高危问题，报告里都附带可用的概念验证和清晰的复现步骤，让工程团队能更快定位并修复。他说自己偏爱把几个看似无害的小问题串成完整攻击链，比如一个开放重定向配上会跟随跳转的 SSRF。日常学习靠安全博客、漏洞分析和会议演讲，但真正掌握要靠亲手复现。他认为 AI 降低了入门门槛，也确实是效率放大器，但决定研究质量的是验证和真实影响，而不是工具。
提供的材料未提及具体可用工具。
GitHub 把 99.99999% 的仓库复制到了 Azure，但最繁忙的那一小部分仓库因为跨区域往返一次约 25 毫秒而搬不过去。原来的写入会锁住整个仓库，一次只能处理一个写入，最慢的副本拖慢了所有写入。现在 GitHub 把锁的范围从整个仓库缩小到单个引用（如分支），不同分支的写入可以同时进行，内部测试中写入吞吐提升了 3 到 4 倍。接下来，等数据都存进 Azure Blob Storage，读取就能和写入分开扩容，读者日常拉取代码时有望更快、高峰期也不容易被写入挤占。这一改动是已公布的架构演进，具体全面上线时间文中未说明。
提供的材料未提及具体可用工具。
GitHub 过去要查看一个仓库的星标增长曲线，工具必须一页页拉取「谁点了星」的名单，每次最多 100 人，像 react/react 这样有约 25.1 万星的仓库要发约 2511 次请求。名单里带着用户名，容易被批量抓去发垃圾邮件和钓鱼，而且数据库每次请求还要数一遍全部星标来算页数，导致很多查询变慢甚至超时。现在 GitHub 新增了一个接口，一次请求就能返回最多 30 周的每日星标数，不带任何用户身份，做法是先在时间上过滤再统计，而不是先查全部再筛。对维护者来说，比较发布前后热度变化会快很多，也少了对隐私和数据库的负担。
GitHub 把 Copilot 运行时的 80 多万行代码，从 TypeScript 和 Node.js 换成了 Rust。Rust 是一种运行更快、更省内存的编程语言。他们没停下来重写，而是边跑边换：先用 N-API 让新旧代码互通，再配合自动测试和人工检查，分 128 次小改动逐步完成，大约花了 14.5 周，期间正常发布版本。对用户来说，Copilot 后端未来可能更快更稳；不过文章只提到迁移过程，没有说明实际性能提升了多少。
GitHub 的漏洞赏金团队为了庆祝网络安全意识月，专门介绍了他们赏金计划里的一位顶尖安全研究员 @vaib25vicky。他平时的工作，就是像普通用户一样去使用 GitHub 的各种功能，然后琢磨这些功能哪里可能被坏人利用。他特别擅长找和“权限控制”有关的漏洞，这次分享了他挑目标功能、验证漏洞的方法，也提到会用 AI 当助手，但强调 AI 给出的结果必须自己亲自验证过才能提交。对读者来说，这让人了解白帽黑客是怎么帮平台提前发现并修好漏洞、让大家的代码更安全的，也顺便知道了 GitHub 调整赏金规则、设了只邀请顶尖研究员的 VIP 计划，最高奖金能到三万美元甚至更多。
GitHub 发布数据称，如今每三个 pull request 中就有一个涉及 AI 智能体，而一年前不到十分之一；代码产出在加速，但泄露的密钥平均要等约 40 天才被人工撤销，五分之一甚至超过 90 天。为解决这个“开发快、修复慢”的失衡，GitHub 与 Microsoft Applied Sciences 合作训练了一个分类器，能在不到两毫秒内判断一组候选密钥，把推送保护扩展到没有固定格式的密钥，有望让可拦截的密钥数量翻倍以上。对开发者来说，更多密钥会在进入仓库历史前被自动拦下，少一些事后手动补救的麻烦。目前该模型的具体上线时间和可用范围，原文尚未说明。
提供的材料未提及具体可用工具。
GitHub 正在一边保持线上服务运行，一边重建它的 Git 底层存储系统。过去每个仓库都在多台文件服务器上保存完整副本，加副本能加快读取，但每次写入也要同步所有副本，于是读扩展越多、写就越慢，难以承受成千上万个 AI 智能体并发提交。新架构的目标是把“数据持久保存”和“读取扩容”拆开，让写入不再被最慢的副本拖累。对普通开发者的直接好处是更快的推送、克隆和 CI，尤其是每天产生海量提交的仓库；目前这还只是重建工作的介绍，没有说明具体上线时间、迁移步骤和性能数据。
提供的材料未提及具体可用工具。
GitHub 推出了 ReviewBench，一个用来评估 AI 代码审查工具的公开基准。此前，各家 AI 审查工具好坏难分：有的发现问题多但噪音大，有的漏报多，团队缺少统一标准来判断谁更适合自己。ReviewBench 参考了 GitHub 上超过 1 亿个真实 PR 的语言和规模分布，挑选了 19 种语言的 219 个公开 PR，用人工审查、前沿大模型和静态分析共同构建“标准答案”，并按严重程度和类别打分，衡量准确率和召回率。它还经过资深工程师独立校验，与线上实验方向基本一致，因此开发团队可以用它离线预判改动是否真的能改善用户体验。该基准目前已可直接使用，且开放提交结果。
GitHub 周四公测了 Copilot 的“computer use”功能：Copilot CLI 和桌面应用现在能像人一样操作 macOS 和 Windows 上的软件，能读屏幕内容，也能点击、打字、滚动和拖拽，连那些没有接口、只能靠图形界面操作的老软件也能用。但 GitHub 自己建议：如果任务能用 API、MCP 服务器、终端命令或专门浏览器工具完成，就优先用它们，因为那样结果更可靠。这项功能目前在公测阶段，需要手动开启，macOS 上还要单独授予辅助功能和屏幕录制权限；敏感窗口内容可能被智能体读到，企业管理员也可用策略限制。
GitHub 安全实验室做了一个开源 AI 工具，叫“任务流智能体”。它把安全研究员平时查漏洞的步骤拆成小提示，让 AI 按步骤检查安卓应用。安卓应用常有一些特殊漏洞，比如外部应用乱传参数、偷偷导入设置，AI 一开始容易漏掉。作者因此针对性写了两套任务流：一套先分清哪些入口能被外部调用，另一套列出常见漏洞类型逐项核对。跑了这些流程后，他们已在多个安卓应用里报告了 24 个漏洞，其中 OsmAnd 的导出页面可被其他应用恶搞设置、偷看位置。任何人都能运行这套开源流程，但需要 GitHub Copilot 许可证，还会消耗大量令牌，中等仓库跑一次可能一两小时。
Jimboocher3373/CopilotWS-Desktop---Copilot-Workspace-2026 · Supercharge development with AI task planning, multi-file editing, PR generation, and Code Review all in one Windows desktop workspace.
CopilotWS-Desktop 是一款面向 Windows 的桌面应用，将 AI 任务规划、多文件编辑、自动生成 Pull Request、Issue 解决方案建议和代码审查整合在同一个工作区中。用户可以用自然语言描述目标，由 AI 生成分步计划，并在编辑多个文件时获得辅助，最后生成 PR；支持连接 GitHub 同步项目，并提供工作区管理与常见问题排查说明。
GitHub 把网站样式的写法从“CSS-in-JS”换成了原生 CSS Modules。原来样式要在浏览器或服务器运行时现场生成，组件一多页面就变慢、更新也难控制。他们先把设计系统 Primer 的组件逐个换掉，用开关控制新旧样式切换、用截图对比确保外观不变，再逐步放量；2024 年 12 月全部换完，页面服务端渲染时间少了 55%，组件初始化时间少了 25%。此后 GitHub 还在继续清理旧写法，让网站更快。
GitHub 安全实验室发布了一个叫 Fuzzing Taskflow 的自动化工具，专门给 C/C++ 项目做模糊测试。模糊测试就是自动给程序喂各种奇怪输入，看能不能把程序搞崩，从而找出安全漏洞。以前这件事很费人：需要人盯着代码覆盖率、手动写测试框架、一个个分析崩溃原因。现在这个工具只要给它一个 GitHub 仓库地址，它就会自己识别关键函数、写测试框架、跑 AFL++、看覆盖率、改进测试、分析崩溃并生成漏洞报告。它不是万能药，复杂项目仍可能需要人工介入，而且必须在一次性环境里运行。
GitHub联合耶鲁气候变化传播项目调查了1039名GitHub用户，想了解他们对软件效率与气候变化的看法。结果发现，八成受访者想要能帮助写出更节能代码的工具，约七成五想测量软件对环境的影响，但63%的人觉得自己写代码对环保影响很小。主要问题不是没兴趣，而是缺少找浪费、量改进、说服维护者的实用路径。调查还建议先找可测量的浪费，用Agent寻找优化机会，但最终决定仍留给维护者。
GitHub把Copilot的底层运行时从TypeScript/Node.js整体改写成了80多万行Rust代码，并且主要让自家的Copilot编程智能体来写代码，由一名开发者主导、几个月完成，拆成128个拉取请求边改边上线。Anthropic收购的Bun也做了类似的事：它原有53万多行Zig代码，长期被内存泄漏和崩溃困扰，创始人用多个Claude智能体并行翻译，11天后Rust版本在六个平台通过原有测试。两家做法不同：Bun是并行快搬，GitHub是慢慢迁移不停产品，但都想说明智能体让过去“养一个团队一两年”的重写变得可行。
github/spec-kit · 💫 Toolkit to help you get started with Spec-Driven Development
Spec Kit 是 GitHub 开源的工具包，用于实践规范驱动开发（Spec-Driven Development）。它提供 Specify CLI，可在项目中初始化规范驱动流程，并生成一组斜杠命令，引导 AI 编程智能体依次完成项目原则建立、需求规范、技术方案、任务拆解、实现与收敛校验。除核心流程外，还提供缺陷修复（assess → fix → test）与想法评估（intake → research → define → shape → decide）等可选的扩展流程，并支持通过扩展、预设和捆绑进行定制。项目支持 30 余种 AI 编程智能体集成。