代码写完了不敢开源？vibe 项目的开源发布完整实战

先划界：这篇只做"发布动作本身"

在动手之前，先把三篇指南的边界说清楚，免得你读串了。如果你担心的是"AI 帮我写的代码里混进了 GPL 代码，会不会污染我的项目"，那是输入侧的合规问题，看《AI 代码许可证风险指南》；如果你已经开源了、现在想的是"怎么靠它收钱"，那是事后的变现问题，看《开源变现四条路：独立开发者的实战选择》。而这一篇，只回答一个问题：从私有仓库到一个健康的开源项目，发布这个动作本身怎么做。许可证是地基，README 和 CONTRIBUTING 是门面，issue 和 PR 的治理是日常运营——这三件事，缺一件，开源就是裸奔。

你不是怕开源，你是怕"被看见之后怎么办"

几乎每个 vibe 开发者都经历过这个心理过程：项目在本地跑起来了，越看越喜欢，然后在 GitHub 点 New repository 的那一刻停住了。停住的原因很少是技术，基本都是这三个：第一，怕代码写得丑，被人笑话——AI 一晚上吐出来的代码，自己都没全读过；第二，怕许可证选错，将来想商用时发现路被堵死了；第三，怕开了仓库没人理，或者更糟，来了人自己不知道怎么接待，issue 区三个月没人回，活活烂掉。

这三个怕，恰好对应开源发布的三块基本功：代码体检解决"丑不丑"，许可证决策表解决"选不错"，社区四件套加治理纪律解决"来了人怎么办"。先说一个定心丸：choosealicense.com（GitHub 官方的许可证选择站，首页有中文版）的第一句话是这么写的——"An open source license protects contributors and users. Businesses and savvy developers won't touch a project without this protection."（开源许可证保护贡献者和使用者；没有这层保护，懂行的公司和开发者根本不会碰你的项目。）看懂了吗？许可证不是束缚，是你的项目被认真对待的前提。没有许可证的公开仓库，在法律上默认是"版权所有、保留一切权利"，别人连看都不能看——那不叫开源，叫把代码晾在网上。

开源前先回答三个问题

别急着选许可证。opensource.guide（GitHub 出品的开源指南站，亲测页面正常）的《Starting an Open Source Project》开篇就让你先想清楚三件事，vibe 开发者尤其要听：

第一，为什么开源？动机决定一切。想要获客引流，就选最宽松的许可证、把 README 写成营销页；想要招人背书，就把架构设计和技术决策写进文档；想要生态，就要早定贡献者协议和治理规则；纯粹理想主义，那就选 GPL 系、把"共享改进"写进基因。动机不明，开源后每一个决策都会摇摆。

第二，开源哪部分？三个选项：全量开源、只开源核心库、开源一个功能阉割版。一人开发者的常见坑是"全量开源但舍不得"，结果仓库里混着半成品的商业代码，进退两难。原则是：开源的部分必须是一个能独立跑起来的完整东西。核心库开源、周边商业插件闭源，是验证过无数次的健康结构；反过来，一个缺了私有模块就跑不起来的"开源项目"，只会收获差评。

第三，什么时候开源？经验法则是：有 3 个真实用户之后。vibe 项目的一大诱惑是"代码刚跑通就想 push"，但一个零用户、零文档、零测试的仓库，公开了等于没公开，还占了你维护的心理带宽。3 个真实用户意味着：有人愿意为它填 issue，有人能告诉你 README 哪里看不懂，有人在你弃坑的边缘把你拉回来。

许可证选型：五分钟决策表

许可证是这篇唯一需要"做对"的法律动作，错了改起来极贵（改许可证需要所有贡献者同意，人越多越难）。先给结论：一人开发者默认选 MIT，90% 的情况不会错。剩下的 10%，看这张决策表：

维度	MIT	Apache-2.0	GPLv3	AGPLv3
商用（闭源卖钱）	✅ 允许	✅ 允许	❌ 衍生必须开源	❌ 衍生必须开源
专利授权	❌ 无明确专利授权	✅ 明确的专利授权+报复条款	✅ 有专利授权	✅ 有专利授权
传染性（copyleft）	无	无	强：分发衍生作品必须同许可证开源	最强：通过网络提供服务也算"分发"
AI 训练	⚠️ 主流许可证均未明确覆盖 AI 训练场景，属灰色地带	⚠️ 同左	⚠️ 同左	⚠️ 同左
一句话画像	最短、最宽松，传播之王	MIT + 专利护甲，企业最爱	理想主义者的盾：逼衍生开源	防云厂商白嫖专用
代表项目	Babel、.NET、Rails	Kubernetes、TensorFlow	Ansible、uBlock Origin	Nextcloud、Mastodon

决策逻辑翻译成人话：

• 选 MIT：你只想让代码传得越广越好，不在乎别人拿去闭源赚钱。choosealicense.com 的原话是 "I want it simple and permissive" 就选 MIT。vibe 做的工具类小项目，闭眼 MIT。
• 选 Apache-2.0：和 MIT 几乎一样宽松，但多了一层明确的专利授权——贡献者把专利也授权给你，且谁先发起专利诉讼谁就失去授权。2017 年 React 从 BSD+Patents 换到 MIT，起因正是社区对专利条款的恐慌；如果你做的东西可能涉及专利攻防，直接 Apache-2.0，省得将来扯皮。
• 选 GPLv3：你在乎"共享改进"——谁拿你的代码改了再分发，就必须同样开源。代价是传染性会吓跑一部分商业用户。选之前想清楚：你的目标用户里有没有想闭源商用的公司，有就别选。
• 选 AGPLv3：你的项目是网络服务/SaaS，且你担心云厂商拿去白嫖（自己搭个服务赚钱，一行代码不回馈）。MongoDB 当年就是被云厂商"拿来主义"逼得换了 SSPL（不是 OSI 认证的开源许可证，是个有争议的"源码可用"许可证，教训是：换许可证本身也会流失社区）。AGPL 是 OSI 认证里防白嫖最强的合法选项。
• 自定义许可证：除非你请得起律师，否则别碰。99% 的"自定义"最后都写成了"版权所有，禁止商用"，等于没开源。

实操只有三步：打开 choosealicense.com（有中文），按上图走一遍，选定后把许可证全文存成仓库根目录的 LICENSE 文件，并在 README 顶部声明。注意一个冷知识：双授权（dual licensing）现在就要预留。如果你将来可能走"社区版开源+商业版收费"的路（变现细节看《开源变现四条路》），从第一个外部 PR 开始就要让贡献者签 CLA（贡献者许可协议）或至少 DCO（开发者原创声明，Linux 内核在用的 Signed-off-by 那套），否则将来改商业授权时，你得去求每一个贡献者点头。

开源前代码体检：密钥清零是生死线

这是整篇最不能跳过的一节。vibe coding 的工作流决定了：AI 为了"让 demo 跑起来"，极大概率把 API key、数据库密码、测试账号直接写进了代码或 .env，而你 git add . 的时候根本没注意。公开仓库的密钥会在几分钟内被全网扫描器抓走——这不是危言耸听，GitHub 之所以给 push 动作默认开启 secret scanning 和 push protection，就是因为太多人吃过这个亏。

体检清单，按顺序做：

• 1. 密钥大扫除。先跑下面这段脚本（保存为 pre-oss-scan.py，直接 python3 pre-oss-scan.py），它扫全仓库的疑似密钥和敏感文件。生产环境建议再跑一遍 gitleaks 或 trufflehog 做交叉验证，GitHub 的 push protection 是最后一道网，不是第一道。
• 2. 查 git 历史。密钥删掉还不够——git log 里还躺着。凡是曾经提交过的密钥，必须视为已泄露：去对应平台 revoke（吊销）并重新生成，然后用 git filter-repo 或 BFG Repo-Cleaner 重写历史。记住原则：删记录是体面，换密钥是保命，两件都要做。
• 3. 删内部注释与客户数据。AI 生成的代码里常有 "TODO: 给张总演示前改掉" 这类注释，测试数据库里可能躺着真实用户信息。全局搜一遍公司名、人名、内网域名、客户数据，mock 数据全部换成虚构的。
• 4. 第三方资产授权复查。图标、字体、示例图片、背景音乐——vibe 项目里这些经常是随手从网上拖的。每一项确认授权：CC0 可商用随便用，CC-BY 要署名，凡是"仅限个人使用"的一律替换。字体尤其容易踩坑，很多"免费字体"只免个人使用。
• 5. AI 生成代码的许可证复查。如果你的代码是 AI 写的，且训练数据里可能混了 copyleft 代码，这一步不能省。具体风险模型和自查方法看《AI 代码许可证风险指南》，这里只记结论：跑一次许可证扫描（如 scancode），把高风险依赖换掉或隔离。
• 6. 把秘密从代码里搬出去。正确姿势是：代码里只读环境变量，仓库里放 .env.example（只写字段名不写值），.gitignore 里加上 .env*。CONTRIBUTING 里写清楚"复制 .env.example 为 .env 并填入自己的 key"。这是开源项目的标准动作，review 的人第一眼就看这个。

#!/usr/bin/env python3
"""pre-oss-scan.py —— 开源前仓库体检：扫描疑似密钥与敏感文件
用法：python3 pre-oss-scan.py [仓库路径]
注意：命中只是"可疑"，必须人工复核；扫完记得换掉真密钥。
"""
import re, sys
from pathlib import Path

PATTERNS = {
    "AWS Access Key": re.compile(r"AKIA[0-9A-Z]{16}"),
    "AWS Secret": re.compile(r"aws_secret_access_key\s*=\s*['\"][^'\"]{8,}"),
    "GitHub Token": re.compile(r"gh[pousr]_[A-Za-z0-9]{36,}"),
    "Slack Token": re.compile(r"xox[baprs]-[A-Za-z0-9-]{10,}"),
    "Private Key": re.compile(r"-----BEGIN (?:RSA |EC |OPENSSH )?PRIVATE KEY-----"),
    "Generic Secret": re.compile(
        r"(?i)(api[_-]?key|secret|password|passwd|pwd)\s*[:=]\s*['\"][^'\"]{8,}['\"]"),
}

SENSITIVE_FILES = {".env", ".env.local", ".env.production", "id_rsa",
                   "id_ed25519", "credentials.json", "service-account.json",
                   ".npmrc", ".pypirc"}
SKIP_DIRS = {".git", "node_modules", "__pycache__", ".venv", "venv",
             "dist", "build", ".next"}

def iter_files(root):
    for p in Path(root).rglob("*"):
        if p.is_file() and not any(part in SKIP_DIRS for part in p.parts):
            yield p

def main(root="."):
    hits = 0
    for f in iter_files(root):
        if f.name in SENSITIVE_FILES:
            print(f"[FILE] {f} —— 敏感文件，不应进仓库")
            hits += 1
            continue
        try:
            text = f.read_text(encoding="utf-8", errors="strict")
        except (UnicodeDecodeError, OSError):
            continue  # 二进制文件跳过
        for no, line in enumerate(text.splitlines(), 1):
            for name, rx in PATTERNS.items():
                if rx.search(line):
                    print(f"[{name}] {f}:{no}")
                    hits += 1
    print(f"\n扫描完成，共 {hits} 处可疑命中（人工复核后再决定删改）。")
    return 1 if hits else 0

if __name__ == "__main__":
    sys.exit(main(sys.argv[1] if len(sys.argv) > 1 else "."))

社区四件套：别人决定留不留下，只看这四个文件

一个陌生人点进你的仓库，平均 30 秒决定是 star 还是关掉。这 30 秒里他看的东西按顺序是：README 顶部、截图、快速开始能不能跑通、有没有 CONTRIBUTING。opensource.guide 的《Building Welcoming Communities》把这套东西叫"降低参与门槛"，翻译成人话就是：别让想帮你的人猜。

1. README.md —— 你的销售页。结构固定：一句话说清这是干什么的（不是"一个基于 AI 的智能平台"，而是"把 Figma 设计稿一键转成 Tailwind 代码的 CLI"）；徽章（构建状态、许可证、版本号， shields.io 现成）；一张截图或 10 秒 GIF（vibe 项目的 README 没有动图等于裸奔）；快速开始——复制粘贴三步能跑起来，超过五步就没人试了；功能列表、路线图、许可证声明。记住：README 是写给"第一次听说你的人"看的，不是写给自己看的备忘录。

2. CONTRIBUTING.md —— 你的员工手册。核心只有三句话：开发环境怎么一键跑起来（docker compose up 或一条安装命令，超过 10 分钟的环境搭建等于劝退）；PR 流程是什么（fork → 分支 → 本地测试命令 → 提 PR）；代码规范（格式化工具、commit 信息格式）。vibe 开发者常犯的错是把 CONTRIBUTING 写成散文，正确姿势是写成 checklist——贡献者照着打勾就行。

3. CODE_OF_CONDUCT.md —— 你的社区宪法。直接用 Contributor Covenant 的模板（GitHub 建仓库时可以一键添加），改两个地方：把联系人邮箱换成你自己的，明确"违反了找谁、怎么处理"。一人项目也需要这个——它最大的作用不是约束别人，是当有人吵架时，你有章可循，而不是凭心情删评论。

4. SECURITY.md —— 你的漏洞上报通道。写清楚三件事：发现安全漏洞不要提公开 issue，去哪里私下报告（邮箱或 GitHub 的 private vulnerability reporting）；你承诺多久响应（比如 48 小时内确认）；哪些版本还在维护。没有 SECURITY.md 的项目，安全研究员发现漏洞只能提公开 issue，全世界都能看到——包括攻击者。

外加两个模板文件，放在 .github/ 目录下：issue 模板（bug 报告：环境版本/复现步骤/期望行为/实际行为；功能请求：解决什么问题/建议方案/替代方案）和 PR 模板（改了什么/怎么测试/关联 issue）。GitHub 建仓库时勾选"Add issue/PR templates"就有，改改字段就能用。这两个模板的价值在于：把低质量的 issue 挡在门外，把高质量的 PR 迎进来。

仓库设置清单：发布前 10 分钟点完

代码和文档就绪后，去仓库 Settings 里把这几件事点完，一共 10 分钟：

• 默认分支保护：Settings → Branches → Add rule，勾选 Require a pull request before merging（哪怕只有你一个人，也逼自己走 PR 流程——这是给未来贡献者看的纪律示范）和 Require status checks to pass。
• Topics 和描述：仓库顶部的一句话描述 + topics 标签（如 vibe-coding、ai、cli），这是 GitHub 搜索流量的入口，别空着。
• Issue/PR 模板和自动打标：用 GitHub Actions 给新 issue 自动打 triage 标签，给首个 PR 的作者自动评论欢迎语（actions/first-interaction 现成）。
• Stale bot 参数调温柔点：默认 60 天无活动标记 stale、7 天后关闭，对新项目太激进——刚发布时 issue 本来就来得慢，机器人 30 天就关 issue 等于赶人。建议改成 90 天标记、14 天后关闭，并在关闭留言里写清楚"随时可以 reopen"。
• Discussions vs Issues 分流：开 Discussions，把"怎么用""求功能"引到 Discussion，把"确定是 bug"留在 Issue。规则写进 CONTRIBUTING，不然 issue 区三个月就会变成许愿池。
• 许可证徽章亮出来：确认仓库主页右侧显示了正确的许可证（GitHub 会自动识别 LICENSE 文件），这是"懂行的人"第一眼看的东西。

发布日 SOP：开源是一次产品发布

选个周二到周四的上午发布（Hacker News 和社交媒体的活跃规律：周末没人看，周一大家都在开会）。发布日的时间表：

• T-3 天：把仓库设为公开（对，先公开仓库再发帖，顺序别反——空仓库的 Show HN 帖会被踩沉）。检查一遍：LICENSE 文件存在、README 截图能打开、快速开始在新机器上真跑过一遍（找台没装过你环境的电脑，或开个 codespace 从零跑）。
• T 日上午：Show HN。标题公式：Show HN: 项目名 – 一句话说清解决什么问题。正文第一段讲你是谁、为什么做这个，第二段讲技术实现（HN 用户吃这套），最后一段讲路线图和求反馈。发完之后在评论区值班 48 小时——Show HN 的潜规则是作者必须在场，每一条认真评论都要回，不懂就承认不懂。消失的作者等于告诉所有人"这个项目没人维护"。
• T 日下午：Reddit + V2EX + X。r/SideProject、r/opensource、V2EX 的分享创造/分享发现节点，X 上 @ 几个相关领域的 KOL（别群发，挑真的用得上的人）。每个平台的文案单独写——Reddit 讨厌营销腔，V2EX 吃技术细节，X 吃截图和动图。
• T+1 到 T+7：issue 三级响应。P0（安全漏洞、完全跑不起来）当天回；P1（功能 bug、有复现步骤）三天内回；P2（功能建议、问题咨询）一周内回。回不等于修——"收到，排进 roadmap"是合格的回复，"已读不回"是自杀。第一周的目标不是修完所有 issue，是让每一个提 issue 的人感到"这个项目活着"。

一个反直觉的建议：别在发布日当天合并大 PR。发布周代码冻结，只修 P0。历史上太多项目在流量 peak 时手忙脚乱合了个 breaking change，把第一批用户全吓跑了。

首月治理：接住第一个外部贡献者

发布只是开始。opensource.guide 的《Best Practices for Maintainers》和《Leadership and Governance》讲的都是这一个月的事，提炼成一人开发者能执行的纪律：

Issue triage（分拣）每周一次，雷打不动。新 issue 先打标签：bug / enhancement / question / good first issue。其中 good first issue 是你最重要的运营资产——把"改个错别字""加个单元测试"这种 30 分钟能做完的活标出来，这是新贡献者的上车台阶。没有台阶的项目，新人看一眼就走。

PR 合并纪律三条：CI 必须绿灯（没配 CI 就先配，这是合并纪律的技术底座）；至少你自己认真 review 一遍（看不懂就问，别装懂合进去）；用 squash merge 保持主分支历史干净。第一周可以"鼓励式合并"——小毛病先合进来再修，目的是让贡献者尝到"我的代码进了这个项目"的甜头。但底线是：测试覆盖不能倒退，许可证头不能丢。

第一个外部贡献者，是你的高光时刻，务必接住。24 小时内回复他的 PR（哪怕只说"收到，周末仔细看"）；合并后公开致谢（release note 里点名，或 README 加 Contributors 名单，all-contributors 规范现成）；主动问他"有没有兴趣继续做 X"。数据上说不清，但经验上：第一个外部贡献者留下来了，第二个、第三个就会来；第一个被晾跑了，仓库就会长期只有你一个人。

学会说"不"，而且要体面地说。功能请求拒绝话术模板："谢谢建议！这个方向和项目的核心目标（一句话）不太一致，暂时不打算做。如果你愿意，可以 fork 出去实现，我很乐意在 README 里 link 过去。"——拒绝的是功能，不是人。hostile fork（有人 fork 后改个名当自己的发）怎么办？先看许可证：MIT/Apache 本来就允许 fork，这是你选许可证时就接受的代价；再看商标：项目名和 logo 可以注册商标保护，代码能 fork，品牌不能偷。2024 年 WordPress 和 WP Engine 的商标大战就是现成教材：代码之争最后都落到商标上。

什么时候该立规矩？当出现第二个稳定贡献者时，就该写 GOVERNANCE.md：谁能合 PR、重大决策怎么定（lazy consensus 还是投票）、什么情况下移除维护者。别等到吵架了再写——opensource.guide 的《Leadership and Governance》原话精神是：规则要在用上之前定好。

反模式清单：这些姿势都在劝退

• 裸奔式 push：无 LICENSE、无 README、无 .gitignore，一个 commit 叫 "init"。这是 vibe 开发者最常见的开源姿势，也是 star 数永远停在 3 的根本原因（其中 2 个是你自己的小号）。
• "以后再补文档"：没有以后。发布日之后你的肾上腺素会断崖式下跌，文档只会越拖越烂。文档必须在公开之前写好。
• 密钥进 git 历史：删文件不算数，历史里还有。用 BFG 重写历史 + 到平台 revoke，一套做完才算完。最惨的案例永远是"我以为删了"。
• Stale bot 当打手：30 天无活动自动关 issue，还配一句冰冷的 "This issue has been automatically closed"。新人的第一个 issue 被机器人关掉，他这辈子不会再来。
• Show HN 发完就消失：评论区 200 条留言，作者一条不回。等于花钱买了广告牌然后关灯。
• 第一个 PR 晾三周：贡献者鼓起勇气提了 PR，你三周后回一句 "LGTM" 合了。他不会有第二次——人都走了，代码才合，有什么用。
• Issue 区变许愿池：没有模板、没有分流、没有关闭，"求加暗黑模式""求支持 Windows"堆了 80 条。你不敢关，关了怕得罪人；不关，新来的人以为这是个无人维护的坟场。
• 合并纪律双标：自己的 commit 直接 push main，别人的 PR 挑三拣四。贡献者不傻，一次就看出来了。
• 许可证朝令夕改：今天 MIT，明天觉得吃亏换 GPL，后天又换回来。每次换许可证都要所有贡献者同意，改到最后没人敢贡献——谁知道你下次又换什么。
• 把开源当 KPI：为了"简历上有个开源项目"而开源，发布日之后再也不看。GitHub 的 contribution 图会诚实地出卖你，面试官也看得出来。

验收：开源前 15 项检查

打印出来，逐项打勾，全勾完再点"公开"：

• □ LICENSE 文件在仓库根目录，GitHub 正确识别了许可证类型
• □ README 有一句话价值陈述、有截图或 GIF、快速开始三步可跑通（在新环境实测过）
• □ CONTRIBUTING.md 写清了环境搭建、PR 流程、测试命令
• □ CODE_OF_CONDUCT.md 用了标准模板，联系人是自己的邮箱
• □ SECURITY.md 写清了私下上报通道和响应时限
• □ .github/ 下有 bug 报告 / 功能请求 issue 模板和 PR 模板
• □ 跑过 pre-oss-scan.py（或 gitleaks），0 可疑命中；历史提交查过，无密钥残留
• □ .env.example 已提交，.gitignore 排除了 .env*，代码里无硬编码密钥
• □ 内部注释、客户数据、真实用户信息已清理；第三方素材（图标/字体/图片）授权已确认
• □ 默认分支保护已开，CI 绿灯是合并前置条件
• □ Discussions 已开，issue/Discussion 分流规则写进 CONTRIBUTING
• □ Stale bot 参数调温和（建议 90 天标记、14 天后关闭）
• □ 第一个外部贡献者预案：good first issue 已标出 3-5 个，欢迎语 bot 已配
• □ 发布帖已排期：Show HN 标题写好、48 小时值班时间空出来、Reddit/V2EX/X 文案各一版
• □ 双授权预留：决定好 CLA 还是 DCO，第一个外部 PR 到来之前文案就绪

最后说一句：开源最难的一步不是写代码，是接受"你的项目会被人评判"。但换个角度想——vibe coding 已经把"从想法到可用产品"的成本打到了地板，开源是把"从产品到影响力"的成本也打到地板的唯一方式。你缺的从来不是代码，是一个把代码递出去的姿势。这篇就是那个姿势的说明书。现在，去把那 15 个勾打完。