企业官网建设流程全解析

最近在帮一个团队评估合同审核方向的AI落地，遇到了一件很典型的事。同一个合同模板，同一个LLM，同样的问题，连跑三次，出来三份略有差异的审查意见。第一次漏掉了一条风险条款，第二次把风险程度标得太高，第三次看起来正常。团队负责人盯着屏幕问我：“是不是参数没调好？”我说，更准确地说，是我们正在让一个掷骰子的引擎，去做需要稳定输出的工作。

这不是个别现象。过去一年里，越来越多垂直领域的AI产品开始强调“Agent”“RAG”“MCP”这些词，合同审核、客服助手、代码审查、招聘筛选、合规初筛，几乎每一个方向都在往LLM上靠。大家默认了一件事：只要把模型接进业务流，配一个足够详细的提示词，它就能像传统软件一样稳定输出。但问题恰恰出在这里：LLM不是传统软件。它不是函数，而是概率分布。

这篇文章想说的其实是一句话：垂直AI真正的泡沫，不是模型能力被高估，而是我们把一个随机生成器当成了确定性计算器在验收、部署和兜底。想明白这件事，很多“翻车”现场都能提前避开。

1. 垂直AI热潮里，被低估的“概率本质”

1.1 我们期待的是函数，得到的却是分布

传统软件里，一个函数给定同样的输入，返回的一定是同样的输出。这是最底层的确定性。过去几十年，所有系统设计、自动化流程、测试用例、合规审计，都默认建立在“输入不变，行为就不变”这条规则上。

但LLM完全不是这样。它做的事情是：给定一段文本作为条件，从词表上计算出一个概率分布，然后根据这个分布去采样下一个token。同一个 prompt，同一个模型，两次运行得到的输出可能不同。随机性不是bug，而是生成模型的底层机制。

很多垂直AI产品在宣传时，会把“智能审核”“自动生成报告”包装得像一个更高配的规则引擎。但到了真实项目里，业务方会问：为什么这条条款上次被标记了，这次没被标记？为什么同样的问题，上午和下午回答不一样？这些问题的答案，往往不是因为模型变笨了，而是因为我们用函数的预期去使用了一个概率系统。

我见过不少团队在做一个垂直AI Demo时非常兴奋，因为单次演示效果很好。但只要进入测试阶段，把同样的测试集跑两遍，就会发现输出存在漂移。这个漂移率在低风险场景里可以接受，但在合同、医疗、金融、代码安全这类场景里，会成为决策障碍。

1.2 “掷骰子”不是比喻，是采样机制

“LLMs Roll Dice”这个说法，容易让人觉得是夸张的批评。其实从工程角度看，它是很准确的描述。一个生成模型在推理时，通常要经过下面这些环节：

1. 把输入文本转成 token 序列。
2. 模型前向计算，输出下一个 token 的概率分布。
3. 按某种采样策略，从概率分布中选出一个或一组 token。
4. 把新 token 拼到输入后，重复直到结束。

采样策略里最重要的参数是 temperature。temperature 越高，分布越扁平，低概率 token 被选中的机会越大，输出越多样。temperature 越低，输出越倾向于高概率 token，但并不意味着完全消除随机性。

即使在 temperature 等于 0 时，很多推理框架也会因为浮点运算、批处理、并行调度、FlashAttention 实现差异，导致输出不完全一致。更关键的是，temperature=0 选择最高概率 token，只是让“单次采样”更确定，并不保证“语义正确”“符合规范”或“一定不幻觉”。

对垂直AI产品来说，这种概率本质带来的直接后果是：我们不能再用“跑通一个用例”来证明系统可用。可复现性、稳定性、错误率、失败兜底，这些传统软件里最基础的能力，在LLM应用中反而成了最需要设计的部分。

2. 为什么单点看起来很好，垂直落地却全面翻车

2.1 垂直场景要求的是稳定可复用，不是偶尔惊艳

垂直AI和通用聊天机器人有一个本质区别：垂直场景是为了稳定地重复完成一类任务。风险审核、代码审查、客服工单分类、合同条款提取，这些任务要求的是“每次都达到及格线以上”，而不是“十次里有一次惊艳”。

在评估一个LLM应用时，很多团队会陷入一个认知误区：看到模型在某几个精心挑的例子上表现很好，就认为它具备了相应能力。但真实业务数据分布很宽，边缘情况很多，而且LLM的输出波动会把“偶尔正确”放大成“不可预测”。

打个比方，这就像你请了一个很聪明但偶尔会走神的实习生。他每次完成任务的质量大概在70分到95分之间波动。对于一个低风险的文字润色任务，这完全没问题；但对于一个需要写入合同或影响订单状态的自动流程，这种波动就是不可接受的。

所以垂直AI的“翻车”，往往不是模型一次性犯大错，而是它在一个长周期里不断产生小概率错误。这些小概率错误单看不致命，堆在每天几万次调用里，就成了每天几十起需要人工介入的异常。

2.2 随机性从哪来：参数、上下文、外部知识、模型路由

当你说“LLM输出不稳定”时，不要急着怪模型。一定要先拆清楚随机性到底是从哪个环节进来的。我一般会按下面几个来源去查。

采样参数。temperature、top_p、max_tokens、seed，这些直接决定生成过程的随机程度。很多应用上线时根本没有冻结这些参数，默认值可能偏向多样性，这在对话场景没问题，但在结构化输出场景可能造成字段时有时无。

上下文动态部分。如果prompt里拼接了时间、用户输入、客服备注、session信息，那么即使主任务相同，模型看到的上下文也不同。有些场景需要这种动态，但要注意动态部分本身会引入输出方差。

外部知识检索。现在很多垂直应用都用了RAG。RAG的一个隐蔽问题不是“检索不到”，而是“检索结果排序不稳定”。同一个query，向量库返回的相关文档可能因为索引更新、Embedding版本、切片方式、重排模型变化而不同。检索结果一变，LLM输出自然变。

模型路由和版本。应用层可能配置了多个模型自动降级，或者供应商后台做了灰度更新。你以为是同一个模型，实际在跑的是不同版本。模型版本一变，分布就变，很多线上问题其实来自这里。

在排查不稳定问题时，建议先用固定日志把每次请求的模型版本、采样参数、输入摘要、RAG检索结果都记录下来。没有这份日志，你很难判断输出波动是来自模型、检索还是prompt。

2.3 更隐蔽的问题：用确定性思维验收随机系统

传统项目验收方式是准备一批测试用例，跑一遍，看通过率。但在LLM项目里，这样做有两个致命缺陷。

第一个缺陷是：单次跑通过的用例，不代表下次还能通过。如果你只用一组静态样例验收，那你验收到的其实是“在特定随机种子和采样参数下的表现”，而不是系统的真实分布。

第二个缺陷是：你只评估了“模型输出”是否正确，没有评估“输出到业务动作”这一整条链路是否可靠。LLM生成的JSON字段被下游解析，只要字段名偶尔变化，下游就会崩。这种问题不是模型能力问题，而是接口契约问题。

更合理的验收方式应该是：准备一个覆盖正常、边缘、异常三类样本的评估集，在固定一组配置下多次运行，记录输出分布，计算关键指标的均值和方差。比如字段缺失率、格式错误率、语义一致性、需要人工介入的比例。只有把这些指标纳入验收，你才是在验收一个随机系统。

3. 构建垂直AI的正确姿势：先接受随机，再控制边界

3.1 三层防护：输入约束、输出校验、人工兜底

既然LLM是随机引擎，就不能指望它自己稳定。工程上能做的，是在它外面套上确定性护栏。我一般把防护拆成三层。

第一层是输入约束。在进入LLM之前，先确定任务边界：这个任务是不是只允许模型处理某类输入？输入格式是否已经标准化？长度、字段、数量有没有限制？如果输入是合同，可以先做PDF解析和章节切分，只取出相关条款，而不是把几百页原文直接丢给模型。输入越规整，模型的输出方差越小。

第二层是输出校验。LLM返回结果后，不要直接信任。用代码做结构化校验：必填字段是否存在？枚举值是否合法？格式是否是JSON或特定模板？数字范围是否合理？如果校验失败，可以重试一次，或者进入降级流程。输出校验层的价值，是把概率问题转化成“可捕获的异常”。

第三层是人工兜底。任何高风险的垂直场景，都应该在流程上保留人工确认环节。这不丢人，反而说明你理解了LLM的边界。自动生成初筛意见、人工复核确认，是现在最成熟的落地方式。完全去掉人的流程，至少在强合规场景里还不到时候。

这三层不是可选项，而是必选项。跳过任何一层，都是在把随机性直接暴露给业务。

3.2 温度、种子、评估集：让实验可复现

“可复现”是开源社区反复强调的词，但在LLM应用开发里，很多人反而不重视。我建议从第一天起就把下面这些配置固定下来，写进工程规范。

• temperature：结构化任务建议从0.0开始调，不要直接从0.7起步。
• top_p：如果需要更保守的输出，可以配合temperature一起调。
• seed：如果平台支持固定seed，实验阶段一定要固定。不过要记住，seed固定不代表跨版本一定可复现。
• 模型版本：在生产环境锁死模型版本，不要用latest这种标签。
• prompt版本：每次修改prompt都要记录版本号，并跑一遍回归测试。
• 外部知识版本：RAG里的知识库、Embedding模型、切分方式都要版本化。

同时，建立你自己的小评估集。这个评估集不需要很大，三五十个典型case，覆盖正常、边界、异常三类。每一轮改动后，用同一个评估集、同一组采样参数跑三到五遍，记录输出。不是为了“验证效果”，而是为了观察稳定性。

3.3 一份可执行的LLM输出排查链路

当线上出现输出不稳定、字段缺失、结果错误时，建议按下面这个顺序排查，而不是一开始就去改prompt。

1. 先看日志：采样参数是什么？模型版本是什么？输入摘要是否完整？RAG检索命中了哪些文档？
2. 固定环境重跑：把同样的输入、同样的配置、同样的知识库版本，用固定seed重跑，看是否稳定复现。
3. 切换输入动态部分：把prompt里的时间、客服备注等变量去掉，只保留核心输入，看输出是否恢复稳定。这一步能判断是否上下文动态内容干扰。
4. 检查RAG检索：将检索结果打印出来，看排序是否稳定。如果同一query在不同时间命中的文档不一致，问题可能在检索层。
5. 检查输出解析：如果下游解析失败，检查字段名、类型和枚举值是否变化。有些模型在长输出时，会自行加引号或换行导致JSON解析失败。
6. 最后再动prompt：前面的链路都排查完，再调整prompt，否则你很难知道改动到底解决了什么。

这套排查链路本质上是在回答一个问题：输出波动到底是模型造成的，还是前面任意一层造成的？把问题定位准确，比盲目调参更有效。

4. 垂直AI的准入线：场景、成本、风险三维评估

4.1 适合生成的场景：低风险、强辅助、人审闭环

垂直AI并不是不能做，而是要选对场景。从我的经验看，下面这几类场景现在更适合落地。

第一类是“内容草稿生成”。比如营销文案初稿、周报生成、产品说明起草。这类任务允许一定程度的差异，核心价值是帮人省去从空白页开始的时间。只要人有最终审阅和修改权，随机性就是可控的。

第二类是“知识辅助问答”。比如企业内部知识库搜索、研发手册问答、政策法规初步解释。这类场景的答案需要人来确认，同时需要标注“仅供参考”。适合把LLM当检索增强助手，而不是最终裁决者。

第三类是“结构化数据提取”。从非结构化文本中抽取字段、实体、关系，例如从简历里提取技能、从发票里提取金额。这类任务可以用强校验层把输出限制在固定Schema里，即使模型偶尔出错，也能被规则拦截。

这几类场景有一个共同点：LLM的输出不是直接产生业务结果，而是作为“初稿”或“候选”进入后续流程。人还在链路上，随机性就不会无限放大。

4.2 不适合直接决策的场景：强规则、强一致、强合规

我也见过一些场景，从一开始就不适合用LLM直接做决策，但团队因为“大家都在做AI”而强行接入。

比如涉及数字计算的场景。LLM擅长自然语言，不擅长精确算术。即便看起来算对了，也可能因为推理过程不同而中途出错。正确的做法是让LLM负责抽取算式，用代码引擎执行计算。

再比如强规则一致性的场景。优惠活动规则、权限判定、费率计算，这类逻辑要求同一条件永远得到同一输出。LLM不适合用来做这类规则引擎，至少不适合在缺少校验和回退方案的情况下直接承担。

还有强合规和高风险场景。医疗诊断、征信审批、法律最终意见等，直接让LLM输出结论，风险高且难以追溯。这类场景更适合让LLM做信息整理、证据链汇总、倾向性提示，最终结论由持证或负责人完成。

不是所有“AI能懂”的任务都适合“AI负责”。垂直AI的价值不是替代规则系统，而是在规则系统覆盖不到的开放语义空间里提供辅助。

4.3 用“不确定性预算表”做选型

我在实际评估一个垂直AI机会时，会画一个“不确定性预算表”。不是看模型能力多强，而是看业务能容忍多少不确定性。

表格的用法是：如果某个场景在右边一列占了三条以上，就要谨慎。不要因为demo效果不错就冲进去。一个垂直AI产品能不能成立，不是看模型答得好不好，而是看整条业务链能不能容忍波动。预算里面，不确定性是一种必须支付的成本。成本不能无限大。

5. 从“AI替代人”回到“AI增强人”：我的一些实操建议

5.1 先跑通单点，再做批量，这是底线

每次有团队问我垂直AI怎么落地，我第一个建议都是：不要一开始就规划宏大平台，先选一个真正高频、低风险、反馈快的单点场景，把整条链路跑通。

这个单点要满足三个条件：

• 频率非常高，大家每天都会遇到。
• 错误后果可控，即使输出错了也不会造成大事故。
• 有明确的输入输出边界，方便做校验。

把单点跑通之后，再观察指标：调用失败率、人工介入率、输出一次性通过率。如果这三个指标稳定，再考虑横向扩展。如果单点都不稳，就不要扩。扩得越快，滚雪球越大。

“AI替代人”是结果，不是起点。起点永远是“AI辅助人，把人的一部分重复工作抽出来”。抽出来的前提是，你已经为随机性设计好了退路。

5.2 把一次性经验沉淀成可复用流程

在垂直AI项目里，真正值钱的资产不是 prompt，也不是模型调参记录，而是一套围绕随机引擎建立的确定性流程。这套流程包括：

1. 每次调用的运行日志，包含输入、采样参数、模型版本、知识库版本、输出和耗时。
2. 一套可重复运行的评估集，覆盖正常、边界、异常三类输入。
3. 一个输出校验模板，针对每个任务定义必填字段、类型、取值范围和兜底动作。
4. 一个人工复核SOP，说明哪些情况必须人工，哪些情况可以自动放行。
5. 一个结果反馈闭环，持续从生产环境收集badcase，每周更新评估集。

有了这套流程，你团队里的任何一个人换到项目里，都能在一个下午恢复上下文。没有这套流程，项目就会一直停留在“只有写prompt的人能维护”的状态。

现在很多人在讨论LLM框架、Agent编排、知识库Wiki化，背后其实都是同一个诉求：把不确定性变成可观测、可控制、可迭代的工程对象。这种“工程化”程度，才是垂直AI能不能长期跑下去的分水岭。

5.3 回到开头那个判断

再回到合同审核那个案例。后来我们做的事情很简单：把LLM输出的审查意见从“最终结论”降级为“初筛建议”，再用规则脚本校验必查条款，最后强制人工确认风险条款。改动之后，系统没有变得更“聪明”，但错误率显著下降了。

这才是垂直AI该有的样子。不要追求让模型变成永不犯错的业务大脑，而是接受它是个聪明但会掷骰子的助手。你真正要做的，是为每一次“掷骰子”设好边界：能校验的校验，能重试的重试，必须交给人的就交给人。

垂直AI泡沫会不会破，不在于资本什么时候降温，而在于我们什么时候愿意承认：LLM roll dice。承认之后，才会认真设计护栏，才会把评估指标从“看一个demo”改成“看一段运行数据”，才会让AI真正走进生产环境。

先接受随机，再谈智能。这听起来没有“AI替代人”带感，但它才是垂直AI从demo到产品的那条窄路。