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 事件中：