📝 Change Log

2026-09-06 18:00:54作者：伍希望

📝 Change Log

Language	Changelog
🇺🇸 English	Fix Select dropdown scroll jumping during search
🇨🇳 Chinese	修复 Select 搜索时下拉列表滚动位置跳动问题


这条规则与仓库 CI 是互相咬合的。从 [pr-open-check.yml](https://gitcode.com/GitHub_Trending/an/ant-design/blob/58b0ee1554835b3ea2d0541f4986306f3d70d0ce/.github/workflows/pr-open-check.yml?utm_source=gitcode_repo_files) 可以看到，`PR Open Check` workflow 在 PR opened/edited/reopened/synchronize 事件上运行 `actions-cool/pr-check-fill` 任务，要求 PR 正文的 changelog 表格中必须填上 `🇺🇸 English, 🇨🇳 Chinese, 🇺🇸 英文, 🇨🇳 中文` 之一，否则机器人会评论提醒“请填写 PR 中的 changelog”；同时该任务配置了 `skip-title-start: 'docs, chore, test, ci'`，即标题以 docs、chore、test、ci 开头的 PR 会跳过该检查。这与 Skill 中“site/docs/demo/ci 用占位即可”的策略恰好呼应：占位写法既满足了模板 section 保留要求，也解释了为什么这些类型不需要实质 changelog。

## PR 标题写法：type(scope) 规范

标题要求汇总自 [SKILL.md](https://gitcode.com/GitHub_Trending/an/ant-design/blob/58b0ee1554835b3ea2d0541f4986306f3d70d0ce/.agents/skills/create-pr/SKILL.md?utm_source=gitcode_repo_files) 的“写法要求”章节：

- **必须是英文**；
- 默认先判断 `type`，再决定是否需要 `scope`；
- 优先使用 `type: subject` 或 `type(scope): subject`；
- 优先写**结果**，不写过程；
- 避免 `update`、`fix issues`、`misc changes` 这类空话；
- 覆盖整条分支的主要目标，不要照搬单个 commit message；
- `type` 要与类型判断步骤的结论一致；
- 若分支包含多类小改动，提炼一个更高层概括。

常用 `type` 参考：

| type | 含义 |
| --- | --- |
| `feat` | 新增能力 |
| `fix` | 修复问题 |
| `docs` | 文档或说明 |
| `refactor` | 重构 |
| `type` | 类型修正 |
| `site` | 站点相关改动 |
| `demo` | 示例相关改动 |
| `test` | 测试改动 |
| `ci` | CI 或 workflow |
| `chore` | 杂项维护 |
| `perf` | 性能优化 |

`scope` 使用规则：改动集中在单个组件或模块时再加，如 `refactor(Image): ...`；若没有明显聚焦对象，就不要硬加 scope；不要把目录名机械塞进 scope。

参考文档给出的正例与反例：

正例（贴近分支真实目标）：

- `fix(Select): keep dropdown scroll position stable during search`
- `docs: clarify Upload beforeUpload return behavior`
- `refactor(Table): simplify sticky offset calculation`
- `site: refine AI theme page empty state copy`
- `feat: add Typography.Shimmer component`
- `ci: adjust pull request label workflow`

反例（不要这样写）：

- `修复 Select 搜索后下拉滚动跳动问题`（中文标题）
- `update select`
- `fix issues`
- `some improvements`

## 先草稿确认，后执行 gh pr create

这是整个 Skill 的安全核心。**无论用户是否说“直接帮我创建 PR”**，都要先完成：

1. 生成 `base`、`title`、`body` 草稿；
2. 明确告诉用户：这是准备提交的 PR 内容；
3. 让用户确认是否继续创建，或先修改；
4. 只有用户明确确认后，才能真正执行 `gh pr create`。

若用户中途要求修改标题、类型、changelog、目标分支等，应先更新草稿，再次确认。信息不足时（基线分支、关联 issue、变动性质、测试或验证方式缺失且无法从分支改动中可靠推断），可以先给出草稿并把无法确认的地方保留为待补充项；即使用户要求直接创建 PR，也必须先说明缺失项并等待确认。

参考文档给出了一段可直接复用的确认话术模板：

```markdown
我先整理了一版待提交的 PR 草稿，请你确认：

- Base branch: `feature-x`
- PR title: `site: adjust token panel interaction on theme preview page`
- PR type: `📝 Site / documentation improvement`
- Change Log: `No changelog required`

如果没问题，我再继续创建 PR；如果你想改 title、type、base 或正文，我先帮你改。

草稿输出时至少包含 Base branch、PR title、PR body 和需要用户补充或确认的点，并明确询问用户是“直接创建 PR”还是“先修改后再创建”。

执行前的最后检查与创建命令

确认后、执行前还要再次检查：

git branch -vv
git remote -v
gh repo view --json nameWithOwner

检查要求：确认当前分支的 tracking remote 和远端分支正确；确认 PR 的目标仓库是 ant-design/ant-design，不要依赖 gh 默认推断；若 tracking remote 缺失、指向不明确、或不是预期 fork，先向用户确认，不要默认推送；只有在推送目标 remote 明确无误时，才推送当前分支。

推送与创建命令的建议形式：

git push -u <remote> HEAD

gh pr create --repo ant-design/ant-design --base <base> --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"

ant-design

An enterprise-class UI design language and React UI library

项目地址：https://gitcode.com/GitHub_Trending/an/ant-design

登录后查看全文

📝 Change Log

📝 Change Log

执行前的最后检查与创建命令

最新内容推荐

项目优选

📝 Change Log

📝 Change Log

执行前的最后检查与创建命令

相关内容推荐

最新内容推荐

项目优选