# 端到端验收 PR 的 UI (/zh/use-cases/design/pr-ui-verification)



复制粘贴下面这句话，快速开始你的第一个任务：

<Prompt>
  帮我建立一个"PR UI 每日验收跟进"的自动化：PR 是 [链接/分支、需求说明、重点页面]。检查功能是否符合需求、关键路径是否正常、文案和界面有没有明显问题，把问题按"必须修复""建议优化""不阻塞"分类列出来，每条说清楚触发条件和影响。之后每天跟进一次 PR 状态，直到问题关闭或合并为止，只汇报新增和已解决的问题，跑不通或需要登录就直接说清楚卡在哪一步，能连 GitHub 的话帮我顺便连上。
</Prompt>

<LivePreview component="NewThread" scenario="{ draft: &#x22;帮我建立一个\&#x22;PR UI 每日验收跟进\&#x22;的自动化：PR 是 [链接/分支、需求说明、重点页面]。检查功能是否符合需求、关键路径是否正常、文案和界面有没有明显问题，把问题按\&#x22;必须修复\&#x22;\&#x22;建议优化\&#x22;\&#x22;不阻塞\&#x22;分类列出来，每条说清楚触发条件和影响。之后每天跟进一次 PR 状态，直到问题关闭或合并为止，只汇报新增和已解决的问题，跑不通或需要登录就直接说清楚卡在哪一步，能连 GitHub 的话帮我顺便连上。&#x22; }" />

## 这个工作流是什么 [#这个工作流是什么]

"端到端验收 PR 的 UI"要解决的是一个反复出现的问题：把一个 PR 链接变成一份站得住的结论，而不是一张孤零零的截图。队友先确认 PR 的身份——链接、分支、最新 commit、合并状态、CI 状态、preview 链接——再按请求要求的状态逐一截图并标注场景、状态和采集时间，最后把结论拆成视觉、前端实现、端到端三层分别汇报，不合并成一句"跑通了"。碰到卡点——登录墙、构建失败、fixture 不匹配、依赖缺失、后端没启动——就直接说明卡在哪一种，不瞎猜。每次复查更新的都是同一个 Artifact 链接，还可以配一个可选的 watcher，在 CI、preview 或最新 commit 变化时自动复查。

<Callout type="warn">
  这位队友可以自主读取 PR、跑测试、打开 preview、截图并汇报。有五件事永远等人来做：合并 PR、push 或改写分支、修改共享 preview 配置、发布到生产环境、请求或扩大仓库写权限。
</Callout>

## 怎么用这个工作流 [#怎么用这个工作流]

<Steps>
  <Step>
    ### 雇一位测试队友，不是截图工具 [#雇一位测试队友不是截图工具]

    在侧边栏打开 **AI Teammates**，点击 **Hire AI Teammate**，选择**测试**模板。默认 bio 是通用的复现和汇报工作，在 Profile 步骤把它换掉，让它知道这份工作是验收一个具体 PR，不是随手看一眼：

    <Prompt>
      你负责端到端验收 PR 的 UI。先确认 PR、分支、最新 commit 和 CI 状态。截图必须来自目标分支的真实页面，不能是猜测或旧图，每张标注场景、状态和采集时间。视觉验收和前端实现验收分开报告，不合并成一句『跑通了』。遇到登录墙、fixture 权限不匹配、构建失败或后端未启动，停下来报告阻塞项，不要猜。绝不合并、推送、改动 preview 配置，也不申请仓库写权限。
    </Prompt>

    <LivePreview component="CreateAssistantPage" scenario="{ focus: &#x22;profile&#x22;, initialState: { start: &#x22;template&#x22;, templateRef: &#x22;@helio/code-reviewer&#x22;, name: &#x22;测试&#x22;, bio: &#x22;你负责端到端验收 PR 的 UI。先确认 PR、分支、最新 commit 和 CI 状态。截图必须来自目标分支的真实页面，不能是猜测或旧图，每张标注场景、状态和采集时间。视觉验收和前端实现验收分开报告，不合并成一句『跑通了』。遇到登录墙、fixture 权限不匹配、构建失败或后端未启动，停下来报告阻塞项，不要猜。绝不合并、推送、改动 preview 配置，也不申请仓库写权限。&#x22; } }" />

    [了解如何雇用队友 →](/ai-teammates/hire-an-ai-teammate)
  </Step>

  <Step>
    ### 连接 GitHub [#连接-github]

    队友需要读取 PR、commit、checks 和部署链接的权限。工作区管理员先安装一次 GitHub App（**Settings → Integrations**），再把仓库授予这位队友。这个授权收窄的是队友能访问哪些仓库，不是权限级别——队友的 token 继承已安装 GitHub App 的全部权限，所以如果 App 是为写代码的队友装的、带写权限，这位队友技术上也有。让验收保持只读的边界是上面 bio 里那句"绝不 push、merge 或重跑任何东西"，务必保留它。[连接 GitHub →](/connect/connect-tools-to-ai-teammates/connect-github-to-ai-teammates)

    <LivePreview component="AssistantIntegrations" />
  </Step>

  <Step>
    ### 配置两条 preview 路径 [#配置两条-preview-路径]

    默认路径是托管 preview：从 PR 的 checks 里拿到部署链接，等目标组件真正加载完，按请求要求的状态截图，不能只截首页。

    兜底路径是本地设备，用在托管 preview 被登录保护拦住、队友进不去的时候。**Settings → Devices** 是个人设置，不是工作区管理员专属的，任何成员都能加自己的设备。点击 **Add a device**，在一台已经装好项目工具链的机器上运行连接命令。雇用或配置队友时，Engine 步骤的 **Runs on** 字段可以把这类工作指向该设备，而不是 Helio Cloud。完整设置见[在你自己的机器上运行 →](/connect/devices)。
  </Step>

  <Step>
    ### 用一条完整的请求启动验收 [#用一条完整的请求启动验收]

    一条缺了目标状态或交付位置的请求，没法拿来直接跑，只会招来一次瞎猜。把 PR、场景、预期状态、允许动作、禁止动作、交付位置都写清楚：

    <Prompt>
      验收 PR #[编号]（分支 [分支名]）：[说明预期行为，什么该发生、什么不该发生]。先查托管 preview，如果被登录保护拦住再切到你的设备。截图 [状态一] 和 [状态二]。不要合并或 push 任何东西。报告以 artifact 形式发到这个频道。
    </Prompt>

    <LivePreview
      component="AssistantChat"
      scenario="{ assistantName: &#x22;测试&#x22;, messages: [
    { author: &#x22;user&#x22;, text: &#x22;验收 PR #482（分支 feature/sidebar-unread-count）：侧边栏的会话应该显示一个未读角标，打开后消失。先查托管 preview，如果被登录保护拦住再切到你的设备。截图未读态和消失后的状态。不要合并或 push 任何东西。报告以 artifact 形式发到这个频道。&#x22; },
    { author: &#x22;assistant&#x22;, text: &#x22;已确认 PR #482，最新 commit a3f91c2，CI 绿灯，部署链接可用。托管 preview 没有遇到登录保护，就走这条路径，不需要用到设备兜底。现在打开侧边栏，先把两个状态都截了图，再往下查其他部分。&#x22; },
  ] }"
    />
  </Step>

  <Step>
    ### 结论拆成三层 [#结论拆成三层]

    一句"跑通了"恰好会盖住最重要的那类失败：视觉证据和实现正确性是可以分道扬镳的。如果 preview 的 fixture 把 `canEdit` 默认成 true，一张本该证明只读态的截图，就会显示出根本不该出现的编辑按钮，哪怕前端代码和测试完全正确。正确的结论不是"坏了"或"能用"，而是"前端实现和测试成立，但这个 preview 的 fixture 不能为只读态提供有效的视觉证据"：

    <LivePreview
      component="AssistantChat"
      scenario="{ assistantName: &#x22;测试&#x22;, messages: [
    { author: &#x22;user&#x22;, text: &#x22;所以这个未读角标到底能不能用？&#x22; },
    { author: &#x22;assistant&#x22;, text: &#x22;分三层回答。视觉：确认成立，两个状态都是从 commit a3f91c2 的真实 preview 截的图，新消息显示角标，打开后消失。前端实现：确认成立，相关的未读状态测试和 typecheck 都通过，打开时清除角标的处理逻辑在 DOM 里确认正常触发。端到端：未验证，preview 的 mock data 没有打到真实的已读回执接口，所以我没法确认清除后的状态在真实后端刷新后还能持久化。这最后一块需要在真实环境里跑一遍，我才能说这个功能完全验收通过。&#x22; },
  ] }"
    />
  </Step>

  <Step>
    ### 发布报告，链接保持不变 [#发布报告链接保持不变]

    报告以 Artifact 形式发出，组织内可见，不对公网公开。同一个 PR 的后续复查更新的是同一份 artifact，不会另外产出一份新报告，任何人打开已有链接刷新一下就能看到最新结果。
  </Step>
</Steps>

## 自动化 [#自动化]

把重复的验收变成自动化，不用每次手动重跑。在侧边栏打开 **Automations**，点击 **Create via Chat**，在打开的 New Thread 里描述触发条件：

<Prompt>
  盯着 PR #[编号]。每 30 分钟检查一次最新 commit、CI 状态或部署状态有没有变化。没变化就保持安静。CI 失败就把失败的 job 贴出来。preview 变成 ready 之后，先确认它真的能加载，再告诉我可以开始验收了。绝不自己合并、push 或重跑任何东西。
</Prompt>

同样的思路还能覆盖另外两种常做的场景：有新 commit 落在通过 CI 的 PR 上时自动重跑既定的验收矩阵、更新同一份 artifact；以及每周一份摘要，汇总那些拖了好几天没人 review、CI 红灯、preview 404 或被登录保护、报告已经过期的开放 UI PR。

**审批：** 这个流程可以自己跑——读取 PR、跑测试、打开 preview、按要求截图，这些都不需要你签字确认。合并 PR、push 或改写分支、修改共享 preview 配置、发布到生产环境、申请或扩大仓库写权限，这五件事永远等人来做。审批机制的完整说明见[控制](/ai-teammates/control)。

## 用得更好的几个提示 [#用得更好的几个提示]

| 提示                      | 说明                                                                                   |
| ----------------------- | ------------------------------------------------------------------------------------ |
| 把 PR、场景和预期状态一次说全        | 缺了目标状态或交付位置的请求没法直接跑，只会招来一次瞎猜。把 PR、分支、预期行为、允许/禁止的动作、报告发去哪儿，一条消息里说清楚。                  |
| 托管 preview 被登录墙拦住时用设备兜底 | 在 **Settings → Devices** 里连接一台装好工具链的设备，把 Engine 的 **Runs on** 指向它，而不是将就用旧截图。         |
| 三层结论都要看，别只认一句总结         | 视觉证据和实现正确性可能分道扬镳——preview 的 fixture 把 `canEdit` 默认成 true，就能让一个本来正确的只读实现，在截图里看起来像是坏的。 |
| 复查用同一个 artifact         | 同一个 PR 的后续检查更新的是同一份 artifact，不会另外产出新报告，谁开着链接刷新一下就能看到最新结果。                            |

## 常见问题 [#常见问题]

<Accordions type="single">
  <Accordion title="托管 preview 被登录墙拦住怎么办？">
    队友会切到 **Settings → Devices** 里连接好的设备，前提是雇用或配置队友时 Engine 步骤的 **Runs on** 字段已经指向那台设备。
  </Accordion>

  <Accordion title="这位队友能合并 PR 或推代码吗？">
    不能。合并 PR、push 或改写分支、修改共享 preview 配置、发布到生产环境、申请或扩大仓库写权限，这五件事永远等人来做。
  </Accordion>

  <Accordion title="为什么是三层结论，不是一句『跑通了』？">
    视觉证据和实现正确性可能分道扬镳——比如 preview 的 fixture 把 `canEdit` 默认成 true，一张本该证明只读态的截图就会显示出不该出现的编辑按钮，哪怕代码和测试完全正确。所以报告把视觉、前端实现、端到端拆成三层分别给结论，而不是一句话盖过去。
  </Accordion>

  <Accordion title="验收没法完成怎么办？">
    队友会停下来，说明具体卡在哪一种——登录墙、构建失败、fixture 不匹配、依赖缺失、或者后端没启动——而不是瞎猜着继续跑。
  </Accordion>

  <Accordion title="复查会产出新报告吗？">
    不会。复查更新的是同一个 Artifact 链接，已经打开链接的人刷新就能看到最新结果；也可以配一个可选的 PR watcher，在 CI、preview 或最新 commit 变化时自动复查。
  </Accordion>
</Accordions>

<Cards>
  <Card title="Design" href="/use-cases/design" description="返回设计场景总览。" />

  <Card title="把 UI 反馈变成修复" href="/use-cases/design/usability-review" description="反馈还没变成 PR 之前的场景。" />

  <Card title="连接 GitHub" href="/connect/connect-tools-to-ai-teammates/connect-github-to-ai-teammates" description="把仓库权限授予需要它的队友。" />
</Cards>