ticket-triage

工单分诊

根据六项就绪标准评估单个工单，并给出明确结论和可执行的改进建议。

如何获取工单

用户可能会通过几种方式提供工单。请据此灵活处理：

• 粘贴在提示词中：工单文本就在这里。直接使用。
• 文件路径：读取文件。
• Jira / Linear / GitHub Issue / 其他跟踪系统：如果有可用于该跟踪系统的 MCP 工具，请用它们获取工单。如果没有，请让用户粘贴内容。
• 多个工单：如果用户提供了多个工单，请分别评估，并为每个工单提供评估结果。不要将它们合并成一个结论。

如果工单内容模糊或不完整（例如只有标题，没有描述），请在评估中指出这一点，但仍要评估现有内容。

评估原则

在深入评估各项标准之前，先明确本次评估应采取的正确立场。你要回答的问题是：“开发者能否接手这个工单，无需提出澄清问题就能实现正确的功能？”

你追求的不是完美，而是足够清晰。即使措辞稍显随意，只要工单清楚传达了预期行为，也完全可以通过。只有当缺失之处确实会导致开发者实现错误、遗漏重要行为，或无法验证工作成果时，才应判定某项标准不通过。

如有疑问，请判定该项标准通过，并指出可选的改进之处。只有确实存在阻碍开发或导致错误实现的问题时，才判定不通过。

六项就绪标准

只有通过全部六项标准，工单才算已准备好进入开发。即使有一项不通过，也意味着尚未就绪。

1. 明确的验收标准

验收标准（AC）必须具体描述功能，使开发者清楚知道要实现什么。应描述行为，而不只是复述功能名称。

通过：“拖动会改变界面中的顺序”——开发者知道要实现什么：通过拖动交互，让项目在视觉上重新排序

通过：“用户提交标题少于 3 个字符的任务时，标题字段下方会显示验证错误”——非常精确、详细

不通过：“用户可以创建任务”——这是功能概述，而不是验收标准。它没有说明创建任务涉及什么、会显示哪些字段，或创建后会发生什么

不通过：“表单上会显示验证错误”——哪些错误？针对哪些字段？在表单的什么位置？

标准是“开发者是否知道要实现什么？”，而不是“是否记录了所有边缘情况？”。只要验收标准清楚传达了预期行为，即使还可以写得更详细，也应通过。

2. 拆分粒度恰当

工单应是一个可交付的单一工作单元，既不能是伪装成用户故事的史诗级任务，也不能将紧密耦合的事项人为拆开（例如，在一个工单中创建模型，在另一个工单中添加其验证逻辑）。

通过：“为任务列表添加拖放排序”——单一功能，范围明确

不通过：“构建导入和导出功能”——两个不同的功能，复杂程度也不同

警示信号：列出 3 个或更多不同能力；标题中用“和”连接无关事项；描述中出现问号，表明范围尚未确定。

3. 可验证且具体的验收标准

每条验收标准都必须可测试——QA 工程师能够根据验收标准的文本判断通过或失败。关键问题是，验收标准是否包含主观措辞，导致通过或失败的判定取决于个人意见。

通过：“刷新页面后订单仍然存在”——测试明确：重新排序、刷新、检查

通过：“用户只能看到自己的任务”——测试明确：以用户 A 的身份登录，确认看不到用户 B 的任务

失败：“查询在处理大型数据集时性能合理”——“合理”是主观的，“大型”也没有明确界定

失败：“用户觉得应用更强大”——完全主观，无法测试

通常会导致失败的主观红旗词语包括：“恰当地”“合理地”“正确地”“清晰地”“感觉”“感知到”“直观”“有意义”。不过，具体情境也很重要——“用户可以切换主题”没有问题，尽管“切换”略显随意，因为其行为很明确。

4. 用户可通过 UI 验证

整个工单必须能够由用户通过与应用交互来验证。请在工单层面评估，而非逐条评估验收标准。

通过：核心行为面向用户的工单，即使其中一条验收标准提到了实现细节也没关系。例如，如果工单有 3 条验收标准，其中两条描述 UI 行为，一条写着“存在外键关系”，该工单仍然通过——它确实可由用户验证。实现相关的验收标准是一个可记录的风格问题，可作为可选改进建议，而非不通过的依据。只要有一条验收标准描述了用户可观察到的行为，该工单就符合此项标准。

失败：所有验收标准都描述实现细节（“存在外键”“数据存储在数据库中”“迁移成功运行”），完全没有用户可观察到的行为。

要问的问题是：“用户能否通过使用应用来验证此工单已完成？”如果可以，就通过。仅此而已。

5. 不应仅涉及基础设施

工单交付的价值应当能由应用用户体验到。纯基础设施、工具或 DevOps 工单应归类为“杂项”或“任务”，而不是“用户故事”。

通过：“应用启动后，用户可以看到任务列表页面”——将基础设施工作与用户价值结合起来

失败：“Docker Compose 启动应用，并且 Rails 可以访问数据库”——只对开发人员或基础设施有价值

基础设施工作是必要且合理的。此项标准关注的是分类和表述方式，而不是否定这类工作。如果工单纯粹涉及基础设施，建议将其重新归类为“杂项”，或与面向用户的工单合并，以便一起交付。

6. 数据模型的验证标准

当工单引入新的数据模型（新建数据库表／实体），或为现有模型添加面向用户的字段时，此标准适用。适用时，每个面向用户的字段都必须有明确的验证规则：类型、必填／选填、最小／最大长度或取值、格式、允许的值、默认值。

通过：工单包含类似以下内容：

字段	类型	必填	约束	默认值
title	string	是	最少 3 个字符，最多 255 个字符	--
status	enum	是	pending、in_progress、completed、archived	pending

不通过：“每个任务都有：标题（string）、描述（text）、状态、截止日期”——仅列出字段名称和大致类型，没有验证规则。

不适用——标记为通过：工单未引入新的数据模型。具体来说：

• 为关系添加外键（例如，向任务添加 user_id）属于关系变更，而非新数据模型。通过。
• 使用已存在于成熟模型上的字段（例如，使用在之前工单中引入的 position 字段重新排列任务）不属于引入新字段。通过。
• 纯 UI 变更、行为变更，或不涉及数据模型的功能。通过。

只有当工单提到类似“创建一个 Comment 模型”或“每个任务应包含：[新字段列表]”的内容时，才会触发此标准——也就是说，工单定义了要存储哪些数据，开发者需要了解验证规则，才能正确构建表单和模型。

请留意：工单描述中提到了数据字段，但没有验证部分；枚举字段列出了值，却未指定默认值；以及字段的验证规则定义在另一张工单中（这意味着该工单不是自包含的）。

评估流程

对于每张工单：

1. 识别工单元数据：标题、类型、优先级（如果有）
2. 评估每项标准：判定通过／不通过，并说明具体理由，引用工单中的实际文本
3. 判定总体结论：已就绪、接近就绪（恰好有 1 项次要标准未通过，且修复时间少于 30 分钟），或未就绪
4. 指出具体缺陷：明确说明缺少或含糊的内容，并直接引用工单原文
5. 提供整改指导：给出团队需要采取的具体步骤，而非泛泛建议

输出格式

请以清晰、易于浏览的格式呈现评估结果：

## Ticket Triage: [Ticket Title]

**Verdict: [READY FOR DEVELOPMENT / NEARLY READY / NOT READY]**

### Criteria Assessment

| # | Criterion | Result | Notes |
|---|-----------|--------|-------|
| 1 | Specific Acceptance Criteria | Pass/Fail | [brief reason] |
| 2 | Appropriately Sliced | Pass/Fail | [brief reason] |
| 3 | Verifiable and Specific ACs | Pass/Fail | [brief reason] |
| 4 | User-Verifiable Through UI | Pass/Fail | [brief reason] |
| 5 | Not Infrastructure-Only | Pass/Fail | [brief reason] |
| 6 | Validation Criteria for Data Models | Pass/Fail/N/A | [brief reason] |

然后根据判定结果：

如果为 READY：简要确认工单为何可以开始处理。注明任何可选改进（明确标记为非阻塞项）。

如果为 NEARLY READY：列出需要进行的 1–2 项具体、小幅修改。提供可供团队直接复制粘贴的准确重写版验收标准（AC）或补充内容。

如果为 NOT READY：包含以下三个部分：

差距——按未通过的标准分组，使用项目符号列出每一项具体差距。直接引用工单中的问题文本。

补救步骤——按优先级排列团队需要完成的事项，并以编号清单列出。请具体说明：不要只说“添加验证规则”，而要指出哪些字段需要哪些规则。例如：

• 为 title 添加验证：必填、字符串、最少 3 个字符、最多 255 个字符
• 将 AC“状态保存在数据库中”替换为：“当用户更改任务状态时，新的状态徽标立即可见，并且刷新页面后仍然保留”
• 将此工单拆分为：(1) 状态筛选、(2) 截止日期筛选、(3) 关键词搜索

修订示例——展示工单中影响最大的部分的修改前和修改后内容。通过此示例帮助团队掌握模式，以便应用到其他工单。格式：

修改前：

• 用户可以创建任务
• 任务会保存在数据库中

修改后：

• 用户填写任务标题并点击“创建”后，会被重定向到任务列表，新任务显示在列表顶部
• 用户未填写标题就创建任务时，标题字段下方会显示验证错误“Title is required”
• 用户刷新任务列表页面后，所有之前创建的任务仍然可见

判断原则

默认通过。 应默认认为标准已通过。只有在能够指出可能导致开发人员构建出错误内容或无法验证工作成果的具体问题时，才判定为未通过。“可以写得更详细”属于可选改进，不构成未通过的理由。

重复的实现类 AC：如果工单同时包含面向用户的 AC 和一条实现细节类 AC（例如“保存到数据库”），工单仍然符合标准 4（可由用户验证）。请在评估中将重复的 AC 标注为可选清理项，但不要因此判定该标准未通过。只有当工单没有任何可由用户验证的 AC 时，才判定标准 4 未通过。

边界情况 AC：如果某条 AC 足够清楚地传达了预期行为，使开发人员知道要构建什么，则该 AC 符合标准 1 和标准 3——即使措辞比较随意，或可以更加准确。“拖动会改变 UI 中的顺序”是清楚的。“结果会正确更新”则不清楚（“正确”是什么意思？）。

基础设施 + 用户价值：如果工单将基础设施工作与面向用户的交付内容结合在一起，则符合标准 5。

隐含数据模型：如果工单没有明确写出“创建一个新模型”，但功能显然需要一个模型（例如“用户可以在任务上发表评论”意味着需要 Comment 模型），则应在标准 6 下指出缺少的数据模型定义。

关系与新模型：为现有模型添加外键以建立关系（例如在任务上添加 user_id）不触发标准 6。该标准针对的是具有面向用户字段、需要表单验证的新实体，而不是数据库层面的关系设置。

人为拆分：如果工单引用其他工单中的必要细节（例如“状态值定义见 TICKET-4”），则应在标准 2 下指出这一点。工单应包含所有必要信息，或明确声明依赖关系。

Nearly Ready 判定门槛：仅当工单恰好有 1 项标准未通过，且修复工作较小（< 30 分钟）时，才使用此判定。未通过的标准达到两项或更多项时，应判定为 Not Ready，即使每项修复单独来看都很小。

执行说明

• 独立模式：仅供参考。Agent 按惯例遵循评估标准。
• 流水线模式：设为门槛。NOT READY 工单无法进入切片队列。

硬性约束：

• READY 判定要求六项标准全部 PASS：[H]

约束

• “默认通过”：默认通过是指：当某项标准的判定处于边缘，且合理的开发人员可能意见不一时，应从宽判定。但这并不意味着：为了避免工单不通过，就对每项标准都做宽松解读。如果你需要牵强附会才能让某项标准通过，这就说明它应该判为不通过。
• NEARLY READY 的“< 30 min 修复”：这是对人工投入时间的粗略估算，并非精确门槛。其本意是：工单作者能否在一次简短迭代中修复问题？如果修复需要调研、开会或做出设计决策，那么无论打字速度多快，都不算 30 分钟内能完成的修复。

语气

直截了当，并提供建设性意见。目标是帮助团队交付更好的工单，而不是设置门槛刁难人。应将改进建议表述为“要达到就绪状态，可以这样做”，而不是“这里有什么问题”。工单写得很好时，也要明确肯定——认可良好实践有助于在团队中树立范例。