把 QA 报告、Bug 报告、测试总结改写成工程师口吻（去…

当你需要把 AI 生成的测试报告、Bug 单、状态更新改得像真人工程师写的、且不新增任何数字或严重级别时使用。

适用场景

解决思路

1. 先查 `.agents/qa-project-context.md`，里面已有的团队语气、跟踪工具、严重级别约定直接沿用，不再重复询问。
2. 只澄清会改变改写结果的三件事：读者是谁（工程师要失败选择器和复现步骤；高管要 ship/no-ship 和阻塞项；客户要影响和时间线）；渠道是什么（Slack 2-3 行加链接，PR 评论给具体代码/选择器修复，正式报告才要结构）；数字和严重级别是否为必须逐字保留的锁定事实（源里写 9 failed、P1 就原样保留，缺失就点明缺口，绝不编造）。
3. 核心原则一：具体胜过全面。写“邮箱带加号时登录失败”，不写“发现多种认证边界情况”；点明行为、触发条件、影响范围。
4. 核心原则二：说发生了什么，而不是它属于哪个类别。把“认证模块”这类桶换成“带加号邮箱的登录”这类具体 bug。
5. 核心原则三：如果读者看不出哪里坏了、该做什么，报告就是失败的。为周五下午 4 点要修它的人写：先讲坏了什么/有什么风险，再讲该做什么。
6. 核心原则四：保留每一个事实，砍掉每一个形容词。数字、错误字符串、严重级别、bug 描述、测试结果一律不得变动，只删填充词、模糊措辞和同义词轮换。
7. 核心原则五：绝不编造要求你补上的具体信息。源里含糊且数字无法核实，就写“用户影响未测量”，不要写“8% 的用户”；编造指标比含糊更糟。
8. 改写模式 1（模板式开头，最严重）：删掉“测试执行已成功完成……”这类铺垫，直接写“Sprint 47：跑了 342 个测试，9 个失败，6 个在 checkout 的支付表单校验，另外 3 个是见过的 flaky 时序问题”。
9. 改写模式 2（夸大严重级别）：把“认证模块发现严重缺陷，可能影响多触点用户体验”改成“邮箱含 `+` 时登录中断，分析显示约 8% 用户是加号邮箱，发布前必须修”（8% 必须来自源里的分析数据）。
10. 改写模式 3（痴迷通过率）：把“通过率从 94.2% 升到 97.1%，体现团队对质量的承诺”改成“通过率 94%→97%，主要来自修好 3 个 dashboard 加载超时的 flaky Playwright 测试；真正发现的 bug：2 个，都在新的导出功能”。
11. 改写模式 4（泛泛的风险语言）：把“已识别若干高风险区域，建议持续警惕”改成“支付流程对 3D Secure 卡没有 E2E 覆盖，过去 6 个月因此出过两次生产事故，建议优先于 admin panel 的工作”。
12. 改写模式 5（测试结果同义词轮换）：把“认证测试通过/登录验证套件无问题/凭证校验返回正面结果/登录流程符合预期”合并成一句“所有 auth 测试通过（login、registration、password reset、SSO）”。
13. 改写模式 6（“尽管有挑战”式结尾）：把“尽管测试阶段遇到若干挑战，团队仍成功完成全部计划活动，未来将聚焦持续改进”改成“这个 sprint 没做移动端浏览器测试——checkout 回归后没时间了，顺延到下个 sprint，其余都完成了”。
14. 改写模式 7（含糊的干系人更新）：把“质量指标持续向好，团队目标一致，致力于高质量发布”改成“这次发布没问题：4 个 bug 未关，都是 P2 或更低；登录加号 bug（P1）昨天已修；staging 冒烟测试通过”。
15. 改写模式 8（什么都没说的 PR 评论）：把“实现很棒！注意到几个可能提升测试覆盖和健壮性的改进点”改成“这个测试只覆盖 happy path，API 返回 429 时会怎样？另外 `.btn-submit` 选择器一旦有人改 CSS class 就会坏，改用 `getByRole('button', { name: 'Submit' })`”。
16. 改写模式 9（Bug 报告注水）：先写坏掉的行为，再给两行复现和真实错误/状态码，例如“删除用户不会吊销其 API token，删除后仍能调 API。复现：建用户→签发 token→`DELETE /api/users/{id}`→用该 token `GET /api/me`，返回 `200 OK` 和用户数据而非 `401 Unauthorized`”，删掉“在进行全面回归测试时发现”这类铺垫。
17. 改写模式 10（三段式总结）：把“本 sprint 提升了质量、速度和信心，团队展现了协作、技术卓越和客户导向”改成“本 sprint 修好了 checkout flakiness（失败率 12%→<1%），并为新的导出功能加了 E2E 覆盖”。
18. 改写步骤 1：砍掉开头段落。第一个有用事实之前的内容全部删除。
19. 改写步骤 2：把最重要的放最前——什么坏了、什么有风险、该做什么。
20. 改写步骤 3：把类别换成具体内容。“认证模块”→“带加号邮箱的登录”；“性能下降”→“dashboard 加载要 8 秒（原来 2 秒）”；“若干边界情况”→“空购物车、过期优惠券、货币不匹配”。
21. 改写步骤 4：杀掉填充词，删除 `references/filler-blocklist.md` 里的所有短语，如“It is worth noting that”“Moving forward”“Despite challenges”“The team is committed to”“Stakeholders can feel confident”。
22. 改写步骤 5：补充有用信息但不编造——读者下一步该做什么、不做有什么风险、你有多确信（“我不确定这还稳不稳”也可以）；支撑结论的数字若源里没有，就说明没有，不要造。
23. 改写步骤 6：大声读一遍。如果 standup 上你不会这么说，就重写。
24. 按格式改写：测试执行总结先写失败数、位置、是否新增，跳过总数和通过率（除非被要求），补充尚未覆盖的部分和需关注项。
25. 按格式改写：Bug 报告先写坏什么、怎么复现、谁受影响，跳过“在进行全面测试时……”，附上真实错误信息、状态码、截图或控制台输出。
26. 按格式改写：Sprint 更新（给干系人）先写发布就绪度（是/否/有条件）和未关阻塞项，跳过方法论、流程、团队士气，补上“如果我在决定是否发布，我想知道什么”。
27. 按格式改写：Slack 消息先给 2-3 行结果加链接，跳过问候和“我想分享……”。
28. 按格式改写：Postmortem 先写坏了什么、何时、持续多久、谁受影响，跳过“本 postmortem 旨在提供……”，诚实交代漏掉了什么及原因。
29. 避免反模式：不要为了显得具体而编造百分比、事故次数或复现步骤；测试失败时不要用“测试执行已成功完成”开头；不要用“潜在影响”代替实际影响；不要写“团队目标一致”；不要把 3 条 bullet 换词扩成 12 条；不要用无信息的乐观结尾；不要用被动语态隐藏谁坏了什么；Bug 报告不要从测试会话开头。
30. 验证步骤 1：用 `grep -oE '[0-9]+(\.[0-9]+)?%?|P[0-3]|[0-9]{3}' input.md | sort -u > /tmp/in.txt` 和同样命令对 output.md 生成 /tmp/out.txt，再 `comm -13 /tmp/in.txt /tmp/out.txt`，输出必须为空（仅允许明显四舍五入，如 97.4→97）。
31. 验证步骤 2：把 `references/filler-blocklist.md` 里的 grep-ready 正则拷进 `BLOCKLIST` 并 `grep -iE "$BLOCKLIST" output.md`，应无输出；有命中就重写那一行。
32. 验证步骤 3：把输出再过一遍全局 `humanizer`（或 `avoid-ai-writing`）技能的 detect 模式，不应再标记破折号滥用、三段式或模糊归因；若标出本技能漏掉的 QA 特有问题，也一并修掉。
33. 完成标准：输出中每个数字、严重级别、错误字符串和 bug 描述都出现在输入中（步骤 1 的 `comm -13` 为空，四舍五入除外）；填充词正则零命中；无同义词轮换（每个测试结果只说一次）；通过全局 humanizer 检查；交付物是改写版，原稿归档或丢弃，不随改写版一起交付。

适用边界 · 注意事项

• 不适用于通用散文、博客或营销文案的清理——那用全局 humanizer 技能。
• 不适用于对 CI 失败进行分类或路由——那用 ai-bug-triage。
• 源文本含糊且关键数字无法核实时，不要为了“更具体”而编造百分比、事故次数或复现步骤。