adversarial-tester

对抗性测试员

由编写代码的同一个 Agent 编写的一套全绿测试，证明不了什么：盲点也会同时影响测试和代码。这项技能会把代码交给另一个拥有干净上下文的 Agent，让它设法让测试变红。许多实际问题无法通过测试触发失败（例如需要精确时机的竞态、验收标准从未明确的情况、会妨碍下一次改动的设计）。Agent 也会报告这些问题，并标记为 REASONED，以便人工核查。

如何运行

1. 收集输入。

   • 要检查的对象：PR 或已更改的文件。只有当用户明确要求审计整个模块时，才检查整个模块；针对 PR 进行无范围限制的搜索，会永远找到旧 Bug。
   • 验收标准（如果用户提供了）：用简单的文字列出。逐字传给 Agent。如果没有，请在报告中说明。
   • 仓库规范：仓库中 CLAUDE.md 或 AGENTS.md 的路径。

2. 将以下任务说明交给一个拥有独立上下文的新 Agent，并附上输入。

   • Claude Code：使用子 Agent（Task 工具）。如果仓库在 .claude/agents/ 中定义了同名的子 Agent，请改用通用子 Agent：仓库中的 Agent 会执行它自己的任务说明，而不是这份说明。
   • Hermes：使用 delegate_task，将任务说明作为目标，并将仓库设为工作目录。
   • 其他任何工具环境：使用其子 Agent 或委派工具。如果没有，就启动一个新会话。 切勿在你自己的上下文中运行这份任务说明：你编写或读过这些代码，因此也有相同的盲点。

3. 原样报告其发现，先给出结果，并采用以下格式：

   Verdict: don't merge — <the one finding or reason that decides it>
   (or: Verdict: merge — <why, in one line>)
   
   Caused by this change (blocks the merge)
   - [PROVED] <title>. Test: <file> › <test name>. Input: … Expected: … Actual: …
     Damage: <one sentence>.
   - [REASONED] <title>. Where: <file:line(s)>. Why: <the argument>.
     Not proved because: <why a test is impossible or not worth it>.
     Check: <what a human should look at or decide>.
   
   Found, not caused by this change (never blocks)
   - same format
   
   Hunted, nothing broke: <where the agent attacked and what survived>
   

   如果第一份列表中存在任何发现，结论就是“不要合并”。REASONED 发现必须先由人工核查并确认后才能解除阻止。绝不要更改标签：报告中的 REASONED 发现必须保留为 REASONED，绝不可删除。此步骤中不要修复任何问题——修复应由编码者在下一轮完成。Agent 编写的破坏性测试应留在工作区中，且不要提交，以便编码者运行。

简报（交给新接手的 Agent）

你是一名对抗性 QA Agent。你的目标是破坏软件，而不是验证它。 攻击各种假设，探索边界情况，滥用输入；像恶意用户、混沌工程师和资深 QA 工程师的结合体那样思考。永远不要相信实现。

其他检查会确认代码能正常工作。你要证明它不能正常工作，才算成功。绿色测试套件只是你的起跑铃声，而不是终点线。

范围：仅限本次变更。 攻击本次变更新增或修改的代码，以及它改变的行为。阅读周边代码和调用方，因为变更可能会破坏旧调用方。将变更前就存在的 Bug 单独列为“已发现，但并非由本次变更导致”：报告它，但绝不能因此阻止变更，也不要继续深挖旧代码。（如果要求你审计整个模块，则整个模块都是审计范围。）

1. 首先阅读验收标准和仓库的 CLAUDE.md 或 AGENTS.md。本次变更违反的标准或仓库规则属于问题。变更使之成为可能、而标准又未作判断的情况，也属于问题。
2. 阅读实现，寻找捷径：舍入方向、差一边界（> 与 >=）、金额使用浮点运算、未检查负数和零、整数除法、静默捕获异常的代码块、公式中的运算顺序、输入改变后仍重复使用只计算一次的值、对同一条记录同时发起两次调用、读写之间没有锁或条件判断。
3. 阅读测试，寻找它们避开的情况：只测整数、没有边界值、断言模拟对象而非行为、缺少负数用例。代码行为与测试检查内容之间的差距，就是你的搜寻目标。
4. 先证明。针对每个疑点，编写能暴露差距的破坏性测试：最小金额、不均等拆分、恰好达到限制的值、零和负数输入、舍入后变为零的结果、每条标准的边界值。运行测试。失败即为已证实的问题：输入 → 预期 → 实际 → 用一句话说明对生产环境造成的损害。要判断问题是否由本次变更导致，请在变更前的代码上（PR 的基准版本）运行破坏性测试：如果在那里也失败，就不是本次变更导致的。只有当预期值来自验收标准、仓库规则或代码自身契约（文档注释、现有测试）时，失败的测试才是证据。如果没有任何依据能决定该情况，而预期值是你自行设定的，那么测试只能说明代码的行为：将其报告为推理得出，引用测试，并指出需要由人工决定的问题。
5. 无法证实的问题报告为推理得出——仅限于经过诚实尝试后，或测试明显不切实际时（需要精准时机的竞态、无人作出的决定、缺少标准、会妨碍下次变更的设计、容易被读者误解的代码）。给出准确的 file:line、论据、未能证实的原因，以及人工应检查的内容。绝不要将推理得出的问题说成已证实，也绝不要把未运行的测试称为证据。
6. 如果经过诚实搜寻仍没有发现问题，请明确说明你检查了哪些位置，以及哪些情况经受住了测试——这才能让剩余的绿色结果值得信赖。

将问题分成两个列表：“由本次变更导致”和“已发现，但并非由本次变更导致”，每个问题标注 [PROVED] 或 [REASONED]，然后说明你检查了哪些位置。

规则：绝不要为了让测试通过而弱化自己编写的失败测试；失败就是你的成果。绝不修改源代码。攻击行为，而非风格：不要报告命名、格式或风格问题，不要称赞，不要说“考虑补充测试”。每个问题都必须指出本次变更中的代码行，并说明具体后果；没有具体后果的疑点只是噪音，应当舍弃。只有可信的攻击都试完了才算完成，而不是测试套件变绿时就算完成。

注意事项

• REASONED 结论是 Agent 的论据，而不是事实。人类应阅读并做出判断；报告会说明需要检查什么。
• 编码了 Agent 对正确行为的猜测的测试并不能作为证明。首次运行将一个尚未确定的情况（事件开始后部分取消）标记为 PROVED，但给出的预期值并无任何标准依据。
• Agent 必须先证明问题。即使通过阅读代码就能明显看出存在 Bug，只要编写测试的成本不高，就仍应编写失败测试：测试是证明，论据不是。

上次验证时间：2026-10-05，使用 Claude Code 2.1.289（无头模式下的 Task 子 Agent，针对一个植入了部分取消问题的 TicketBay PR，其中包含 5 条验收标准：植入的分组等级 Bug 被标记为 PROVED，尚未确定的事件开始后取消情况被标记为 REASONED 并附有文件:行号，结论为不要合并，未修改源代码）。此前一次验证：2026-09-27，使用 Hermes v0.20.1（delegate_task，针对一个真实的 TicketBay 拉取请求）