项目详情
Awesome
互联网最大的人工策展资源目录
更新于 2026-07-07
← 返回汇总
项目速览
一句话定位
互联网最大的人工策展资源目录
GitHub 上所有 awesome 清单的母清单。本身不收录工具，而是收录指向各领域精选清单(awesome-x)的链接，形成覆盖编程、平台、安全等 27 大类的知识地图。靠严格规范(30天成熟期、互审4个PR、CC0协议、unicorn暗号)和 awesome-lint 自动化维持 630+ 清单质量。GitHub 历史 star 最高仓库之一。
核心数据
规模一览
数据来源：GitHub API（2026-07-07）。482,676 stars，35,752 forks，1,206 commits，30 名贡献者。
为什么存在
它解决的三个问题
信息过载
搜索引擎返回的是「最多链接的」，不是「最好的」。策展清单用人工判断筛掉噪声。
资源分散
某领域的优质工具散落在博客、issue、gist 各处，没有统一入口。
缺乏质量门槛
列表式目录要么「全收录」（变垃圾堆），要么「不维护」（过期失效）。Awesome 用强规范治理。
核心理念
Awesome 宣言
「Only awesome is awesome」——清单是策展（curation），不是收集（collection）。
- 宁缺毋滥：收录前必须亲自验证可用、值得推荐，宁可留空也不滥收
- 说明价值：每个条目必须附带「为什么 awesome」的描述，不能只甩链接
- 主题明确：清单开头必须一句话说清「这个清单是关于什么的」
- 拒绝过期：不允许收录 archived / deprecated / 无文档的项目
治理机制
靠规范维持 630+ 清单质量
| 规范 | 要求 |
|---|
main 分支 | 必须用 main，禁用 master（去奴隶制联想） |
| 命名格式 | 仓库必须 awesome-xxx 小写 slug，标题 Title Case |
| 存活期 | 清单创建满 30 天 才能提交 PR，给成熟时间 |
| 互审义务 | 提交者必须审查至少 4 个其他开放 PR，不能只说「looks good」 |
| 协议 | 强烈推荐 CC0（公有领域），禁用 MIT/Apache/GPL 等代码协议 |
| 禁 AI 生成 | 纯 AI 生成的 PR 和清单一律拒绝 |
| 暗号验证 | PR 中须留言 unicorn 证明读完全部规范 |
架构
三层结构
入口层
awesome（母清单）
27 大类目录，指向 630+ 子清单。一个 readme.md 即全部内容。
分支层
awesome-x 子清单
独立仓库，由领域专家维护。如 awesome-nodejs、awesome-ios、awesome-python。
治理层
规范 + 自动化
manifesto、PR template、awesome-lint、GitHub Actions 机器人共同把关。
母清单本身几乎不含工具，它是索引的索引——真正的策展发生在子清单层。
自动化守门
repo_linter：机器第一道关
每个 PR 先过 .github/workflows/repo_linter.sh，机器检查不通过直接拦下。
检查项
- 链接是否 404 / 死链
- 条目描述格式（首字母大写、句末句号）
- 是否含 CI badge（禁止）
- 是否 hard-wrapping（禁止）
awesome-lint 配套
独立 npm 包（792 stars），子清单维护者本地运行，提交前自检格式与内容规范。
# 子清单维护者本地自检
npx awesome-lint https://github.com/me/awesome-x
27 大类全景
覆盖范围
- Platforms
- Programming Languages
- Front-End Dev
- Back-End Dev
- Computer Science
- Big Data
- Theory
- Books
- Editors
- Gaming
- Dev Environment
- Entertainment
- Databases
- Media
- Learn
- Security
- CMS
- Hardware
- Business
- Work
- Networking
- Decentralized Systems
- Health & Social Science
- Events
- Testing
- Miscellaneous
- Related
从编程语言到健康社会科学，几乎涵盖开发者与求知者会接触的所有技术领域。
生态规模
不只是一个仓库
- awesome- 前缀已成 GitHub 元文化：数万个 awesome-x 仓库以此为模板，形成事实上的「清单协议」
- awesome.re 短链：独立品牌域名，统一所有子清单的 Awesome 徽章回流入口
- 徽章体系：
Awesome 徽章（清单用）+ Mentioned in Awesome 徽章（被收录项目用），双向信用背书
- 连锁治理：母清单规范 → 子清单复制规范 → 子清单收录项目遵守，逐层传递质量标准
快速上手
三种用法
找资源
访问 awesome.re，按分类定位目标领域清单，再深入子清单找工具。
建清单
读 create-list.md，建 awesome-x 仓库，跑 awesome-lint，养 30 天后提 PR。
贡献条目
在子清单 readme 点编辑 → 提 PR，遵循描述格式（首字母大写、句末句号）。
# 入口
访问 awesome.re → 自动跳转 github.com/sindresorhus/awesome
适用场景
适合谁用
- 新手入门某领域：想学 Rust / iOS / 安全，先找对应 awesome 清单当学习地图
- 技术选型：对比某类工具时，清单给出经过筛选的候选，省去自己搜
- 领域专家建影响力：维护一个高质量 awesome-x 清单，是建立技术权威的低成本路径
- 团队知识库种子：内部 wiki 可直接 fork 子清单作为起点
风险与局限
需要警惕
- 收录 ≠ 质量保证：规范保证「曾经 awesome」，但子清单可能后续失修。母清单 2026-06 刚批量删除 17 个 archived 子清单
- 维护瓶颈：Sindre Sorhus 单人主导，PR 积压常见，互审机制也增加时间成本
- 非工具非服务：纯目录，不提供搜索、过滤、订阅功能，630+ 条目靠 Ctrl+F 浏览
- 分类僵化：27 大类固定，跨领域主题（如 AI Agent）难以归位
潜力评估
未来空间
作为策展范式的开创者，它已不可替代。未来挑战在于：如何应对 AI 时代「自动生成清单」的冲击，以及把静态目录升级为可搜索、可订阅的知识服务。