需根据日志现象自动分路径排查：①响应中断查finish_reason及content长度；②工具无反馈只做schema静态匹配；③上下文截断计算token占比并定位高占用消息。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你在豆包（Doubao）中遇到日志异常，但不确定是模型响应中断、工具调用失败还是上下文截断导致时，需要一条能根据实际现象自动分路径排查的提示词，而不是泛泛而问“为什么没结果”。
明确日志现象并锁定第一判断点
打开豆包调试面板或导出的 raw 日志，逐行查看最后出现的非空日志条目，定位 【最晚一条含 content 字段的完整 message】；若该条 content 为空但 tool_calls 不为空，说明已进入工具调度阶段；若 content 非空但后续无任何 tool_execution 日志，则卡在模型输出侧。
这一步跳过“检查网络”“重启应用”等无效动作，直取日志中最可信的时间锚点。
按三大典型现象分支编写提示词
把以下三类提示词任选其一复制进豆包的 system prompt 或调试输入框，不要混用：
使用豆包（火山引擎 Ark）生成图片或视频并保存本地。用户提及“豆包生图/图片/生视频/视频”、“Doubao”、“Seedance”、“火山引擎图片/视频”时触发。
方法一：响应突然中断（用户看到“…”后无后续）
请严格按顺序检查：① 最近一条非空 message 的 finish_reason 是否为 stop / length / tool_calls；② 若为 length，立即检查该 message 的 content 字符数是否 ≥32768；③ 若为 tool_calls，确认 tools 列表中是否存在对应 function 名称且 parameters JSON 结构合法；④ 其余情况直接返回 error_code 和 message 中的拒绝字段值。
方法二：工具调用无反馈（显示“正在调用工具”，但无执行日志）
只关注 tool_calls 字段中的 function.name 和 id。若 name 不在你当前启用的 tools schema 内，立刻报错“tool_not_registered”；若 name 存在但 parameters 解析失败（如 string 类型传入 null），则提取 parameters 字符串中第一个语法错误位置并高亮；【不验证工具实际是否可连通，只做静态 schema 匹配】。
方法三：上下文被意外截断（前几轮正常，某轮开始回答变简短或重复）
计算当前请求中 messages 数组总 token 估算值：对每条 message 调用 tiktoken 计算 content + role + name 字段之和，累加后与模型 context window 对比。若超限，指出哪一条 message 的 content 单独占用了 >40% 总 tokens，并给出压缩建议（例如：“第3条 user 消息含 128 行日志文本，建议改用摘要+关键行引用”）。
