企业官网建设流程全解析

老板打电话过来，第一句往往是：“我们想上大模型，预算已经批了，帮我们落地。”我一般会先劝一句：先别急着买。

这话听上去很不合时宜，毕竟热搜天天在讲大模型，隔壁厂上了AI客服，同行用大模型写标书，自己公司再不行动好像就要掉队了。但过去一年多，我看过太多企业把大模型“买”回去，最后变成大屏上演示用的玩具，或者花了几十万部署完，员工还是偷偷用自己电脑上的免费网页版。问题通常不是技术不行，而是从一开始就把“买大模型”这件事想简单了。

这篇文章不是讲算法的，是一份老板和技术负责人都能看懂的落地路线图。核心思路只有一句话：你以为缺的是模型，其实你缺的是一套能跑通业务、算得清账、养得活的解决方案。我会把三种主流的获取方式——“用API租模型、用开源模型自己部署、买商业大模型平台”——拆开算账，说清楚各自适合什么人，然后讲自建时真正要踩的那些坑：上下文、RAG、微调、显存、数据质量，再把试点和推广的组织问题一并聊完。适合谁看？想拍板买不买的老板、被老板逼着“上周大模型”的技术负责人、以及想在公司内部推AI落地但怕翻车的产品经理。

1. 先把“买大模型”这三个字拆开

1.1 老板口中的“买”，和技术人说的“用”是两回事

老板说“买大模型”时，脑子里想的往往是一个软件：装完、双击打开、输入问题、自动出结果。但真实的大模型不是这样交付的。你买到的不过是一份模型权重文件，或者一个API调用权限，离“能干活”还差着十万八千里。

我常用一个比喻：大模型不是买了个员工，是请了一个特别聪明但没有任何业务经验的实习生。他脑子快、见识广，但不了解你公司的流程，不知道你的客户喜欢什么话术，更不知道你的数据里藏着哪些雷。你需要有人给他做上岗培训、整理参考资料、告诉他出错怎么处理，甚至要安排一个人天天检查他的作业。这个“有人”——对应到企业里就是提示词工程、知识库搭建、微调、评测和运维——才是真正烧钱的地方。

所以拆开第一层：大模型本身不是产品，是原材料。你真正要买的是“用模型解决业务问题的能力”。想清楚这一点，后面很多决策都会变简单。

1.2 决定买不买之前，先回答三个问题

我帮企业做选型前，一定会逼着对方先回答三个问题，答不上来就不谈采购。

第一个问题：到底要让机器替人做哪件事？要具体到能数出来的程度。比如“客服组每天处理300条咨询，其中一半是重复的退换货问题”“合同审核每天要翻50页材料”这种。如果只能说“想用AI提升效率”，这项目基本还没开始就输了，因为没法验收。

第二个问题：允许它错多少？大模型天生会“一本正经地胡说八道”。做内部文档问答，答错一句顶多被同事骂两句；做财务凭证审核，答错一行可能就要出事故。容错率决定了你选模型的路线，也决定了上线时的兜底方案。

第三个问题：有没有足够的数据喂给它？这是最容易被忽略的。很多老板以为买了大模型，它就自动懂公司业务。实际上，模型不知道你们公司的报销制度长什么样，也不知道你们产品线的具体参数。如果没有历史客服记录、制度文档、技术手册这些数据资产，那买回来的大模型就是个“有知识没常识”的毕业生，得先让他看三个月的档案才能上岗。

这三关都过了，才有资格进入下一步聊路线。

1.3 把场景分成四类，别一上来就想“全公司都用”

企业里能用大模型解决的场景，我习惯分成四类，优先级天差地别。

很多老板上来就挑最难啃的“行业大模型微调”，觉得这才显得有技术含量。但真正能快速见效、让团队建立信心的，永远是前两类。我经手的项目里，第一仗打的一定是“内部文档问答”或“客服辅助”，因为数据现成、效果肉眼可见、出错代价低。

等这套跑通了，再考虑要不要把某个业务环节拆出来做深度定制。顺序反了，项目推进起来会非常痛苦。

2. 三种主流路线，成本和风险心里有数

2.1 路线一：API调用——今天就能用，但要管住数据出口

最务实的入门方式是直接调用大模型API。不需要买显卡，不需要懂部署，注册账号、拿到密钥、调用接口，当天就能在业务系统里接上。

成本怎么算？大模型API大多数按token计费。你可以把token理解成“词块”，大概1个英文单词约等于1个token，1个汉字约等于1到2个token。每次请求花多少钱，取决于你输入的文本长度和输出的文本长度。举个例子，假设某个模型的定价是每百万token几块钱到几十块钱不等，一次普通客服问答消耗几百token，那算下来单次成本往往不到一分钱。真正贵的是“长文档+高并发”，比如每天自动总结几百份合同，月账单才会明显起来。

但这条路有个绕不开的坎：数据要去外部服务商那里过一道。对数据敏感的企业，客户的个人信息、内部财务数据、未公开的产品资料，能不能送出去，首先要过法务和合规这关。我见过不少企业因为这个问题，硬生生把方案从API改成了私有化部署。

我的建议是：先用非敏感数据跑POC，把效果验证了再谈数据边界。API最大的价值是让你用最低成本判断“大模型到底能不能解决这个场景”，而不是直接当生产环境用到底。

2.2 路线二：私有化部署——看着省钱，其实是个系统工程

“模型开源免费，我们自己部署，不花钱”是我听过最贵的错觉。

开源大模型确实免费下载，但把模型跑起来并支撑业务，是一笔被低估的持续支出。首先是算力硬件。一个70B参数量的模型，FP16精度通用显存估算差不多要140GB上下，这意味着一台机器基本得配多张高端GPU，采购成本轻松到几十万级别。即便是小一点的14B模型，想在生产环境支撑多人并发，也要认真掂量显卡配置。其次是运维人力。模型文件要下载、部署工具要调试、服务要监控、日志要看、版本要升级，这些都得有人干。一个能玩转大模型部署的工程师，月薪不比云API的年账单便宜。

工具链上，入门最友好的是Ollama，一条命令就能把模型跑起来，适合本地测试、个人电脑玩一玩。生产环境我见过更多用vLLM的，吞吐量高、支持连续批处理，还能通过OpenAI兼容接口无缝接入现有业务系统。

私有化部署真正适合的是这三类企业：数据敏感程度极高、业务量大到API账单不可控、已经有运维和算法团队能接得住。如果只是老板觉得“自建才安全”，那很容易变成买了一堆显卡，最后跑起来的效果还不如API版本。

2.3 路线三：商业平台或一体机——买的是省心，但要问清三件事

这两年很多厂商推“大模型一体机”或“企业级AI平台”，说开箱即用、安全私密、包部署包落地。这类产品不是不能买，但掏钱之前，我建议老板至少追问三个问题。

第一，底座模型能不能换？很多一体机预装的是某个开源模型，封装好之后看起来像个黑盒子。你要问清楚：以后出了更好的开源模型，想升级底座，厂商收不收费、技术上支不支持迁移。第二，接入数据是不是真的私有化？有的“私有化部署”只是把API请求转发到厂商云端，数据照样过人家的服务器。合同里一定要白纸黑字写清楚数据存储位置和流转路径。第三，扩展能力有没有锁死？比如后续要加多模态识别、要接自己的知识库、要支持几百人并发，一体机扛不扛得住，扩容是加机器还是加钱。

商业平台省掉了底层搭建的麻烦，适合没有技术团队的中小企业。但它本质上卖的是“整合方案”，不是“大模型本身”，所以一定要把售后服务、版本升级、数据迁移这些条款谈细。不然过两年厂商产品线一变，你的系统就成了没人维护的孤岛。

2.4 一张决策表，帮老板五分钟定方向

这张表不是死的，很多企业会走“先API试点，再私有化扩容”的路线，这也是我比较推荐的方式。记住一个原则：第一笔投入不该放在买硬件上，而该放在验证场景上。

3. 如果决定自建或私有化，请把这几件事搞明白

3.1 别被“上下文长度”忽悠了——模型记性再好，也不如一个档案室

大模型厂商都爱宣传“128K上下文”“超大上下文窗口”，老板听着觉得厉害，好像什么文档都能塞进去让模型记住。实际上，上下文窗口只是说模型一次性最多能“看到”多少内容，不是说你把公司所有资料都丢给它，它就能全部记住。窗口一长，模型中间部分容易“遗忘”，响应变慢，token成本也直线上升——因为每次请求都要把这堆内容重新算一遍。

真正把企业知识库用起来的技术叫RAG（检索增强生成）。原理不复杂：先把文档切片、转成向量存进向量数据库，用户提问时，系统先去库里检索最相关的几段内容，再把这几段塞给大模型，让它基于这些材料回答。你可以把它理解成：模型不是把所有档案背下来，而是配了一个档案管理员，你问什么，他先去档案室把对应的卷宗翻出来递给你。

落地RAG时我踩过不少坑，最值得提醒的有三点：一是文档要提前清理，PDF扫描件要OCR转文字，烂格式、乱码、重复内容都会污染检索效果；二是文本切片大小要试，切的太碎找不全上下文，切得太长又容易把不相关的内容卷进来，一般500到800字左右起步调；三是检索出来的内容不能直接全信，要有重排环节，让最相关的结果排到前面。

3.2 微调是锦上添花，不是雪中送炭

很多技术负责人一上来就要微调，“开源模型效果不够好，我要用公司数据微调”。但据我观察，真正需要微调的场景其实非常少。一个模型不知道你们公司内部制度，这是知识缺失，要用RAG解决；一个模型的回答风格太通用、不够专业，这是表达问题，可以靠提示词解决；只有当模型经常用错行业术语、输出格式与业务系统硬性不匹配、怎么调提示词都白费时，才轮到微调上场。

微调的意义是“让模型学会一种表达习惯或专门技能”，比如让它把病案数据按固定模板转写成结构化报告，或者让它用特定的法律条款风格起草文书。这不是教它新知识，而是教它“说话的方式”。

真正做微调时，要记住它的成本不只包括训练那几小时的算力，还包括数据准备和评测验证。一般几百到几千条高质量样本就能见到效果，但样本质量一致性特别重要——找三个人同时标注，标准不统一，模型学了只会更乱。现在主流做法是LoRA这类参数高效微调，只训练很少一部分参数，成本可控。流程上我习惯走：数据准备→人工抽查标注质量→LoRA训练→在预留测试集上对比原模型→小流量灰度→再全量上线。千万别跳过后两步，不然“灾难性遗忘”会让模型连原来的通用能力都丢掉。

3.3 从Ollama到vLLM：本地跑着玩和上生产完全不是一回事

很多人第一次接触私有化部署，都是从Ollama开始的。它确实是目前本地跑模型最友好的工具：一条命令下载模型，一条命令起服务，自带命令行和API接口，Windows、Linux都能跑。用它验证一个7B或14B模型能不能满足需求，完全够用。

但一旦并发用户多了，Ollama就容易吃力，因为它缺生产级的请求排队、连续批处理和显存管理优化。这时候就该换vLLM了。vLLM是当前生产环境部署开源模型的主流选择，吞吐量高，支持OpenAI兼容接口，意味着你的业务代码几乎不用改，把base_url换成vLLM的服务地址就行。降本增效非常明显。

硬件上怎么估算？给你一个粗糙公式：FP16精度下，模型显存占用约等于参数量乘以2。7B模型大概需要14GB显存，14B大概28GB，70B大概140GB。所以一张24GB的消费级显卡，勉强能跑7B量化模型（int8或int4量化后显存更低），支撑个位数的并发测试。但生产环境想支撑几十人同时用，就得考虑多卡集群或直接租云GPU了。我见过一家公司用一台双卡机器跑14B量化模型，服务一百多内部员工，勉强够用；后来并发一高，响应延迟明显增加，只能再扩容。

3.4 多模态别盲目跟风，简单任务交给简单模型

最近“多模态大模型”被炒得很热，不少企业也想让大模型直接“看图识别”。但这里我劝一句：先分清你到底是需要“看一眼图片就懂意思”，还是需要“精确检测出产品上某个瑕疵的位置”。

如果是后者，比如工业质检、印刷缺陷检测、安全帽佩戴识别，这类任务传统CV模型反而更稳定、更快、更便宜。用多模态大模型去干这活，是拿大象踩蚂蚁，精度和实时性都可能让你失望。多模态大模型真正擅长的，是理解整体语义，比如“这张合同扫描件里有没有金额改动的痕迹”“这张产品图适合配什么文案”“这段视频里的关键事件是什么”。这些任务没有明确规则，需要跨模态理解，才是多模态的用武之地。

选型时不要因为“别人都在上”就跟着上。正确姿势是回到业务本身：这个任务到底要不要“理解”这件事？如果只要检测和分类，传统算法就够；如果确实需要理解，再评估多模态大模型，并且小范围试用后再谈采购。

4. 上线之前，最容易被忽略的是组织准备

4.1 不会算账的项目，十有八九会烂尾

技术方案聊完，接下来得把ROI算成一张明明白白的表，否则老板的热情坚持不了三个月。我不会用什么“效率提升百分之多少”这种虚词，而是直接算工时和成本。

举个例子：一个售后客服团队5个人，每天处理300条咨询，每条平均耗时20分钟，人均月成本1万，合计人力成本5万。引入大模型辅助后，预计40%的常规问题由AI直接回复，剩下60%由人工处理，因为AI先准备好了草稿，人工处理时间降了一半。算下来每天节省人工工时约40小时，按一个人月工作160小时算，相当于节省1.25个人的成本，一个月就是1.25万。如果这个项目的月成本（API费用加开发人员分摊）控制在5000块以内，那ROI是明显为正的，可以放心推进。

反过来，如果算下来每个月AI成本比节省的人力还高，那说明场景选错了，或者方案做得太重了。这时候该做的不是硬扛，而是换场景、换轻量方案。记住，老板不关心你的模型多先进，他关心的是这笔投入什么时候能省回来。

4.2 试点项目怎么选：低风险、高痛点、看得见

大模型落地最容易犯的错误是“上来就想改造核心业务系统”。我觉得最稳的试点项目应该同时满足三个条件：低风险——错了不会出大事；高痛点——业务方天天叫苦，有强烈改进意愿；看得见——效果能用数据直观呈现。

比较经典的试点候选有：内部制度问答（员工找人事/行政问问题，AI先答）、会议纪要自动生成（每周省掉大量整理时间）、合同要素抽取（配合人工复核，减少录入工作量）。选一个场景，定好3个月的试点周期，明确三个验收指标，比如问答准确率、单次处理时长、人工介入比例。指标不达标，分析原因；达标了，再横向复制到第二个场景。

项目启动时就把验收指标发到项目群里，让老板和业务方都看到基线数据。你后面优化有没有效果，不是靠嘴说，是拿数字说话的。

4.3 数据质量决定了模型智商的“天花板”

这可能是整条落地路线里最枯燥、也最值钱的一步。模型的通用能力来自底座，但它在你们公司好不好用，完全取决于喂给它的数据质量。数据烂，模型再强也白搭。

知识库建设不是把一堆Word、PDF丢进系统就完事。要做的工作包括：把扫描件转成可检索的文字、统一不同部门的文档格式、去掉重复和过期内容、给文档打上清晰标签、建立更新机制——制度改了，旧版立刻下架，不然模型会拿旧制度一本正经地胡说。如果你要做微调，数据标注的规范和一致性更要较真，因为模型学坏容易学好难。

数据安全这块也得提前设计。内部知识库不是所有内容都对所有人开放，薪酬类、战略类文档要设权限，避免员工问一句“市场部薪资方案是什么”就把不该看的内容调出来。先做权限设计，再谈上线推广，这是底线。

4.4 别让一线员工觉得你是来抢饭碗的

系统做完了，没人用，是这个行业最常见的死法。很多时候不是工具不好，而是员工打心底里抵触。一线客服会担心AI取代自己，业务骨干会嫌“又要我配合填表、又要我验证答案，增加了工作量”。这种情绪不解决，再好的模型也推不动。

我惯用的做法是把员工拉进来当“共创者”，而不是“测试对象”。让资深客服参与整理标准回答话术和标注，让行政同事帮忙挑测试问题，系统上线后每一版改进都告诉他们“这条是你那天提的问题，现在已经能答对了”。同时把定位讲清楚：AI负责处理那些重复、机械、没成长性的劳动，人负责判断、沟通和复杂个案。想让员工配合，先让他们感受到这个工具确实帮自己省了事，而不是给自己添了堵。

推广期还要留一个显眼的反馈通道——哪怕只是群里收集问题，也要让使用的人知道“提了反馈真有人会改”。否则两周后没人再提意见，项目也就凉了。

5. 常见问题与排查技巧实录

5.1 模型一本正经地胡说八道，怎么办

症状很典型：问它一个内部政策问题，它给了一个听起来很专业、实际上根本不存在的答案。先别骂模型笨，按顺序排查。

第一步，确认是不是知识库压根没收录相关内容。很多“胡说”其实是“没找到资料硬编答案”，在RAG系统里，先查检索环节有没有召回相关片段。第二步，降低模型的“创作欲”，也就是调低temperature参数，让它别发挥。第三步，在提示词里明确写“如果你不知道答案，直接说不知道，不要编造”。第四步，如果还是错，那就必须加人工复核兜底——比如客服系统里AI只生成草稿，人工确认后再发出。

我对生产系统一直有个原则：能用规则兜底的就用规则兜底，能用人工复核的就用人工复核。大模型不是用来做最终决策的，它是用来把人从低效劳动里解放出来的。

5.2 回答达不到业务预期，到底是模型问题还是场景问题

很多团队会陷入“盲目调试”的怪圈：把模型换来换去、训练参数改来改去，最后发现还是不行。我建议用排除法。

先问“这个任务是不是大模型该干的”。如果是要精确计算发票税额，大模型再聪明也会马虎，这时候就该交给代码去算。再问“提示词有没有把任务说明白”，很多效果问题其实是提示词太笼统，加一个角色设定、输出格式示例、步骤分解，效果立刻不一样。接着问“知识库里有没有足够的相关信息”，没有的话先补资料。最后才轮到“是不是需要换模型或微调”。

我经手过一个合同信息抽取项目，用7B模型始终抽不准，换14B模型就好很多。这种情况不是模型“坏”，是任务难度超过了小模型的能力范围。该升级就升级，但在升级前先把前面的步骤走完，不然升到70B也只是花更多钱买一个还没定位准确的问题。

5.3 部署完，系统就躺在那里没人用

系统功能没问题，但活跃度极低，这是企业AI落地最常见的尴尬。排查时先看入口，如果员工要专门打开一个后台网址才知道有个AI助手，那基本不会有人用。解决方法是把入口放进员工每天都在用的地方，比如企业微信、钉钉、飞书群里直接@机器人，或者放到OA首页搜索框旁边。

再看回答质量，如果前面十个问题里有三四个答得不准，员工立刻就会对系统失去信任。这时候宁可先限制范围，只让它回答最有把握的几十个问题，也别让它“什么都知道一点、什么都不靠谱”。信任一旦崩了，再想拉回来就难了。

5.4 成本悄悄超出预算了

预算超支有规律：要么是上下文长度失控，每次调用都塞一大段历史记录，费用指数级上涨；要么是接口被全量测试程序暴力调用；要么是模型选型过大，杀鸡用牛刀。对应解法也很直接：给请求做缓存，相同问题不重复计费；加限流，控制单用户调用频率；长对话只保留最近几轮内容；调试阶段先用小模型，跑通逻辑后再换大模型提升质量。

我每做一个项目都会从第一天就统计tokens消耗和响应分布，做成一张简单的日报表。没有这张表，成本失控通常要等月底账单出来才发现，那时候已经晚了。

最后补一个我觉得价值最高的习惯：从第一天就建一个评测集。挑20到50条最能代表业务场景的问题固定下来，所有改动都在同一批问题上跑一遍，效果好或差用分数说话，而不是凭感觉。我见过太多团队调了半个月参数，最后说不出到底哪里变好了，就凭一个“感觉差不多”收场。有评测集，优化才有方向，项目验收才有依据。

这些年做下来，我最大的体会是：大模型落地的成败，多数不取决于模型本身多先进，而取决于你是否愿意花时间把场景、数据、流程、人这些“脏活累活”做扎实。老板别急着买大模型，先让团队用最便宜的方式把问题跑一遍；验证清楚了，再回头决定是租、是买、还是自建。这个顺序只要对了，后面花的每一分钱，都会变成生产力。