企业官网建设流程全解析

1. "万能钥匙"陷阱：为什么我们总想把一切都交给LLM

上个月我参与评审了一个内部工具项目，团队花了两周时间把工单自动分类功能接上了大模型，演示效果确实惊艳——一段模糊描述扔进去，模型能输出工单类型、紧急程度、负责部门，甚至还能附一句处理建议。当时会议室里一片叫好，领导直接拍板："以后凡是搞不定的分类需求，统一走LLM。"

结果系统上线第三天就出问题了。这个分类接口每天的调用量在高峰期达到几十万次，每次几十到几百毫秒的延迟直接把网关拖到告警，账单也在肉眼可见地疯涨。更要命的是，模型在个别边界case上会自由发挥，把"账号无法登录"误判成"密码重置"，运维同事拿着错误工单排查了半天，差点酿成事故。

这就是我今天想聊的问题。过去一年，我见过太多团队把大模型当成一块万能砖，哪儿需要往哪儿搬。口号是"用AI解决一切"，实际上是在用一套概率系统去硬扛那些本该用精准规则或专用决策模型解决的问题。

先说清楚一个真相：LLM确实很强大，它是目前我们手里语义理解能力最强的工具，甚至没有之一。但它的强大集中在"模糊输入到模糊输出"的场景——你说个大概，它还给个大概，双方都能接受这种不确定性。然而一旦负载的本质是"精确输入到精确输出"，比如结构化数据抽取、固定规则判断、数值计算、状态机流转，LLM的能力不仅帮不上忙，反而会添乱。

很多人没想明白一个朴素的道理：选模型不是在选"谁更聪明"，而是在选"谁的错误代价更小"。一个分类任务错了，如果只是推荐位少推一个商品，成本为零；但如果错在财务审批、错在权限判定、错在线上故障定级，一次错误可能抵得上十万美元的API费用。这时候，你需要的不是更强的推理能力，而是更确定的执行能力——这就是专用决策模型的主场。

所以这篇文章没有打算劝退谁，也不是说LLM不好。我的核心观点是：LLM和专用决策模型不是替代关系，而是分工关系。下面我会从能力边界、量化判据、典型负载、混合架构几个角度，聊聊到底什么样的负载该果断放弃LLM，以及怎么在工程上优雅地切换过去。

2. LLM的能力边界：直觉过人，但算力不会白给

聊选型之前，先要把LLM的本质看清楚。大模型的底层机制是"根据上文预测下一个最可能的token"，它从头到尾做的都是概率采样，而不是逻辑推演。这意味着三个先天特征。

第一，它没有"计算器"能力。让模型做三位数乘三位数它经常算错，原因不是模型笨，而是它压根不走乘法逻辑，它是在"猜"那个最像正确答案的字符串。你让它写一段快速排序的代码，它能写得有模有样，但你要它精确算出某个请求在队列里的等待时间，它只能给你一个"大概差不多"的数字。

第二，它没有持久状态。每次调用都是独立的，模型不知道上次给用户推荐了什么，也不知道这个工单五分钟前已经流转过一轮。你要它维护一个"对话中已经完成哪些步骤"的状态机，纯属强人所难——这本质上是应用层该干的事。

第三，它的输出不可证明。你可以用规则、用正则、用schema校验去约束它输出json格式，但你无法证明它在某个边界case上一定给出正确分类。更麻烦的是，同样一句话换个问法，它可能给出完全不同的判断，这种"创造性"在创作场景是优点，在决策场景就是灾难。

反过来看专用决策模型。这里的"专用"并不特指某种复杂的机器学习模型，它可以是一个决策树、一套业务规则引擎、一个有限状态机、一条最优路径求解器，甚至就是几十行写得足够严谨的if-else。这些方案的特点正好和LLM互补：确定性强、零幻觉、延迟稳定在个位数毫秒级、可解释性拉满、单位成本几乎可以忽略。

我常用一个类比来给团队讲这个问题：LLM像一个知识面极广的杂学家，你问他"这首诗表达了什么情绪"、"这段客户反馈透露出什么问题"，他能说得头头是道；但你要是让他精确计算一个房贷月供、判断一笔转账是否符合风控规则，他可能一本正经地给你一个错误答案，还附带两个道歉表情。而专用决策模型是那种刻板的专业技师，你输入固定格式，它返回固定结果，枯燥但可靠。

再往深一层说，LLM的价值密度其实非常不均匀。它有大约90%的算力消耗在处理高频、低价值的单次请求，真正需要深度语义理解、开放域推理、创造性生成的高价值请求只占一小部分。你如果不管三七二十一全部喂给LLM，等于给全公司的取水需求装了一台海水淡化设备——清洁度很高，但大部分场景根本用不上这种纯净水。

这个认知很重要。因为一旦你接受"LLM是杂学家而不是精确计算器"这个设定，选型思路就会从"谁更强"转向"谁更匹配"。接下来要解决的就是：匹配度怎么量化？我建议从三个维度判断，下面展开。

3. 量化判据：用延迟、成本、确定性三个维度识别"该换"的信号

很多团队在选型时只盯准确率，这是一个误区。准确率当然重要，但生产环境的决策模型好不好用，至少要看三个指标的组合：延迟、成本、确定性。这三个维度任何一个出现红灯，都说明负载可能不适合LLM。

3.1 延迟：业务能容忍模型"想多久"？

第一个问题是延迟预算。LLM的推理延迟通常在几百毫秒到几秒之间，即使是用最轻量的小模型，一次调用也要几十毫秒。而专用规则引擎、查表、简单分类器通常能做到1到10毫秒以内。

不是所有场景都需要毫秒级响应，但你要先确认自己的延迟预算。判断方法很简单：用户等待时，模型的思考时间是否成为体验瓶颈。

• 用户点了一个按钮，期望0.5秒内得到反馈——高延迟不可接受。
• 用户在写工单，点提交后系统异步处理，5秒后出结果也没关系——延迟预算宽松。
• 系统在交易链路上做实时风控，100毫秒都可能影响超时策略——毫秒级响应是刚需。

我见过最典型的反面案例是：某团队让LLM判断用户的退款申请是否满足"七天无理由"条件。一次判断耗时近一秒，用户提交退款后页面要转圈半天。而这条规则用10行代码就能精确判定，延迟几乎为零。

3.2 成本：单次调用单价 × 调用量 = 真实代价

第二个维度是成本，这里必须学会算账。很多人只看到LLM接口的单次调用价格"好像不贵"，完全没算全局成本。

我做了一个粗略对比，你可以直接套用：

这个表并不精确，不同模型定价差异很大，但数量级是对的。消耗的算力是实打实的，如果你每天处理100万次工单分类，用云端大模型一年光是分类这一项就要烧掉几十上百万，而这部分成本用规则或小模型可以压缩到忽略不计。

更隐蔽的还有失败重试成本。LLM输出一旦不符合预期，你要做校验、重写提示词、重新调用，每次重试都是一次新的费用。在我的观察里，生产环境中LLM接口的实际有效成本往往是预估成本的2到3倍。这不是危言耸听，我审过的项目里几乎无一例外。

3.3 确定性：决策错了，代价谁来扛？

第三个维度是我认为最核心的——确定性。这里要区分两种负载类型：

一类负载可以容忍"模糊但合理"。典型如客服话术生成、内容摘要、辅助写作、情感分析。这些场景用户不会拿一个标准答案来校对模型输出，只要整体看起来靠谱就行。这种场景LLM是最优选。

另一类负载要求"必须精确"。典型如业务规则判定、权限校验、审批决策、价格计算、状态流转。这些场景背后是合同条款、法律法规、业务流程底线。错了就是事故，不是"抱歉，我重新生成一次"能糊弄过去的。

关键问题是：这类精确负载出错后，你有没有能力兜底？如果兜底方式是"再调一次LLM"，那等于没兜。如果兜底方式是人工审核，那成本还得往上加。如果压根没有兜底，那就是在赌模型的运气，赌注是业务事故。

我判断一个负载该不该换掉LLM，就三个问题：

1. 丢给LLM的输入，是否本质上是结构化或半结构化的？
2. 决策结果是否需要被进一步计算、流转、存档或审计？
3. 出错后的损失是否超过单次调用成本的100倍甚至1000倍？

只要有2个回答是"是"，这个负载就应该考虑迁移到专用决策模型。这套自测我在多个项目里验证过，虽然不是银弹，但足以帮助团队从"感觉不对"进入"有理有据"的选型状态。

4. 典型负载拆解：五类场景调LLM纯属浪费

理论讲完，来看具体场景。下面是我在过去一年里反复见到的高频误用案例——这些负载在架构评审时被我拦下过，大部分都成功切换到了更合适的方案，效果立竿见影。

4.1 结构化数据抽取与转换

这是最常见的误用。团队拿到一堆非标准格式的文本，比如从PDF发票里抽字段、从日志里提取错误码、从网页里抓价格信息，第一反应就是"上LLM，它能读懂语义"。

问题在于，这些文本背后通常存在可归纳的模式，哪怕模式复杂一点，也可以用编译原理里的语法解析器、正则表达式、模板匹配来解决。LLM确实能抽取，但它抽取结果需要再经过一遍schema校验，失败率在5%到20%波动，命中失败就得重试或人工介入。而一个写好的解析器可以做到99.99%的稳定输出，延迟为零，还能在出错时告诉你具体是哪个字段匹配失败。

我并不是说完全不用LLM，而是说：如果你能找到一个足够覆盖80%样本的模式化解析方案，剩下的20%交给LLM作为兜底，整体效率和成本会远优于全面使用LLM。

4.2 规则判断与业务分流

第二个高频场景是分流。比如客户消息进来，要判断是"投诉"、"咨询"还是"催单"。很多团队的实现方式是把消息拼进prompt，让LLM输出分类结果。

这类任务看起来需要语义理解，但它本质上是一个文本分类问题，传统机器学习、关键词加权、甚至一套精心设计的决策规则完全可以处理。更关键的是，业务分流的结果要驱动后续流程——投诉要转给客服主管，催单要升级到24小时内处理。如果分类错了，整个流转链就乱了。LLM在绝大多数常规样本上表现不错，但在模棱两可的样本上会随机摇摆，这种不确定性对流程系统是不可接受的。

我给的建议是：先建立一套多层次分流策略。第一层用硬规则（关键词、黑名单、异常标志），第二层用轻量分类模型（fastText、BERT级别的模型就够），最后一层才轮到LLM处理"前两层都拿不准"的长尾情况。在这个架构里，LLM的调用量会骤降到原来的10%以下，而系统整体准确率反而更高。

4.3 数值计算与精确查询

这个场景更加离谱。有人问我"能不能让LLM根据销量数据预测下周库存"，还有人真的尝试让LLM计算"如果A大于B且C小于D，返回E"。看到这种需求我通常直接打断：凡是涉及数字运算、条件判定、最优化求解的，都不该请LLM来猜。

正确的做法是：

• 数值计算走数学计算库或业务公式；
• 状态判定走规则引擎；
• 库存预测走时序模型；
• 路径规划走图算法或求解器。

这些方案不仅准确，还能给出计算过程和依据。LLM在这里唯一的用处是"把自然语言翻译成调用参数"——比如用户说"帮我算一下过去30天的平均客单价"，LLM负责把意图翻译成查询条件和计算公式，真正的计算必须交给数据库和计算引擎。翻译和计算各干各的活儿，混合模式才是健康形态。

4.4 权限与合规校验

权限校验是最不该碰LLM的领域。因为权限规则的背后是组织架构、安全策略、合同约束，任何一条规则都必须精确执行。让LLM判断"这个用户能访问这个项目吗"，等于让一个艺术家去当法官——不是他不聪明，是他根本不具备这个职责所需的那种严格性。

这一类的正解是基于策略的访问控制（PBAC）、属性基访问控制（ABAC）或者简单的RBAC检查。把权限规则建模成数据表格和判定函数，查询时走索引和位运算，毫秒内出结果，而且每一次拒绝都能给出明确原因供审计。我见过一个团队原本用LLM判断会员等级对应的折扣，上线后出现多次折扣计算错误，财务对账对不上。换成规则配置后，三天解决。

4.5 实时监控与告警决策

最后是运维监控领域。有团队尝试用LLM分析日志判断系统是否异常，思路看起来很美，但工程上问题很多：日志量大、延迟要求高、错误判断会导致告警风暴或漏报。

实际情况是，异常检测更适合用统计方法、时序分析和专门的异常检测模型。LLM可以做的是"告警后总结根因"，给运维人员一份自然语言的分析报告——这是增值环节，而不是判断环节。把监控判断和根因解释拆开，用不同的模型做不同的事，才是靠谱的工程架构。

5. 混用才是终态：LLM与专用决策模型的协同架构

聊完了不该用什么，接下来聊聊该怎么用。我跑过不少项目，最终沉淀下来的架构其实很简单：分层、兜底、回流。这里我结合一个真实的工单分类系统来讲。

5.1 分层策略：先用规则，再用专用模型，最后才是LLM

整体思路是从低成本方案往高成本方案逐层递进，每一层只有在前一层"拿不准"的时候才把请求交给下一层。一个典型的判断流程如下：

def classify_ticket(ticket): # 第一层：硬规则命中 rule_result = match_hard_rules(ticket) if rule_result.confidence == "high": return rule_result.category # 第二层：轻量分类模型 model_result = lightweight_classifier(ticket.text) if model_result.confidence > 0.9: return model_result.category # 第三层：LLM兜底，处理语义复杂的长尾样本 llm_result = llm_classify(ticket.text) return llm_result.category

这个流程用到的技术很朴素，关键在于每层都要有置信度评估。规则层返回一个"是否明确命中"的标记，模型层输出softmax概率，只有低于阈值才下沉。实际落地时，超过80%的工单在第一层和第二层就完成分类，只有不到20%的长尾请求真正进入LLM，成本和延迟都被控制住了。

5.2 兜底机制：永远别让LLM是唯一出口

即便走到了LLM这一层，也不要直接信任它的输出。在我的项目里，LLM的判决必须经过结果校验器验证——检查输出是否在合法类别集合内、字段是否完整、与其他关键字段是否矛盾。校验不通过就重新调用或标记为人工审核。

这种"模型负责给出判断，程序负责检查判断"的机制，本质上是接受了LLM会产生幻觉这个现实，并在系统层面为幻觉划定了边界。你没法让模型不犯错，但你可以让错误无法传导到业务链路上。

5.3 回流机制：从LLM输出中提取规则，让系统越用越"轻"

还有一层的进阶玩法是规则回流。LLM处理长尾样本后，把一些被验证是正确的分类结果倒推成关键词规则和模式，定期沉淀到第一层的规则库中。

我们实际做过：工单系统上线三个月后，第一层的规则命中覆盖率从50%提升到75%，这意味着进入LLM的流量进一步减少，账单又降了一个台阶。这个过程很像人类团队里的"老带新"——LLM像一个知识渊博但速度慢的前辈，它在处理疑难问题上协助训练那些快速、稳定的规则执行者。最终系统的整体能力，是由规则库的广度和LLM的深度共同决定的。

6. 几个容易踩的坑：从选型到上线的实战经验

最后聊几个我亲自踩过或亲眼见过别人踩的坑。如果能帮你在做架构决策时少走弯路，这文章就没白写。

坑一：拿LLM跑Demo验证需求，错把"效果可行"当成"方案可行"

一个工单分类Demo，人工review了一百条，觉得准确率不错，就大张旗鼓上线了。问题是Demo阶段没有并发、没有成本压力、没有输出校验，一切看起来都很美好。真正的风险永远在生产环境中暴露：尖峰流量来了，下游超时；输出格式偶尔抽风，解析器报错；账单一个月比一个月吓人。我的建议是：技术选型评审时，除了看准确率，必须让相关负责人提交延迟P99、成本估算、错误处理方案，三个材料齐了再谈是否可行。

坑二：只测常规样本，不测边界样本

LLM在常规样本上的表现几乎总是很好的，所以总是拿常规样本去评测，得到的结论很乐观。但生产环境里的真实流量分布是长尾的——错别字、口语化、中英混杂、emoji、残缺句式，一大堆奇奇怪怪的东西。这些恰恰是LLM最容易摇摆、最容易产生幻觉的地方。回归测试集最好覆盖这些边界样本，宁可常规样本少一点，也要把边角料样本纳入评估体系。

坑三：把规则库做成死板的黑盒子，拒绝迭代

有些团队一提到用规则，就开始搞一个巨型的静态配置文件，里面堆了上千条正则，改一条怕影响另外十条，完全不敢动。结果规则库越来越陈旧，覆盖率越来越低，又反过来论证"LLM更好"。这不对，规则系统本身也需要工程化管理——规则要版本化、可灰度、可测试，每条规则都应该有对应的样本断言。规则不是一锤子买卖，它和模型一样需要持续维护。

坑四：混淆"无状态API"与"有状态流程"

LLM本身是无状态的，但在不少项目里，团队试图用LLM来维护一个多轮对话的决策状态，比如"用户是否已经提供了地址""这个工单当前处于哪个审批阶段"。这种状态信息放在外部存储里就完了，为什么非要让模型"记住"？我在多个项目里强制要求：所有业务状态一律落到数据库或缓存，LLM只负责理解和生成，不负责记忆。这样系统在主流程上仍然是可校验、可回溯的。谁把状态交给模型，谁就会在第二天收到鬼打墙一样的前后矛盾输出。

坑五：把"换掉LLM"变成"全部换掉"

最后一个坑是走极端。有人看了类似这篇文章的内容，回头就把所有接口里的LLM全部下线，结果发现很多语义理解类功能确实离不开LLM。任何时候都不建议做这样的大扫除式迁移。正确的姿势是：先把负载按本章前面提到的三个自测问题分个类，先拿20%最不需要语义能力的接口试点切换，验证延迟、成本和准确性之后再逐步扩大范围。保留LLM在内容生成、语义分析、长尾兜底这些位置上的优势，让每一层系统做它最擅长的事，这才是架构价值最大化的做法。

在我个人实践里，这套"规则+专用模型为主、LLM为兜底与增强"的架构，通常能让分类系统的成本下降一个数量级以上，同时把延迟和错误率控制到业务完全无感知的程度。很多人问我：LLM这么火，还用这种土办法会不会过时？我通常反问一个问题：如果你负责的业务里有客户财务数据，你希望系统用"概率猜测"还是"精确计算"来反馈结果？想清楚这个，你就想清楚了一切。