风险不一定发生在模型回答的那一刻，也可能发生在数据被读取、解释、执行和写回的整条链路里。

一个远程输入拿不到 shell，却能让审核系统放行内容、让 SOC 关闭告警、让 coding agent 安装依赖、让工具路由从只读变成写入。它不是传统意义上的 RCE，但风险直觉很接近：外部输入影响了系统将要执行的动作。

模型身份不只写在 model card 里，也会写在 tokenizer 的边界、chat template 的入口、logits 的局部偏好，以及那些稳定复现的错误里。

一个模型可能不会告诉你它是谁，但它会用错误暴露自己。

从 Sure, here's 开始，GCG 越狱首先攻击的不是完整回答，而是 assistant 起手阶段的拒绝边界。

GCG 越狱最容易被误读成一个结果：模型有没有输出完整有害内容。这个口径太粗。GCG 原论文里常见的 Sure, here is ...，本质上先攻击的是更靠前的一道边界：模型能不能离开拒绝模板，进入 affirmative response 前缀。

这个判断不是凭空来的。GCG 原论文把 suffix 的优化目标写得很明确：提高模型生成 affirmative response 的概率，而不是 refusal。后来 continuation-triggered jailbreak 的机制分析也把这类现象解释成 continuation drive 和 safety refusal 之间的竞争。换句话说，越狱最先发生变化的位置，往往不是完整内容，而是 assistant 起手阶段的条件竞争。

所以本文关心三件事：英文经典 case 里拒绝轨迹如何被推开；中文 target prefix 下 loss 和 generate 为什么会错位；同一批中文 suffix 换模型后，前缀控制是否还能保留。

这也是本文最重要的评估口径：loss 只能说明目标前缀概率被推近，generate 才说明模型真的跨过了输出门槛。 如果换模型后只看到 loss 变化或相邻服从模板，那只能算弱迁移信号，不能直接写成稳定越狱迁移。

将GCG概念从模型后缀搜索转移到离散空间优化

第一篇已经把 GCG 的最小主干拆开了：candidate proposal、target loss evaluation、greedy update。这里继续往前走一步，把 2024–2026 年围绕 GCG 展开的几条工作线放到同一个实验框架里。

这篇文章要回答的是：这些 GCG 变体到底改了哪一环？改完以后，是降低了计算成本，还是改变了优化目标，或者只是换了一套评估方式？