企业官网建设流程全解析

今年下半年我一直在做 AI 应用的选型梳理，发现一个很明显的现状：大模型已经从“少数团队研究的算法”变成了“几乎所有软件产品都在接入的基础设施”，而真正拉开差距的，早已不是谁家的模型跑分高一点，而是谁更懂“模型和应用怎么组合落地”。这份整理以模型/应用两个维度展开，把国内外主流大模型、典型应用场景、本地部署与微调的关键参数都过了一遍，适合正在做 AI 应用开发、准备接入大模型 API、或者打算本地部署开源模型的同学直接参考。

1. 先看清全景：模型是引擎，应用是车轮

1.1 “模型+应用”为什么是现在的行业主线

大模型不是独立的科研项目，它的价值最终体现在应用里。过去两年大家聊得最多的还是“哪个模型聪明”，到了这个阶段，话题重心明显转向了“模型接进来之后怎么用”。原因很简单：模型能力已经越过了基本可用的门槛，逻辑推理、长文档理解、多模态识别、代码生成这些能力都相对成熟，产品团队现在考虑的不再是“能不能做”，而是“用哪家模型、以什么方式接入、成本怎么控制”。

这条主线下有三个绕不开的关键词：一是推理成本，二是工具调用，三是场景数据。大模型 API 的价格每年都在快速下降，但应用做大了以后推理成本仍然是核心指标；工具调用能力决定了 Agent 能不能真正操作软件、查数据库、调接口；场景数据则是微调价值的来源，通用模型在垂直领域往往差一口气，这口气需要自己的数据去补。

1.2 国内外大模型产业版图速览

先把版本画出来。国际阵营里，OpenAI 的 GPT 系列依然是综合能力的标杆，GPT 的推理模型在数学、代码、复杂任务拆解上有明显优势；Anthropic 的 Claude 系列在长上下文和代码场景口碑很好，Claude 的 Artifacts 功能等于把“对话生成应用”变成了一个实打实的前端工具；Google 的 Gemini 主打多模态原生能力，从文本到图片、视频、音频的跨模态理解一直是强项；Meta 的 Llama 系列是开源阵营的地基，很多本地部署和微调项目都建立在 Llama 之上；xAI 的 Grok 以实时数据和幽默风格出圈，也在快速补齐技术能力；Mistral 的模型则以高效轻量著称，适合做欧洲市场的合规部署。

国内阵营更是热闹。DeepSeek 是这两年开源社区绕不开的名字，它在推理能力和成本控制上做得非常激进，一度让“国产模型也能打”成为共识；阿里的 Qwen（通义千问）系列是覆盖面最全的开源体系，从 0.5B 到 72B 甚至更大参数都有对应版本，Qwen2.5-7B 是最常被拿来微调的入门选择；字节的豆包依托流量生态，在 C 端应用渗透率很高；百度的文心系列结合搜索和云生态，政企项目里出现频率高；智谱的 GLM 系列在中文理解与 Agent 场景上积累深，很多智能体框架的默认模型都支持 GLM；月之暗面的 Kimi 以长文本处理见长，学术论文、合同审查这些场景很受欢迎；MiniMax 在多模态和语音交互上发力，腾讯混元和讯飞星火也都在各自生态里推进。

这些模型各有各的主场。用表格看更直观：

看完这张表，你会发现选模型本质上是在选“约束条件下的最优解”：预算、场景、数据是否可出域、需要的模态类型，这些约束比单点跑分重要得多。

2. 应用维度拆解：大模型到底落在哪里

2.1 从通用助手到生产力工具的演进

大模型最先把应用价值释放给了所有人，典型的载体就是 AI 助手。ChatGPT、Claude、Gemini、豆包、Kimi、文小言这些产品，看似都是“对话框”，其实已经分成两条路线：一条是通用对话助手，什么都能聊，但深度有限；另一条是任务型工作台，围绕写作、编程、分析、翻译来做深做透。

以编程场景为例，GitHub Copilot 和 Cursor 这类工具已经把大模型嵌入了开发者的日常流程，自动补全、跨文件重构、根据 issue 描述直接生成 PR，这些能力背后依赖的都是强大的代码模型。办公场景里，Notion AI、飞书智能伙伴、WPS AI 这类产品把文档生成、会议纪要、数据表格分析做成了按钮级操作。内容创作领域，Midjourney 虽然还是独立应用，但很多团队已经通过大模型的多模态能力把“文生图、图生视频、配音、剪辑”串进了一条流水线。

“大模型应用”这个概念，不再是一个单独的 App，而是一种能力。就像当年的云服务一样，先有物理服务器，然后有云主机，最后大家不再关心机器在哪，只关心服务能不能弹性扩展。现在的 AI 能力正在经历同样的过程。

2.2 行业场景：车联网、企业知识库与 Agent

行业应用的落地比通用助手更有想象空间。车联网里，TBox 加导航定位的应用场景就是把大模型接进车载系统：语音助手结合实时路况、车辆位置、用户习惯，不再只是执行“打开导航”这种指令，而是能主动推荐路线、解释故障码、规划充电路线。这种场景和一般聊天最大的区别是，模型必须同时处理上下文（当前导航状态、驾驶时长）、传感器数据（车速、电量）和 API 调用（地图服务），对实时性和稳定性要求很高。

企业知识库是另一块硬骨头。很多公司想通过“AI 问答机器人”来替代传统的客服和文档检索，但直接用通用大模型会发现它经常胡说。于是 RAG（检索增强生成）成了标配：先把企业文档切片、向量化存入数据库，用户提问时先匹配相关段落，再把检索结果交给大模型生成答案。这种方式的好处是模型不需要记住企业机密，答案都基于检索内容生成，减低了幻觉风险，也方便随时更新知识库。

Agent 则是更高级的形态。一个真正的 Agent 至少要具备任务拆解、工具调用、结果验证三个能力：收到“帮我整理本月销售数据并生成周报”后，它会自己决定先查数据库、再写 Python 脚本做聚合、最后调用文档接口生成报告。这类应用看起来已经远远超出传统聊天机器人，它本质上是一个会使用数字工具的初级员工。

2.3 新手入行：AI 应用开发的学习路线

经常有人问我 AI 应用开发到底要学什么、从哪开始。我给的路线一般是这样：

第一步是掌握提示词工程。别嫌简单，提示词决定了模型输出的下限。你至少要知道如何写清晰的指令、如何给模型示例、如何在多轮对话中控制上下文。很多产品效果不好，不是模型不行，而是提示词太笼统。

第二步是熟悉至少一种大模型 API。以 OpenAI 或国内厂商的 API 为例，学习消息格式、参数调优、流式输出、Token 计算。这个阶段不需要懂数学，但要知道如何用代码和模型对话。

第三步是了解 RAG 和向量数据库。会装一个 Embedding 模型，把文档向量化，再用检索逻辑把结果喂给大模型。这里涉及文本切分、相似度计算、召回质量评估，是工程里最常踩坑的部分。

第四步才是模型微调和部署。微调不是所有项目都需要，但当你需要模型学会特定的风格、术语或业务逻辑时，微调就绕不过去。再往后是部署，涉及 GPU、显存、量化、推理框架，属于工程能力，可以循序渐进。

这套路线走完，你基本能独立做一个 AI 应用的原型了。后面要补的还有 Agent 框架、多模态接口、模型评估体系，但骨架已经有了。

3. 工程实践：微调、本地部署与推理成本

3.1 该微调还是该 RAG？先做决策

很多团队上来就说“要微调模型”，但微调不是万能药。我的判断标准很简单：如果问题出在知识不够，用 RAG；如果问题出在行为不对，再考虑微调。

什么叫知识不够？比如公司产品的售后手册，模型没见过，你问它“这个报错码怎么解决”，它只能瞎编。这种情况喂文档、做检索就能解决。什么叫行为不对？比如客服机器人总喜欢长篇大论解释原理，但公司要的是简洁、带歉意的回答风格。再比如法律文书要求严格按照特定格式，模型总是跑偏。这些不是知识问题，是风格、格式、结构化输出的问题，微调才能真正纠正。

还有一种情况是工具调用能力不足。很多开源小参数模型在“调用函数”上表现不稳，参数填错、格式不对。针对这类能力做微调，效果比提示词工程明显得多。我在实际项目里经常是先上提示词，再上 RAG，等数据攒到一定程度之后，再用微调解决最后那几个顽固问题。

3.2 本地部署配置参考：以 Qwen2.5-7B 为例

本地部署最大的好处是数据不出内网、没有按 Token 计费的压力、可以随意调参。目前开源模型里，Qwen2.5-7B 是一个性价比很高的选择，很多行业微调项目都拿它当基线。

7B 模型是指参数量 70 亿。如果不做量化，FP16 精度下大概需要 14GB 显存用于加载权重，加上推理时的中间缓存，实际建议至少有 16GB 显存。如果有 24GB 显存（比如 RTX 3090/4090），就可以比较舒服地跑 7B 模型，甚至可以尝试 14B 模型的量化版本。热词里有人提到 RX 6750 GRE 训练大模型，A 卡在部分推理框架如 Ollama 里也能用，但生态比 N 卡麻烦，建议优先 N 卡。

推理框架推荐按使用习惯选：Ollama 适合快速体验和本地 API 调用；LM Studio 适合小白可视化；vLLM 适合高并发生产环境；llama.cpp 适合 CPU 和边缘设备。如果只是个人电脑跑着玩，Ollama 一行命令就能起服务，支持 OpenAI 兼容接口，写个 Python 脚本就能调。

量化方案值得多说一句。常见的量化位数是 INT8、INT4，数字越小模型体积越小、显存占用越低，但精度损失越大。以 7B 模型为例，FP16 约 14GB，INT8 约 7GB，INT4 约 4GB。实验的时候可以用 INT4 快速跑通流程，但生产级微调评估最好还是用高精度版本，因为量化后的模型在复杂推理上确实会有可感知的下降。

3.3 微调实战：从数据准备到效果评估

微调的核心不是调参，而是数据。我给微调新手的第一条建议永远是：先花 80% 的时间清洗和构造数据。用 Qwen2.5-7B 微调行业模型，一般流程是这样的：

第一步，准备数据。至少几百条高质量样本，格式用对话式或指令式。对话式的典型结构是 system 设定角色，user 放用户输入，assistant 放期望输出。数据里的输出必须是人工确认过的标准答案，一个文本里不要混入太多噪声。清洗时特别要注意：去掉模型本来就能答对的简单问题，那只会让微调变得无意义。

第二步，设定训练参数。LoRA（低秩适配）是目前微调的主流方案，它只训练一小部分参数，显存占用低。一般设置 4 到 8 的 LoRA rank，学习率 2e-4 到 5e-4，批次大小根据显存调整，轮次通常 2 到 4 轮。如果你是在单卡 24GB 显存上跑，7B 模型配合 LoRA 是可行的，全参微调则建议至少 48GB 以上的显存或使用多卡。

第三步，训练与评估。训练完不要只看 loss，更不要只看训练集上的表现，一定要留一份评测集。评测集不能和训练集同源，最好是从真实场景里抽样。评估维度包括：答案正确率、格式规范性、是否出现幻觉、对敏感问题的拒答表现等。

我记得有个项目需要模型生成工单摘要，刚开始用提示词限制格式，模型偶尔会偷偷多写两句，微调之后这个问题就基本消失了。类似的“行为纠正”是微调最擅长的事情。

4. 常见问题排查与选型避坑指南

4.1 模型选型时先问自己五个问题

面对这么多模型，很多团队反而不知道怎么选。我给自己的决策框架是五个问题：

一是数据能不能出域。数据涉及商业机密、用户隐私，就不能用公有云 API，只能本地部署开源模型，比如 Qwen、Llama、DeepSeek 等。

二是延迟和成本要求。实时对话场景对响应延迟很敏感，要选推理速度快的模型；离线批量处理则更关注单次成本。

三是需要什么模态。纯文本场景可选空间很大；如果需要图片理解、语音输入、视频分析，就必须考虑 Gemini、GPT-4o、Qwen-VL 这类多模态模型。

四是中文能力要求。虽然现在主流模型的中文能力都不弱，但涉及中文古诗词、成语、行业黑话时，国内模型整体表现更稳定。

五是后续可维护性。闭源模型版本更新由厂商控制，可能突然改版；开源模型可以固定版本，但要自己负责升级和 bug 修复。

4.2 应用集成时的典型“暗坑”

接入大模型 API 时，最容易被低估的是成本。开发阶段调用量小，感觉不到；上线之后如果每个请求都带一大堆历史上下文，Token 消耗会翻好几倍。这里有一个习惯养成：及时清理无用上下文，把系统提示词精简到够用为止，嵌入长文本时优先走 RAG 而不是全部塞进提示词。

还有一个常见的坑是“模型热切换”。有些团队在代码里把模型名写死，一旦厂商下线旧版本或者发布新版本，服务直接报错。建议统一封装模型网关层，模型名称、API Key、超时重试都做成配置，切换模型时只改配置文件不动业务代码。

本地部署场景里，如果出现“回答特别慢”或者“CPU 跑满”，多半是没加载 GPU 加速，或者推理框架的线程设置不对。用 Ollama 时可以通过ollama ps看模型是否成功加载到显卡，还可以在环境变量里指定 GPU 层数，把部分层强制放到显存，速度提升非常明显。

4.3 2026 年更值得关注的几个方向

如果眼光放远一点，下面几个方向在 2026 年明显在加速：第一个是多模态更加通用，文本、图片、音频、视频之间的边界在被打破，以后的应用大概率默认支持多模态；第二个是端侧小模型，手机、车机、智能穿戴设备上跑得动的模型越来越强，离线可用会成为卖点；第三个是 Agent 走向工程化，单纯“会聊天”已经不是卖点，能调用工具、跨系统完成任务才是；第四个是推理成本继续下探，开源模型和闭源模型的差距在缩小，本地部署的门槛也在降。

还有一点容易被忽视：模型评估会越来越像软件测试。以后每个 AI 应用项目里都应该有一条“评测流水线”，把核心场景用例固化下来，每次更换模型、修改提示词、调整参数后自动回归测试一遍。我在实际项目里发现，只要坚持做这套评估，模型选型和迭代方向就不会跑偏。

最后分享一点个人体会：不管是做大模型应用还是做微调，最重要的都不是追新模型，而是把场景想清楚。模型的新闻每天都有，版本号更新快得令人焦虑，但用户真正关心的永远是“这个应用帮我解决了什么问题”。先回答好这个问题，再回头选模型，你会发现选项一下子就清晰了。