docs(workflow): 新增 PR 审核合并流程说明（模拟用）

docs/PR审核合并流程.md

@@ -0,0 +1,31 @@
+# PR 审核与合并流程（团队约定）
+
+适用：docwise-web 私有仓库，所有改动通过 Pull Request 进入 `main`。
+
+## 一、队友提交 PR 后，负责人（邹州）怎么做
+
+1. **看**：打开 PR，点"文件更改（Files changed）"逐行审阅，可留行内评论。
+2. **批**：看完点右上角"审查更改（Review changes）"，选"批准（Approve）"并提交审查；需要修改时选"请求更改（Request changes）"。
+3. **合**：等 CI 全绿且已批准后，点"合并拉取请求"右侧小箭头，选"压缩合并（Squash and merge）"，确认。
+4. **删**：合并后点"删除分支（Delete branch）"。
+
+CI 未通过时先不合并，让提交者修复后再审。
+
+## 二、三种合并方式的区别
+
+| 方式 | 效果 | 适用 |
+|---|---|---|
+| 创建合并提交（Create a merge commit） | 保留分支上所有提交，另加一个合并节点 | 想完整保留开发过程时 |
+| 压缩合并（Squash and merge） | 分支上所有提交揉成一个提交进 main | 仓库约定，默认使用 |
+| 变基合并（Rebase and merge） | 提交逐个重放到 main 上，历史线性但提交被重写 | 需要保留每个提交时 |
+
+仓库统一使用**压缩合并**，由负责人操作。
+
+## 三、负责人自己的 PR
+
+GitHub 不允许作者批准自己的 PR。负责人自己的改动：
+
+- 小改动：以管理员身份勾选"无需等待满足条件即可合并（绕过规则）"后压缩合并；
+- 或由一位有写入权限的队友批准后正常合并。
+
+（2026-08-05 为流程模拟而建，内容待团队确认）