企业官网建设流程全解析

这两年，大模型（LLM）这三个字几乎把互联网的每一个角落都塞满了，但一个很有意思的现象是：真正把大模型用起来的人，和围观热闹的人，中间往往隔的不是技术深度，而是信息整理门槛。模型名字换来换去，今天这个出开源，明天那个放API，哪些是绕不开的知名选手，哪些能直接接进自己的项目里，很多人其实是一头雾水。这篇东西不和你扯参数竞赛，也不做成发布会转述，就从一个常年做应用落地的开发者视角，把国内外那些绕不开的大模型按模型和应用两个维度捋一遍，顺带聊聊从“选模型”到“做功能”中间那段最容易踩坑的路。适合谁看？准备做AI应用开发的、想本地部署模型尝鲜的、被老板派去调研技术选型的，应该都能从这里拿走点能直接用的东西。

1. 先给大模型世界画一张地图

1.1 模型、API、开源权重和产品其实是四件事

很多人会把ChatGPT、GPT-4、OpenAI API这几个词混在一起说，但它们其实是完全不同的东西。用开车来类比：模型像发动机，决定了这辆车能跑多快、油耗多少；API像方向盘和仪表盘，是你直接操作它的接口；开源权重相当于把发动机图纸甚至整台发动机交给你，你可以自己改装；而最终的产品（比如一个聊天网页、一个写作助手）则是整车。搞清楚自己手里拿到的是哪一层，才不会在后面的选型和排查里犯迷糊。

拿我常接触的例子说，同样一个效果需求，你可以直接调用某个大厂商的对话API，五分钟拿到结果；也可以从开源社区下载一个7B或13B的模型权重，部署到自己服务器上跑；还可以基于API或本地模型再做一层应用，比如检索增强的问答系统、自动化报表生成工具。这三条路的成本结构、数据隐私边界、性能天花板完全不同，没有绝对的好坏，只有适不适合当时场景。

1.2 生态里站着三类角色，各管一段

把现在的大模型生态拆开看，主要是三类参与者在互相配合。第一类是模型厂商，专门负责训练出好模型并对外提供服务，典型如国外的OpenAI、Google、Anthropic，国内的阿里、百度、智谱、DeepSeek等。第二类是开源社区，他们把模型权重公开出来，再配上量化工具、推理框架、微调教程，让普通人也能在自己电脑上跑起来，Meta推出的Llama系列和中通的Qwen系列就是这个路线的代表。第三类是应用开发者，也就是把模型能力包装成具体功能的人，比如做知识库问答机器人、写代码助手、会议纪要工具等。

这个分工有个很重要的作用：你不用在每一层都从零开始。想做个简历优化工具，直接拿一个对话模型当大脑，再写几百行业务逻辑就行。真正决定项目生死的往往不是模型本身，而是你对场景的理解和工程实现，这句话我后面还会反复提到。

1.3 我观察到的三个明显趋势

从这几年接触大量项目的经验看，有三个趋势值得关注。第一是从“拼参数”转向“拼价格和效率”，前几年大家都在比模型规模有多大，现在已经很少见人把万亿参数挂在嘴边了，反而更关注推理速度、每百万Token价格、部署成本，同级别的小参数模型因为便宜和快，被大规模采用。第二是从“万能大模型”转向“垂直小模型”，法律、医疗、制造这些行业，光靠通用模型不够，大家更愿意花精力在开源基座模型上继续微调，得到自己行业的专属大脑。第三是从“纯云端”转向“端云混合”，很多场景要求在手机、车载设备、办公电脑上本地运行模型，既有隐私考虑，也有离线可用的刚需，这也是为什么量化技术和轻量推理框架热度一直很高。

这三个趋势说实话给应用开发者带来了不少红利：模型能力在快速普及化，好用的基座越来越多，把想法变成产品的门槛一直在下降。

2. 国外知名模型盘一盘

2.1 闭源大模型里的几根标杆

国外闭源模型里，绕不开的当然是OpenAI的GPT系列。它的ChatGPT把对话交互做成了行业标杆，API生态也非常成熟，擅长生成、推理、代码编写，适合做通用型助手类的应用。Google的Gemini系列则把多模态做得更彻底，图片、视频、音频、文本一起处理，对想直接做“视觉问答”“图文理解”这类产品的团队来说，省掉了很多拼装多模型的麻烦。Anthropic的Claude系列以长上下文和高质量写作见长，在代码生成、文档分析、安全对齐方面口碑很稳，不少做企业知识库和复杂任务处理的团队会优先选它。xAI的Grok算是个性比较强的一位，风格偏轻松，常被用来做社交场景的伴聊产品。

选闭源模型的时候，我的建议是先列一个需求清单：你要处理的是文本还是多模态？需要多长的上下文？出错的代价高不高？再把各家的免费额度和付费价格拿来对比。不要因为某个模型参数最强就无脑选，实际线上跑起来时，速度和成本往往比那零点几个百分点的准确率更致命。很多朋友上来就想接最强的旗舰级模型，结果一个月账单出来，才发现日活用户根本撑不住这个成本。

2.2 开源生态里的几个硬角色

如果说闭源模型是“租车出行”，那开源模型就是“自己买车”。Meta的Llama系列是开源生态绕不开的一座山，Llama 2和Llama 3出来之后，直接养活了一大片微调教程、量化工具和行业应用。Mistral一家来自欧洲的团队做的模型以轻量著称，从小尺寸到中尺寸都有不错表现，非常适合部署资源有限的小团队。Google的Gemma系列定位更轻，是给单卡和端侧场景设计的，跑起来门槛低。Microsoft这边Phi系列则走“小模型专精”路线，参数不多，但在推理和数学任务上表现超出很多人的预期。

开源模型最让人舒服的地方是你可以彻底掌控它：权重在自己手里，跑在哪儿自己说了算，不用害怕哪天API接口升级把应用搞得不能用，也不用担心敏感数据传出去。代价是拿模型回来之后，部署、调优、维护都得自己干，每一个环节都有坑。我见过很多团队满怀热情下载了一个大模型，结果卡在环境配置上折腾一周，最后又默默回到API调用这条路，所以做决定之前最好先掂量一下自己的工程能力。安全有要求的时候，我再强调一句：下载权重尽量从官方渠道或可信的平台拿，不要贪图来路不明的“加速包”或“整合版”，开源社区里也确实出现过恶意权重投毒这样的事故，下载后最好比对一下官方发布的哈希值。

2.3 国外模型选型时的几个判断维度

用一张表讲清楚我会怎么看国外模型：

有人喜欢追新，模型一出新版就切。我的习惯是：线上在跑的模型只做小版本升级，大版本切换必须单独开一轮回归测试。别小看这个习惯，很多线上事故都是“模型偷偷变聪明了”或者“格式变了”导致的，这类问题在快速迭代的大模型圈里尤其常见。

3. 国内知名模型盘一盘

3.1 商用闭源模型，各有各的主场

国内闭源模型这几年进步很明显，而且整体的性价比一直很能打。DeepSeek（深度求索）是我个人用得比较多的，它的推理能力在同类里相当突出，代码和数学任务表现出色，API价格也压得很低，很适合创业团队拿来做原型验证。阿里的通义千问系列（Qwen）背后有很强的云生态，从基座模型到开源权重到工具链都搭配整齐，如果你本身就在用阿里云的资源，集成会很顺。智谱AI的GLM系列背靠清华系，技术底子踏实，对中文理解细致，很多做知识问答和政府企业项目的会优先考虑。月之暗面的Kimi靠长文本技能出了圈，是处理几十万字文档场景很能打的选手。字节的豆包则强在应用生态和Agent能力，背靠字节成熟的产品工程，做C端陪伴和客服类应用有很多现成方案。昆仑万维的Skywork（天工）、百度的文心一言、腾讯的混元、讯飞星火也都各有各的垂直场景积累，选型的时候不要只盯着知名度，要看它们在自己行业里的数据积累。

3.2 国产开源模型：中文微调的沃土

国产开源模型这两年是全球开源社区里一股没法忽视的力量。最典型的就是通义千问团队的开源Qwen系列，从0.5B一直到70B，尺寸覆盖非常完整，官方和社区贡献的中文微调教程、数据集、实战案例数量巨大。对一个想快速做垂直行业大模型团队来说，拿Qwen开源模型当底座，去训练自己的“行业版”，几乎是标准操作，热词里大家反复提到的“qwen2.5-7b微调行业大模型”走的就是这个路子。智谱的GLM也有开源版本，DeepSeek也开源过自己的模型，再加上各个高校和创业公司贡献的模型，整个国产开源生态已经从“能用”进化到了“好用”。

中文社区还有一个得天独厚的优势：数据土壤好。像Llama这类的开源模型虽然强大，但原始训练数据里中文占比不算高，你想拿去落地中文业务，要么加大量的中文语料继续训练，要么在做提示词时做额外适配；而国产开源模型的知识积累天然围绕中文，很多行业检索增强的效果会更好。

3.3 国产模型横向参考

选国内模型这件事，我比较反感“只看跑分”的惯性。模型榜单上差那几个点，放在实际业务里用户根本感知不到；真正拉开差距的是中文语料适配程度、API稳定性、售后支持这些“看不见的东西”。有条件的话，把自家业务里的100条真实问题整理出来，同时在几家候选上跑一遍，然后人工盲测打分，这比什么榜单都可靠。

4. 应用维度：模型到底怎么变成产品功能

4.1 内容生产与知识管理

最接地气的大模型应用就是内容生产。写周报、写邮件、生成推广文案、翻译文档、总结会议纪要、给代码写注释，这些重复性的文字活交给大模型效率确实高。稍微进阶一点的玩法是知识管理：把企业内部一堆PDF、Word、网页文档接进来，做一个“基于自身资料的问答机器人”。常规做法是RAG（检索增强生成），先把文档切成小块、做向量化入库，用户提问时先检索相关片段，再把这些片段塞进上下文让模型回答，这样模型回答的是你的资料，而不是胡编乱造。很多做法律咨询、内部培训、售后帮助中心的团队，第一站都是这个方案。

这类应用实现起来其实不复杂，市面上现成的工具和平台一大堆，关键是文档切分和检索质量。切得太碎就丢失上下文，切得太粗又检索不到精确内容。我一般的做法是先用结构化标题切分，再按固定窗口补重叠，最后对检索结果做重排。很多人做完第一版发现回答问题老是不着四六，八成就出在这几个环节。

4.2 智能对话与Agent，不只聊天那么简单

对话型应用已经从“随便聊两句”进化到了“帮我干活”的阶段。一个成熟的智能助手，至少要具备三个能力：记忆（记住你说过的偏好和背景）、规划（把目标拆解成步骤）、工具调用（访问数据库、发请求、调用业务系统）。比如一个酒店预订助手，用户说“帮我订下周北京出差三天的酒店，离客户公司近一点”，它要理解需求，要查日历定日期，要在酒店列表里筛选位置，还要走到下单支付那一步。这一类实现，业界习惯叫Agent应用，是现在大模型落地最火的方向之一。

做Agent应用有一个常见的误区：把希望全押在模型能力上，觉得模型聪明了，一切都会好。实际上工程侧要做很多兜底工作，比如给模型限定可调用的工具清单、做好参数校验、设置任务退回策略。我的经验是，把Agent当成一个刚入职、脑子转得很快但偶尔会臆想细节的新人，你需要给它清晰的边界和可以随时叫你回来的机制，而不是放手让它自由发挥。

4.3 多模态与端侧：把模型装进口袋

多模态大模型在教育、电商、医疗影像等场景里很吃香，一张图片丢进去，模型能描述内容、识别物体、提取文字、按图回答问题。以前想做这类功能要来回调用好几个模型，现在一个大模型直接搞定，开发效率提升非常明显。语音这一侧也成熟得很快，语音转文字、文字生成语音、实时语音对话，工具链已经相当齐全。

端侧应用同样热闹，很多开发者开始尝试把模型部署到手机、车载设备和个人电脑上。比如用GGUF量化格式在Android应用里集成大模型，不联网也能做智能问答；在PC上用消费级显卡跑本地模型，实现“本地部署大模型让个人电脑智能化”；车载领域的T-BOX结合导航定位，也能做更自然的语音交互和驾驶场景理解。这些玩法背后的共同点是：模型正在从云端神坛走下来，变成设备上的普通组件，类似早年“把智能助手放进手机”的故事重演。

不过端侧部署要认清现实的物理约束：存储空间、内存带宽、续航、散热，每一项都在限制模型大小。跑一个120B的大模型在手机上是不现实的，但在车上跑一个4bit量化后的7B模型是完全可行的。建议做端侧之前，先想清楚用户真正能在离线环境拿到什么，别为了噱头硬把模型塞进去。

4.4 落地的正确顺序：由轻到重

我给想做大模型应用的新手一条不算秘密的经验：下手别太狠。第一次尝试，直接用大厂的API跑通最小功能，这一步能让你专注在业务逻辑上。跑通之后，再花时间优化提示词，把系统指令、示例、输出格式约束都调好，很多问题在提示词阶段就解决了。如果效果还不够，再考虑引入RAG，给你的模型装上外部知识。等知识检索和提示词都调不动了，最后才考虑微调。至于本地部署，只在数据安全、离线、成本三方面有明确诉求时才真正需要。

这个顺序的核心逻辑是：越往后的步骤，成本越高、周期越长、维护越累。API调用改一行代码就能测试，而微调一次少说也要几十分钟到几小时，重来一遍的代价完全不同。我做项目这几年，见过太多团队一上来就要微调、要自己部署，结果三个月还在折腾训练环境，业务一点没推进。反而那些老老实实从API开始的小团队，产品早迭代好几个版本了。

5. 实操环节：本地部署、微调和提示词的细节

5.1 本地部署：显存、量化与工具选择

本地跑模型，先要算一笔账。决定能不能跑起来的关键是显存。一个粗略的估算公式：模型权重显存约等于参数量乘以每个参数的字节数。7B模型用FP16精度，大约需要14GB显存；用4bit量化，可以压到接近4到6GB。再加上推理时还需要一块KV Cache区域，实际需求还要再上浮两到三成。所以你拿一张12GB显存的RX 6750GRE显卡，跑7B模型的4bit量化版本是可行的，跑14B模型就可能很勉强了，需要用更激进的量化或者更短的上下文长度。现在好一点的推理工具还会自动做部分层卸载，比如AirLLM这类单卡推理方案，可以在小显存上跑更大的模型，但速度会明显下降，适合离线分析不适合实时交互。

工具方面，普通用户直接使用llama.cpp或者Ollama这类封装好的工具，一条命令就能跑起一个本地模型。想嵌入到自己的应用里，可以调用本地推理服务，或者通过推理框架的绑定接口做集成。Windows上用NVIDIA显卡跑计算任务时，有人会纠结用TCC还是WDDM模式，我的建议是绝大多数时候保持默认（WDDM）就好，它既能兼顾显示输出又能跑模型，只有在专门的服务器场景、你需要极致压榨计算卡性能时，才去考虑切TCC模式。实测下来，大多数本地模型应用根本没到需要纠结这点性能差距的程度。

部署过程中也有一个安全提示：下载模型权重时尽量从官方渠道、官方镜像或大型开源社区仓库下载，认准官方发布的校验值。模型文件动辄几个GB，如果有人篡改并夹带恶意内容，你运行时损失的就不只是磁盘，而是整个设备的安全性。这个环节省不得。

5.2 微调不是大厂专属，消费级显卡也能玩

提到微调很多人第一反应是“那是大厂才玩得起的东西”，实际上早不是这样了。如果你只是想给模型注入特定领域的说话风格或专业知识，LoRA（低秩适配）这种轻量微调方案，只需要训练一小部分额外参数，显存要求大幅下降。实践里用消费级显卡微调7B模型完全可行。网上常说的“环境配置+模型微调+模型部署+效果展示”，指的往往就是这条路径。

以Qwen2.5-7B这种常见的国产开源基座模型为例，一个完整的微调实战流程大概是：第一步，配置环境，安装好对应版本的CUDA、PyTorch，再用Python拉起训练基础环境；第二步，整理数据，把自己行业里的问答对按模型要求的JSONL格式整理好，这是整个流程里最花时间的一步；第三步，写LoRA配置，设置学习率、批量大小、训练轮数这些参数；第四步，开启训练，用一张消费级显卡等上几十分钟到几小时，观察loss曲线确认没有异常；第五步，把训练出的LoRA权重和基座模型合并，导出新模型；第六步，写推理脚本做效果对比，拿出几类场景、几十个问题分别测基准模型和微调后的模型。这套流程跑下来，你就真正体会到了从“用别人训练好的大脑”到“自己动手塑造大脑”的转变。

数据质量是我最想强调的一点：有些人觉得数据越多越好，于是拿几万条网上的数据直接开训，结果模型把各种噪声和矛盾全学进去了，效果反而更差。我的实践经验是，几百到几千条高质量、标注规范的指令数据，效果远远好于几万条稀烂的数据。训练时留出一部分验证集，不断用验证集评估，而不是只看训练集loss，能帮你及早发现过拟合。

5.3 提示词工程与上下文工程的边界

我不止一次跟人讲，前面所有的努力，都应该排在提示词工程之后。很多团队抱怨“这个模型不行”，结果我一看，系统指令只有几个字，连基本的输出格式都没限定，换哪个模型来都一样拉胯。提示词工程不是玄学，它本质上是在给模型补足任务背景和约束条件。一份合格的系统指令至少要包含：角色定义（你是一名客服专员）、任务目标（回答用户关于退款的提问）、行为守则（只允许基于知识库内容回答）、输出格式（先给结论再给依据）、出现不确定时的处理方式（承认不知道并提供转人工）。

上下文工程则解决“模型不知道的事”。模型训练完成之后，知识就凝固在权重里了，你没办法让它实时知道你们公司最新价格表是什么，但你可以通过RAG把最新文档检索出来，作为上下文传给模型。很多“智能到不像AI”的应用体验，其实就是上下文工程做得好。核心是把重要信息提前放在它看得见的地方，用更少的推理时间换更准的答案。

提示词调优和微调之间怎么取舍？我的经验是：如果问题出在“没告诉它相关知识和规则”，先调提示词、上RAG；如果问题出在“风格不像、格式不对、领域术语用不好”，才考虑微调。先轻后重的原则在这里同样成立。

6. 新手路线图与避坑清单

6.1 一条稳的大模型应用开发学习路线

经常有读者问我要“大模型学习路线”，我给它浓缩成几个阶梯：第一步，建立基本概念，搞清楚Token、上下文窗口、温度系数、量化格式这些词都是什么意思，不需要你能手推Transformer结构，但至少要理解大模型大概是怎么工作的；第二步，学会写提示词，在大模型官方网页版反复练习，学习角色设定、少样本示例、思维链的基本写法；第三步，动手调API，申请几个主流的开放平台账号，写一个简单的Python脚本把对话打通，体验一下Token计费和限流规则；第四步，接触框架，了解LangChain或者LlamaIndex能帮你解决什么问题，做一个知识库问答的小项目；第五步，解锁RAG技能，自己准备几十份文档，搭一个检索问答系统；第六步，尝试微调，用开源模型做一次LoRA实战，体验数据准备到模型部署的完整流程；第七步，做一个完整应用，比如一个带前端页面的私有知识库助手，从产品到代码全都自己搞定。

这套路线我见过太多人走成了“每样都会一点但搭不出东西”。破局的关键是：每个阶段都要有一个可以展示的产出物。即使做出来的东西很简单，也不要跳到下一步，因为大模型项目真正的能力是在一次次调试、一次次从报错里爬出来后长出来的。

6.2 常见问题速查表

把踩过的坑整理成一张表，方便对着查：

有两条通用经验：一是先看日志再改代码，排查问题把推理日志和请求日志打开，尤其看清楚模型实际返回的是什么；二是小步快跑，每次只改一个变量，改完立刻测，同时改好几个变量会让人完全失去判断的依据。

6.3 一些真正值得长期记住的经验

做这件事做了这些年，我最深的体会就是：选模型不要当追新族，当产品经理。把场景拆清楚，把约束摆出来，再去匹配模型，顺序一定不能反。今天的模型榜单基本每隔几个月就会重排一次，你死守着的那个“最强模型”可能随时被替代，但你对业务的理解、对场景的把握、稳定可靠的工程能力，这些是无论模型怎么换都抢不走的核心资产。另一个很实际的建议是，尽量让自己培养一个“模型不可用时业务仍可用”的降级方案，大模型的API总有波动，能自动切换到备用模型或本地模型，才是真正的架构成熟。最后想说，大模型这行变化确实快，但越是这样，越要沉住气把手头的小事情做扎实——把提示词写好一点，把数据洗干净一点，把问答做准一点。你会发现，真正拉开产品差距的，从来都不是那个模型的名字，而是你围绕它做的所有工程和细节。