"数据比算法更重要，业务比技术更重要。" 这句话我以前也常说，但真正理解还是最近几个月接触了很多中小企业的大模型应用项目之后。
今天来讲个很有代表性的售前报价 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 米扬程） 、稳压泵×1（8 吨/小时） 、变频控制柜×1（ABB 变频器+施耐德电控元件） 、气压罐×1（Φ800 规格） 、各种阀门、传感器、管道...
对于这类需求，这家工厂大部分设备都会外采，比如从格兰富采购水泵从 ABB 采购变频器从施耐德采购电控元件等，最后连同自己的部分组件一起组装调试成一套系统，当然还向客户提供安装、售后等服务。
1.2
业务复杂度
不熟悉这个行业的盆友，可能会好奇为啥会需要这样的集成商呢？简单来说，就是因为组合太复杂了。
设备维度
10+种核心部件（泵、变频器、控制柜、气压罐、传感器...）
每种部件几十到上百个 SKU
3-5 个主流品牌，每个品牌又有多个系列
需求维度
流量：5-100 吨/小时（每个项目不同）
扬程：20-120 米（每个项目不同）
品牌：客户可能指定，也可能不指定
预算：有的要求性价比，有的要求质量
标准：有的是国标，有的是地方标准
一个简单计算
10种部件 × 平均50个SKU/部件 = 500种选择理论组合数 = 50^10 ≈ 10^17 种可能
实际可行的组合几千到几万种，这也是为什么报价这个活儿需要老板的资深从业经验。进一步来说，这类公司的核心价值，是针对各种非标需求，提供了选型+集成+交付的打包解决方案。
1.3
真实场景还原
为了更好理解这个需求场景，结合客户的口头描述情况，我尝试还原一下实际的业务场景。
首先，一般是微信上朋友转介绍来一个意向客户，对方上来就发了个 Word 文档的招标需求： 某大学新建生活给水系统，要求：主水泵：28m³/h，85m 扬程，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-7（85 米）。
更进一步的，可以再推荐合理价格，例如 "同类配置历史均价 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_searchresults = hybrid_search(query="交换机 预算10万",top_k=10,bm25_weight=0.6, # 60% 精确匹配vector_weight=0.4 # 40% 语义理解)
5.2
数据流转全流程
这张图展示了报价单文件从上传到可以被检索的完整数据处理流水线。核心流程是：解析 Excel → 识别子表 → 提取设备清单 → 构建特征文本 → 调用 Ollama 生成向量 → 同步到 ChromaDB。
有个关键点：不是每个 Excel Sheet 都会被处理，只有包含完整 9 列标准表头（序号/设备名称/型号/品牌/数量/单位/参数/单价/合计）的表格才会被识别为"子表"。实际测试中，5 个报价单文件可能只识别出 15 个子表，每个子表会生成一条向量索引，最终可能累积几十到几百条可检索的条目。
# Excel 解析入口from src.core.excel_parser import parse_excel_to_dbfile_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 Falseif word in self.vocab:self.vocab[word]["freq"] += 1else:self.vocab[word] = {"freq": 1, "last_used": str(date.today())}jieba.add_word(word) # 动态加载到 jiebaself.save()return True
5.4
混合检索流程
这是整个系统最核心的部分。BM25 负责精确匹配（比如用户搜"H3C S5120"必须能找到），向量检索负责语义理解（搜"千兆核心交换机"能匹配到各种品牌的类似设备）。
权重配比还在动态优化中，目前采用的是 60% BM25 + 40% 向量。因为报价单场景对型号、品牌的精确性要求很高，不能全靠语义，但又需要向量来补充模糊查询的能力。最后做了文件级聚合，避免同一个报价单的多个子表把结果列表刷屏。
# 混合检索核心代码片段（简化版）bm25_scores = bm25_search(query, top_k=50)vector_scores = vector_search(query, top_k=50)# 融合分数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] = score
5.5
数据库 ERD 关系
系统用了两个数据库：SQLite 存业务数据（报价单、子表、向量），Supabase 存埋点数据（搜索日志、用户反馈）。这样设计的好处是即使 Supabase 挂了或者断网，本地检索功能完全不受影响，埋点数据等网络恢复后再补传就行。
SQLite 里的 quote_embeddings 其实是和 ChromaDB 同步的，为什么还要存一份？因为需要通过 file_id 和 table_id 反查原始数据，ChromaDB 只负责快速检索，元数据管理还是得靠关系型数据库。
# 典型的关联查询SELECT f.filename, t.sheet_name, e.contentFROM quote_files fJOIN quote_tables t ON f.id = t.file_idJOIN quote_embeddings e ON t.id = e.table_idWHERE e.id IN (向量检索返回的 ID 列表)
5.6
用户行为埋点
下面这个时序图展示了完整的用户交互链路，从上传文件到搜索、下载、反馈全程埋点。关键是用 query_id 把整个链路串起来，这样后续分析的时候就能知道"用户搜了什么 → 下载了哪个文件 → 给了好评还是差评"。
Session ID 是前端用 localStorage 生成的，这样即使用户刷新页面也能保持会话连续性。所有埋点调用都是异步的，用 Supabase 的 Python SDK 直接插入，不会阻塞用户体验。
// 前端生成 Session ID（static/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 持久化会话 ID
Query 追踪: 后端返回 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_code），Mac 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 小企业主手里。
项目源代码及脱敏测试文档已发布至星球，加入后自取
