本文作者：泊舟（@bozhou_ai）。版权归作者所有，未经授权禁止转载。
为了演示这套流程，我们让 Codex 做了一个宠物零食售卖网站。
第一版几分钟就出来了。接着加商品搜索、价格筛选、购物车数量修改、移动端适配，页面越做越完整，另一个问题也冒了出来：
哪一版是能用的？这次到底改了哪些文件？如果新功能把旧页面改坏了，怎么回到上一个版本？还有哪些需求没做？
Vibe Coding 最容易让新手翻车的地方，往往不是 AI 不会写代码。
是它改得太快，你开始管不住了。
很多人会继续补提示词，让 Codex、Cursor 或 Claude Code 再改一轮。但当项目进入第二次、第三次迭代，问题已经不只是怎么把代码写出来，而是怎么管理每一次修改。
这就是 GitHub 在 AI 时代的新位置。
它不只是一个放代码的网站，更像是你和 AI 共用的项目工作台。
如果你刚开始 Vibe Coding，不需要先学完 GitHub 的所有功能。先记住它对新手最直接的两种价值：
动手之前，去找别人已经做好的东西。动手之后，把自己的项目管起来。
一. GitHub 对新手最有用的两件事
很多零基础用户第一次打开 GitHub，会被满屏英文、代码和文件名劝退。
但你不需要先学会写代码，才能从 GitHub 得到好处。对刚开始 Vibe Coding 的人来说，它最直接的价值可以分成两部分：
- 找项目：发现别人已经做好的工具、模板和解决方案。
- 管项目：记录自己的修改，给 AI 分任务，合并前做验收。
先说找项目。
你想在手机和电脑之间传文件，不一定要自己做一个传输工具。GitHub 上已经有 LocalSend，可以在安卓、iPhone、Windows、macOS 和 Linux 之间互传文件。
你想在本地处理 PDF，也可以先看看 Stirling-PDF。Windows 用户想找截图和录屏工具，可以看看 ShareX。
这类项目能给新手三种东西：
- 直接使用：项目本身已经是一个能解决问题的工具。
- 拿来学习：README、目录结构和 Issue 里，能看到一个真实项目怎么组织。
- 作为起点：许可证允许的情况下，可以在现有项目上修改，不必每次从空文件夹开始。
这里有一个很容易踩的坑：代码公开，不等于你可以随便复制、商用或重新发布。
一个项目是否真正开源、允许你怎么使用，要看它有没有写清楚 License，也就是开源许可证。Star 数量也只能说明它受关注，不能证明它一定安全、适合你，或者还在维护。
找到一个项目后，我建议先看四个地方：
- README：它到底解决什么问题，怎么安装。
- Releases：有没有给普通用户下载的正式版本。
- 最近更新和 Issues：项目是不是还在维护，大家常遇到什么问题。
- License：能不能修改、分发或用于商业项目。
如果你看不懂，可以把项目链接交给 Codex 或 Claude Code，但先别急着安装：
先不要运行这个项目，也不要执行安装脚本。
请阅读它的 README、目录结构、License、Releases 和最近的 Issues，然后告诉我：
1. 它解决什么问题
2. 是否支持我的操作系统
3. 最简单的使用方式是什么
4. 项目最近是否还在维护
5. 安装时会执行什么脚本，有没有明显安全风险
6. 许可证是否允许我修改和发布AI 的回答只能帮你做第一轮筛查，不能当成安全认证。如果安装脚本要求管理员权限、账号密码或 API Key，先停下来确认，不要一路点确定。
这样逛 GitHub，你看到的就不再是一堆代码，而是一批已经做出来、可以继续研究的真实项目。
找项目是一面。等你自己开始 Vibe Coding，GitHub 的另一面才会出现：它开始帮你管理项目。
二. 先分清 Git 和 GitHub
Git 和 GitHub 经常一起出现，但它们不是同一个东西。
Git 是装在电脑里的版本记录工具。
你可以先把它理解成游戏存档。AI 每完成一个能用的小功能，你就让 Git 记一次。后面改坏了，只要之前存过，就有机会回到那个状态。
这个存档动作叫 Commit，也就是提交。
GitHub 是放在网上的项目工作台。
它可以保存 Git 的版本记录，也可以管理需求、检查修改、讨论问题。项目换一台电脑还能继续做，几个人或几个 AI Agent 一起干活，也能看清楚谁改了什么。
只看最核心的分工：
- AI：写代码、改代码、跑测试。
- Git：记录每次修改，给项目留存档。
- GitHub：放项目、管任务、看改动、做验收。
- 你：定目标，判断结果能不能用。
GitHub 不能保证 AI 一定写对，也不会替你验收。它解决的是另一件事：让 AI 的工作过程看得见、查得到、退得回。
放到一个最小项目里，就是这条流程：
AI 做功能 → Git 留存档 → GitHub 管任务和验收 → 你决定要不要合并
三. 用一个项目跑通 GitHub
继续看这个宠物零食网站。
第一版页面做好以后，我们先不急着让 AI 一路往下改，而是把项目放进 GitHub，再围绕它继续迭代。
整个过程只需要理解几个核心概念。别急着背英文名，用一遍自然就记住了。
1. Repository：项目的固定地址
在 GitHub 里，一个项目通常放在一个 Repository 里，简称 Repo，中文一般叫仓库。
它看起来像一个在线文件夹，但比网盘多了一层版本记录。项目里的代码、图片、说明文件，以及每次提交的历史，都放在这里。
你做的是网站，就建一个网站仓库。以后让 AI 找这个项目、继续改功能、检查旧版本，都从这里开始。
仓库里最好再放一个 README.md。
README 是项目的首页说明，至少写清楚三件事：
- 这个项目是做什么的。
- 怎么启动和测试。
- 哪些文件或功能不要随便改。
对 Vibe Coding 新手来说，README 不只是给人看的说明书。你让 Codex 或 Claude Code 接手项目前先读一遍，它会少猜很多。
2. Issue：先把需求变成任务单
第一版网站有了，接下来想加商品搜索。
先别只在聊天框里说一句：帮我加个搜索功能。
在 GitHub 里创建一个 Issue，把它当成这次修改的任务单。一个能用的 Issue，不用写得很专业，至少说清楚：
# 增加商品搜索功能
## 目标
用户可以按商品名称搜索零食。
## 做完的标准
- 输入关键词后，只显示匹配商品
- 没有结果时显示空状态
- 手机页面可以正常使用
- 不要修改购物车和结算逻辑
这一步看起来多了一点工作，其实是在帮你少返工。
需求只留在对话里，聊久了容易散。写进 Issue 以后，AI 知道这次只做什么，你也有一份可以回头检查的标准。
3. Branch：让 AI 在单独的工作线上修改
任务定好以后，不要让 AI 直接改稳定版本。
更稳的做法是从当前版本拉一条 Branch，中文叫分支。你可以暂时把它理解成一条单独的工作线，AI 在这里加搜索功能，原来的主线先不动。
大多数 GitHub 项目会把稳定主线叫 main。你现在不需要研究这个名字怎么来的，只要记住：新功能先放在别的分支，确认没问题再回到 main。
它并不是把整个项目复制成两份。Git 只是从当前存档拉出一条新的修改路线，所以开分支很快。
如果搜索功能没做好，删掉这条分支就行。原来的版本还在。
这也是为什么 Branch 很适合 AI 编程。AI 可以大胆施工，但不用一上来就动主版本。
4. Commit 和 Push：存好，再传上去
AI 完成一个小功能后，要留下一个 Commit。
Commit 就是一次带说明的存档。说明不用写得多复杂，能看懂这次改了什么就行，例如：
增加商品搜索和空状态提示
这里还要分清两个动作：
- Commit：把这次修改记录在本地 Git 里。
- Push：把本地的新记录同步到 GitHub。
你不一定要自己敲命令。可以直接告诉 Codex：
完成这个功能后先运行测试。确认通过再提交一次 Commit，写清楚修改内容，然后 Push 到当前分支。不要合并到 main。
重点不在背 git add、git commit 和 git push。
你只需要知道：AI 说“改好了”，不代表已经留下存档，更不代表 GitHub 上已经能看到。Commit 和 Push 都完成，修改过程才真正被记录下来。
5. Pull Request：合并前先验收
功能做完以后，先不要马上放进主版本。
让 AI 创建一个 Pull Request，简称 PR。它的真实含义是：这条分支已经改好了，现在申请把这些修改合并回主线。
你可以把 PR 理解成 AI 交上来的一份作业，但它不只是一句话。PR 里会集中展示：
- 改了哪些文件。
- 增加和删除了哪些内容。
- 对应哪个 Issue。
- AI 用什么方法测试过。如果项目配了自动检查，还能直接看到检查结果。
- 页面修改前后长什么样。
你不一定能看懂每一行代码，这很正常。
Vibe Coding 初学者可以先检查三件事：功能是不是能用，旧功能有没有坏，AI 有没有修改任务之外的东西。
有问题就让 AI 在这条分支继续改。确认没问题，再点 Merge，把它合并进主版本。
到这里，一次完整迭代才算结束：
写 Issue → 开 Branch → AI 修改 → Commit → Push → 创建 PR → 人工验收 → Merge
下一次要加价格筛选，再建一个新的 Issue，重新走一遍。
GitHub 就这样从“放代码的地方”，变成了整个项目的任务台、记录本和验收入口。
四. AI 怎么操作你的 GitHub
看到这里，很多新手会有一个问题：Codex 或 Claude Code 怎么把代码传到我的 GitHub？
如果 AI 只改你电脑里的文件，它不需要登录 GitHub。但要创建仓库、Push 代码、读取 Issue 或创建 PR，通常需要一个连接通道。
最常见的是 GitHub 官方命令行工具 GitHub CLI，它的命令叫 gh。
你可以让 Codex 先检查电脑里有没有安装：
gh --version安装好以后，用下面这条命令登录：
gh auth login它一般会引导你打开浏览器，自己确认 GitHub 登录和授权。这一步应该由你完成，不要把账号密码发给 AI。
这里再补一个容易混淆的地方：
- git 管的是电脑里的版本记录。
- gh 操作的是 GitHub 上的仓库、Issue 和 PR。
你也可能在其他教程里看到 Token。对于第一个 Vibe Coding 项目，我反而不建议新手一上来手动创建 Token。
先用 gh auth login 跑通登录。只有某个工具明确要求 Token，并且你知道它需要哪些权限时，再单独配置。Token 跟密码一样敏感，不能贴进提示词、截图、代码或公开仓库。
五. 第一个项目，直接把这两段话交给 AI
如果你还没用过 GitHub，可以先让 AI 帮你完成机械操作。你负责看懂它准备做什么，以及最后检查结果。
第一次上传项目，可以这样说：
请先检查当前项目是否适合上传到 GitHub。 重点检查： - 有没有 API Key、密码或其他敏感信息 - 有没有应该写进 .gitignore 的文件 - 项目是否能正常启动 检查完成后先向我汇报，不要直接上传。 我确认后，再初始化 Git，创建一个私有 GitHub 仓库，完成第一次 Commit 和 Push。
这里的 .gitignore，就是一张“这些文件不要交给 Git 管”的名单。看不懂也没关系，让 AI 先解释它准备忽略哪些文件，你确认后再上传。
以后增加新功能，可以这样说：
请为“增加商品搜索功能”创建一个 GitHub Issue，先写清目标和验收标准。
我确认 Issue 后：
1. 从 main 创建新分支
2. 只完成这个 Issue，不修改无关功能
3. 完成后运行测试
4. 提交 Commit 并 Push
5. 创建 Pull Request，说明改了什么、怎么测试
不要自动合并，等我验收。这两段提示词不是什么标准答案。不同项目会有不同的启动方式、测试方法和安全要求。
它们真正有用的地方，是把“让 AI 随便改”变成“让 AI 按任务施工，做完留下记录，最后等你验收”。
六. 新手先守住四条线
GitHub 的功能很多。Actions、Release、Projects、Fork、权限管理，都有用，但不是你做第一个项目时必须掌握的东西。
先守住四条线：
- 一个功能，一个 Issue：不要把五六个需求塞进同一次修改。
- 新功能放进 Branch：别让 AI 一上来直接改 main。
- 合并之前看 PR：至少检查功能、旧页面和修改范围。
- 密钥不要进仓库：API Key、密码和 .env 文件要单独保护。
如果你的项目只有一个页面，只准备生成一次，以后也不会再改，GitHub 的这套流程可能有点重。把文件备份好就够了。
但只要你准备继续迭代，或者让多个 AI Agent 接手，越早把项目放进 GitHub，后面越省心。
附录：5 个适合新手找项目的入口
如果你还不知道该在 GitHub 上搜什么，可以先从下面几个入口逛。
1. GitHub Trending
GitHub 自己的趋势榜，可以看最近哪些项目受到关注。它适合帮你发现新东西，但热度不等于质量，看到感兴趣的项目还是要回去看 README、更新记录和 License。
2. HelloGitHub
对中文用户更友好，会整理和介绍有趣的开源项目。相比直接扎进代码仓库，它更适合第一次逛 GitHub 的人。
3. GitHubDaily
长期分享 GitHub 上的实用项目和工具。你不知道该关注哪些开发者、哪些方向时，可以先拿它当项目推荐目录。
4. Awesome Lists
GitHub 上有很多以 awesome 开头的项目清单。想找某个方向的工具，可以搜索 awesome + 关键词，例如 awesome python、awesome self-hosted、awesome ai tools。
它更像社区整理的专题目录，不是官方质量认证。清单里的项目仍然需要自己判断。
5. Open Source Alternative
这个网站不属于 GitHub，但很适合反向找项目。你可以先输入一个正在使用的软件，看看有没有开源替代品，再顺着链接进入对应的 GitHub 仓库。
刚开始不用收藏几百个项目。
先找一个你真的需要解决的问题，挑一个项目，读懂 README，检查它是否还在维护，再决定要不要安装或让 AI 帮你改。
写在最后
AI 编程把“做出第一版”变得很容易。
真正拉开差距的，开始变成第一版之后的事情：需求怎么拆，修改怎么留，出错怎么退，结果由谁验收。
GitHub 的价值也不只发生在你开始写代码以后。
动手之前，你可以在上面找到现成工具、学习别人怎么做项目。动手之后，你可以用它记录版本、管理任务、检查 AI 的修改。
AI 帮你干活，Git 帮你存档，GitHub 帮你管理过程。最后那一下判断，还是要由你来做。
下一次让 Codex 或 Cursor 做项目，别等改到第十版才想起版本管理。
第一版能跑起来，就把它放进 GitHub。下一个功能从 Issue 开始，在 Branch 里做，最后到 PR 里验收。
先跑通这一圈。
你就不再只是让 AI 帮你写代码，而是在真正管理一个项目了。
