主题
高频面试题
零样本 CoT 和少样本 CoT 有什么区别？各自适合什么场景？
面试官问这题，不是想听“一个有示例一个没示例”，而是在看你能否按任务难度、示例质量、成本和稳定性做取舍。
面试官角度分析，想考什么
- Zero-shot CoT 和 Few-shot CoT 的核心区别是什么？
考你能否从“触发方式”和“示范推理模式”解释，而不是只背概念。 - 为什么一句“让我们一步步思考”会有效？
考你是否理解 CoT 通过中间步骤增加推理计算和可分解性。 - Few-shot 示例越多越好吗？
考 token 成本、示例污染、示例代表性和边际收益。 - 生产里怎么选？
考稳定性、延迟、成本、评估集和失败兜底。
可直接抄走的 30 秒参考答案
text
Zero-shot CoT 是不给示例，只加一句“请一步步推理”来触发模型分步思考；Few-shot CoT 是给几个带完整推理过程的样例，让模型模仿解题路径。前者轻量、通用、适合快速验证；后者更稳定，适合复杂或业务规则明确的任务，但会增加 token 成本，也依赖示例质量。生产里我会用评估集比较二者，而不是凭感觉选。面试回答详解，知其所以然
这道题的核心不是“有没有例子”这么浅，而是要讲清：模型是否只被提醒“要推理”，还是被示范“该怎么推理”。
1. Zero-shot CoT：用通用指令触发推理
Zero-shot CoT 不提供任务样例，只在问题后追加类似指令：
text
请一步步推理，最后给出答案。它的优势是 prompt 短、迁移性强、接入成本低。对于中等难度的数学、逻辑、因果判断、需求分析等任务，它能让模型先拆步骤再回答，减少直接猜答案的概率。
但它的问题也明显：模型知道“要分步”，却不一定知道“按什么粒度、什么格式、什么判断标准分步”。所以输出可能啰嗦、绕路，甚至生成看似合理但错误的推理链。
2. Few-shot CoT：用示例教会推理样式
Few-shot CoT 会给模型 2 到 5 个示例，每个示例不仅有问题和答案，还展示中间推理过程：
text
问题: ...
推理: 第一步... 第二步... 第三步...
答案: ...
问题: {新问题}
推理:它更像“示范解题规范”。模型会模仿示例里的拆解方式、术语、输出格式和判断标准，因此在垂直任务、格式严格任务、复杂多步推理里更稳定。
代价是 token 更多，维护成本更高；如果示例选得不好，还会把错误路径、过度假设和格式偏差一起带进输出。
3. 两者的主要差异
- 触发方式：Zero-shot CoT 靠一句通用指令；Few-shot CoT 靠带推理过程的示例。
- 稳定性：Zero-shot CoT 更依赖模型自身能力；Few-shot CoT 能固定推理模式。
- 成本：Zero-shot CoT prompt 短；Few-shot CoT 会占上下文窗口。
- 适配性：Zero-shot CoT 适合快速泛化；Few-shot CoT 适合任务边界清晰的高价值场景。
- 风险：Zero-shot CoT 容易“假装推理”；Few-shot CoT 容易被坏示例带偏。
4. 选择建议
简单事实问答、翻译、摘要、分类不一定需要 CoT，直接约束输出更好。需要多步推理但没有成熟样例时，可以先用 Zero-shot CoT 快速试水。
当任务有稳定评判标准、错误代价较高、输出要符合固定业务逻辑时，再升级到 Few-shot CoT。比如风控规则解释、复杂 SQL 生成、代码修复分析、面试题解析，都更适合放少量高质量示例。
5. 生产落地边界
生产里不要只看单个 demo 的效果，要建小型评估集，对比直接回答、Zero-shot CoT、Few-shot CoT 和 Self-Consistency。还要记录 token 成本、延迟、格式错误率和人工抽检结果。
如果模型是内置推理能力很强的 reasoning model，外部强行要求详细 CoT 可能反而干扰输出。这时更推荐要求“给出简洁结论和关键依据”，而不是让模型暴露冗长推理过程。
面试官追问3个问题
追问一：Zero-shot CoT 为什么有时会输出错误推理？
- 考察点：是否知道 CoT 不是事实校验器。
- 回答方向：它只鼓励模型展开中间步骤，不保证每一步都对；要通过证据、工具、校验器或投票降低风险。
追问二：Few-shot 示例怎么选？
- 考察点：是否能讲出示例质量。
- 回答方向：选择覆盖典型边界、步骤清晰、格式统一、答案可验证的示例；数量宁少而精。
追问三：推理模型还需要 CoT prompt 吗？
- 考察点：是否了解模型能力差异。
- 回答方向：通常不需要冗长 CoT 指令，更适合要求输出结论、关键依据和可验证结果。