AI競品分析工具的探索之旅充滿技術與成本的雙重挑戰(zhàn)。從多模態(tài)識別到RAG增強生成，開發(fā)者投入200多元卻最終折戟于復雜的產(chǎn)品化陷阱。本文將深度復盤這場失敗的實驗，揭示從簡潔技術棧到臃腫業(yè)務系統(tǒng)的致命轉折，為AI產(chǎn)品落地提供血淚教訓。

———— / BEGIN / ————

狂砸了 200 多塊錢的 Claude API 調(diào)用費，結果最終還是失敗了。非常心痛，于是寫下這篇文章。總要有點收獲，不能錢砸進去之后，什么都沒剩下。

最初的設想與技術鏈路

剛開始我對 AI 競品分析的設想非常簡單：輸入一個目標鏈接，系統(tǒng)自動分析頁面內(nèi)容，并按照固定的 Prompt 輸出一篇結構化的競品分析報告。

為了實現(xiàn)這個閉環(huán)，我設計了一條包含多節(jié)點的處理鏈路：

1）信息抓取（爬蟲腳本）： 拆分為兩個獨立的腳本執(zhí)行。一個專門負責對網(wǎng)頁進行全局截圖；另一個負責把網(wǎng)頁里的 HTML 源碼和全量文本提取出來。

2）多模態(tài)識別（VLM Agent）： 引入視覺模型，對第一步抓取到的網(wǎng)頁截圖進行識別，將圖片中的視覺信息轉化為文本描述。

3）數(shù)據(jù)清洗（Clean Agent）： 負責處理亂序文本，將 HTML 源碼里無用的標簽和亂七八糟的冗余代碼全部清洗掉，只保留干凈的純文本數(shù)據(jù)。

4）報告生成（Generator Agent）： 將壓縮后的截圖與清洗后的純文本，一并交給負責撰寫分析報告的 Agent 進行歸納輸出。

5）審查與兜底（Review Agent）： 這是解決“AI 幻覺”和信任問題的核心機制。報告寫完后，由審查 Agent 將生成的文字與原始圖片及內(nèi)容進行交叉驗證，核實內(nèi)容是否基于事實。如果不合格直接打回重寫，設置重試上限為 3 次。如果 3 次后仍不達標，則在最終報告上明確標記“置信度較低”。

為了控制成本（省 Token）和提升效果，我在鏈路中應用了明確的工程策略：

1）圖片壓縮：截圖直接丟給模型非常消耗 Token，必須在前端先進行壓縮處理。

2）模型路由（大模型分發(fā)）：不同任務調(diào)用不同能力的大模型。多模態(tài)識別、報告生成和最終審查，調(diào)用能力強、價格高的模型以保證質量；而數(shù)據(jù)清洗這種機械工作，則分配給便宜的“小模型”處理。

3）結構化輸出控制（Prompt Engineering）：為了保證不同 Agent 之間數(shù)據(jù)傳遞的穩(wěn)定性，我放棄了讓模型輸出自然語言長文，而是通過 Few-Shot（少樣本提示）和明確的 Prompt 約束，強制“報告生成 Agent”以嚴格的 JSON 格式（如包含核心功能、定價、目標客群等字段）輸出。這使得下游的“審查 Agent”能夠進行字段級的精準核對，而不是在長篇大論中迷失。

增加復雜度的轉向：引入 RAG

后來我覺得，如果作為日常使用的工具，每次都要盯著長篇幅的分析文檔看，效率太低。最符合直覺的交互應該是“問答”——等系統(tǒng)分析完，我直接就我關心的細節(jié)提問。

于是，我決定在產(chǎn)品里引入 RAG（檢索增強生成）：

• 向量化存儲： 競品分析報告生成后，直接轉化為向量（Embedding），存入向量數(shù)據(jù)庫中。這里的切片策略定為 800 字一切塊，保留 10% 的重合度，以保證上下文的語義關聯(lián)性。

• 檢索與問答： 前端提問時，系統(tǒng)將當前問題與歷史對話作為上下文一并發(fā)給向量數(shù)據(jù)庫，按相關性優(yōu)先級排序召回片段，最后由大模型總結并回答。單純這一步的開發(fā)成本其實并不高。

噩夢的開始：陷入偽需求與 Bug 叢林

但正是由于加入了問答機制和想要“產(chǎn)品化”的沖動，各種不順利接踵而至，場景復雜度直線上升。

1）邏輯漏洞與邊界情況

問答功能極度依賴意圖識別。

如果我問了與競品無關的問題，系統(tǒng)需要專門的邏輯去攔截處理；

如果我問的是數(shù)據(jù)庫里還沒有抓取過的競品，Agent 也得準確識別并返回“庫中暫無該數(shù)據(jù)”。

想把這些邊界情況處理得足夠智能化，工程量非常大。

2）需求膨脹與業(yè)務系統(tǒng)

我想把它做成一個完整的 SaaS 產(chǎn)品部署上線給朋友們用，就必須做賬號登錄注冊、多租戶的數(shù)據(jù)隔離。

不同的賬戶登錄，看到的報告和問答記錄必須完全獨立。

此外，還得做一套 Token 消費的賬單計費系統(tǒng)。

3）被邊緣功能拖垮

結果是，系統(tǒng)淹沒在了 Bug 里。

最開始，我用 Gradio（一個專門做 Python Demo 的框架）搭 MVP 的核心邏輯，一天不到就跑通了。

但后來為了優(yōu)化 UI 界面、做成真正的產(chǎn)品，我把前端重構成了 Next.js + React，接著開始加賬號、賬單、數(shù)據(jù)隔離這些外圍系統(tǒng)。

為了修這些邊緣業(yè)務的 Bug，我花了整整三天，且依然報錯不斷。

這已經(jīng)徹底背離了我最初“用 AI 節(jié)省時間成本”的初衷。

反思與總結

最終我選擇果斷放棄。

開發(fā) AI 核心業(yè)務邏輯連 50 塊錢都沒花到，但修周邊系統(tǒng)的 Bug 卻消耗了三倍以上的金錢和精力，關鍵是還沒修好。

雖然心痛，但也算交了學費。

如果讓我重新操盤這個項目，我會摒棄掉所有花哨的技術堆砌，完全從實用主義和成本角度出發(fā)。

如果是個人或小團隊的提效工具，其實只需要做透兩件事：

1. 初次基建：抓取網(wǎng)站原始信息，生成一篇高質量的基線競品分析報告。

2. 定期追蹤：定期（如每周/每月）執(zhí)行抓取，結合原始資料和上一次的報告，專注輸出“對比分析”（明確指出了增加了什么新功能、修改了什么核心文案）。

這就足夠解決業(yè)務痛點了。

至于 RAG 問答、復雜的多賬戶系統(tǒng)，在項目早期根本不是核心需求，純粹是錦上添花的負擔。

本文來自作者：玉澤