【向原廠下單系統 ①】人工組報價單的規模極限:型號 × 相容 × 折扣的組合爆炸

前面兩套系統，一套把讀不完、看不懂的設備狀態檔判讀完(設備分析，D19–21)、一套在時效內追完全球漏洞(CVE，D22–24)。這篇是三套範例系統的最後一套，也是跟整個系列主張呼應最直接的一組:它撞的是最赤裸的一種規模——組合爆炸。

一張正確的原廠報價單，不是「查個價格」那麼單純，它是型號 × 相容性 × 折扣/時效三個維度相乘出來的東西。人工做得動的是「相加」——多幾個品項慢慢加;

做不動的是「相乘」——維度一多，組合數就以指數往上翻。

這篇不談技術，先讓你看清這面牆有多高;怎麼翻過去，是 D26 的事。

「幫我報一份 50 人辦公室的網路」為什麼不是一件事?

因為這句話什麼型號都沒指定——它是一個「需求」，不是一張「規格」。 而從需求到規格之間，藏著一連串必須被展開的選擇，每一個選擇又會再岔出更多選擇。

先看一個Presales或是業務每天都會收到的需求:

「幫我擬一份 50 人辦公室的網路報價。」

聽起來很具體，其實什麼都沒指定。要把它變成一張真的能下單的報價單，中間得先回答一長串問題:核心交換器要幾埠、要不要 PoE 供電給 AP、無線要幾台、要不要堆疊、上聯走光纖還是銅線、要不要冗餘電源、軟體授權訂閱幾年、保固要原廠幾小時到府……

每回答一個，底下又岔出更多。你選了某一台核心交換器，它立刻決定了:能配哪些模組、吃哪種光模組、要哪條堆疊線、搭哪張授權——而這些又各自有型號、有相容限制。

這就是重點:從「一句話需求」到「一張可下單的規格」，不是一題填空，而是一連串會層層展開、彼此牽動的選擇。

而客戶的需求也只是希望能依照他的需求迅速列出一個可行的方案跟提出大致上的價格。

這篇先不講它怎麼做到，只讓你先看到「長什麼樣」:

把「幫我擬一份 50 人辦公室的網路報價」這種沒指定型號的需求，AI 先反問幾個關鍵維度、再查候選型號、確認可下單與即時單價，幾秒生成一張規規矩矩的報價單。這篇先講:同一件事，為什麼人工做會撞到牆。

一台選型錯了，為什麼整張報價單要重來?

因為這些選擇是有方向、環環相扣的:上游一改，下游一整串就得跟著重配。 這是人工報價最貴、卻最看不見的成本。

舉個具體的來回。業務照需求選了一台核心交換器，往下把光模組、堆疊線、授權、電源都配齊，湊出一張看起來完整的報價單送給原廠確認。結果原廠回一句:「這台核心不吃你選的那款光模組。」——這時候不是換一個品項就好，而是以那台核心為起點、往下配出去的一整串，都要重新盤一次:光模組換了，可能連帶影響上聯介面;上聯變了，可能又牽動堆疊方式。

上游一個選擇動，底下一整串跟著動。人工做這件事，靠的是記憶力和經驗:記得哪台配哪個、哪兩個湊在一起會出事。可是型號一多，這份「記憶」就開始漏——不是誰不夠細心，是這些選擇的組合量，本來就超過一顆腦袋能穩定記住的範圍。

相容性:那張「配了才能知道」的隱形清單

選一台設備，牽動的從來不是一個品項，是一整排「配了才能知道下單條件」的相依配件。 任一項不相容，整張單就作廢。這張清單多半不寫在需求裡，卻決定報價單成不成立:

這些欄位彼此還會互相約束:光模組要同時對得上「交換器支援的規格」和「上聯那條線的介面」。所以「相容性」不是一個檢查項，是一張會互相牽動的網——這正是組合數往上翻的主要來源。

折扣與即時價是動態的，人工查到的只是「某一刻的快照」。 前面兩面牆(型號、相容)是空間上的爆炸;
價格這一面，是再疊上時間。

一張中型報價，人工湊起來往往不是一次完成:要來回跟原廠查證料號、確認相容、等報價回覆。等到整張單湊齊，最早查的那幾項，價格或折扣條件可能已經變了。於是你手上這張「完整的報價單」，其實是由好幾個不同時間點的快照拼起來的——看起來完整，實際上未必還算數。

空間上的組合已經夠大，再乘上「價格會過期」這層時間壓力，人工這條線就更追不上了。

不過最常見的情況其實是會直接請Presales去跟客戶對資訊。

把型號、相容、價格相乘，人力的天花板到底在哪?

把三個維度相乘，你要跑完的不是幾十個選擇，是成百上千種合法組合。 用一組示意的數字算一次就看得出來——光是「核心交換器」這一個品項群:

5 種候選核心 × 每種吃 3 種光模組 × (PoE / 非 PoE) × (3 年 / 5 年授權) × (堆疊 / 不堆疊)
= 5 × 3 × 2 × 2 × 2 = 120 種合法組合(示意值)

而這才一個品項群。再把無線、上聯、電源、保固各自的選項乘進去，數字是相乘往上翻、不是相加往上疊——D3、D4 講的組合爆炸，在這裡具體到你能一個一個數:每多疊一個維度，合法組合就再翻一倍。

最要命的是，這張組合表還會自己變:原廠隨時可能把某個型號 EOL(End of Life，終止銷售/支援)，你昨天還能報的組合，今天送單就被打回——連「這個型號現在到底還能不能下單」本身，都是動態的。這片組合的複雜度大到連原廠自己都未必全盤掌握，人工要穩定追上，幾乎不可能。

所以這張報價單，本來就沒有人能穩定「湊」得完?

把三面牆疊起來，答案很誠實:在自動化之前，「快速湊出一張又正確又即時的原廠報價單」，多數時候沒有人能穩定做完。 硬扛(一項一項慢慢查、量一大就漏配)、降精度(只報幾套「常用組合」、失去逐案配到剛好的彈性)——這兩條都補不平;於是這一行最後幾乎都走上第三條路:靠老手。

把料號、相容規則、哪兩個湊在一起會出事，全記在少數幾個資深 PreSales 的腦子裡——平常這是最有效率的解，卻也是最脆的一條:他一忙、一請假、哪天離職，整條報價線就跟著卡住。這在工程上有個名字叫 bus factor = 1——整套運作的存亡，綁在一個人身上。這不是誰失職，是被規模逼出來、又最沒有安全感的一種妥協。

這正是「向原廠下單系統」要切進來的位置:它不嫌組合多、不會記漏一條相容規則、也不在乎價格幾點更新過——把「型號 × 相容 × 即時價」這張攤開來會嚇到人的組合表，穩定地查完、驗到可下單。它接手的，是一件人怎麼選都會留下缺口的事;不是取代業務，是把業務從「湊料號」裡放出來。

總結一下

• 報價的難點是「相乘」不是「相加」:型號 × 相容 × 折扣/即時價，三個維度相乘就是組合爆炸，不是品項變多而已。
• 選錯上游、下游全倒:設備選型是一連串環環相扣的選擇，上游一改、下游一整串跟著重配——這是人工最貴的隱形成本。
• 相容性是「配了才能用」的隱形網:光模組、授權、堆疊線、電源……任一不相容整張單作廢，而且欄位彼此互相約束，這是組合爆炸的主要來源。
• 價格會過期:折扣與即時價是動態的，人工查到的是快照，湊完一張單可能就不準了——空間爆炸再疊上時間變動。
• 這一行最後多半「靠老手」撐,也就是 bus factor = 1:料號與相容規則綁在一兩個資深 PreSales 腦裡，他一請假整條報價線就卡——硬扛、降精度也都補不平。這不是失職，是被規模逼出來、又最脆的妥協;業務空出來要做什麼，留白給人自己。

「幫我報一份 50 人辦公室的網路」——這不是一件事，是一連串環環相扣的選擇:型號要選對、配件要相容、價格要即時。三個維度相乘，就是一面人工穩定不了的規模牆。

牆量得再清楚，重點還是怎麼翻過去。明天 D26，我把「用向量檢索從 16 萬組型號裡撈出相關候選 + 用 CCW GraphQL introspection 讓 AI 自己問出原廠 schema」實際做出來——看這面「人湊不完」的組合爆炸，怎麼被一段會自己去問原廠、自己去爬相容的流程翻過去。