我找了下，应该是这个：https://github.com/zhoujinjian/skills/blob/main/skills/api-failure-diagnoser/SKILL.md!/uploads/photo/2026/91aa3049-f8b8-4db8-8d03-4195cb002708.png! large)[](

好的，我查看下能否解决问题

感谢楼主分享，我有个问题需要请教下，对于输入和输出不确定的 Agent，使用此项目能否完成测试

好的，我尝试回复下，可能存在错误，还请批评指正：
1、传统测试与大模型业务测试本质上没有太大的区别，而测试大模型业务需要转换思考问题的方式，传统测试是代码逻辑比较固定，而测试结果大多数只有通过/不通过，大模型业务测试本身存在随机性，动态性，要结合业务特点制定通过标准，比如，同样得问题不同的人问，返回的结果不一样，那么要去考虑如何降低幻觉等问题。

传统测试与大模型测试的核心差异可归纳为：
从 “确定性” 到 “概率性” ：接受生成结果的合理波动，但需量化控制风险边界。
从 “功能验证” 到 “内容治理” ：不仅要确保功能正确，更要防范生成内容的安全与合规风险。
从 “单点工具” 到 “全栈工具链” ：需整合模型微调、评估、监控的一体化平台，而非孤立工具。
需在思维、技能、工具链三个层面同步升级

2、我了解到的一些信息为，业务本身的模型所使用的数据来源大致为：模型本身数据、业务私有化数据、向量数据。我们可以先暂时不考虑模型本身的数据，我们侧重于业务数据和对应向量数据，可以理解为 A 数据集。测试数据应依赖于业务数据和向量数据去制造相反测试数据集 a。a 数据集里存在金标准用例，即通过用例，存在相反数据是检验业务本身处理异常数据和噪声数据的能力。分类可以分为：【金标准类】此类下用例要全部通过，为业务数据。【95% 类】此类型下用例通过率达到 95 以上。【敏感类】此类包含敏感信息、犯罪、暴力等信息。【噪声类】基于金标准类用例衍生出噪声用例，完美预期是通过率为 0。【基本常识类】业务本身的一些常识，例如金融类专业属于是否能够理解、行业常识是否能够回答等。基于多个数据集下的测试结果和制定通过标准公式算出通过率。例如，通过率低于 60%，此功能是不是可以认定为测试不通过。
3、数据来源补充：可以根据业务需要什么数据，爬对应数据，但要遵守法律法规 (保命语句)

我的一些拙见，如果需要测大模型应用，建议学习一些大模型基本知识，可以参考下高飞总的博客：https://testerhome.com/articles/38557

这个可以明确下获取大模型的途径，如果是调用官方接口，那么需要考虑到接口异常后业务侧的展示等，如果是公司内集群部署，需要考虑集群异常和故障自恢复能力。需要对大模型应用入口稳定性关注。底层文档性关注后，那么则对业务尽场景可能测试异常场景。

除了关注产品文档上那一点黑盒的东西外，还应该关注研发处理提问用户词的逻辑。还有根据词抽取数据（模型数据/私有化数据/向量数据）的正确性（抽取数据是否符合预期）和数据展示安全性（敏感数据/歧视性数据是否能够拒绝回答，和敏感字段的脱敏展示策略）。总的来说，除了大模型本身的能力外，需要重点关注业务层结合模型处理的业务逻辑的处理规则。

听了下，真不错

依靠 Bug 数量衡量？