follow_ups: Array<{ label, prompt }> 字段。这些是由 AI 生成、感知当前模式的下一轮建议 —— 可以直接作为建议芯片放入聊天界面。
何时会生成后续追问
- 在每一次文本模式补全中（
auto、fast、think、code、research、roast、genui、vision，以及隐身文本变体）。 - 在图像 / 视频 / 文档轮次中 —— 后续追问通常是编辑/变体类提示（例如”试试更宽的宽高比”、“把背景调亮一些”）。
- 不会在
stt（语音转文本）或tts（文本转语音）响应中生成 —— 因为不存在自然的下一轮。 服务器每次响应会返回 0 到 3 条后续追问。对于简短的回答、出错情况，或 Theo 没有可供建议内容的场景，返回空数组也是正常情况。
数据结构
label 是芯片上展示给用户的文本。prompt 是用户点击该芯片时，作为下一次请求的 prompt 字段提交的内容。两者通常并不相同 —— label 是简短的祈使句，prompt 则是一条完整的指令，承接上一轮对话的内容继续下去。
生成方式
Theo 会将该轮对话的内容、使用过的工具以及产出的任何附件，传入一个在主补全之后运行的轻量级后续追问生成器。这些建议是由 AI 生成的，而非基于规则，因此质量会随模型档位不同而有所差异 ——think 模式生成的后续追问通常比 fast 模式更好。这里不存在单独的”后续追问费用”项目；生成器是搭载在同一次 LLM 调用上完成的。
在聊天界面中渲染
一个最简单的 React 模式：在最后一条助手气泡下方渲染一行芯片。- 在完整消息显示之后再渲染这些芯片。对于流式响应，
follow_ups只会在done事件中出现，因此要等到该事件出现之后再渲染。 - 当用户点击某个芯片时，将
prompt原样作为下一次的prompt发送。不要将它与用户自己输入的内容拼接在一起 —— 这些 prompt 本身就是自包含、可直接使用的。 - 一旦用户开始输入新消息，就隐藏芯片行，并在下一轮补全完成后再重新显示新的芯片。这也是大多数生产环境聊天界面所采用的模式。
流式场景
对于流式补全，后续追问会出现在done 事件中：