qa-report-humanizer

一份精致却没说出问题的 QA 报告，不如一份粗糙但指出故障的报告。 “在身份验证模块中发现了一个严重缺陷”通过了所有语法检查，却什么也没告诉读者。这项技能会改写 QA 报告、Bug 报告、测试摘要和状态更新，让工程师能够据此采取行动。保留原文中的事实和不确定性；交付前，将改写内容与原文进行对照。

发现问题

先检查 .agents/qa-project-context.md——其中包含团队的语气、跟踪工具和严重性约定；已在其中回答的问题无需再问。之后只澄清会影响改写的内容：

• 谁会读这份内容——工程师、高管还是客户？ 工程师需要失败的选择器和复现步骤；高管需要知道是否发布，以及有哪些未解决的阻碍；客户需要了解影响和时间安排。不同受众所适用的语气和删减内容也不同。
• 发布渠道是什么——Slack、PR 评论还是正式报告？ Slack 内容应控制在 2～3 行，并附上链接；PR 评论应指出具体的代码或选择器修复；报告则需要结构化内容。长度和格式应与渠道相符。
• 是否有意不向这类受众披露某些信息？ 否则，应保留所有提供的数量、百分比、严重性、标识符、结果和重要限定条件。默认情况下，这些内容必须保留；不要征求保留它们的许可。指出相关证据的缺失之处，而不是编造信息（参见核心原则 5）。

核心原则

1. 具体胜过面面俱到。 “电子邮件地址中含加号时，登录失败”胜过“发现了各种身份验证边缘情况”。读者能修复前者，却无法从后者中学到任何东西。在原文有提供时，指出具体行为、触发条件和影响范围。缺少这些信息时，应指出缺失的细节，而不是编造更完整的说法。

2. 说清楚发生了什么，而不是给它归类。 “身份验证模块”只是一个分类；“使用带加号的电子邮件地址登录”才是一个 Bug。分类会让作者看起来考虑周全，却掩盖了他们并不了解具体情况。使用原文中的具体细节；如果原文含糊不清，可以简短说明仍有哪些信息未知。

3. 如果读者看不出哪里出了问题或该怎么做，这份报告就不合格。 为周五下午 4 点必须修复问题的人写作。先说明故障或风险，再指出应采取的措施。删去没人会看的部分。

4. 保留事实和不确定性。 改写只改变措辞，绝不改变数据。精确保留数字、严重性、错误字符串、测试名称、提交 ID 和时间戳，并确保它们仍对应相同的结果和环境。不要对百分比取整，也不要根据经过取整的通过率推算失败数量。保留“疑似”“未复现”“未运行”和“未批准”等表述：它们说明的是证据，而不是赘语。先前构建通过测试，并不能证明当前候选版本的状态。建议不等于批准。

5. 绝不要编造被要求补充的具体信息。 “写得具体些”容易诱使模型编造精确百分比、事件数量或从未见过的复现步骤。不要这样做。如果原文含糊不清，且无法核实具体数字，诚实的改写应指出信息缺口（“未衡量用户影响”），而不是写成“8% 的用户”。伪造指标比含糊的表述更糟糕。

需要识别并修正的 QA 专属 AI 表述模式

以下每个改写仅使用草稿中的事实。缺失的细节仍然缺失。

1. 模板式开场

草稿：“Sprint 47 的测试执行已成功完成。共在 5 个测试套件中执行了 342 个测试用例，通过率为 97.4%。”

改写：“Sprint 47：在 5 个测试套件中运行了 342 项测试；报告的通过率为 97.4%。草稿未提供失败数量、受影响的测试套件，也未说明失败是新出现的还是已知问题。”

经过取整的通过率无法得出精确的失败情况。不要为了让报告更有用，就编造结账失败或不稳定测试。

2. 夸大严重程度的措辞

初稿："在身份验证模块中发现了一个严重缺陷，可能会影响多个环节的用户体验。"

改写："报告称存在一个严重的身份验证缺陷。未说明异常行为、复现步骤和受影响的用户。"

保留报告中的严重程度，不要自行确认。只有来源提供了加号电子邮件地址和受影响用户的百分比时，才在此处提及。

3. 对通过率的过度关注

初稿："整体通过率从 94.2% 提高到 97.1%，这表明质量显著改善，也展现了团队对质量的重视。"

改写："通过率从 94.2% 提高到 97.1%。未说明变化原因，也未说明哪些测试发生了变化。"

保留精确百分比。没有证据时，不要将变化归因于修复、不稳定测试或产品缺陷减少。如果提供了原因，则先说明原因。

4. 泛泛而谈的风险措辞

初稿："已识别出几个需要密切监控的高风险领域。团队建议继续保持警惕并主动开展测试。"

改写："初稿称存在高风险领域，但未指出具体领域或拟议的检查。在确定优先级之前，请列出相关领域和证据。"

这是信息请求，并非声称存在支付覆盖或事故。

5. 用同义词反复描述测试结果

初稿："身份验证测试成功通过。登录验证套件顺利完成。凭据验证检查结果为正面。登录工作流测试按预期执行。"

改写："据报告，身份验证检查均已通过：登录、凭据验证和登录工作流。"

删去重复内容，但不要增加注册、密码重置或 SSO 覆盖范围。

6. 含糊的结尾

初稿："尽管测试阶段遇到了若干挑战，团队还是成功完成了所有计划中的测试活动。接下来将重点关注持续改进。"

改写："团队报告称，所有计划中的测试活动均已完成。初稿未说明遇到的挑战、测试结果或后续步骤。"

不要把已完成的计划说成跳过了移动端测试，或凭空编造后续计划。

7. 含糊的利益相关者更新

初稿："质量指标持续向好。团队就优先事项达成一致，并致力于交付高质量版本。"

改写："初稿未提供测试结果、未解决的阻塞项或发布决策，无法据此评估是否已准备就绪。在称发布已准备就绪之前，请补充这些证据。"

乐观的表述不能证明冒烟测试已通过，也不能证明已获得批准。

8. 内容空泛的 PR 审查评论

初稿："这个实现做得很好！我注意到有几个可能需要改进的地方，或许可以提升整体测试覆盖率和稳健性。"

改写："该评论指出可能存在覆盖缺口，但未说明具体测试或缺失场景。哪个场景需要添加断言？"

除非提供的代码或审查内容确实表明存在易失效的 CSS 选择器、缺少 429 场景或只覆盖了正常流程，否则不要声称存在这些问题。

9. 为已有证据的缺陷报告凑字数

初稿："在进行回归测试时，我们发现删除用户不会撤销其 API 令牌。复现：创建用户、生成令牌、DELETE /api/users/{id}，然后使用该令牌 GET /api/me。实际结果：200 OK，并返回用户数据。预期结果：401 Unauthorized。"

改写："删除用户后，其 API 令牌仍可使用。复现：创建用户、生成令牌，执行 DELETE /api/users/{id}，然后使用该令牌执行 GET /api/me。实际结果：200 OK，并返回用户数据。预期结果：401 Unauthorized。"

来源提供了此行为和复现步骤。如果来源只说“发现了一个用户管理缺陷”，则不足以支持上述任何细节。

10. 三条规则总结

草稿：“本次冲刺提升了质量、效率和信心。团队展现出出色的协作能力、技术水平和客户导向。”

改写：“草稿没有说明本次冲刺的具体工作或衡量数据。请补充已完成的改动及其结果。”

不要捏造从 12% 降至 <1% 的不稳定率变化，也不要编造新增的导出覆盖率。

如何改写

1. 梳理事实。 记录结果、数量、百分比、错误、严重程度、负责人、ID、日期、证据链接、未知信息和拟议行动。每项都要与其主体对应。
2. 先讲重点。 出了什么问题？有什么风险？应该采取什么行动？把这些放在最前面。
3. 使用已提供的具体信息。 只有当来源明确说明其行为时，才用具体内容替换类别。缺少的信息如果会影响读者的决策，就要指出。
4. 删掉填充内容。 将 references/filler-blocklist.md 作为编辑辅助。即使精确引用的错误、UI 标签、测试名称和证据中包含列表里的短语，也要原样保留。
5. 补充有用信息，但不要捏造。 读者接下来应该做什么？如果不做会有什么风险？你有多大把握（请如实说明，例如“我还不能确定这是否稳定”）？如果来源中没有支撑某项主张的数字，就直说，不要编造。
6. 大声读一遍。 如果你不会在站会上这么说，就重新改写。

特定格式指南

格式	开头先讲	省略	还要包括
测试执行总结	已提供的失败项及其状态	模板式开场和重复表述	精确数量和百分比、未运行的检查、构建标识
Bug 报告	哪里出问题、如何复现、影响了谁	“在执行全面测试时……”	实际错误消息、状态码、截图或控制台输出
冲刺进展（面向利益相关者）	是否具备发布条件（是／否／有条件）、未解决的阻塞项	方法论、流程、团队士气方面的表述	如果你要决定是否发布，你会想了解什么
Slack 消息	用 2-3 行说明结果 + 链接	问候语、“我想分享一下……”	—
事后复盘	出了什么问题、何时发生、持续多久、影响了谁	“本次事后复盘旨在……”	坦诚说明遗漏了什么以及原因

包含已提供事实的 Slack 示例：“大家好，我想分享一下，E2E 运行中有 2 个 dashboard 超时失败，正在调查。完整报告：[link]。” 改写：“E2E：2 个 dashboard 超时失败，正在调查。完整报告：[link]。” 在来源确认之前，不要把失败项称为不稳定、已知问题或通过。

反面模式

• 捏造要求你补充的具体信息。 把含糊的草稿改写得看似精确，却编造了来源中没有的百分比、事件数量或复现步骤。要指出信息缺口。
• 测试失败时以“测试执行已成功完成”开头。 开场与正文矛盾。先说失败项。
• 把不确定性写成确定性。 来源不确定时，就保留影响的可能性。说明已知信息和未衡量的内容，不要猜测。
• 在任何情境下都写“团队已达成共识”。 这句话没有传达任何信息，纯属 AI 腔。
• 把 3 条要点改写成 12 条来凑数。 这是同义词循环。一个结果，用一句话说明。
• 以不提供信息的乐观表述收尾。 “展望未来，我们将持续改进”——删掉。
• 用被动语态回避指出故障。 “发现了一个问题”隐去了主体。说清楚哪里出了什么问题。
• Bug 报告从测试环节而非 Bug 本身开始。 不需要“在进行模块回归测试时”。从故障行为说起。

验证

并排对照源文和改写稿。仅凭数字集合对比无法确认事实是否保留：这种做法会漏掉遗漏的事实、被替换的构建 ID 和颠倒的结果。

1. 对照证据清单。 对每一项重要的源文事实，检查它在输出中的具体值、主体、环境、日期和状态。正反两方面都要检查：输出中没有杜撰内容，源文中也没有事实被悄然省略。保留精确数字；除非用户明确要求，否则不得四舍五入。
2. 检查关联关系和不确定性。 失败不等于跳过；重试通过不代表首次失败就不作数。怀疑的原因不等于已确认的原因。在较早提交上运行的结果，不能作为较新候选版本的证据。拟议发布不等于已批准发布。缺失的证据仍属未知。将建议的后续操作标明为建议。
3. 检查语言。 检查参考文件中的填充语禁用列表，并去除重复表述。精确错误字符串或必须保留的引文中出现匹配内容时，应予保留。如果有全局 humanizer 或 avoid-ai-writing 技能可用，可以用它征求第二种意见；否则直接完成这项检查。缺少这些技能不妨碍改写。完成任何风格调整后，重新检查证据清单。

完成标准

• 源文中的重要事实及其精确值和关联关系均得到保留；输出中的每项事实陈述都有源文依据（验证步骤 1）。
• 未知事项、未运行的检查、重试、构建身份和批准状态均保留原意（验证步骤 2）。不得用此技能中的示例填补缺失事实。
• 除精确证据字符串和必须保留的引文外，均已去除填充语（验证步骤 3）。
• 不反复使用同义表达：每种不同的测试结果只陈述一次（不得串用“通过 / 顺利完成 / 返回肯定结果”等说法）。
• 交付内容是按要求语言和通道提供的改写版本。除非用户要求执行文件操作，否则不得删除或归档用户的原始文件。

相关技能

• ai-bug-triage — 缺陷报告模板和严重性／优先级矩阵。分诊用于判断缺陷是什么以及如何分类；此技能用于改写已完成分类的报告文案。
• qa-metrics — 实际应跟踪哪些指标。报告需要引用真实指标时使用此技能；此技能则确保这些指标带有背景信息，而不是沦为虚荣指标。
• qa-dashboard — 仪表板设置和利益相关者报告布局。此技能用于润色仪表板配套说明。
• quality-postmortem — 复盘结构和根因分析。先在那里撰写复盘，再在此处润色文案。

外部技能

这些技能属于全局 Claude 技能集，不在此仓库的 skills/ 目录中：

• humanizer / avoid-ai-writing — 通用的反 AI 写作工具。如果两者都适用且可用，可用它进行语言层面的润色（避免过度使用 em dash、三段式排比和模糊归因），并用此技能处理 QA 专用结构和事实保留。如果有工程师真实的站会或 Slack 表达风格示例，可将样本提供给全局 humanizer 的语气模式，让改写贴合该人员的风格，而非泛泛的“人类”语气。

参考文件（位于 references/）

• filler-blocklist.md — 禁用填充短语的可复制列表、可用于 grep 的可选语言筛查正则表达式、同义表达反复使用的迹象，以及用被动语态回避“是谁造成问题”的写法。