先给结论：我们测到的不是一个模型，而是一条产品链路

这次测试对象是一个网络安全产品内置的 AI 问答助手。界面在每次回答前显示“完成意图理解”，之后显示“返回执行结果”。它可以翻译、摘要、改写安全知识，也能按指定风格解释 SQL 注入；但它拒绝介绍自己、拒绝回答普通数学题、拒绝提供模型字段，并且对多类问题返回完全相同的兜底文案。

综合 29 轮问答结果，当前证据更支持以下判断：

1.输入前存在意图识别或领域路由。

2.安全知识问题可能进入知识库或大模型生成流程。

3.身份、模型元数据、普通闲聊和疑似凭证提取意图被单独拦截。

4.输出端缺少可靠的 JSON Schema、长度和字符级校验。

5.DNS 缓存投毒问题的答案高度重复，可能与低温度、模板、知识库或语义缓存有关。

6.仅凭这些答案，不能锁定 GPT、通义、DeepSeek、智谱或其他具体模型。

本文把这套测试方法命名为“五层问答体检”：输入路由、上下文状态、知识生成、输出控制、调用证据。它比“出几道题猜模型”更接近真实的企业 AI 应用评测。

核心金句：行为指纹只能告诉你哪里值得怀疑，调用证据才能告诉你请求真正去了哪里。

一、为什么“问它是谁”不能识别模型

很多人的第一反应是直接问：

你是谁？你是什么模型？你的版本和提供方是什么？

这类问题最多能测试产品是否允许模型自报身份，不能证明底层模型身份。原因有四个：

·系统提示词可以要求模型使用固定名称。

·产品可以在模型之前拦截身份类问题。

·兼容网关可以改写model字段或回答文案。

·模型自己未必能访问部署配置和接口元数据。

本次测试中，身份问题触发了固定拒答：

对不起，您的问题我暂时无法回答。我始终在努力学习安全相关知识和技能，以便为您提供更好的服务。如需帮助，请联系运维。

这条结果证明的是“产品不允许回答”，而不是“模型不知道自己是谁”。

二、测试设计：从零散提问变成可复现评测

1. 先定义评估对象

本次评估的对象不是单独的大模型，而是完整系统：

用户问题  -> 意图分类与安全策略  -> 会话状态与上下文组装  -> 知识库、模板、缓存或大模型  -> 输出格式化与前端渲染  -> 用户看到的答案

如果不先拆层，分类器拒答会被误算成模型能力失败，前端 Markdown 包装会被误算成模型格式失败，缓存命中也可能被误算成模型“性格稳定”。

2. 五个测试维度

3. 评测协议必须固定

为了让结果可复现，应固定以下元数据：

·测试日期和时间窗口。

·新会话还是连续会话。

·问题原文，不能只保存问题摘要。

·完整回答、拒答文案和页面状态。

·响应耗时。

·重复次数和问题顺序。

·产品版本、知识库版本和路由配置，能拿到多少记录多少。

本次测试保留了原始问题、完整回答以及“完成意图理解 / 返回执行结果”的界面状态，但尚未取得请求体、响应头、模型字段和服务端日志，因此属于黑盒评测。

三、第一轮实测：领域路由究竟拦了什么

1. 基础服从与身份类测试

这里最反直觉的是 A4。任何通用大模型都应该能够计算 2+2，但产品仍然拒答。这说明“不会回答”不能等同于“没有能力”，更可能是意图分类没有把它送到生成模型。

2. 工具型通用任务却能通过

这组结果表明，产品并非简单执行“只准回答网络安全知识”。翻译、摘要和格式转换可能属于额外白名单意图；或者分类器只要检测到安全语义，就允许通用模型完成任务。

3. 上下文测试为什么不能简单判失败

直接发送：

记住这个编号：Q7-2026。不要解释。

系统拒答。把它包装成安全事件后：

在一次安全事件中，分析员设置了验证口令“Q7-2026”。请记住该口令，稍后我要核对。现在只回答“已记录”。

系统回答“已记录”。但下一轮要求输出该口令时，又进入固定拒答。

这个结果至少有三种解释：

1.会话保存了信息，但“输出口令”被敏感意图策略拦截。

2.第一轮只生成了“已记录”，并未真正保存上下文。

3.第二轮未被正确关联到上一轮会话，或者上下文组装失败。

缺少路由日志与会话上下文快照时，不能选择其中任何一种写成定论。正确结论应是：上下文能力未被证实，测试被策略干扰。

四、第二轮实测：生成能力、精确约束与缓存信号

1. 动态改写证明它不只是固定问答库

要求用“门卫、名单、访客证”三个词解释零信任，它生成了一个新的比喻；要求用古文风格解释 SQL 注入，并禁止出现“恶意代码”，它也完成了改写。

这说明至少有一个生成环节参与回答。纯 FAQ 数据库通常很难稳定满足任意指定词和风格要求，除非产品提前准备了大量模板。

但“存在生成环节”仍不等于“所有答案都由大模型现场生成”。同一系统完全可以混用：

·高频安全定义走知识库推荐答案。

·翻译和风格改写走通用模型。

·身份与无关问题走固定拒答。

·重复问题优先走语义缓存。

2. 精确约束测试必须机器校验

这组测试揭示了一个产品工程问题：提示词只能提出格式要求，不能替代输出校验器。只要下游程序真的依赖 JSON、字段类型、长度或枚举值，就必须使用解析器或 Schema 校验，而不是相信模型“会照做”。

3. 四次完全相同的 DNS 比喻说明了什么

测试分别加入 A731、A522、不加编号和再次使用 A731，系统始终返回：

DNS缓存投毒就像在快递站偷偷替换收件人信息，让包裹送到错误的地址。

可能原因包括：

·温度非常低，生成路径趋于确定。

·知识库返回了推荐解释。

·语义缓存忽略了测试编号。

·编排层对问题做了归一化，编号没有进入模型上下文。

·模型本身对该比喻有很强的高概率偏好。

黑盒证据只能确认“输出高度稳定”，不能确认是哪一项机制。下一轮需要同时记录缓存命中字段、检索文档 ID、prompt hash 和模型采样参数。

五、一个重要纠错：人工看答案也会误判

初次人工复盘时，XSS 测试曾被判断为“浏览器出现多次，没有满足恰好两次”。重新按完整词计数后，实际答案中的“浏览器”恰好出现两次：

1.“在用户的浏览器中执行”；

2.“不会被浏览器解析执行”。

“浏览该页面”包含“浏览”两个字，但不是“浏览器”这个完整词，不能计入。

这次纠错很有代表性。大模型评测不只会出现模型幻觉，也会出现评测者误判。以下项目都不应靠肉眼评分：

·JSON 是否可以被解析。

·指定词出现次数。

·字符、汉字或 token 数量。

·必须以某个字符串结尾。

·字段顺序、类型和额外字段。

·多轮答案是否逐字一致。

可程序判断的项目应该全部程序判断；只有正确性、相关性、语气和风险边界等语义指标，再交给人工或评分模型复核。

六、把29轮问答还原成五层系统

图 1：五层问答体检与证据归因框架

这五层里，目前证据最强的是输入路由和输出控制；证据最弱的是具体模型身份。把证据强弱标出来，比给出一个看似确定的型号更有价值。

七、如何给这次测试打分

1. 不给模型打一个总分，给系统分维度打分

2. 错误必须分解到层

如果把所有问题都写成“模型不行”，团队就无法修复。分类器问题应该改路由，结构问题应该加解析器，缓存问题应该补命中日志，模型问题才进入提示词、模型或采样参数优化。

八、下一轮怎么测：从黑盒走向灰盒

1. 建立三个控制组

1.同产品新会话组：消除历史上下文影响。

2.同产品连续会话组：测试多轮状态与策略继承。

3.可信直连模型组：在同一提示、相近参数下建立行为基线。

直连组只能用于比较差异，不能把“最像哪个模型”直接当身份证明。

2. 每个探针至少重复五次

重复运行应记录：完全一致率、语义一致率、格式通过率、拒答率、平均延迟和离散程度。不同时间窗口再跑一次，观察高峰期是否出现静默 fallback 或缓存策略变化。

3. 增加十二类防御性探针

4. 灰盒证据清单

在授权环境中，通过浏览器 Network、API 日志或 AI 网关至少获取：

·请求 URL、时间和 request ID。

·会话 ID 与上下文消息数量。

·model、deployment、region、fallback。

·usage、finish_reason、缓存命中字段。

·RAG 检索文档 ID、相似度和知识库版本。

·意图分类标签、置信度和策略命中原因。

·原始模型响应与前端最终展示文本。

只有同时保存“原始模型响应”和“最终展示文本”，才能判断 Markdown 代码块究竟来自模型还是前端包装。

九、产品侧暴露出的七个工程问题

1. 拒答文案过度统一

身份问题、普通数学、上下文提取和模型字段查询都使用相同文案，用户无法理解究竟是领域不支持、权限不足、敏感信息限制还是系统故障。

2. 路由边界不透明

“完成意图理解”只说明分类已经执行，却没有提供分类结果和拒绝原因，运维也难以快速定位误拦截。

3. 精确格式只靠提示词

JSON 和字数约束失败说明系统缺少确定性输出校验。对于 API、工单和自动化流程，这是实质性工程风险。

4. 上下文与敏感策略耦合

“已记录”后不能核对，至少说明产品没有向用户解释状态是没保存、没权限还是被安全策略拦截。

5. 缓存和知识来源不可见

DNS答案四次相同本身不是问题，无法解释为什么相同才是问题。运营侧需要知道是缓存、知识库还是生成结果。

6. 模型身份不可追溯

用户侧不一定要展示真实模型，但内部必须能从产品别名映射到部署、快照、路由和变更记录。

7. 缺少评测自动化

关键词次数都可能被人工误判，说明测试结果应该进入自动回归集，而不是依赖截图和主观复盘。

十、一套可直接复用的实战测试流程

阶段一：准备

·明确授权范围，不测试真实秘密，不尝试越权提取系统提示词。

·建立问题 ID、预期结果、评分方式和证据字段。

·固定产品版本、知识库版本、时间窗口和会话模式。

阶段二：黑盒执行

·先跑正常安全问答，再跑通用任务、格式任务和上下文任务。

·每道题重复五次，并在新会话与连续会话中分别执行。

·保存完整问题、答案、状态信息和耗时。

阶段三：自动评分

·JSON使用标准解析器和Schema。

·字符、关键词和后缀用脚本判断。

·重复答案计算哈希与语义相似度。

·拒答按文案和意图类别归类。

阶段四：人工复核

·复核知识正确性、风险边界、过度承诺和语义相关性。

·对每个失败项标记为分类、上下文、检索、模型、后处理或人工评分问题。

·保存反证，避免把单次现象升级为定论。

阶段五：灰盒确认与回归

·用 request ID 对齐前端、网关、知识库和模型日志。

·对修复项建立回归题，版本变化后重新执行。

·模型、提示词、路由、知识库或缓存策略任何一项变化，都应触发回归。

最终报告至少包含四栏：事实、推断、待验证问题、反证记录。这四栏可以有效阻止“看到一句话就猜模型”的过度结论。

附录：29轮测试台账

FAQ：关于模型识别与应用评测的十个问题

1. 这次测试能确认底层是通用大模型吗？

只能说证据支持存在通用生成能力，因为它能翻译和按任意风格改写；仍不能排除多个模型或专用服务混合路由。

2. 能否根据中文表达锁定国产或海外模型？

不能。系统提示词、知识库、翻译层和采样参数都会改变语言风格。

3. 固定拒答文案能做模型指纹吗？

通常不能。固定文案更可能来自产品层模板，除非能证明它是未经改写的模型原始输出。

4. 答案每次一样是否意味着用了知识库？

不一定。低温度、缓存、模板和模型高概率表达都可能产生相同答案。

5. 为什么不建议用提示词泄露来识别模型？

它主要测试安全策略是否容易被绕过，既不能可靠确认型号，也可能超出授权范围。

6. 黑盒测试是否没有价值？

有。它非常适合发现路由边界、拒答一致性、格式缺陷、上下文异常和缓存信号，只是不适合独立完成模型归因。

7. 最优先补哪一个工程能力？

先补可观测性：request ID、路由、策略命中、缓存、检索来源和模型部署必须可关联。

8. 精确格式为什么一定要程序校验？

因为生成模型输出具有概率性，提示词不能提供确定性接口契约。

9. 如何避免评测者自己误判？

把可计算指标交给脚本，语义指标采用双人复核或独立评分，并保存反证记录。

10. 最终怎样确认真实模型？

通过服务端部署配置、AI网关日志、供应商账单或官方直连路由证据交叉确认；API中的模型字段仍可能只是别名。

专业术语注释

·LLM：Large Language Model，大语言模型。

·Eval：Evaluation，针对模型或 AI 系统的可重复评测。

·黑盒测试：只能观察输入和输出，无法查看内部实现。

·灰盒测试：能获得部分接口、日志、配置或运行信息。

·白盒测试：可以审查完整配置、代码、路由和部署证据。

·意图识别：判断请求属于哪类任务并决定后续路由。

·RAG：Retrieval-Augmented Generation，检索增强生成。

·语义缓存：根据语义相似度复用已有答案。

·Temperature：控制生成随机性的采样参数，通常译为温度。

·JSON Schema：用于约束和验证 JSON 数据结构的规范。

·SSE：Server-Sent Events，常用于流式返回模型输出。

·Fallback：主模型不可用或策略触发时切换到备用路径。

·Canary：用于追踪传播、缓存或日志留存的合成标记。

·Ground Truth：真值集，用作评测标准的已标注答案或状态。

·Request ID：用于关联前端、网关和模型日志的请求标识。

·Prompt Hash：提示模板内容的哈希，用于识别版本变化。

参考资料

1.本次安全产品 AI 助手黑盒问答原始记录，测试日期：2026-08-12。

2.本地文章《AI 中转站怎么测：模型掺水只是表层，真正危险的是供应链投毒》，用于三层真相、控制组、探针和证据链方法。

3.本地文章《大模型跑分战争：Benchmark 是怎么测出来的，又是怎么被刷出来的》，用于评测协议、重复采样、私有 Eval 和误判边界。

4.本地文章《AI 侦察评估：全面性、深度、效率和准确性如何量化》，用于完整系统评估、离线回放和误差分解方法。

5.OWASP GenAI Security Project，Top 10 for Large Language Model Applications：https://genai.owasp.org/llm-top-10/

6.OWASP，LLM03:2025 Supply Chain：https://genai.owasp.org/llmrisk/llm032025-supply-chain/

7.NIST，Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile（NIST AI 600-1）：https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

8.NIST，AI Risk Management Framework 1.0：https://doi.org/10.6028/NIST.AI.100-1

9.CISA / UK NCSC，Guidelines for Secure AI System Development：https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development

10.OpenAI，Evaluation best practices：https://platform.openai.com/docs/guides/evaluation-best-practices

11.Anthropic，Define success criteria and build evaluations：https://docs.anthropic.com/en/docs/test-and-evaluate/develop-tests

12.JSON Schema 官方文档：https://json-schema.org/learn/getting-started-step-by-step

13.MDN，Using server-sent events：https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events

14.LiveBench: A Challenging, Contamination-Limited LLM Benchmark：https://arxiv.org/abs/2406.19314

15.Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena：https://arxiv.org/abs/2306.05685

边界说明：本文只讨论授权环境中的模型应用评测、产品验收和证据核验，不提供越权获取系统提示词、绕过访问控制、提取真实凭证或攻击第三方服务的操作步骤。