Vibe Coding 新手指南

主题

Git 和开源 ​

Git 和开源是什么？为什么要学？ ​

先理解这些概念 ​

Git = 代码版本管理工具

  • 记录代码的每次修改
  • 可以回到之前的任何版本
  • 多人协作不会乱

GitHub = 代码托管平台

  • 把代码放在云端
  • 别人可以看到、下载、使用
  • 全球最大的开源社区

开源 = 把代码公开分享

  • 任何人都能看到代码
  • 可以学习、使用、改进
  • 也是个人品牌和引流手段

小白最大的困惑 ​

很多新手对 Git 和开源的理解是模糊的：

  • "Git 是干什么的？我一个人做项目也要用吗？"
  • "开源是什么？代码公开了不怕被抄吗？"
  • "GitHub 和 Git 有什么关系？"
  • "我不会 Git 命令，能用 AI 吗？"

这一章会解答这些问题，并分享真实的使用经验。

案例：我的第一次 Git 使用 ​

完全不会，靠 AI 学 ​

第一次用 Git 是做开源项目的时候。

当时的状态：

  • git push 是什么？不知道
  • 怎么创建 GitHub 仓库？不知道
  • 本地代码怎么传到 GitHub？不知道

一开始很慌。

然后想起来，可以问 AI。

我想把代码推到 GitHub，
完全不会 Git，
怎么做？

AI 给了完整步骤：

  1. git init - 初始化本地仓库
  2. 去 GitHub 创建远程仓库
  3. git remote add origin [仓库地址] - 关联远程
  4. git add . - 添加所有文件
  5. git commit -m "first commit" - 提交
  6. git push -u origin master - 推送

照着做，报错了。

再问 AI："为什么报错？怎么解决？"

AI 分析错误信息，给出修复方法。

再试，成功了。

从完全不会，到成功推送代码，花了半小时。

到现在也没深入理解 ​

真实情况：到现在也没有深入理解 Git。

什么是深入理解？

  • 不知道 Git 的底层原理
  • 不知道 rebase 和 merge 的区别
  • 不知道怎么用分支策略

但够用吗？完全够用。

日常怎么用？

1. 写代码
2. git add .
3. git commit -m "xxx"
4. git push

就这4步，重复一万次。

遇到复杂情况？

问 AI："我想回退到上个版本，怎么做？"

AI 给命令，照着做就行。

不需要精通 Git，AI 可以帮你解决所有问题。

一个坏习惯 ​

坏习惯：

总想着把功能开发得差不多再推送。

为什么这是坏习惯？

  1. 代码一直在本地，丢了就没了
  2. 多台电脑开发，同步麻烦
  3. 想回到某个中间状态，没法回

Git 的核心价值是版本管理，不是"等完美了再记录"。

更好的做法：

  • 哪怕功能还没做完，也可以 commit
  • 先推到私有仓库，后面再开放
  • 或者直接 Build in Public（公开开发）

案例：为什么要开源微信 RSS？ ​

开源前的纠结 ​

当时的顾虑：

  • 代码质量不够好，会不会被人吐槽？
  • 开源了会不会被抄袭？

最后决定开源，理由是：

1. 受益于开源，想回馈社区

微信 RSS 本身就是基于开源项目二开的。

没有开源，就没有微信 RSS 这个项目。

2. 开源可以引流

开源 → GitHub 曝光 → 用户发现 → 部分转化为 SaaS 用户

3. 产品力才是核心

即使开源了，SaaS 版也有优势：

  • 更直观的界面
  • 更便捷的使用方法
  • 用户什么都不需要准备，直接订阅就行

不会私有化部署的用户，更喜欢简单轻松的 SaaS 服务。

只要能解决问题，就愿意付费。

开源前的准备 ​

最重要的事：清理敏感信息。

问 AI：

帮我检查代码中的敏感信息：
- API 密钥
- 数据库密码
- 服务器 IP
- 其他敏感配置

给出清理方案。

AI 会帮你找出所有硬编码的敏感信息，建议用环境变量替代。

选择开源协议：

问 AI："我的项目想开源，但也想做 SaaS 变现。推荐用什么开源协议？"

AI 推荐了几个，最后选了 AGPL-3.0（传染性开源协议）：

  • 个人使用、学习、二开 → 完全自由
  • 商业使用 → 必须开源或联系授权

这在一定程度上规避了直接的商业竞争。

全面检查一遍，确保没有泄露，然后就推送到 GitHub，开源了。

开源后发生了什么？ ​

Star 增长和阮一峰周刊的影响 ​

开源初期：

Star 增长很慢，每天一两个。

转折点：自荐到阮一峰周刊

把项目自荐到了阮一峰的科技爱好者周刊。

几天后，周刊发布了，微信 RSS 被收录。

效果：

看 Star History 曲线，有一波非常明显的增长（从几十个涨到 300+）。

SaaS 用户也有增长，项目知名度提升。

经验：好产品也需要曝光，找对渠道很重要。

当前数据（截止2026年4月3日） ​

  • ⭐ 444 个 Star
  • 🍴 28 个 Fork
  • 🐳 1.2k Docker Pull
  • 👥 约 400 个真实 SaaS 用户

变现情况：

  • 项目已实现变现
  • 开发成本、服务器成本已收回

这证明：开源和商业可以共存。

Issue 和 PR 的处理 ​

先理解这两个概念：

Issue（问题报告） = 用户在 GitHub 上提出的问题或建议

  • 可能是 Bug："功能不工作了"
  • 可能是需求："能不能加个 XX 功能？"
  • 可能是疑问："这个怎么用？"

PR（Pull Request，代码贡献） = 别人帮你改代码

  • 用户 Fork 了你的项目
  • 改了代码（比如修 Bug、加功能）
  • 提交 PR，请求你合并到主项目

Issue 处理：每个都回复

处理流程（和 AI 协同）：

  1. 用户提 Issue
  2. 看 Issue 描述
  3. 问 AI："这个问题可能是什么原因？怎么解决？"
  4. AI 分析并给方案
  5. 测试、修复、回复用户

有时候一个 Issue 要来回沟通好几次，但都会认真处理。

PR 处理：质量不行会拒绝

有人提过 PR，但因为质量不高被拒绝了。

标准：

  • 代码质量要符合项目规范
  • 功能要有明确价值
  • 不能引入新的问题

不好意思拒绝吗？

一开始有点不好意思，但后来想明白了：

维护开源项目的代码质量是作者的责任，不能因为不好意思就接受低质量的 PR。

开源的真实价值 ​

对项目：

  • 用户增长（GitHub 曝光 → 部分转化 SaaS 用户）
  • 代码质量提升（有人看代码，更注重质量）
  • 社区反馈（用户帮你发现 Bug 和需求）

对个人：

  • 技术提升（处理 Issue 和 PR）
  • 影响力提升（开源项目是个人名片）

核心要点 ​

Git 不需要精通，AI 可以帮你

日常 4 步：写代码 → add → commit → push

遇到问题问 AI，半小时从不会到成功推送。

开源和商业可以共存

微信 RSS：444 Star、400 SaaS 用户、已实现变现。

关键：

  • 用对协议（AGPL 规避商业竞争）
  • 产品力决定成败（SaaS 体验更好，用户愿意付费）
  • 宣传很重要（阮一峰周刊带来一波大增长）

三个建议：

  1. 尽早推送代码（先私有仓库，后开放）
  2. Issue 认真处理（让用户感受到用心）
  3. 不和大厂竞争（找细分市场）