关于 LLM大多数团队的第一步就选错了很多开发团队上手大语言模型LLM的方式是找到一个通用对话接口然后开始“什么都往里塞”——让模型写周报、查数据库、生成图片、做客服、分析财报甚至尝试让它直接替代整个业务系统。结果通常是简单任务做得不错复杂任务频繁出错关键业务不敢让它碰最后项目停在“演示可用生产不可用”的尴尬阶段。问题不在于 LLM 不够强而在于团队没有想清楚一个根本问题——LLM 应该做什么不应该做什么。这是一个比“怎么调 prompt”“怎么选模型”更前置的问题。选错方向后面所有工程优化都是在错误的地基上盖楼。本文会给出一个可操作的判断框架并从代码生成、数据分析、客服、文档处理等真实场景出发说明 LLM 的适用边界、接入方式和最容易踩的坑。读完这篇文章你会得到三个明确结论LLM 的可靠工作区间是“生成式、归纳式、转换式”任务而不是“精确计算、严格校验、强状态管理”任务。判断一个需求该不该用 LLM可以用一套简单规则快速过滤。真正把 LLM 用到生产环境关键不在模型本身而在工程控制——校验、降级、熔断、可观测一个都不能少。1. 为什么必须有“LLM 该做什么”的判断先看一个普遍现象很多团队把 LLM 当成一个超级函数期望传入任意输入就得到正确输出。但 LLM 的本质是概率模型它生成的是“最像样子的答案”而不是“经过验证的正确答案”。这两个概念在大部分场景下接近但在关键场景下会差之千里。举个例子让 LLM 做文本摘要、润色文案、改写代码风格它表现得很好因为这类任务允许多样性没有唯一正确答案。但如果你让它做用户订单金额的累计汇总它可能在前几次计算正确后几次就出错因为数字计算不是概率生成的强项。更危险的是它出错时极其自信不会告诉你“这个我不确定”。所以“LLM 应该做什么”不是一个哲学问题而是一个工程决策。它决定了你在系统架构里的哪一层使用模型、用多重的校验逻辑、如何设计降级方案。这里可以先给出一个核心判断LLM 适合做“从模糊到清晰”的创造性工作不适合做“从精确到精确”的确定性计算。“从模糊到清晰”包括把一段口语描述转换成结构化需求把几百页文档归纳成要点把用户的模糊意图映射到系统的标准动作把一个函数改写成另一种语言或风格“从精确到精确”包括金额计算、库存扣减、权限校验定时任务、消息队列的状态管理数据库事务的一致性保障任何要求“必须百分之百正确”的逻辑这不是说 LLM 不能碰第二类任务而是说当它参与这类任务时必须把 LLM 当作“生成者”而不是“决策者”。决策权要掌握在可验证的代码手里。2. LLM 的能力边界能做什么不能做什么要准确判断“LLM 应该做什么”需要先建立一个客观的能力模型。从实际项目表现来看LLM 的能力边界可以分成三层。2.1 第一层非常可靠的工作这类工作即使不经过严格校验错误率也在可接受范围内因为任务本身对“唯一正确答案”的要求不高。任务类型具体场景为什么可靠内容生成营销文案、邮件草稿、故事框架没有标准答案只要通顺合理即可格式转换JSON 转 XML、自然语言转 SQL 初稿模式固定模型见过大量类似数据摘要归纳会议纪要、长文档提炼只要关键信息不丢偏差可控代码补全函数实现、单元测试初稿、正则生成有大量语料支撑生成质量稳定意图分类判断用户意图属于“查询”还是“操作”分类任务对模型来说相对容易这些任务的共同特点是输出可以被人工或程序快速验证即使出错修复成本也不高。2.2 第二层需要严谨工程控制的场景这类任务 LLM 能做但输出质量波动大必须引入额外的校验机制。任务类型风险点工程控制方式自然语言转 SQL生成的 SQL 可能语法错误或语义偏差只执行只读查询用 EXPLAIN 验证限制返回行数信息抽取抽取结果可能遗漏或多余定义严格的输出格式用规则校验关键字段代码生成可能引入安全隐患或逻辑错误强制 Code Review运行单元测试静态扫描对话客服可能答非所问或产生误导限定知识库范围无法命中时转人工数据清洗清洗规则可能出现不一致先在小样本上对比验证再全量执行这类场景最容易出现“看起来能用实际上不能信”的问题。团队往往只看到了 80% 的成功样例忽视了 20% 的失败会在生产环境造成多大影响。2.3 第三层不应该让 LLM 独立承担的工作这部分是事故高发区。如果输入材料没有明确支持建议直接绕开用传统代码实现。任务类型为什么不能用 LLM精确数值计算概率生成无法保证计算结果精确一致多步骤状态流转LLM 没有可靠的内存机制跨步骤状态容易丢失权限校验与鉴权安全边界必须由确定性代码控制金融交易与订单履约错误成本高且需要完整审计链路时间敏感型任务LLM 输出时长不稳定不适合硬实时要求这里要特别强调一个常见误区不要用 LLM 去“修正”一个原本就应该用规则解决的问题。比如用户输入手机号校验、邮箱格式校验这类问题用正则表达式一行解决准确率 100%完全没有必要让模型参与。3. 从“什么事该用 LLM”到“怎么用 LLM”一个判断框架在真实的业务需求评审中我建议用下面这个四步框架来判断一个需求是否适合 LLM。3.1 框架总览判断流程如下需求提出 ↓ 第一关领域是否涉及强安全/强一致 ├── 是 → 不用 LLM或只让 LLM 做辅助生成 └── 否 → 进入第二关 ↓ 第二关是否存在海量可能答案 ├── 是 → 适合 LLM 生成 └── 否 → 进入第三关 ↓ 第三关输出是否可验证 ├── 是 → 适合 LLM 自动校验 └── 否 → 需要人工兜底谨慎使用 ↓ 第四关失败成本是否可控 ├── 是 → 可以进入生产 └── 否 → 建议先人工处理成熟后再迁移3.2 实际案例走查用三个常见需求走一遍这个框架。需求一根据用户描述生成工单标题和分类。第一关不涉及安全一致性问题。第二关工单标题没有唯一答案分类是有限的枚举但模型可以做得很好。第三关标题可以人工修正分类可以和后端规则做比对。第四关失败成本低最多是分类错了用户重新选一下。结论适合用 LLM。需求二让 LLM 根据对话历史计算出用户本月消费总额。第一关涉及金额属于强一致领域。第二关虽然答案唯一但模型计算不可靠。第三关输出可以被程序验证但模型给出错误结果时程序无法自动发现。第四关一旦算错客服投诉和财务差错成本很高。结论不应该让 LLM 直接计算。正确做法是让 LLM 从对话中抽取订单 ID再用 SQL 汇总金额。需求三让 LLM 根据自然语言查询自动执行数据库 DELETE 操作。第一关涉及数据删除强一致、强安全。结论直接否决。LLM 可以生成 DELETE 语句草稿但必须由 DBA 审核后手动执行。生产环境永远不应该把删除操作完全交给模型。3.3 框架背后的设计原则这个框架的本质是把 LLM 放在“生成候选方案”的位置把确定性代码放在“决策执行”的位置。这个原则在业内被称为 Human-in-the-loop 的变体但更准确的说法是verification-in-the-loop——不是“人要盯着模型”而是“代码要校验模型”。4. LLM 与周边工具的协同不是替代是分工有些团队会问LLM 和传统框架是什么关系比如 LLM 是否取代了 RAG 框架、Agent 框架、规则引擎答案是LLM 不会取代这些工具而是作为大脑调用这些工具完成具体任务。4.1 LLM 与 RAG 的分工RAG检索增强生成解决的是“模型知识过时”和“领域知识缺失”的问题。不要把 RAG 当作一个独立产品它是一个数据管道文档切块向量化相似度检索把检索结果拼进 PromptLLM 基于上下文生成答案在这个链路里LLM 负责“基于给定材料生成回答”向量数据库负责“找到相关材料”切块策略和检索逻辑负责“保证材料质量”。如果检索到的材料本身是错的LLM 再强也救不回来。4.2 LLM 与 Agent 的分工Agent 框架解决的是“多步骤任务自动执行”的问题。LLM 在 Agent 中扮演“任务规划者”负责决定下一步调用哪个工具、参数是什么。但工具本身的行为是确定性的例如天气查询工具返回的是真实天气数据数据库查询工具返回的是真实查询结果邮件发送工具执行的是真实发送动作Agent 的价值在于让 LLM 学会“选择工具”而不是让 LLM 去执行工具背后的逻辑。4.3 一个常见的直觉误区有人认为“LLM 什么都能干所以我们要把业务逻辑全部交给 LLM”。这个直觉是错误的。业务逻辑需要确定性而 LLM 天然是概率性的。正确的架构是职责归属理解用户意图、拆解任务LLM执行具体动作、保证一致性代码/工具/服务校验动作结果、处理失败代码/规则引擎记录日志、监控、审计传统中间件5. 一个完整的场景分析代码生成任务LLM 该怎么用代码生成是 LLM 目前最成熟的应用场景之一。但“让 LLM 写代码”和“在工程中用好 LLM 代码生成”是两回事。下面用一个最小示例演示正确姿势。5.1 场景描述假设团队需要把一段 Python 函数改写成 Java 版本。函数的逻辑是根据用户等级计算折扣。原始 Python 代码# 文件路径price.py def calculate_discount(level, amount): if level VIP: return amount * 0.8 elif level NORMAL: return amount * 0.9 else: return amount * 1.05.2 让 LLM 生成初稿把需求描述发给 LLM得到 Java 初稿// 文件路径PriceCalculator.java public class PriceCalculator { public double calculateDiscount(String level, double amount) { switch (level) { case VIP: return amount * 0.8; case NORMAL: return amount * 0.9; default: return amount * 1.0; } } }这段代码看起来没问题但直接复制进生产代码是不合格的。问题在哪里没有处理level为null的情况VIP和NORMAL使用魔法字符串容易打错浮点数乘法涉及金额时应该考虑 BigDecimal没有单元测试验证5.3 人工加固后的生产版本// 文件路径src/main/java/com/example/demo/PriceCalculator.java import java.math.BigDecimal; public class PriceCalculator { private static final BigDecimal VIP_DISCOUNT new BigDecimal(0.8); private static final BigDecimal NORMAL_DISCOUNT new BigDecimal(0.9); private static final BigDecimal DEFAULT_DISCOUNT new BigDecimal(1.0); public BigDecimal calculateDiscount(UserLevel level, BigDecimal amount) { if (level null || amount null) { throw new IllegalArgumentException(level and amount must not be null); } switch (level) { case VIP: return amount.multiply(VIP_DISCOUNT); case NORMAL: return amount.multiply(NORMAL_DISCOUNT); default: return amount.multiply(DEFAULT_DISCOUNT); } } public enum UserLevel { VIP, NORMAL } }// 文件路径src/test/java/com/example/demo/PriceCalculatorTest.java import org.junit.jupiter.api.Test; import java.math.BigDecimal; import static org.junit.jupiter.api.Assertions.assertEquals; import static org.junit.jupiter.api.Assertions.assertThrows; class PriceCalculatorTest { private final PriceCalculator calculator new PriceCalculator(); Test void shouldReturnDiscountForVip() { BigDecimal result calculator.calculateDiscount( PriceCalculator.UserLevel.VIP, new BigDecimal(100.00)); assertEquals(new BigDecimal(80.00), result); } Test void shouldReturnDefaultForUnknownLevel() { BigDecimal result calculator.calculateDiscount( null, new BigDecimal(100.00)); assertThrows(IllegalArgumentException.class, () - calculator.calculateDiscount(null, new BigDecimal(100.00))); } }5.4 这个例子的启示LLM 生成初稿只用了 10 秒但真正能进生产环境的代码是由工程师结合业务规范加固完成的。这里想传达的关键判断是LLM 在代码生成上的正确用法是“加速器”而不是“替代者”。它大幅压缩了从空白页面到初稿的时间但 Code Review、单测、边界处理、安全审查这些环节一个都不能省。6. 用 LLM 做客服场景什么该自动什么该转人工客服是 LLM 应用最广泛的场景之一但也是最容易翻车的场景。很多团队直接把历史工单灌进模型期望它完美回答所有用户问题。结果遇到投诉、退款、法律风险类问题时模型的回答可能造成严重后果。6.1 推荐的客服分层策略层处理方式适用问题工程要求L1LLM 直接回答产品功能、操作步骤、费用说明知识库 RAG 引用溯源L2LLM 规则兜底订单查询、物流查询调用后端 API 获取真实数据LLM 只做语言组织L3人工客服投诉、退款争议、法律条款、安全风控设置敏感词和风险识别规则自动转人工6.2 代码示例风险问题识别在 L1 转 L3 的场景里可以用 LLM 做一次风险判断但必须用规则引擎兜底。下面是一个 Python 示例# 文件路径service/risk_check.py import re RISK_KEYWORDS [投诉, 退款, 法律, 起诉, 赔偿, 举报] def rule_based_risk_check(message: str) - bool: 基于规则的风险识别用于兜底 for keyword in RISK_KEYWORDS: if keyword in message: return True return False def llm_risk_check(message: str, llm_client) - str: 让 LLM 对用户消息做风险等级判断 prompt f 判断以下用户消息是否属于高风险类别高风险包括投诉、退款纠纷、法律威胁、人身攻击、安全举报。 只输出一个词HIGH 或 LOW。 用户消息{message} response llm_client.chat(prompt) return response.strip().upper() def handle_message(message: str, llm_client) - str: # 规则引擎优先 if rule_based_risk_check(message): return 转人工客服检测到高风险关键词 # LLM 二次判断 risk_level llm_risk_check(message, llm_client) if risk_level HIGH: return 转人工客服模型判定为高风险 return 正常处理这个设计的关键是规则引擎先拦截LLM 做补充判断。即使 LLM 判断失误规则也会挡住最恶劣的情况。7. 文档智能化场景LLM 真正的高价值区如果说代码生成是 LLM 最成熟的场景那么文档智能化是 LLM 最容易产生确定性业务价值的场景。原因在于文档处理天然是“从模糊到清晰”的任务而且失败成本相对可控。7.1 典型应用清单合同条款抽取从合同中提取甲方、乙方、金额、期限、违约责任研报摘要把几十页研报压缩成三个关键结论会议纪要生成把原始录音转写文本整理成结构化纪要政策解读把法规条文翻译成业务人员能理解的语言工单自动分类根据描述自动打上标签并指派负责人7.2 实操合同条款抽取假设需要从合同中抽取关键信息使用 LLM 加 JSON 结构化输出的方式# 文件路径service/contract_extract.py import json def extract_contract_info(contract_text: str, llm_client) - dict: prompt f 你是合同信息抽取助手。请从以下合同中抽取指定字段并输出 JSON 格式。 字段包括 - party_a: 甲方名称 - party_b: 乙方名称 - amount: 合同金额数字不带货币符号 - currency: 货币类型 - sign_date: 签订日期格式 YYYY-MM-DD - term: 合同期限描述 合同内容 {contract_text} 只输出 JSON不要输出其他内容。 response llm_client.chat(prompt) # 解析 JSON try: result json.loads(response) except json.JSONDecodeError: # 解析失败时进行修复 repaired repair_json(response, llm_client) result json.loads(repaired) # 关键字段校验 required_fields [party_a, party_b, amount] for field in required_fields: if not result.get(field): raise ValueError(f缺少关键字段: {field}) return result def repair_json(raw_response: str, llm_client) - str: prompt f 以下内容是从合同抽取的结构化结果但 JSON 格式不完整请修复为合法 JSON。 {raw_response} repair_prompt f请修复下面的 JSON使其合法。只输出修复后的 JSON。 原始内容 {raw_response} return llm_client.chat(repair_prompt)这里有两个工程细节值得注意必须校验关键字段。LLM 可能漏掉字段所以抽取结果进入下游流程前要检查party_a、party_b、amount是否齐全。必须处理 JSON 解析失败。LLM 输出不一定是合法 JSON要有修复策略而不是直接报错给用户。8. 生产环境接入 LLM 的工程约束通过前面的场景分析可以提炼出生产环境接入 LLM 的通用工程约束。这部分往往是博客文章容易忽略的但恰恰是最重要的。8.1 输出校验是第一道防线LLM 输出永远要过一层校验器。校验器可以是正则、JSON Schema、枚举比对、业务规则甚至是另一个小型模型。没有校验的 LLM 输出等于把系统的正确性交给概率。# 文件路径service/output_validator.py from jsonschema import validate, ValidationError SCHEMA { type: object, properties: { intent: {type: string, enum: [query, order, complaint]}, params: {type: object}, confidence: {type: number, minimum: 0, maximum: 1} }, required: [intent, confidence] } def validate_llm_output(raw_output: str) - dict: import json try: data json.loads(raw_output) validate(instancedata, schemaSCHEMA) return data except (json.JSONDecodeError, ValidationError) as e: raise ValueError(fLLM 输出校验失败: {e})8.2 超时与降级LLM API 的响应时间波动较大必须设置超时时间并准备降级方案。不能因为模型超时导致主业务流程挂起。// 文件路径src/main/java/com/example/demo/LlmService.java import java.time.Duration; public class LlmService { private final LLMClient client; public LlmService() { // 配置超时时间建议 10 秒 this.client LLMClient.builder() .connectTimeout(Duration.ofSeconds(5)) .readTimeout(Duration.ofSeconds(10)) .build(); } public String generateWithFallback(String prompt, String fallback) { try { return client.chat(prompt); } catch (Exception e) { // 降级返回预设兜底文案 return fallback; } } }8.3 可观测性每一次 LLM 调用都要留痕生产环境里LLM 调用必须记录完整链路输入 prompt、输出结果、耗时、token 数、模型版本、校验结果。这样当线上出现问题时可以回溯是 prompt 问题、模型问题还是校验逻辑问题。{ trace_id: a1b2c3d4, timestamp: 2025-06-01T10:00:00Z, model: gpt-4o-mini, prompt_hash: 6f2d8a..., response_preview: {\intent\:\query\}, latency_ms: 842, token_usage: { prompt_tokens: 356, completion_tokens: 48 }, validation: pass }8.4 安全边界LLM 接入生产环境安全边界必须明确不把 LLM 的输出直接作为权限判定的依据权限校验永远由身份认证和授权框架负责。不把 LLM 的 prompt 拼进系统命令防止提示词注入影响底层服务。不把未经脱敏的敏感数据直接发给外部模型 API需要数据脱敏或使用私有化部署。9. LLM 不该做什么典型反面案例复盘为了把“LLM 应该做什么”这个问题讲透再用三个反面案例说明“不该做什么”。9.1 反面案例一让 LLM 维护会话状态背景某团队做了一个智能表单助手用 LLM 管理多步骤填表过程中用户已经填写的字段。现象用户在第 3 步填写的信息在第 5 步的 prompt 中丢失了。LLM 忘记用户之前选择了哪个城市。原因LLM 的上下文窗口有限而且模型对“跨多次调用的状态保持”没有内建的可靠性保证。正确方案状态存到 Redis 或数据库LLM 只负责解析当前这一步的用户输入从存储中读取前序状态拼入 prompt然后把新状态写回存储。9.2 反面案例二让 LLM 做精确排重背景某团队需要判断用户提交的两条商品描述是否指向同一件商品。现象LLM 给出的结论在 90% 的情况下正确但剩余的 10% 出现了大量误判导致商品数据重复。原因语义相似度判断是一个概率任务但商品排重需要精确结果。当数据量达到百万级时小概率错误会被放大成大量脏数据。正确方案用确定性字段SKU、品牌型号做第一层排重LLM 只负责处理“确定性字段缺失”的长尾样本且结果必须人工确认。9.3 反面案例三让 LLM 直接写生产数据库背景某团队实现了“用自然语言查询数据库”的功能用户可以说“把订单日期为昨天的记录全部标为已处理”。现象一次 prompt 注入攻击让 LLM 生成了DELETE FROM orders WHERE 11这样的危险语句好在权限控制拦截了。原因让 LLM 生成写操作 SQL等同于允许任意用户通过自然语言执行数据库变更风险极高。正确方案自然语言只允许映射到只读查询写操作必须走审批流由人工确认后执行且数据库账号必须遵循最小权限原则。这三组案例指向同一个结论LLM 越靠近决策执行层风险越大越靠近生成建议层价值越稳妥。10. 常见问题与排查思路在实际接入 LLM 的过程中团队会遇到很多共性问题。整理成表格方便对照排查。问题现象可能原因排查方式解决方案同一 prompt 输出结果不稳定模型采样温度过高检查 temperature 配置调低至 0.10.3或固定随机种子输出 JSON 频繁解析失败prompt 未约束格式或模型版本较弱查看原始输出日志在 prompt 中给出 JSON 示例使用 JSON Mode增加格式校验和修复回答内容过时模型训练数据不包含最新信息检查知识库更新时间接入 RAG让模型基于检索内容回答回答包含幻觉内容模型对不确定问题强行作答对比知识库原文在 prompt 中要求“无法确定时明确说明不知道”接口响应过慢prompt 过长 / 模型参数量大查看 token 数和模型选择精简 prompt使用更小的模型加入缓存金额/数字计算错误模型本质是概率生成不适合精确计算检查输出与预期差异改为 LLM 抽取数据 代码计算业务状态丢失把状态保存交给 LLM 管理检查多轮调用之间的上下文用 Redis/DB 管理状态LLM 只做输入解析线上出现敏感内容未设置内容安全过滤检查输出端安全策略增加敏感词过滤和内容审核服务11. 最佳实践清单把 LLM 放在正确的位置基于目前所有讨论下面是一份可以直接用在项目评审和架构设计中的最佳实践清单。11.1 需求评审阶段先问“这个任务有没有唯一的正确答案”。如果有再问“错误成本有多高”。优先用传统代码实现确定性逻辑用 LLM 处理非确定性内容。对“LLM 可以做”和“LLM 应该做”划清界限前者是能力后者是决策。明确失败降级方案LLM 不可用时系统是降级为规则回答还是直接转人工。11.2 开发实现阶段所有 LLM 输出必须有校验器不能直接进入业务逻辑。涉及数据变更的操作LLM 最多生成语句草稿执行权交给人工和审批流。外部 API 调用必须设置超时、重试和熔断避免模型故障拖垮主服务。敏感数据在发送给外部模型前必须完成脱敏处理。11.3 上线运维阶段对 LLM 调用做全链路日志记录包含输入输出和耗时。建立离线评测集每次更换模型或修改 prompt 前跑一遍回归。监控模型的 answer rejection rate输出被校验拦截的比例这个指标上升往往意味着 prompt 或模型有问题。使用灰度发布新 prompt 或新模型先在 5% 流量上观察再逐步放量。12. 总结回到标题的问题“What LLMs Should Do”。我的回答是LLM 应该做生成者、建议者和转换者而不是决策者、计算者和执行者。把 LLM 放在“生成候选结果”的位置让它充分发挥语言理解、内容生成和意图识别方面的优势把“最终决策”的权力留给确定性代码、规则引擎和人工审核。这套边界看起来保守但恰恰是当前技术条件下把 LLM 稳定落地到生产环境的正确姿势。如果你现在正要开始一个 LLM 项目建议按照下面的路径走一遍先用本文的判断框架过滤需求判断哪些环节真正需要 LLM。从最小场景做起比如文档抽取、意图分类、代码生成辅助。在代码里搭好校验、日志、降级、评估四件套。小流量上线收集真实数据持续优化 prompt 和模型选择。“LLM 能做什么”是模型能力问题“LLM 应该做什么”是架构决策问题。前者是模型厂商和开源社区在推进的后者才是每个开发团队真正需要自己回答的。希望这篇文章能帮你找到更清晰的答案。建议收藏备用等下一次需求评审会上有人提出“这个功能用 LLM 能不能做”时对照这份清单你可能就能给出更准确的判断。