[原创]单次提问，鉴别中转站模型掺假-AI 自身安全-看雪安全社区

# 零 为什么要做这个
你也不想在中转站画了GPT-5.5的钱，买到的模型却是写着GPT-5.5的deepseek-v4-pro，对吧？

早在2024年，便有<a href="elink@ff1K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6S2M7Y4S2A6N6W2)9J5k6h3!0J5k6#2)9J5c8X3q4T1M7#2)9J5c8U0t1@1x3o6N6Q4x3X3f1I4y4e0R3@1y4H3`.`.">学者</a>发现可以通过数次提问来鉴别LLM的身份。

作为一篇社区博客，本文将谈论如何构造一个提问，使得这个提问能最大化不同的模型的响应的区别；然后，本文将探讨如何基于不同的模型对此提问的响应构造一个文本分类模型。最后，本文还将在文末开源一个简化版的LLM身份分类器（为了方便没有GPU的坛友运行，是10分类的）。

那么，闲话休提，让我们开始吧。

# 壹 提问的构建

## 0x00 Backgrounds

早在[上一篇博客](https://bbs.kanxue.com/thread-290943.htm)中，我们提到了GCG等基于优化的可解释性方法。那么，为什么我们不能对商业模型使用基于优化的可解释性方法呢？

对于 GPT-5.5、Gemini 这类部署在云端、通过 API 访问的商业模型，我们无法像对开源模型那样直接进行基于梯度或连续优化的可解释性探测。原因有而。首先，我们无法获取梯度信息。商业模型的权重、结构都是黑盒，用户仅能拿到文本输出，无法对输入进行反向传播。这使得 GCG这类需要计算损失对输入 token 梯度的方法完全不可用。此外，就是因为采样与随机性不可控。商业模型往往强制开启一定程度的随机采样（temperature、top-p 等），即使输入完全相同，输出也可能浮动，这让精确的梯度估计或基于损失的优化变得极不稳定。

因此，要在这种受限环境下最大化不同模型输出的差异，我们必须放弃任何依赖模型内部信息的白盒方法，转而使用纯粹的黑盒搜索策略——遗传算法正是一个合适的选择。

遗传算法（Genetic Algorithm, GA）是一种模拟自然界优胜劣汰过程的启发式搜索算法。它维护一个由若干候选解组成的“种群”，每一代通过**选择、交叉、变异**三类操作推动种群向更优的方向演化。在我们的场景中，每个候选解是一条提示文本（由一系列单词拼接而成），适应度则由“不同模型对该提示的响应之间的嵌入距离”来定义。算法迭代地让距离更大的个体存活、重组、变异，最终找到一条能最大限度拉开模型响应的提示。

选择操作是遗传算法中筛选亲本的关键步骤。锦标赛选择（Tournament Selection）因其简单且不易过早收敛而被广泛使用。下图展示了一次典型的三元锦标赛选择流程：

![GA](upload/attach/202606/994475_EUDKR76NES6EMQQ.webp)

在我们的代码中，k 取 3，即每次随机抽取 3 条候选提示，保留其中使模型响应距离最大的那条作为父代，重复多次填满交配池。这种方式平衡了选择压力与种群多样性，即使适应度较差的个体也有极小概率参与繁殖，避免搜索陷入局部最优。

字节对编码（BPE）是现代大语言模型中最主流的子词分词算法。它的核心思想很朴素：从最细粒度的字符开始，反复将文本中出现频率最高的一对相邻符号合并成一个新符号，从而逐步构建出包含常见字符组合、词根、乃至完整单词的词表。训练完成后的分词器在面对新文本时，就按照当初合并的顺序，贪心地把输入切分成词表中存在的、尽可能长的子词单元。这样一来，无论遇到多罕见甚至从未见过的词汇，模型总能用一连串更小的、已知的子词“拼”出它的表示，避免了传统词级别分词中大量未登录词直接变成<unk>的窘境。

下面这张图用一个简单例子演示了 BPE 的迭代合并过程：假设初始词汇表就是字符 {a, b, c, d}，训练语料中反复出现字符串 "aaabdaaabac"。算法首先统计相邻符号对的频率，发现 "aa" 出现次数最多，于是将其合并为一个新符号 "aa"；接着在更新后的序列里 "aa" 与 "a" 组成的 "aaa" 又成为最高频对，再次合并……如此循环，直到达到预设的合并次数或词表大小。最终，原始字符序列会被切分成一组子词单元，每个单元都对应词表里的一个独立 token。

![BPE](upload/attach/202606/994475_NHB8RR6HYPB4SJZ.webp)

从上面的流程可以看出来，BPE 词表的内容和大小完全取决于训练它所用的语料以及预设的超参数（如词表容量、允许的最大合并步数）。不同的模型，哪怕都用 BPE 分词器，只要它们训练的语料不同、词表尺寸不同、或者在实现细节上对 Unicode 规范、标点处理、空白保留等规则有差异，最终得到的合并优先级列表就会不一样。同一段文字，在 GPT-4 的 tokenizer 下可能被切成 10 个 token，到了 Gemini 的 tokenizer 里就可能变成 12 个——因为某个常见词在一个词表里是独立 token，在另一个词表里却被拆成了两个更小的子词。这种分歧正是我们稍后利用嵌入距离来“指纹识别”模型身份的基础：相同的文本在不同模型内部经历的分词路径不同，导致其上下文化的语义表征也自然地产生了系统性的偏移。

## 0x01 How

既然商业模型是黑盒，我们唯一能做的就是不断尝试不同的输入，观察输出，再调整输入方向。遗传算法恰好匹配这种“试错—评估—择优—变异”的范式。每条候选提示就是一个个体，它的适应度由“将该提示分别喂给不同模型后，各模型响应之间的嵌入距离”来定义——距离越大，说明这几个模型对同一个问题的理解越不一致，这条提示就越有区分力。遗传算法的选择、交叉、变异三个操作则负责在由词汇组合构成的巨大离散搜索空间里，沿着适应度升高的方向迭代前进：选择让高分提示更大概率存活并繁殖；交叉把两条已经表现不错的提示的片段拼接，可能产生更优的组合；变异则以小概率随机替换、插入或删除提示中的词汇，防止搜索卡在局部最优。这个框架早在对抗样本生成领域就有成功案例，比如在 NLP 中搜索能绕过内容审核的对抗性短语，本质思想一致——只不过我们不是在找“能骗过模型”的输入，而是在找“能让多个模型表现得迥然不同”的输入。

当我们只区分两个模型时，最大化它们响应之间的余弦距离是直接的。但假如要同时区分三个甚至更多模型，适应度函数的设计就需要更谨慎。一个直觉的方案是把所有两两模型对之间的距离加起来，然而这个“距离之和”会导致严重的盲区：假设我们正在区分模型 A、B、C，某条提示使 A 与 B 的距离极高、A 与 C 的距离也极高，但 B 与 C 的距离几乎为零。这条提示的“距离之和”仍然可以很大，因为两项高值把总分拉上去了；但在实际分类场景中，B 和 C 几乎无法被区分，这条提示的鉴别价值就大打折扣。

将优化目标改为所有两两距离的乘积（或等价的几何平均）则可以强制避免这种“偏科”。乘积对任何一个极小值极度敏感——只要有一对模型的距离趋于零，整个适应度就会崩掉。这迫使搜索算法必须找到一条能让每一对模型的输出都均匀拉开的提示，不存在被“放水”的模型对。换句话说，距离乘积最大化等价于在保证没有一个维度薄弱的前提下，整体拉开所有模型的嵌入分布，这正是构建可靠多分类判别器所需要的数据特征。

## 0x02 Code

遗传算法的核心逻辑在上文已经解释清楚，这里直接给出最关键的适应度计算与主循环代码片段，帮助读者对整体流程有一个具体的感知。

```python
def calculate_fitness(prompt_words: list) -> float:
    """适应度函数：计算两个 LLM 响应的 Embedding 余弦距离"""
    prompt = " ".join(prompt_words)
    if not prompt.strip():
        return 0.0
    
    response_a = call_llm_a(prompt)
    response_b = call_llm_b(prompt)
    
    emb_a = get_embedding(response_a)
    emb_b = get_embedding(response_b)
    
    distance = cosine(emb_a, emb_b)
    return float(distance)
```

上面是针对两个模型的简化版。当需要同时区分多个模型时，只需将适应度改为所有两两配对的嵌入距离之乘积。锦标赛选择、单点交叉和随机变异的实现沿用了经典遗传算法的范式，读者可根据上文给出的参数（种群大小、变异率、锦标赛规模 k=3 等）自行组装，此处不再逐行罗列。

```python
for gen in range(GENERATIONS):
    fitness_scores = [calculate_fitness(ind) for ind in population]
    
    best_idx = np.argmax(fitness_scores)
    print(f"第 {gen+1} 代 -> 最大距离: {fitness_scores[best_idx]:.4f}")

next_population = []
    for _ in range(POP_SIZE // 2):
        p1 = max(random.choices(list(zip(population, fitness_scores)), k=3), key=lambda x: x[1])[0]
        p2 = max(random.choices(list(zip(population, fitness_scores)), k=3), key=lambda x: x[1])[0]
        c1, c2 = crossover(p1, p2)
        c1 = mutate(c1, VOCABULARY, MUTATION_RATE)
        c2 = mutate(c2, VOCABULARY, MUTATION_RATE)
        next_population.extend([c1, c2])
    population = next_population
```

需要特别说明的是，代码产出的原始提示词虽然在数学意义上最大化了一组模型间的响应距离，但从人类的视角看往往是一堆词汇的机械堆砌，缺乏连贯的句法和可读性。本文最终使用的那条提示并非代码的直接输出，而是在多次遗传算法迭代中筛选出距离表现优秀的候选后，由笔者手工调整语序、修补语法、使其读起来像一句正常人会说出的话。这种“人机协同”的打磨过程牺牲了一小部分区分度，换来了在实际使用中更不易引起模型警觉的自然文本——毕竟如果一条提示看起来明显是机器生成的对抗样本，某些商业模型可能会触发安全拒绝机制，反而拿不到响应。

## 0x03 Result

出于简略考量，最终获得的完整提示词不在此处给出。感兴趣的读者可在本文附件中获取，其中还包含了针对该提示在不同模型上的响应样本以及对应的嵌入距离矩阵。这里仅做一个概括性说明：经过遗传算法搜索和人工润色后，这条提示在参与测试的 10 个主流商业及开源模型上，使任意两个模型响应嵌入之间的最小余弦距离达到了 0.4 以上——对于经过对齐训练的现代大模型而言，这意味着它们在面对完全相同的输入时，输出产生了足够显著且稳定的分化，为下一步训练判别器提供了干净的数据基础。

# 贰 判别器的构建

## 0x00 Backgrounds

BERT、GPT 等基于 Transformer 的模型之所以展现出强大的语言能力，根本前提在于它们在海量语料上经历了漫长的预训练，通过数亿甚至数十亿的参数吸收了语言中的结构、常识与推理模式。当我们只有几百条样本——比如几十个模型对同一提示的响应——时，这种数据规模连让大型 Transformer 模型学会最基本的文本表征都不够。参数量过大而样本极少，模型会在训练的前几个 epoch 就把训练集背得滚瓜烂熟，随即在未见过的响应上完全失去泛化能力，这是典型的严重过拟合。此外，从零开始训练一个大 Transformer 所需要的计算资源和时间与我们的任务目标（快速、轻量地判别模型身份）背道而驰。即便是微调预训练权重，也要求下游任务有成千上万的标注样本才能稳定迁移，而我们手头每个模型的响应数量可能只有两位数。因此，必须选择一种样本效率更高、参数规模可控的分类器架构。

Inception v1（GoogLeNet）是图像分类领域的一个里程碑式工作，它解决的核心问题是：在同一层中，我们不知道该用多大的卷积核才能最有效地捕捉信息——3×3 适合局部细节，5×5 视野更大，1×1 则能进行通道间的信息融合与降维。Inception 模块的做法是将这些不同感受野的卷积分支并行放置，把它们的输出在通道维度上拼接起来，交给后续网络自己去决定哪些尺度的特征更重要。同时，1×1 卷积在所有分支中被大量使用，用于先压缩通道数、降低计算量，再扩展到目标维度。这种设计带来的好处是：参数效率极高，一个模块内就集成了多尺度特征提取能力，且天然适合作为分类器的前端骨干。

下面这张图展示了一个完整的 Inception 模块结构，也是本文代码中实际采用的 Inception-1D 块。它针对一维文本序列做了适配，将二维卷积替换为一维深度卷积，但保留了多分支并行、逐点融合的核心思想。

![HsCNN](upload/attach/202606/994475_KF6QWTY6DXGF25G.webp)

代码中连续堆叠了两个这样的 Inception-1D 块（features.0 和 features.1），再跟一层普通卷积（kernel=3）和全局平均池化、全连接层完成分类。四个分支的卷积核大小从 3 跨越到 81，覆盖了从一个短语到接近一整段话的感受野；深度可分离卷积配合 1×1 逐点卷积让参数量始终保持在极低水平，即使只有数百条样本也足以训练出一个稳健的分类器。

在嵌入之后，文本就不再是零散的符号序列，而是一个规整的实数矩阵：每一列对应一个 token 的嵌入向量，每一行则对应所有 token 在某一特征维度上的值。这个矩阵的形状是 (嵌入维度, 序列长度)，恰好可以看作一个“高度为嵌入维度、宽度为序列长度”的单帧信号，或者说是一个具有 嵌入维度 个通道、每个通道长度为 序列长度 的一维多通道数据。图像是二维空间上的多通道像素网格，而嵌入后的文本序列则是时间方向上的多通道采样点——两者在张量形式上是完全对等的，唯一的区别仅在于一个在空间维度上做卷积，另一个在时间维度上做卷积。正因如此，原本为图像设计的 Inception 架构可以毫无障碍地“降维”为一维卷积版本，将感受野从像素块替换为连续的 token 跨度，从而在文本序列上同样享受多尺度特征提取与高效参数复用的好处。

## 0x01 How

有了前面的铺垫，选择 Embedding + Inception-1D 这个组合来做文本分类就变得顺理成章了。

我们的任务本质上是一个小样本、短文本、多类别的分类问题：输入是一条模型对特定提示的响应，输出是这条响应来自哪个模型。直接训练一个 Transformer 会因为数据量不足而过拟合，但我们仍然需要某种方式将文本转化为机器学习模型能处理的数值特征。这里就有一个天然的捷径——使用一个现成的、在大规模语料上预训练好的**通用嵌入模型**（如 all-MiniLM-L6-v2）来冻结提取每条响应的嵌入向量。这些嵌入模型已经学会了将语义相似的句子映射到相近的向量空间位置，我们不需要再训练它，只需要“借用”它的输出作为下游分类器的输入特征即可。

嵌入向量堆叠成一个矩阵后，文本就从离散符号变成了上一节所说的 1D 多通道信号。接下来要解决的就是用什么分类器来处理这个信号。全连接网络无法利用序列中的局部模式；循环神经网络虽然可以，但训练慢、样本效率一般。CNN-1D 则恰好踩中甜点：卷积核在序列方向上滑动，天然捕捉局部的 n-gram 模式，且参数量远小于 Transformer，在小数据集上不易过拟合。

而选择 Inception-1D 而非朴素 CNN，原因在于我们的分类线索分布在多个尺度上。某些模型可能在用词上有明显偏好（局部 2-3 个 token 就能看出来），另一些模型则可能在句式结构、回答长度、乃至段落组织方式上才暴露出差异（需要几十甚至上百个 token 的感受野）。Inception 模块并行放置了 kernel size 从 3 到 81 的四条分支，小的捕捉措辞习惯，大的覆盖句式风格，最后通过 1×1 逐点卷积将这些不同粒度的线索融合在一起。这种设计让分类器不需要事先猜测“区分模型的信号到底在哪个尺度”，而是把多个尺度都扫一遍，让训练过程自己决定哪个尺度更重要。

总结一下这条数据流：冻结的嵌入模型负责将原始文本无损地翻译为一个富含语义的实数矩阵；堆叠的两个 Inception-1D 块负责在这个矩阵上提取多尺度的局部特征；全局平均池化将变长的序列压缩为固定长度的向量；最后两层全连接网络将这个向量映射到具体的模型类别上。整个流程参数量极低，收敛速度快，对数百条样本就能稳定训练，且推理时只需要做矩阵乘法和卷积，在 CPU 上也能毫秒级完成。

## 0x02 Code

下面是 Go 语言实现的推理侧核心结构，完整对应了上文描述的 Embedding + Inception-1D + 全局池化 + 分类头流程。

```go
// conv1d 实现分组一维卷积，支持深度可分离卷积
func conv1d(input [][]float32, weight []float32, bias []float32,
    out [][]float32, outC, inC, seqLen, kernelSize, pad, groups int) {
    outPerGroup := outC / groups
    inPerGroup := inC / groups
    for oc := 0; oc < outC; oc++ {
        inStart := (oc / outPerGroup) * inPerGroup
        wOffset := oc * inPerGroup * kernelSize
        for t := 0; t < seqLen; t++ {
            var sum float32
            for k := 0; k < kernelSize; k++ {
                inT := t - pad + k
                if inT >= 0 && inT < seqLen {
                    for icG := 0; icG < inPerGroup; icG++ {
                        ic := inStart + icG
                        w := weight[wOffset+icG*kernelSize+k]
                        sum += input[ic][inT] * w
                    }
                }
            }
            out[oc][t] = sum + bias[oc]
        }
    }
}

// runTextCNN 执行一个 Inception-1D 块
func runTextCNN(x [][]float32, prefix string, seqLen, base int,
    step1, step2, finalOut [][]float32) {
    w := globalData.Weights

// 四个并行深度卷积分支，kernel 分别为 3, 9, 27, 81
    conv1d(x[0:base*4], w[prefix+"dw_conv1.weight"], w[prefix+"dw_conv1.bias"],
        step1[0:base*4], base*4, base*4, seqLen, 3, 1, base*4)
    conv1d(x[base*4:base*6], w[prefix+"dw_conv2.weight"], w[prefix+"dw_conv2.bias"],
        step1[base*4:base*6], base*2, base*2, seqLen, 9, 4, base*2)
    conv1d(x[base*6:base*7], w[prefix+"dw_conv3.weight"], w[prefix+"dw_conv3.bias"],
        step1[base*6:base*7], base, base, seqLen, 27, 13, base)
    conv1d(x[base*7:base*8], w[prefix+"dw_conv4.weight"], w[prefix+"dw_conv4.bias"],
        step1[base*7:base*8], base, base, seqLen, 81, 40, base)

// 1×1 逐点融合
    conv1d(x, w[prefix+"pw1_part1.weight"], w[prefix+"pw1_part1.bias"],
        step2[0:base*2], base*2, base*8, seqLen, 1, 0, 1)
    conv1d(step1, w[prefix+"pw1_part2.weight"], w[prefix+"pw1_part2.bias"],
        step2[base*2:base*4], base*2, base*8, seqLen, 1, 0, 1)

catInStep1 := make([][]float32, base*16)
    copy(catInStep1[:base*8], x)
    copy(catInStep1[base*8:], step1)
    conv1d(catInStep1, w[prefix+"pw1_part3.weight"], w[prefix+"pw1_part3.bias"],
        step2[base*4:base*8], base*4, base*16, seqLen, 1, 0, 1)

// 最终投影 + 激活
    conv1d(step2, w[prefix+"pw2.weight"], w[prefix+"pw2.bias"],
        finalOut, base*8, base*8, seqLen, 1, 0, 1)
    leakyReluInplace(finalOut)
}

// Predict 完整推理：嵌入 -> 两个 Inception 块 -> 尾部卷积 -> 池化 -> 分类
func Predict(text string) []float32 {
    tokens := tokenize(text)
    seqLen := len(tokens)
    embDim := base * 8

// 查嵌入表构造输入矩阵
    input := alloc2D(embDim, seqLen)
    for c := 0; c < embDim; c++ {
        for t := 0; t < seqLen; t++ {
            input[c][t] = embW[tokens[t]*embDim+c]
        }
    }

// 两个 Inception-1D 块 + 尾部卷积
    runTextCNN(input, "features.0.", seqLen, base, buf1, buf2, buf3)
    runTextCNN(buf3,  "features.1.", seqLen, base, buf1, buf2, input)
    conv1d(input, w["features.2.weight"], w["features.2.bias"],
        buf3, embDim, embDim, seqLen, 3, 1, 1)
    leakyReluInplace(buf3)

// 全局平均池化 + 两层全连接 + Softmax
    pooled := globalAvgPool(buf3)
    h := linear(pooled, w["regressor.0.weight"], w["regressor.0.bias"], base*4, embDim)
    leakyReluInplace1D(h)
    logits := linear(h, w["regressor.2.weight"], w["regressor.2.bias"], numClasses, base*4)
    return softmax(logits)
}
```

为了聚焦于模型架构本身，上面省略了训练流程中的诸多工程细节，包括 Dropout 层的位置与比例、学习率预热与衰减策略、优化器（如 AdamW）的具体超参数、梯度裁剪、批归一化与层归一化的放置等。这些技巧对最终模型的收敛和泛化至关重要，但已超出本文的结构性介绍范畴。想要系统掌握这些实践知识的读者，强烈推荐动手完成 <a href="elink@7c4K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6V1x3X3I4Q4x3X3g2S2K9b7`.`.">d2l.ai</a> 中的配套代码练习，那会是比任何博客都更扎实的学习路径。

## 0x03 Result

较小尺寸（截图时还没有用Go重写）的模型就能较好地鉴定输出的模型。

![Test](upload/attach/202606/994475_D762VS8AK5TQW3F.webp)

# 叁 系统的测试
不难写一个好看的前端，之类的；这里按下不表，希望在线体验的可以来 <a href="elink@2c8K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6S2K9g2)9J5k6e0R3$3z5o6x3J5x3W2)9J5k6i4S2&6P5W2)9J5c8R3`.`."><mark class="encrypted">dc2K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6S2K9g2)9J5k6e0R3$3z5o6x3J5x3W2)9J5k6i4S2&6P5W2)9J5c8R3`.`.</mark></a> 玩；希望本地部署的可以自己下载附件编译部署。

![UIUX](upload/attach/202606/994475_2GJX785ZARVBZ7Y.webp)

# 肆 后记

## 碎碎念

很多朋友一听到“模型”、“推理”，脑子里蹦出来的就是 PyTorch、CUDA、大显存、docker 拉个镜像动辄十几个 G，好像机器学习天然就绑定着 Python 和 GPU，离轻量部署十万八千里。这也是为什么我这次特意选了 Go 来写整个分类器的推理服务：没有 FFI、没有 libtorch、不需要 ONNX Runtime，一个不到 15MB 的二进制文件嵌入了所有权重，甩到任意一台云服务器甚至树莓派上就能直接跑。CPU 推理一个请求的延迟稳定在个位数毫秒，内存占用几十 MB，配合 Go 原生的 HTTP 库，一个能扛并发请求的 WebUI 不过 200 行代码。这其实想说一件事：当模型架构被精心控制在足够小的量级时，部署本身不该是门槛。你完全可以用你熟悉的任何语言、在任何能执行加减乘除的设备上，把机器学习模型跑起来。

## 免责声明

本文所呈现的方法本质上是对模型身份的一种统计推测，而非精确的数学证明。大语言模型的输出受采样策略、温度、top-p、系统提示、版本热更新等大量因素影响，同一条提示在不同时刻、不同会话中可能得到不同的响应，进而导致分类器给出不同的判断。因此，本文提供的提示词与分类器仅供学术交流和技术验证使用，不应被当作商业真伪鉴定的唯一依据。对于因使用本文方法产生的任何误判或损失，笔者概不负责。如果您真的在意自己调用的模型是否“货真价实”，最可靠的方式仍然是向服务提供商索取明确的模型卡与版本承诺。

回复或点赞可查看完整内容

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

最后于 2026-6-16 01:54 被the_hs编辑，原因： title

上传的附件：

catchGPT.zip （1.23MB，46次下载）

最新回复 (38) 1 2 ▶
Saileaxh 雪币： 3110 活跃值： (2919) 能力值： ( LV6，RANK：80 ) 在线值：发帖 18 回帖 49 粉丝 108 关注私信	Saileaxh 1 2 楼强烈支持 2026-6-16 10:10 0
hambaga 雪币： 187 活跃值： (3931) 能力值： ( LV3，RANK：20 ) 在线值：发帖 6 回帖 94 粉丝 61 关注私信	hambaga 3 楼 ohhh 2026-6-16 14:11 0
mb_oowiiidy 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 3 粉丝 0 关注私信	mb_oowiiidy 4 楼 let me see see 2026-6-17 09:47 1
淡然他徒弟雪币： 5589 活跃值： (7263) 能力值： ( LV10，RANK：160 ) 在线值：发帖 23 回帖 296 粉丝 124 关注私信	淡然他徒弟 1 5 楼 mark 2026-6-18 11:40 0
wx_Fengx 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 1 粉丝 0 关注私信	wx_Fengx 6 楼我测试一下中转是否参水 2026-6-25 15:45 0
王嘟嘟雪币： 1349 活跃值： (754) 能力值： ( LV4，RANK：45 ) 在线值：发帖 5 回帖 37 粉丝 3 关注私信	王嘟嘟 7 楼 mark 2026-6-25 15:52 0
stay0D 雪币： 20 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 2 粉丝 0 关注私信	stay0D 8 楼 mark 2026-6-25 16:11 0
38.5 雪币： 211 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 5 粉丝 0 关注私信	38.5 9 楼 mark 2026-6-26 11:26 0
koflfy 雪币： 102 活跃值： (4101) 能力值： ( LV4，RANK：50 ) 在线值：发帖 8 回帖 482 粉丝 5 关注私信	koflfy 1 10 楼 mark 2026-6-26 16:30 0
IsBerry 雪币： 23 活跃值： (2522) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 18 粉丝 0 关注私信	IsBerry 11 楼 mmmark 2026-6-26 16:38 0
mb_qkpnryky 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 4 粉丝 0 关注私信	mb_qkpnryky 12 楼 mmmark 2026-6-28 00:51 0
王多余雪币： 13 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 6 粉丝 0 关注私信	王多余 13 楼 gpt 5.5 掺5.3 speak gpt 5.4 掺5.4mini 2026-6-28 11:48 0
38.5 雪币： 211 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 5 粉丝 0 关注私信	38.5 14 楼这类检测方案放到主动探测中转站模型时，会不会因为中转站侧的额外提示词注入导致检测结果不稳定？ 2026-6-28 22:11 0
windzmf 雪币： 0 活跃值： (20) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 1 粉丝 0 关注私信	windzmf 15 楼看起来方案很可行 2026-6-28 22:28 0
zzw_xjx 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 44 粉丝 0 关注私信	zzw_xjx 16 楼这类检测方案放到主动探测中转站模型时，会不会因为中转站侧的额外提示词注入导致检测结果不稳定？ 2026-6-29 19:04 0
the_hs 雪币： 2906 活跃值： (2128) 能力值： ( LV6，RANK：90 ) 在线值：发帖 18 回帖 22 粉丝 52 关注私信	the_hs 1 17 楼 38.5 这类检测方案放到主动探测中转站模型时，会不会因为中转站侧的额外提示词注入导致检测结果不稳定？建议手动问一下类似于“你有没有收到很长的系统提示词”之类的问题，一般来说提示词虽然可以要求ai不泄露提示词是什么，但是想要隐藏自身的存在还是很困难的如果提示词很短，那一般来说不影响；如果很长，直接问就行了 2026-6-29 20:03 0
IndexGuc 雪币： 232 活跃值： (90) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 29 粉丝 4 关注私信	IndexGuc 18 楼起来方案很可行 2026-6-30 11:57 0
mb_sldlxhzw 雪币： 9 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 9 粉丝 0 关注私信	mb_sldlxhzw 19 楼 tql 2026-7-1 10:48 0
@mh 雪币： 204 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 3 粉丝 0 关注私信	@mh 20 楼 2026-7-1 11:20 0
yyyhushqqq 雪币： 195 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 6 粉丝 0 关注私信	yyyhushqqq 21 楼 tql 2026-7-1 15:02 0
学计算机睡觉雪币： 779 活跃值： (1237) 能力值： ( LV3，RANK：30 ) 在线值：发帖 3 回帖 94 粉丝 4 关注私信	学计算机睡觉 22 楼 tql 2026-7-3 10:35 0
mydvdf 雪币： 711 活跃值： (293) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 56 粉丝 2 关注私信	mydvdf 23 楼 tql 2026-7-3 11:17 0
mb_mebydiyd 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 1 粉丝 0 关注私信	mb_mebydiyd 24 楼 tql 2026-7-6 18:25 0
茅山小僧雪币： 1631 活跃值： (2830) 能力值： ( LV5，RANK：75 ) 在线值：发帖 12 回帖 242 粉丝 7 关注私信	茅山小僧 25 楼学习一下 2026-7-8 11:13 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复