企业官网建设流程全解析

2024年我从杭州回到西安，和两个老同事注册了一家智能体开发公司，方向很明确：只做垂直行业智能体，不碰通用聊天机器人。两年多下来，最大的感受是这里的市场和北上广完全是两个世界——客户不关心你用了什么模型，只关心你能不能解决他车间里的老师傅退休后没人会修设备的问题、业务员离职后客户跟单断档的问题、以及领导忽然要一份报表却没人会查数据库的问题。到了2026年，西安本地的制造、能源、贸易企业开始主动打听智能体怎么落地，我们的项目从单个定制变成行业复购。这篇东西，就是我在西安做垂直行业智能体开发和本土落地实践的全过程复盘，适合想在这个方向创业的团队，也适合正在帮传统企业做AI转型的技术负责人。

1. 西安市场的真实需求盘点：谁在买单，买单要什么

1.1 本土企业客户的典型画像

在西安待久了你会发现，真正的企业客户不是高新区的互联网公司，而是散布在各开发区、产业园里的制造企业、贸易公司、能源配套商和职业院校。这些客户有几个共同特征：年营收几千万到几个亿，IT部门只有两三个人，甚至没有专职IT；内部数据散落在ERP、Excel、纸质单据和企业微信聊天记录里；管理层听说AI很火，但说不清具体能干什么。

我们接到的第一类典型需求来自一家做汽车零部件的工厂。他们的采购负责人在展会上看了我们的演示，回去就跟老板汇报说"这东西能让新来的质检员少问老员工问题"。第二类典型需求是一家做外贸的小公司，七八个业务员每天有一半时间在回复重复的询盘、查报关政策、翻译客户邮件。第三类来自一所职业技术学院，他们想把实验课的选择式问答搬到线上，让每个学生都能有自己的"AI助教"。

这三类客户决定了我们的产品形态：不是做一个大而全的智能体平台，而是针对每个行业的痛点做"知识库+工作流+系统对接"的垂直解决方案。2026年回头看，这个判断是对的：通用智能体在西安几乎没有付费场景，垂直行业智能体才是企业愿意掏钱的形态。

1.2 客户以为的"智能体"和我们要交付的"智能体"不是一回事

绝大多数客户第一次来咨询，开口就是"我们要做一个AI客服"。但聊到第二轮就会发现，他们真正要解决的不是客服问题，而是业务流程跑不通的问题。比如那家外贸公司，表面上是需要回答客户关于产品规格、交期、付款方式的问题，实际上需要的是：根据客户邮件内容自动填写报价草稿、从历史订单里找出类似产品做参考、把新的询盘自动归类进不同的业务组。这三个动作如果只用"AI客服"去承接，效果一定很差。

所以我们定制了一套需求澄清流程，核心是一个选择式问答清单：

• 你希望智能体"知道"哪些信息？（产品手册、流程文件、历史问答记录）
• 你希望智能体"能操作"哪些系统？（ERP、CRM、数据库、企业微信）
• 哪些问题是必须给出标准答案的？（报价、审批、合规）
• 哪些问题是允许它凭已有知识发挥的？（介绍、解释、建议）
• 回答错了会造成什么后果？有没有人工兜底？

这个清单看着简单，但它能帮客户把他们脑子里的模糊想法，转成可落地的产品边界。很多项目能不能成，在需求澄清阶段就已经决定了。

1.3 真正能成交的三个行业切入口

两年多跑下来，西安市场真正能形成付费意愿的垂直行业智能体，集中在三个方向：

垂直知识库+问答（RAG）：制造和能源行业最普遍的需求。设备维修手册、安全操作规程、质量检验标准，这些文档动辄几百页，老师傅凭经验知道答案，新员工翻半天找不到。用RAG把文档变成智能问答，是投入产出比最高的切入点。

销售跟单与商品推荐：企业有明确的决策链和ROI可算。一个销售智能体如果能让新人快速掌握产品卖点、自动生成报价方案、根据客户历史偏好推荐商品，老板很愿意为它付费。

教学与培训场景：高校、职业院校、培训机构的预算相对稳定。选择式问答、实训辅导、作业批改助手，这些需求在学校里是明确的痛点，而且采购周期清晰、回款也稳定。

这三个方向不是我们凭空想出来的，都是被客户需求推着走才逐渐聚焦的。

2. 框架选型不能只看热度：从Dify到自研的取舍逻辑

2.1 为什么低代码平台是本地项目的第一选择

智能体开发的热门词汇每年都在变，2025年最火的是各种Agent框架和多智能体平台，很多团队一上来就自研编排引擎。但我在西安做垂直行业项目，第一选择永远是Dify、扣子这类成熟平台，理由不是技术，而是交付后的可维护性。

本地企业客户几乎没有一个专职的AI工程师。项目交付后，客户那边真正每天在用的是业务部门的人，比如质检主管、外贸跟单员。他们遇到"智能体回答不准"的情况，第一反应是改知识库、调提示词，而不是看代码日志。Dify这类平台最大的价值，是让业务人员不用写代码就能维护智能体。我们把系统文档、提示词、知识库结构都迁到平台里，客户的项目经理经过半天培训就能自己换零件、调参数。

扣子平台在有些场景下甚至更合适，尤其是客户不想折腾私有化部署、只想要一个能快速上线的内部工具时。但如果是制造业客户、数据不能出内网的场景，Dify社区版的私有化能力就成了刚需。我的结论是：先别管框架是不是"先进"，先问客户谁能长期维护这个系统。

2.2 多智能体框架在什么阶段才需要

2025年"多智能体"成了行业热词，AgentScope、各种多智能体编排框架铺天盖地。但我必须说一句得罪人的话：很多项目把简单问题搞复杂了。一个智能体能解决的，不要拆成三个。多智能体的代价是调试难度指数级上升、回答延迟变高、错误来源变多，对一个只有两三个人维护系统的客户来说，可能是个灾难。

我自己的判断标准很简单：

我们真正启用多智能体是在一个销售跟单项目里：一个Agent负责从邮件中抽取客户需求，一个Agent负责查询历史订单和库存，一个Agent负责根据报价规则生成方案，最后还有一个审核Agent检查数字是否一致。每个Agent的知识库和工具权限完全隔离，这样才不会出现"销售方案里混进了设备维修的内容"这种事故。2026年的现状是，多智能体不是不能做，而是必须建立在单智能体已经跑通、业务边界足够清晰的前提下。

2.3 MCP、RAG、工作流的组装顺序

最近客户和同行问的最多的问题，就是"智能体怎么和业务系统打通""MCP和RAG到底先做哪个"。我的经验是，大部分垂直行业项目里，打通业务系统的优先级应该高于灌知识库。

很多团队拿到项目先做RAG，把一堆PDF丢进向量库，模型确实能回答知识问题了。但客户一句话就能把你问住："那上周的订单金额是多少？"这种问题根本不在文档里，而在ERP数据库里。如果不在前期就设计好工具调用（API、MCP、数据库查询），最后还得返工接系统。

我推荐的组装顺序是：

1. 梳理任务清单，标出哪些是"读文档能答"的，哪些是"查系统才能答"的
2. 先把工作流搭出来，把任务的先后依赖关系定死
3. 接系统和工具调用（MCP/API/数据库连接），确保事实性数据有源可查
4. 再补RAG知识库，覆盖制度文档、产品手册、经验总结这类非结构化内容
5. 最后统一调提示词，让模型知道什么情况下调用工具、什么情况下检索文档、什么情况下直接回答

这个顺序帮我们避开了很多坑。RAG做得再好，回答不了系统里的实时数据，客户一样觉得"不智能"。

3. 把一个智能体真正塞进业务流程：交付层面的关键设计

3.1 权限与私有化部署：本土客户最在意的不是模型能力

做西安的制造业客户项目多了以后，我发现一个规律：他们第一关心的不是智能体聪明不聪明，而是"数据能不能留在我内网"。很多企业有自己的保密要求，产品图纸、工艺参数、客户信息都不能传到外部API。这句话基本决定了技术方案的天花板。

所以我们在投标或方案设计阶段，都会明确问三个问题：

• 这个智能体要处理的数据里，有没有涉密或敏感数据？
• 是否允许调用云端大模型API，还是必须全部在内网跑？
• 客户现场能不能提供GPU服务器？没有的话，CPU推理能不能接受？

如果是纯内网部署，模型一般选择开源模型而不是API。Dify平台可以接入本地模型，向量库用内网部署的向量数据库，Embedding模型也用本地的。整个链路全部内网化，客户才敢把真正的生产数据喂进来。

这里有一个容易被忽略的细节：本地部署的模型和云端API的性能差距是肉眼可见的。所以要在项目启动前就和客户对齐预期，明确"内网环境下，回答速度会慢一些，复杂推理能力会有上限"，避免交付时被吐槽"怎么和你们演示时不一样"。

3.2 RAG落地中的数据清洗与知识库维护

做了一堆RAG项目之后，我敢说80%的效果问题出在源文档上，而不是模型上。客户给的PDF经常是扫描件、表格错位、目录混乱、同一个知识点在不同文件里说法不一。如果直接切块丢进向量库，出来的答案一定让人失望。

我们现在每个RAG项目都有一套固定的数据清洗流程：

1. 先做文档去重，把内容相近的版本合并
2. 扫描件先OCR，人工抽检至少两页，确认识别准确率
3. 表格统一转成结构化文本，因为纯文本切块会把表格拆散
4. 按目录结构切块，起始点放在章节标题，避免语义在中间被切断
5. 重叠窗口切块，通常前后各重叠100-200字，防止跨块信息丢失

切块后还要做一轮检索调参。默认的top_k往往不够用，要根据文档量和问题类型调整。这块没有标准答案，只能一个项目一个项目地试。

知识库上线只是开始，真正的难点是持续维护。我见过太多项目，上线时智能体回答得很漂亮，三个月后客户发现新文档加不进去、旧数据更新不生效，系统就荒废了。所以交付时一定要帮客户建立更新机制：新增文档走什么格式、谁来审核、什么时候重新做向量化。这些写进运维手册，甚至写进合同的服务条款。

3.3 评测与验收：怎么证明智能体"好用"

"智能体到底做得好不好"这个问题，如果答不上来，验收就是一场灾难。客户觉得哪里不对又说不清，你也不知道该改哪里。所以我们现在每个项目必须建一套垂直领域的评测集，用数据说话。

我常用的一张验收维度表：

评测集不是随便找几个问题就行，必须来自客户真实的业务场景。我们一般会让客户提供50到100个高频问题，再叠加我们自己整理的错误变体，组成一个评估集。每次改完提示词或知识库，就跑一遍回归评估，看分数有没有下降。这个习惯救了我们很多次——至少不会出现"改好了一个问题，弄坏了三个问题"的尴尬。

如果涉及代码，也可以用简单的脚本计算准确率：

import json evals = [ {"question": "SKU 30012 的库存是多少？", "answer_docs": ["库存表.xlsx"], "expected": ""}, {"question": "这个订单要审批到哪一级？", "answer_docs": ["订单审批流程.md"], "expected": ""} ] def evaluate(predicted, expected_doc): hit = 1 if expected_doc.lower() in predicted.lower() else 0 return hit total = len(evals) hit_count = sum(evaluate("返回结果中的来源", item["answer_docs"]) for item in evals) print(f"来源命中率: {hit_count / total:.2%}")

脚本本身不复杂，但它把验收从"感觉好用"变成了"指标达标"，客户和我们都轻松很多。

4. 踩坑实录：从Demo到生产环境要过的四道坎

4.1 客户买的是"替班员工"，不是"百科全书"

我们丢过很多单子，大部分不是技术败了，而是需求错位。很多客户看到Demo里智能体能回答各种问题，潜意识里把它当成了"什么都知道的百科全书"，上线后发现它没答出某个很偏门的问题，立刻失望。

现在我在项目启动时一定会做一件事：明确智能体的"支持范围"。给它划定领域边界，边界之外的问题明确回答"不在我的支持范围内，请联系相关负责人"。表面上这是降低了智能体的能力，实际上是保住了信任——客户知道哪些问题可以问，也知道问错了会得到什么反馈，预期就稳了。业务人员真正要的是一个"替班员工"，知道自己该干什么、不该干什么，而不是一个假装全能的聊天机器人。

4.2 模型幻觉在垂直场景里的致命性，以及兜底策略

如果智能体只是讲讲产品介绍，模型说错一两个形容词问题不大。但在报价、安全规程、库存查询这些场景里，模型一本正经地编出一个价格或者一段操作流程，是会出大事的。所以我们给所有垂直场景的智能体都加了硬性的兜底策略。

第一个策略：所有给出事实性结论的回答，必须附上知识库来源或系统数据依据。没有来源支撑的内容，模型宁可说"我需要查阅更多资料后再回答"，也不能凭空推断。

第二个策略：数值类问题不走生成。库存、价格、订单状态这些字段，一律通过数据库查询或API获取，模型只负责把查询结果转成自然语言。数字的来源必须是业务系统，而不是模型的记忆。

第三个策略：设置置信度阈值。对模型的回答做一次"自我评分"，低置信度的时候转给人工处理。这个策略在一些问答场景里非常有效，可以大幅降低错误引导的概率。

没有完美模型。落地的时候，不是追求模型能不犯错，而是设计一套机制让错误不会造成严重后果。

4.3 交接文档比代码更重要

第一次交付给一家工厂时，我们把部署文档和API说明扔给客户就撤了。结果第二周客户打电话来，说知识库更新后智能体回答变差了。一查发现是他们把新文档直接传进了系统，但没做去重和切块处理，导致同一知识点有多个互相矛盾的碎片。

从那以后，我把交接文档提到了和代码同等的级别。一个完整交付包必须具备：

• 系统架构说明：哪些组件部署在哪台机器上，网络访问关系是什么
• 知识库更新指引：文档格式要求、切块规则、向量化步骤
• 提示词变更日志：每次调整改了哪个Prompt、影响范围是什么
• 常见问题手册：高频报错、恢复步骤、客服联系方式
• 业务侧培训资料：面向客户业务人员的操作说明，不需要懂技术

这些文档不是写给工程师看的，是写给客户公司里那个被临时指派来"管智能体"的行政或业务骨干看的。写清楚这些，能减少80%的售后问题。

4.4 部署环境参差不齐

本地化部署遇到的坑远比你想象的多。有的工厂整个厂区用的还是老旧的网络架构，外网访问要层层转发，白名单申请要走半个月；有的客户现场只有一台老服务器，内存32G，还要同时跑模型和向量库；还有的客户数据库只开放给指定IP，智能体应用根本连不上。

现在我养成了一个习惯：签合同之前，先派工程师去客户现场做一次部署环境调研，出一份环境清单：

• 网络拓扑：内网能否访问外部API，还是必须全内网？
• 服务器资源：CPU核心数、内存、硬盘、是否预留GPU？
• 系统版本：Linux发行版、Python版本、Docker是否可用？
• 数据源情况：数据库类型、连接方式、有没有只读账号
• 安全合规：有没有数据外发限制、日志留存要求

别嫌麻烦。环境问题在项目中期爆发，代价是整体工期延期，这个时间成本远高于提前一趟现场调研。2026年的今天，我们接新项目时都把环境调研作为第一道关卡，不再让部署问题成为项目延期的理由。

5. 团队配置与项目节奏：一家西安智能体公司的生存法则

5.1 人效模型：轻研究、重交付

在西安这种非一线城市，一线城市那种动辄几十个人的AI研发团队根本不现实。我们目前只养了一个精干小团队，核心架构是"2+1+1"：两个开发工程师，一个负责前端和交互、一个负责后端和AI链路集成；一个行业解决方案顾问，负责行业调研、客户需求梳理和方案设计；一个项目经理兼客户成功，负责进度、沟通、培训和售后。

这套配置最大的好处是：每个项目的决策链路极短，客户抛出一个需求，当天就能讨论出能不能做、怎么做、报价多少。不会因为组织层级太多，把琐碎的沟通成本转嫁到客户身上。

如果后续业务量上来，我们宁可多招懂行业的实施顾问，也不急着堆算法工程师。垂直行业智能体的重点不在攻克技术难点，而在理解业务、梳理流程、把系统接好。

5.2 项目节奏：两周Demo、一个月POC、三个月交付

做本地项目，节奏感太重要了。一上来就埋头开发，等三个星期给客户看成果，客户往往早就失去耐心了。我们现在的标准节奏是：

前两周做一份高保真Demo，不追求全流程打通，把核心交互和关键答案展示出来，让客户看得见摸得着。一个能聊出行业味道的Demo，比五十页PPT管用得多。

Demo通过后，进入为期一个月的POC验证。这个阶段会接真实数据、跑真实场景，用评测集输出效果报告。POC阶段可以象征性收费，但一定不能免费到底。免费的东西客户不会认真对待，也不会珍惜你的投入。

POC通过后签正式合同，三个月内完成开发和交付。包括系统部署、数据接入、知识库清洗、评测达标和人员培训。这套节奏下，一个项目的完整周期大概五个半月，客户能看到阶段性的产出，我们也避免了长期项目拖垮现金流。

5.3 收费模式：项目制为主，SaaS在2026年还不是主力

我们刚开始也想做SaaS订阅，一劳永逸。但很快发现，西安的量产客户既没有标准化系统，也没有像样的IT基础设施，通用SaaS根本接不进去。每个客户都要定制，SaaS的产品化程度远不够。

所以目前的收费模式是："项目交付费+年度维护费"。项目交付费覆盖定制开发、私有化部署和实施，按项目复杂度评估。年度维护费覆盖知识库更新、模型迭代、系统巡检和培训支持。

这个模式的好处是客户决策简单——一次性采购，没有续费的陌生感。维护费会在第二年产生复购，形成持续收入。缺点是每接一个新客户几乎都要从头搭一套，利润率上不去。这也是为什么我们越来越看重产品化，把一个行业的交付经验沉淀成可复用的模块。

6. 2026年之后：垂直智能体的分水岭与西安的机会窗口

6.1 从"会做"到"规模化"：产品化是唯一出路

做了大量项目制订单之后，我开始意识到一个残酷的问题：每个项目都从零开始做定制，公司只会越做越累，利润也上不去。2026年对智能体开发公司来说，最大的分水岭不是技术能力，而是有没有能力把项目经验沉淀成产品。

我们现在做的，是把已经交付过的行业解决方案拆成两层：一层是"行业知识包"，包括该行业的高频问题集、知识库结构模板、领域提示词模板、评测集；另一层是"技术基座"，包括统一的RAG流程、工作流模板、权限模块、运维脚本。新项目来了，先用行业知识包快速生成Demo，再用技术基座搭建系统，把80%的重复工作固化下来，只对20%的客户特殊需求做定制。

6.2 细分赛道的预测：销售、数据仓库、教学

2026年，我认为西安市场会出现三个快速放量的垂直智能体赛道。

销售智能体：西安的贸易和制造业企业有大量销售跟单需求，把客户邮件自动转化为报价草稿、销售话术推荐、历史订单匹配，这些场景ROI清晰，决策链短。

数据仓库智能体：很多企业积累了十几年的ERP、ERP周边表、Excel台账，管理层想看数据只能麻烦IT部门。让业务人员用自然语言查数据，是刚需中的刚需。这类智能体的关键在于建模和数据权限，技术难度高，护城河也深。

教学训练智能体：职业院校和企业的培训部门有明显付费意愿。选择式问答、实训考核、AI助教这些场景，可以按学期复购，是一种接近订阅制的商业模式。

6.3 给想入局的开发者/公司的建议

如果你也想在西安或者类似城市做智能体开发公司，我只有几条实在的建议，送给你：

第一，不要一上来就做通用智能体平台。通用市场是巨头和资本的游戏，本地公司拼不过。选一个行业扎进去，泡三个月，把客户的业务语言、决策流程、系统链路摸清楚。

第二，从能成交的小订单开始。做一个500人的工厂知识库问答，可能只有两三万预算，但也足够你积累第一个标杆案例。案例比技术更重要，中小客户特别认同行业的"同行经验"。

第三，团队里一定要有能听懂客户业务的人。不是每个写代码的都能和厂长对话。如果你自己是技术出身，就找个行业顾问合伙，或者逼自己天天泡在客户现场。

做垂直行业智能体，本质上不是做算法，是做服务。能放低姿态钻进客户车间里看工人怎么操作、跟着业务员跑几趟客户的客户，比在键盘上调模型的收益大得多。