豆包是怎么答一个问题的？（下）：四类场景的打法与能力边界

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

上篇拆了四层逻辑里的前两层：识别需求与内容判定（判断意图、完备度、内容域、风险），内容规范约束（硬约束与软约束，以及软约束在发布场景会升级为硬约束）。

一句话概括前两层的作用：在开口之前，把"要什么"和"不能碰什么"确定下来。

但方向对、边界稳，不代表回答就好用。真正决定"这段回答像不像人写的"的，是后两层。这篇就讲这两个环节，以及它们失效的地方。

四、环节三：按问题类型匹配回答策略

这是最能体现"逻辑"的一层。同样是"回答"，四类问题的目标完全不同：知识性问题追求准确，创作类追求可用，计算题追求可验证，闲聊追求舒服。目标不同，打法就必须不同。

用同一套方式应对四类问题，结果一定是"都能答，但都不好用"。

火山引擎的官方文档其实印证了这种分流思路：豆包助手 API 把能力拆成了四种模式，并且明确单次仅可开启一个：

这个"一次只能选一种"的限制很说明问题：策略路由是个真实存在的、必须做选择的环节。闲聊用搜索是浪费，查实时价格用纯推理是冒险，做行业研究却只开单轮搜索，结论一定薄。

下面四类，逐个给要点和打法。

4.1 知识性问题（是什么/为什么/怎么做/有什么区别）

回答要点

常见处理方式

• 概念类 → 定义 + 类比 + 反例（"它不是什么"往往比"它是什么"更好懂）；

• 对比类 → 直接上对照表，按维度拆；

• 操作类 → 编号步骤，每步给验收标准（做完怎么知道对了）；

• 原因类 → 分清直接原因和根本原因，别混在一起讲。

典型失败：正确的废话（说了三百字等于没说）、过度自信（把推测讲成定论）、术语堆叠（用更难的词解释难的词）。

4.2 创作类（文案、文章、脚本、方案、命名）

回答要点

先锁定五要素：体裁、受众、目的、长度、风格与禁忌；

给结构骨架，再填肉——让人看到"为什么这样排"；

出完整可用稿，不要给提纲让用户自己写；

标注可替换点（"这里可以换成你的具体案例"）；

提供 2–3 个差异化版本，而不是同一版微调三次。

常见处理方式

缺参数时：先按最合理的假设出一版，把假设写在开头。这比连续追问更符合真实使用习惯，用户看到具体文字才知道自己要什么；

需要选择时：给"稳的版本"和"有锋芒的版本"，说清各自适合的场景；

涉及对外发布：主动过一遍极限词和平台规范，把风险点标出来。

典型失败：通篇形容词没有信息量、把"高端大气"当风格指令、模板腔（每一段都是"首先/其次/最后"）。

这里要点出一个常见误解：创作类不是知识类的变体。知识类要求收敛到一个正确答案，创作类恰恰要求发散出多个可选项。用"给标准答案"的心态写文案，出来的东西必然是四平八稳但毫无记忆点的。反过来，用"多给几个版本"的心态答知识题，用户会更困惑——他要的是一个准确答案，不是五个候选。

4.3 计算与客观题（算术、单位换算、日期推算、逻辑题、代码题）

回答要点

先列式，再算：把条件和公式摆出来，让人能检查；

分步给中间结果：一步到位的结果不可验证；

写清单位和口径：含税/不含税、自然日/工作日、四舍五入到哪一位；

结果单独成行，方便一眼看到；

给验算或边界检查：量级对不对、极端情况是否成立。

常见处理方式

纯计算 → 公式 + 代入 + 结果 + 一句量级校验；

代码题 → 可直接运行的代码 + 关键行注释 + 边界用例；

有歧义的口径 → 明说采用了哪种假设，并给出另一种口径下的结果。

典型失败：过程省略只给答案（错了也无法定位）、单位混用、把"看起来对"的数字直接输出。这类问题上，承认"这个数我算出来是 X，但建议你用工具核一遍"比硬给一个数更负责。

4.4 闲聊（情绪表达、寒暄、无明确目标）

回答要点

短：一到三句话，别把聊天变成讲座；

先接情绪，再给信息：用户说累，先回应累，而不是立刻给一套作息方案；

不硬转业务：闲聊里突然推销是最伤体验的操作；

最多一次轻追问，给个台阶，不逼用户回答。

常见处理方式：共情 + 一个可选项（"要不要聊聊具体是哪件事卡住了"）；或者顺着话题给一个轻量信息点，把主动权交回去。

典型失败：把"今天好累"回答成一篇《缓解疲劳的十个方法》、过度热情的语气词堆砌、每句话都以反问结尾。

4.5 四类场景速查表

五、环节四：控制表达与追问补充

前三层决定"说什么"，这一层决定"怎么说"以及"什么时候干脆不说、改成问"。

5.1 表达控制的五件事

结构：能分点就分点，能列表就列表，超过三个并列项考虑表格；

顺序：结论先行。技术读者尤其没耐心看铺垫；

密度：一段只讲一件事，长句拆短，避免"通过……的方式，对……进行……的处理"这类嵌套；

语气：跟着用户走。用户一句话问，别回三千字；用户用术语，别强行降智解释；

不确定性标注："据我所知""这一点建议核实""我没有实时数据"——这三句话不丢人，反而建立信任。

5.2 追问的三个触发条件

不是所有信息缺失都值得追问。满足以下任一条才问：

• 缺的是关键参数，且直接改变结论（比如问"帮我算房贷"，没有贷款金额和利率）；

• 风险高，不能替用户假设（医疗剂量、法律时效、财务承诺）；

• 存在多个合理解释，且分支答案差异极大（"这个多少钱"且无上下文）。

反过来，以下情况不该追问：

• 能从上下文合理推断 → 推断 + 说明推断依据；

• 追问成本高于试错成本 → 直接给多版本覆盖所有分支；

• 只是细节缺失 → 先答主体，末尾补一句"如果你要的是另一种情况，告诉我"。

5.3 追问本身的质量标准

一次追问最多三个问题，且必须满足：

连环追问是体验杀手。用户提问时预期是"得到东西"，连续三轮只收到问题，大概率直接关掉。这也是为什么 C 端产品普遍选择"先按假设出稿"而不是"先问清楚再动"——追问在效率上是负收益，除非它省下的返工成本足够大。

六、注意事项与适用范围

这套逻辑解释力不错，但边界必须说清楚，否则容易用错地方。

6.1 这套逻辑自身的边界

① 它是行为逻辑，不是源码架构。 四层划分是为了便于理解和复用，真实系统里的模块边界未必如此，也不排除多层被合并成一次推理。

② 通顺不等于正确。 语言模型的本质是预测下一个最合理的词，生成流畅和事实正确是两件事。越是具体的数字、人名、文献、法条，越要复核。

③ 时效性靠外部能力兜底。 训练数据有截止时间，实时信息依赖联网检索。所以"官方文档把联网搜索单列成一种模式"这件事本身就在提示：该不该联网，是个需要判断的选择，而不是默认开启。

④ 多轮对话会衰减。 官方 API 侧对连续对话的支持上限是 20 轮。轮次一多，早期约束容易被稀释——第一轮说"全文不超过 500 字"，第五轮往往就忘了。重要约束值得在每轮重申，或者干脆重开一个会话把结论带过去。

⑤ 可调空间有限。 豆包助手 API 目前仅支持文本输入，不能调整 temperature、top_p、max_tokens 这类参数，且单次只能启用一个功能模式，也不能与自定义函数、私域知识库等工具混用。这意味着大量"回答逻辑"是产品侧固化的策略——你享受了开箱即用，就要接受精细控制的缺失。需要强控制时，自建才是正解。

6.2 使用者侧：怎么问才能拿到好答案

给交付物，不给话题。"写个活动方案" → "写一份 300 字内的门店开业活动方案，面向周边三公里居民，重点是到店礼"；

一次把约束说完：受众、长度、风格、禁忌，开头讲完，比后面纠偏五轮省事；

要求它先复述需求。复杂任务加一句"先说说你理解的任务是什么"，能挡掉大量跑偏；

让它标不确定。"不确定的地方直接说不确定"，这一句能显著降低幻觉；

不对就指位置，不说"不对"。"第三段的结论和前面矛盾"比"重写"有效十倍。

6.3 开发者侧：把四层抄进自己的 Agent

• 把路由做成显式模块：先用规则或小模型做意图分类，再决定走检索、推理还是创作链路。别指望一个大 prompt 兼顾所有类型；

• 把约束从提示词里抽出来：能写成规则的（字数、格式、禁用词、免责声明）就不要靠模型记，用代码兜；

• 把追问做成槽位填充：预先定义必需参数，缺哪个补哪个，比自由发挥式的反问稳定得多。

6.4 什么时候别用它

• 需要承担责任的专业判断：诊断、法律意见、投资决策，AI 只能辅助整理信息；

• 必须绝对准确的数字：报表口径、合同条款、报价，以原始文件为准；

• 强实时、强地域的事实：库存、路况、排队情况，走专用接口；

• 涉及他人隐私与企业机密的内容：不上传、不粘贴、不让它"帮你分析一下"。

七、总结

把四层逻辑串起来看，最大的价值不是"看懂了一个产品"，而是拿到一套可以迁移的方法：

• 识别需求与内容判定决定了方向对不对——先想清楚"他要什么"，再想"我知道什么"；

• 内容规范约束决定了边界稳不稳——硬约束先过，软约束随后，公开渠道按最严处理；

• 按类型匹配策略决定了打法对不对——知识求准、创作求用、计算求验、闲聊求舒服，四套目标不能混用；

• 表达控制与追问补充决定了体验好不好——结论先行、该问才问、不确定就说不确定。

这四层的优先级是从上到下的：方向错了，后面全废；边界破了，答得再好也是负分；打法错了，内容再对也不好用；表达失控，前面全白做。

所以遇到"AI 答得很怪"的时候，与其反复重写提示词，不如先定位是哪一层出的问题——是没听懂、越界了、用错打法，还是表达失控。定位准了，改一句就够；定位不准，改十遍还是原样。

对普通用户来说，记住一句话就够了：AI 的输出质量，上限由模型决定，下限由你的提问决定。对开发者来说，则是另一句：这套逻辑最值得抄的不是结论，是"分层 + 路由 + 兜底"的结构。