在业务项目里我经常被问到同一个问题这个需求用大模型能不能做需求方说要让 AI 自动回复所有工单让 AI 算出员工工资甚至让 AI 直接修改线上数据库。如果你是后端开发者肯定知道这种问法本身就有问题。真正要回答的不是“能不能”而是“应不应该”。大模型不是一块万能补丁它有自己的能力边界也有它不应该承担的任务。如果边界没有想清楚项目大概率会变成成本高、准确率低、难维护的“伪 AI 系统”。这篇文章我想围绕一个核心话题展开What LLMs Should Do也就是大语言模型在真实业务系统中应该做什么、不应该做什么。我会先从能力边界讲起再给出一个可落地的任务判断框架然后结合一个“工单智能分类与回复助手”的完整实战案例把 LLM 放进架构里看它到底该承担哪个环节。最后补充框架选型、本地部署与常见问题适合正在做 LLM 落地的后端开发者、架构师以及刚开始接触大模型应用的新手。1. 为什么需要定义 LLM 应该做什么1.1 从一场需求评审说起之前参与过一个客服工单系统的改造需求方一开始的想法很简单把所有工单丢给大模型让 AI 自动分类、自动回复、自动跟踪结果。听起来很省事但拆开需求后发现工单里大概有 60% 是固定规则就能处理的比如网络不通就引导重启、密码重置走统一流程20% 需要查询订单系统拿到实时状态真正需要大模型发挥语言理解和生成能力的大概只有 20%。如果一开始不划定界限直接把全部工单交给 LLM会带来几个问题调用成本高每个工单都走一次模型推理延迟不可控用户等不起更关键的是大模型属于概率性输出可能出现一本正经的错误回复一旦回复错了责任很难追。我们后来把规则引擎、订单查询、LLM 生成三段拆开整体成本和准确率才真正达到可交付的状态。这个例子说明在引入大模型之前最重要的一步不是“选模型”而是定义 LLM 的职责边界。这也是本文标题想表达的意思我们需要知道的不是 LLM 能做什么而是它应该做什么。1.2 LLM 擅长的是“语言任务”不是“业务任务”大语言模型本质上是一个基于海量文本训练出来的概率语言模型它做的是根据上下文预测下一个 token从而生成一段最“像样”的文本。它能理解问题、重组信息、生成摘要、编写代码给人一种很聪明的感觉。但这种聪明建立在统计规律上不是建立在业务事实和逻辑约束上。举个例子你问模型“3.27 和 3.31 哪个大”它大概率能答对但如果你让它算“一批订单的总金额然后做分账”它可能把数字算错还可能编出一个不存在的订单号。原因很简单模型擅长的是“语言流畅性”而不是“确定性计算”和“对实时数据的访问”。业务系统需要的往往是确定性、可审计性和实时性这些恰恰是大模型天生不擅长的。所以在设计系统时我们通常把业务任务拆成两层语言子任务和业务子任务。语言子任务包括理解用户意图、生成回复文案、抽取关键信息业务子任务包括查询数据库、执行计算、触发流程、落库。LLM 只承担语言子任务其余部分交给传统代码和规则系统。这个拆分听起来简单但实践中很容易被忽略。1.3 本文的讨论范围考虑到 LLM 技术迭代非常快本文不会纠结于某个具体模型或版本而是讨论相对稳定的方法论。你会看到LLM 的核心能力地图、不该承担的任务清单、任务适配判断框架、生产系统中常见的架构模式以及一个可以运行在本地 Python 环境的实战示例。代码方面我使用 OpenAI 兼容的接口风格同时提供 Mock 模式这样即使你没有 API Key也能把整个流程跑通。具体的模型名、接口地址需要按你实际使用的服务商来调整本文重点是让你理解“在哪些环节放 LLM在哪些环节不放 LLM”。2. LLM 的核心能力地图2.1 文本理解与生成这是大模型最基础也是最擅长的能力。你给它一段话它可以总结要点、改写措辞、扩写细节也可以根据指令生成一段符合要求的文案。常见的场景有智能客服的回复话术生成、营销邮件的标题优化、产品文案改写、会议纪要整理。这类任务的特点是输入是自然语言输出也是自然语言没有严格的正确与错误只有“好不好”的差别。实际项目中我建议把这类任务当作“辅助生成”而不是“最终决策”。比如让 LLM 先生成回复草稿再由人工审核后发送。这样既发挥了模型的速度又避免了概率性输出带来的风险。2.2 摘要、改写与翻译摘要和改写是 LLM 性价比最高的应用领域。传统抽取式摘要只能从句子里挑关键词而大模型可以做语义理解把一段长文压缩成几个要点或者把技术文档改写成面向普通用户的说明。这类任务的判断标准比较主观出错的代价也比较低。即使模型漏掉一个次要信息也不会造成严重后果。因此非常适合作为大模型落地的第一个试点项目。一个很典型的用法是把客服聊天记录输入 LLM让它输出“客户诉求、情绪状态、待办事项”三个结构化字段。虽然我们希望拿到结构化结果但本质上仍然属于文本理解LLM 能处理得很好。2.3 知识问答与检索增强知识问答是大模型最广为人知的能力但要注意直接用模型内部参数里的知识做问答会出现两个问题一是知识过时二是会产生幻觉。也就是说模型可能自信地告诉你一个错误信息而且说得很有条理。所以生产环境更推荐检索增强生成Retrieval-Augmented GenerationRAG架构。先把企业内部的文档、FAQ、知识库做切片和向量化用户提问时先从知识库检索出相关片段再把片段拼进 Prompt 中让模型生成答案。这样模型不用“背”知识只需要“理解和转述”准确率和可解释性都会高很多。关于 RAG我会在第 6 章给出一个简化但可运行的实现思路。你需要理解的关键点是LLM 的职责是“基于给定资料生成回答”而不是“凭记忆回答”。2.4 代码生成与解释代码生成是开发者最关心的能力之一。LLM 可以根据需求描述生成函数、写单元测试、解释一段看不懂的逻辑甚至帮忙做代码评审。它的价值在于把重复性的编码工作自动化或者充当一个随时在线的小白友好助手。但这类场景同样需要设置边界模型生成的代码不能直接上生产必须经过编译、测试、人工 review。你可以让它生成 80% 的代码但最后 20% 的边界处理和安全性校验必须由人工完成。很多团队把 LLM 接入 IDE 后效率确实提高了但出问题往往不是因为模型写得不对而是因为开发者过于信任模型的输出。2.5 意图识别与信息抽取意图识别是大模型相对传统 NLU 的一个明显优势。传统做法要准备大量训练数据定义好意图标签然后训练分类模型。现在只需要在 Prompt 里描述意图集合模型就能把用户输入归到对应类别甚至抽取时间、地点、金额等实体信息。这个能力很适合用来做工单分诊、对话入口、信息录入自动化。相比传统模型大模型少了很多训练成本也更容易扩展新意图。但要注意的是意图分类结果仍然需要落回代码逻辑再决定后续走什么流程。模型负责“理解用户想干什么”系统负责“真正去干这件事”。3. LLM 不应该承担的任务3.1 精确计算与强逻辑我在第 1 章已经提过大模型的本质是“概率生成”所以它不适合做精确计算。虽然像“123 456”这种简单计算它能答对但一旦涉及复杂公式、金额分账、税率计算、数据聚合错误率会明显上升。生产环境中的金额、库存、日期计算必须交给代码完成。如果你确实需要 LLM 分析数据正确做法是让 LLM 生成查询语句或者执行计划再由代码去查询和计算最后让 LLM 做结果解读。3.2 实时查询与权威数据大模型没有数据库连接能力也没办法主动获取最新订单状态。你问它“当前服务器负载多少”它不可能知道。所以涉及实时数据的问题不能指望模型回答。更好的模式是把实时查询封装成工具函数让 LLM 在需要时调用。模型先判断“用户想查什么”然后触发代码去查数据库或调用接口再把查询结果整理成自然语言。3.3 不可逆操作与安全边界删除数据、修改权限、转账、封禁账号这一类不可逆或高影响操作不应该由 LLM 自动执行。原因是模型输出没有 100% 的确定性一旦指令理解出错后果难以挽回。即便要让 LLM 参与也应该采用“人机确认”的流程LLM 生成操作指令系统展示给操作人确认确认后才执行。从安全角度来看这一步不能省。3.4 高并发与低延迟接口大模型推理的延迟通常在几百毫秒到几秒不等资源占用也比较高。如果一个接口面向用户侧且要求 200 毫秒以内返回直接把大模型放在主链路里通常不合适。解决思路有两种一是用传统算法和小模型扛住大部分低延迟请求LLM 只处理兜底或复杂场景二是使用语义缓存把常见问题提前算好命中缓存直接返回降低 LLM 调用量。任务类型不适合的原因推荐的替代方案金额计算、日期计算概率输出缺少确定性代码计算LLM 只做解释实时库存、订单状态模型不持有最新数据API/数据库查询LLM 做语义封装删除数据、转账、改权限不可逆存在误判风险人机确认 最小权限执行高并发、低延迟接口推理耗时高成本高规则/缓存/小模型兜底长链路事务状态管理能力弱Workflow 编排LLM 作为节点4. 任务适配判断框架接到需求怎么快速决策4.1 两个关键维度任务特征与风险等级面对一个具体需求我不建议直接纠结“用哪个模型”而是先回答两个问题第一个问题是这个任务本质上是语言任务还是逻辑任务如果输入输出都是自然语言允许模糊和多样那就是语言任务如果结果必须精确、必须可验证那就是逻辑任务。第二个问题是如果模型出错影响范围有多大影响越大风险越高。把这两个维度放在一起可以得到一个简单判断高风险 逻辑任务不要用 LLM低风险 语言任务可以优先用 LLM中间地带常用混合架构比如 LLM 生成草稿规则引擎做校验。4.2 一个可执行的最小判断函数下面是一个很精简的判断函数用于需求评审阶段快速给结论。它不代表最终架构只是为了把模糊的讨论变成可以衡量的输入。def evaluate_llm_task(name: str, is_language_task: bool, risk_level: int) - dict: is_language_task: True 表示任务本质是语言理解和生成 risk_level: 1 表示低风险2 表示中风险3 表示高风险 if not is_language_task and risk_level 2: suggestion 不适合使用 LLM建议用规则或代码实现 elif is_language_task and risk_level 3: suggestion 可以使用 LLM但必须加入人工审核或二次确认 elif is_language_task and risk_level 2: suggestion 适合使用 LLM可采用生成后抽查的方式 else: suggestion 建议采用混合方案语言部分用 LLM逻辑部分用代码 return { task: name, is_language_task: is_language_task, risk_level: risk_level, suggestion: suggestion, } tasks [ evaluate_llm_task(工单自动回复, is_language_taskTrue, risk_level2), evaluate_llm_task(订单金额计算, is_language_taskFalse, risk_level3), evaluate_llm_task(删除过期数据, is_language_taskFalse, risk_level3), evaluate_llm_task(客服对话摘要, is_language_taskTrue, risk_level1), ] for t in tasks: print(t)运行结果{task: 工单自动回复, is_language_task: True, risk_level: 2, suggestion: 适合使用 LLM可采用生成后抽查的方式} {task: 订单金额计算, is_language_task: False, risk_level: 3, suggestion: 不适合使用 LLM建议用规则或代码实现} {task: 删除过期数据, is_language_task: False, risk_level: 3, suggestion: 不适合使用 LLM建议用规则或代码实现} {task: 客服对话摘要, is_language_task: True, risk_level: 1, suggestion: 适合使用 LLM可采用生成后抽查的方式}这个函数的价值不在算法而在于它强迫你把“是否适合 LLM”这个问题拆成“任务类型”和“风险等级”两个维度。很多架构争议其实是在这两个维度上没达成一致。4.3 伪需求与隐藏的真实问题需求评审中还有一个常见现象用户提出“要一个 AI 功能”但真正的问题根本不需要大模型。比如有人说要智能客服深入聊下去发现用户只是希望“未读消息能自动带上常用 FAQ 链接”这用简单的规则匹配就能做到。遇到这种情况不要急着说服对方“用不用大模型”而是先用实际问题倒推用户当前的痛点是回复慢、知识分散、还是人工成本高如果只是回复慢规则模板加快捷键可能就够了如果是知识分散优先做知识库检索如果确实需要生成个性化回复再引入 LLM。判断框架最终要回答的是“LLM 应该做什么”而它天生就只能做一件事在语言世界中提供智能。凡是语言之外的都应该交给代码和系统。5. 生产系统中的典型架构模式5.1 直接调用只做一次生成最简单的模式是直接调用 LLM 接口。前端输入一段文本后端把 Prompt 发给模型拿到结果后返回。适合单轮问答、文案生成、标题润色等场景。但它必须搭配两个机制超时控制和降级方案。大模型服务可能因为负载过高而变慢或报错如果主流程直接依赖它用户就会感知到故障。所以要在代码层面设置超时时间超时后返回兜底内容。5.2 RAG给 LLM 接上外部知识RAG 是当前企业落地最多的模式它解决的是模型知识过时和幻觉问题。核心流程是把企业文档切片用 Embedding 模型转成向量存入向量数据库。用户提问时把问题转成向量从向量库里召回相关片段。将片段作为参考材料拼进 Prompt让 LLM 根据材料生成回答。这里 LLM 的角色从“知识源”变成了“阅读器”。它不再依赖记忆而是根据给定的文档片段做归纳总结。这样即使文档更新也不需要重新训练模型只要更新向量库即可。5.3 Workflow用代码编排确定性流程很多业务场景并不是“一次问答”而是一系列步骤比如接收工单 - 判断类型 - 查询订单 - 生成回复 - 人工确认 - 发送。这时更适合采用 Workflow 模式规则引擎处理固定题型直接走分支。函数工具负责查询数据库、调用内部 API。LLM 只负责某个节点比如判断用户意图、生成回复文本。编排层控制状态流转保证每一步可追踪。Workflow 的好处是确定性和可维护性。你可以对每个节点做单元测试LLM 节点也能独立升级或替换不会影响整体流程。5.4 Agent让 LLM 做有限度决策Agent 模式让 LLM 具备工具调用能力它可以决定“先查什么、再调什么”然后循环执行直到完成目标。这种模式灵活度更高但也更不可控因为你无法预知模型每一步会做什么选择。我的建议是Agent 适合用在低风险、可重试、有校验的场景比如个人知识助理、自动化测试、搜索引擎增强。对于生产系统里的核心链路先不要全面放开 Agent而是限定它可用的工具范围并在关键节点增加人工确认。5.5 模式选择对照表模式适用场景优点风险直接调用文案生成、单轮问答实现简单幻觉、超时RAG企业知识库问答知识可更新幻觉减少检索质量影响结果Workflow客服工单、审批流程可控、可测试灵活度低Agent复杂任务拆解自主性强不可控、成本高6. 实战案例工单智能分类与回复助手6.1 需求分析与职责边界假设现在要做一个客服工单助手输入是用户提交的文本工单输出是“工单分类”和“回复建议”。我们拿之前第 1 章的方法来分析工单分类本质上是一个意图识别任务属于语言任务风险等级为中低。工单回复建议需要结合固定模板和用户描述语言生成部分适合 LLM但最终发送前需要人工确认。因此架构上采用 Workflow 模式流程是对工单文本做预处理去掉多余空格和无效字符。从本地模板库中检索最相似的模板作为参考。把模板和用户问题一起发给 LLM让它输出分类和回复建议。代码对输出做格式校验如果校验失败则返回规则生成的兜底文案。在这个流程里LLM 只负责“理解”和“生成”不负责“决策”和“执行”。6.2 项目结构我用纯 Python 标准库实现完整的可运行示例唯一可选依赖是 requests用于真实调用 API。如果你没有 API Key可以开启 Mock 模式。ticket_assistant/ ├── main.py # 主流程 ├── config.py # 配置项 ├── llm_client.py # LLM 调用与 Mock 实现 ├── retriever.py # 本地模板检索 └── tickets.json # 测试工单数据6.3 环境准备本文示例使用 Python 3.10不需要安装额外框架。如果你要调用真实大模型接口需要准备一个 OpenAI 兼容的服务地址和 API Key还要安装 requestspip install requests如果你只是本地验证流程可以直接使用 Mock 模式代码会生成模拟回复。6.4 配置文件config.py# 文件路径ticket_assistant/config.py MODEL_NAME your-model-name # 实际模型名按服务商调整 API_BASE https://your-llm-endpoint/v1 # OpenAI 兼容接口地址 API_KEY your-api-key # 鉴权密钥 USE_MOCK True # True 表示不调用真实接口 # 本地模板库 TEMPLATE_FILE templates.json这里使用 USE_MOCK 开关方便你在没有真实环境的条件下先跑通流程。上线时把 USE_MOCK 改为 False并填入真实接口参数。6.5 LLM 客户端llm_client.py这个模块封装了请求逻辑和 Mock 逻辑。真实模式下我使用 requests 发送 POST 请求到 OpenAI 兼容的/chat/completions接口Mock 模式下直接返回一组固定的模拟数据。# 文件路径ticket_assistant/llm_client.py import json from typing import List, Dict import config def _build_mock_response(prompt: str) - str: # 简单模拟根据 prompt 中是否出现关键词来生成返回结果 if 网络 in prompt or 无法连接 in prompt: return 分类网络故障\n建议请用户尝试重启路由器并检查网线连接。 if 密码 in prompt or 账号 in prompt: return 分类账号问题\n建议引导用户通过自助重置密码功能修改密码。 return 分类其他\n建议请先记录用户描述并转交相关技术组处理。 def chat(prompt: str, messages: List[Dict[str, str]]) - str: 调用 OpenAI 兼容接口。 如果 USE_MOCK 为 True则返回本地模拟结果不会发起网络请求。 if config.USE_MOCK: return _build_mock_response(prompt) url f{config.API_BASE}/chat/completions headers { Authorization: fBearer {config.API_KEY}, Content-Type: application/json, } payload { model: config.MODEL_NAME, messages: messages, temperature: 0.2, } try: resp requests.post(url, headersheaders, jsonpayload, timeout15) resp.raise_for_status() data resp.json() return data[choices][0][message][content] except Exception as exc: # 网络异常或服务异常时返回兜底文案 return f分类其他\n建议暂时无法获取智能回复请人工介入处理。异常信息{exc}这里的关键点是异常兜底。真实项目中LLM 服务随时可能超时或报错所以一定要在调用层捕获异常并返回降级文案。6.6 本地模板检索retriever.py为了让 LLM 在生成回复时有参考依据我们从本地模板库中检索最相似的模板。这里我用一个很简单的“字符交集”算法模拟语义检索真实项目中可以替换成向量检索。# 文件路径ticket_assistant/retriever.py import json from typing import List, Dict def load_templates(path: str) - List[Dict[str, str]]: with open(path, r, encodingutf-8) as f: return json.load(f) def tokenize(text: str) - set: # 简单的字符分词中文场景下按字符切分 return set(list(text)) def _similarity(a: str, b: str) - float: tokens_a tokenize(a) tokens_b tokenize(b) if not tokens_a or not tokens_b: return 0.0 return len(tokens_a tokens_b) / len(tokens_a | tokens_b) def retrieve_template(query: str, templates: List[Dict[str, str]], top_k: int 1) - List[Dict[str, str]]: scored [] for t in templates: score _similarity(query, t[question]) scored.append((score, t)) scored.sort(keylambda x: x[0], reverseTrue) return [t for _, t in scored[:top_k]]这里用集合相似度只是为了演示真实生产建议使用正规的 Embedding 模型加向量数据库效果会稳定得多。6.7 模板数据创建 templates.json[ { question: 网络无法连接怎么办, category: 网络故障, answer: 请先重启路由器并确认网线是否插好。如果仍然无法连接请提供网络报错截图。 }, { question: 登录密码忘记了, category: 账号问题, answer: 请通过登录页的忘记密码入口重置密码重置后使用新密码登录。 }, { question: 订单一直没有发货, category: 订单问题, answer: 请提供订单号我们会在一个工作日内为你确认发货状态。 } ]这个文件作为参考语料会帮助 LLM 理解相似问题的回复风格。6.8 主流程main.py主流程负责串联整个 Workflow加载配置 - 读取测试工单 - 检索模板 - 构造 Prompt - 调用 LLM - 输出结果。# 文件路径ticket_assistant/main.py import json import config import llm_client import retriever def process_ticket(ticket_text: str) - None: print( * 50) print(用户工单, ticket_text) print(- * 50) templates retriever.load_templates(config.TEMPLATE_FILE) matched retriever.retrieve_template(ticket_text, templates, top_k1) context if matched: t matched[0] context f参考模板分类{t[category]}\n参考模板回复{t[answer]} prompt f你是一个工单助手。请根据用户工单内容输出工单分类和回复建议。 要求 1. 分类必须从以下范围选择网络故障、账号问题、订单问题、其他。 2. 回复建议必须简洁、友好不超过两句话。 3. 如果提供了参考模板可以借鉴模板的表达方式。 参考模板 {context} 用户工单 {ticket_text} messages [ {role: system, content: 你是一个严谨的客服工单助手。}, {role: user, content: prompt}, ] result llm_client.chat(prompt, messages) print(LLM 输出) print(result) print( * 50) if __name__ __main__: test_tickets [ 我的网络一直连不上显示错误代码 651, 忘记登录密码了想重新设置, 下单三天了还没发货请问什么时候能到, 我想换个套餐有什么推荐吗, ] for ticket in test_tickets: process_ticket(ticket)6.9 运行与验证在项目目录下执行cd ticket_assistant python main.py开启 Mock 模式时运行输出类似 用户工单 我的网络一直连不上显示错误代码 651 -------------------------------------------------- LLM 输出 分类网络故障 建议请用户尝试重启路由器并检查网线连接。 这里需要说明的是Mock 模式的输出是本地规则生成的仅用于验证流程。切换到真实模型后你会发现回复风格更自然并且能参考模板语料生成更贴合业务的回答。真实环境做验证时建议多准备几组测试文本覆盖每个分类同时准备一些“模型要拒绝回答”的样本比如用户要求删除后台数据。你要确认模型不会直接答应执行而是返回“请通过后台操作”之类的安全话术。6.10 上线前检查清单检查项说明LLM 输出格式是否稳定建议让模型输出 JSON并在代码中解析校验超时与重试是否配置设置合理超时时间失败后走兜底回复敏感词与操作限制模型不能直接承诺退款、赔偿等敏感内容人工审核是否保留高风险回复必须有人工确认环节日志与追踪是否完整记录输入、输出、模型版本、耗时成本和调用量评估统计每类工单的模型调用成本7. 框架选型、本地部署与热门问题7.1 为什么需要 LLM 框架现在提到 LLM 应用很多人会想到 LangChain、LlamaIndex 这类框架。它们的价值在于封装了 Prompt 模板、向量检索、工具调用、Agent 循环这些常见模式让你少写很多胶水代码。尤其是做知识库问答、Agent 应用时框架能明显缩短开发时间。但框架也有成本抽象层多出了问题不好排查版本更新快接口容易变化。我个人的建议是如果你的场景只是单次调用、简单 RAG不一定非要引入重型框架用 requests 加向量数据库就够了。当场景上升到复杂 Agent、多工具调用、需要记忆和规划时再考虑框架。7.2 本地部署还是 API 服务这是一个经常被拿到台面上讨论的问题。本地部署的优点是数据不出内网可控性强但运维成本高需要显卡资源而且模型能力往往落后于商业 API 服务。API 服务的优点是模型能力强、部署快、按量付费但需要考虑数据合规和调用成本。选择标准通常是这样如果数据敏感性强必须走本地私有化部署如果只是内部工具或非敏感业务优先用 API 服务跑通流程当调用量上来后再评估本地推理是否更划算。另外模型选型不要盲目追求“最大参数”。很多业务场景里小模型配合好的 Prompt 和 RAG效果已经足够而成本会低一个数量级。7.3 热门追问ComfyUI 与 LLM 必须在同一台电脑上么这里顺带回答一个经常出现的问题ComfyUI 与 LLM 是否必须在同一台电脑上。先说结论不必须。ComfyUI 是一个可视化工作流工具主要用于 Stable Diffusion 等图像生成模型。LLM 是语言模型服务二者一个是图像链路一个是文本链路。如果你只是想在一个工作流里先用 LLM 优化提示词再交给 ComfyUI 出图两者之间走 HTTP 接口通信即可完全可以部署在不同机器上。什么情况下建议放在同一台电脑或同一局域网主要看延迟和带宽。如果需要在 ComfyUI 的节点里频繁调用 LLM跨公网调用会有明显网络延迟影响交互体验。如果本地显卡资源紧张LLM 和图像模型分开部署反而更好因为二者都是显存大户放在同一台机器上可能互相抢占资源。我的建议是个人实验阶段ComfyUI 和 LLM 可以在同一台机器上部署生产环境或资源充足的团队按业务链路拆分服务通过内部 API 通信并做好监控和鉴权。8. 常见问题与排查清单问题现象常见原因解决思路LLM 回复格式不稳定Prompt 没有明确约束温度过高使用 JSON 输出模式解析失败后重试回答内容出现幻觉没有提供参考资料接入 RAG限制模型只基于给定材料回答接口响应超时模型负载高或 Prompt 过长设置较短超时启用缓存或降级规则同一问题回答不一致温度参数过高将 temperature 调低至 0 到 0.3成本迅速增长所有请求都走 LLM先做意图筛选简单问题走规则和模板本地显存不足模型参数过大选用量化版本、小模型或将服务拆分到多机排查思路可以统一遵循“由外到内”的顺序先确认网络和服务状态再检查 Prompt 和入参最后看模型版本和参数。不要一上来就重新训练模型大多数问题出在数据流和参数配置上。9. 工程经验与最佳实践9.1 永远先定义职责边界接到任何 LLM 需求先写一行字这个功能里LLM 负责什么代码负责什么。如果这一行字写不出来说明需求还没想清楚。LLM 负责的部分尽量限制在语言理解和生成其他部分全部由传统代码承担。9.2 建立评估集不要凭感觉判断模型输出好不好。准备一批固定测试用例包含正常场景、边界场景、危险场景。每次换 Prompt、换模型、调参数都跑一遍评估集对比输出质量。这样你才能知道改动是变好了还是变坏了。9.3 设计好降级方案LLM 服务可能因为网络、限流、模型升级而不可用。上线前必须想清楚模型挂了业务能不能继续跑降级策略可以包括返回规则模板、提示稍后重试、转人工处理。9.4 安全与权限最小化给 LLM 应用配的工具和数据权限应该坚持最小化原则。模型不需要访问的数据库坚决不给模型能执行的敏感操作坚决不放开涉及用户隐私的字段做脱敏处理后再进入 Prompt。9.5 从“辅助”开始而不是“替代”落地大模型项目时最稳妥的方式是让它先做辅助角色生成草稿、提供建议、辅助分类、批量预处理。人工负责最终决策。当业务方对模型输出有了足够信任再逐步提高自动化比例。这既控制了风险也能让大家在过程中积累对模型能力的正确认知。做 LLM 应用开发最值得记住的一点是大模型是一个强大的“语言引擎”但引擎不能自己决定方向方向盘始终要握在系统和流程手里。搞清楚 What LLMs Should Do比学会调用十个框架都重要。