LaunchRepo简短回答
- 先从仓库本身做起：一个回答“做什么、为什么、怎么开始”的 README、一份许可证、最多 20 个 GitHub 话题，以及一张社交预览图。
- 然后去用户已经在交流的地方：你所用语言或框架的论坛、聊天群或 subreddit。等别人无需注册就能运行时，再发一篇 Show HN。
- 挑一两个合适的 awesome 列表，按照每个列表自己的贡献规则，向维护者提出收录请求。
- 把网站或在线托管版本提交到几个目录站和发布平台，并持续发布新版本。稳定的活跃度会不断带来新访客。
开源项目的推广地图
开源项目被发现的途径分为四层。每一层都建立在前一层之上：社区帖子把人带到你的仓库，所以仓库必须先说服他们。
- 1 · 仓库每位访客最先看到的东西。
- README
- 许可证
- 话题
- 社交预览
- 版本发布
- 2 · GitHub 内的发现别人在 GitHub 内找到你的方式。
- 话题页
- GitHub 搜索
- Explore
- Star 和列表
- 3 · 社区用户已经在交流的地方。
- Show HN
- 生态论坛和聊天群
- subreddit
- 问答回复
- 4 · 精选与收录会持续指向你的地方。
- awesome 列表
- 包管理仓库
- 目录站
- 技术周刊
制定你的四周计划
回答八个问题，再粘贴你的话题。生成器会按 GitHub 的规则检查这些话题，把每个渠道安排到某一周，并标明是已就绪还是需要先修复什么。一切都在你的浏览器中运行，不会发送或保存任何内容。
让仓库容易被找到
本页的每个渠道最终都会把人带到你的仓库页面。GitHub 自己的文档写明了 README 应该回答哪些问题；下表把它们变成了首屏上的具体内容。
| 部分 | 访客需要什么 | 有效做法 |
|---|---|---|
| 它做什么 | 几秒钟内判断它是否适合自己的问题 | 标题下方一句话，用用户搜索时会用的词 |
| 为什么有用 | 选择它而不是常见替代方案的理由 | 一个具体的差异，或一个简短的对比 |
| 怎么开始 | 几分钟内获得第一次成功 | 一条安装命令，加一个粘贴即可运行的最小示例 |
| 展示运行效果 | 安装前就能看到证据 | 在靠前位置放截图、GIF 或终端录屏 |
| 去哪里求助 | 相信自己不会被晾在一边 | 链接 Issues、Discussions 或聊天群，并说明什么问题去哪里 |
| 谁在维护 | 确信项目仍然活跃 | 维护者、最近的版本、贡献指南 |
话题：最多 20 个通往 GitHub 搜索的入口
- 混合使用 GitHub 建议的四类话题：用途（cli、static-site-generator）、领域（accessibility）、社区（hacktoberfest）和语言（rust）。
- 使用大家真正会浏览的话题。打开 github.com/topics/，确认该话题下已经有仓库。
- GitHub 也会为公开仓库推荐话题。接受合适的，拒绝其余的。
社交预览
没有预览图时，分享出去的链接只会显示仓库的基本信息和你的头像。一张清晰的 1280 × 640 图片，写上项目名称和一句用途说明，能让每次分享都一眼就被认出来。上传前，可以先用免费的图片尺寸检查工具确认尺寸和格式。 按各平台尺寸规范检查你的发布图片 →
| 规则 | 官方原文 | 对你意味着什么 |
|---|---|---|
| README | A README is often the first item a visitor will see when visiting your repository. | 把 README 当作你的落地页：首屏决定了别人会不会留下来。 |
| README 大小 | When your README is viewed on GitHub, any content beyond 500 KiB will be truncated. | 过长的 README 会被截断。把深入的参考资料移到文档里，再加上链接。 |
| 话题类型 | Helpful topics to classify a repository include the repository's intended purpose, subject area, community, or language. | 从用途、领域、社区和语言中分别挑选话题，而不是同一个词的十种变体。 |
| 话题格式 | Use lowercase letters, numbers, and hyphens. Use 50 characters or less. Add no more than 20 topics. | 计划生成器中的检查器正是按这三条规则执行的。 |
| 社交预览 | Your image should be a PNG, JPG, or GIF file under 1 MB in size. For the best quality rendering, we recommend a size of at least 640 by 320 pixels (1280 by 640 pixels for best display). | 准备一张 1280 × 640、小于 1 MB 的 PNG 或 JPG 图片。 |
| 社区资料 | The community profile checklist checks to see if a project includes recommended community health files, such as README, CODE_OF_CONDUCT, LICENSE, or CONTRIBUTING, in a supported location. | 在你的仓库中打开 Insights → Community Standards，补上缺少的内容。 |
awesome 列表：两条不同的路线
awesome 列表是 GitHub 上的精选合集，每个主题一个。常被引用的那些规则，比如 30 天和四次评审，只适用于一种特定情况。先弄清楚你走的是哪条路线。
路线 A：把你的项目加入某个主题列表
对于库、工具或应用来说，这是常见情况。为你的主题找到一两个活跃的列表，阅读该列表的贡献文件，并按它的格式提议添加一行。各个列表接受的内容不同，所以它们自己的指南就是规则。真正能说服维护者的，是你的 README、许可证和近期的活跃度。
路线 B：把你的精选列表加入 awesome 元列表
只有当你自己维护一个列表时才适用。这时要遵守元列表严格的模板：至少已存在 30 天、评审 4 个其他未合并的拉取请求、运行 awesome-lint、使用 Creative Commons 许可证、添加 awesome 和 awesome-list 话题，以及“Add Name of List”格式的标题。
| 规则 | 官方原文 | 对你意味着什么 |
|---|---|---|
| 加入列表 | If you have something awesome to contribute to an awesome list, this is how you do it. | 每个列表都会说明自己的收录方式。请阅读该列表的贡献指南，而不是通用指南。 |
| 列表时长 | That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent. | 仅适用于想加入 awesome 元列表的列表：从第一次实质性提交起等待 30 天。 |
| 评审 | Just commenting “looks good” or simply marking the pull request as approved does not count! | 向元列表提交的人必须评审至少 4 个其他未合并的拉取请求，并给出真正的反馈。 |
| AI | Fully AI-generated pull requests are not accepted. | 亲自撰写拉取请求。完全由 AI 生成的会被关闭。 |
| 许可证 | A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. | 列表需要 Creative Commons 许可证，推荐 CC0。代码许可证不算数。 |
| 质量 | Only has awesome items. Awesome lists are curations of the best, not everything. | 列表只收录最好的，而不是所有东西。让你入选的是你的 README 和活跃度。 |
我们引用的是核查日期当时的规则，维护者会更新它们。LaunchRepo 不会替你提交拉取请求，也不会替你联系列表维护者。
欢迎项目分享的社区
在这一点上，开源项目有优势：很多开发者社区都乐于看到能跑起来的项目，只要它解决了真实问题，而且你会留下来回答问题。
| 渠道 | 最适合 | 第一步 |
|---|---|---|
| Show HN（Hacker News） | 别人能马上运行的工具 | 只发一次，留在帖子里，回答每一个问题 |
| 你所在技术生态的论坛或聊天群 | 面向某种语言或框架的库和插件 | 先读项目展示的规则，再发一个用例，而不是口号 |
| 合适的 subreddit | 在 Reddit 上有明确受众的项目 | 先查看每个 subreddit 关于自我推广的规则 |
| 问答回复 | 能解决反复出现的问题的项目 | 完整回答问题；只在项目真正有帮助时提到它 |
| 你所在技术生态的周刊 | 有故事可讲的版本发布 | 给编辑发一段简短说明，附上版本链接 |
| 线下聚会和技术大会演讲 | 有经验可以分享的项目 | 从你所用语言的本地聚会开始 |
在我们的公开数据集中，收录了 2025年9月至2026年8月间所有 15,859 篇链接到代码仓库的 Show HN 帖子，帖子得分的中位数为 2 分，达到 10 分或以上的占 9.5%。一篇帖子只是开始，而不是整个计划。
如何在 Show HN 上发布你的产品 →在 Reddit 推广你的 SaaS，同时不违反规则 →
| 规则 | 官方原文 | 对你意味着什么 |
|---|---|---|
| 适合什么 | Show HN is for something you've made that other people can play with. | 别人能实际运行的东西，而不是公告或落地页。 |
| 分量 | The project should be non-trivial. Don't post quickly-generated one-offs; anybody can do that now. | 发布你真正投入过心血、也能聊得出东西的项目。 |
| 门槛 | Please make it easy for users to try your thing out, ideally without barriers such as signups or emails. | 一条安装命令就能用的公开仓库，是理想的 Show HN。 |
| 投票 | Please don't ask friends to upvote or comment. That's not ok on HN. | 分享链接，但不要请人投票。让作品自己说话。 |
| 目标 | Don’t spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project. | 选择几个你的项目能解决真实问题的社区。 |
| 声誉 | the best way to invite people to share and contribute to your project is to share and contribute to their projects. | 先去帮助其他项目。大家会注意到，然后来看看你的项目。 |
目录站和发布平台
一旦有了网站、文档站或在线托管版本，几个目录站就会成为访客和链接的稳定额外来源。以下三个很适合开源项目：
- AlternativeTo：当你的项目是某个知名软件的免费替代品时。
- SourceForge：通过其 Create a Project 入口托管开源项目并提供下载，与它的商业软件目录相互独立。
- Product Hunt：适合界面精致、并且你能在发布当天全程在线的项目。
按受众匹配度选择平台，并查看每个平台的最新规则；被收录是一扇门，而不是用户的保证。 让你的开发者工具出现在开发者真正会看的地方。 →
不要做的事
- 购买或互换 Star
- GitHub 的政策禁止排名滥用，研究也表明，买来的 Star 只能带来短暂的帮助。详细内容和我们自己的测量见： 靠真正的实用价值赢得 GitHub Star →
- 请朋友帮忙投票
- Hacker News 说得很直白：这样做不行。一群朋友的投票，也无法告诉你真实的兴趣有多少。
- 到处发同一篇帖子
- 同一天在很多社区复制粘贴的公告，看起来就像垃圾信息。挑几个地方，分别为每个地方写。
- 在 README 之前就发布
- 注意力很短暂。在发出任何帖子之前，先把仓库的首屏整理好。
LaunchRepo 能做什么
LaunchRepo 负责目录站和发布平台这一层：你的编程智能体会准备你的项目网站，并把它提交到一个大型目录站列表中，追踪器会区分已上线的收录和仍在审核中的收录。
社区帖子、awesome 列表请求和各种交流仍由你亲自完成，因为用你自己的声音效果最好。LaunchRepo 帮你省下填表的时间，让你把这些时间花在那里。
来源
所有规则均于 2026年10月1日 查阅，并以英文原文逐字引用。文本副本与我们的证据资料一并保存。
常见问题
- 如何推广一个开源项目？
- 从仓库开始：一个回答“做什么、为什么、怎么开始”的 README、一份许可证、话题和预览图。然后，等别人无需注册就能试用时，在你的技术生态社区和 Show HN 上分享它，向一两个合适的 awesome 列表提出请求，并持续发布新版本。
- 怎样让我的项目进入 awesome 列表？
- 打开该列表，阅读它的贡献文件，并按它的格式提议一个条目。那些严格的规则（30 天、四次评审、awesome-lint）只在你把自己的精选列表提交到 awesome 元列表时才适用。
- 应该添加多少个 GitHub 话题？
- GitHub 最多允许 20 个。使用能描述用途、领域、社区和语言的话题，只用小写字母、数字和连字符，每个不超过 50 个字符。
- Show HN 适合开源项目吗？
- 适合，前提是别人能马上运行这个项目，而且你能留下来回答问题。Show HN 要求发布别人能试用的东西，不设注册门槛，也不要请朋友投票。
- 要不要买 GitHub Star，让项目看起来更成熟？
- 不要。GitHub 的可接受使用政策（Acceptable Use Policies）禁止自动加 Star 之类的排名滥用行为，一项大型研究也发现，买来的 Star 只能带来短暂的帮助，长期来看反而有害。
- LaunchRepo 会替我在社区发帖吗？
- 不会。LaunchRepo 为你的智能体提供把项目网站提交到目录站和发布平台的 playbook。社区帖子和 awesome 列表请求仍然由你亲自完成。
让你的智能体处理目录站
一次购买，由你的编程智能体执行，适用于你做的每一个产品：在你和用户交流的同时，你的编程智能体用 LaunchRepo 把你的项目网站提交到目录站和发布平台。
查看价格