🏗️ 第 05 阶段 · 项目工程化有基础更佳
多人协作与代码审查：PR、审查、AI 帮你把关
学会和别人一起做项目：分支、Pull Request、代码审查，以及让 AI 当你的审查官。
⏱ 20 分钟 · ☑ 4 个实操任务
多人协作的完整流程
开分支 → 做功能 → 提交 → 推远程 → 发 Pull Request → 别人审查 → 合并
- Pull Request（PR）：把你的改动「申请合并」到主分支，别人能看到你改了什么
- 代码审查：在合并前检查有没有问题
术语提示：远程仓库 = 放在网上的代码存放处；分支 = 从主版本分出去的试验线；合并 = 把分支的改动并回主版本；代码 = 让电脑干活的一组指令文字。
🌐 需要代理或海外网络：GitHub 的 PR 功能在国内不稳定。国内替代：用 Gitee 的 Pull Request，流程基本一样；两个人都在本地协作也可以，只是少了网页版审查。
PR 的完整流程（一步一步）
| 步骤 | 做什么 | 谁做 |
|---|---|---|
| 1 | 开一个分支做新功能 | 你 + AI |
| 2 | 功能做完，提交并推送到远程 | 你 |
| 3 | 在网页上发起 Pull Request | 你 |
| 4 | 对方在网页上看改动、提意见 | 对方 |
| 5 | 根据意见修改，再推送 | 你 + AI |
| 6 | 对方确认没问题，点「合并」 | 对方 |
新手先练：让 AI 审查你的代码
不用等团队，AI 就能当审查官：
帮我审查最近这次改动。请检查：
1. 有没有明显的 bug
2. 有没有会破坏现有功能的地方
3. 命名和结构是否规范
4. 需不需要补测试
然后按严重程度列出问题清单。
审查清单（照着问）
| 检查项 | 问 AI 的话 |
|---|---|
| 有没有 bug | 这段代码有没有明显错误？ |
| 会不会破坏旧功能 | 这个改动会影响哪些现有功能？ |
| 规范不规范 | 命名和结构符合项目规则吗？ |
| 测试缺不缺 | 这些新功能需要补测试吗？ |
审查意见怎么处理
让 AI 根据意见修改：
按你列的问题，一个一个修。每修一个就告诉我改了什么，最后重新跑一遍测试。
怎么回复别人的审查意见
- 同意：
好的，我改一下 - 不同意：
这里我理解不一样，能再解释一下吗？ - 不确定：
我先试试你建议的方案，有问题再讨论
给别人提意见的三个原则
- 对事不对人：说「这里可能有问题」，不说「你写错了」
- 给建议不给命令：用「可以改成 X」而不是「必须改」
- 小步提交：每次改动越小，审查越容易
下一步
工具都学完了，下一课把它们全部用起来：把记账本做一次工程化重构。