@no_stp_on_snek: 实地笔记:AI与QA 将一个代理指向我的测试套件,只问一个问题。不是“测试通过了吗。” 这个测试能不能检测出它存在所要捕获的那个bug…
摘要
一篇实地笔记认为,全绿的测试套件并不能证明测试是有意义的;应该让AI代理尝试让测试失败,以验证它们确实能捕获bug。
实地笔记:AI与QA
让一个代理用一个问题去检查我的测试套件。不是“测试通过了吗。”而是“这个测试能检测出它存在所要捕获的那个bug吗?”
两个仓库里的17个测试文件都做不到。断言写得如此松散,什么东西都不会触发它们。几个月来一直显示绿色,下游所有人都信任它们。
一个绿色勾号只意味着测试运行了并且没有抱怨。它并不能说明一个根本无法抱怨的测试有什么价值。
所以现在我不先问覆盖率或通过率。我会要求看测试失败。给我看不了?那它就不是测试,只是一个亮着绿灯的装饰品。
查看缓存全文
缓存时间: 2026/08/09 03:17
现场笔记:AI 与 QA
我让一个 agent 去检查我的测试套件,只问了一个问题。不是“测试通过了吗”,而是“这个测试能检测出它本来要抓的那个 bug 吗?”
两个仓库里的 17 个测试文件都做不到。断言写得过于松散,没有任何东西会让它们失败。绿灯亮了几个月,下游所有人都信任它们。
绿色勾号只意味着测试跑了,而且没有抱怨。可对于一种根本没有办法抱怨的测试来说,它什么都说明不了。
所以现在我不会先问覆盖率或通过率。我会要求看着测试失败。你展示不出来?那它就不是测试,只是一个亮着绿灯的装饰品。
相似文章
你的AI代理绿色测试套件实际证明了什么
本文认为,由于输入空间无限且行为非确定性,AI代理使用固定输入和预期输出的标准测试套件并不充分,主张应采用基于属性的测试方法。
你的AI智能体只需一个糟糕的提示就能毁掉你的品牌(以及为什么传统QA毫无用处)
文章认为传统的聊天机器人QA是有缺陷的,因为它只测试了理想路径(happy path),并提出使用AI驱动的用户模拟器,通过多样化的角色和边缘案例来攻击机器人,在部署前发现漏洞。
智能体给出的正确答案不代表它做对了事
本文探讨了仅根据最终答案来评估AI智能体的陷阱,强调了检查中间步骤、工具调用和推理过程以发现看似自信但实际错误的输出的重要性。文章建议使用自动评分和轨迹回放来测量并改进智能体的行为。
不可能测试自己的智能体。我试过了,失败了。
一位开发者亲身讲述客观评估自己AI智能体性能的困难,强调了自我测试的陷阱以及意外真实世界基准的价值。
智能体失败应成为评估标准,而不仅仅是追踪记录
主张将智能体失败视为评估基准,而不仅仅是追踪日志,强调需要对AI智能体行为进行系统性测试。