企业官网建设流程全解析

在业务项目里，我经常被问到同一个问题：这个需求，用大模型能不能做？需求方说要让 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 Generation，RAG）架构。先把企业内部的文档、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 调用量。

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_task=True, risk_level=2), evaluate_llm_task("订单金额计算", is_language_task=False, risk_level=3), evaluate_llm_task("删除过期数据", is_language_task=False, risk_level=3), evaluate_llm_task("客服对话摘要", is_language_task=True, risk_level=1), ] 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 是当前企业落地最多的模式，它解决的是模型知识过时和幻觉问题。核心流程是：

1. 把企业文档切片，用 Embedding 模型转成向量，存入向量数据库。
2. 用户提问时，把问题转成向量，从向量库里召回相关片段。
3. 将片段作为参考材料拼进 Prompt，让 LLM 根据材料生成回答。

这里 LLM 的角色从“知识源”变成了“阅读器”。它不再依赖记忆，而是根据给定的文档片段做归纳总结。这样即使文档更新，也不需要重新训练模型，只要更新向量库即可。

5.3 Workflow：用代码编排确定性流程

很多业务场景并不是“一次问答”，而是一系列步骤，比如：接收工单 -> 判断类型 -> 查询订单 -> 生成回复 -> 人工确认 -> 发送。这时更适合采用 Workflow 模式：

1. 规则引擎处理固定题型，直接走分支。
2. 函数工具负责查询数据库、调用内部 API。
3. LLM 只负责某个节点，比如判断用户意图、生成回复文本。
4. 编排层控制状态流转，保证每一步可追踪。

Workflow 的好处是确定性和可维护性。你可以对每个节点做单元测试，LLM 节点也能独立升级或替换，不会影响整体流程。

5.4 Agent：让 LLM 做有限度决策

Agent 模式让 LLM 具备工具调用能力，它可以决定“先查什么、再调什么”，然后循环执行直到完成目标。这种模式灵活度更高，但也更不可控，因为你无法预知模型每一步会做什么选择。

我的建议是：Agent 适合用在低风险、可重试、有校验的场景，比如个人知识助理、自动化测试、搜索引擎增强。对于生产系统里的核心链路，先不要全面放开 Agent，而是限定它可用的工具范围，并在关键节点增加人工确认。

5.5 模式选择对照表

6. 实战案例：工单智能分类与回复助手

6.1 需求分析与职责边界

假设现在要做一个客服工单助手，输入是用户提交的文本工单，输出是“工单分类”和“回复建议”。我们拿之前第 1 章的方法来分析：

工单分类本质上是一个意图识别任务，属于语言任务，风险等级为中低。工单回复建议需要结合固定模板和用户描述，语言生成部分适合 LLM，但最终发送前需要人工确认。因此架构上采用 Workflow 模式，流程是：

1. 对工单文本做预处理，去掉多余空格和无效字符。
2. 从本地模板库中检索最相似的模板作为参考。
3. 把模板和用户问题一起发给 LLM，让它输出分类和回复建议。
4. 代码对输出做格式校验，如果校验失败则返回规则生成的兜底文案。

在这个流程里，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，还要安装 requests：

pip 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": f"Bearer {config.API_KEY}", "Content-Type": "application/json", } payload = { "model": config.MODEL_NAME, "messages": messages, "temperature": 0.2, } try: resp = requests.post(url, headers=headers, json=payload, timeout=15) 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", encoding="utf-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(key=lambda x: x[0], reverse=True) 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_k=1) 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 上线前检查清单

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. 常见问题与排查清单

排查思路可以统一遵循“由外到内”的顺序：先确认网络和服务状态，再检查 Prompt 和入参，最后看模型版本和参数。不要一上来就重新训练模型，大多数问题出在数据流和参数配置上。

9. 工程经验与最佳实践

9.1 永远先定义职责边界

接到任何 LLM 需求，先写一行字：这个功能里，LLM 负责什么，代码负责什么。如果这一行字写不出来，说明需求还没想清楚。LLM 负责的部分，尽量限制在语言理解和生成；其他部分，全部由传统代码承担。

9.2 建立评估集

不要凭感觉判断模型输出好不好。准备一批固定测试用例，包含正常场景、边界场景、危险场景。每次换 Prompt、换模型、调参数，都跑一遍评估集，对比输出质量。这样你才能知道改动是变好了还是变坏了。

9.3 设计好降级方案

LLM 服务可能因为网络、限流、模型升级而不可用。上线前必须想清楚：模型挂了，业务能不能继续跑？降级策略可以包括：返回规则模板、提示稍后重试、转人工处理。

9.4 安全与权限最小化

给 LLM 应用配的工具和数据权限，应该坚持最小化原则。模型不需要访问的数据库，坚决不给；模型能执行的敏感操作，坚决不放开；涉及用户隐私的字段，做脱敏处理后再进入 Prompt。

9.5 从“辅助”开始，而不是“替代”

落地大模型项目时，最稳妥的方式是让它先做辅助角色：生成草稿、提供建议、辅助分类、批量预处理。人工负责最终决策。当业务方对模型输出有了足够信任，再逐步提高自动化比例。这既控制了风险，也能让大家在过程中积累对模型能力的正确认知。

做 LLM 应用开发，最值得记住的一点是：大模型是一个强大的“语言引擎”，但引擎不能自己决定方向，方向盘始终要握在系统和流程手里。搞清楚 What LLMs Should Do，比学会调用十个框架都重要。