标准回答
一、总思路
LLM 强在理解和生成自然语言，但它是概率模型、会幻觉、有延迟和成本。凡是和这些短板冲突的场景就要慎用，或只让它做辅助 + 人审。
二、不适合的几类场景
- 要求 100% 准确、可审计：医疗诊断、财务/税务计算、法律判决等直接决策，错误代价大且需可解释可追溯，LLM 的不确定性不可接受。
- 强实时、低延迟、低成本：高并发、毫秒级响应或预算极紧的链路，LLM 推理慢又贵，不划算。
- 简单规则可解：表单校验、固定流程判断，写 if-else、正则或用传统模型既稳定又便宜，杀鸡不用宰牛刀。
- 精确数学 / 确定性输出：纯计算、严格排序、必须每次结果一致的任务，应交给代码或计算器，LLM 易算错。
- 数据缺乏或隐私极敏感：没有可用语料、或数据不能外传的场景，需评估本地部署或干脆不用。
三、更稳的做法
这些场景优先用规则、传统模型或检索；确实需要 LLM 时，让它只做辅助（草稿/解释），关键结果由确定性逻辑或人工把关。参考 RAG 架构指南。
常见误区
⚠️ 常见踩坑
误区一：容易答偏的地方：把 LLM 当万能锤，什么需求都套大模型，结果在简单/高频/高精度场景上既贵又慢还不稳定；以及在高风险决策里让 LLM 直接拍板而不加人工复核。
追问
追问 1：如果业务确实要在高风险场景用 LLM，怎么降低风险？
让 LLM 只做辅助而非最终决策：用 RAG 接权威数据减少幻觉、关键计算交给确定性代码、输出加约束和校验、保留人工复核（human-in-the-loop），并记录可审计日志，把它定位成「提效助手」而非「拍板者」。
追问 2：怎么判断一个需求该用 LLM 还是传统方案？
先看任务是否需要理解/生成自然语言或处理开放性输入——是才考虑 LLM；再评估准确性要求、延迟与成本预算、数据与隐私约束。如果规则或传统模型就能稳定满足，优先用它们，LLM 留给真正发挥语言理解优势的部分。
🔗 相似问题
同一考点的不同问法，换着练更稳
延伸学习
按主题分类的相关资源，便于系统复习