企业官网建设流程全解析

先看一组我们自己算出来时都愣了一下的数字：5个人的销售团队，靠一套内部代号叫 Rasp 的 AI 智能体，每个月省下约600小时的等效工时。当时这个数字报上去，运营负责人第一反应是“你们是不是把等待时间也算进去了”。我说对，等待时间本来就是要算的——客户回复的等待、系统流转的等待、人工来回确认的等待，这些在过去都是一个萝卜一个坑地占着人的时间。Rasp 做的事情，简单说就是把销售团队里那些重复、低认知、纯执行的工作接过来，让真人只做需要判断和经验的事。

这套东西能跑通，底层依赖是 OpenRouter。它把我们接入多个大模型的成本压到了很低，一个 API Key 就能按任务切换模型，不用再分别对接不同厂商的接口。我把整个过程拆成几块讲清楚：从时间账怎么算，到 Rasp 的架构设计、关键配置、踩坑实录，再到最后几句大实话。不管你是做销售的、带销售团队的，还是正在给业务方做 AI 自动化的开发者，这篇应该都能给你一份可以直接抄作业的参考答案。

1. 先算一笔账：600小时是怎么从5个人手里挤出来的

1.1 五个时间黑洞，把销售的一天撕成碎片

我们团队做的是某 B2B SaaS 产品的销售，客单价不算低，销售周期两到三个月，所以每个人手里同时有几十个在跑的线索。这种模式下，真正影响成单的是有效沟通时长，但现实是每个人的白天几乎都被五类事占满。

第一类是线索清洗。CRM 里填进来的线索质量参差不齐，有从表单里来的，有展会扫码来的，有客户转介绍来的，经常缺联系人、缺行业标签、缺公司规模。正式联系之前，销售得先去补齐这些信息，一条线索平均花两分钟，一天一百多条就是三四个小时。第二类是邮件跟进。一个销售一天收发几十封邮件，真正需要深度回复的可能只有几封，但每封邮件都要读完、判断意图、组织措辞再发出去，三五分钟是跑不掉的。第三类是会议纪要。每周周会、复盘会、客户需求会加起来十几场，开完会还要整理纪要、提取待办、同步到项目平台，一场四十分钟算少的。第四类是报价单和合同初稿。价格表、服务项、折扣、付款条件都要填进模板，改格式就要折腾半天。第五类是竞品动态和周报。销售新人要培训，老人要盯竞品，每周定期整理行业新闻、竞品更新、话术库，一弄就是几个小时。

这些事有一个共同点：它们不是销售的“本事”，而是销售的“成本”。我花了一周时间盯团队的时间消耗，拉了一个保守的估算表：

这个表就是整个项目的起点。刚才说了，600小时不是把五个人每天压缩出多少“纯空闲时间”，而是这些流程如果继续用手工做，本该被吞掉的等效工时。对我们来说，省下来的时间意味着同样的人力可以覆盖多三到四成的客户量，或者把每个客户的触达频次提上去。

1.2 为什么OpenRouter是这套方案的底座

确定要做自动化之后，技术选型是第一道坎。我们把需求列了一遍：邮件语义判断要有强分类能力，线索清洗要能处理非结构化文本，会议纪要要能长文归纳，报价单生成还得稳定输出结构化字段。没有哪个单一模型在这些任务上全都能打，而且不同任务的频率和成本敏感度差别很大——线索清洗是高频、低单价的活，会议纪要是中频、重上下文的活，邮件起草是低频但需要谨慎的活。

最初考虑直接接入多家大模型厂商的 API，结果发现维护成本很高。每个厂商的接口格式、鉴权方式、限流策略都不一样，今天这个模型效果好，明天另一个模型降价了，每切换一次都要改代码。后来团队里一个开发者提出来用 OpenRouter 做模型网关，理由很直接：它已经把几十家模型厂商的 API 统一成了一个标准接口，我们用一套代码就能完成模型切换，剩下的事情全部交给路由策略。

OpenRouter 在我们项目里承担的角色可以理解成一个“模型调度中心”。Rasp 每个任务进来，先看任务类型和复杂度，再决定路由到哪个模型。比如批量文本分类这种对推理深度要求不高的活，可以路由到便宜的轻量模型，成本只有旗舰模型的零头；而涉及客户邮件语义这种容易踩雷的任务，就强制走强推理模型。这个设计用了一年，最大的感受是“不被任何单一模型绑架”。某家模型服务临时不可用的时候，其他家的接口照样顶着，业务侧完全无感知。后面我会把具体的配置方式展开讲。

2. Rasp怎么设计：让AI干脏活，把决定权留给人

2.1 四条设计原则

Rasp 上线之前，我们定了四条不能破的原则，这几条原则在后续推进中几乎决定了项目能不能被团队接受。

原则一是“能自动的全部自动，但对外动作必须留人工确认”。所谓对外动作，包括发出去的邮件、报出去的报价单、对外承诺的交期等等。AI 可以起草，可以推荐，但最后一下点击发送或者确认，必须由真人完成。这不是不信任模型，而是把责任边界划清楚——模型出错时，最终责任在操作的人。

原则二是“Agent 只做初稿，不做拍板”。Rasp 可以根据客户历史记录和当前对话生成回复初稿，但遇到折扣、个性化承诺、风险话术，它只会给出建议选项，不会自作主张。团队里没有一个人会觉得被机器架空了，反而觉得这是个干活很利索的助手。

原则三是“每个动作都要可追溯”。Rasp 执行的每一次任务，从触发条件、调用模型、输入输出，到人工是否确认、确认耗时多久，全部落日志。后面排查问题、计算真实节省工时、说服管理层继续投入，靠的全是这些日志。

原则四是“从低风险场景开跑，别一上来就碰钱”。我们第一批自动化只做了会议纪要和内部知识库整理，让团队用顺手了，建立信任，再逐步开放邮件、线索清洗，最后才上报价单。这个节奏很重要，销售团队对 AI 的接受度是养出来的，不是逼出来的。

2.2 一次任务在Rasp内部的完整流转

Rasp 的整体结构不复杂，本质上是一个带调度和记忆的 Agent 壳子，核心可以拆成四层。

第一层是触发层。它得知道什么时候该干活。我们接了三个触发器：CRM 新建线索事件、邮箱收到新邮件事件、日历会议结束事件。也可以定时触发，比如每天早上八点生成当日跟进建议，每周五下午生成周报初稿。

第二层是路由层。这是 OpenRouter 发挥核心作用的地方。Rasp 根据任务类型、文本长度、语义复杂度三个维度给任务打标，然后决定走哪个模型。分类标签决定模型档位，文本长度决定上下文处理方式，语义复杂度决定是否追加“谨慎输出”的指令。路由规则写在一个配置文件里，调整模型档位的时候只改配置，不改业务代码。

第三层是执行层。Rasp 要真正操作外部系统，得靠工具。我们给 Rasp 配了 CRM 读写工具、邮件读取与草稿工具、日历查询工具、知识库检索工具、PDF 生成工具。每个工具都是一个封装好的函数，Agent 通过函数调用方式使用。

第四层是人工复核层。Rasp 输出的结果不是直接落地，而是先进入一个审批队列。审批队列展示在团队内部的工作台页面上，销售可以一键通过、一键退回修改、或者直接编辑后发送。这一层是整个系统信任感的来源。

一个典型流程长这样：客户给销售邮箱发来一封询价邮件 → 触发层把邮件文本送入路由层 → 路由层判断属于“高语义复杂度的商务沟通”，路由到强推理模型 → Agent 调用 CRM 工具读取该客户的历史订单和沟通记录 → 结合知识库里的报价规则生成邮件回复草稿到审批队列 → 销售看到草稿，微调了价格表述，点击发送 → 任务完成，日志记录全过程，统计本次节省约4分钟。

2.3 五条自动化工作流的具体实现

线索清洗这条线，Rasp 每天凌晨批量跑一次。逻辑是：从 CRM 里抽出状态为“待清洗”的线索，对每一条做公司信息补全、联系人多渠道匹配、行业自动打标，输出结构化的补全建议。对于置信度在95%以上的字段，直接自动写入；置信度在70%-95%的字段，写入“待确认”状态；置信度低于70%的字段，明确标出来交给人工补。这套分级让系统不至于瞎填，同时把人工工作量压到最低。实测下来，原来120条线索要手工处理四个小时，现在销售只需要看那十来条低置信度的记录，二十分钟左右就能收工。

邮件处理这条线是使用频率最高的。Rasp 在邮件系统上做了收件箱监听，对新到邮件做意图分类：询问产品、询问价格、催促交付、投诉抱怨、已读不回的跟进、垃圾广告。分类结果直接决定动作。催交付的邮件会提示销售“该客户已经等了一周，建议优先处理”，询问价格的邮件会自动带上最近的报价模板草稿。我一开始担心分类不准确，后来设置了连续一周的对照测试：AI 分类 vs 人工分类一致率在九成以上，剩下的基本都是边界模糊案件，人的判断本来也会分歧。

会议纪要这条线属于“用了就回不去”的典型。Rasp 接到会议结束信号后，拉取会议语音转写文本，做三段式处理：先提炼议程和关键结论，再按发言人提取待办事项，最后把待办同步到项目管理系统并标记负责人。销售不需要打开会议工具再去逐条听录音，直接点开 Rasp 生成的纪要，确认任务分配无误即可。

报价单这条线最谨慎。Rasp 从审批通过的邮件中识别报价需求，提取产品型号、数量、客户行业、历史折扣，再从价格表工具里拉标准价，生成一式两份的报价 PDF 和配套说明文字。折扣字段只要出现，就强制要求销售在审批台手动确认，Rasp 不会自己往下填。这个设计在这个项目上线三个月后救了一次：有个案子因为客户采购量很大，Rasp 按惯例生成了批量折扣，但那个折扣级别早就不适用于新款产品了，幸好人工确认环节拦住了。

竞品情报和周报这条线是定时任务。Rasp 每天扫描一批行业关键词和技术社区，抓取内容做摘要，去重后存入团队知识库，每周五下午自动把一周的摘要拼成周报初稿。销售只需要删掉不相关内容、补充自己的客户反馈，十分钟搞定。

3. 落地实操：接入OpenRouter与配置智能体的关键步骤

3.1 模型接入与分级路由配置

先把接入这步讲透。OpenRouter 的使用方式本质上就是一个标准的 Chat Completions API，只是 backend 是它。第一步在 OpenRouter 创建账号、创建 API Key，然后把 Key 配到环境变量里。我们用 Python 调用，核心代码长这样：

import os import requests API_KEY = os.getenv("OPENROUTER_API_KEY") url = "https://openrouter.ai/api/v1/chat/completions" def ask_model(messages, model="openrouter/auto", temperature=0.3): response = requests.post( url, headers={"Authorization": f"Bearer {API_KEY}"}, json={ "model": model, "messages": messages, "temperature": temperature, "max_tokens": 2000, }, timeout=30, ) response.raise_for_status() return response.json()["choices"][0]["message"]["content"]

注意这里 model 参数填了openrouter/auto，这个值表示让 OpenRouter 根据题目自动选一个合适的模型。在项目初期我们确实用它跑了一阵，省去手动测试不同模型的功夫。等跑了两周积累了实际数据之后，发现很多任务用自动路由不是最优的——有些场景想固定走便宜模型，有些场景想固定走最强推理模型。于是我们改成了手动路由配置。

我们的路由配置核心是一个映射表，用 YAML 写成：

route_rules: - task_type: "email_intent_classification" model: "openrouter/auto" temperature: 0 human_review: false - task_type: "email_drafting" model: "a-premium-reasoning-model" temperature: 0.7 human_review: true - task_type: "lead_enrichment" model: "a-cheap-fast-model" temperature: 0.1 human_review: false - task_type: "meeting_minutes" model: "a-premium-context-model" temperature: 0.2 human_review: true

分级的意义一是效果，二是成本。我们把当月 API 账单拉出来对比过，采用分级路由后，单月成本比全程用旗舰模型方案降了差不多一半，同时高难度任务的输出质量没有明显下降。温度这个参数也别忽视，分类、清洗这类任务把 temperature 降到0附近，输出更稳定；起草邮件这种创意性任务，调到0.6到0.8，语气更自然。

3.2 工具链打通：CRM、邮件、日历、知识库

Rasp 真正从“聊天机器人”变成“智能体”，靠的是工具调用。我们把 Rasp 的所有工具统一成一套 JSON Schema 接口，Agent 根据任务需要自行决定调用哪个工具。这里有一个实操建议：工具定义要尽量窄，一个工具只做一件事。比如“读取客户历史订单”和“写入线索状态”要拆成两个工具，不要合成“操作客户数据”，否则模型容易在参数上犯迷糊。

CRM 工具我们对接了开放 API，Rasp 可以读取线索、联系人、订单、跟进记录，也能写入状态变更。邮件工具只开放了“创建草稿”权限，没有开放“直接发送”权限，严格遵守前面说的对外动作人工确认原则。日历工具用于读取会议时间、创建会议邀请。知识库用的是向量检索，文档先切片再存入向量库，Rasp 在回答时先检索相关片段作为上下文，再生成回复。这一步对于报价规则、产品参数这类事实类问题特别重要，能显著降低瞎编概率。

还有个容易被忽略的工具是“模板引擎”。报价单生成不是让模型自由发挥排版，而是让模型输出结构化字段值，模板引擎去套用现成的 PDF 模板。比如模型输出product_code=,quantity=,discount=0.15，模板引擎负责排版。生成速度和格式稳定性都远超直接让模型生成 HTML 再转 PDF 的方案。

3.3 人工复核机制，防止AI失控

人工复核不能设计成“每件事都要审批”，否则销售会疯的。我们的准则是“按风险分级”。风险等级是自动计算的：涉及对外发送的动作全要审；涉及金额变更、折扣、合同条款的动作全要审；只写内部笔记、整理标签、补全公开信息、生成内部摘要的动作，直接自动执行，但保留日志。这样销售每天打开审批台，需要处理的条目通常只有十几条，每条看一眼点掉，整体不超过二十分钟。

审批台本身要做得轻。我们用内部工作台做了一个简单的列表页，每一条任务显示：触发来源、AI 生成的草稿内容、关联的客户和订单、模型分辨率、置信度评分。销售可以直接在页面上编辑，编辑后保存会触发版本记录。

设置置信度评分是为了让销售对 AI 输出有提前心理预期。置信度来自三个信号：模型返回时的采样概率、规则引擎的校验结果、知识库检索的相关度。三者加权生成一个0到100的分数。分数高于90的条目，审批台默认折叠详情，一键通过；分数低于60的条目，醒目提示“建议详细核对后再操作”。

3.4 成本核算和效果追踪

这套系统到底值不值，账要算清楚。我们在每月最后一天拉一次报表，统计维度包括：各任务类型执行次数、调用 token 总量、按路由模型拆分的费用、人工审批通过率和退回率、以及“单任务节省工时”的汇总。

节省工时的核算口径得提前定好，否则各部门会扯皮。我们的口径是：每个自动化任务以一个“手工完成该任务所需的标准时间”为基准，再由人工实际处理时间折算。比如一封邮件人工标准处理时间是4分钟，Rasp 起草后销售只需30秒确认，那这单就节省3.5分钟。一个月下来，所有任务的节省时间相加得到总节省工时。这样算出来才能支撑“每月节省约600小时”这句话。

成本那边，OpenRouter 的 API 是按 token 计费的。我们的月度用量大约在千万级 token，费用在几百到两千之间浮动，具体取决于当月高峰期。语音转写是另一个成本大头，好在会议数量稳定，费用可控。对比一下：如果这600小时全部折算成招聘兼职或者外包处理的成本，哪怕按当地最低时薪水平算，也是 API 费用的几十倍。ROI 在这个项目里是断档级别的划算。

4. 踩过的坑和排查实录

4.1 模型选型：不是所有任务都该用旗舰模型

项目一开始我们犯过一个挺典型的错：所有任务都用同一个强模型跑，觉得“贵有贵的道理”。跑了一周发现，邮件意图分类这种简单任务用旗舰模型完全是浪费，而且因为强模型思考链路长，响应时间反而更慢，批处理队列经常堆积。后来把分类、标签、情感判断这类任务全部切到轻量模型，成本降下来，速度提上去，准确率基本没变化。

反过来也有教训。会议纪要在初期用轻量模型跑，结果长对话摘要丢失关键决策，待办事项提取得支离破碎，甚至出现过把客户说的客套话当成需求的乌龙。这个场景换回强模型之后，质量立刻上来。所以我的建议是：每类任务上线前，拿一周真实数据做 A/B 对照，用轻量模型和强模型各跑一遍，比对输出质量和成本，再决定路由规则。

4.2 API超时与限流

OpenRouter 的 API 偶尔也会碰到限流和超时。最典型的场景是跟某几个大模型厂商的波动有关，但因为我们走了聚合网关，受影响面比直连小很多。即便这样，代码里面也要做重试和退避。我们踩过的坑是：没有重试机制时，凌晨批量跑线索清洗，只要有一个请求超时，整个批处理就中断，第二天早上销售看到的是“清洗失败”的报错。

后来给请求做了三层保护：轻量模型请求失败先退避重试，重试次数上限两次；重试仍失败就排队，等下一轮批量任务统一补跑；所有失败请求都会记录到错误队列，运维只需扫一眼错误队列就能判断是模型问题还是网络问题。

4.3 幻觉与数据安全

幻觉是所有 LLM 应用的必修课。在我们场景里，最怕的幻觉是编造客户名称、编造报价、编造历史沟通。处理思路就一句话：让模型在事实性问题上不依赖记忆，而是去检索。报价数字从价格表工具里实时读取，客户信息从 CRM 工具里实时读取，模型只做理解、归纳和生成，不做记忆。凡是涉及具体数字、客户名称、日期、订单状态，生成之后还有一道规则校验，比如金额格式、折扣范围、日期逻辑。规则校验能拦掉一大半明显错误。

数据安全方面，我们规定客户个人敏感信息在传给模型前做脱敏处理，模型拿到的字段里，姓名和手机号替换成占位符，生成完毕后再映射回来。Prompt 里也做了约束：模型收到的指令是规则化、模板化的，客户原始邮件中的内容被视为“待处理数据”而不是“指令”，防止邮件正文里夹带恶意指令影响模型行为。这套防护虽然不是银弹，但至少挡住了常规的注入尝试。

4.4 团队信任问题

这个坑最容易被技术团队忽略。Rasp 上线初期，销售同事嘴上说“挺方便”，实际行为却是不太敢用，审批台里面堆了一堆未处理的草稿，大家宁可自己重写邮件。后来我们发现根因是“不知道 AI 为什么这么写”。加了置信度分数和生成依据摘要之后，销售能看懂每条建议背后的逻辑，使用率才慢慢上来。

还有个小细节：审批台的一键通过按钮要设计得显眼，编辑功能要顺手。如果工具本身用起来别扭，AI 再智能大家也不愿意碰。我们的做法是让销售同事参加审批台的原型评审，他们提了“不要让我在弹出的多个窗口之间切换”“草稿邮件要能一键复制到邮件正文而不是下载文件”这些实际操作建议。采纳之后，团队接受度立刻不一样。

5. 关于600小时，几句大实话

5.1 等效工时的口径

前面表格里的600小时，我必须再把口径说清楚，免得有人照着抄作业的时候对不上。这个数字是“等效工时节省”，不是“员工每天多出了这么多时间闲着”。它的意义在于：如果没有 Rasp，这些工作量必须有人去做，那意味着要么团队加班，要么增聘人手。所以你也可以理解为，这套系统相当于在团队没有扩编的情况下，凭空多出了大约三个半全职人力。

这种算法在公司内部汇报时很站得住脚，因为你拿出的是“人工原耗时 - 人工现在耗时”的差值，每一步都有日志支撑。但如果有人拿这个数字说“我们团队现在每天只用干两小时活”，那是不对的。销售们省下的时间大多从低价值执行转移到了高价值客户沟通上，这是自动化项目该有的样子。

5.2 哪些团队最适合做这套改造

复盘一下，这个模式不是所有销售团队都能照搬。适合的前提有三个：一是流程标准化程度高，销售每步动作都有明确规则，AI 才有章可循；二是线索和沟通量足够大，至少每天两位数以上的批量任务，自动化的规模效应才出得来；三是管理层愿意花一到两周做流程梳理，把原先“凭经验干活”变成“有规则可执行”。

反过来，如果你的团队做的是客单价极高的战略型销售，每一封邮件都要仔细斟酌个性表达，那自动起草邮件这步就不适合，最多只做会议纪要和情报整理。工具是死的，边界是活的。我们现在的思路也是分阶段扩大范围：先帮团队省出时间，再让省出的时间花在真正不可替代的事情上。

5.3 给准备复刻的同学的最终建议

如果你准备在团队里做类似的事，我的核心建议有三条。

第一条，先花一周记录时间开销，用数据说话。没有前面那张表，后面所有技术方案都会变成自嗨。第二条，不要一开始追求“全自动”，先把“辅助生成 + 人工确认”的闭环跑稳。销售团队对 AI 的信任是靠一次次不出错的草稿攒出来的。第三条，把所有技术细节留给日志，别让销售去理解技术，他们只需要看到一个好用的工具和一个清晰的数字。

最后提一个我们自己还在优化的方向：Rasp 目前还是“任务触发式”，下一步准备做“主动建议式”，比如根据客户长期不活跃、竞品动态等信号，主动触发销售去触达某个客户。这会把节省工时进一步转化为商机收入。自动化这件事，思路一旦打开，可做的空间比想象中大得多。