企业官网建设流程全解析

上周跟一位做连锁餐饮的老板吃饭，他去年年初拍板搞大模型，买了GPU服务器做了私有化部署，前后花了六十多万。前两天他跟我说，这个项目现在真正在用的，就剩一个会议纪要自动整理，还是他自己坚持在用的。这不是他一个人的故事。过去两年我接触了大量做AI落地的公司，发现一个很反直觉的现象：大模型项目死掉，很少死在模型不够聪明，而是死在老板把“买大模型”当成了采购项目——货到了，就开始等效果；效果没来，就归咎于技术团队。

这篇文章写给两类人：一类是正在被各种大模型方案包围的老板，另一类是要向老板汇报的技术负责人。我想用最不技术的方式，把一套能落地的路线图讲清楚：什么阶段该做什么、花多少钱、怎么判断有效、什么时候该停。记住一个前提：别急着买大模型，先跑出真实业务价值，再回来买。

1. 买模型之前，先搞清楚90%的成本花在哪

老板们最容易犯的错，是把大模型项目当成一次采购，按“买设备”的方式做预算。买台机器，验收完了就能用；大模型不是这样，模型本身只是一个引擎，要让它在业务流程里干活，你得给它输油、接管路、装仪表，还得有人天天盯着。

数字化采购最大的陷阱就在这：你看得到的模型采购价只是冰山一角，淹没在水下的那部分才是决定项目生死的大头。

1.1 一个真实的账本：模型本身只占三成

我们看一个典型的100万预算项目。老板想象中的分配是：模型50万、硬件20万、开发30万。实际跑起来通常是这样的：

• 模型权重获取（或API调用费）：20万
• GPU服务器、机房与电费：25万
• 技术对接与数据清洗：30万
• 业务部门试用与迭代反馈：20万
• 各种返工和补救：5万

你会发现，“买模型”这件事只占一小块，水面下的成本才是大头。如果走API路线，硬件那25万省了，但数据清洗、业务对接、效果调优的投入一点不会少。模型调用费是浮动的，随着使用量增长，还可能变成另一种固定支出。

我之前帮一家制造业公司做了一次复盘，他们一年前采购了一套私有化方案，合同额80万，其中模型授权占40万。结果一年下来，真正吃掉预算的不是授权费，而是为了把模型接进ERP系统花的开发费，以及业务部门每天核对AI输出花费的人工。授权费只占整个项目总投入的三分之一左右，但立项时所有人的注意力都在那三分之一上。

1.2 “买模型”和“买能力”不是一回事

采购模型是获得一个工具，获得能力是让工具真正在一个业务环节里稳定干活。中间隔着什么？业务流程的梳理、数据的准备、输出结果的校验机制、出错后的兜底方案、使用者习惯的改变……这些没有一项是可以直接下单买到的。

这也是为什么我一再建议老板们：项目立项的第一件事，不是去比哪家模型跑分高，而是画一条从业务问题到大模型输出的链路图——每一步谁来做、数据从哪来、结果怎么校验。链路画不出来，采购规模越大，浪费越多。

有句话我常对身边老板说：大模型不是一件设备，而是一个需要接管的员工。你招一个员工回来，不会指望他自己就能找到活干出业绩，得有岗位说明书、有培训期、有绩效反馈。大模型比新员工更需要“带教”，因为它连基本的业务语境都要你一点点喂给它。

2. 老板不需要懂代码，但这五个概念不能不辨

不懂技术不丢人。但在做决策之前，有五个词必须分得清。我尽量用人话讲，每一个词背后都对应一种花钱方式或一个判断标准，搞混了，预算就走偏。

2.1 上下文窗口：一张桌子能铺开多少材料

上下文窗口是大模型一次可以同时处理的文字量。可以把它想成开会时面前能铺开的材料大小。桌面小，材料多，就只能分批看，很容易漏掉前后呼应的信息；桌面大，所有材料一次铺开，回答更连贯，但成本也更高。

老板只需要判断一个问题：你的业务场景，单次要给模型多少资料？如果是客服问答，几百字就够；如果是合同审阅，可能一次要喂进去几十页。别盲目追求长上下文，很多场景用分段处理反而更稳，而且省钱。

有些售前人员会拿“上下文窗口多大”当卖点。别只看窗口多大，要看你的业务每次到底用得到多大。窗口大只是“可选范围”大，不代表每次调用都会好用。

2.2 训练、微调和调用：三种动作对应三种花钱方式

这三个词经常被混着用，其实完全是三个量级的动作：

• 训练：从零训练一个通用大模型，成本动辄千万级，是AI大厂做的事，普通企业不应该碰。
• 微调：在现成模型基础上用你的业务数据做专项调整，相当于给全科学霸补一门专业课。成本看数据量和复杂度，老板只要知道“这是优化动作”就行。
• 调用：直接使用现成模型的接口，按量付费，相当于雇了个小时工，随叫随到。

绝大多数公司一年内碰到的只有“调用”。跑通业务后，如果发现通用模型的不足，再考虑微调。它们不是同一维度的选择，是三个不同阶段的动作，千万别一上来就跟技术团队说“我们要训练自己的大模型”。

2.3 开源模型和闭源模型：私有化部署不等于更安全

开源模型是指权重公开、可以部署在自己服务器上的模型；闭源模型是只能通过API调用的模型。很多老板一听“数据不出内网”，就觉得必须私有化。

这里有一个常见的认知偏差。数据放内网和真正安全之间，还隔着服务器漏洞、权限管理、日志加密、模型版本更新等一堆看不见的运维问题。你的IT团队一周能值几次班？出了安全事故有没有预案？这些都不是买了服务器就自动有的。

反过来，走API也不是“一定会泄露数据”。商用API一般都有明确的数据使用条款，小规模调用时，真正敏感的核心数据也可以在脱敏后再调用。决策的关键其实不是技术路线，而是问问业务本身：这项业务的数据，到底哪些字段不能让第三方看到？这些字段能不能绕开？绕不开且预算足够，才考虑私有化。

2.4 Token和API计费：小项目的成本也能算出大数字

Token是模型处理文本的基本单位，可以近似理解成“半个汉字左右”。API按Token计费，输入和输出价格往往不同。要估算一个月支出，公式很简单：

月成本 = 日均调用次数 × 单次消耗Token数 × 单价 × 30

举个例子。假设一个客服助手，用户问题约300个Token，模型回答约200个Token。若某API报价输入0.02元/千Token、输出0.06元/千Token，单次成本约0.018元，每天一万次调用，一个月约5400元。但如果你为了让回答更准，把公司产品手册全文都塞进输入里，单次输入涨到5000个Token，单次成本会变成0.1元出头，同样的调用量，一个月就超过3万元。功能没变，产品设计一变，成本差了五六倍。

这组数字只是为了演示算法。老板不用自己算，但可以设一道习惯：每次看到大模型项目的报价，都问一句“这里的成本是按什么Token量和调用量算的”，而不是只听“每次调用几分钱”这种话术。

2.5 多模态：图片、语音和文字不一定是同一个模型

有的模型只擅长文字，有的能同时读懂图片、音频、视频，这就是多模态。如果你的业务要处理照片（比如拍照质检、票据识别）、语音（比如客服录音分析）或者视频，选型时就要单独考虑多模态模型的能力，不能只看它在文字题上的跑分。

同一家模型的多模态版本通常比纯文本版本更贵。能文字解决的场景不要为多模态多付钱。很多项目一开始根本没想清楚要处理什么格式的数据，采购时被“全都支持”宣传打动，买了最贵档位，结果用到的功能连十分之一都不到。

3. 三条落地路线怎么选：API、私有化、微调的真实边界

路线图的核心是路线选择。很多老板一上来就排优先级：私有化优先、自研优先、买授权优先……都反了。正确的是按“当下阶段”定路线，而不是按“组织偏好”定路线。

3.1 路线一：公开API，九成企业应该从这里起步

最直接的做法是调用公开大模型的API。优点是启动快——一周内能跑出demo；成本低——有免费额度，或者按量付费很便宜；不需要购买硬件；后续可以随时换厂商。

缺点也很明确：数据要出内网，长期按量付费可能会超过自建成本。但对一个还在验证业务阶段的项目，这些缺点远没有“快速跑通”重要。我见过太多企业花了三个月搭私有化底座，结果发现业务场景根本不需要，或者压根没人用。

关于免费额度多说一句：很多平台都有免费额度或最低价档位，足够支撑试点期的数据量，技术团队查一下就知道。老板千万别因为“免费的不安全”这种直觉否定这条路线，先跑起来才知道钱该花在哪。

3.2 路线二：私有化部署，只在一种情况下优先考虑

只有当数据合规、合同约束、安全审计这类硬性要求出现时，私有化才应该排到前面。注意，这说的是“硬性要求”，不是“觉得数据放自己这里更放心”。后一种错觉，往往让公司多掏几十万的硬件和运维费，换来的所谓安全感，其实靠几个安全补丁就能实现。

私有化的成本大致分三块：

• GPU服务器的一次性投入。跑不同参数规模的模型，预算差距很大。入门级可能十几万，高配阵列是几倍甚至十几倍。
• 机房与电力的持续性成本。高负载的GPU服务器连续跑，电费和散热开支会吓人一跳。
• 模型运维的人力成本。版本升级、故障排查、并发调度，都要有人管。现在技术团队通常会提 vLLM、Ollama 这类部署框架，配合 Dify、FastGPT 这类应用框架来降低难度，但调试和迭代的时间仍然要算进去。

老板不需要懂这些工具，只需要知道：私有化跑起来只是第一步，让它在业务里稳定、准确、可用，才是需要持续投入的部分。

3.3 路线三：微调，是优化手段，不是起点

微调经常被包装成“用你的数据训练专属模型”，听起来很强大，容易让老板产生“别人买我用”的冲动。但微调有两个硬前提：一是你已经通过API把业务跑熟了，知道通用模型的短板到底在哪；二是你积累了足够多、足够干净的样本数据，可能是几百条，也可能上万条。没有这两个前提，微调很可能只是浪费预算。

很多业务问题，靠提示词优化和知识库检索就能解决80%。所谓知识库检索，就是把资料放进外部索引，模型按需调用答案，而不是把所有内容都装进模型。解决了这80%，剩下的20%才值得考虑用微调去补。

换个容易懂的说法：先让小时工干着，把干的不好、但天天都要干的那部分活挑出来，再考虑给小时工开小灶。一上来就开小灶，你可能根本不知道灶该开在哪。

3.4 一张表把三条路线摆上桌

这张表不是让你做出唯一选择，而是告诉你：同一个项目，不同阶段可以走不同路线。先用API快速验证，验证成功后再考虑私有化，最后才谈微调，这是最省钱的路径。

4. 两周起步试点：怎么用最少成本拿到第一组有效数据

不管你最终走哪条路线，第一件事永远是做一个两周试点。它不是为了证明AI有多强，而是为了让你看到真实业务中的可用性。这可能是整个项目里最有价值的两周。

4.1 先挑一个场景：高价值、低风险、可量化

选场景有个三标准，满足三个就是好试点：

• 高价值：减少明显的时间浪费，或者带来看得见的收入增长。
• 低风险：输出错了不会出大事故。
• 可量化：前后对比有数字。

常见的优质试点有：售后工单自动分类、合同关键字段抽取、标书初筛、FAQ客服机器人、周报汇总摘要。这些场景的共性在于边界清晰、评价标准明确。

反过来，第一个项目选“最炫场景”一般都会踩坑。比如做一个人人可聊天的企业知识助手，听起来很厉害，但知识库本身不整理好，它什么都答不对，最后结论就成了“大模型不行”。选场景宁可土一点，也不要选那些听起来很高大上、实际上根本无法验收的。

4.2 试点操作步骤：人、数据、工具一次配齐

光有想法不能叫试点，必须按下面的步骤走一遍：

1. 指定一个业务骨干和一个开发同事，组成两人试点小组。业务骨干负责出题目和验收，开发负责接API和调流程。
2. 挑一个场景，从真实业务里收集20到50条样本。比如20条真实工单，或者20份合同的不同章节。
3. 用有免费额度或最低档的公开API，把样本逐条跑一遍。
4. 业务骨干对每条结果打分：是否可用、错误类型、改进意见。注意，不是技术同事打分，是业务人员打分。
5. 跑两周，积累几十条带标注的结果，形成第一份《试点可用性报告》。

很多平台都有免费额度，或者最低档套餐足以支撑试点量级。技术团队再配合 FastGPT、Dify 这类工具，甚至可以把试点直接做成一个小界面给业务用。界面丑一点没关系，关键是让真实业务人员每天在点、在看、在反馈。

4.3 第一组数据怎么读：别用“准不准”一刀切

试点结果看三个数：

• 可用率：业务可以直接采用，或只做轻微修改后采用的输出占比。
• 修正成本：业务改动一份输出大概要多长时间。
• 错误集中点：哪一类样本总出错，错的类型是标签选错、信息漏掉，还是格式不符合要求。

可用率在70%以上，基本可以进到扩大试点阶段；30%到70%之间，先别急着换方案，去改提示词或调整输入数据，很多错误其实是需求描述不清导致的；不到30%，换场景或换模型，别在这个场景上死磕。

这个章节给的建议可能看起来比较慢，但恰恰是这快不起来的两周，能帮老板省掉后面最大的那笔预算——买错方向的钱。

5. 上线和铺开之间：先算清楚预算、ROI和退出机制

试点通过后，项目进入铺开阶段。这时老板最容易在两个方向上犯错：要么觉得成功了直接砸钱铺开；要么开始焦虑“不够稳定”迟迟不敢上。正确的姿势是把账算明白，同时设定好止损线。

5.1 预算模型：实验预算、生产预算、运维预算分开列

别把预算打包成一坨，建议分三份：

• 实验预算：控制在总预算的10%到15%，覆盖试点API费、试点小组人力。这个阶段的任务是验证，不是大规模投入。
• 生产预算：模型调用费或硬件折旧、系统对接、效果监控。按前面提到的Token公式，根据预估调用量产出一个半年区间。
• 运维预算：负责调优和迭代的人。要么是固定岗位，要么是现有团队折算工时。这块最容易被忘，但没有它，试点的效果保持不住。

我见过很多公司的预算比例是70%买模型和硬件，30%留给实施，最后连一个业务接口都接不完。后来调过来的比例是30%给技术资产、70%给人力和流程，项目反而跑顺了。顺序很重要：先让项目活着，再考虑买得风光。

5.2 ROI不要只算“省了几个人”

许多老板算大模型价值，习惯性折算成人力成本，比如“省了两个客服、省了一个标书专员”。这种算法会严重低估项目，因为大模型常常带来的是增量价值：

• 同样的人，一天能处理的工单从50个变成200个；
• 标书初筛吞吐量翻倍，意味着同样时间能投更多标；
• 售后响应从几小时变成几秒，客户流失率变化。

省人赚的是小钱，增量赚的是大钱。做ROI表时，建议列三行：省下的时间（换算为人数）、提升的质量（错误率、客户满意度、响应速度）、新增的能力（以前做不了的事）。后两行的数字往往比第一行大得多。

5.3 三个信号出现，说明项目该停或转向

铺开三个月后，如果出现下面三个信号，别犹豫，停下来复盘：

1. 真实日调用量还是个位数，业务人员不愿意用。技术团队说“功能都上线了”，但数据不会说谎。
2. 业务部门要求对AI输出保留100%人工复核，且复核成本比手工做还高。这说明AI没有减少工作量，反而增加了工作量。
3. 关键的业务数据始终无法开放给AI，演示只能靠造假的测试样本。这意味着项目根本没接进真实业务。

这三个信号都不等于“模型不行”，而是场景、数据、流程和AI不匹配。停下来不是认输，是避免把坏项目拖成更大的坏项目。换个场景重新试点，往往很快就跑通了。我见过一家公司做智能客服失败后，把同一套技术挪去做内部IT工单问答，反而两周就见效了。

6. 落地之后真正要盯的事：运营、迭代和组织分工

过了铺开线，项目进入持续运营阶段。这个阶段的坑不会像前面的坑那么剧烈，但会一点一点把项目拖死。老板的注意力要从“上线”转向“持续使用”，重点盯三件事。

6.1 模型上线只是开始：评测集和反馈回流

上线前要做一个评测集：几十条覆盖典型场景的输入和期望输出。以后每次换模型版本、改提示词，都拿它跑一遍，保证变化不会让已经好的地方变差。这几十条数据就是AI项目的“体检表”，没有它，你可能某天发现模型变笨了还不知道是哪次升级造成的。

同时要设一个反馈回流开关：让业务人员对AI输出点“对”或“错”，那些被打标记的样本会持续累积成下一轮优化的素材。没有这个开关，AI只会原地踏步。另外，上线初期要做几轮边界测试，用刁钻的、反转的、带诱导性的输入去试探输出，防止模型被“带偏”。很多问题不是模型知识不够，而是边界没有划好。

6.2 别急着成立AI部门，先从业务骨干里找“翻译官”

我见过不少公司一上来就搭一个AI团队，结果团队和业务各讲各的话。更有效的做法是从现有业务团队挑一个逻辑清楚的骨干，把一半精力切过来当“翻译官”，负责定义场景、梳理输入输出规则、验收效果。技术侧的职责是把这个人的业务语言变成模型调用和提示词。

这个人不需要会写代码，但要有两个特质：能把业务问题说得非常具体；愿意反复试错。很多公司最后发现，这种人的价值比一个高级算法工程师还高，因为项目推动靠的是业务认可，不是技术指标。

具体怎么安排？每周固定一个联席评审会，业务骨干和技术开发一起过一遍新加的场景和收到的反馈，当场决定哪些调整下周生效。这种例会看起来很笨，但能避免技术和业务脱节。

6.3 老板每周只要盯两个指标：采纳率和实际使用率

模型跑分再高，如果业务人员一周只用两次，这个项目仍然是失败的。老板不需要懂技术指标，每周盯这两个就够了：

• 采纳率：AI输出被业务直接采用，或者只做轻微修改后采用的比例。低采纳率说明输出不匹配业务习惯，通常调提示词就能解决，不必推倒重来。
• 使用率：目标用户里，每周真的在用AI的人数占比。低使用率说明需求场景选错了，或者入口太麻烦，这是产品问题，不是模型问题。

这两个指标不需要任何技术背景就能看懂，却最能反映项目健康度。我之前跟踪过一个项目，上线首月使用率不到20%，业务负责人天天抱怨说模型不行。后来发现是入口藏得太深，要在三个系统里跳转才能用到AI功能。把入口集成到业务人员天天开的系统里之后，使用率直接到了70%。模型一个字没改，效果完全不同。

最后说点实在话

这个行业现在最不缺的是“大模型很厉害”的信息，缺的是一家公司把它用起来的方法和耐心。那些花钱买了几百万硬件然后吃灰的公司，和那些用几万块API费用把业务跑通的公司，差别往往不在于预算多少，而在于路线顺序对不对。别急着买大模型，不是说大模型不值得投入，而是买只是第一步，有时候连第一步都不算。把一个小场景用最低成本跑出来，拿到真实数据，再决定下一步买什么、花多少钱——这是每一个老板都能立刻开始的最小动作。

这个月，建议你先做一件事：把公司里那件所有人都嫌烦、但又天天在做的单点事务列出来，挑一个量化最容易的，让技术同事接个公开API跑两周。两周后的数据，会比任何厂商的PPT都更能告诉你，这条路到底该怎么走。