开头先讲一个矛盾同一个大语言模型LLM有些任务让人惊喜有些任务让人想砸键盘。问题往往不在模型本身而在我们让它“做”的事不对。很多资料会把模型能力列成一张很长的清单能写代码、能翻译、能总结、能当Agent到了真实业务里我们缺的不是“能不能做”的清单而是“该不该做”的判断方法。What LLMs Should Do表面是能力问题实际是任务边界问题。1. 先放下“能不能做”回答“该不该做”1.1 能力边界不等于使用边界很多人评估一个模型能否用于业务方式是拿几条问题去跑一遍看回答像不像。这是体验不是评估。真实业务里一个任务需要的是重复跑、稳定输出、在无人盯情况下不出事。你让模型写一首诗写得一般也能接受你让模型批量处理用户留言错一条就需要解释。同一个模型在不同任务约束下使用价值完全不同。比如模型能“做”会议纪要也能“做”订单金额汇总。但会议纪要只要要点齐全人可以容忍部分措辞不完美订单金额只要错一位数后面所有流程都会被带偏。所以不能因为模型“认识这些词”就断定它适合这个任务。能力边界回答的是“模型能输出什么”使用边界回答的是“我们该让它负责什么”。1.2 LLM 真正适合的任务通常具备四个特征我一般用四个特征做初步筛选输入和输出都以文本/自然语言为主。结果可以被人工或程序快速校验。任务本质是生成、总结、改写、抽取、分类或格式转换。不要求绝对确定性、不依赖实时状态、不直接执行外部动作。以“把一段会议记录整理成待办事项”为例输入是文本输出是文本人可以几秒内判断待办是否合理模型可以抽取“负责人、时间、事项”这条任务适合交给LLM。反过来“统计订单总金额并生成报表”虽然输入输出也是文本但数字必须精确一旦出错影响很大。它不满足第4条不适合让模型直接输出最终数字更合适的方式是让模型从非结构化描述里抽取订单号、金额和日期再由代码完成计算。1.3 为什么先跑通再优化在任务边界判断上也成立很多团队选型时先比参数量、看跑分、看榜单然后才到业务里试。这里的成本很高。更实用的顺序是先拿20条真实业务样本用同一个提示词、同一个温度参数跑一遍人工看结果。如果方向不对先调整任务分解而不是急着换大模型。因为很多“模型不行”的结论其实是任务定义不清晰或提示词没有围绕任务结构写。比如只告诉模型“帮我把评论分类”不如告诉它“存在这三个分类每个分类定义是什么输出格式是JSON如果无法判断就返回unknown”。先在小样本上把任务边界说清楚再评估模型水平才是有意义的比较。2. 不该交给 LLM 的任务往往就坏在“看起来能做”2.1 幻觉不是模型故意骗人而是概率生成的下界要理解为什么有些任务不该交给LLM需要接受一个底层事实LLM是在做下一个token的概率预测。它擅长的是“在给定上下文中生成最自然的延续”而不是“在数据库中查询并返回唯一真理”。所以当模型缺少某个事实时它不会像搜索引擎一样说“查无此条”而是会用一个看起来合理的回答填补空白。这就是幻觉。可以把LLM想象成一位经验丰富但偶尔会自信出错的助手。你让它起草一份方案它很高效你让它直接对外发布最终版本就需要有人校对。这不是它能力低而是它的工作机制决定了它适合“生成草稿”不适合“终审发布”。凡是要求100%忠实于事实的任务都必须给模型提供可信来源或者把事实核对逻辑放到模型外面。2.2 用“错误代价”给任务分级在做任何决定前先评估“如果输出是错的会带来什么后果”低风险内容可以被人工快速修改例如营销文案、代码注释、会议纪要、非正式邮件草稿。中风险内容涉及结构化数据或下游流程但可以在执行前被程序拦截例如提取字段后由正则校验、生成SQL后在沙箱执行。高风险内容直接影响资金、权限、人身安全、法律条款或对外承诺例如自动退款、自动发版、自动发送合同。低风险任务可以直接交给LLM。中风险任务需要给LLM套一层“只生成、不执行”的护栏。高风险任务里LLM能做的只是提供参考决策权必须留给人。判断标准不是“模型能不能做到”而是“错了之后补救成本高不高”。2.3 很多人忽略的信号任务描述里有没有“总是”“所有”“一定”如果你的任务描述是“所有邮件都分类正确”“接口每次都返回相同格式”那么LLM不一定是最优选。它擅长处理模糊性和多样性而不是维持硬性约束。这时需要把任务拆成两个部分让LLM处理语义部分比如识别意图、抽取要素用代码处理规则部分比如字段校验、格式校验、唯一性检查。这个思路比逼模型变得更精确更可靠。一个常见教训不要因为框架自带 Agent 能力就把一个本来可以用固定 prompt 完成的分类任务拆成多轮自省。Agent 每多一步都意味着更高的延迟、更大的出错概率和更难的日志排查。3. 用 LLM 框架把“该做的事”固化下来3.1 框架不是在包装模型而是在维护任务的上下文现在提到 LLM 框架很多人会想到 LangChain、LlamaIndex 这类常见选择。最初我也觉得框架是在简化模型调用后来才发现框架真正解决的是上下文维护问题。在一次真实任务里模型需要知道的不是一句“帮我分类”而是背景信息、任务目标、字段定义、示例、输出格式、边界条件。如果每次都在业务代码里临时拼一个prompt迟早会混乱。框架把这些内容模板化并把模型调用、日志、重试、结构化输出等固定成可复用组件。但要注意框架本身不解决“该不该做”的问题。如果任务方向错了框架只是更快地跑到错误地方。所以不要一上来就搭一套完整的 Agent、RAG、记忆、工具调用系统先想清楚任务是否需要这些组件。3.2 提示词管理是框架的第一层回报提示词也是代码需要版本管理和测试。用框架可以把 system prompt、user prompt、示例放到独立目录或配置中心再用测试集做一个评估样板。例如一个分类任务先准备20条标注过的文本每次修改提示词后都跑一遍看准确率是上升还是下降。这样提示词就不再是某个开发者本地的“咒语”而是整个团队可以迭代的资产。这是 LLM 落地中最容易忽略也最值得投入的部分。很多人把精力放在选模型和调参数上忽略了 prompt 模板本身会随着业务变化而过期。一个稳定的评测集比换一个大模型更能保证长期效果。3.3 检索增强和工具调用本质是给 LLM 缩小责任半径很多复杂任务不适合直接交给LLM因为它们要求模型知道太多外部事实。一个典型解法是检索增强RAG把私有文档切成片段用向量库做相似度检索再把命中片段和用户问题一起交给LLM生成答案。这样一来LLM不用靠记忆回答它只需要基于“给定的片段”做总结和表达。这是 What LLMs Should Do 的一个正面案例让LLM负责它擅长的语言组织让检索系统负责事实召回。工具调用也一样。别让LLM直接完成“给用户发通知”这个动作而是让LLM决定“应该调用哪个工具并传什么参数”再由代码执行工具并校验结果。这样即使模型判断错了工具层还可以做权限校验和审批。框架的意义就是把这种“模型只做决策、代码负责执行”的分工固化下来。4. 部署形态先于任务判断本地还是 API和“是否同机”不是一回事4.1 一个常见问题的拆解ComfyUI 与 LLM 必须在同一台电脑上么在社区里看到过一个高频问题ComfyUI 与 LLM 必须在同一台电脑上么这个问题的背后不是两款软件怎么连而是对 LLM 部署形态的误解。直接回答不必需。ComfyUI 本身处理的是图像生成与图像处理对显卡和 CUDA 环境要求较高。如果只是想用它调用LLM来生成提示词、总结标签或做画质评估LLM完全可以部署在另一台机器上通过 HTTP API 或局域网端口调用。反过来如果非要让两个服务共享同一块 GPU才需要关心显存是否够大、是否会互相抢占、会不会频繁 OOM。所以正确的提问方式不是“必须同机吗”而是“我的资源约束和服务调用关系是什么”。4.2 三种部署形态分别适合什么场景全远程 API本地只发请求。适合快速验证、低频调用、不想维护模型服务。缺点是有网络依赖、数据要经过外部服务、按量付费。本地模型服务在一台机器上部署一个模型服务例如通过 ollama、vLLM 这类工具然后把 API 暴露给局域网或其他应用。适合对隐私有要求、需要高频内网调用、或者要控制成本。同进程内嵌加载在同一个应用里把模型加载进来不走网络。适合完全离线的小型任务但资源耦合度高多项目共用时容易互相影响。在“ComfyUI 与 LLM 是否同机”这个具体场景里最常见的是第二种LLM 作为独立服务运行ComfyUI 通过 HTTP 调用。这也是更合理的架构因为图像生成和文本生成的时间、显存需求不一样拆开后可以单独扩容出问题时也更好排查。4.3 本地部署时真正要盯的是资源约束和生效质量本地跑LLM不等于把模型文件下载下来就万事大吉。显存和内存决定了你最多能跑多大参数量、多少并发上下文长度决定了单次任务可以喂多少材料量化精度会影响占用和生成质量温度参数则影响稳定性和创造性。如果业务任务是分类、抽取这类低随机性任务temperature 一般直接设为0如果是在做文案生成可以适当调高。这里最容易踩坑的是“模型能加载但效果达不到预期”。本地7B模型在一些简单分类上可能够用但如果要做复杂的逻辑推理或多文档总结效果就会明显下滑。此时别急着调提示词先确认是不是模型能力上限的问题再考虑升级模型或切回 API。判断方法还是一样固定一批小测试集对比不同模型在相同提示词下的输出质量。5. 判断任务该不该交给 LLM 的一套最小流程5.1 五步评估法把前面的内容收敛成一个可复用流程写下任务描述标出输入是什么、输出是什么。判断输出是否以文本/自然语言为主如果不是考虑拆解让 LLM 只做语义部分。评估错误代价如果错了能否在低成本的条件下被人或程序发现并修复。确认是否需要外部事实或实时状态如果需要先规划检索或工具调用而不是让模型硬记。准备20条真实样本作为验收集用固定提示词和固定参数跑一遍人工判断通过率。如果第2、3、4步都提示“不适合”就不要硬上。如果通过了再用最小流程验证。5.2 一个示例从客户评论分类到摘要生成假设要处理“客户评论分类并生成摘要”。输入是文本评论输出是“分类摘要”这是典型的文本任务。错误代价分类错误或摘要不准确运营人员可以在发送反馈前人工抽查问题不大。外部事实不需要实时状态只需要模型自身语义理解能力。验收样本从历史评论里随机抽20条先人工标好分类标签和期望摘要。然后开始第一次测试。提示词里写清楚分类定义、输出格式最好加一两个示例。temperature 设为0。跑完20条后人工判断通过率。如果通过率达到90%就可以逐步扩大到一个更大的验证集如果没达到先看失败样本判断是分类定义模糊、输出格式不稳定还是评论本身太复杂再针对性调整提示词或模型。示例结构可以这样# 示例结构用统一函数调用本地或远程 LLM 服务 def run_llm(system_prompt: str, user_prompt: str, temperature: float 0.0): # 内部实现负责调 API、超时、日志记录 response call_llm_service( messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], temperaturetemperature, ) return response注意这是示例结构不是某个框架的官方 API。真实项目里还要在这里加上版本号和输出校验。5.3 从最小流程到批量化最后才是工程化单次跑通并不等于能稳定批量使用。一个任务验证通过后还需要做三件事给每次调用加日志记录模型版本、prompt版本、耗时、输出结果和校验结果。加失败重试和降级策略。例如网络超时重试两次仍然失败就写入待人工处理队列。把输入输出放到固定的目录或表结构里方便审计和回溯。如果后续要长期使用还要关注 prompt 测试集维护。随着业务变化初始的20条样本会过期需要定期补充新样本。这个部分看起来琐碎但在生产环境里它的价值比“换一个更强模型”更大。5.4 输出不稳定的前四个检查点如果已经把一个任务交给 LLM但输出时好时坏建议按顺序排查输入端检查消息结构、编码、上下文长度和权限设置。很多空输出或报错来自请求格式不对。提示词看是否给了足够的示例和明确的输出格式。如果只是加一句“要准确”效果通常有限。采样参数分类/抽取任务先确认 temperature 是否设为0同时检查 top_p、max_tokens 是否限制了输出长度。模型与框架版本同一个模型在不同兼容层下可能有差异改了 prompt 模板或升级了框架版本也会影响结果。这个排查顺序已经能解决大部分“模型不稳定”的困惑。如果还没有解决再往业务数据观察看是不是输入分布超出了预期。回到开头的那个问题What LLMs Should Do。我的答案是LLM 应该承担那些“由语言驱动、允许校验、错误成本可控”的任务而不是成为一个被强塞一切需求的万能盒子。能力边界会随着模型迭代快速变化但任务边界判断方法基本不会变。以后遇到一个“能不能用 LLM 做”的问题先别急着上框架、调参数拿20条真实样本跑一遍算一下错误代价再决定让它做什么。这一步想清楚了后面的工程化才有意义。