企业官网建设流程全解析

在 AI 应用快速落地的大背景下，越来越多的开发团队开始把手里的业务系统与大型语言模型（LLM）对接。无论是做智能客服、知识库问答，还是自动化流程编排，都会面对同样的技术选择题：模型怎么选、上下文怎么管理、工具怎么编排、服务怎么部署。本文从工程视角梳理 AI 应用开发的完整链路，包含核心概念、环境搭建、Spring AI 实战代码、模型部署优化以及高频问题排查，适合打算从零开始落地 AI 应用的开发者，也适合想系统补全 AI 工程化知识的后端工程师。

1. AI技术演进与工程化趋势

1.1 当前AI发展的几个明显信号

过去两年，AI 领域最直观的变化是“模型能力增长”与“工程落地”两条线并行。一方面，基础大模型在语言理解、代码生成、多模态理解上的能力持续提升；另一方面，真正让 AI 进入生产环境的，是那些把模型封装成稳定服务的工程链路。早期大家关注的是“哪个模型更强”，而现在更关心的是“能不能稳定地接入业务”。

从开发者视角观察，有几个信号比较明显。开源模型与商业模型的差距在缩小，通过量化、蒸馏、微调等手段，中小团队也可以在消费级硬件上运行可用的大模型；AI 应用从“单次对话”走向“多步骤任务”，开发者不再满足于调用一次模型拿结果，而是希望模型能理解业务上下文、调用外部工具、按流程完成任务；开发工具链越来越完善，Spring AI、LangChain、LlamaIndex、Ollama、vLLM 等工具让 AI 应用开发逐渐标准化；AI 编程工具也进入了日常工作流，基于大模型的代码助手已经能完成相当一部分样板代码和测试代码的编写。这些信号背后有一个共同点：AI 的竞争已经从“谁的模型参数多”转向“谁能把模型稳定、可控、低成本地放进业务系统”。

1.2 从模型能力到工程落地的转变

早期使用 AI 的方式很简单：把问题丢给模型，拿到回答。这种方式在个人场景足够，但在企业级系统中远远不够。企业需要的是稳定的响应时间与吞吐、可解释可审计的决策过程、与现有业务系统（订单、用户、库存）的安全集成、数据不出内网或符合合规要求，以及成本可控、预算可预测。这些诉求把问题从“模型有多强”转移到了“系统如何设计”。

同样的模型，在不同团队手里的最终效果可能差别很大。区别在于是否有完善的提示词管理、数据接入、上下文组织、工具调用、异常兜底和性能监控。换句话说，AI 竞赛的下半场是工程化能力的较量。一个模型能力突出但没有配套工程链路的系统，很难在真实业务中长期稳定运行；反过来，工程链路完善但模型选型一般的系统，往往也能通过提示词、检索增强和流程编排达到不错的效果。

1.3 技术生态的差异化路径

不同技术生态在 AI 落地方式上各有侧重。有些团队擅长快速迭代原型，把 AI 功能嵌入现有产品，利用成熟的开源生态降低起步成本；有些团队则更重视底层基础设施，从模型训练、微调到推理优化都自主掌控。这两种路径没有绝对优劣，更多是资源禀赋和业务需求的差异。

对开发者来说，与其争论哪种模式更好，不如掌握通用的 AI 工程技能——数据准备、模型调用、RAG、Agent 编排、部署监控。这些能力无论技术风向怎么变，都能快速迁移。本文后面介绍的本地模型部署、Spring AI 集成、向量检索等方法，也是围绕这条主线展开的，理解了这些通用能力，你再去看任何新的 AI 框架都会轻松很多。

2. AI开发环境准备与工具链

2.1 基础运行环境

在动手写代码之前，先梳理一套比较通用的开发环境。版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路。操作系统方面，Windows 10/11、macOS 或 Linux 都可以；如果是 Java 开发，建议 JDK 17 及以上，因为 Spring Boot 3.x 需要 JDK 17 作为基础；Maven 建议 3.8 以上，用于管理项目依赖；如果需要做数据处理或模型微调，可以准备 Python 3.10 以上的环境；模型服务方面，可以选择云端 LLM API，也可以使用 Ollama 在本地运行开源模型。

如果本机还没装 Ollama，可以到官网下载对应系统的安装包。安装完成后，在命令行执行ollama list能正常输出，就说明安装成功。对初学者来说，本地模型最大的好处是调试不花钱、数据不出本机，等逻辑跑通之后再迁移到云端或服务器，成本结构会更清晰。

2.2 模型接入方式

AI 应用开发首先需要确定“模型从哪里来”。常见方式有两类。第一类是调用云端大模型 API，优点是接入简单，不用关心 GPU 和部署，按量付费，接口标准；缺点是数据会发送到外部服务，成本随调用量线性增长，适合业务验证期和中小流量场景。第二类是本地部署开源模型，通过 Ollama、vLLM 等工具，把 Qwen、Llama 等开源模型跑在自己的服务器上，数据不出内网，长期调用成本可控；缺点是需要准备一定配置的 GPU 服务器，运维复杂度更高，模型更新也需要自己维护。

对初学者来说，建议先从云端 API 或本机 Ollama 开始，把应用逻辑跑通之后，再根据业务需求决定是否迁移到私有化部署。选择模型时，除了关注榜单分数，还要看社区活跃度、许可证、生态工具是否完善。一个生态完善但分数略低的模型，在实际工程中往往比一个分数高但资料稀缺的模型更好落地。

2.3 开发框架选择

常见的 AI 应用开发框架主要有三个方向。LangChain 是 Python 生态中最成熟的 AI 编排框架，适合快速做 RAG、Agent 原型；LlamaIndex 偏向数据索引与知识库问答，RAG 场景功能很强；Spring AI 面向 Java/Spring 生态，可以把 AI 能力嵌入既有 Spring Boot 服务，对后端团队非常友好。如果你所在团队以 Java 为主，第 4 章的 Spring AI 实战会更贴近实际工作；如果你更熟悉 Python，LangChain 和 LlamaIndex 的学习成本会低一些。

框架不是关键，关键是理解背后的核心概念。无论用哪个框架，你都会遇到提示词管理、文本向量化、检索召回、工具调用、流式输出、成本统计这些通用问题。先把这些概念吃透，再选一个你熟悉的框架动手实践，学习效率会高很多。

3. AI工程实践核心概念拆解

3.1 提示词工程：让模型输出更可控

提示词工程（Prompt Engineering）是 AI 应用开发最基础的技能。它解决的问题是：通过设计输入给模型的指令，让模型输出更符合预期。一个完整的提示词通常包含角色、任务、上下文、输出格式和约束条件等要素。角色是告诉模型“你是一个什么角色”，例如“你是一位资深 Java 架构师”；任务是明确要求模型做什么，例如“请审查以下代码中的线程安全问题”；上下文是提供必要的背景信息，例如业务规则、已知约束；输出格式是约束输出结构，例如“输出为 JSON，字段包括 errorType 和 suggestion”；约束条件是说明不能做什么，例如“如果信息不足，请回答‘信息不足’，不要推测”。

下面是一个提示词模板示例：

你是一名运维工程师，负责处理用户提交的技术工单。 请根据以下工单内容，判断问题类型（网络/数据库/应用/其他）， 并给出排查步骤。 工单内容： {work_order} 输出格式： {"type": "问题类型", "steps": ["步骤1", "步骤2"]}

在实际项目中，提示词不应该散落在代码里，建议统一维护在配置中心或单独的提示词文件中，方便迭代和回滚。提示词也是需要版本管理的，每次修改都要有记录，否则上线后很难定位是模型问题还是提示词变化导致的效果波动。

3.2 RAG：让模型拥有“私有知识”

大模型的知识来自训练数据，遇到训练时间之后的信息、企业内部文档、特定业务规则时，模型往往会答错。RAG（Retrieval-Augmented Generation，检索增强生成）是解决这个问题的常用方案。它的基本流程可以拆成四步：文档切分、向量化、检索、生成。文档切分是把 PDF、Word、Markdown 等文档按段落或固定长度切分成小块；向量化是用嵌入模型把每个文本块转成向量，存入向量数据库；检索是用户提问时，把问题也转成向量，在向量数据库中检索最相关的若干文本块；生成是把检索到的文本块与用户问题一起拼进提示词，交给大模型生成回答。

整个过程可以用下面这段伪代码表达：

def rag_answer(question: str) -> str: # 1. 生成问题的向量 question_vector = embedding_model.encode(question) # 2. 从向量库检索TopK相关文档 docs = vector_store.search(question_vector, top_k=3) # 3. 拼接上下文 context = "\n\n".join(doc.content for doc in docs) prompt = f"基于以下资料回答问题：\n{context}\n\n问题：{question}" # 4. 调用大模型生成 return llm.generate(prompt)

RAG 的关键在于“检索质量”。如果检索到的文档与问题无关，模型生成得再好也无济于事。因此，文档切分的粒度、嵌入模型的选择、TopK 参数都需要针对业务数据做调优。此外，还要考虑文档更新频率，知识库内容变了，向量库里的旧向量是否要清理、多久重建一次索引，这些问题在长期运行中都会暴露出来。

3.3 AI Agent：从“回答问题”到“完成任务”

如果说 RAG 解决的是“知识来源”问题，AI Agent 解决的是“行动能力”问题。Agent 可以让模型自主规划步骤、调用外部工具、观察执行结果，并在必要时调整策略。一个典型的 Agent 循环包含以下环节：接收用户目标；模型规划需要哪些步骤；调用工具（查询数据库、调用 API、执行命令）；把工具返回结果反馈给模型；模型判断是否达成目标，未达成则继续执行下一步。

工具调用（Function Calling / Tool Calling）是 Agent 的核心能力。模型本身不执行代码，但它可以输出一个结构化的“调用意图”，由程序去真正调用对应函数。下面是一个工具定义的简化示例：

{ "name": "query_order_status", "description": "查询订单状态", "parameters": { "type": "object", "properties": { "order_id": {"type": "string", "description": "订单号"} }, "required": ["order_id"] } }

当用户问“我的订单 2001 什么时候发货”时，模型会输出调用query_order_status的意图，并填入order_id=2001，程序拿到这个意图后执行真实查询，再把结果交给模型组织自然语言回复。开发 Agent 时需要注意两个问题：一是给工具的 description 要写清楚，模型靠它判断什么时候该调用哪个工具；二是要设置最大迭代次数和超时时间，防止 Agent 陷入死循环。

4. Spring AI集成实战

Spring AI 是 Spring 官方推出的 AI 应用开发框架，目标是让 Java 开发者用熟悉的 Spring 风格接入大模型。下面我们用 Spring AI + Ollama 本地模型，实现一个最简的对话接口和 RAG 问答接口。

4.1 创建项目结构

为了方便跟随操作，我们先把工程目录结构确定下来。可以使用 IDEA 的 Spring Initializr 新建项目，也可以手写 pom.xml 后导入。如果选择 Spring Initializr，可以直接勾选 Web 与 Spring AI 依赖，IDE 会自动生成标准目录结构；这里我们以手写为主，方便看清每一步。创建完成后，把 pom.xml、启动类、控制器与服务类分别放入对应位置，包名统一使用com.example.aidemo。

整体结构如下：

spring-ai-demo ├── pom.xml └── src └── main ├── java │ └── com │ └── example │ └── aidemo │ ├── AidemoApplication.java │ ├── controller │ │ └── ChatController.java │ └── service │ └── ChatService.java └── resources └── application.yml

4.2 添加依赖

在pom.xml中引入 Spring Boot 与 Spring AI 相关依赖。Spring AI 版本迭代比较快，不同版本的依赖坐标和 API 可能有差异，本文示例思路以常见稳定版本为准。建议使用 Spring AI BOM 统一管理版本，具体版本号请以官方最新稳定版为准，避免因为手动指定不兼容版本导致启动失败。

<parent> <groupId>