qa-only

qa-only 概览

qa-only 是一个仅报告、不修复的 QA skill，适用于你希望对 Web 应用进行测试、记录 bug，并捕获证据，但不做任何修复的场景。qa-only 最适合 QA 审核人、产品负责人，以及需要清晰 bug 报告流程、而不是“测试—修复—验证”闭环的 agent。如果你的目标是“找问题并写成报告”，qa-only 就很合适；如果你需要改代码，请改用 /qa。

qa-only 用来做什么

这个 skill 重点输出结构化的 QA 结果：健康评分、截图、复现步骤，以及清晰的 bug 报告。它专为“只检查 bug”与“测试但不要修复”这类请求设计，可以在用户想要的是证据而不是实现时，减少歧义。

qa-only 为什么不同

qa-only skill 的核心价值在于克制。它会把 agent 引导到报告行为上，避免误做修复工作；当交付物是评审材料、分诊记录或交接报告时，这一点尤其重要。也正因为如此，qa-only for Qa 在修复动作不在范围内或存在风险的环境中格外有用。

适用场景与不适用场景

当你需要对现有应用做一次 QA 检查，尤其是用于发现 bug、排查回归问题或形成书面评估时，用 qa-only。如果你需要代码编辑、重构或迭代式修 bug，就不要把它当作通用测试助手安装；qa-only guide 的设计本来就是“先报告，不先修复”。

如何使用 qa-only skill

安装并验证这个 skill

使用基于 repo 的安装流程：npx skills add garrytan/gstack --skill qa-only。安装后，在把它用于正式工作前，先确认 skill 文件已经出现在你的 skills 目录中，而且可以正常读取。只有当你的 agent 能在 QA 运行时真正加载到 skill 上下文时，qa-only install 才有实际价值。

给出合适的起始提示词

一个高质量的 qa-only usage 提示词应该明确应用、测试目标、“只写 bug 报告”具体是什么意思，以及边界在哪里。好的输入例如：“在 staging 上检查 checkout flow，只报告可见 bug，包含复现步骤和截图说明，不要建议修复方案。” 像“帮我 QA 这个应用”这种弱输入，会给模型留下太多猜测范围和严重程度的空间。

先读这些文件

先从 SKILL.md 看起，再查看 SKILL.md.tmpl，理解生成后的工作流是如何组装出来的。因为这个 repo 不包含额外的 rules/、resources/ 或脚本，这两个 skill 文件才是行为、触发条件和约束的真实来源。如果你想在采用 qa-only 之前先弄清楚它的工作方式，这是最快的路径。

放到实际 QA 工作流里使用

一个好的 qa-only guide 工作流是：先定义测试范围，明确预期行为，让 skill 做一次聚焦评审，然后把输出整理成 bug 清单或 QA 备忘录。如果第一轮结果太宽泛，就把范围收窄到一个用户旅程、一个设备/浏览器，或者一个 release candidate。这个 skill 最强的地方在于任务边界清晰、报告格式明确时。

qa-only skill 常见问题

qa-only 只适合浏览器应用吗？

大体上是。qa-only 面向 Web 应用 QA 和 bug 报告，因此很适合 UI 流程、staging 环境，以及可以直接观察和记录的用户旅程。对于纯后端验证，或者没有任何可见产品行为的任务，它就没那么有用了。

它和普通提示词有什么区别？

普通提示词也可以要求做 QA，但 qa-only skill 会带来一致的报告姿态，以及更明确的“不要修复”行为约束。这样一来，当团队需要的是一份干净的问题报告，而不是分析与实现混在一起的结果时，就能减少来回沟通。

qa-only 适合新手吗？

适合，只要用户能说清应用、环境和目标即可。新手最常见的错误是范围描述不够明确；qa-only guide 最适合在你明确告诉它要测什么、要收集什么证据、不要做什么的时候使用。否则，报告可能过于笼统，难以直接采取行动。

什么时候不该用 qa-only？

如果你的真实需求是调试、打补丁，或者做端到端修复验证，就不要用 qa-only。如果你需要深入的测试自动化搭建、基础设施工作，或者任何依赖代码写权限的事情，它也不是合适选择。

如何改进 qa-only skill

收窄范围，并强化验收信号

提升 qa-only 输出的最好方式，是定义一个清晰的目标和一个明确的成功条件。例如：“在 mobile Safari 上测试登录表单，报告验证失败问题，附上步骤、预期与实际结果，以及截图引用。” 这样能给 skill 一个可衡量的框架，而不是一个模糊的审计请求。

补足报告应该包含的证据

如果你想要更有用的 qa-only 报告，就应该要求具体产物：复现步骤、受影响的 URL 或 route、严重程度、出现频率，以及问题是阻塞型、外观型还是偶发型。相比直接说“找 bug”，这种要求更有效，因为它会迫使模型输出结构化结果，方便别人快速接手。

注意常见失败模式

最常见的失败模式是覆盖面过大：agent 试图把所有内容都测一遍，结果报告变得很浅。另一个失败模式是把修复意图混进只报告任务里，这会削弱 qa-only 的定位。如果出现这种情况，就把请求明确改写成“只报告，不修复，不改代码”，并缩小测试面。

用第一轮报告迭代到第二轮复测

先用第一轮发现最可能的问题，再针对最重要的 bug 路径跑第二轮 qa-only。当第一份报告暴露出一条关键流程，但你还想进一步确认边界情况、浏览器差异或复现稳定性时，这种做法尤其有用。通过迭代，qa-only 会从一次性的提示词变成可靠的 QA 习惯。