AI 生成文字是一个字一个字往后接的，它自己并不天然知道什么时候收笔，停止序列就是给大模型装的一只刹车：你预先指定一串字符，输出里一旦出现它，系统立刻掐断生成，后面的内容一个字也不吐。对经常调用模型接口的人来说，这个小参数解决的是"回答拖泥带水"的老毛病。
最贴近的类比是电梯。电梯从一楼往上走，到了你按下的那层楼就自动开门停住，不会一路冲到天台。停止序列就是你提前按下的那个目标楼层，模型写到这儿就停，干净利落。顺带一个能带走的判断：凡是想从回答里剥掉固定后缀的任务，先想刹车，再想别的办法。
它在生成流程里卡在哪一步
模型每生成一小段文字，接口都会比对一次：新吐出的内容里有没有你设定的那串字符。有，就当场截断，并且这次命中本身不会被写进最终答案。这和输出上限是两种不同的停下方式——后者像油箱烧干被迫熄火，前者是主动踩刹车，两者的分工可以在输出上限一篇里看得更细。截断是逐段进行的，所以停止序列哪怕恰好横跨两次比对，也照停不误，但它不会追溯已经输出的内容。
一个具体例子：只让 AI 答一句话
假设你想让模型做翻译，只想要译文、不要解释。把换行符设成停止序列：模型翻完第一行，一换行就被截住，多余的客套话根本没有出场机会。在 DeepSeek 这类开放接口里，对应参数通常叫 stop，允许一次填多个候选，命中任意一个就停。Kimi 的网页版没把这个旋钮露出来，但背后走的是同一套逻辑，区别只在有没有把开关交到你手里。反过来讲，如果你想让模型先给答案、再补一段解释，就别把换行设成刹车，否则解释刚起头就被掐了。
电梯类比在哪里失效
电梯停住是因为真到了那个物理位置，而模型对"到达"毫无感觉：它只是被逐段做字符串匹配，命中即断。这带来两个后果。其一，停止序列必须是能精确预期的字符串，比如换行符、固定的标记词，随手挑一个常见短词，正常回答也会被拦腰斩断；其二，它只负责"看见就停"，语义对不对它一概不管。所以刹车踏板装太灵，等于轻轻一碰就熄火。还有一点容易忽略：截断之后已生成的部分照常计入用量，省下的是没写出来的内容，而不是整次请求。
什么场景值得踩这脚刹车
带得上判断的用法有三类。结构化输出场景，比如让模型只产出一行标题或一段固定格式的字段，用结束标记当停止序列最省心；批量处理场景，几千条翻译逐条跑时截得越早花得越少，开销还和计费梯度挂在一起；多轮对话场景，消息列表怎么排、每轮带多少历史，同样影响截断时机，可参考消息列表一篇。至于模型"想多久"再动笔，那是另一个旋钮，见思考预算。拿不准时做个小实验：同一批输入跑两次，一次设刹车一次不设，对比输出和用量，结论立刻清楚。
几种常见用法摆在一起，设法与误伤点各不相同。
| 场景 | 怎么设 | 换来什么 | 要防的误伤 |
|---|---|---|---|
| 只想要译文 | 把换行符设成停止序列，翻完第一行就截住 | 多余的客套话没有出场机会 | 想先给答案再补解释时，别把换行当刹车 |
| 结构化输出（一行标题、固定格式字段） | 用结束标记当停止序列 | 最省心，格式外的内容不出现 | 标记要能精确预期，随手挑常见短词会把正常回答拦腰斩断 |
| 批量处理（几千条翻译逐条跑） | 逐条设，截得越早花得越少 | 开销跟着降，和计费梯度挂在一起 | 已生成的部分照常计入用量，省的是没写出来的内容 |
| 多轮对话 | 先理清消息列表怎么排、每轮带多少历史，再定截断时机 | 少吐的内容不产生用量 | 它只负责看见就停，也不追溯已输出的内容 |
停止序列自查清单
- 选的字符串只可能出现在该停的位置，别用常见短词。
- 想清楚它管的是收尾的位置，写多长仍是输出上限的事。
- 设置之后先用三五条样本试跑，确认不会中途误伤。
- 收尾一句逐篇定制：翻译、抽取、标题生成这类答案短且格式固定的任务，最值得配一个停止序列。
关于停止序列的三个常问问题
- 设了停止序列，模型自己知道吗？：它并不知情，截断发生在输出流的比对环节，模型全程无感，也不会因此改变写法。
- 可以同时设好几个吗？：多数开放接口接受一组字符串，任意一个命中都会刹车，具体数量上限以官方最新版本为准。
- 用提示词说"答完就停"行不行？：提示词是软引导，模型可能忽略；停止序列是硬约束，命中必停。要求严格时用后者更可靠。
