# 把 UI 反馈变成修复 (/zh/use-cases/design/usability-review)



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

<Prompt>
  帮我建一个 UI 反馈每日修复队列自动化：每天早上把设计相关频道里过去 24 小时新增的反馈汇总一遍，先按 bug、交互问题、视觉问题、文案问题、需求分歧分好类；对高优先级的反馈写清楚复现路径、用户影响、建议修复方案和优先级；范围清楚的小改动（比如文案、颜色、间距、图标级别）直接建任务派给工程师，方便当天就出 PR；范围不明确的反馈单独列出来，等我确认之后再分配，不要自己瞎猜；反馈来源可以是截图、用户吐槽或页面链接。
</Prompt>

<LivePreview component="NewThread" scenario="{ draft: &#x22;帮我建一个 UI 反馈每日修复队列自动化：每天早上把设计相关频道里过去 24 小时新增的反馈汇总一遍，先按 bug、交互问题、视觉问题、文案问题、需求分歧分好类；对高优先级的反馈写清楚复现路径、用户影响、建议修复方案和优先级；范围清楚的小改动（比如文案、颜色、间距、图标级别）直接建任务派给工程师，方便当天就出 PR；范围不明确的反馈单独列出来，等我确认之后再分配，不要自己瞎猜；反馈来源可以是截图、用户吐槽或页面链接。&#x22; }" />

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

"把 UI 反馈变成修复"要解决的是一个反复出现的问题：UI 反馈散落在各个频道里，不能指望有人记得去翻。每天早上，一份晨报会把反馈从所有设计相关频道里捞出来，不只是有人记得查的那几个。文案、颜色、间距、图标这类范围清楚的小改动，会直接分诊成任务派给工程师，当天出一个附真实截图的 PR；范围不明确的，会交给真正的设计师去判断，而不是让 AI 猜。每个修复依然要等设计师审查并合并——没有这一步，任何东西都不会进 main。

<Callout type="warn">
  这位队友不会合并自己的 PR，也不会直接推 main，永远由设计师审查并合并。如果任务进了代码之后发现范围其实不清楚，或者原始反馈不够具体、没法有把握地修，它会停下来问，而不是去猜设计意图：猜错要花的返工时间，比原本修一次要多得多。
</Callout>

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

<Steps>
  <Step>
    ### 雇一位频道值守做每日扫描 [#雇一位频道值守做每日扫描]

    在侧边栏打开 **AI Teammates**，点击 **Hire AI Teammate**，选择**频道值守**模板。默认 bio 是通用的态势感知，在 Profile 步骤把它换掉，让它知道这份工作是分诊，不只是做摘要：

    <Prompt>
      你每天早上扫一遍所有设计相关频道过去 24 小时的反馈，发一份晨报到 #design。文案、颜色、间距、图标这类小改动，范围清楚的直接建任务指派给工程师，在频道 @ 交接；范围不明确的建任务指派给设计师，不要自己猜。你不碰代码。
    </Prompt>

    确认名字，点击**创建队友**。[了解如何雇用队友 →](/ai-teammates/hire-an-ai-teammate)

    <LivePreview component="CreateAssistantPage" scenario="{ focus: &#x22;profile&#x22;, initialState: { start: &#x22;template&#x22;, templateRef: &#x22;@helio/channel-watcher&#x22;, name: &#x22;频道值守&#x22;, bio: &#x22;你每天早上扫一遍所有设计相关频道过去 24 小时的反馈，发一份晨报到 #design。文案、颜色、间距、图标这类小改动，范围清楚的直接建任务指派给工程师，在频道 @ 交接；范围不明确的建任务指派给设计师，不要自己猜。你不碰代码。&#x22; } }" />
  </Step>

  <Step>
    ### 雇一位工程师接手修复，并连接 GitHub [#雇一位工程师接手修复并连接-github]

    再打开一次 **AI Teammates**，选择**工程师**模板。默认 bio 是通用的实现工作，把它换掉，让它知道接手的都是已经分诊过的小修复，不是开放式的功能开发：

    <Prompt>
      你接手晨报交接过来的小型 UI 修复任务。拉分支、实现、跑项目检查、开 PR，把链接回贴到任务里。绝不合并自己的 PR，也不直接推 main。如果进代码之后发现范围其实不清楚，停下来问，不要猜设计意图。
    </Prompt>

    <LivePreview component="CreateAssistantPage" scenario="{ focus: &#x22;profile&#x22;, initialState: { start: &#x22;template&#x22;, templateRef: &#x22;@helio/software-engineer&#x22;, name: &#x22;工程师&#x22;, bio: &#x22;你接手晨报交接过来的小型 UI 修复任务。拉分支、实现、跑项目检查、开 PR，把链接回贴到任务里。绝不合并自己的 PR，也不直接推 main。如果进代码之后发现范围其实不清楚，停下来问，不要猜设计意图。&#x22; } }" />

    修复要以 PR 形式提交，绝不直接推送。工作区管理员在**设置 → 集成**里安装一次 GitHub App，再把仓库权限授予这位队友。[连接 GitHub →](/connect/connect-tools-to-ai-teammates/connect-github-to-ai-teammates)

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

  <Step>
    ### 把每日扫描和分诊自动化 [#把每日扫描和分诊自动化]

    队友只能读取和发言自己加入过的频道——先把频道值守邀请进所有它要扫描的设计频道，以及晨报要发到的 `#design-digest`，再在侧边栏打开**自动化**，点击**通过对话创建**，在打开的 New Thread 输入框上方选频道值守：

    <Prompt>
      每个工作日 09:30，扫描所有设计相关频道过去 24 小时的消息，把晨报发到 #design-digest。明确的小改动（文案、颜色、间距、图标级），建任务指派给工程师，并 @ 提及交接；范围不明确的，建任务指派给我，不要自己猜。
    </Prompt>

    <LivePreview component="NewThread" scenario="{ populated: false }" />
  </Step>

  <Step>
    ### 看一个小修复从任务走到 PR 的全程 [#看一个小修复从任务走到-pr-的全程]

    晨报那一步已经建好了一个真实的 Task，工作实际发生在这里。工程师作为 assignee 领这个任务，不是靠私信，每一次更新（拉分支、检查通过、PR 链接）都以评论的形式发在这个任务上，任何有权限的人都能看到，而不是单独回报给你：

    <LivePreview component="TaskBoard" scenario="{ select: &#x22;t_001&#x22; }" />

    这样一个任务会有一个标题（`UI-482：上传弹窗里 placeholder 和 loading 效果同时出现`）和一份完整的描述：上传弹窗里，描述的 placeholder 文案和图片上传中的 loading 效果同时显示，看起来像两个互相矛盾的状态叠在一起；创建按钮应该在有图片还在上传时保持禁用，因为上传过程中提交会导致条目先建出来、附件却还没到位。评论区就是工程师干活的地方：领任务、拉分支、跑项目真实检查，修好之后把 PR 链接连同三张状态截图一起发在评论里，交给设计师审查。
  </Step>

  <Step>
    ### 审查并合并 [#审查并合并]

    工程师的工作到"开出一个附证据的 PR"为止。设计师审查截图和真实的 diff，再合并。如果这次修复里有任何一处其实是设计决策而不是机械改动，这就是该被拦下来的时刻，在上线之前，不是之后。
  </Step>
</Steps>

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

| 提示               | 说明                                                              |
| ---------------- | --------------------------------------------------------------- |
| 把频道值守邀请进所有要扫描的频道 | 它只能读取和发言自己加入过的频道。在打开每日自动化之前，把它加进所有设计频道，以及 `#design-digest`。     |
| 分诊的标准要具体         | "文案、颜色、间距、图标级"就是"小改动"的边界。模糊到够不上这个标准的反馈，会交给设计师，而不是让 AI 猜。        |
| 审查时看 diff，不只看截图  | 截图只能证明修好之后的状态渲染正确；真正能判断这次改动是"顺手的机械修复"还是"其实是个设计决策"的，是那份真实的 diff。 |
| 让它该停就停           | 如果任务进了代码之后发现范围其实不清楚，它会停下来问，而不是自己猜。回答这个问题，比事后返工一次猜错的修复要快得多。      |

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

<Accordions type="single">
  <Accordion title="谁来审查并合并修复？">
    永远是真正的设计师。工程师不会合并自己的 PR，也不会直接推 main。
  </Accordion>

  <Accordion title="反馈太含糊、没法直接动手怎么办？">
    会被路由给设计师，建一个任务，而不是让 AI 猜意图——晨报分诊时如果判断不了是不是小改动会这样处理，工程师进了代码之后发现范围其实不清楚时也是一样，会停下来问。
  </Accordion>

  <Accordion title="会扫描哪些频道？">
    只有频道值守被邀请进去的频道——它只能读取和发言自己加入过的频道。在打开自动化之前，把它邀请进所有要扫描的设计频道，以及晨报要发到的频道。
  </Accordion>

  <Accordion title="搭这套流程需要工作区管理员吗？">
    只有连接 GitHub 这一步需要：工作区管理员在设置 → 集成里安装一次 GitHub App，再把仓库权限授予工程师队友。雇队友和搭自动化本身不需要管理员权限。
  </Accordion>

  <Accordion title="开 PR 这一步需要我批准吗？">
    Helio 是按具体动作决定信任程度，不是一个全局开关：常规工作会自己运行，凡是触达 Helio 之外、或者没法撤销的动作，都会停下来等你签字。具体怎么运作看[控制](/ai-teammates/control)；这里能确定的是，合并这一步永远不会跳过设计师的审查。
  </Accordion>
</Accordions>

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

  <Card title="设计 UI 原型" href="/use-cases/design/ui-interaction-design" description="在动手开发前说清楚结构、状态和边缘情况。" />

  <Card title="端到端验收 PR 的 UI" href="/use-cases/design/pr-ui-verification" description="修复变成真正的 PR 之后，确认 preview 和实现是否真的成立。" />
</Cards>