企业官网建设流程全解析

起因很普通，一个做小家电的朋友，售后团队两个人，在售型号四十多个，说明书和常见问题散在几个共享文件夹里。客户问一句"这个滤芯多久换一次"，客服得先确认是哪个型号，再翻对应的手册，来回三四分钟，他想做个能自动回答的入口。

我列了张清单，文档切片、向量库、embedding 服务、重排模型、一套常驻的问答服务，再加一份调用日志，写满小半页纸。

真动手以后发现，这半页纸上大部分条目，蓝耘元生代的控制台里已经有了；下面按我实际走过的顺序讲，每一节都是同一个结构，我原本准备自己干什么，后来发现不用干，以及这件事的边界在哪。

一、一个凭证，撑起文字和图片两条输入

朋友的问答会遇到两类输入，一类是客户打字的文字问题，另一类是客户拍的产品铭牌照片，他想让客服直接拍照，不用手输型号；前者走文本模型，后者得能看图，按我以前的习惯，这两类要各申请一份凭证，再写两套鉴权代码。

蓝耘元生代这边则是一份凭证管住全部模型，模型名只是请求体里的一个字段，接口地址也只有一个：

fromopenaiimportOpenAIimportos client=OpenAI(base_url="https://maas-api.lanyun.net/v1",api_key=os.environ["LANYUN_API_KEY"],)answer=client.chat.completions.create(model="qwen3.8-max",messages=[{"role":"user","content":question}],)

chat.completions这套方法、消息结构、流式返回、工具调用，一行都不用改。从接入角度看，改动量就是base_url和model两个字符串。

少一份凭证省掉的不只是一次申请。配额要分两处看、用量要对两遍账、轮换密钥要停两次服务，这些都是常态化的维护成本，现在这一行直接从清单上划掉了。

边界也在这儿，一份 Key 能调平台上的全部模型，一旦泄出去，损失面比原来大得多；凭证少了不等于风险小了，是风险集中了，所以这份 Key 只从环境变量读，代码里不出现明文，开发和生产分开两份，换的时候按环境换。

二、检索那段没自己写，创建表单只有三项

我原本打算自己搭检索，做法都想好了，把四十多份手册切成小块，算向量存进向量库，查询时先检索再拼上下文，效果不够就再挂一个重排模型；这套东西写起来不算难，难的是它得一直活着，向量库要备份，embedding 服务要扛住并发，手册更新了要重跑一遍切片。

实际动手时发现，蓝耘的控制台里「数据管理 > 知识库」点一下新建，表单只有三个字段。知识库名称填到一百字，知识库描述填到两百字，向量化模型从下拉里选一个，确定就完了。向量库、切片逻辑、embedding 服务全在后面，列表页会给每个库标出切片数量和文档数量，状态和更新时间也是一列。

向量库和 embedding 服务这两样，我一样都不用部署，选一个向量化模型，整条检索链路就通了；对照我那张清单，划掉的是切片逻辑、向量库的选型与运维、embedding 服务的部署和扩容。

边界落在文档量级上，这套做法适合资料在几十份到几百份、问题以查事实为主、不需要复杂排序的场景，朋友那四十多份手册正好落在区间里；如果文档到了十万份这个量级，或者要按人员权限做隔离、要混合检索加重排序，那还是得自己搭，它给的是能跑起来的下限，不是能力上限。

三、对话层有现成模板，但那是默认答案不是唯一答案

蓝耘的「模型服务 > 智能路由」这一页我看得比较久，页面顶部写着一句原文：「平台提供内置路由策略，支持直接调用或复制后调整模型优先级与异常处理规则。」

页面分两排。上排是分类标签，办公协同、客服工单、研发分析、文档数据、营销多媒体。

下排是十张按业务场景预置的模板卡片，通用、智能客服与工单、邮件与即时消息辅助、企业知识库问答、合同与法务审阅、公文与文档写作、财务票据与报表处理、代码开发与评审、数据分析与商业智能、营销文案与多媒体创作，常见的企业业务类型基本都覆盖到了。

朋友这个场景正好落在客服工单这一类里，每张卡片都预置了一组默认模型，三个主模型加两个备用模型，还标了适用任务；卡片底部三个动作，调用标识、立即调用、复制编辑，调用标识就是拿去当模型名用的东西，代码里把它填进model字段，请求就落到这套策略上。

这里有个容易搞混的地方，我一开始也想错了。模型广场里那个叫 AutoModel 的，看着也是不用自己选模型，但它和智能路由不是一回事；AutoModel 是广场里的一个模型，填进模型名就把选型权交出去了，代价是响应里只回automodel这个名字，不告诉你实际路由到了谁。

智能路由则是模型服务下的一个独立入口，拿到的是一个任务标识，策略和模型集能在线改，任务详情里带账单。

这一页真正有用的地方，是它把复制编辑摆在了明面上，平台给的是默认答案，不是唯一答案。预置的模型组如果不合适，复制一份出来改模型优先级、改异常处理规则，改完在线生效不用发版；朋友这个规模我打算先用默认的，等真出现某一类问题答不好，再复制一份出来动。

边界提前记一笔，模型集带着自己的限流配额，撞到配额的表现是请求被拒而不是变慢，所以备模型不能是摆设，得真的能顶上去。

四、模型不是越贵越好，得看这次任务被什么决定

客服问答是短问短答，输入是客户一句话加上检索回来的几段资料，输出是两三句解释，这类任务的量级不大。

蓝耘同一份凭证下的模型，单价差得并不小，输入从每百万 token 两块钱到十二块钱都有，输出从三块到三十六块都有，输出那一项能差出十倍以上。

所以选型的第一件事不是挑最便宜的，而是先看这次任务的成本被输入还是被输出决定；客服问答两头都轻，中档模型足够，像把一整年的工单导出来做归类这种，输出量大、结构要求高，才值得往上走一档。

有一个可以带走的判断，输出量是你说了算的，输入量是资料说了算的；输出多的任务先想办法压输出，限字段、限条数、只让它回结构化的东西，压完再考虑换模型。输入多的任务先想办法少喂，检索命中准一点，少拼几段无关资料，比换模型省得多。

五、想把口径改掉，我算了一笔账

问过几轮之后会冒出一个念头，能不能让模型学会朋友家的说法。四十多个型号的换件周期、耗材规格、常见故障，这些内容是固定的，全塞进提示词太长，靠文档检索又未必每次都能命中。

「模型服务 > 模型微调」就是冲这件事来的，蓝耘把它收进了一个表单，底座模型从平台上的模型里选，训练方式是 LoRA，参数是 Epoch、Learning rate、batch_size、LoRA Rank、LoRA Alpha、LoRA Dropout 六个。

数据集从「数据管理 > 数据集」里挑，那边分 SFT 微调、DPO、继续预训练三种，格式是 jsonl。

往下是选算力，型号是 NVIDIA H200，一卡一小时十六元，两卡三十二，四卡六十四，八卡一百二十八，按卡数和时长线性走。

我在这儿停下来算了一下，朋友那边一天的咨询量就算全交给模型，推理开销也是分这个量级。而训练的最低下限是一卡一小时十六元，这两者差着一个数量级，不是省着用就能拉平的。

所以这一节我没往下走，微调对朋友这个规模还不是现在该做的事，等工单攒到几千条、某个环节反复出错、并且这个能力要在多个业务里重复用，摊销的分母才够大。

入口我还是记下来了，它解决的是想做这件事的时候不用先解决有没有机器的问题，买不到卡、抢不到时段、环境配不明白，这三样真到微调那一步都会拦人。

一处细节如实记下，训练费用那一栏显示的是抵扣后的数字，页面上写着存在卡券会优先使用卡券，所以看到零不代表不花钱，得连账户里的券和余额一起看。

六、常驻那一步，选两个下拉框就够了

问答要能被人用，得有个地方常驻，我原本的打算是租一台小服务器，装好运行环境，用进程守护跑起来，前面挂反向代理，配好证书。

实际在蓝耘上走了一遍，流程是三个选择加一次点击：先选模式，OpenClaw 或者 Hermes 二选一，这两个都是开源项目，平台把它们做成了可以直接创建的容器。

再选套餐，日常开发那档是每月二十九元、两核四G内存、五十G系统盘，尝鲜那档是每月九块九、两核两G、二十G，选完挂载哪个模型、买多长时间，点创建。

整个过程没有出现部署脚本、没有出现 Dockerfile、也没有出现反向代理配置。

这一节我也没往下走，原因很直接，朋友那边还没有真实咨询量，现在迁过去只是把一台空跑的机器从我这挪到平台上，每月照样付一份钱；我的做法是先在本机把问答链路跑顺，等真的有人用了、量起来了再迁，那时候选套餐也有依据，知道该选两核还是四核。

边界说清楚，九块九那档是两核两G，客服问答这种并发不高的场景够用。但要记住它是按月计费的常驻成本，跟按 token 走的推理费用是两笔账，一笔随用量走，一笔不管用不用都要付。

七、账本有两本，维度不一样

跑起来之后要盯的是两件事，钱花在哪，和为什么慢。

蓝耘的调用记录里单独有一列 TTFT，首字延迟。这一列的价值在于把"慢"拆成了两段，从发出请求到吐出第一个字的等待，和之后流式输出的过程；这两段的原因完全不同，前者是排队和调度，后者是输出 token 的数量。没有这一列，你只知道一次对话花了八秒，至于是模型卡住还是答案太长，只能靠猜。

平台那本账按模型、调用方式、API Key、统计周期几个维度切，切到哪个模型花了多少就到头了；它回答不了哪一步花了多少，因为一次业务动作中间可能调了好几次模型，平台看到的是几次独立请求。

所以我另外记了一本，按阶段记，检索、生成、复核各占多少 token。两本账不是重复劳动，平台那本管结算，我记的那本管优化，哪一步值得改，只能从自己那本里看出来。

八、清单上还剩什么

回到开头那张清单，四十多个型号、两个客服、一堆散着的手册，这件事现在有了可行的做法，接一个接口，建一个知识库，套一张客服模板，先在本机跑通。

这半页清单上的活，蓝耘元生代接走了一大半，划掉的是向量库、embedding 服务、切片逻辑、多份凭证、训练环境、部署脚本；留下的是提示词怎么写、检索命中率高不高、答错了怎么发现，这些事没人能替你干，工具只负责把重复的部分收走。