企业官网建设流程全解析

做了大半年 AI 应用落地，回头看 Spring AI 项目里最难的其实不是写那几行链式调用，而是每一步都在做选择：用哪个模型、走流式还是同步、上下文留多少、要不要上向量库、缓存怎么设计、模型挂了怎么办。这些决策直接决定了项目的成本、稳定性和交付节奏。这篇文章整理了我自己在实际项目里反复踩坑后沉淀的一套决策框架，一共 10 个关键决策，后面再补上选型方法论、成本控制手段和交付前的 Checklist，基本就是一份可以直接拿去对照落地的操作指南。

1. 先想清楚：AI 应用落地的阻力到底在哪

1.1 为什么 90% 的项目卡在选择上

传统后端开发，技术选型相对固定：数据库用什么、缓存用什么、消息队列用什么，社区里都有成熟的最佳实践。但 AI 应用完全不是这么回事。模型层几乎每隔几个月就换一轮，同一个任务用 A 模型和 B 模型的效果差异能大到让人怀疑人生，更别说成本和延迟的差别。

我做过一个问答助手项目，同一个问题在不同模型间对比，回答质量和 Token 消耗能差出 3 倍以上。这意味着你没法简单照抄别人的方案，必须针对自己的业务做权衡。很多团队卡住，不是写不出代码，而是没人愿意为这些决策负责。选模型、定上下文策略，听起来像"技术选型"，实际牵扯到预算、产品预期和运维能力。我见过一个项目，开发两周就能出 demo，但为了选模型反复对比，拖了一个月还没定下来。所以这篇文章的核心目的，就是把决策清单拉出来，每个点给你判断依据和取舍标准。

1.2 这篇文章的使用方式

如果你是做 Java / Spring 技术栈的工程师，或者正在为团队规划 AI 功能，这篇文章应该能帮你少走不少弯路。我不会贴大段源码，重点讲决策逻辑和踩坑经验。每一个决策我都会给一个"结论先行"的判断，再展开细节。你可以按顺序读，也可以直接跳到感兴趣的部分。后面 3、4、5 章分别是方法论、成本账和交付清单，偏管理向，但都是我自己用过的落地工具，建议收藏起来在项目评审时对照着过一遍。

2. 十个关键决策逐个拆解

2.1 决策一：模型选型是地基，但不是一次定终身

先给结论：不要把模型选型当成一次性决定，要把它设计成一套可切换机制。

我项目初期踩过最大的坑，就是代码里到处硬编码了模型名，等到想换模型的时候改了几十个地方。后来统一封装了一个模型工厂接口，所有业务代码只依赖 ChatClient 这个抽象，换模型只改一处配置。这个改动不复杂，但能让你在后续选型中占据主动权。

选型维度其实就三个：任务效果、单次调用成本、响应延迟。任务效果怎么评？不要信网上随便贴的排行榜，那是在通用任务上调出来的。你要拿自己业务里最典型的 50 条问题，跑一轮人工打分。成本不能只看单价比，还要结合输出长度——有的模型价格低但答得啰嗦，实际算下来反而更贵。延迟也一样，同一个模型在不同网络环境下表现差异很大，你必须用生产环境的真实链路去测。

模型类型上，主流选择基本分三类。第一类是海外头部模型，综合能力强，尤其在复杂推理上明显领先，但国内合规链路复杂、数据出境有限制，适合对数据要求不敏感的通用场景。第二类是国产主流大模型平台，响应速度快、中文效果好、企业服务完善，缺点是部分模型在复杂逻辑推理上还差一口气。第三类是开源可私有化部署的模型，数据不出内网，适合金融、医疗这类敏感场景，但你需要自己维护推理服务，GPU 成本不低。

我的建议是生产环境至少留两套模型可切换：一套主力，一套备用。不用让备用模型跑同样流量，但降级方案必须有，这个后面细讲。

2.2 决策二：流式还是同步，本质是体验决策

模型生成是逐 Token 输出的，完整回答可能要好几秒。如果用户界面上只有一个 loading 转圈，等 3 秒就开始焦虑，等 5 秒很多人直接关页面。所以凡是面向用户实时交互的场景，一律优先做流式输出（SSE），让文字逐个蹦出来，感知延迟能从 5 秒降到 1 秒以内。

Spring AI 对流式有原生支持，ChatClient 接口里拿到的是一段响应式数据流。落地时有一个很容易被忽略的坑：你的网关或者中间代理如果开启了响应缓冲，SSE 数据会被攒到全部生成完才推给前端，流式就白做了。解决方法是把代理层的缓冲关掉，或者让 SSE 接口走独立路由绕过缓冲。

业务场景不同，选择也要跟着变。我一般这么定：用户在线对话，必须流式；定时任务、批处理、报表生成，用同步，逻辑简单、好追踪；如果前端能力受限确实接不了流式，那就降级为同步返回加轮询。这里没有绝对的对错，关键是别把流式当成标配硬做，内部工具用流式纯属给自己找事儿。

2.3 决策三：上下文窗口管理，决定成本和效果能不能兼得

大模型 API 本身是无状态的，每次调用它只能看到你传进去的消息列表。你要是把全部历史对话都传进去，Token 预算很快烧光。我算过一笔简单的账：假设平均每轮对话消耗 500 Token，聊天 20 轮就是 1 万 Token。如果同时有 1000 个用户在线，光上下文占用的成本就非常可观，更别说超出窗口长度后调用直接报错。

我常用的上下文管理分三层。第一层是滑动窗口，只保留最近 N 条消息，通常 10 到 20 条比较合适，具体要看任务复杂度。第二层是摘要压缩，当历史超过一定阈值，先把早期对话用模型压成一段摘要，再放进上下文。第三层是关键信息提取，从历史对话里把用户姓名、偏好、订单号这些结构化字段抽出来，下次拼进提示词就行，不用把整段历史都带上。

Spring AI 里可以通过自定义 Advisor 来统一实现消息裁剪逻辑，不用在业务代码里到处写判断。这里有一个容易出错的点：裁剪时一定要保留系统提示词（System Prompt），只对用户和助手消息做窗口截断。如果把系统提示词也裁掉了，模型行为和回答风格可能会跑偏。

2.4 决策四：记忆机制，不是所有场景都需要

很多人把记忆和上下文窗口混为一谈。上下文窗口是当前会话内传给模型的文本，记忆是跨会话模型能利用的用户信息。这两者的实现路径完全不同。

很多场景根本不需要长期记忆。一次性的知识问答、文本润色、代码解释，模型只看到当前输入就够了。但客服、陪伴闲聊、个性化推荐这类场景，没有记忆的话效果会大打折扣。比如用户上次说过"我对花生过敏"，下次点餐推荐时模型又推荐花生酱，这体验就很崩。

落地方式从简单到复杂分三档。第一档是进程内 Map，适合 demo 和单实例部署，重启就丢，不推荐生产用。第二档是 Redis 缓存，设置过期时间，大多数生产项目够用。第三档是向量库记忆，把每轮对话编码成向量存起来，检索相关历史片段，适合重场景。我的建议是绝大多数项目从 Redis 起步，不要一上来就上向量库。很多团队把记忆想得太复杂，实际上 80% 的场景只需要记住最近几个关键事实，用一个简单的用户画像字段就解决了。给每个用户维护一个"关键信息备注"字段，每次对话后让模型总结一句存入，比存几十轮聊天记录便宜得多，效果也更好。

2.5 决策五：RAG 引入时机与向量库选择

先给判断标准：当模型幻觉开始造成业务问题时，再上 RAG。如果业务文档不超过 100 篇，而且直接把相关内容拼进提示词效果还能接受，那就先别急着上向量库。这个标准能帮你省下大量初期搭建和运维成本。

RAG 的核心链路是三个环节：文档切分、向量化入库、检索召回。切分策略是最容易翻车的地方。我踩过坑：按固定字符数切分，结果把一个完整段落从中间断开，检索召回的内容逻辑不连贯。后来改成按语义段落切分，并且让相邻块保留少量重叠，召回质量提升了很多。

向量库选型，前期强烈建议用 pgvector，直接复用现有 PostgreSQL，不用额外引入一套中间件。数据量到了千万级、检索 QPS 要求很高的时候，再考虑专用向量库产品。检索策略上，只做向量相似度检索往往不够。我实际项目里把向量检索和关键词检索做了混合，再用倒排融合算法合并结果，召回准确性比单路检索高一截。

2.6 决策六：工具调用（Function Calling）的边界设计

工具调用的本质，是让模型在回答过程中决定要不要调用外部函数，然后把函数返回结果纳入最终回答。最常见的场景包括查实时天气、查库存、做数学计算、查订单状态。

设计原则有一条非常重要：工具越少越好。模型一次能考虑的候选是有限的，工具数量一多，误选率飙升。单体业务系统控制在 5 个以内比较稳妥，平台型系统才考虑拆分更多工具。

Spring AI 里用 @Tool 注解就能定义一个工具方法，框架会自动生成工具的 Schema 描述。但任何一个工具都要做参数校验，不能直接信任模型填的参数——模型经常凭空捏造参数值，这是实战里最常见的翻车点。比如模型可能会在用户没有提供订单号时，编一个"12345"传给你的查单工具。

安全红线必须划清楚：给模型配工具时，要区分"可自动执行"和"需人工确认"两类。涉及发消息、下单、删除这类影响真实世界状态的操作，模型只能生成"建议指令"，必须由人来确认后才能实际执行。我在做某个审批类应用时，让模型直接调用了后端接口，测试时一切正常，上线后才发现模型在用户没说清楚的情况下就发起了申请，差点酿成事故。

2.7 决策七：结构化输出，如何稳定拿到 JSON

模型的返回值本质是字符串，你要把它变成业务可用的数据。Spring AI 支持声明结构化输出，内部通过提示词约束加解析器实现。直白说，它不是魔法，偶尔会失败。

我遇到的失败类型主要有三种。第一种是模型返回了多余的说明文字，比如在 JSON 前面加一句"好的，这是你要的结果："，解析器直接报错。第二种是字段名对不上，模型自以为是地把你定义的对象字段名改了。第三种是内容太长被截断，JSON 不完整。

解决办法按优先级做三层。第一，在系统提示词里明确要求"只输出 JSON，不要任何解释文字"。第二，解析失败时自动重试一次，把模型上一次的错误输出原样返回给模型，告诉它格式不对，要求重新生成。第三，重试仍失败就返回业务错误码，不要让底层异常直接抛给用户。另外，我建议所有结构化输出的 JSON 字段都要有默认值兜底，防止模型漏字段。

2.8 决策八：缓存策略，直接的钱袋子

AI 应用里做缓存，目的不只是性能，更重要的是省钱。同一个用户问同一个问题，每次都送到模型重新算一遍，这钱花得完全没有必要。

我实际用的缓存分三层。第一层是精确缓存，请求参数完全一致直接返回历史结果，适合不常变化的问答模板。第二层是 Embedding 缓存，同一个文本的向量反复计算是很费钱的，本地存一份能省不少。第三层是语义缓存，把用户输入做向量化，语义相近的问题直接复用答案。语义缓存要特别小心，如果答案涉及实时数据，比如天气、库存、价格，绝对不能缓存。

实践数据可以参考：我负责的一个知识库问答项目，上了语义缓存之后，模型调用量下降了接近 40%，对应成本也降了 40%。但代价是可能返回陈旧答案。所以在时效性要求高的场景要设置很短的过期时间，或者干脆关掉语义缓存，只保留精确缓存。

2.9 决策九：降级与容灾，模型挂了业务不能挂

大模型 API 不可能永远稳定，限流、超时、5xx 都会遇到。生产环境必须有一整套容灾设计，否则模型一挂，你的应用跟着挂。

基础配置方面，超时时间一定要设短，我通常把连接超时和读超时都控制在几秒以内，框架默认值往往太长，会把你的线程池等死。重试要有上限，配合指数退避，避免雪崩。Spring AI 自带了重试机制，也可以接入专门的熔断组件。

真正的降级要分三层。第一层是模型切换，主力模型不可用，自动切到备用模型。第二层是功能降级，模型不可用但业务不能挂，返回预先写好的兜底话术，或者走简单规则引擎。第三层是服务降级，把非核心功能的入口关掉，保护核心链路。我最开始偷懒没做降级，线上模型限流导致整个页面接口全部超时，用户反馈铺天盖地。那次之后，我把降级策略纳入每个 AI 接口的设计文档，必须写清楚"模型挂了返回什么、走什么替代逻辑"，评审通过才算完成。

2.10 决策十：可观测性，回答不了"花了多少钱"就是失控

AI 应用上线后，你最先要回答的问题大概是：今天调了多少次、花了多少钱、成功率多高、哪个业务线最费 Token。如果没做埋点和日志，这些问题一个都答不上来。

我一般对每次模型调用记录这些字段：业务线、模型名、输入 Token 数、输出 Token 数、延迟、返回码、错误类型、缓存是否命中。日志以 JSON 格式输出，方便接入日志平台做聚合分析。Spring AI 有专门的观测点机制，也可以自己做一个过滤器统一记录，成本很低。

成本追踪上，我给每个业务线设月度 Token 预算，预算快耗尽时自动告警，超出硬限制直接熔断。效果评估更复杂一些，我习惯用抽检方式：每天随机挑 20 条对话，人工打分，记录在表格里，用来观察模型调整前后的效果变化。这套机制让我在模型升级时能快速判断"变好了还是变差了"，而不是靠感觉。

3. 选型方法论：三个步骤锁定方案

3.1 建一个真实业务评测集

前面反复强调别迷信排行榜，那选型到底怎么做？第一步是建评测集。从真实业务中收集 50 到 100 条有代表性的问题，覆盖高频场景、边界场景和易错场景。比如你做客服机器人，评测集里要有查退款进度的、有投诉骂人的、有问售后政策的，不能全是"你好"。

评测集不是一次性资产，需要持续维护。每次模型版本更新、每次提示词调整，都重新跑一遍，你才知道到底变好了还是变差了。我团队里这套评测集现在已经积累到了几百条，每次升级模型前先跑评测，已经成了固定流程。

3.2 离线评测打分，别只看答案对不对

把评测集发给待选模型，让它们各自生成答案，然后打分。打分维度我常用三个：准确率、完整率、格式合规率。准确率是看结果里有没有事实性错误；完整率是看该答的点是否都覆盖了；格式合规率是看是否符合约定的结构化输出。

打分时有一个很容易忽略的点：模型可能在训练时见过类似问题，导致"背答案"。所以评测集里必须包含一些私有化、网络上搜不到的业务问题，才能拉出真实差距。我见过在公开问题上表现优秀的模型，到私有业务问题上直接翻车，效果天差地别。

3.3 灰度切流，用小流量换安全

离线评测通过只代表"纸上成绩好"，还要做小流量灰度。我实际操作是这样一个节奏：先在内部群小范围试用，让团队成员当小白鼠，然后放开 5% 流量，观察两天，再逐步提升到 20%、50%，每个阶段都盯效果指标和成本指标，稳定后再切全量。

灰度期间有个技巧：把新旧模型的结果同时记录，做双跑对比，人工抽看差异。这样得出的结论比任何评测分数都可信。灰度不光是验证模型效果，还要验证新模型的成本和延迟有没有超预期，这两个指标经常在离线评测中被忽略。

4. 成本控制：六个手段把账单降下来

4.1 先算清楚 Token 账本

成本估算公式很简单：总成本等于输入 Token 数乘输入单价，加上输出 Token 数乘输出单价。麻烦的是怎么估算业务量。我的办法是先压测一个典型会话流程，统计平均每轮对话消耗多少 Token，再乘上预期日活和平均交互轮数。

给一个可代入的计算思路：假设某客服助手日均 10 万次调用，每次平均输入 1500 Token、输出 800 Token。你可以按当前选定模型公开的单价去算，得出的数字一定会让你重新审视上下文策略和缓存设计。我每次给团队看这个账，大家的优化意愿立刻提升。

4.2 提示词压缩，成本效果两手抓

减少 Token 最直接的办法是精简提示词。很多人把大模型当搜索引擎用，提示词写得又长又啰嗦，光背景铺垫就几百字。原则很简单：能用三句话说清楚的任务，不要写三百字。

每轮请求里如果带着大量固定模板信息，可以做"首轮全量、后续增量"，也就是把固定知识只在第一轮发给模型，后续对话用简短引用代替。这样单轮成本能降低不少。还有一个容易忽略的地方：历史消息里如果带着很长的工具返回结果，或者代码片段，一定要设上限，超过就截断或摘要。

4.3 模型分级调用，别用牛刀杀鸡

不是所有请求都需要主力大模型。简单意图识别、实体抽取、文本分类这些任务，轻量模型完全能胜任，只有复杂推理和长文本生成才需要动用主力模型。

我在一个聚合应用里做了分级：文本分类和关键词提取走轻量模型，问答生成走主力模型，整体成本下降了差不多 30%。模型分级的关键是给每个业务接口定义好"最低可用模型"，然后在配置中心动态调整，测试后逐步下放到更小的模型。

4.4 善用缓存和批处理

缓存前面讲过了，这里补充批处理。批处理适合非实时场景，比如每天晚上把当天所有对话打包起来，做统一分析、生成日报。很多模型服务提供批量接口，价格比实时单条调用便宜，还能避免白天高峰期限流。

4.5 配额与告警，防患于未然

给每个维度都设上限：按天总 Token、单业务线 Token、突发消耗速率告警阈值。超过阈值自动发通知，甚至自动熔断特定入口。我踩过最痛的一次是某个统计脚本死循环，一夜之间烧掉一大笔预算。从那以后我强制给所有非核心定时任务加了硬限额，数量超了就终止任务，这个习惯救了我很多次。

4.6 成本核算表，每周看一眼

在日志平台里建一个视图，按业务线、按模型、按天聚合 Token 和费用，每周出一个快照给团队。这个表格的作用是让成本变成可见的东西，大家开会时看着数据聊，哪个功能性价比低，该优化还是下架，一目了然。

5. 交付前 Checklist：照着勾就不会漏

5.1 功能验收清单

• 核心问答流程走通了吗？输入一个典型业务问题，回答能正确理解并给出可用结果
• 流式输出是否真正逐字到达前端？用抓包工具确认没有经过缓冲
• 工具调用是否准确？模型调用工具的参数是不是后端校验过的，而不是直接信任
• 结构化输出是否稳定？连续调用 50 次，解析失败率有没有超过可接受范围
• 记忆功能是否按预期工作？重启应用后用户画像还在不在

5.2 性能与稳定性清单

• P95 响应时间是否满足业务目标，流式场景还要看首字返回时间
• 并发高峰时线程池是扛住了还是会打满，打满后是排队还是拒绝
• 超时、重试、熔断行为是否符合预期，有没有出现重试风暴
• 触发降级后用户看到的内容是合理的，而不是白屏或报错
• 长时间运行有没有内存泄漏问题，尤其是流式连接的释放

5.3 安全与合规清单

• 做没做 Prompt 注入防护？比如用户输入里带"忽略之前的指令"这类攻击
• 日志和会话记录里有没有敏感信息？手机号、身份证、住址这类字段是不是做了脱敏
• AI 接口有没有鉴权？确认不能裸奔在公网
• 数据出境和隐私政策是否符合业务合规要求，这个要跟法务同学过一遍

5.4 运维与可观测性清单

• 是否埋点了 Token 数、成本、延迟、错误类型这些关键指标
• 告警配置好了吗？通知发给谁？有没有人值班响应
• 模型切换的开关在哪里？能不能在紧急情况下一键切换
• 有没有灰度开关和回滚方案？出问题能不能迅速切回旧版本

6. 常见问题与避坑实录

6.1 高频故障速查表

6.2 让我印象深刻的几个坑

第一个坑是开发环境随便用了一个模型，生产环境换成了另一个，效果直接崩盘。AI 应用对模型是敏感的，不同模型在格式遵循、语气风格上差别很大。从第一天起就要用同一个模型跑开发和测试，避免"开发爽、上线慌"。

第二个坑是日志里记录了完整对话内容，结果安全评审被打回。对话内容往往包含用户隐私，不能都存原始文本。后来我改成只存必要的业务字段和 Token 统计信息，用户原始输入统一脱敏存储，并且设了访问权限。

第三个坑是长时间没关注模型平台的价格调整，突然某个月账单翻倍。模型价格是会变化的，成本监控要持续做，甚至可以考虑在配置中心维护多个价格档位对应的模型列表。

第四个坑是流式连接没有正确释放。Java 里响应式流如果没订阅完就断开，连接会一直占着，并发一高线程池就爆了。排查了很久才发现是前端主动关闭了连接，后端检测超时才释放。后来给流式接口加了心跳和超时回收机制才稳定下来。

根据我个人的实践经验，落地 AI 应用本质上不是把模型接进来那么简单，而是一整套工程化的决策和管理。最核心的一点是：永远把降级和成本当成一等功能来设计，而不是上线后再补。每次做模型切换或者提示词修改，先把评测集跑一遍，再灰度，再全量，虽然流程慢一点，但带来的确定性远超省下的那点时间。希望这篇内容能帮你在做 Spring AI 项目时少踩几个坑，把精力真正花在业务价值上。