企业官网建设流程全解析

这段时间团队里天天有人在群里问，能不能把GPT-6、Claude Opus 5.5这些新模型接到项目里来用。开发想用API做自动化测试，运营想做内容生成，产品又盯着多模态识图不放。作为技术负责人，这个问题听起来简单，真正落地的时候却绕不开选型、成本、安全和团队协作一堆事。这篇文章我不打算堆概念，就按我们团队实际走过的流程，把从评估到上线的关键决策和坑点完整讲一遍，适合正在做技术规划、或者刚被老板丢来一句“接入大模型”的负责人参考。

1. 接入前先想清楚：场景清单、接入方式和模型选型

1.1 先别急着调API，把团队的场景清单拉出来

我见过不少团队，第一步就找销售要了API Key，然后让后端写个通用接口，结果上线两周后才发现，业务部门要的“AI”根本不是同一个东西。有人要的是聊天问答，有人要的是结构化信息抽取，还有人只是想用AI给图片写描述。如果一开始不把场景定义清楚，后面所有选型都是盲猜。

建议先做一次内部需求盘点，问三个问题：这个场景对回答准确性要求高不高？数据能不能出公网？单次交互是短对话还是长文档？把答案汇总成一张场景清单，每个场景标明优先级、调用频率、敏感等级。比如内部知识库问答，数据敏感但调用频率低，适合私有化模型；客服工单分类，准确率要求中等、调用量大，用云端API更划算；代码辅助生成，上下文长且涉及代码安全，最好在网关层做内容脱敏。

我们当时梳理出12个内部场景，最终只选了5个进入第一期。把“想用AI”和“必须用AI”分开，第一期只做ROI最明显的三个。这个步骤看似花时间，实际是给后面省几周的扯皮。

1.2 API调用和私有化部署不是二选一，而是可以组合

接入方式大致分两条路：直接调用云端API，或者在内部私有化部署开源/商业模型。很多技术文章喜欢把两条路对立起来，真实团队往往是混用。云端API胜在省事，GPT-6、Claude Opus 5.5这类最新模型的能力门槛低，几乎不需要运维，但数据会经过第三方服务，敏感业务要慎用。私有化部署则意味着你拿回控制权，可以用开源模型自己跑，但需要GPU资源、推理优化和持续的模型维护。

我给的建议是先画一条数据边界线。凡涉及用户隐私、企业内部文档、未公开代码的场景，一律走私有化；其他偏通用、低风险、对最新能力有依赖的场景，可以放心用云端API。两套体系之间用统一网关隔离，外部模型和内部模型对业务层暴露相同的接口，后续切换模型时业务代码不用动。

这里还要考虑团队基础。如果没有懂推理优化的同学，一开始就上vLLM、TensorRT-LLM这类重型方案容易翻车。先拿Ollama起步，把链路跑通，再逐步换成生产级别的服务框架。我们第一期就是API和Ollama并跑，第二期才引入了vLLM。

1.3 模型选型：不要只盯着完成度，还要看上下文和成本

团队选模型时最容易犯的错，是拿一个测试用例反复对比谁回答更“聪明”。真实生产里，决定模型能不能落地的是上下文长度、推理速度、成本、工具调用能力这几个硬指标。拿上下文长度举例，GPT-6、Claude Opus 5.5这类新一代模型的上下文窗口都在百K量级，看起来很强，但窗口越长，单次请求的成本和延迟都直线上升。如果业务根本不需要一次塞进几十万字，选小一号的模型性价比反而高。

具体要拉一张模型对比表，列上模型商、上下文长度、输入/输出价格、延迟、是否支持结构化输出、是否支持作图和附件输入。记得把“有效上下文”也测一下，很多模型标称支持200K，实际上超过一定长度就开始遗忘中间内容或重复输出。

另外要把开源模型纳入选项。现在Qwen、Llama、还有社区里流传的各种新模型，在7B到70B这个区间都有成熟的中文能力。不要因为团队用了几个云端API就忽视本地模型，很多内部工具用7B模型就够了，成本和响应速度都更优。

2. 搭建团队统一接入层：网关、Dify和本地模型服务

2.1 用统一API网关管钥匙、配额和日志

如果每个部门各申请一个API Key，直接对着模型厂商调接口，短期爽，长期就是灾难。钥匙散落、额度混乱、账单分不清哪笔是谁花的，出了问题也很难定位。我们的做法是在模型前面加了一层统一API网关，所有请求都走这个网关，由网关负责路由到云端API或本地模型服务。

网关至少要具备四个能力：第一，Key统一管理，每个团队分发独立的AccessKey，密钥不落地到业务代码里；第二，限流和配额，按部门或应用设置每分钟/每小时的调用上限，防止一个人把预算烧完；第三，日志和审计，记录每次请求的模型、token消耗、耗时和结果状态，这一步对后期优化成本至关重要；第四，模型路由，可以在不修改业务代码的情况下把流量切换到不同模型。

实现上可以自己用FastAPI写一个几十行的代理，也可以直接用开源API网关。如果团队已经有网关设施，就添加上游转发逻辑。关键是让业务方只看到“一个AI接口”，而不是“一堆模型账号”。

2.2 本地私有化部署：Ollama与vLLM怎么选

私有化部署不是只有一种姿势。我个人的建议是：实验和开发环境用Ollama，生产环境用vLLM。Ollama胜在极简，一条命令就能把一个开源模型跑起来，对硬件要求也不高，适合团队快速试错。但它的高级功能相对少，并发吞吐和扩展性不如vLLM。

vLLM的部署方式也很直接。先写一个配置好的启动命令：

vllm serve Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --max-model-len 32768 \ --served-model-name qwen7b \ --port 8000

启动后就能拿到一个兼容OpenAI格式的接口，业务端几乎不用改代码。这里的--max-model-len要特别注意，它决定了模型最多能接收多长的上下文，同时也直接影响显存占用。不是设得越大越好，要根据实际场景测算，设太大会导致OOM。

选型时还要看团队对推理引擎的熟悉程度。如果没人接触过CUDA优化，先用Ollama跑通流程，再迁移到vLLM不迟。另外，模型文件下载和存储要做好版本管理，像下载离线包之类的操作，尽量在CI流水线里固化，避免每台机器手动装。

2.3 用Dify把模型、知识库和业务串起来

如果你的团队不只是写代码，还有运营、产品、客服这些不太熟悉技术的角色想用AI，那就需要一个“低代码”层。Dify这类工具的价值是把模型接入、Prompt编排、知识库、工作流和Agent能力封装成可视化界面。我们可以把本地模型或云端模型先接入Dify，然后让业务同事自己搭应用，不需要等待研发排期。

比如把GPT-6或Claude Opus 5.5接入Dify后，运营可以自己创建一个“公众号文案生成器”，把常用的Prompt模板、品牌风格指南都配好，生成结果不满意就自己在界面里改。研发要做的是把Dify里的应用封装成API，供内部系统调用。

Dify也可以挂接内部知识库，实现简单的RAG。注意知识库文档的更新频率和分片策略。我们踩过坑：直接把几万字合同扔进去，结果检索出来的片段不完整，回答充满编造。后来按章节分块，加上重叠片段，效果才稳定下来。

3. 实操记录：从零到上线的一次完整接入流程

3.1 需求收集与技术评估：用一周时间跑通第一个试点

我们的第一期选了一个相对简单的场景：客服工单分类。之前客服要手动给工单打标签，每天几百条，准确率和效率都一般。这个场景敏感度低、数据量明确、评估标准简单，非常适合做试点。

流程是这样的：先拉出最近三个月的工单样本，去掉隐私字段，让模型做多分类，拿结果和历史标注对比，算精确率和召回率。同时测试不同模型的响应时间和成本。测试时不要只看模型“聪不聪明”，要看它稳定不稳定。同一个问题换几个说法测试，看看会不会出现明显漂移。

当时对比了GPT-6、Claude Opus 5.5和一个本地7B模型。云端模型分类质量确实高，但调用成本和每次请求的延迟也是本地模型的几倍。考虑到工单分类对答案长度要求不高，最终选择用本地开源模型做主体分类，遇到低置信度场景再升级到云端模型做二次校验。

3.2 成本测算：上下文长度直接决定账单数字

很多团队接大模型之前没做过预算，上线后才被账单吓到。这里分享一个通用的成本测算模板。假设某场景每次请求输入2000 tokens，输出500 tokens，每天调用1000次。如果云端模型定价是输入每百万tokens 5美元、输出每百万tokens 15美元，那么每天成本就是：

• 输入：1000 × 2000 = 2,000,000 tokens，费用为 2 × 5 = 10美元
• 输出：1000 × 500 = 500,000 tokens，费用为 0.5 × 15 = 7.5美元
• 单日合计约 17.5美元，月成本约525美元

如果把上下文拉到2万tokens，哪怕输出不变，输入费用直接翻10倍，这就非常可观了。所以接入前一定要先定义好“一次请求最多多少token”，在业务代码里加上硬限制。像RAG类应用，还要控制检索回来的文档长度，不能把整本手册都塞给模型。

3.3 开发联调与权限管理：让业务代码不感知模型切换

开发和联调阶段，我们重点做三件事。第一，统一接口封装，所有模型调用都走内部SDK，业务层只能传入prompt和参数，不直接接触模型API。第二，错误重试和降级，云端模型超时或限流时自动切换到备用模型，本地模型挂了则返回可读的错误提示，不能把模型的HTTP 500直接暴露给用户。第三，权限和审计，不同团队只能访问自己绑定的模型和Key，管理员能在后台看到每个应用的token消耗情况。

这里有个细节：提示词模板要独立出来，不要硬编码在代码里。运营和产品经常要调整措辞，每次调整都要发版太麻烦。我们把提示词模板放到配置中心，改动即时生效，并记录版本历史。有次运营把提示词改坏了，因为能追溯版本，一分钟就回滚了。

3.4 上线后的监控：不止看接口状态，还要看回答质量

模型上线的监控和普通接口不太一样。除了常规的QPS、延迟、错误率，还要关注“回答质量”的隐性指标。比如分类任务可以定期抽检结果分布，如果某个标签的比例明显异动，很可能是模型被新数据带偏了；生成类任务可以统计平均输出长度和用户点击采纳率，间接反映效果。

我们当时的做法是用测试集做每日回归。每次更新模型版本或提示词，都自动跑一遍预约好的测试用例，对比前后结果差异，防止“优化一个场景，搞砸另一个场景”。另外，日志里保留每次请求的原始输入输出，方便排查争议和投诉。注意日志脱敏，凡是可能包含身份证号、手机号的内容，在落库前要过滤掉。

4. 常见问题、踩坑记录和团队落地建议

4.1 模型一本正经胡说八道怎么办

这是所有接入大模型的团队都会遇到的问题。不管是GPT-6还是Claude Opus 5.5，都有概率在不确定的场景里生成貌似可信的错误内容。解决手段不是“换更聪明的模型”，而是从产品机制上限制风险。

首先，对事实性要求高的场景，不要裸用模型输出，要接RAG或业务数据库，让模型基于检索结果回答。其次，让模型在不确定时明确说“不知道”，在提示词里加一句“如果信息不足，请直接回答无法确定”，能显著减少胡编概率。最后，对高风险内容做二次校验，比如生成的法务回复、财务话术，必须要人工审核才能发出。

4.2 接口超时、并发上不去，先排查这些瓶颈

接到生产环境后最常见的抱怨是“AI转圈太久了”。排查顺序是这样的：先看网络链路，云端API跨地域调用延迟可能就有几百毫秒，能走内网就走内网；再看prompt长度，一条几万token的请求，生成时间必然长，业务上可以缩短上下文或采用流式输出。

流式输出对用户体验提升很大。不要等模型全部生成完再展示，改成SSE逐字吐出来，用户的等待感会好很多。并发方面，云端API有配额限制，要在网关层做好重试和退避；本地模型服务则要关注显存占用，7B模型在FP16下大概需要14GB显存，超过并发阈值会出现排队，这时可以加一个简单的推理队列，避免请求直接超时。

4.3 私有化部署资源不够，怎么降级

如果团队只有一两张卡，还要跑多个模型，资源就会很紧张。我的经验是分清场景：轻量任务用7B模型量化版，重量级任务才用更大模型。量化能在损失少量精度的情况下大幅降低显存占用。比如把13B模型从FP16量化到INT4，显存可以从约26GB降到不到9GB，多数内部工具根本感知不到精度差异。

另一个思路是用模型路由。简单请求命中快速模型，复杂请求才转到昂贵的大模型。网关可以加一层语义判断，检测到“需要推理、创作、总结”这类关键词时，倾向选择大模型；普通问答直接走小模型。

4.4 团队想持续用好模型，一定要沉淀提示词和评估集

接入大模型只是个开始，真正拉开差距的是团队能不能持续复用和优化。我们建了一个内部的“提示词库”，按场景分类维护，每个模板都有负责人、版本号和变更记录，新产品接入时直接复制已有模板，不需要从零开始。

比提示词更重要的是评估集。每个场景维护一份覆盖正常、边界、恶意输入的测试用例，任何模型升级、提示词调整、知识库更新，都要在评估集上跑一遍回归。没有评估集，就等于在盲调模型，出了问题都不知道是哪次改动引起的。

最后分享一个让我省下不少时间的做法：把所有模型调用都加上“trace_id”，从网关到模型到业务日志全程串联。出了问题，输入一个ID就能看到完整链路，再也不用让前端、后端、算法互相踢皮球。团队接大模型本身没有想象中那么玄乎，先把场景切小、把权限和成本控住、把评估集建起来，剩下的都是持续迭代的体力活。