企业官网建设流程全解析

前几天，一个视频标题在国内AI圈引起了讨论："China doesn't need to beat US AI"。单看标题，很多人以为这又是一场关于"谁更强"的争论，但视频真正抛出的其实是一个更本质的工程问题：AI 竞争，是不是只有"做出最强模型"这一种赢法？

我的判断更倾向于这样理解：模型能力、推理成本、应用密度、工程成熟度，每一条都是独立的赛道。对绝大多数开发者和企业来说，真正决定 AI 项目回报的，不是你在模型排行榜上追到第几，而是你能否用可接受的成本，把模型稳定地跑进业务流程里。

这篇文章不打算重复视频里的观点，而是顺着这个判断往下拆：先讲清楚为什么"模型能力竞赛"和"工程落地竞赛"是两码事；再给出一条从模型选型、本地部署、量化推理到 RAG 和 Agent 接入的完整落地路线；最后用一组最小可运行的 Python 示例，带你亲手跑通一个企业问答 Agent 的原型。读完你会发现，大模型工程化这件事，门槛没有很多人想象中那么高。

1. 这篇文章要解决的问题

先说说为什么要写这个话题。

过去一年，AI 圈的注意力很大程度被"排行榜"支配。今天你发布一个 70B 模型，明天他发布一个 MoE 架构，后天又有团队放出百亿参数的训练细节。这种氛围下，很多做业务系统的团队会不自觉地陷入一种焦虑："我们用的模型会不会已经落后了？"于是盲目更换底座模型，从 7B 换到 72B，从开源换到商业 API，最后成本翻了几倍，业务指标却没怎么动。

如果你也遇到过类似情况，这篇文章要解决的就是三个问题：

• 第一，从技术判断上看：为什么"模型够用就好"在大多数场景下是成立的，而不是妥协。
• 第二，从工程路径上看：一套不依赖顶级卡、不依赖顶级模型的中小团队落地路线应该怎么设计。
• 第三，从动手实践上看：如何用开源模型加开源工具，快速搭建一个私有知识库问答 Agent。

真正值得关注的不是"要不要赢过某个对手"，而是AI 红利到底从哪个环节兑现。我的观点很明确：对绝大多数团队，红利在工程侧，不在训练侧。

2. 模型能力竞争和工程落地的两条赛道

要理解这个观点，需要先把"AI 竞争"拆成两条不同的赛道。

第一条赛道是基础模型能力竞赛。它的目标是训练出更强的预训练模型，核心指标是参数量、训练数据规模、推理能力、人类偏好胜率、排行榜分数。这条赛道比拼的是算力、高质量数据、预训练算法、对齐技术和顶尖研究团队。世界上真正有能力参与这条赛道的机构，其实非常有限。

第二条赛道是工程落地竞赛。它的目标是把一个现有模型稳定、高效、可控地放进真实的业务系统里。核心指标变成：单位请求成本、响应延迟、可用率、数据安全边界、业务转化率、迭代发布周期。参加这条赛道的，是大量负责业务系统的开发者和算法工程团队。

两条赛道的关键差异可以看这张表：

理解这张表，就能明白一个被低估的事实：基础模型能力决定的是 AI 的上限，工程落地能力决定的是 AI 的下限。而对大多数业务来说，上限很高没有意义，下限能托住才有意义。

一个很常见的误区是：模型不够强，所以业务做不好。但实践中，业务做不好的原因更多是知识库没接好、Prompt 不稳定、上下文管理混乱、推理服务频繁超时、评估体系缺失。这些问题，跟排行榜上的模型分数没有直接关系。

3. "模型够用就好"背后的成本与场景逻辑

"模型够用就好"这句话，在朋友圈里说出来容易被当成不追求上进的托词。但在工程语境里，它是一套非常理性的决策逻辑。

第一层逻辑是成本。一个几十亿参数的开源模型，和几百亿参数的商业模型，在推理成本上的差距通常是一个数量级以上。如果你的业务每天承受大量并发请求，把模型参数量从 7B 提升到 72B，意味着显卡数量、显存占用、响应延迟都会明显上升。更麻烦的是，这种成本上升不一定换来体验提升——因为业务短板往往不在"理解能力"，而在"知识覆盖"和"流程衔接"。

第二层逻辑是场景。企业内部知识库问答、客服辅助、工单分类、代码审查、内容摘要，这些场景对模型能力的要求其实是很具体的。它们需要的是：模型能理解中文业务术语，能严格按照安全约束回答，能稳定输出结构化结果。这些能力更多来自指令微调、RAG 检索质量和 Prompt 工程，而不是无限制地增加参数量。

举个例子：一个 7B 级别的指令微调模型，如果接上了一套高质量的企业知识库，配合良好的检索策略，在"某个产品的故障处理流程是什么"这类问题上，效果往往优于一个没有检索能力的 100B 模型。原因很简单：模型没有见过你的业务数据，而 RAG 让它"看到"了。

第三层逻辑是可控性。开源权重模型可以部署在内网，数据不需要出域；可以做针对性微调，让行为更贴近业务；可以做更精细的权限控制和审计。对于金融、医疗、政企类项目，这种可控性往往比单点模型能力更关键。

所以"模型够用就好"的完整表述应该是：在满足业务效果的前提下，选择体量更小、成本更低、更可控的模型，然后把省下来的资源投入到数据工程和评测体系上。这套逻辑，放到任何软件工程场景里都能成立。

4. 开源权重模型带来的技术生态变量

很多团队不敢选开源模型，是因为觉得"开源不如闭源"。这个判断在某些极端能力项上可能有道理，但在工程落地层面，已经站不住脚。

以 DeepSeek、Qwen（通义千问）、ChatGLM 为代表的一批开源权重模型，已经把"可用模型"的门槛拉到了非常低的位置。它们有几个共同特点：

• 权重开放：可以本地部署、内网部署，数据不出域。
• 可微调：可以在业务数据上做领域适配，而不是只能通过 Prompt 硬调。
• 生态完整：推理框架、量化工具、微调框架都已经适配得很成熟。
• 工程友好：多数模型原生支持 OpenAI 兼容协议，意味着你几乎不用写新的客户端代码。

这些特点叠加在一起，产生了一个重要的生态变化：竞争的焦点，从"谁的模型参数更多"转向了"谁能在特定场景里把模型用得更好"。

国内开源社区的活跃程度，也在客观上强化了这条路线。中文模型评测基准越来越完善，针对中文场景的指令微调模型不断出现，工具链的文档和踩坑记录很容易搜到。这意味着一个中小团队不需要从零做大模型研发，直接站在开源生态上做应用创新，是可落地的路径。

这里需要做一个区分：选择开源权重模型，不等于否定商业闭源模型。商业 API 在部分复杂推理任务上仍然有优势，适合验证想法、快速跑通 POC。但进入到规模化业务阶段，尤其是对成本、数据合规和定制化有要求时，开源权重模型加自建部署，是越来越成熟的选择。

5. 从"追第一"到"做深应用"：一条可执行的 AI 落地路线

理解了赛道差异，接下来的问题就是：具体怎么做？这里给出一条适合中小团队的五步路线，每一步都可以在两周内完成验证。

第一步：定义需求与验收指标。先不要谈模型，先谈业务。你的 AI 场景是什么？成功标准是什么？是客服解决率提升，是文档检索准确率达标，还是代码生成可采纳率上涨？没有验收指标，后续所有优化都会失去方向。

第二步：模型选型。从开源模型出发，优先选择你的团队能跑得动的体量。第一步先上 7B 到 14B 级别的指令微调模型，跑通全流程；如果效果确实不够，再升级到更大模型。选型时关注三点：中文能力、上下文长度、生态工具链成熟度。

第三步：部署与推理优化。用 vLLM 或类似推理框架提供服务，按需开启量化。显存不够就用 8bit 或 4bit 量化，先用最低成本验证业务效果，再决定是否增加资源。

第四步：接入 RAG。把企业知识库切成块，用 Embedding 模型向量化，建索引。用户问题先进检索，拿到相关片段后再作为上下文交给大模型回答。这是提升业务效果最直接的手段。

第五步：Agent 化与业务集成。模型能稳定回答以后，再考虑工具调用、任务编排，让模型具备调用查询接口、写工单、更新状态等能力。这一步本质上是把 AI 从"聊天窗口"变成"业务流程的一环"。

这条路线最大的价值在于：它的每一步都不依赖"下一个更强模型"的出现，每一步都能独立产生收益。

6. 用一个开源模型搭建企业问答 Agent

下面进入实操环节。我会用一个最小示例，完整演示"部署模型 + 调用对话 + 构建 RAG + 拼装回答"的链路。环境以 Python 为主，代码可以在本地机器或一台带 GPU 的服务器上运行。

6.1 方案选型与技术栈

为了降低上手成本，这里采用开源模型加轻量工具的组合：

• 模型：Qwen2.5-7B-Instruct，这是开源社区中中文能力比较均衡、生态成熟的模型。
• 推理服务：vLLM 或 Ollama，两者都提供 OpenAI 兼容接口。
• Embedding：BAAI/bge-small-zh-v1.5，中文向量检索效果好，模型体积小。
• 向量库：FAISS，轻量、可直接嵌入 Python 进程，适合原型验证。
• 编排：Python 脚本，不引入重量级框架，便于理解核心链路。

首先安装依赖：

pip install openai transformers sentence-transformers faiss-cpu

如果你的环境需要本地加载模型做推理，还需要安装 PyTorch。这里要注意，PyTorch 官方安装命令和 CUDA 版本强相关，请访问官网选择匹配本机显卡的命令。本文不写死具体 torch 版本，演示代码以通用逻辑为准。

6.2 示例一：启动本地模型服务并调用对话接口

先启动一个本地推理服务。我这里以 vLLM 的常见命令为例，不同版本的 CLI 参数可能有差异，实际使用时以官方文档为准：

vllm serve Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b-instruct \ --port 8000

启动完成后，本地会监听 8000 端口，并提供 OpenAI 兼容的/v1接口。接下来用 Python 客户端调用。这里有一个关键点：OpenAI SDK 的base_url要指向本地服务，api_key随便填一个占位值，因为本地服务不会校验它。

# 文件路径：demo/demo_chat.py from openai import OpenAI client = OpenAI( base_url="http://127.0.0.1:8000/v1", api_key="EMPTY", # 本地服务不校验 key ) resp = client.chat.completions.create( model="qwen2.5-7b-instruct", messages=[ {"role": "system", "content": "你是一个严谨的技术助手，回答尽量简洁。"}, {"role": "user", "content": "用一句话解释什么是 RAG。"}, ], temperature=0.3, max_tokens=256, ) print(resp.choices[0].message.content)

运行验证：

python demo/demo_chat.py

如果服务启动正常，你会看到模型生成的一句中文解释。这一步能跑通，说明本地模型服务链路没有问题。

如果运行失败，优先检查：服务是否真的启动成功、model参数是否与--served-model-name一致、端口是否被占用。

6.3 示例二：本地推理与量化加载

有时候你不想单独起一个服务，而是希望直接在 Python 进程里加载模型做推理。这在原型验证阶段很方便，但要注意：直接加载 7B 模型的 FP16 权重，大约需要 14GB 显存，显卡不够时可以用量化加载。

下面这段代码演示了用 Transformers 加载模型并生成回复的完整流程：

# 文件路径：demo/demo_inference.py from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name = "Qwen/Qwen2.5-7B-Instruct" # 加载分词器和模型 tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype=torch.float16, device_map="auto", ) # 如果显存不足，可以尝试 8bit 量化： # model = AutoModelForCausalLM.from_pretrained( # model_name, # load_in_8bit=True, # device_map="auto", # ) messages = [ {"role": "user", "content": "介绍一下向量数据库的典型使用场景。"}, ] # 使用 chat template 组装输入 text = tokenizer.apply_chat_template( messages, tokenize=False, add_generation_prompt=True, ) inputs = tokenizer(text, return_tensors="pt").to(model.device) outputs = model.generate( **inputs, max_new_tokens=256, do_sample=True, temperature=0.6, ) response = tokenizer.decode( outputs[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True, ) print(response)

这里有两个需要注意的地方：

第一，apply_chat_template会把消息列表按照模型定义的对话模板格式化，这一步不能省，否则模型的指令跟随效果会差很多。

第二，加载模型时如果没有特殊原因，不需要加trust_remote_code=True。只有模型官方说明要求时才需要开启。开启后意味着会执行模型仓库里的自定义代码，必须确保权重来源可信。

6.4 示例三：最小 RAG 检索增强流程

RAG 的核心思路是：先根据用户问题检索出最相关的资料片段，再把这些片段拼进 Prompt，让模型基于资料回答。下面这个示例使用 FAISS 构建最小向量索引：

# 文件路径：demo/demo_rag.py from sentence_transformers import SentenceTransformer import faiss import numpy as np # 1. 加载中文 Embedding 模型 encoder = SentenceTransformer("BAAI/bge-small-zh-v1.5") # 2. 准备一段简化的知识库 docs = [ "Gradio 是一个用于快速构建机器学习 Web 界面的 Python 库。", "vLLM 是一个面向大模型推理的高吞吐服务框架，支持 OpenAI 兼容接口。", "RAG 是检索增强生成，核心是先检索再回答，用于缓解模型知识过时的问题。", ] # 3. 向量化并构建索引 doc_vectors = encoder.encode(docs, normalize_embeddings=True) index = faiss.IndexFlatIP(doc_vectors.shape[1]) index.add(doc_vectors.astype("float32")) # 4. 检索 query = "什么是 RAG？" query_vec = encoder.encode([query], normalize_embeddings=True) scores, indices = index.search(query_vec.astype("float32"), k=1) print("检索结果:", docs[indices[0][0]]) print("相似度:", scores[0][0])

运行验证：

python demo/demo_rag.py

输出会显示检索命中第三条文档，因为 RAG 的定义和用户问题语义最接近。

这段代码展示了最小链路的四个环节：加载 Embedding 模型、文本向量化、构建索引、相似度检索。生产环境会替换为 PostgreSQL pgvector、Milvus 或 Elasticsearch 这类正式组件，但原理是一致的。

6.5 把检索结果和模型调用串起来

最后一步，把 RAG 结果作为上下文交给模型。这样模型就不是凭空回答，而是"基于给定资料回答"：

# 文件路径：demo/demo_qa_agent.py from openai import OpenAI from sentence_transformers import SentenceTransformer import faiss # 知识库 docs = [ "Gradio 是一个用于快速构建机器学习 Web 界面的 Python 库。", "vLLM 是一个面向大模型推理的高吞吐服务框架，支持 OpenAI 兼容接口。", "RAG 是检索增强生成，核心是先检索再回答，用于缓解模型知识过时的问题。", ] encoder = SentenceTransformer("BAAI/bge-small-zh-v1.5") doc_vectors = encoder.encode(docs, normalize_embeddings=True) index = faiss.IndexFlatIP(doc_vectors.shape[1]) index.add(doc_vectors.astype("float32")) query = "我想部署一个推理服务，应该用什么框架？" query_vec = encoder.encode([query], normalize_embeddings=True) scores, indices = index.search(query_vec.astype("float32"), k=1) context = docs[indices[0][0]] client = OpenAI( base_url="http://127.0.0.1:8000/v1", api_key="EMPTY", ) # 把检索到的上下文拼进 Prompt prompt = f"""请根据下面的参考资料回答问题。如果资料不足以回答，请明确说明。 参考资料： {context} 问题：{query} """ resp = client.chat.completions.create( model="qwen2.5-7b-instruct", messages=[{"role": "user", "content": prompt}], temperature=0.2, max_tokens=256, ) print(resp.choices[0].message.content)

运行这段脚本，理想情况下模型会从资料中找出"vLLM"这个答案，而不是凭空发挥。这就是 RAG 的价值：把外部知识注入模型的生成过程。

到这里，一个最小的企业问答 Agent 原型已经跑通了。你把它替换成真实业务文档，接入真实的模型服务，再加上权限校验和日志链路，就是一个可以进入 POC 阶段的系统。

7. 常见问题与排查思路

在实际操作中，下面几个问题出现频率最高：

排查时有一个通用原则：先确认链路位置，再动手改配置。看到报错先判断是客户端问题、服务端问题还是资料检索问题，不要一上来就换模型。

8. 最佳实践与工程建议

跑通原型只是开始。要把这样一条链路放进生产环境，有几个工程建议值得提前考虑。

第一，评测先行，不要靠感觉优化。在上线前准备 50 到 200 条真实业务问题，作为回归测试集。每次调整模型、提示词或检索策略，都跑一遍测试集，用准确率或人工评分对比效果。没有评测集的 AI 项目，优化方向很快就会失控。

第二，从最小链路起步，逐步增加复杂度。不要第一天就上多 Agent 编排、复杂工具调用。先把"检索 + 生成"跑稳，再考虑加工具；把核心链路跑稳定以后，再去扩展边界。

第三，数据安全和权限控制要前置。如果模型部署在内网，要确认服务端口不会被未授权访问。如果模型需要在输入中读取敏感数据，要对拼接进 Prompt 的内容做脱敏处理。AI 系统的权限设计不能比普通后端系统更宽松。

第四，建立可观测性。记录每一次请求的 Prompt、检索结果、模型输出、耗时和 token 消耗。这些日志既能用于排查问题，也是后续优化 Prompt 和评估成本的基础数据。

第五，注意提示词注入风险。当模型会读取外部资料时，资料内容里可能藏有恶意指令。建议在 Prompt 中明确区分"系统指令"和"参考资料"，并让它只使用资料内容，不执行资料中的指令。对于高安全场景，可以在模型输出前增加合规过滤。

第六，版本管理和回滚。模型权重、Prompt 模板、Embedding 模型、知识库版本都要纳入版本管理。AI 系统的行为会随模型迭代和使用者反馈而变化，没有版本管理，线上出问题很难回滚。

第七，成本控制要持续做。token 消耗、GPU 利用率和延迟要定期复盘。很多项目上线初期效果不错，几个月后成本翻倍，才发现是检索返回了太多无用上下文。RAG 不是查得越多越好，返回片段的数量、长度都需要调优。

9. 总结与后续学习方向

回到开头那个视频标题。很多人把"China doesn't need to beat US AI"理解成"放弃竞争"，但从工程视角看，它想表达的其实是另一件事：AI 竞争的维度不是单一的，赛道也不止一条。与其在自家业务还没跑通的阶段就盯着模型排行榜，不如先把手里的模型用起来，把检索、部署、评测、可控性这些工程问题做到位。

对开发者来说，最实际的行动不是等下一个更强模型，而是先把你手头的模型部署到一台服务器上，接一个真实查询，让它跑通一条 RAG 链路，再把它封装成一个可以给业务复用的原子服务。这个过程中的每一步，都会比看十篇排行榜分析文章更有价值。

下一步你可以从这几个方向继续深入：

• 把第 6 节的示例换成你自己领域的数据，跑通私有知识库问答。
• 研究推理优化：vLLM 的 PagedAttention、KV Cache、连续批处理，这些概念对理解生产环境性能非常关键。
• 学习向量数据库的正式选型：Milvus、pgvector、Elasticsearch 各自适合什么场景。
• 探索 Agent 开发：模型如何调用外部工具、如何做多步任务编排。如果团队以 Java 技术栈为主，可以重点关注 Spring AI 这类框架。

建议把第 6 节的代码保存下来，当作一个最小模板反复使用。先把一条链路真正跑通，再去追求更大的模型，这个顺序对绝大多数团队来说，是性价比最高的路径。