Replay QA

突出的是“给你的编码智能体提供根本原因和修复方案”这一点——大多数QA工具只停留在“这是失败的会话”，而这个工具似乎能真正闭环到修复。你发现智能体能可靠地利用这些上下文吗，还是说在应用之前仍然需要人来检查建议的根本原因？

有机会参与这次发布，第一次体验的速度让我震惊🤯

去 qa.replay.io，几秒钟就能拿到第一份报告。

你们后台用的是哪个模型，?makers？

这感觉像是 replay/devtools 方向的自然演进，把会话录制变成主动寻找 bug 而非等待用户触发。既然它自己探索应用，它是否也能深入检查像权限边界和跨用户数据隔离这类问题——那些从不报错、只是静默泄露或丢失数据的 bug？还是目前主要关注崩溃和 UI 流程断裂？这类 bug 在 vibe-coded 应用里极难捕捉，如果智能体能可靠地暴露出来，那将是个重大突破。

恭喜发布！这篇文章精准指出了 QA 的痛点——AI 把构建时间缩短到几小时，而测试却跟不上。我们也遇到过类似情况：早期一半的 bug 都是在流程运行几次后才出现，第一次跑根本没问题。我总是回到 GitHub PR 流程——根本原因和修复直接贴在 PR 上。你们如何处理非确定性行为应用（竞态条件、不稳定的异步 UI）带来的误报？Replay QA 会在标记之前重新运行失败吗？还是由开发者来做分类？

录制会话 + 根本原因的组合才是亮点。发现某个东西坏了固然有用，但给编码智能体提供导致错误的具体交互、状态和上下文，就能省去 QA 和工程之间大量来回沟通。

第一次体验的速度也快得几乎有点可疑 :)) 好奇 Replay QA 如何处理不稳定或环境特定的行为。它能否区分真正的产品 bug、临时网络问题和只在特定浏览器或会话状态下才会出问题的情况？

恭喜发布了theproduct