智慧水厂物联网落地：传感器选型、TSN组网与设备健康诊断实战
2026/9/18 2:58:58
dotnet/skills AI自动Issue分诊全解：issue-triage智能体3步自动打标签的实战指南
【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills
dotnet/skills 是微软开源的 .NET 与 C# 技能库项目，它为 AI 编码代理提供了大量 .NET 技能（skills）。这个项目本身就用上了一个很实用的自动化能力：issue-triage 智能体自动 Issue 分诊——每当新 Issue 打开或重新打开时，AI 会自动打area-*标签、按 CODEOWNERS 指派负责人、标记 Issue 类型，并留一条简明的分诊总结评论，全程无需维护者手动干预。
上图是该项目 AI 工作流自动发布的结构化结果评论（Skill Evaluation Results）。issue-triage 智能体发布的分诊评论就是这种"结论先行 + 可展开细节"的风格。
issue-triage 分诊智能体是什么？
传统的开源项目 Issue 分诊靠人：看标题 → 猜领域 → 找负责人 → 打标签 → 写评论。当项目 Issue 量大时，维护者常常顾不过来，新 Issue 可能在队列里躺上几天。
dotnet/skills 的做法是把这件事交给 AI 智能体（基于 GitHub Agentic Workflows 实现）：
- 自动触发：
issues: [opened, reopened]事件直接唤起，重新打开的旧 Issue 也会重新分诊 - 自动分类：从 15 个预定义的
area-*标签中挑选最匹配的一个（如area-msbuild、area-dotnet-ai、area-dotnet-maui） - 自动指派：读取
.github/CODEOWNERS，把 Issue 指派给对应路径的负责人 - 自动留痕：发布一条以🎯 Issue Triage开头的评论，包含摘要、类型、负责人和置信度（High/Medium/Low），并附带可折叠的分诊依据
核心定义文件就是 issue-triage.md，它用 Markdown 编写智能体提示词，再通过gh aw compile编译出可运行的 issue-triage.lock.yml（带安全加固的标准 GitHub Actions YAML）。这种"Markdown 写逻辑、编译出流水线"的方式，是整个 docs/agentic-workflows.md 描述的 DevOps 智能体工作流体系的通用模式。
一次分诊的 7 个步骤
智能体的完整分诊流程定义在 issue-triage.md 中，步骤非常清晰：
| 步骤 | 动作 | 说明 |
|---|---|---|
| 1️⃣ 读取 Issue | get_issue拉取全文 | 明显是垃圾/机器人 Issue 直接加Triaged标签跳过；已有Triaged标签则不重复处理 |
| 2️⃣ 收集上下文 | 读 CODEOWNERS、列出标签、搜索相似 Issue | 为打标签和查重做准备 |
| 3️⃣ 定领域 | 选定一个area-*标签 | 匹配不到任何已有标签时宁缺毋滥，不乱打 |
| 4️⃣ 定负责人 | 按 CODEOWNERS 路径匹配 | 无法确定时打needs-manual-assignment标签，不强猜 |
| 5️⃣ 定类型 | bug/enhancement/task/question四选一 | 必须恰好一个 |
| 6️⃣ 打标签 | 通过add_labels追加 | 含Triaged、重复 Issue 则加duplicate |
| 7️⃣ 发评论 | 唯一的分诊总结评论 | 2-3 句摘要 + 类型 + 负责人 + 置信度 + 相似 Issue 链接 |
几个针对"重新打开的 Issue"的细节很贴心：它会先检查已有标签是否仍然正确、重点关注导致重开的那条评论中的新信息，并在评论中注明"此问题回归/再次出现"。
安全设计：如何防止 AI"越权操作"
把 AI 接进真实仓库，最怕它被 Issue 内容"带跑偏"。这个工作流在 issue-triage.md 里做了层层设防，对新手理解"AI 自动化安全"很有参考价值：
- 把 Issue 内容当数据，不当指令：提示词明确规定 Issue 标题、正文、评论都是不可信输入，即使内容伪装成维护者身份、要求改标签或泄露 Token，智能体也只描述、不执行
- safe-outputs 操作上限：最多打 5 个标签、最多 2 次 Issue 更新（且禁止修改正文）、最多 1 条评论——AI 能做的事被"物理限幅"
- 最小权限：
contents: read+issues: read，只读权限 - 并发控制：
concurrency组按 Issue 编号隔离，同一个 Issue 不会同时跑两个分诊 - 10 分钟超时：
timeout-minutes: 10，避免智能体卡死占用资源 - PAT 池轮询：通过 shared/pat_pool.md 从 10 个 Token 中挑选，避免单个 Token 额度耗尽
批量补漏：用 issue-triage-batch 分诊历史 Issue
自动触发只覆盖"新打开"的 Issue。那过去攒下来的一批呢？答案是 issue-triage-batch.yml——一个手动触发的确定性工作流：
- 支持
date_from/date_to两个可选日期参数，默认扫描最近 7 天 - 用
gh issue list --search "created:起..止 -label:Triaged"找出所有未分诊的开放 Issue（上限 200 个） - 逐个通过
gh workflow run派发 issue-triage 智能体
也就是说，新 Issue 走实时通道，存量 Issue 用批量通道"补课"，两条腿走路。
如何在自己项目里启用
- 安装
gh awCLI 扩展：gh extension install github/gh-aw - 参考本项目仓库结构（clone 地址：
https://gitcode.com/GitHub_Trending/skills17/skills），在.github/workflows/下编写智能体.md文件 - 执行
gh aw compile编译生成.lock.yml，两个文件一起提交 - 用
gh aw run <workflow> --dry-run先空跑验证，再实际运行
本项目里同体系还有 issue-investigate.md：当分诊后的 Issue 被加上auto-investigate标签时，深度调查智能体会对照代码库分析根因，甚至在修复方案明确时直接创建草稿 PR——分诊只是第一环。
延伸：PR 侧也有一套自动分诊
除了 Issue，PR 侧同样有完整的自动化分诊体系，详见 docs/design/pr-triage-workflows.md：
- 每小时批量编排：枚举所有开放 PR，计算确定性状态并派发 worker
- 单 PR worker：维护唯一
pr-state/*标签，触发评测、@ 作者或 @ 维护者，并有 4 天冷却期防止骚扰 - 每周僵尸 PR 清扫：30 天无活动发警告，37 天直接关闭
写在最后
dotnet/skills 的 issue-triage 智能体展示了一套可直接借鉴的 AI 分诊范式：Markdown 定义逻辑 + 编译成受控流水线 + 严格的操作限幅与不可信输入隔离。对个人开发者，最有价值的三点是——打标签宁缺毋滥、无法确定负责人就标记转人工、每次分诊给出置信度自评。这套方案既保证了自动化效率，也把出错半径控制在"一条评论、几个标签"之内。
【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考