A2UI Issue Triage Criteria 实战指南分类、优先级与自动化值守流程【免费下载链接】a2ui项目地址: https://gitcode.com/GitHub_Trending/a2/a2ui本篇技术指南以 A2UI 仓库中 a2ui-issue-triage 技能的分类判定文档 为核心骨架系统讲解 A2UI 项目在 GitHub 上对 Issue 进行分类、设定优先级、推荐负责人与起草回复的完整值守流程。读完本文你将掌握 P0–P4 优先级体系的语义、四类 status 标签的使用规则、Bug/功能/咨询三类 Issue 的标准处理动作以及从fetch_issues.py到apply_triage.py的自动化分诊工具链的底层实现。一、文档定位三份权威事实源Canonical Sources of Truthtriage_criteria.md本身是一份执行规则手册它规定了一线值守工程师oncall engineer和分诊 Agent 在操作 Issue 时必须遵守的分类、优先级、负责人与回复规范。为了避免规则漂移它没有把全部细节重复内联而是明确指向仓库内三份权威文档权威事实源仓库路径覆盖内容优先级定义与不变式docs/contributing/triage.mdP0–P4 的语义与仓库维护目标GitHub 状态标签docs/contributing/triage.mdstatus: first-line-handled、status: waiting-for-author-response、status: needs-team-input、status: needs-triage标准回复模板docs/contributing/triage-templates.md索要信息、合规报告、无优先级已指派 Issue、过期 Issue 提醒、重复 Issue、超范围请求等标准回复写作回复时要求逐字复制标准模板文本保证对外口径一致所有被分诊的 Issue 都必须打上status: first-line-handled标签作为已被一线处理过的标记。二、优先级体系P0–P4 的语义与维护不变式triage_criteria.md直接引用 triage.md 中的优先级定义。A2UI 的优先级与其他 Dash 团队保持一致核心目标是持续保证外部 PR 得到处理、Issue 得到优先级排序并被跟进、分支数量可观测。各优先级的精确含义如下P0非常紧急very urgent必须立即指派负责人P1正在积极处理中actively being worked on应当指派负责人P2预计在常规规划流程中于三个月内升级为 P1P3暂未列入计划但未来可能成为优先事项P4团队不计划投入we do not plan to investIssue 保持打开状态留作记录。配套的 PR 评审不变式是只要满足以下任一条件团队就会评审外部贡献者的 PR——PR 对应一个 P0–P3 的 IssueP4 的 PR 不会被评审、Issue 已由 A2UI 团队指派作为 assignee 或在 Issue 描述首行标明或带type: contributions-welcome标签、或者变更在团队看来绝对清晰且显然必要。PR 描述中应当链接其对应的 Issue。三、分诊使用的 GitHub 标签全集仓库中与分诊相关的标签分为优先级标签、状态标签和类型/规模标签三类优先级P0、P1、P2、P3、P4状态status: needs-team-input需要团队输入、status: needs-triage待分诊、status: first-line-handled一线已处理、status: waiting-for-author-response等待作者回复其他size: small、type: contributions-welcome其中两个标签是自动化的status: needs-triage完全由机器人管理status: waiting-for-author-response由人工添加一旦作者回复会被自动清除。自动化分诊机器人如何工作triage.mjs 脚本通过 GitHub Actions 工作流运行负责在所有打开的条目上对账status: needs-triage标签规则如下跳过的条目带status: waiting-for-author-response的条目作者发帖/评论/评审后自动移除该标签已指派的 Issue假定团队成员在跟进。Issue 被标记needs-triage的条件缺少优先级标签P0/P1 高优先级但没有 assignee超过优先级对应的过期阈值P0 超过 1 天、P1 超过 30 天、P2 超过 90 天P3/P4 永不因过期被标记最新的人类评论来自外部贡献者。PR 被标记的条件由外部贡献者打开且没有维护者回应作者的最新贡献维护者自己的 PR 不标记。透明度自动化脚本会在控制台打印哪些条目被标记/取消标记及原因便于跟踪分诊进度。过期时间基于最后一次人类贡献评论、评审或创建而非updated_at计算避免机器人编辑重置计时器。工作流按日计划UTC 15:00 / PST 07:00、手动触发以及 Issue 事件打开、编辑、打标签、取消标签、指派、取消指派、重新打开、新评论、PR 评审提交时自动运行。四、Issue 分类与操作动作流triage_criteria.md将 Issue 分为三大类每一类都有明确的分析Analysis→ 动作Action流程。4.1 Bug 报告分析阶段复现Reproduction除非复现步骤简单清晰且环境可以立即搭好否则不要尝试本地复现。如果需要检出分支或克隆 PR 仓库来复现必须在临时克隆或 git worktree 中进行例如appDataDir/brain/conversation-id/scratch/issue_12345_repro/完成后清理所有临时文件、worktree 和克隆。静态分析Static Analysis对于复杂 Bug分析日志、堆栈跟踪以及相关规范文件如specification/下的 JSON Schema来诊断问题。动作阶段若缺少复现步骤或日志动作设为needs_info打上status: waiting-for-author-response标签并使用 triage-templates.md 中的请求信息Requesting Information模板回复若已验证建议合适的优先级P0–P3并根据路径映射和文件提交历史推荐受影响组件的负责人。路径映射规则为renderers/lit路径下的问题归属 Lit renderer 维护者specification/归属规范维护者等。负责人推荐可以通过文件提交历史来辅助判定例如运行git log -n 5 --format%ae file4.2 功能请求分析阶段核对该请求是否与 A2UI 路线图 以及受影响组件的设计哲学一致。动作阶段与路线图一致动作设为backlog优先级P2或P3并建议组件/类型标签如component: standard catalog specification、type: feature/enhancement超出范围优先级设为P4动作仍为backlog保持 Issue 打开回复使用 Out of Scope / Roadmap Conflict 模板。4.3 支持请求与咨询分析阶段判断 Issue 本质是使用或安装问题而非 Bug。动作阶段动作设为close_resolved或close_invalid直接回答问题或提供相关指南链接如 quickstart.md或 GitHub Discussions然后关闭 Issue。五、回复准则Response Guidelines起草回复时triage_criteria.md给出了三条硬性要求直接Be direct直接说明正在采取的动作或当下需要什么去芜存菁Eliminate fluff不要使用客套话例如 I hope this helps参照模板Refer to templates草稿评论必须与权威模板保持同步逐字复制 triage-templates.md 中的标准文本。值得注意的是apply_triage.py 在实现层面对同步模板做了双重保障发布评论前强制为回复加上A2UI Triage:前缀并且会在发布前检查该评论是否已存在避免重复发布。六、标准回复模板的完整用例triage-templates.md 提供了覆盖常见场景的标准回复triage_criteria.md的分类规则正是围绕这些模板设计的Issue 类Weekly A2UI Compliance ReportAI 生成的合规报告类 Issue优先级 P3动作backlog保持打开回复说明已按约定分配 P3 优先级需要更好的工作流以便跟进发现的问题已指派但无优先级的 Issue优先级 P2动作assign_and_fix保留现有 assignee回复说明分配 P2 以移出分诊队列如需调整请修改优先级过期的 P2 Issue仅添加评论提示在下一个规划周期应与其它 P2 一起考虑升级为 P1过期且已指派的 P1 Issue仅添加评论用分诊流程的 ping 询问此 Issue 是否仍在你的雷达上超范围 / 路线图冲突优先级 P4动作backlog完整回复强调超出 A2UI 协议路线图当前范围标记为 P4我们不计划投入针对它的 PR 不会被评审保持打开作为请求记录。PR 类由维护者手工处理dashboard 与 apply 脚本仅覆盖 Issue被取代的 PR关闭旧 PR 并链接新 PR说明创建了基于你分析和变更的取代 PR你的原始提交已包含其中没有关联 Issue 的复杂 PR关闭说明团队资源有限评审政策优先处理对应已优先级化 Issue 的 PR超出项目范围的 PR关闭鼓励寻找更合适的仓库或自建仓库复杂但未指派给作者的 PR关闭并链接到对应 Issue说明我们只评审指派给该贡献者的 PR有冲突的有意义过期 PR打status: waiting-for-user-response请作者解决冲突后重新评审关闭已关闭 Issue 的 PR直接关闭说明关联 Issue 已解决。七、从判定文档到自动化工具链a2ui-issue-triage 技能triage_criteria.md是 a2ui-issue-triage 技能 的核心引用文档。该技能把上述判定规则落地为四步工作流全部围绕一个约定俗成的 scratch 目录存放中间产物appDataDir/brain/conversation-id/scratch/。Step 1拉取未分诊 Issue。运行 fetch_issues.py 拉取仓库中所有缺少优先级标签的打开 Issue 及其评论python3 .agents/skills/a2ui-issue-triage/scripts/fetch_issues.py \ --repo a2ui-project/a2ui \ --output-file appDataDir/brain/conversation-id/scratch/raw_issues.json该脚本依赖 GitHub CLIgh依次执行拉取 assignee 列表并借助git log --format%an %ae建立登录名 → 真实姓名映射包含子串匹配兜底拉取仓库标签前 150 个列出打开 Issue 并过滤掉已带优先级标签或waiting-for-author-response/needs-team-input/first-line-handled状态的条目再为每个 Issue 拉取评论最终输出包含repo、assignees、labels、issues、total_issues_count的 JSON 载荷。Step 2分析与建议分诊。读取判定文档和标准模板后为每个 Issue 评估五个字段字段可选值priorityP0紧急/P1高/P2中/P3低/P4未计划/超范围/NoneP0 与 P1 必须带 assigneeassignee基于受影响组件或领域推荐的负责人actioninvestigate、assign_and_fix、needs_info、backlog、close_duplicate、close_invalid、close_resolvedlabels适用的仓库标签如type: bug、component: lit renderer、status: first-line-handled、status: waiting-for-author-responsereply依据标准模板起草的礼貌、结构化的草稿回复若判定为潜在重复最多做三次针对性 GitHub 搜索来寻找权威重复 Issue再建议close_duplicate。技能还提供了启发式辅助脚本 suggest_triage.py其guess_triage_heuristics函数体现了判定文档的工程化落地内置COMPONENT_DIRS路径映射component: lit renderer→renderers/lit、component: angular renderer→renderers/angular、component: react renderer→renderers/react、component: standard catalog specification/component: specification→specification、component: samples→samples、component: agent library→agent_sdks对标题与正文做关键词匹配——lit/angular/react/spec/schema/sdk等推断组件标签typo/docs/feature/enhancement/error/crash/bug等推断类型标签Bug 报告若缺少reproduce/steps等关键词则自动建议needs_info动作与status: waiting-for-author-response标签已指派 Issue 且非合规报告、非needs_info、非 P0/P1 时遵循模板规则提升为 P2 assign_and_fix。get_suggested_assignees则对每个组件目录运行git log -n 30 --format%an %ae统计排除dependabot/github-actions后的提交者频率再与合法 assignee 列表做精确或前缀匹配排序。实际执行时技能推荐由父 Agent原生编排并行子 Agent而非用 Python 脚本派生子进程避免本机 gRPC 凭据策略导致失败加载前 N 个默认 10Issue并行调用invoke_subagent让每个子 Agent 依据判定文档返回结构化 JSON再汇总为issues_to_triage.json。Step 3启动审查 Dashboard。运行 launch_dashboard.py启动本地 HTTP 服务器并自动打开浏览器python3 .agents/skills/a2ui-issue-triage/scripts/launch_dashboard.py \ --data-file appDataDir/brain/conversation-id/scratch/issues_to_triage.json \ --output-file appDataDir/brain/conversation-id/scratch/triage_decisions.json从源码实现看该服务器绑定随机本地端口127.0.0.1:0提供GET /返回 triage_dashboard.html 界面、GET /api/comments读取建议数据、POST /api/save把人工审查后的决策写入triage_decisions.json并置退出码 0、POST /api/abort置退出码 1/api/save与/api/abort都会触发 shutdown 事件结束进程。Dashboard 使用 marked.js 渲染 Markdown、DOMPurify 做 XSS 净化界面按优先级着色P0 红、P1 橙、P2 黄、P3 绿、P4 灰。若用户点击Abort非零退出码Agent 必须停止并询问用户不得修改任何 Issue。Step 4批量应用到 GitHub。Dashboard 审查通过退出码 0后运行 apply_triage.pypython3 .agents/skills/a2ui-issue-triage/scripts/apply_triage.py \ --decisions-file appDataDir/brain/conversation-id/scratch/triage_decisions.json该脚本仅处理approved: true的决策按 Issue 依次读取当前标签、移除冲突的旧优先级标签并添加新优先级标签、强制确保status: first-line-handled存在、按needs_info动作管理status: waiting-for-author-response、添加组件/类型标签、指派 assignee、发布带A2UI Triage:前缀且去重的评论最后按动作执行关闭close_duplicate→duplicate、close_invalid→not planned、close_resolved→completed。八、人工值守的两层职责配合自动化triage.md还定义了两个人工程序一线分诊First line triage每日对每个尚未first-line-handled的 Issue——若为 P0 则加P0标签并通知团队聊天群然后统一打上status: first-line-handled标签。二线分诊Second line triage每周处理needs-triage队列至少完成以下一项设定优先级P0/P1 必须指派到人、回答外部评论、需要更多信息时添加status: waiting-for-author-response。可以手动移除needs-triage标签加速流程但只要条目仍匹配规则机器人会重新打上。需要团队输入时按四步流程加status: needs-team-input标签 → 在团队聊天发布消息并征求输入 → 推动讨论收敛 → 移除该标签。周度分诊结束后needs-triage列表理想状态下应为空。九、FAQ 中的设计决策triage.md的 FAQ 解释了两个容易被误解的设计为什么允许分支存在因为来自 fork 的 PR 无法在提交前运行 eval 与 e2e 测试需要仅原仓库可见的 API key。禁止分支不会减少工作量只会转移到 fork且清理分支所有权清晰团队成员也更谨慎管理分支。为什么需要 P4 而不是直接关闭关闭无法留下可检索的关闭原因外部开发者可以重新打开 Issue 却无法修改标签。保持 P4 打开是未实现、看似有价值、被认定为 P4的明确信号既增加透明度也让推动优先级提升变得更难。十、总结A2UI 的 Issue 分诊体系由三层构成判定文档triage_criteria.md定义分类与动作规则权威文档triage.md 与 triage-templates.md定义优先级语义与标准回复自动化工具链fetch → suggest → dashboard → apply 四个脚本把规则工程化。理解这三层你既能作为值守工程师手动处理 Issue也能驱动 Agent 以并行子任务方式批量分诊并在人机协作中保持回复口径一致、队列状态可追踪。【免费下载链接】a2ui项目地址: https://gitcode.com/GitHub_Trending/a2/a2ui创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/14 3:58:08 · 阅读 1.2k A2UI Issue Triage Criteria 实战指南：分类、优先级与自动化值守流程
A2UI Issue Triage Criteria 实战指南分类、优先级与自动化值守流程【免费下载链接】a2ui项目地址: https://gitcode.com/GitHub_Trending/a2/a2ui本篇技术指南以 A2UI 仓库中 a2ui-issue-triage 技能的分类判定文档 为核心骨架系统讲解 A2UI 项目在 GitHub 上对 Issue 进行分类、设定优先级、推荐负责人与起草回复的完整值守流程。读完本文你将掌握 P0–P4 优先级体系的语义、四类 status 标签的使用规则、Bug/功能/咨询三类 Issue 的标准处理动作以及从fetch_issues.py到apply_triage.py的自动化分诊工具链的底层实现。一、文档定位三份权威事实源Canonical Sources of Truthtriage_criteria.md本身是一份执行规则手册它规定了一线值守工程师oncall engineer和分诊 Agent 在操作 Issue 时必须遵守的分类、优先级、负责人与回复规范。为了避免规则漂移它没有把全部细节重复内联而是明确指向仓库内三份权威文档权威事实源仓库路径覆盖内容优先级定义与不变式docs/contributing/triage.mdP0–P4 的语义与仓库维护目标GitHub 状态标签docs/contributing/triage.mdstatus: first-line-handled、status: waiting-for-author-response、status: needs-team-input、status: needs-triage标准回复模板docs/contributing/triage-templates.md索要信息、合规报告、无优先级已指派 Issue、过期 Issue 提醒、重复 Issue、超范围请求等标准回复写作回复时要求逐字复制标准模板文本保证对外口径一致所有被分诊的 Issue 都必须打上status: first-line-handled标签作为已被一线处理过的标记。二、优先级体系P0–P4 的语义与维护不变式triage_criteria.md直接引用 triage.md 中的优先级定义。A2UI 的优先级与其他 Dash 团队保持一致核心目标是持续保证外部 PR 得到处理、Issue 得到优先级排序并被跟进、分支数量可观测。各优先级的精确含义如下P0非常紧急very urgent必须立即指派负责人P1正在积极处理中actively being worked on应当指派负责人P2预计在常规规划流程中于三个月内升级为 P1P3暂未列入计划但未来可能成为优先事项P4团队不计划投入we do not plan to investIssue 保持打开状态留作记录。配套的 PR 评审不变式是只要满足以下任一条件团队就会评审外部贡献者的 PR——PR 对应一个 P0–P3 的 IssueP4 的 PR 不会被评审、Issue 已由 A2UI 团队指派作为 assignee 或在 Issue 描述首行标明或带type: contributions-welcome标签、或者变更在团队看来绝对清晰且显然必要。PR 描述中应当链接其对应的 Issue。三、分诊使用的 GitHub 标签全集仓库中与分诊相关的标签分为优先级标签、状态标签和类型/规模标签三类优先级P0、P1、P2、P3、P4状态status: needs-team-input需要团队输入、status: needs-triage待分诊、status: first-line-handled一线已处理、status: waiting-for-author-response等待作者回复其他size: small、type: contributions-welcome其中两个标签是自动化的status: needs-triage完全由机器人管理status: waiting-for-author-response由人工添加一旦作者回复会被自动清除。自动化分诊机器人如何工作triage.mjs 脚本通过 GitHub Actions 工作流运行负责在所有打开的条目上对账status: needs-triage标签规则如下跳过的条目带status: waiting-for-author-response的条目作者发帖/评论/评审后自动移除该标签已指派的 Issue假定团队成员在跟进。Issue 被标记needs-triage的条件缺少优先级标签P0/P1 高优先级但没有 assignee超过优先级对应的过期阈值P0 超过 1 天、P1 超过 30 天、P2 超过 90 天P3/P4 永不因过期被标记最新的人类评论来自外部贡献者。PR 被标记的条件由外部贡献者打开且没有维护者回应作者的最新贡献维护者自己的 PR 不标记。透明度自动化脚本会在控制台打印哪些条目被标记/取消标记及原因便于跟踪分诊进度。过期时间基于最后一次人类贡献评论、评审或创建而非updated_at计算避免机器人编辑重置计时器。工作流按日计划UTC 15:00 / PST 07:00、手动触发以及 Issue 事件打开、编辑、打标签、取消标签、指派、取消指派、重新打开、新评论、PR 评审提交时自动运行。四、Issue 分类与操作动作流triage_criteria.md将 Issue 分为三大类每一类都有明确的分析Analysis→ 动作Action流程。4.1 Bug 报告分析阶段复现Reproduction除非复现步骤简单清晰且环境可以立即搭好否则不要尝试本地复现。如果需要检出分支或克隆 PR 仓库来复现必须在临时克隆或 git worktree 中进行例如appDataDir/brain/conversation-id/scratch/issue_12345_repro/完成后清理所有临时文件、worktree 和克隆。静态分析Static Analysis对于复杂 Bug分析日志、堆栈跟踪以及相关规范文件如specification/下的 JSON Schema来诊断问题。动作阶段若缺少复现步骤或日志动作设为needs_info打上status: waiting-for-author-response标签并使用 triage-templates.md 中的请求信息Requesting Information模板回复若已验证建议合适的优先级P0–P3并根据路径映射和文件提交历史推荐受影响组件的负责人。路径映射规则为renderers/lit路径下的问题归属 Lit renderer 维护者specification/归属规范维护者等。负责人推荐可以通过文件提交历史来辅助判定例如运行git log -n 5 --format%ae file4.2 功能请求分析阶段核对该请求是否与 A2UI 路线图 以及受影响组件的设计哲学一致。动作阶段与路线图一致动作设为backlog优先级P2或P3并建议组件/类型标签如component: standard catalog specification、type: feature/enhancement超出范围优先级设为P4动作仍为backlog保持 Issue 打开回复使用 Out of Scope / Roadmap Conflict 模板。4.3 支持请求与咨询分析阶段判断 Issue 本质是使用或安装问题而非 Bug。动作阶段动作设为close_resolved或close_invalid直接回答问题或提供相关指南链接如 quickstart.md或 GitHub Discussions然后关闭 Issue。五、回复准则Response Guidelines起草回复时triage_criteria.md给出了三条硬性要求直接Be direct直接说明正在采取的动作或当下需要什么去芜存菁Eliminate fluff不要使用客套话例如 I hope this helps参照模板Refer to templates草稿评论必须与权威模板保持同步逐字复制 triage-templates.md 中的标准文本。值得注意的是apply_triage.py 在实现层面对同步模板做了双重保障发布评论前强制为回复加上A2UI Triage:前缀并且会在发布前检查该评论是否已存在避免重复发布。六、标准回复模板的完整用例triage-templates.md 提供了覆盖常见场景的标准回复triage_criteria.md的分类规则正是围绕这些模板设计的Issue 类Weekly A2UI Compliance ReportAI 生成的合规报告类 Issue优先级 P3动作backlog保持打开回复说明已按约定分配 P3 优先级需要更好的工作流以便跟进发现的问题已指派但无优先级的 Issue优先级 P2动作assign_and_fix保留现有 assignee回复说明分配 P2 以移出分诊队列如需调整请修改优先级过期的 P2 Issue仅添加评论提示在下一个规划周期应与其它 P2 一起考虑升级为 P1过期且已指派的 P1 Issue仅添加评论用分诊流程的 ping 询问此 Issue 是否仍在你的雷达上超范围 / 路线图冲突优先级 P4动作backlog完整回复强调超出 A2UI 协议路线图当前范围标记为 P4我们不计划投入针对它的 PR 不会被评审保持打开作为请求记录。PR 类由维护者手工处理dashboard 与 apply 脚本仅覆盖 Issue被取代的 PR关闭旧 PR 并链接新 PR说明创建了基于你分析和变更的取代 PR你的原始提交已包含其中没有关联 Issue 的复杂 PR关闭说明团队资源有限评审政策优先处理对应已优先级化 Issue 的 PR超出项目范围的 PR关闭鼓励寻找更合适的仓库或自建仓库复杂但未指派给作者的 PR关闭并链接到对应 Issue说明我们只评审指派给该贡献者的 PR有冲突的有意义过期 PR打status: waiting-for-user-response请作者解决冲突后重新评审关闭已关闭 Issue 的 PR直接关闭说明关联 Issue 已解决。七、从判定文档到自动化工具链a2ui-issue-triage 技能triage_criteria.md是 a2ui-issue-triage 技能 的核心引用文档。该技能把上述判定规则落地为四步工作流全部围绕一个约定俗成的 scratch 目录存放中间产物appDataDir/brain/conversation-id/scratch/。Step 1拉取未分诊 Issue。运行 fetch_issues.py 拉取仓库中所有缺少优先级标签的打开 Issue 及其评论python3 .agents/skills/a2ui-issue-triage/scripts/fetch_issues.py \ --repo a2ui-project/a2ui \ --output-file appDataDir/brain/conversation-id/scratch/raw_issues.json该脚本依赖 GitHub CLIgh依次执行拉取 assignee 列表并借助git log --format%an %ae建立登录名 → 真实姓名映射包含子串匹配兜底拉取仓库标签前 150 个列出打开 Issue 并过滤掉已带优先级标签或waiting-for-author-response/needs-team-input/first-line-handled状态的条目再为每个 Issue 拉取评论最终输出包含repo、assignees、labels、issues、total_issues_count的 JSON 载荷。Step 2分析与建议分诊。读取判定文档和标准模板后为每个 Issue 评估五个字段字段可选值priorityP0紧急/P1高/P2中/P3低/P4未计划/超范围/NoneP0 与 P1 必须带 assigneeassignee基于受影响组件或领域推荐的负责人actioninvestigate、assign_and_fix、needs_info、backlog、close_duplicate、close_invalid、close_resolvedlabels适用的仓库标签如type: bug、component: lit renderer、status: first-line-handled、status: waiting-for-author-responsereply依据标准模板起草的礼貌、结构化的草稿回复若判定为潜在重复最多做三次针对性 GitHub 搜索来寻找权威重复 Issue再建议close_duplicate。技能还提供了启发式辅助脚本 suggest_triage.py其guess_triage_heuristics函数体现了判定文档的工程化落地内置COMPONENT_DIRS路径映射component: lit renderer→renderers/lit、component: angular renderer→renderers/angular、component: react renderer→renderers/react、component: standard catalog specification/component: specification→specification、component: samples→samples、component: agent library→agent_sdks对标题与正文做关键词匹配——lit/angular/react/spec/schema/sdk等推断组件标签typo/docs/feature/enhancement/error/crash/bug等推断类型标签Bug 报告若缺少reproduce/steps等关键词则自动建议needs_info动作与status: waiting-for-author-response标签已指派 Issue 且非合规报告、非needs_info、非 P0/P1 时遵循模板规则提升为 P2 assign_and_fix。get_suggested_assignees则对每个组件目录运行git log -n 30 --format%an %ae统计排除dependabot/github-actions后的提交者频率再与合法 assignee 列表做精确或前缀匹配排序。实际执行时技能推荐由父 Agent原生编排并行子 Agent而非用 Python 脚本派生子进程避免本机 gRPC 凭据策略导致失败加载前 N 个默认 10Issue并行调用invoke_subagent让每个子 Agent 依据判定文档返回结构化 JSON再汇总为issues_to_triage.json。Step 3启动审查 Dashboard。运行 launch_dashboard.py启动本地 HTTP 服务器并自动打开浏览器python3 .agents/skills/a2ui-issue-triage/scripts/launch_dashboard.py \ --data-file appDataDir/brain/conversation-id/scratch/issues_to_triage.json \ --output-file appDataDir/brain/conversation-id/scratch/triage_decisions.json从源码实现看该服务器绑定随机本地端口127.0.0.1:0提供GET /返回 triage_dashboard.html 界面、GET /api/comments读取建议数据、POST /api/save把人工审查后的决策写入triage_decisions.json并置退出码 0、POST /api/abort置退出码 1/api/save与/api/abort都会触发 shutdown 事件结束进程。Dashboard 使用 marked.js 渲染 Markdown、DOMPurify 做 XSS 净化界面按优先级着色P0 红、P1 橙、P2 黄、P3 绿、P4 灰。若用户点击Abort非零退出码Agent 必须停止并询问用户不得修改任何 Issue。Step 4批量应用到 GitHub。Dashboard 审查通过退出码 0后运行 apply_triage.pypython3 .agents/skills/a2ui-issue-triage/scripts/apply_triage.py \ --decisions-file appDataDir/brain/conversation-id/scratch/triage_decisions.json该脚本仅处理approved: true的决策按 Issue 依次读取当前标签、移除冲突的旧优先级标签并添加新优先级标签、强制确保status: first-line-handled存在、按needs_info动作管理status: waiting-for-author-response、添加组件/类型标签、指派 assignee、发布带A2UI Triage:前缀且去重的评论最后按动作执行关闭close_duplicate→duplicate、close_invalid→not planned、close_resolved→completed。八、人工值守的两层职责配合自动化triage.md还定义了两个人工程序一线分诊First line triage每日对每个尚未first-line-handled的 Issue——若为 P0 则加P0标签并通知团队聊天群然后统一打上status: first-line-handled标签。二线分诊Second line triage每周处理needs-triage队列至少完成以下一项设定优先级P0/P1 必须指派到人、回答外部评论、需要更多信息时添加status: waiting-for-author-response。可以手动移除needs-triage标签加速流程但只要条目仍匹配规则机器人会重新打上。需要团队输入时按四步流程加status: needs-team-input标签 → 在团队聊天发布消息并征求输入 → 推动讨论收敛 → 移除该标签。周度分诊结束后needs-triage列表理想状态下应为空。九、FAQ 中的设计决策triage.md的 FAQ 解释了两个容易被误解的设计为什么允许分支存在因为来自 fork 的 PR 无法在提交前运行 eval 与 e2e 测试需要仅原仓库可见的 API key。禁止分支不会减少工作量只会转移到 fork且清理分支所有权清晰团队成员也更谨慎管理分支。为什么需要 P4 而不是直接关闭关闭无法留下可检索的关闭原因外部开发者可以重新打开 Issue 却无法修改标签。保持 P4 打开是未实现、看似有价值、被认定为 P4的明确信号既增加透明度也让推动优先级提升变得更难。十、总结A2UI 的 Issue 分诊体系由三层构成判定文档triage_criteria.md定义分类与动作规则权威文档triage.md 与 triage-templates.md定义优先级语义与标准回复自动化工具链fetch → suggest → dashboard → apply 四个脚本把规则工程化。理解这三层你既能作为值守工程师手动处理 Issue也能驱动 Agent 以并行子任务方式批量分诊并在人机协作中保持回复口径一致、队列状态可追踪。【免费下载链接】a2ui项目地址: https://gitcode.com/GitHub_Trending/a2/a2ui创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考