企业官网建设流程全解析

昆明网站seo技术厂家,做个小程序开发的公司,wordpress api插件,2345网址导航怎么关数据比算法更重要#xff0c;业务比技术更重要。 这句话我以前也常说#xff0c;但真正理解还是最近几个月接触了很多中小企业的大模型应用项目之后。 今天来讲个很有代表性的售前报价 Agent 项目#xff1a;一家年产值 2000 万的设备集成商#xff0c;7000份…数据比算法更重要业务比技术更重要。 这句话我以前也常说但真正理解还是最近几个月接触了很多中小企业的大模型应用项目之后。今天来讲个很有代表性的售前报价 Agent 项目一家年产值 2000 万的设备集成商7000份历史报价单10种设备组合没有 BOM 表没有标准流程。很好的反应了国内中小企业的常态换句话说不是不想数字化而是连基础的数据治理都还没开始。在这样的环境下做 AI 应用落地技术反而是最不重要的那部分。我最初的设想是做一个中规中矩的 AI Agent解析 Word 需求 → RAG 检索 BOM 知识库 → Agent 规划选型 → 自动输出 Excel 报价单。标准的 RAG Multi-Agent 方案技术上看似很完美。但第一次和工厂老板深度聊了后发现这个方案压根行不通。原因也很简单我预设的完整产品数据、标准价格库、明确的业务规则其实并不存在。当然这个事并没黄。最后我做了一个看起来很初级的检索系统用向量搜索帮老板在海量历史报价里快速找参考。就这么简单的东西却解决了 80%的问题。这篇试图说清楚项目客户画像、真实需求场景、MVP 需求边界梳理过程以及技术方案的七个关键维度拆解。以下enjoy:1、项目背景一览以下分别讲下这家客户的业务模式业务复杂度、真实报价场景环境和痛点梳理。1.1、业务模式这是一家做水处理设备集成的小工厂十来人的规模 年产值 2000 万左右。 主要业务模式是部分部件 ODM大部分设备组件做集成。啥是集成 举个例子某个大学要建一套生活给水系统可能需要主水泵×2格兰富品牌28 吨/小时85 米扬程 、稳压泵×18 吨/小时 、变频控制柜×1ABB 变频器施耐德电控元件 、气压罐×1Φ800 规格 、各种阀门、传感器、管道...对于这类需求这家工厂大部分设备都会外采比如从格兰富采购水泵从 ABB 采购变频器从施耐德采购电控元件等最后连同自己的部分组件一起组装调试成一套系统当然还向客户提供安装、售后等服务。1.2、业务复杂度不熟悉这个行业的盆友可能会好奇为啥会需要这样的集成商呢简单来说就是因为组合太复杂了。设备维度10种核心部件泵、变频器、控制柜、气压罐、传感器...每种部件几十到上百个 SKU3-5 个主流品牌每个品牌又有多个系列需求维度流量5-100 吨/小时每个项目不同扬程20-120 米每个项目不同品牌客户可能指定也可能不指定预算有的要求性价比有的要求质量标准有的是国标有的是地方标准一个简单计算10种部件 × 平均50个SKU/部件 500种选择理论组合数 50^10 ≈ 10^17 种可能实际可行的组合几千到几万种这也是为什么报价这个活儿需要老板的资深从业经验。进一步来说这类公司的核心价值是针对各种非标需求提供了选型集成交付的打包解决方案。1.3、真实场景还原为了更好理解这个需求场景结合客户的口头描述情况我尝试还原一下实际的业务场景。首先一般是微信上朋友转介绍来一个意向客户对方上来就发了个 Word 文档的招标需求 某大学新建生活给水系统要求主水泵28m³/h85m 扬程22KW立式多级变频泵 品牌要求格兰富/威乐/塞莱默配置一用一备带稳压泵和气压罐控制恒压变频供水可接入 BA 系统 后面还有 8000 字的技术要求...工厂老板翻了几遍需求描述文档脑子里捕捉到关键信息28 吨、85 米、22 千瓦、格兰富、一用一备 还要稳压泵、气压罐、变频控制 内心 os 这个跟去年那个 XX 大学的项目差不多然后凭着记忆开始在电脑文件夹里搜索最相关的关键词找到几个打开看看参数比如这个扬程只有 75 米不够这个流量是 30 吨稍微大了点但可以参考最终找到 3 份比较相关的然后开始对比修改。改的过程据说倒不是很慢就是主要参照最相似的那一份修改比如 把流量 28 改成 18扬程 75 改成 85 ,泵型号要重新选原来的 75 米泵不够用价格重新算的话就再打个电话问供应商报价。1.4、痛点总结现场在老板电脑上看的时候注意到这家工厂最早从 12 年就开始做相关的集成设备业务。目前十来个年头里积累了 7000 多份的报价单而且文件命名相对来说没有那么的规范或者统一。不过哪怕文件命名相对规范单靠个人记忆能记住的案例也毕竟有限。进一步的依赖文件名搜索加载很慢不说由于文件名称是个简称并不能很完整的概括报价的主要内容这也导致了检索的参考报价单不够准确进而导致修改的工作量很大。最后从经营层面上来说由于核心的报价工作受限于隐性经验老板很难将其交给助理处理这就导致工厂老板不可避免地每天要花一定的时间据说每天平均 10个报价不定时地去处理这些繁琐的报价工作。另外按照老板的自述也因为这个精力有限所以没有考虑进一步通过像投流等方式承接新的业务。从这个角度来说老板变成了整个公司业务发展壮大的瓶颈所在。2、理想的方案设想在去这家客户之前通过转介绍的朋友大概了解了其主要业务模式。因此我预想了下面这样一个技术方案并提前做了一版非常简单的 demo。┌─────────────────────────────────────────────┐│ 端到端AI报价系统理想版 │└─────────────────────────────────────────────┘客户需求文档Word↓┌───────────────────┐│ Agent 1: 需求解析 │└───────────────────┘↓提取结构化参数- 主泵28m³/h, 85m, 22KW- 稳压泵8m³/h, 75m, 4KW- 品牌要求格兰富- 预算范围X万↓┌───────────────────┐│ Agent 2: 知识检索 │└───────────────────┘↓从完整BOM表中检索- 主泵格兰富 CR32-7符合28吨85米- 稳压泵格兰富 CR15-3- 变频器ABB ACS510-11KW- 控制柜施耐德标准柜- 气压罐Φ800规格↓┌───────────────────┐│ Agent 3: 价格计算 │└───────────────────┘↓从价格库查询- 格兰富 CR32-7¥15,800- 稳压泵¥4,200- 变频器¥4,000- ...总价¥28,500应用折扣规则↓┌───────────────────┐│ Agent 4: 报价生成 │└───────────────────┘↓生成Excel报价单 ✨这个方案成立的前提包含以下假设✅ 数据假设有完整的产品 BOM 表所有品牌、型号、参数有标准的价格库实时更新有明确的选型规则if...then...✅ 流程假设需求是结构化的总是包含流量、扬程、功率选型是确定性的输入参数 → 输出型号价格是稳定的查表即可✅ 技术假设LLM 能准确提取需求准确率 95%RAG 能找到正确产品召回率 90%规则引擎能正确选型准确率 95%但第一次聊完之后发现和预期偏差很大。3、实际情况很骨感现实骨感体现在以下方面3.1、BOM 表没现成的现场第一次刚开始聊的时候我上来就问了下能不能先看下产品的 BOM 表。结果老板说没有现成的只有一些供应商的 Excel 明细表、PDF 样册还有一些没有的可以找供应商去要。我问对方没有参考材料那他怎么去报价的老板回答得比较干脆说要么翻历史报价单要么打电话问供应商。3.2、没有固定选型规则接着我问了下选型规则的问题比如流量 28 吨、扬程 85 米应该选什么型号老板结果来了句这要看情况。先看预算预算充足就用格兰富 CR32-7质量好预算紧张就用威乐 MVI3204性价比高。其次看客户要求有的招标文件明确只要格兰富有的要求国产品牌进口的反而不要。另外还要看交货期比如格兰富有现货的型号优先选没货要订货至少 3 周客户等不了急单只能选有库存的哪怕参数不是最优。还有些更隐晦的参考条件比如看供应商关系跟 XX 品牌的经理关系好能拿到 9 折XX 品牌那边有账期资金紧张就选威乐再或者某些型号供应商有返点优先推荐等等。3.3、定价是个玄学关于报价单的上的定价问题我最初以为简单粗暴的做法无非是有个 BOM 表的成本价然后按照比例或者金额进行加价就是有一定的报价规则可以硬编码。但听老板实际解释下来发现根据不同的采购量、付款方式、供应商的关系、市场波动还有配套销售等等方面的原因价格都是动态的。3.4、MVP 的边界思考总而言之在这类场景里报价的关键是灵活决策而不是标准流程。核心的知识也不在任何系统里而是在老板脑子里。仔细梳理老板的报价人肉工作流最耗时间的环节也确实不是选型和定价。最开始预想的端到端的 Agent 方案是试图自动化并不是最花时间的选型和定价真正应该解决的问题是先帮老板快速准确的自动提取客户的需求描述信息然后再更快更全更准地找到历史参考报价单。换句话说不是替代老板决策而是提供决策支持。4、三阶段落地方案4.1、阶段一解决找得快的问题第一步把所有报价单做向量化用语义关键词搜索代替文件名搜索。比如搜28 吨 85 米格兰富可以找出所有相关的案例并按照关键词和相似度的加权得分排序实际 2 天内完成了第一版开发交付。老板后来使用反馈例如以前搜“格兰富 28”很多相关的文件名里没有这些词就搜不到。现在只要内容里有都能找出来还自动排序。有时候搜到了一个最相关的案例发现自己早就忘了。4.2、阶段二解决提取快的问题核心思路是先短平快的用 LLM 自动提取需求文档关键信息老板只需审核确认不用重复阅读之前的阅读流程。现在的流程简化为Word 文档 → LLM 提取(1 分钟) → 老板审核(2 分钟) → 确认后自动检索。这部分的价值也不是替代人更多也是查漏补缺。4.3、阶段三解决真 Agent 的问题前两个阶段按照工厂老板反馈实际已经解决了 80%的痛点。后续需要更多数据积累以及根据系统数据情况的深度访谈梳理老板的隐性经验。但并不是意味着不考虑进一步开发报价Agent。只是鉴于业务的非标程度较高需要先看阶段二效果来验证投入产出比。当有足够数据和经验后系统理论上不仅能找到相关报价单提取需求信息。 还能对比参数差异 需求 85 米历史报价 41 米扬程不够 然后给出调整建议 建议更换为格兰富 CR32-785 米。更进一步的可以再推荐合理价格例如 同类配置历史均价 2.5 万建议报价 2.3-2.7 万 。最后基于最相似案例自动调整参数生成 90%完成度的报价单。但这还需要上述提到的对全量历史报价单深度分析 以及老板选型经验系统化梳理以及大量实际案例验证策略有效性。一言以蔽之先把阶段二做好用数据说话。如果效果好再决定是否投入阶段三。小步快跑快速迭代。5、技术实现解析以下从系统架构先看全貌、数据流转全流程数据怎么进来、词汇学习机制数据处理的核心技巧、智能检索流程核心功能、数据库 ERD数据怎么存、用户行为埋点运营分析、生产部署架构实际落地七个方面进行实现拆解。5.1、系统整体架构整个系统采用经典的分层架构最核心的是把 Excel 解析、特征提取、检索引擎完全解耦了。这样做的好处是后续如果要换向量模型或者调整检索策略基本不用动核心业务逻辑。图中可以看到四个清晰的层次用户层浏览器→ Web 应用层Flask 静态资源→ 核心业务层Excel 解析 特征构建 词汇管理→ 检索引擎层BM25 向量索引 混合检索。数据存储分散在 SQLite、ChromaDB 和 vocabulary.json 三个地方埋点数据异步上报到 Supabase完全不阻塞主流程。# 典型的检索调用 from src.search.hybrid_search import hybrid_search results hybrid_search( query交换机 预算10万, top_k10, bm25_weight0.6, # 60% 精确匹配 vector_weight0.4 # 40% 语义理解 )5.2、数据流转全流程这张图展示了报价单文件从上传到可以被检索的完整数据处理流水线。核心流程是解析 Excel → 识别子表 → 提取设备清单 → 构建特征文本 → 调用 Ollama 生成向量 → 同步到 ChromaDB。有个关键点不是每个 Excel Sheet 都会被处理只有包含完整 9 列标准表头序号/设备名称/型号/品牌/数量/单位/参数/单价/合计的表格才会被识别为子表。实际测试中5 个报价单文件可能只识别出 15 个子表每个子表会生成一条向量索引最终可能累积几十到几百条可检索的条目。# Excel 解析入口 from src.core.excel_parser import parse_excel_to_db file_id parse_excel_to_db(报价单.xlsx) # 自动触发: 提取子表 → 构建特征 → 学习词汇 → 生成向量5.3、词汇学习机制这个功能是为了解决 jieba 默认词典对专业领域词汇识别不准的问题。比如千兆交换机如果没有专门训练可能会被切成千兆 / 交换 / 机搜索效果就会很差。系统会在每次搜索和解析文件的时候自动提取新词通过简单的规则长度≥2、非纯数字、非停用词过滤后加入词汇表。词汇表存在data/vocabulary.json里会记录每个词的使用频率和最后使用时间后续可以根据频率做更精细的优化。# 词汇管理器核心逻辑core/vocabulary_manager.py def add_word(self, word: str) - bool: if len(word) 2 or word.isdigit() or word in self.stopwords: return False if word in self.vocab: self.vocab[word][freq] 1 else: self.vocab[word] {freq: 1, last_used: str(date.today())} jieba.add_word(word) # 动态加载到 jieba self.save() return True5.4、混合检索流程这是整个系统最核心的部分。BM25 负责精确匹配比如用户搜H3C S5120必须能找到向量检索负责语义理解搜千兆核心交换机能匹配到各种品牌的类似设备。权重配比还在动态优化中目前采用的是 60% BM25 40% 向量。因为报价单场景对型号、品牌的精确性要求很高不能全靠语义但又需要向量来补充模糊查询的能力。最后做了文件级聚合避免同一个报价单的多个子表把结果列表刷屏。# 混合检索核心代码片段简化版 bm25_scores bm25_search(query, top_k50) vector_scores vector_search(query, top_k50) # 融合分数 final_scores {} for file_id in set(bm25_scores.keys()) | set(vector_scores.keys()): score ( 0.6 * bm25_scores.get(file_id, 0) 0.4 * vector_scores.get(file_id, 0) ) final_scores[file_id] score5.5、数据库 ERD 关系系统用了两个数据库SQLite 存业务数据报价单、子表、向量Supabase 存埋点数据搜索日志、用户反馈。这样设计的好处是即使 Supabase 挂了或者断网本地检索功能完全不受影响埋点数据等网络恢复后再补传就行。SQLite 里的quote_embeddings其实是和 ChromaDB 同步的为什么还要存一份因为需要通过file_id和table_id反查原始数据ChromaDB 只负责快速检索元数据管理还是得靠关系型数据库。# 典型的关联查询 SELECT f.filename, t.sheet_name, e.content FROM quote_files f JOIN quote_tables t ON f.id t.file_id JOIN quote_embeddings e ON t.id e.table_id WHERE e.id IN (向量检索返回的 ID 列表)5.6、用户行为埋点下面这个时序图展示了完整的用户交互链路从上传文件到搜索、下载、反馈全程埋点。关键是用query_id把整个链路串起来这样后续分析的时候就能知道用户搜了什么 → 下载了哪个文件 → 给了好评还是差评。Session ID 是前端用localStorage生成的这样即使用户刷新页面也能保持会话连续性。所有埋点调用都是异步的用 Supabase 的 Python SDK 直接插入不会阻塞用户体验。// 前端生成 Session IDstatic/search.js const sessionId localStorage.getItem(session_id) || (() { const id sess_ Date.now() _ Math.random().toString(36).substr(2, 9); localStorage.setItem(session_id, id); return id; })();埋点数据流Session 生成: 前端localStorage持久化会话 IDQuery 追踪: 后端返回query_id关联后续交互行为链路:search → download → feedback完整闭环异步上报: Supabase 插入不阻塞用户体验5.7、生产部署架构Mac mini 现场交付中小企业AI落地的算力“最优解”一台插电即用的Mac mini之前发过一篇 Mac mini 作为中小企业算力终端的文章这个架构也是我接触的几个中小项目中摸索出来的做法。Mac mini 提前配置好在客户现场插电和网线后不用任何操作就能用。本地跑 Ollama 模型不依赖外网 API但通过 WiFi/4G 把埋点数据实时上报到云端 Supabase。OTA 更新是通过 Supabase 的ota_commands表实现的在后台插入一条指令比如pull_codeMac mini 这边每 5 分钟轮询一次拉到指令后自动执行。这样就能远程更新代码、推送新模型、调整配置不需要跑现场。# OTA 轮询逻辑简化版 while True: cmd supabase.table(ota_commands)\ .select(*)\ .eq(device_id, DEVICE_ID)\ .eq(status, pending)\ .execute() if cmd.data: execute_command(cmd.data[0][command]) supabase.table(ota_commands)\ .update({status: completed})\ .eq(id, cmd.data[0][id])\ .execute() time.sleep(300) # 5分钟轮询一次6、写在最后这类中小企业的项目在实际落地过程中我意识到这可能代表了一类被忽视已久的需求。像金蝶、用友这样的传统 SaaS 厂商服务的主要是中大型企业对于大量年营收小几千万的中小企业来说他们既没有预算或者意愿采购重型 ERP也没有 IT 团队去维护复杂系统。这些企业的数字化基础很薄弱甚至连报价单都还在用 Excel 手工管理。但他们手里积累的行业经验、客户资源、产品知识都是真金白银换来的隐性资产。大模型的出现有了把这些隐性经验显性化的可能性。以前做一个企业内部的知识库检索系统可能需要几十万的预算、半年的开发周期还要配专人维护。现在用 Ollama 本地模型 ChromaDB 几百行 Python 代码一个人两周就能搞定原型Mac mini 部署到现场就能跑起来。这种轻量级、低成本、快速迭代的模式让长尾市场的 ROI 算得过账了。从服务商的角度看这也似乎是一个可以规模化复制的标准产品。反观中大型企业虽然数字化基础好但数据孤岛、部门墙、漫长的审批流程往往让一个简单的需求半年都落不了地。相比之下中小企业决策链短、试错成本低老板拍板今天上线明天就能用。或许正儿八经享受到 AI 时代的第一波红利可能不在那些喊着降本增效的大公司而在这些有很深行业 Know-How 小企业主手里。项目源代码及脱敏测试文档已发布至星球一线从业者欢迎交流加入后自取。