桌面应用
代码审查收件箱应用设计
代码审查收件箱应用设计将审查请求、CI 失败、分配的问题和活动汇集到一个便于每日梳理待办、可快速浏览的工作区中。
代码审查收件箱应用使用场景
- 审查请求分流在一个队列中查找待批准项、开放的拉取请求和待回复内容。
- CI 失败监控展示失败的检查，并同时提供后续跟进所需的提交上下文。
- 问题优先级排序扫描分配给你的工作，包括仓库、状态、标签和近期活动。
- 工程活动审查让已合并的变更保持可见，同时不将其与紧急工作混在一起。
审查收件箱设计亮点
- 优先处理黄色审查面板将等待你处理的工作放在顶部。
- 上下文中的证据紧凑的代码差异位于其审查请求内部。
- 基于状态的颜色绿色、红色、黄色和紫色用于区分工作流状态。
- 单一工作区请求、检查、问题和活动共享同一条阅读流程。
代码审查收件箱：逐面板展示
1 / 2
代码审查收件箱结构
这款桌面应用设计将 GitHub 审查请求与提及收件箱呈现为一个按垂直顺序排列的工作区。左侧栏以“All 5”开头，随后是“Participating”、“Mentions”和“Review requests 2”。主列接着将工作分为审查请求、CI 检查、分配的问题和活动。这样的顺序将多个工程信号转化为一条扫描路径，同时独立的类别保留了足够上下文，帮助用户判断首先需要关注什么。
作为证据的审查请求
第一条审查项标识了 open-design/web PR #2371，列出“feat: orbit briefing card”，并显示“3 of 5 reviewers approved · waiting on you + cody”。其下方的文件路径“src/components/OrbitBriefingCard.tsx”引出一段紧凑的差异，其中包含删除行和新增行。这种组合让审查者能够将批准状态与具体变更联系起来。代价是占用更多纵向空间：代码摘录提供了有用上下文，但也使第一条项目明显高于第二条请求。
工程待办梳理场景
该设计支持多项不同任务，但没有假装它们属于同一种工作。审查请求需要回复或批准，CI 检查表示验证失败状态，分配的问题代表由某人负责的待办工作，而活动记录已完成的变更。将这些分组保留为独立面板，可以让任务边界清晰可见。代价是相关信号仍分散在页面各处，而不是被压缩为一个通用分数。
待处理审查
黄色的“Review requests waiting on you”标题带有数量 2。第一行是一个开放的拉取请求，包含审查者头像和明确的等待状态；第二行显示“Conversation needs your reply”，并标识 @cody。这些标签区分了批准工作和对话工作，尽管两者都需要采取行动。
验证失败
红色的“CI / Checks”面板包含一项内容：open-design/web · main · “test (e2e) failed”。附近的最近提交文本“chore(deps): bump cheerio to 1.0.2”提供了一个可能的调查切入点，但没有声称测试失败的原因。红色强调使该状态十分醒目，但并未说明修复方式。
负责中的工作与已完成工作
问题行将“Auth middleware refactor”与 Open 状态、“backend”标签和“p1”组合在一起。下方的活动行显示 PR #2401 已由 bob 合并到 main。这种顺序让未解决的负责人工作位于已完成历史之前，不过页面仍要求读者根据标签和状态自行判断紧急程度。
工作区阅读流程
该工作区使用宽阔的主列和紧凑的导航栏，而不是尺寸相同的仪表盘磁贴。已交付的 CSS 将页面最大宽度设为 1280px，可见布局也将大部分水平空间交给事件面板。这一比例能够容纳较长的仓库名、拉取请求标题、时间戳和代码行，而不必将每个项目强行放入独立的卡片列中。代价是垂直扫描距离较长，尤其是在审查请求包含内嵌差异时。
审查面板
黄色标题、数量徽章、开放状态胶囊、审查者头像和代码差异将紧迫性与证据结合起来。
CI 面板
红色标题和失败检查行将验证问题从审查工作与负责人工作中单独划分出来。
问题面板
状态和标签在一行简短内容中展示分配项的工作流状态与类别。
活动面板
紫色的已合并样式标识已完成的历史记录，同时不会与上方未解决的项目争夺注意力。
从筛选到详情
顶部搜索框显示“Type / to search”，但没有搜索处理程序。侧边栏筛选项会作用于提供的本地分组：Participating 显示审查请求和分配的问题，Review requests 显示审查分组，Mentions 仅显示带有源数据提及标记的分组。该标记附加在分配的问题上，而不是需要回复的审查行上。这种筛选属于本地呈现行为，并非连接到 GitHub 的搜索或收件箱服务。
通过颜色呈现状态变化
颜色在其他相似的行之间传递状态。绿色表示开放或看起来健康的仓库状态，黄色表示等待回复的工作，红色表示失败的测试，紫色表示已合并的活动项。问题标签使用独立的蓝色和粉色胶囊分别表示“backend”和“p1”。这比逐句阅读更有利于快速扫描，但颜色仍然只是辅助信息：每种状态也都以文字呈现，因此当单独依赖颜色不足以传达含义时，信息仍然保留。
能力边界
源代码实现了本地类别筛选，并为行和标题构建指向 GitHub 的外部链接。这些链接使用显示的示例标识符，指向一个固定仓库；链接存在并不能验证所展示的拉取请求、问题或 CI 结果。搜索、经过身份验证的收件箱获取、持久化审查状态和真实测试执行均未实现。名称、数量、时间戳、批准状态和代码摘录仍然是该设计场景中的说明性内容。
如何在 OpenDesign 中创建代码审查收件箱应用设计
设置工作区顺序
创建一个桌面工作区，使用常驻左侧栏放置“All”、“Participating”、“Mentions”和“Review requests”，右侧接一列宽阔的主内容区。先放置审查请求，再放置 CI 检查、分配的问题和活动，让未解决的工作排在历史记录之前。
添加特定案例状态
使用示例行展示 PR #2371 和 PR #2389、main 上失败的“test (e2e)”检查、分配给你的 ENG-148 问题，以及已合并的 PR #2401 活动项。保留“waiting on you”、“Conversation needs your reply”、“backend”和“p1”等明确标签。
建议提示词创建一个桌面代码审查收件箱应用设计，包含常驻左侧筛选栏和宽阔的分组工作区。首先展示审查请求，其中包括带有紧凑 OrbitBriefingCard.tsx 差异的 PR #2371，以及处于需要回复状态的 PR #2389；然后展示包含失败 test (e2e) 的 CI / Checks、包含 ENG-148 的 Issues assigned to you，以及包含已合并 PR #2401 的 Activity。仅使用说明性本地数据，不要暗示存在实时 GitHub 连接、后端、存储或真实测试执行。
完善扫描模式
检查黄色审查强调、红色 CI 失败处理、绿色开放状态和紫色已合并活动在配合文字标签时仍然清晰易读。让代码摘录从属于其审查行，保留较长的仓库名和文件名，并确认工作区变窄时，垂直分组仍能正确呈现阅读顺序。
导出并获取分享链接
导出完成的设计稿，然后在 OpenDesign 中使用「Share」功能获取分享链接。在单独的浏览器窗口中打开链接，确认目标版本及其资源均可正常访问后，再将链接发送给他人。
