Jira Issue 智能分类：用 Jira Automation 和 Jev 自动给工作项打标签

Jira Cloud 现在把 issue 叫作工作项（work item），把项目叫作空间（space）；自动化文档用的是新名称，而智能值仍以 issue 开头。接收大量请求的团队——无论来自服务台、收集表单，还是同事直接提单——都会在同一个第一步上花时间：读每个新工作项，判断它属于哪类工作。分类就是把这一步自动化：从一张简短固定的列表里贴一个标签，例如 bug、feature_request、question 或 other，让看板筛选、队列或下一条规则接手。把这个类别和另一个同样重要的问题分开：文本是否表明现在有人被阻塞？把它作为独立的是/否问题来问，而不是做成标签，用它来加评论或通知某人；在测出准确程度之前，不要用它改优先级。先从标签开始，因为加标签成本低、删起来也容易；改工作类型、经办人或状态会影响工作流和报表，那里的自动改错代价很高。如果你的 issue 在 GitHub 而不是 Jira，GitHub Issue 自动打标签指南用 GitHub Actions 讲了同样的思路。

六个组件。1）触发器：工作项已创建（Work item created），可用 JQL 限定只对需要分类的工作类型生效。2）操作：重新获取工作项数据（Re-fetch work item data），让创建时填写的字段在构造请求前加载完；Jira 在一次运行中不会自动刷新 {{issue}} 数据。3）操作：发送 Web 请求到 https://jevmodel.app/api/v1/systemone，方法 POST，加 Content-Type: application/json 头，以及 Authorization 头（Bearer 加上用已验证邮箱的账号在 JevModel Console → API keys 创建的密钥；勾选 Hidden，保存后该值会被遮蔽），请求体选 Custom data。勾选“Delay execution of subsequent rule actions until we’ve received a response for this web request”；如果希望 API 返回错误状态时仍走兜底分支，再勾选“Continue running the rule even if the request response is not successful”。4）If/else 块，用高级比较条件：{{webResponse.body.code}} 等于 0。5）在 if 分支里，用“编辑工作项”的附加字段 JSON 修改 Labels，添加 ai- 加上选中的标签；对是/否答案再加一个条件，可以添加评论。6）在 else 分支里加 needs-triage 标签。Jira 标签不能包含空格，这也是标签 ID 用 feature_request 这种写法的原因之一。

四个问题涵盖了大部分失败的规则。响应值为空：Atlassian 知识库列出的常见原因是没勾选等待响应选项、在发出请求的 if 块之外读取响应，以及响应的 Content-Type 不是 application/json；JevModel 返回的是 JSON，所以要重点检查前两条。JSON 被弄坏：带引号的摘要或带换行的描述原样粘进去会产生无效 JSON，所以每个值都用 asJsonString 包一层，它会转义特殊字符并加上引号。如果描述可能为空，加一个“描述不为空”的条件，或者只发送摘要。请求大小：整个 JevModel 请求（state 加 questions）必须在 8,000 字符以内，所以对描述用 abbreviate（示例保留 5,000 字符）。重复运行：JevModel 没有幂等键，如果规则挂在“工作项已更新”上，每次编辑都会发出一次新的计费请求，还可能在有人纠正标签之后再叠加标签；只在创建时触发。另有两点治理同样重要。Atlassian 提醒，能编辑规则的人就能把“发送 Web 请求”操作改成把数据发到别处，所以要限制规则编辑者。规则或该操作被复制、导出或导入时，Hidden 的头部值会丢失，之后要重新填入密钥。只发送摘要和描述，不发报告人姓名或邮箱。

Jira 自动化还提供“使用 Rovo 智能体”（Use Rovo agent）操作：它让智能体生成一段回复，再交给评论这类文本输出的操作。下表按文档对比各条路径的形态，不是准确率，也没有任何一行是基准测试。

规则在规则构建器里搭建，所以示例把每个组件写成文本，并给出要粘贴的值。请求遵循 JevModel 文档化的契约：用已验证邮箱账号的 Bearer 密钥 POST /api/v1/systemone，发送 state 和具名问题，这里是名为 kind 的 Choice 和名为 blocking 的 Noul；成功响应 code 为 0 并带 data.answers。没有 model 字段，因为本站始终通过 OpenRouter 调用 typesafe/jev-1.13；JevModel 与开发 Jev 的 TypeSafe AI 相互独立。ai- 前缀让自动标签容易查找和删除。Jira 智能值不方便按动态键取概率，所以这条规则直接加标签，把概率检查留给测试样本；如果需要按标签设阈值，就对 {{webResponse.body.data.answers.kind.probabilities.bug}} 等每个标签各加一个条件。blocking 的 0.8 只是占位值，不是推荐值。测试时用“记录”（Log）操作输出 {{webResponse.body}}，并查看规则的审计日志。

# Illustrative only. Jira Cloud automation rule, written out component by component.
# Trigger:  Work item created            (optional JQL: type in (Bug, Task, Story))
# Action:   Re-fetch work item data
# Action:   Send web request
#   Web request URL:  https://jevmodel.app/api/v1/systemone
#   HTTP method:      POST
#   Headers:          Content-Type = application/json
#                     Authorization = Bearer <your JevModel key>   [x] Hidden
#   Web request body: Custom data
#   [x] Delay execution of subsequent rule actions until we've received a response
#   [x] Continue running the rule even if the request response is not successful
{
  "state": {
    "summary": {{issue.summary.asJsonString}},
    "description": {{issue.description.abbreviate(5000).asJsonString}}
  },
  "questions": {
    "kind": {
      "type": "choice",
      "instructions": "Which kind of work item is this, based on its summary and description?",
      "criteria": {
        "bug": "Something that used to work is broken, slow, or shows an error.",
        "feature_request": "Asks for new behavior the product does not have yet.",
        "question": "Asks how to do something; nothing is broken.",
        "other": "Anything that fits none of the labels above."
      }
    },
    "blocking": {
      "type": "noul",
      "instructions": "Does the text say that users, customers, or a release are blocked right now?",
      "criteria": {
        "true": "Someone cannot continue their work until this is resolved.",
        "false": "Work can continue while this waits in the backlog."
      }
    }
  }
}
# If:  Advanced compare  {{webResponse.body.code}}  equals  0
#   Action: Edit work item → More options → Additional fields:
{ "update": { "labels": [ { "add": "ai-{{webResponse.body.data.answers.kind.choice}}" } ] } }
#   If:  Advanced compare  {{webResponse.body.data.answers.blocking.noul}}  greater than  0.8   (placeholder)
#     Action: Comment on work item: "Automatic check: this may be blocking someone. Please confirm."
# Else:
#   Action: Edit work item → Additional fields:
{ "update": { "labels": [ { "add": "needs-triage" } ] } }

已解决的工作项就是现成的标注集：它们的工作类型、组件或已有标签都是人设定的。用 JQL 筛选（例如上一季度已解决的工作项）导出几百条，保留摘要、描述和人工类别，把文本放进 JevModel Console → Batch，用同一个 Choice 问题跑一遍。Batch 返回逐行答案，但不会计算准确率，所以要在表格里和人工那一列对上。查看每个标签的一致率、哪些类别容易混淆（报告人把使用失误说成 bug 时，bug 和 question 经常混在一起），以及在并不紧急的工作项上 blocking 有多常为真。改写含糊的定义，用同一份样本重跑。然后先在一个空间里开启规则，读一周审计日志，统计人们删掉 ai- 标签的频率。别忘了旧类别是在时间压力下设定的；先读一些分歧，再判断是不是模型的问题。在这之后再考虑改经办人或优先级，并保持可撤销。

如果你想要的标签来自你掌控的列表，能被筛选器、看板和后续规则可靠地使用，而且你能维护一条带 JSON 请求体的规则，就选“发送 Web 请求 + Jev”。如果目标是生成一段供人在评论里阅读的摘要或建议，就选 Rovo 智能体操作。如果要测试定义，或在完全不改动 Jira 的情况下给一次性积压打标签，就选导出 CSV 加 Console → Batch。如果请求是以 Zendesk 工单、Slack 消息或 GitHub Issue 的形式到达的，有专门的指南覆盖这些来源。无论哪种的检查清单：1）写带明确 other 的标签定义；2）紧急程度用单独的是/否问题；3）只在创建时触发，因为 JevModel 没有幂等键；4）只发送摘要和描述，并截到 8,000 字符上限以内；5）限制谁能编辑规则，密钥放在 Hidden 头里；6）先用 ai- 标签和 needs-triage 兜底，在已解决的工作项上测过一致率后再扩大规则。JevModel 只处理文本，且不是开源项目；工作项上附带的截图、附件和日志不会被这条规则分类。