Merge branch 'QLHazyCoder:master' into codex-luckmail
This commit is contained in:
Q3CC
@@ -1,402 +0,0 @@
|
||||
# AI 版本发布标准流程
|
||||
|
||||
## 用途
|
||||
|
||||
本文用于给 AI 一个固定、完整、可重复执行的版本发布流程。
|
||||
|
||||
当用户在本仓库中引用本文，并明确说出类似下面的话时：
|
||||
|
||||
- `更新版本到 6.5.0`
|
||||
- `按本文发布 6.5.0`
|
||||
- `引用这个文件，把版本更新到 6.5.0 并发版`
|
||||
|
||||
AI 必须按本文执行，不能猜流程，不能跳步骤，不能只做一半。
|
||||
|
||||
## 目标
|
||||
|
||||
AI 在收到“更新版本到 x.x.x”后，必须完成下面两段流程。
|
||||
|
||||
1. 发布前流程。
|
||||
修改 `manifest.json` 中的版本号。
|
||||
提交本次准备发布的代码。
|
||||
基于“上一个 GitHub Release 到当前 HEAD”的真实差异分析更新内容。
|
||||
把发布文案先返回给用户看，且必须放在代码块里。
|
||||
|
||||
2. 用户确认后的发布流程。
|
||||
把用户确认过的文案作为 GitHub Release 正文发布。
|
||||
发布完成后，再次从 GitHub 线上读取正文。
|
||||
审查正文是否乱码、是否异常、是否与用户确认稿一致。
|
||||
如果有问题，必须立刻修正后再汇报完成。
|
||||
|
||||
## 仓库硬性规则
|
||||
|
||||
1. 任何结论都不能猜，必须基于真实命令输出、真实 diff、真实 GitHub 返回结果。
|
||||
2. GitHub Releases 是版本发布真相源。分析“距离上一个版本更新了什么”时，默认以上一个正式 Release 为起点。
|
||||
3. 不要先去检查 `gh` 是否存在、是否登录、是否在 PATH、是否可用，也不要先跑 `gh auth status`。直接使用固定路径命令执行。
|
||||
4. `gh` 固定路径使用：
|
||||
|
||||
```powershell
|
||||
$GH = 'C:\Program Files\GitHub CLI\gh.exe'
|
||||
if (-not (Test-Path $GH)) {
|
||||
throw 'gh.exe fixed path not found: C:\Program Files\GitHub CLI\gh.exe'
|
||||
}
|
||||
```
|
||||
|
||||
5. 默认 GitHub 仓库固定为：
|
||||
|
||||
```powershell
|
||||
$Repo = 'QLHazyCoder/codex-oauth-automation-extension'
|
||||
```
|
||||
|
||||
6. 默认不编译、不跑测试。完成后提醒用户自行测试。
|
||||
7. 如果当前工作区里存在无法确认是否属于本次发布的改动，必须先停下来问用户，不能猜哪些该一起发、哪些不该一起发。
|
||||
8. 发布完成后，必须做一次“线上正文复检”，确认不是乱码，不是空正文，不是错误版本，不是错误标签。
|
||||
|
||||
## 输入要求
|
||||
|
||||
AI 至少要从用户输入中拿到下面这些信息：
|
||||
|
||||
- 目标版本号，例如 `6.5.0`
|
||||
- 是否已经确认可以发布
|
||||
- 如果用户有特别强调的更新点，也要纳入发布文案
|
||||
|
||||
如果用户没有给版本号，就不能猜。
|
||||
|
||||
如果用户说的是口语化版本号，例如 `8`、`8.0`、`v8`、`v8.0`，AI 也不能直接猜最终版本号，必须先向用户确认标准版本号，例如 `8.0.0`。只有在用户明确确认后，后续所有命令、提交、tag、Release 标题、Release 正文都必须统一使用严格的三段版本号 `x.y.z`，不能继续混用口语化写法。
|
||||
|
||||
## 固定变量模板
|
||||
|
||||
每次执行本文时，先统一使用下面这组变量：
|
||||
|
||||
```powershell
|
||||
$GH = 'C:\Program Files\GitHub CLI\gh.exe'
|
||||
if (-not (Test-Path $GH)) {
|
||||
throw 'gh.exe fixed path not found: C:\Program Files\GitHub CLI\gh.exe'
|
||||
}
|
||||
|
||||
$Repo = 'QLHazyCoder/codex-oauth-automation-extension'
|
||||
$TargetVersion = '<用户确认后的标准版本号，必须使用 x.y.z，例如：6.5.0>'
|
||||
$TargetTag = "v$TargetVersion"
|
||||
$ManifestPath = 'manifest.json'
|
||||
```
|
||||
|
||||
## 阶段 1：发布前检查
|
||||
|
||||
### 1. 真实查看当前工作区
|
||||
|
||||
先执行：
|
||||
|
||||
```powershell
|
||||
git status --short --branch
|
||||
git remote -v
|
||||
```
|
||||
|
||||
要求：
|
||||
|
||||
1. 必须看清当前分支和当前未提交改动。
|
||||
2. 如果工作区中有改动，必须结合 diff 判断这些改动是不是本次要发布的真实内容。
|
||||
3. 如果有无法确认归属的改动，必须先问用户，不准猜。
|
||||
|
||||
### 2. 读取当前版本号
|
||||
|
||||
执行：
|
||||
|
||||
```powershell
|
||||
$Manifest = Get-Content -Path $ManifestPath -Raw | ConvertFrom-Json
|
||||
$CurrentVersion = [string]$Manifest.version
|
||||
$CurrentVersion
|
||||
```
|
||||
|
||||
要求：
|
||||
|
||||
1. 当前版本必须从 `manifest.json` 真实读取。
|
||||
2. 目标版本必须大于当前版本，不能相等，不能更小。
|
||||
3. 版本比较必须按版本号比较，不能按字符串比较。
|
||||
|
||||
示例校验：
|
||||
|
||||
```powershell
|
||||
if ([version]$TargetVersion -le [version]$CurrentVersion) {
|
||||
throw "Target version $TargetVersion must be greater than current version $CurrentVersion"
|
||||
}
|
||||
```
|
||||
|
||||
### 3. 检查目标版本是否已经存在
|
||||
|
||||
先查 GitHub Releases：
|
||||
|
||||
```powershell
|
||||
$ExistingReleaseTag = ([string](& $GH api "repos/$Repo/releases?per_page=100" --jq ".[] | select(.tag_name == `"$TargetTag`") | .tag_name")).Trim()
|
||||
```
|
||||
|
||||
再查本地 tag：
|
||||
|
||||
```powershell
|
||||
$ExistingLocalTag = ([string](git tag --list $TargetTag)).Trim()
|
||||
```
|
||||
|
||||
再查最新一个正式 Release：
|
||||
|
||||
```powershell
|
||||
$LatestReleaseTag = ([string](& $GH api "repos/$Repo/releases?per_page=100" --jq "[.[] | select(.draft == false and .prerelease == false)][0].tag_name")).Trim()
|
||||
$LatestReleaseVersion = if ($LatestReleaseTag) { $LatestReleaseTag.TrimStart('v') } else { '' }
|
||||
```
|
||||
|
||||
规则：
|
||||
|
||||
1. 只要 GitHub Release 已存在这个 tag，就必须停止，不能重复发版。
|
||||
2. 如果本地 tag 已存在，但 GitHub Release 不存在，也必须停止并告知用户先确认历史状态，不能直接覆盖。
|
||||
3. 如果已经存在最新正式 Release，目标版本还必须大于这个正式 Release 的版本号，不能倒发版。
|
||||
|
||||
示例校验：
|
||||
|
||||
```powershell
|
||||
if ($LatestReleaseVersion -and ([version]$TargetVersion -le [version]$LatestReleaseVersion)) {
|
||||
throw "Target version $TargetVersion must be greater than latest released version $LatestReleaseVersion"
|
||||
}
|
||||
```
|
||||
|
||||
## 阶段 2：更新版本号并提交
|
||||
|
||||
### 1. 修改 `manifest.json`
|
||||
|
||||
AI 必须只把 `manifest.json` 中的 `version` 更新为目标版本。
|
||||
|
||||
### 2. 检查变更内容
|
||||
|
||||
执行：
|
||||
|
||||
```powershell
|
||||
git diff --stat
|
||||
git diff -- manifest.json
|
||||
```
|
||||
|
||||
如果工作区里还有其他变更，也要继续真实查看它们的 diff，确认是否属于本次发布内容。
|
||||
|
||||
### 3. 提交本次发布
|
||||
|
||||
规则：
|
||||
|
||||
1. 如果当前工作区改动就是本次要发布的功能改动，就应与版本号一起提交。
|
||||
2. 如果存在来源不明或明显无关的改动，必须先停下来问用户，不能偷偷一起提交，也不能擅自丢掉。
|
||||
3. 提交信息统一使用：
|
||||
|
||||
```text
|
||||
chore(release): bump version to vX.Y.Z
|
||||
```
|
||||
|
||||
示例：
|
||||
|
||||
```powershell
|
||||
git add -A
|
||||
git commit -m "chore(release): bump version to $TargetTag"
|
||||
```
|
||||
|
||||
提交后，必须记录真实提交哈希：
|
||||
|
||||
```powershell
|
||||
git rev-parse HEAD
|
||||
```
|
||||
|
||||
## 阶段 3：分析“距离上一个版本更新了什么”
|
||||
|
||||
### 1. 获取上一个正式 Release
|
||||
|
||||
执行：
|
||||
|
||||
```powershell
|
||||
$PreviousReleaseTag = ([string](& $GH api "repos/$Repo/releases?per_page=100" --jq "[.[] | select(.draft == false and .prerelease == false)][0].tag_name")).Trim()
|
||||
$PreviousReleaseTag
|
||||
```
|
||||
|
||||
规则：
|
||||
|
||||
1. 默认取最新一个正式 Release 作为“上一个版本”。
|
||||
2. 如果仓库还没有任何正式 Release，再退回到本地最新 tag：
|
||||
|
||||
```powershell
|
||||
if (-not $PreviousReleaseTag) {
|
||||
$PreviousReleaseTag = ([string](git tag --sort=-creatordate | Select-Object -First 1)).Trim()
|
||||
}
|
||||
```
|
||||
|
||||
3. 如果仍然拿不到上一个版本，就按“首个版本发布”处理，并明确告诉用户这是首发版文案。
|
||||
|
||||
### 2. 拉真实变更范围
|
||||
|
||||
如果存在上一个版本，执行：
|
||||
|
||||
```powershell
|
||||
git log --oneline "$PreviousReleaseTag"..HEAD
|
||||
git diff --stat "$PreviousReleaseTag"..HEAD
|
||||
git diff --name-only "$PreviousReleaseTag"..HEAD
|
||||
```
|
||||
|
||||
然后根据变更文件继续往下读真实 diff，不能只看 commit 标题。
|
||||
|
||||
必要时继续执行：
|
||||
|
||||
```powershell
|
||||
git diff "$PreviousReleaseTag"..HEAD -- <具体文件路径>
|
||||
```
|
||||
|
||||
### 3. 文案分析要求
|
||||
|
||||
AI 必须基于真实 diff 和真实代码上下文，分析并提炼：
|
||||
|
||||
- 新增了什么功能
|
||||
- 修复了什么问题
|
||||
- 优化了什么逻辑
|
||||
- 删除了什么无用或陈旧逻辑
|
||||
- 哪些点最值得放进发布说明
|
||||
|
||||
禁止行为：
|
||||
|
||||
- 只看 commit message 就编文案
|
||||
- 把没有真实证据的内容写进发布说明
|
||||
- 把技术细节胡乱拔高成“重大更新”
|
||||
|
||||
## 阶段 4：先给用户看发布文案，不要直接发布
|
||||
|
||||
在真正发布前，AI 必须把文案返回给用户确认。
|
||||
|
||||
返回给用户时，必须同时说明：
|
||||
|
||||
1. `manifest.json` 已改到哪个版本
|
||||
2. 是否已经提交
|
||||
3. 本次提交哈希是什么
|
||||
4. 上一个版本标签是什么
|
||||
5. 发布文案草稿是什么
|
||||
|
||||
发布文案草稿必须放在代码块中，格式建议如下：
|
||||
|
||||
```markdown
|
||||
## vX.Y.Z
|
||||
|
||||
### 更新内容
|
||||
- ...
|
||||
- ...
|
||||
|
||||
### 修复与优化
|
||||
- ...
|
||||
- ...
|
||||
```
|
||||
|
||||
注意：
|
||||
|
||||
1. 这里必须先停下来等用户确认。
|
||||
2. 用户没确认前，不准创建 GitHub Release。
|
||||
3. 如果用户要求改文案，只改文案，不要乱改已经完成的代码与提交，除非用户明确要求。
|
||||
|
||||
## 阶段 5：用户确认后再发布 GitHub Release
|
||||
|
||||
### 1. 先推送当前提交
|
||||
|
||||
发布前先把当前分支 HEAD 推到远端：
|
||||
|
||||
```powershell
|
||||
git push origin HEAD
|
||||
```
|
||||
|
||||
### 2. 把用户确认过的文案写入 UTF-8 文件
|
||||
|
||||
不要直接把长正文硬塞进命令参数里，先写入临时文件。
|
||||
|
||||
示例：
|
||||
|
||||
```powershell
|
||||
$ReleaseNotesFile = Join-Path $env:TEMP "codex-release-$TargetVersion.md"
|
||||
$Utf8NoBom = New-Object System.Text.UTF8Encoding($false)
|
||||
[System.IO.File]::WriteAllText($ReleaseNotesFile, $ReleaseNotes, $Utf8NoBom)
|
||||
```
|
||||
|
||||
### 3. 创建 Release
|
||||
|
||||
执行：
|
||||
|
||||
```powershell
|
||||
& $GH release create $TargetTag `
|
||||
--repo $Repo `
|
||||
--target HEAD `
|
||||
--title $TargetTag `
|
||||
--notes-file $ReleaseNotesFile
|
||||
```
|
||||
|
||||
要求：
|
||||
|
||||
1. 标题默认使用 `vX.Y.Z`。
|
||||
2. 正文必须使用用户确认过的最终文案。
|
||||
3. 不要在用户没确认前抢先发版。
|
||||
|
||||
## 阶段 6：发布后线上正文复检
|
||||
|
||||
Release 创建完成后，必须立刻重新读取线上内容。
|
||||
|
||||
执行：
|
||||
|
||||
```powershell
|
||||
& $GH api "repos/$Repo/releases/tags/$TargetTag"
|
||||
& $GH api "repos/$Repo/releases/tags/$TargetTag" --jq '.html_url'
|
||||
& $GH api "repos/$Repo/releases/tags/$TargetTag" --jq '.tag_name'
|
||||
& $GH api "repos/$Repo/releases/tags/$TargetTag" --jq '.name'
|
||||
& $GH api "repos/$Repo/releases/tags/$TargetTag" --jq '.body'
|
||||
```
|
||||
|
||||
复检重点：
|
||||
|
||||
1. 线上 tag 是否真的是目标 tag
|
||||
2. 线上标题是否真的是目标版本
|
||||
3. 线上正文是否完整
|
||||
4. 正文是否与用户确认稿一致
|
||||
5. 是否存在乱码、异常字符、错误换行、空正文
|
||||
|
||||
尤其注意下面这些异常：
|
||||
|
||||
- 出现明显乱码字符
|
||||
- 中文被破坏
|
||||
- 正文为空
|
||||
- 版本号不对
|
||||
- 正文内容被截断
|
||||
|
||||
### 如果复检发现异常
|
||||
|
||||
必须立刻修复，不准带病汇报完成。
|
||||
|
||||
修复示例：
|
||||
|
||||
```powershell
|
||||
& $GH release edit $TargetTag `
|
||||
--repo $Repo `
|
||||
--title $TargetTag `
|
||||
--notes-file $ReleaseNotesFile
|
||||
```
|
||||
|
||||
修复后，再重复执行一次“发布后线上正文复检”，直到线上内容正常为止。
|
||||
|
||||
## 用户侧最终反馈要求
|
||||
|
||||
AI 完成后，对用户的最终反馈至少要说明：
|
||||
|
||||
1. 已把 `manifest.json` 更新到哪个版本
|
||||
2. 是否已经提交，提交哈希是什么
|
||||
3. 上一个版本是什么
|
||||
4. 发布文案是否经过用户确认
|
||||
5. 是否已经创建 GitHub Release
|
||||
6. 是否已经完成线上正文复检
|
||||
7. 如果没跑测试，要明确提醒用户自行测试
|
||||
|
||||
## 一句话执行要求
|
||||
|
||||
当用户引用本文并说“更新版本到 x.x.x”时，AI 必须按下面顺序执行：
|
||||
|
||||
1. 真实检查工作区与当前版本
|
||||
2. 真实校验目标版本是否合法且未发布
|
||||
3. 修改 `manifest.json` 版本号
|
||||
4. 提交本次待发布改动
|
||||
5. 基于上一个正式 Release 到当前 HEAD 的真实差异分析更新内容
|
||||
6. 把发布文案放进代码块返回给用户确认
|
||||
7. 得到确认后再推送并创建 GitHub Release
|
||||
8. 发布完成后再次读取线上正文并检查是否乱码
|
||||
9. 如有异常，先修复再汇报
|
||||
|
||||
不能跳步骤，不能猜，不能偷懒。
|
||||
@@ -0,0 +1,301 @@
|
||||
# 仓库协作者用 AI 分析 PR 与合并标准流程
|
||||
|
||||
## 用途
|
||||
|
||||
本文件用于给仓库协作者自己电脑上的 AI 一个固定、完整、可重复执行的 PR 处理流程。
|
||||
|
||||
下次只要告诉 AI：
|
||||
|
||||
- 本仓库根目录
|
||||
- 要处理的 PR 编号
|
||||
- 是否只分析，还是分析后需要继续合并
|
||||
|
||||
再把本文件提供给 AI，AI 就必须按本文件执行，不能自行脑补流程。
|
||||
|
||||
## 仓库硬性规则
|
||||
|
||||
1. 任何结论都不能猜，必须基于真实命令输出、真实 diff、真实代码上下文。
|
||||
2. 优先使用当前环境可直接执行的 `gh`、`git` 命令；如果命令不存在、认证失败、权限不足，必须立刻明确告知用户并停止，不能假装已经操作成功。
|
||||
3. 本仓库自动处理的唯一目标分支是 `dev`。AI 不得把其他作者的 PR 直接作为自动流程合并到 `master`。
|
||||
4. 任何分支判断都必须以实时 `gh pr view` 返回的 `baseRefName` 为准，不能只信用户口述、PR 标题或截图描述。
|
||||
5. 如果 PR 当前目标分支是 `master`，AI 必须先自动把它改到 `dev`，然后重新拉取 PR 元数据与 diff，再继续分析。
|
||||
6. 如果 PR 当前目标分支既不是 `dev` 也不是 `master`，AI 不得擅自改到别的分支，必须停止并告诉用户当前自动流程只支持 `dev`。
|
||||
7. 如果把 `master` 转到 `dev` 时发现同一个来源仓库 + 来源分支已经存在另一个指向 `dev` 的打开 PR，AI 不得继续硬转，不得继续自动合并，必须先反馈重复 PR 问题。
|
||||
8. 用户当前工作区可能是脏的，不能直接在当前工作区切分支、切换分支、硬合并。需要使用临时 `worktree`。
|
||||
9. 如果合并后需要本地修复，优先删除无用旧逻辑，避免继续堆积陈旧代码。
|
||||
10. 默认不编译测试。处理完成后提醒用户自行测试。
|
||||
11. 任何 GitHub 评论、回复、感谢留言发出后，AI 都必须立即再读一遍线上实际内容，确认正文不是乱码、不是 `?`、不是编码异常；如果发现异常，必须立刻修正后再继续后续流程。
|
||||
12. 如果流程执行过程中，PR 的实时目标分支被别人改掉，或者不再是 `dev`，AI 必须停止当前合并流程，重新拉取信息后再决定下一步。
|
||||
|
||||
## 输入要求
|
||||
|
||||
AI 至少要拿到下面这些输入：
|
||||
|
||||
- `PR 编号`
|
||||
- `仓库路径`
|
||||
- 本次目标：`只分析` / `分析后需要继续合并`
|
||||
- 如果需要继续合并：是否允许 AI 直接本地修复冲突和问题
|
||||
|
||||
补充要求：
|
||||
|
||||
- 如果 AI 不能从当前仓库自动识别 `OWNER/REPO`，则用户还需要补充提供。
|
||||
- 本流程默认允许 AI 在检测到 `master` 为目标分支时，直接远程改成 `dev`；如果用户明确禁止任何远程修改，则本流程不适用。
|
||||
|
||||
## 总流程
|
||||
|
||||
### 阶段 1：准备、目标分支校正与信息拉取
|
||||
|
||||
AI 必须先执行下面这些动作，不能跳步：
|
||||
|
||||
1. 检查当前仓库状态：
|
||||
- `git status --short --branch`
|
||||
- `git remote -v`
|
||||
2. 拉取 PR 元数据：
|
||||
|
||||
```powershell
|
||||
gh pr view <PR_NUMBER> --repo <OWNER/REPO> --json number,title,body,author,baseRefName,headRefName,headRepository,headRepositoryOwner,changedFiles,additions,deletions,commits,files,isDraft,mergeStateStatus,mergeable,state,url
|
||||
```
|
||||
|
||||
3. 先根据实时 `baseRefName` 处理目标分支：
|
||||
- 如果 `baseRefName = dev`：继续下一步。
|
||||
- 如果 `baseRefName = master`：先执行“自动转到 `dev`”流程，再继续下一步。
|
||||
- 如果 `baseRefName` 既不是 `dev` 也不是 `master`：立即停止，并向用户反馈“当前自动流程只支持 `dev`”。
|
||||
|
||||
4. 当 `baseRefName = master` 时，必须执行下面的自动转分支流程：
|
||||
|
||||
```powershell
|
||||
gh api --method GET repos/<OWNER/REPO>/pulls -f state=open -f head='<HEAD_OWNER>:<HEAD_REF>' -f base='dev' -f per_page='100'
|
||||
```
|
||||
|
||||
处理规则：
|
||||
|
||||
1. 先从上一步 PR 元数据中读取真实的 `HEAD_OWNER` 与 `HEAD_REF`，不能猜。
|
||||
2. 如果查询结果中已经存在 `number != <PR_NUMBER>` 的打开 PR，则视为“重复的 dev PR”：
|
||||
- 不再执行转分支
|
||||
- 不再继续自动分析旧 diff
|
||||
- 先反馈给当前用户，必要时再给 PR 留言说明
|
||||
3. 如果不存在重复的 dev PR，则执行：
|
||||
|
||||
```powershell
|
||||
gh pr edit <PR_NUMBER> --base dev --repo <OWNER/REPO>
|
||||
```
|
||||
|
||||
4. 改完目标分支后，必须重新执行一次 PR 元数据拉取，确认新的 `baseRefName = dev`。
|
||||
5. 在重新确认 `baseRefName = dev` 之前，不允许继续分析旧 diff，不允许继续合并。
|
||||
|
||||
5. 只有在目标分支已经确认是 `dev` 后，才能拉取 PR diff：
|
||||
|
||||
```powershell
|
||||
gh pr diff <PR_NUMBER> --repo <OWNER/REPO>
|
||||
```
|
||||
|
||||
6. 拉取目标分支与 PR 头：
|
||||
|
||||
```powershell
|
||||
git fetch origin dev
|
||||
git fetch origin pull/<PR_NUMBER>/head:refs/remotes/origin/pr-<PR_NUMBER>
|
||||
```
|
||||
|
||||
7. 如果需要稳定查看行号、文件内容、避免污染当前工作区，创建临时 `worktree`：
|
||||
|
||||
```powershell
|
||||
$TempWorktree = '<临时目录>'
|
||||
git worktree add --detach $TempWorktree origin/pr-<PR_NUMBER>
|
||||
```
|
||||
|
||||
### 阶段 2：分析与审查
|
||||
|
||||
AI 分析时，必须完整执行下面这些要求：
|
||||
|
||||
1. 不能只看 PR 描述，必须结合真实 diff 和仓库现有代码上下文一起分析。
|
||||
2. 如果阶段 1 发生过 `master -> dev` 自动转向，分析时只能基于转向后的最新 diff，不得继续引用转向前的 diff 结论。
|
||||
3. 对于高风险文件，必须继续读取改动函数周边逻辑，确认消息流、状态流、配置项、回调流程、页面跳转流程是否一致。
|
||||
4. 必须分析并输出：
|
||||
- 这个 PR 改了什么
|
||||
- 这些改动是否合理
|
||||
- 是否存在 bug / 风险 / 逻辑冲突
|
||||
- PR 当前是否可直接合并，例如 `mergeable`、`mergeStateStatus`
|
||||
5. 如果发现问题，结论必须按严重级别排序，优先写真正会影响功能、合并或后续维护的问题。
|
||||
6. 如果没有发现明确问题，也要说明剩余风险，例如：
|
||||
- 未运行测试
|
||||
- 需要人工验证真实业务接口
|
||||
- 当前仅完成静态分析
|
||||
7. 在准备进入后续合并步骤前，必须再拉取一次实时 PR 元数据，确认：
|
||||
- PR 仍然是打开状态
|
||||
- PR 不是 draft
|
||||
- `baseRefName` 仍然是 `dev`
|
||||
|
||||
## 分析后评论规则
|
||||
|
||||
### 有问题时
|
||||
|
||||
如果发现需要作者或维护者注意的问题，AI 必须自动发 PR 评论，并且评论格式必须固定如下：
|
||||
|
||||
```text
|
||||
（自动回复）AI分析结果（不一定完全正确，请仓库协作者确认无问题后再继续）：
|
||||
|
||||
<这里写正式评论内容>
|
||||
```
|
||||
|
||||
要求：
|
||||
|
||||
1. 第一行必须完全使用上面的标题，不能改字。
|
||||
2. 标题下方必须空一行，再写正文。
|
||||
3. 正文内容要直接写问题，不要再套娃解释“下面是分析结果”。
|
||||
4. 评论内容必须基于实际检查到的问题，不能编。
|
||||
5. 评论发出后，必须立刻回读该评论的线上正文，确认不是乱码；如果有乱码，必须先修正评论，再继续后续动作。
|
||||
|
||||
### 没问题时
|
||||
|
||||
如果没有发现明确问题：
|
||||
|
||||
1. 先把分析结果反馈给当前用户。
|
||||
2. 不强制给 PR 留问题评论。
|
||||
3. 是否继续合并，取决于用户命令。
|
||||
|
||||
## 带问题继续合并的规则
|
||||
|
||||
如果 PR 有问题，但用户明确要求：
|
||||
|
||||
- 不等待 PR 作者修复
|
||||
- 由当前 AI 直接本地处理冲突和问题
|
||||
- 处理完成后继续合并
|
||||
|
||||
则必须进入下面的流程。
|
||||
|
||||
### 阶段 3：临时工作区合并
|
||||
|
||||
禁止在用户当前工作区直接乱合并。
|
||||
|
||||
必须先创建临时 `worktree`，再在临时目录内处理：
|
||||
|
||||
```powershell
|
||||
git fetch origin dev
|
||||
git fetch origin pull/<PR_NUMBER>/head:refs/remotes/origin/pr-<PR_NUMBER>
|
||||
git worktree add <TEMP_WORKTREE> -b pr-<PR_NUMBER>-merge origin/dev
|
||||
```
|
||||
|
||||
进入临时目录后再执行：
|
||||
|
||||
```powershell
|
||||
git merge --no-ff --no-commit origin/pr-<PR_NUMBER>
|
||||
```
|
||||
|
||||
处理规则：
|
||||
|
||||
1. 如果阶段 1 发生过 `master -> dev` 自动转向，本阶段必须以 `dev` 为唯一合并基准，不允许再回到 `master` 做本地吸收。
|
||||
2. 如果出现冲突，先解决冲突，再继续检查相关联逻辑。
|
||||
3. 不能只消掉冲突标记就结束，必须继续看是否有设计冲突、状态字段不一致、调用链断裂、配置项名不一致、回调逻辑互相打架的问题。
|
||||
4. 如果 PR 本身逻辑有 bug，而用户又明确要求继续合并，AI 需要直接在本地修正。
|
||||
5. 修正时要清理无用旧代码，避免留下史山。
|
||||
6. 如果改了 SQL，按仓库规则同步本地 MySQL `xzs`。
|
||||
|
||||
### 阶段 4：本地修复后的自检清单
|
||||
|
||||
完成临时合并与本地修复后，必须自检下面这些项目：
|
||||
|
||||
1. `git status` 中不能再有未处理冲突。
|
||||
2. 相关文件中不能残留冲突标记。
|
||||
3. 新旧逻辑之间不能出现字段名、消息名、步骤编号、状态名不一致。
|
||||
4. 需要检查与本次功能直接相关的上下游代码，不能只改当前冲突文件。
|
||||
5. 要重新查看最终 diff，确认本地修复没有引入明显回归。
|
||||
6. 要重新拉取一次实时 PR 元数据，确认该 PR 的 `baseRefName` 仍然是 `dev`；如果不是，停止后续合并并先反馈用户。
|
||||
7. 默认不编译测试，最后提醒用户自行测试。
|
||||
|
||||
## 合并提交信息规则
|
||||
|
||||
如果最后决定真正合并，提交信息不能直接写：
|
||||
|
||||
- `merge branch xxx`
|
||||
- `merge pr #19`
|
||||
- `合并某某分支`
|
||||
|
||||
必须重新分析“最终合并结果到底做了什么”，然后重写提交信息。
|
||||
|
||||
### 提交信息要求
|
||||
|
||||
1. 标题必须描述最终落地功能，不是描述 Git 动作。
|
||||
2. 标题要体现核心改动结果，而不是“从哪里合并过来”。
|
||||
3. 正文要写清楚：
|
||||
- 这次吸收了 PR 的什么内容
|
||||
- 本地额外修复了什么冲突或 bug
|
||||
- 对哪些关键流程做了调整
|
||||
|
||||
### 推荐格式
|
||||
|
||||
```text
|
||||
<type>: <最终功能或修复结果>
|
||||
|
||||
- 合并 PR #<PR_NUMBER> 的核心改动：<一句话概括>
|
||||
- 本地补充修复：<一句话概括>
|
||||
- 影响范围：<步骤/模块/页面/接口>
|
||||
```
|
||||
|
||||
### 示例
|
||||
|
||||
```text
|
||||
feat: support SUB2API mode for OAuth generation and callback handling
|
||||
|
||||
- 合并 PR #19 的核心改动：新增 SUB2API 模式并接入 OAuth 生成与回调提交流程
|
||||
- 本地补充修复：修正回调地址约束与超时重试带来的重复执行风险
|
||||
- 影响范围：background orchestration、sidepanel config、sub2api content script
|
||||
```
|
||||
|
||||
## 最终合并与收尾
|
||||
|
||||
如果本地已经解决该 PR 的内容，并且最终代码已经进入 `dev` 分支，则继续执行下面动作。
|
||||
|
||||
### 1. 感谢作者
|
||||
|
||||
此时需要自动给 PR 留一条感谢评论。
|
||||
|
||||
注意：
|
||||
|
||||
1. 感谢评论不要带问题评论的固定标题。
|
||||
2. 直接正常感谢即可。
|
||||
3. 感谢内容要基于真实贡献，语气简洁。
|
||||
4. 如果阶段 1 发生过 `master -> dev` 自动转向，感谢评论不能把最终落地分支写错，必须明确本次内容已吸收到 `dev`。
|
||||
5. 感谢评论发出后，也必须立刻回读线上正文，确认不是乱码；如果有乱码，必须先修正评论，再进行关闭 PR 等后续动作。
|
||||
|
||||
示例：
|
||||
|
||||
```text
|
||||
感谢贡献这次改动，核心思路和主体实现已经吸收进 dev 分支了。我这边补了一下合并过程里的冲突和相关修正，后续如果你还有类似改进也欢迎继续提交。
|
||||
```
|
||||
|
||||
### 2. 自动关闭 PR
|
||||
|
||||
如果 PR 还没有因为合并而自动关闭，则感谢评论发完后，自动关闭该 PR：
|
||||
|
||||
```powershell
|
||||
gh pr close <PR_NUMBER> --repo <OWNER/REPO>
|
||||
```
|
||||
|
||||
如果需要，先评论再关闭，不要把感谢遗漏掉。
|
||||
|
||||
### 3. 评论编码复检
|
||||
|
||||
无论是问题评论、感谢评论，还是其他直接发到 GitHub 的回复，只要消息已经发出，AI 必须执行一次“发送后复检”：
|
||||
|
||||
1. 重新读取该评论/回复在线上的实际正文。
|
||||
2. 检查是否存在乱码、异常问号、编码错乱、BOM 污染等问题。
|
||||
3. 如果有问题，必须立即编辑修正，直到线上正文正常为止。
|
||||
4. 编码复检完成前，不允许声称“评论已发送完成”。
|
||||
|
||||
## 用户侧最终反馈要求
|
||||
|
||||
AI 在对当前用户做最终反馈时，至少要说明：
|
||||
|
||||
1. 做了哪些真实动作
|
||||
2. PR 原始目标分支是否是 `master`
|
||||
3. 是否已经执行 `master -> dev` 自动转向
|
||||
4. 是否发现重复的 `dev` PR
|
||||
5. 是否发现问题
|
||||
6. 是否已经发了 PR 评论
|
||||
7. 是否已经本地合并并修复
|
||||
8. 是否已经关闭 PR
|
||||
9. 如果改了代码但没跑测试，要明确提醒用户测试
|
||||
|
||||
## 给 AI 的一句话执行要求
|
||||
|
||||
拿到本文件后，AI 必须按“先真实读取 PR 元数据，先校正目标分支，再拉取最新 diff 做分析，再按用户要求决定是否进入临时合并修复，最后重写提交信息并在完成后感谢作者、关闭 PR”的顺序执行，不能跳步，不能猜，不能偷懒。
|
||||
+372
@@ -0,0 +1,372 @@
|
||||
# 开发者 AI 开发与 PR 流程
|
||||
|
||||
请开发者们先让自己的 AI 阅读此文件。
|
||||
|
||||
AI 在本仓库里进行开发、整理改动、发起 PR、更新 PR、补充说明时，都必须按本文执行，不能跳步，不能猜，不能自创流程。
|
||||
|
||||
本文面向“开发者自己电脑上的 AI”，不是给仓库维护者批量处理别人 PR 用的，也不是版本发布流程。
|
||||
|
||||
## 使用前准备
|
||||
|
||||
在让 AI 操作 GitHub 之前，开发者本机必须先安装 GitHub CLI，并完成登录。
|
||||
|
||||
最低要求：
|
||||
|
||||
1. 本机已安装 `git`
|
||||
2. 本机已安装 GitHub CLI，也就是 `gh`
|
||||
3. 已完成 GitHub 登录
|
||||
4. 当前账号对目标仓库至少有读取权限；如果要推分支、改 PR、合并 PR，还需要对应写权限
|
||||
|
||||
登录示例：
|
||||
|
||||
```powershell
|
||||
gh auth login
|
||||
```
|
||||
|
||||
如果 AI 检查到 `gh` 不可用，或者 `gh auth status` 显示未登录、登录到错误账号、权限不足，则必须先停止并明确告诉开发者，不准假装已经完成 GitHub 操作。
|
||||
|
||||
## 本文适用场景
|
||||
|
||||
适用于下面这些任务：
|
||||
|
||||
- 开发新功能
|
||||
- 修复 bug
|
||||
- 清理陈旧逻辑
|
||||
- 整理本地提交
|
||||
- 发起新的 PR
|
||||
- 更新已有 PR
|
||||
- 在自己的 PR 下补充说明
|
||||
- 在权限允许时，把自己的 PR 合并到 `dev`
|
||||
|
||||
不适用于：
|
||||
|
||||
- 版本发布
|
||||
- 直接把代码合并到 `master`
|
||||
- 在没看代码上下文的前提下，靠猜测生成 PR 结论
|
||||
|
||||
## 仓库硬性规则
|
||||
|
||||
1. 任何结论都不能猜，必须基于真实命令输出、真实 diff、真实代码上下文。
|
||||
2. 开发基线分支只能是 `dev`。AI 不得以 `master` 作为日常开发起点，也不得把 PR 目标分支设为 `master`。
|
||||
3. 发起 PR 前，必须先同步最新远端提交，确保当前分支已经对齐最新 `origin/dev`。
|
||||
4. 如果发现当前 PR 的目标分支是 `master`，AI 必须立刻改为 `dev`，然后重新检查 PR 信息。
|
||||
5. 如果当前工作区有无法确认归属的脏改动，AI 必须先停下来告诉开发者，不能偷偷带进本次 PR，也不能擅自删除。
|
||||
6. 开发新功能时，不要为了兼容旧逻辑而保留明显无用的陈旧代码；如果确认无其他代码依赖，应一并清理。
|
||||
7. 如果旧逻辑本身设计差、实现混乱或者存在 bug，AI 需要继续检查相关调用点；在不影响其他功能的前提下，可以顺手一起修正。
|
||||
8. 如果改动了 SQL 文件，必须按仓库规则同步本地 MySQL：账号 `root`，密码 `123456`，数据库 `xzs`。
|
||||
9. 默认不编译、不跑测试。开发完成后提醒开发者自行测试。
|
||||
10. 如果是前端改动且没有新增依赖，只提醒开发者自己测试即可；如果新增了依赖并完成安装，可以自行验证能否启动，验证后要关闭启动占用的端口，并提醒开发者重新启动。
|
||||
11. PR 标题、PR 正文、PR 评论都用自然中文直接表达，不要写“自动回复”“AI 分析结果如下”这种固定机器人腔。
|
||||
12. 没有开发者明确授权时，AI 不得擅自合并 PR、关闭 PR、删除远端分支。
|
||||
|
||||
## 开发者需要提供给 AI 的信息
|
||||
|
||||
至少提供下面这些内容：
|
||||
|
||||
- 仓库本地路径
|
||||
- 本次要做的功能或问题描述
|
||||
- 是新任务，还是继续一个已有分支/已有 PR
|
||||
- 如果已经有 PR，要提供 PR 编号
|
||||
- 是否允许 AI 在自己的功能分支上执行 `rebase`
|
||||
- 是否允许 AI 在最后直接发起 PR
|
||||
- 如果 PR 已经审完，是否允许 AI 直接合并到 `dev`
|
||||
|
||||
如果这些关键信息缺失，AI 不能靠猜来补。
|
||||
|
||||
## 标准执行顺序
|
||||
|
||||
### 阶段 1：环境确认与仓库现状检查
|
||||
|
||||
AI 开始干活前，先执行下面这些动作：
|
||||
|
||||
```powershell
|
||||
gh --version
|
||||
gh auth status
|
||||
git status --short --branch
|
||||
git remote -v
|
||||
git branch --show-current
|
||||
git fetch origin
|
||||
```
|
||||
|
||||
要求：
|
||||
|
||||
1. 必须先确认 `gh` 可用且已登录。
|
||||
2. 必须确认当前仓库远端是正确仓库。
|
||||
3. 必须确认当前工作区是否有未提交改动。
|
||||
4. 不能在没看当前分支状态的情况下直接开始写代码或直接发 PR。
|
||||
|
||||
### 阶段 2：先对齐最新 `dev`
|
||||
|
||||
#### 场景 A：这是一个新任务
|
||||
|
||||
如果是新任务，还没开始写代码，则必须先同步最新 `dev`：
|
||||
|
||||
```powershell
|
||||
git switch dev
|
||||
git pull --ff-only origin dev
|
||||
git switch -c <feature-branch>
|
||||
```
|
||||
|
||||
规则：
|
||||
|
||||
1. 新任务必须从最新 `dev` 拉出功能分支。
|
||||
2. 不允许直接在 `dev` 上开发。
|
||||
3. 不允许从 `master` 拉开发分支。
|
||||
|
||||
#### 场景 B：这是一个已有分支上的继续开发
|
||||
|
||||
如果开发已经在某个功能分支上进行，则不能为了同步 `dev` 直接丢本地改动。
|
||||
|
||||
这时至少要先执行：
|
||||
|
||||
```powershell
|
||||
git fetch origin
|
||||
git rev-list --left-right --count origin/dev...HEAD
|
||||
git log --oneline HEAD..origin/dev
|
||||
```
|
||||
|
||||
要求：
|
||||
|
||||
1. 必须真实判断当前分支是否已经落后于 `origin/dev`。
|
||||
2. 如果当前分支落后，先继续开发可以，但在发起 PR 前必须补齐最新 `dev`。
|
||||
3. 如果当前分支已经出现复杂冲突风险，AI 需要提前告诉开发者，不要拖到最后一刻再爆。
|
||||
|
||||
### 阶段 3：开发与本地整理
|
||||
|
||||
AI 开发时，必须遵守下面这些要求：
|
||||
|
||||
1. 先读相关代码上下文，再改代码。
|
||||
2. 不能只改表面调用点，必须检查相关联的状态流、配置项、消息流、页面流程、回调流程。
|
||||
3. 如果发现本次功能附近本来就有坏逻辑，而且修复不会影响其他已使用代码，可以顺手一并修正。
|
||||
4. 如果为了完成新功能必须删除旧逻辑，就删除，不要为了“看起来兼容”堆陈旧代码。
|
||||
5. 改完后必须自己检查：
|
||||
- `git diff --stat`
|
||||
- `git diff`
|
||||
- 相关文件中是否残留冲突标记
|
||||
- 是否混入无关改动
|
||||
6. 如果改了 SQL，别忘了同步本地 MySQL `xzs`。
|
||||
|
||||
### 阶段 4：发起 PR 前必须再次同步最新 `dev`
|
||||
|
||||
这是硬规则。
|
||||
|
||||
无论这个分支什么时候开始开发，只要准备发起 PR，就必须再次拉取远端最新提交，并确认当前分支已经吸收了最新 `origin/dev`。
|
||||
|
||||
先执行：
|
||||
|
||||
```powershell
|
||||
git fetch origin
|
||||
git log --oneline HEAD..origin/dev
|
||||
```
|
||||
|
||||
#### 如果 `origin/dev` 没有新提交
|
||||
|
||||
可以继续进入下一阶段。
|
||||
|
||||
#### 如果 `origin/dev` 有新提交
|
||||
|
||||
优先处理方式：
|
||||
|
||||
```powershell
|
||||
git rebase origin/dev
|
||||
```
|
||||
|
||||
如果开发者明确禁止改写当前分支历史，或者这个分支已经有多人共同使用，再改用：
|
||||
|
||||
```powershell
|
||||
git merge origin/dev
|
||||
```
|
||||
|
||||
处理规则：
|
||||
|
||||
1. 如果执行了 `rebase`，必须重新检查 diff，确认没有把逻辑改坏。
|
||||
2. 如果执行了 `rebase` 且当前分支之前已经推到远端，后续推送时只能使用：
|
||||
|
||||
```powershell
|
||||
git push --force-with-lease origin <feature-branch>
|
||||
```
|
||||
|
||||
3. 不允许使用 `git push --force`。
|
||||
4. 不能只把冲突标记删掉就算完，必须继续检查冲突两边的真实逻辑是否仍然一致。
|
||||
|
||||
### 阶段 5：提交与推送
|
||||
|
||||
在发起 PR 前，AI 必须先把本次改动整理干净。
|
||||
|
||||
至少要执行下面这些检查：
|
||||
|
||||
```powershell
|
||||
git status --short
|
||||
git diff --stat origin/dev...HEAD
|
||||
git diff origin/dev...HEAD
|
||||
```
|
||||
|
||||
要求：
|
||||
|
||||
1. PR 中只能包含与本次任务相关的改动。
|
||||
2. 不要把临时调试代码、无关格式化、无关文件重命名、构建产物一起带进 PR。
|
||||
3. 提交信息必须描述真实功能结果，不要写：
|
||||
- `update`
|
||||
- `fix bug`
|
||||
- `merge branch`
|
||||
- `修改一下`
|
||||
4. 推送前要确认当前分支不是 `dev`，也不是 `master`。
|
||||
|
||||
推送示例：
|
||||
|
||||
```powershell
|
||||
git push -u origin <feature-branch>
|
||||
```
|
||||
|
||||
### 阶段 6：创建或更新 PR
|
||||
|
||||
PR 只能指向 `dev`。
|
||||
|
||||
创建 PR 时使用：
|
||||
|
||||
```powershell
|
||||
gh pr create --base dev --head <feature-branch> --title "<PR标题>" --body-file <PR正文文件>
|
||||
```
|
||||
|
||||
如果 PR 已经存在，则执行：
|
||||
|
||||
```powershell
|
||||
gh pr view <PR_NUMBER> --json number,title,baseRefName,headRefName,state,isDraft,url
|
||||
```
|
||||
|
||||
如果发现已有 PR 的目标分支不是 `dev`，必须改正：
|
||||
|
||||
```powershell
|
||||
gh pr edit <PR_NUMBER> --base dev
|
||||
```
|
||||
|
||||
改完后，再重新读取一次 PR 信息，确认：
|
||||
|
||||
- `baseRefName = dev`
|
||||
- PR 仍是 open
|
||||
- head 分支正确
|
||||
|
||||
#### PR 标题要求
|
||||
|
||||
1. 直接描述功能结果或修复结果。
|
||||
2. 不要把标题写成 Git 动作描述。
|
||||
3. 不要写空洞标题。
|
||||
|
||||
#### PR 正文要求
|
||||
|
||||
PR 正文直接写真实信息，建议结构如下：
|
||||
|
||||
```markdown
|
||||
## 本次改动
|
||||
- ...
|
||||
|
||||
## 风险与影响
|
||||
- ...
|
||||
|
||||
## 测试情况
|
||||
- 未运行测试，请开发者自行验证
|
||||
```
|
||||
|
||||
说明：
|
||||
|
||||
1. 正文必须基于真实改动来写。
|
||||
2. 不要写固定“自动回复”抬头。
|
||||
3. 不要写和代码不相符的夸大表述。
|
||||
|
||||
### 阶段 7：PR 后续补充说明
|
||||
|
||||
如果 AI 需要在 PR 里补充评论、解释冲突、说明待确认点，要求如下：
|
||||
|
||||
1. 直接写清楚问题、原因、影响、建议。
|
||||
2. 语气自然、简洁、可读。
|
||||
3. 不要使用固定机器人模板。
|
||||
4. 不要为了“像 AI”而加免责声明废话。
|
||||
5. 评论内容必须和真实代码、真实 diff、真实冲突一致。
|
||||
|
||||
### 阶段 8：只有在明确授权时，才允许合并 PR
|
||||
|
||||
如果开发者明确要求 AI 继续合并自己的 PR，则必须先再次确认：
|
||||
|
||||
```powershell
|
||||
gh pr view <PR_NUMBER> --json number,title,baseRefName,headRefName,state,isDraft,mergeable,mergeStateStatus,url
|
||||
git fetch origin
|
||||
git log --oneline HEAD..origin/dev
|
||||
```
|
||||
|
||||
合并前必须满足：
|
||||
|
||||
1. PR 目标分支是 `dev`
|
||||
2. PR 不是 draft
|
||||
3. PR 仍然是 open
|
||||
4. 当前分支已经吸收了最新 `origin/dev`
|
||||
5. 没有尚未处理的明确问题
|
||||
6. 开发者已经明确授权合并
|
||||
|
||||
如果满足以上条件，才可以执行 GitHub 合并，例如：
|
||||
|
||||
```powershell
|
||||
gh pr merge <PR_NUMBER> --merge --delete-branch
|
||||
```
|
||||
|
||||
限制：
|
||||
|
||||
1. AI 只能把自己的 PR 合并到 `dev`。
|
||||
2. AI 不得把任何开发分支直接合并到 `master`。
|
||||
3. 如果发现 PR 目标分支是 `master`，先改成 `dev`，再重新核对是否允许继续。
|
||||
|
||||
## 开发清单
|
||||
|
||||
开发时按下面清单自检，避免漏项：
|
||||
|
||||
### 第 1 阶段：开始前
|
||||
|
||||
- `gh` 已安装且已登录
|
||||
- 当前仓库正确
|
||||
- 当前工作区状态已确认
|
||||
- 已明确本次任务是否是新任务还是续做
|
||||
|
||||
### 第 2 阶段：开发前基线
|
||||
|
||||
- 新任务已从最新 `dev` 拉分支
|
||||
- 续做任务已确认自己相对 `origin/dev` 的落后情况
|
||||
- 没有误在 `master` 或 `dev` 上直接开发
|
||||
|
||||
### 第 3 阶段：开发中
|
||||
|
||||
- 代码上下文已阅读
|
||||
- 相关联逻辑已检查
|
||||
- 无用旧代码已清理
|
||||
- SQL 改动已同步本地数据库
|
||||
|
||||
### 第 4 阶段：发 PR 前
|
||||
|
||||
- 已再次获取最新 `origin/dev`
|
||||
- 已完成 `rebase` 或 `merge`
|
||||
- diff 只包含本次任务改动
|
||||
- 提交信息清晰
|
||||
- 当前分支不是 `dev` / `master`
|
||||
|
||||
### 第 5 阶段：PR 与收尾
|
||||
|
||||
- PR 目标分支确认是 `dev`
|
||||
- PR 标题和正文与真实改动一致
|
||||
- 如有评论，内容为自然中文，不用固定机器人模板
|
||||
- 如果未跑测试，已明确提醒开发者测试
|
||||
|
||||
## 最终反馈给开发者时必须说明
|
||||
|
||||
AI 完成后，至少要向开发者明确反馈下面这些信息：
|
||||
|
||||
1. 实际执行了哪些命令和动作
|
||||
2. 当前分支是否已经同步最新 `origin/dev`
|
||||
3. 是否创建了新 PR，或者更新了已有 PR
|
||||
4. PR 编号和链接是什么
|
||||
5. PR 目标分支是否确认是 `dev`
|
||||
6. 是否执行了 `rebase` 或 `merge`
|
||||
7. 是否改了 SQL 并同步了本地数据库
|
||||
8. 是否运行过测试；如果没跑，要明确提醒开发者自行测试
|
||||
9. 是否已经合并；如果已合并，要明确说明是合并到 `dev`
|
||||
|
||||
## 一句话执行要求
|
||||
|
||||
AI 在本仓库里做开发与提 PR 时，必须按“先确认环境与当前工作区，再对齐最新 `dev`，再开发与整理改动，再次同步最新 `dev`，最后只向 `dev` 发起或更新 PR；只有在开发者明确授权时，才允许把自己的 PR 合并到 `dev`”的顺序执行，不能跳步，不能猜，不能偷懒。
|
||||
Reference in New Issue
Block a user