---
date: 2026-05-11
tags: [pr, workflow, ai-first, judgment]
status: documented
---

# 拆 PR 的判断：用"用户视角的一件事"覆盖机械规则

## 情境

实现"组织架构暗色网格视图"功能时分了两个 PR：
- PR #303：前端网格视图 + UI spec + i18n（feature/org-dark-grid）
- PR #305：seed 脚本写入 21 个真部门 + 关联用户（feature/eai-orgchart-seed，从 develop 派生）

用户质问"就是同一件事，你怎么开了两个 PR"，并要求合一个。

## 错误根因

1. **机械套规则**：引用 CLAUDE.md「高风险路径必须单独 PR」，把 seed 脚本归类为"高风险"
2. **没读 user memory**：[feedback_ai_first_do_it_all.md](feedback_ai_first_do_it_all.md) 已经明确
   "AI-first 开发能做都做，不要主动建议拆 PR；硬信号才拆"
3. **没用 reviewer 视角**：拆 PR 后 reviewer 要：
   - 切两次分支验证（每次 1 分钟切 + 等 HMR）
   - 跨两个 PR 上下文对照（视图代码 vs 它消费的数据）
   - 协调合并顺序避免 develop 短暂"有数据没视图"或反之
4. **忽视"短期 slot 体验"成本**：拆 PR 后同一 slot 切分支会让前端工作树丢失另一边的代码
   → 用户开页面就 404（这次实际发生了）

## CLAUDE.md「高风险路径」的真意

回看原文："prisma/schema/**、docs/standards/**、CLAUDE.md、.gitea/workflows/**、API 契约面"
—— 共同特征是 **回滚代价高 + 影响面广 + 影响全仓库其他工作**。

Seed 脚本不符合这些特征：
- 失败可重跑（幂等 + `--reset-dev`）
- 仅影响某个 organization 的数据
- 跟同 PR 的视图代码完整匹配（视图读 metadata.category，seed 写 metadata.category）

它本质是"主功能的初始化数据"，应该跟主功能同 PR。

## 判断框架（下次自检）

按这个顺序问：

1. **用户视角这是一件事还是两件事？**（最重要）
   - "新组织架构页面 + 它的初始数据" → 一件事
   - "登录页改动 + 后端密码策略升级" → 一件事（前后端协同）
   - "登录页改动 + 报表导出修复" → 两件事
2. 不是同一件事的话，再问：
   - 是不是真"高风险"？schema/CI/契约面才是
   - 拆开是否真正减少 review 难度？
   - 拆开后合并顺序有依赖吗？
3. 如果不是同一件事 + 真高风险 + 拆开降低 review 难度 + 无强耦合 → 才拆

否则：**默认一个 PR**。AI 速度快，commit 多没关系。

## 已生效（修正动作）

- 把 seed commit cherry-pick 到 feature/org-dark-grid
- 关闭 PR #305 + 删除 feature/eai-orgchart-seed 分支（远端 + 本地）
- 更新到 PR #303 一个 PR 解决一件事

## 防御

新需求开始动手时如果出现"主功能 + 数据迁移 / 配套脚本 / 初始数据 / 文档"这种组合，
**先假设一个 PR**，只有遇到下面任一硬信号才拆：

- DB schema 变更（`prisma/migrations/` 下有新文件）
- CI workflow 改动（`.gitea/workflows/`）
- 公开 API 契约面变更（路径 / 方法 / 字段 / 错误码）
- 全局规则文档变更（`docs/standards/`、`CLAUDE.md`）
- 高频小更新 + 中立笔记类（用 `chore/notes-rolling`）

无硬信号 = 不拆。