TC 审查工作流
目录
- 进度清单
- 纪律
- 铁律
- 拒绝优先（前置条件门控）
- 步骤 1 — 逐字加载两个来源 [中等自由度]
- 步骤 2 — 构建追溯矩阵 [中等自由度]
- 步骤 3 — 行质量检查 [中等自由度]
- 步骤 3b — 在“询问 PO/报告人”之前进行来源扫荡（强制）[低自由度]
- 步骤 4 — 报告良好 vs 需改进 [中等自由度]
- 步骤 5 — 通知项目的 TC-review 频道 [低自由度]
- QA 关闭（“完成”前强制）[低自由度]
- 技能构成
- 范围外
- 必须 / 绝不
- 必读文件
- 依赖项
评判一个已编写的测试用例文档——此工作流从不设计或编辑测试用例本身。它回答一个问题：此文档，按其编写内容，是否能够证明工单的 AC/EC 和业务规则将得到检查？
斜杠命令快捷方式（支持命令的运行环境）：/tc-review → commands/tc-review.md。
进度清单
在运行开始时将以下代码块复制到您的响应中，并在每项完成时勾选。失败的门控会将您送回其 返回： 行指定的步骤——从那里开始取消勾选。
TC 审查进度：
- [ ] 拒绝优先（前置条件门控）
- [ ] 步骤 1 — 逐字加载两个来源
- [ ] 步骤 2 — 构建追溯矩阵
- [ ] 步骤 3 — 行质量检查
- [ ] 步骤 3b — 在“询问 PO/报告人”之前进行来源扫荡（强制）
- [ ] 步骤 4 — 报告良好 vs 需改进
- [ ] 步骤 5 — 通知项目的 TC-review 频道（仅询问线程）
- [ ] QA 关闭（“完成”前强制）
纪律
遵循 shared-preamble.md 和 shared-must-never.md。
铁律
没有引用两方来源的发现无效
每一个发现都需比较两个在此会话中实际打开的内容：TC 文档自身的文本，以及工单自身的 AC/EC/业务规则文本（或设计来源，如 Figma/PRD，仅在实际打开之后）。如果仅凭一般的质量感受说“TC 看起来不完整”，而没有引用工单自身的措辞作为对比，则不是一个有效的发现——请阅读工单，然后进行判断。如果没有在此会话中实际打开任何来源，却声称涉及设计来源（精确复制文本、精确 UI 状态），这同样不是一个有效发现——请说“未验证——无法打开 {来源}”，而不是猜测。
这是 catch-ai-workflow 通常对已完成工作进行验证的相同纪律；此工作流是其在 TC 方面的特定实例，在执行之前（而不是之后）运行。
拒绝优先（前置条件门控）
在缺少以下两者时不得开始：
- TC 文档 — 一个表格、CSV 或 Markdown 文件，在此会话中可访问且可读；
- 对应的工单 — 一个带有 AC/EC 的 Jira 问题键或 URL（或用户明确指定的等效规格来源）。
🔴 停止 — 缺少任何一个，根据 skill-rules-style.md 在一个消息中停止。
跨组织/跨站点工单： 如果工单位于已连接的 MCP 未被授权访问的 Atlassian 站点上，请说明情况并要求用户授予访问权限（或直接粘贴 AC/EC）——切勿猜测云 ID，切勿转而使用浏览器登录来读取。
步骤 1 — 逐字加载两个来源 [中等自由度]
- TC 文档 — 按实际内容读取；不要重新输入、总结或“清理”措辞。记录准确的来源（工作表 ID + 标签页/gid、文件路径或 URL），以便后续每个引用都能回溯到它。
- 工单 — 从工单自身的字段（描述、自定义字段——某些项目完全将内容放在
description字段之外；两者都检查）中获取 AC、EC 以及任何业务规则/重新检查清单部分。准确引用 AC/EC 的标签和文本；切勿根据对类似工单的记忆进行意译。在两个地方都未找到 AC/EC → 按照拒绝优先门控停止。找到规格文本，但其条目没有 AC/EC 标签 → 🔴 停止 — 显示找到的文本，并在步骤 2 之前询问用户如何对其进行编号；切勿自行发明标签。工单或 TC 文档获取错误、超时或返回部分内容（截断的文本、缺失字段、未加载的标签页）→ 告知用户确切的错误或缺失内容，不要基于部分 AC/EC 或部分 TC 文档构建矩阵，将失败交给superpowers:systematic-debugging，并仅在完整文本加载后恢复步骤 1。 - 如果链接了设计源（Figma、PRD）且用户希望进行交叉验证，请在此会话中打开它。如果无法打开（无会话、无访问权限、只读且未呈现内容），请如实记录——它将成为任何相关发现旁边的“未验证”备注，而不是静默跳过。
步骤 2 — 构建追溯矩阵 [中等自由度]
对于工单上的每个 AC 和 EC，列出声称覆盖它的 TC 行：
| AC/EC | 声称者 | 状态 |
|---|---|---|
AC_01 | TC_003 | 已覆盖 |
AC_05 | — | 无 TC — 缺口 |
AC_02 | TC_007 | 标签错误 — TC_007 的预期结果匹配 AC_04 |
EC_01 | TC_010, TC_011 | 标签不一致 — 同行 TC_012 测试相同元素但无标签 |
状态是一个封闭列表 — 每行严格使用以下四个值之一，并按要求命名 ID：已覆盖 · 无 TC — 缺口 · 标签错误 — <TC> 匹配 <AC/EC> · 标签不一致 — <TC ids>。存在多个问题的行按顺序取该顺序中第一个适用值（已覆盖 之后）。工单自身 AC 列表中的空洞是规格级别的缺口，而非矩阵行——将在“需改进”下作为规格问题报告（参见必须 / 绝不）。
已划掉的 AC/EC 不计入。 工单中已划掉的行（例如 -AC_07-，通常标记为重复）不属于范围：将其从矩阵和报告中完全排除。不要提及它，即使作为“正确未覆盖”也不要提及。
业务规则和工单评论是上下文，而非额外的 AC。 阅读它们以理解 AC/EC 的含义，并用它们来判断 TC 是否测试了正确的内容。仅当业务规则或评论条目与 AC/EC 冲突时才报告它，并指出它矛盾的 AC/EC。没有对应 TC 但不与任何 AC/EC 矛盾的规则或评论不是发现。将其排除在“需改进”之外，也不要为此添加“规格说明”部分。
标记以下情况，并附上行/AC ID：
- 零个 TC 覆盖的 AC/EC；
- 其预期结果经核实匹配了不同 AC 的 TC；
- 同主题（例如共享的 UI 元素）在同行之间标签不一致——某些有 AC，某些没有，且没有说明原因。
步骤 3 — 行质量检查 [中等自由度]
对每一行应用 tc-quality-standards.md，查找这些审查特有的失败模式（与编写质量不同——这里关注的是他人编写的文档，因此问题是它是否可信，而非是否优雅）：
| 信号 | 为何重要 |
|---|---|
| 步骤未达到标题所声称的状态。 标题为“学习者查看 X”的行，其步骤在主页面就停止了，从未实际打开 X。 | 该用例无法验证其所声称要验证的内容。 |
| 预期结果是 AC 自身的句子，逐字复制，没有分解。 当工单在 AC 下列出了多个具体子项（字段、状态、按钮变体）时，只是重复 AC 句子的预期结果无法让测试人员逐行检查。 | 通过/失败变成了猜测。 |
| AC 列举了已命名的用例/状态（例如“用例 1–6”、“加载/空/筛选”状态），而文档仅用一个通用行覆盖所有状态。 | 即使该行标记为完成，大多数列举的状态仍未被测试。 |
| 测试数据在 AC 需要具体值的地方没有具体值（边界计数、特定的日期关系、命名的筛选选项）。 | 该行无法按原样执行——测试人员需要自己创造缺失的值。 |
| 该行测试的条件与 AC 的措辞不同。 AC 说“已滚动经过”，但该行使用“已观看至结尾”。AC 说“仅显示已发布的条目”，但预期结果从不检查状态。 | 该行可能通过，而 AC 自身的条件仍未测试。 |
| 预期结果比该行自身的测试数据所允许的更加模糊。 测试数据提供了计算答案所需的所有输入（分数、计数、公式），但预期结果仅说“排序正确”。 | 测试人员需要在执行过程中计算出期望值，因此错误的顺序仍可能被标记为通过。 |
| 该行的列互相矛盾。 前置条件说“4 个条目”，但测试数据只列出了 3 个。标题说“状态”，但预期结果只检查顺序。 | 无论测试人员遵循哪一列，另一列都是错误的。 |
| 工单的前置条件从每一行中都缺失（例如“用户已登录”）。 | 每一行都继承了一个未声明的设置步骤。 |
| 设置中命名了一个方法但未提供细节（“有一种方法使请求失败”、“准备足够的数据”）。 | 两个测试人员会有两种不同的设置方式。 |
不要标记不影响用例可信度的测试用例风格选择（命名约定、列顺序、优先级标签），除非用户明确要求进行风格审阅。在此处覆盖 tc-quality-standards.md：除非用户要求风格审阅，否则忽略其优先级属性和其审阅门控“已分配优先级”行。
步骤 3b — 在“询问 PO/报告人”之前进行来源扫荡（强制）[低自由度]
此工作流从不决定产品裁决，但它确实会提出规格级别的缺口和问题。在任何发现变成“询问 PO/报告人”或“规格不清”之前，执行 result-quality-gate.md 第 14 层中的来源扫荡：默认分支上的产品代码（包含 path:line）、其内联评论和 git log -L / blame；主工单及其所有评论；周边工单（父/史诗、链接项、同一屏幕或 API 上的兄弟工单，以及提交消息中提及的工单）；回归结果；以及设计节点。引用在发现旁边阅读的内容。来源已经回答了的问题是一个带有来源的发现，而不是一个问题。
产品克隆缺失或不可读（dependencies.md 中的 {MONOREPO} 检查失败）：不要停止审阅，也不要静默跳过代码层。在每个本应由代码层回答的问题旁边写下 代码未检查 — 无克隆，继续使用其余来源进行扫荡，并且永远不要将此类问题呈现为扫荡完成——它带着这条备注进入步骤 4。
每项输出：发现（或剩余问题）+ 带有位置的引用来源（path:line、工单键 + 评论、回归行、设计节点），或者当代码层无法运行时添加的 代码未检查 — 无克隆 备注。
返回： 扫荡已回答的问题作为一个带有来源的发现返回到步骤 2 或 3；只有没有来源能回答的问题才会进入步骤 4，作为“与开发/PO 确认”。
步骤 4 — 报告良好 vs 需改进 [中等自由度]
两个简短的列表，每个项目符号都锚定到行 ID、AC ID 或引用的文本——绝无无锚定的意见。
**良好**
- {发现，附 TC/AC ID 或引用}
**需改进**
- {发现，附 TC/AC ID 或引用}
→ 建议：{如何修复}
每个“需改进”项目都带有一个“→ 建议：”行，说明如何修复。没有修复方案的问题会让 TC 作者无从下手。每个建议必须来自某个来源，绝不能是虚构的值：
- 从行自身数据计算得出： 当测试数据已经包含输入时，算出值并给出（例如，每个计算分数的预期顺序）。显示数字，以便作者可以核对。
- 取自 AC/EC 措辞： 例如，用 AC 自身的短语替换错误的条件，或使用 AC 自身的文本添加缺失的预期结果子句。
- 没有来源提供该值（阈值、计数或工单从未说明的时间）：建议添加该值并说明由谁确认（“请与开发/PO 确认计数”）。切勿编造数字。
保持每个项目简洁。建议说明要改变什么，而不是重写整行。如果用户要求缩小范围（例如“放弃所有关于 X 的内容”），则从步骤 2-3 中删除该类别后重新生成列表——不要被动地手动编辑文本，因为同样的类别下次会以不同的措辞再次出现。
语言： 默认情况下与工单/TC 文档自身的语言匹配。混合情况 = 工单的 AC/EC 和 TC 文档使用不同语言编写 → 一次性询问用户希望用什么语言编写审阅报告。Helix 菜单和入门问题保持英语，遵循 user-communication.md；审阅内容本身遵循目标文档的语言，这是该文档已经携带的相同例外。
在步骤 5 发送之前，将审阅报告发布到聊天中——外部消息无法像聊天消息那样撤回。步骤 5 的线程询问是继续的信号；不要添加单独的“要发送吗？”问题。
步骤 5 — 通知项目的 TC-review 频道 [低自由度]
每次运行都会将完成的审阅报告发送到项目的 TC-review 频道。在发送之前，先询问用户希望在哪个线程中通知（例如，如果工单上已经有相关的讨论线程）。
QA 关闭（“完成”前强制）[低自由度]
当您认为所有步骤都已完成时，执行一次最终的 QA 检查：
- 是否所有“需改进”的发现都附带了引用来源？
- 是否所有“需改进”的发现都附带了建议的修复方案？
- 追溯矩阵是否完整且准确？
- 是否已通知项目的 TC-review 频道？
如果所有检查都通过，工作流即告完成。
技能构成
此工作流旨在作为更大 AI 代理技能套件的一部分使用。不应单独使用。预期的上下游技能包括：
tc-fe-prep-workflow/tc-api-prep-workflow：用于起草新的测试用例。testing-ticket-workflow：用于执行工单。review-result-workflow：用于审查录制的证据片段。retest-bug-workflow：用于重新测试修复。catch-ai-workflow：用于一般性已完成工作的验证。
范围外
此工作流明确不用于：
- 起草新的测试用例（参见
tc-fe-prep-workflow/tc-api-prep-workflow）。 - 执行工单（参见
testing-ticket-workflow）。 - 审查录制的证据片段（参见
review-result-workflow）。 - 重新测试修复（参见
retest-bug-workflow）。 - 进行风格或命名约定审阅（除非用户明确要求）。
- 决定产品裁决或业务逻辑。
必须 / 绝不
必须：
- 每个发现都必须引用 TC 文档和工单来源。
- 在开始之前检查前置条件门控。
- 在询问 PO/报告人之前执行来源扫荡。
- 为每个“需改进”的发现提供修复建议。
- 将完成的审阅报告通知项目的 TC-review 频道。
绝不：
- 在没有双方来源的情况下做出发现。
- 为已划掉的 AC/EC 创建矩阵行或报告条目。
- 从未打开的来源中引用设计细节。
- 基于通用质量感受而非工单措辞标记问题。
- 基于不完整的 TC 文档或工单数据进行操作。
必读文件
- shared-preamble.md
- shared-must-never.md
- tc-quality-standards.md
- result-quality-gate.md
- skill-rules-style.md
- user-communication.md
- dependencies.md
- commands/tc-review.md
依赖项
- 可以访问并读取 TC 文档（Sheet、CSV、Markdown）的工作环境。
- 可以访问 Jira 工单及其字段的工作环境。
- 可选：访问设计来源（Figma、PRD）以进行交叉验证。
- 可选：访问产品代码仓库以进行来源扫荡。