LLM 测试 Skill：从事实正确性到拒答与安全边界验证

5 分钟阅读 PolyForm Noncommercial 1.0.0

AI 测试Agent SkillsLLM 测试

大模型测试不能只问“回答对不对”。一致性、事实依据、安全边界、成本和延迟都会一起决定这个能力能否投入真实工作流。

LLM 测试 Skill 将这些维度转为可观察检查和验收规则，但不假装随机行为能够完全确定。

本文围绕事实性、安全和拒答边界，说明如何把大模型测试结果接回证据和决策。

LLM 测试 Skill 用来做什么

LLM 测试适合需要同时守住事实准确性、指令遵循和安全边界的 AI 产品团队。它把答案质量、拒答行为和版本回归分开记录，便于设置有解释力的门禁。

先回到源 Skill

这个 Skill 的完整执行规则在 LLM 测试 提示词。源目录还包含 3 个评测用例，用于验证输出是否遵守契约。

它要求特别注意：

  • 避免只用精确字符串断言
  • 固定并记录模型参数
  • 对非确定性结果采用重复和分布判断

用一份项目材料开始

先把现有材料列出来。缺口可以保留，但状态要说清楚。

材料这次填什么缺失时的处理
目标与范围验证订单问答 LLM 在事实准确性、引用、拒答、时延和敏感信息处理上的表现标出不在本轮判断内的链路
版本与环境模型与系统 Prompt、检索索引、参数、区域和测试窗口版本未锁定时只给样本级观察
证据golden set、响应原文、事实来源、延迟、拒答和安全日志缺少来源链接时不判定事实准确
决策边界质量阈值、敏感信息处理、人工复核和发布 Owner把模型问题与数据问题分开升级

可以这样调用：

请使用 llm-testing Skill。

任务：验证订单问答 LLM 在事实准确性、引用、拒答、时延和敏感信息处理上的表现
输入材料：[版本、链接、日志或报告路径]
范围：[本次包含和排除的对象]
限制：[时间、数据、权限、合规要求]

先审计输入，再按风险和证据强度排序。材料没有证明的内容标为假设，并列出验证方法。

LLM 测试要分别记录答案和边界行为

产物要回答的问题最低证据
事实性回答是否符合事实源和引用要求参考材料、答案和核对结果
指令遵循模型是否按格式、角色和约束输出输入版本、输出和断言
拒答与安全危险请求是否拒绝，安全请求是否继续攻击样例、拒答文本和策略
版本回归模型或 Prompt 变化后哪里变了基线差异、分项分数和阈值

没有事实源、重复运行或安全样例时，结论只能停留在测试设计阶段。

在项目里跑一轮

先从一个边界清楚的小回合开始：验证订单问答 LLM 在事实准确性、引用、拒答、时延和敏感信息处理上的表现。别急着把结果写成报告。先把输入版本、时间窗口和负责人贴到同一处；然后把每个判断连回具体材料；最后只安排一项能改变结论的验证动作。

把正确性、稳定性和安全性拆开测，避免用一条好答案覆盖其他风险。这一轮至少要留下可复查的证据索引、仍然成立的假设，以及下一位同事可以直接执行的动作。

进阶使用：把一次分析变成持续机制

每次 LLM 测试都保存模型、Prompt、参数、输入集和安全类别。版本变化后同时比较事实、格式、拒答和安全结果，不用总分掩盖单类回归。

三段式 Skill 链

prompt-testing → llm-testing → llm-evaluation-design

交接传递内容接收方要检查什么
上游到 llm-testing来源版本、范围、风险、未决项输入是否过期，冲突是否标记
llm-testing 到下游判断、证据索引、残余风险、待办产物是否可执行，Owner 是否明确
下游回写 llm-testing执行结果、缺陷、事实变化是否更新基线与回归范围

交接时同时传摘要、证据索引和原始材料的位置。这样即使结论出了问题，也能回到来源。

团队门禁

门禁检查内容未满足时
llm-testing 输入门禁版本、环境、证据来源和 Owner停止生成，列出缺口
llm-testing 产物门禁关键结论带依据、状态和影响退回补证据
llm-testing 执行门禁命令、查询或验证路径可复现标记基础设施或测试问题
llm-testing 决策门禁残余风险有接受人与日期不进入下一阶段

容易踩的坑

  1. 只看答案是否流畅，没有核对事实来源。
  2. 把一次拒答当作安全边界稳定，忽略改写和多轮绕过。
  3. 用平均分覆盖关键业务类别的失败。
  4. 没有记录模型参数，无法解释同一输入为何得到不同结果。

相关 Skill

LLM 测试要把模型输出、评测标准和攻击路径放在同一条链上：

交付前复核：把判断落到证据

拿到 Skill 输出后，先核对四件事：输入版本是否明确、范围是否完整、每条结论能否回到证据、下一步由谁执行。缺一项，报告就容易变成漂亮的猜测。

项目需要留下缺失时
输入边界版本、环境、时间窗口和本次范围标记假设，不写成事实
证据索引日志、报告、Trace、截图或命令输出标记 evidence_pending
结论状态verified、assumption、blocked 或 pending停止扩大结论
后续动作最小验证命令、负责人和截止时间交付为待办，不进入门禁
source_version: [版本或提交]
scope: [本次包含和排除的对象]
evidence: [日志、报告、Trace 或命令输出]
status: pending
owner: [负责人]
next_action: [最小验证动作]

分析类 Skill 要保留查询条件和时间窗口；执行类 Skill 要保留命令、退出码和失败产物。人工修改也要记录，否则下一次复核时无法解释结论为何变化。

安装与调用

安装这个 Skill：

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/llm-testing -g

安装后，直接使用上面的 llm-testing 调用词，并附上本次的真实材料。

常见问题

输入还不完整，能开始吗？

能。先交付受限初版：列出已知事实、假设、缺口和最小验证动作。环境、数据或权限缺失时，不写执行结论。

什么时候需要人工确认？

范围取舍、风险接受、生产操作、数据权限和发布决定必须由对应负责人确认。Skill 负责整理证据与选项，不替团队做授权决定。

先用一份真实材料跑通 LLM 测试，并把输入、产物、人工修改和验证证据留在同一条工作链上。这样下一次发生变化时，才有东西可以复用。

参考

安全测试白盒测试背靠背测试本地化测试边界测试
分享