GitHub Issue 人工验证提示词

将下面的 <ISSUE_URL> 和 <PR_URL_OR_BRANCH_OR_COMMIT> 替换为实际内容，然后将整段提示词交给 Claude Code。

请针对下面的 Issue，生成一份可直接执行的人工验证方案：

Issue：
<ISSUE_URL>

待验证的 PR、分支或 Commit：
<PR_URL_OR_BRANCH_OR_COMMIT>

你的任务仅限于确认“人工如何判断该 Issue 已经被修复”。

禁止：
- 修改任何代码或配置
- 创建提交或 PR
- 实施修复
- 输出自动化测试方案
- 给出泛化的测试建议

请先阅读：
1. Issue 标题、正文、评论、截图和验收条件。
2. PR、分支或 Commit 的实际代码差异。
3. 与该问题有关的页面、功能入口、启动方式和测试数据。

然后根据真实改动，输出以下内容：

## 一、验证目标

用简短语言说明：

- 原问题是什么
- 修复后应该是什么表现
- 人工验收时最关键的可观察结果是什么

## 二、验收准备

明确列出：

- 需要检出的分支或 Commit
- 应用启动命令
- 访问地址或功能入口
- 所需账号及权限
- 所需测试数据
- 浏览器、设备或系统要求
- 是否需要清理缓存、重新登录或重置数据

命令必须可以直接复制执行。

## 三、核心人工验证步骤

使用以下格式逐条输出：

### 用例 1：<用例名称>

前置条件：

1. 明确的账号、数据及页面状态。

操作步骤：

1. 从哪个页面进入。
2. 点击或输入什么。
3. 按什么顺序操作。
4. 在哪里观察结果。

预期结果：

1. 每一步应该出现的具体结果。
2. 页面文案、按钮状态、数据变化、跳转结果或错误提示。
3. 明确的通过标准。

失败表现：

- 出现什么现象即可判定修复未生效。

验收证据：

- 应截取哪个页面或区域。
- 如需日志或接口响应，说明具体查看位置。

必须至少包含：

1. Issue 中原始问题的完整操作场景。
2. 修复后的正常场景。
3. 最可能再次触发原问题的边界场景。
4. 一个相关功能的回归场景。

## 四、修复前后对比

用表格输出：

| 验证场景 | 修复前表现 | 修复后预期表现 | 通过标准 |
|---|---|---|---|

描述必须具体，禁止使用“功能正常”“符合预期”“没有问题”等模糊表述。

## 五、最终验收标准

明确说明：

- 满足哪些条件可以确认 Issue 已修复。
- 出现哪些情况必须判定验收失败。
- 是否存在人工验证无法覆盖的风险。

## 六、验收结果记录模板

提供以下可直接填写并粘贴到 Issue 或 PR 的模板：

验收版本：
验收环境：
验收账号/数据：

核心场景：通过 / 失败
边界场景：通过 / 失败
回归场景：通过 / 失败

实际结果：
发现的问题：
截图或录屏：
最终结论：接受修复 / 拒绝修复

要求：

- 验证步骤必须基于这个 Issue 和实际代码改动生成。
- 让不了解源码的测试人员也能独立完成。
- 每一步都必须可操作、可观察、可判断。
- 如果缺少 Issue、PR、运行环境或测试账号等关键信息，明确列出缺失项，不要自行编造。