"數據比算法更重要，業務比技術更重要。" 這句話我以前也常說，但真正理解還是最近幾個月接觸了很多中小企業的大模型應用項目之后。

今天來講個很有代表性的售前報價 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 文檔的招標需求： 某大學新建生活給水系統，要求：主水泵：28m3/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: 需求解析 │
└───────────────────┘
        ↓
提取結構化參數：
- 主泵：28m3/h, 85m, 22KW
- 穩壓泵：8m3/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.1BOM 表沒現成的

現場第一次剛開始聊的時候，我上來就問了下，能不能先看下產品的 BOM 表。結果老板說沒有現成的，只有一些供應商的 Excel 明細表、PDF 樣冊，還有一些沒有的可以找供應商去要。我問對方沒有參考材料那他怎么去報價的，老板回答得比較干脆，說要么翻歷史報價單，要么打電話問供應商。

3.2沒有固定選型規則

接著我問了下選型規則的問題，比如，流量 28 噸、揚程 85 米，應該選什么型號？老板結果來了句這要看情況。先看預算，預算充足就用格蘭富 CR32-7，質量好，預算緊張就用威樂 MVI3204，性價比高。其次，看客戶要求，有的招標文件明確只要格蘭富，有的要求國產品牌，進口的反而不要。

另外還要看交貨期，比如格蘭富有現貨的型號優先選，沒貨要訂貨，至少 3 周，客戶等不了，急單只能選有庫存的，哪怕參數不是最優。還有些更隱晦的參考條件，比如看供應商關系，跟 XX 品牌的經理關系好，能拿到 9 折，XX 品牌那邊有賬期，資金緊張就選威樂，再或者某些型號供應商有返點，優先推薦等等。

3.3定價是個玄學

關于報價單的上的定價問題，我最初以為簡單粗暴的做法無非是有個 BOM 表的成本價，然后按照比例，或者金額進行加價，就是有一定的報價規則可以硬編碼。但聽老板實際解釋下來，發現根據不同的采購量、付款方式、供應商的關系、市場波動，還有配套銷售等等方面的原因，價格都是動態的。

3.4MVP 的邊界思考

總而言之，在這類場景里報價的關鍵是靈活決策，而不是標準流程。核心的知識也不在任何系統里，而是在老板腦子里。仔細梳理老板的報價人肉工作流，最耗時間的環節也確實不是選型和定價。

最開始預想的端到端的 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_search


results = 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_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 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.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 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 小企業主手里。