做 AI 競品分析失敗了：一次被 Bug 和需求膨脹拖垮的嘗試

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

———— / BEGIN / ————

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

最初的設(shè)想與技術(shù)鏈路

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

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

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

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

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

4）報(bào)告生成（Generator Agent）： 將壓縮后的截圖與清洗后的純文本，一并交給負(fù)責(zé)撰寫分析報(bào)告的 Agent 進(jìn)行歸納輸出。

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

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

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

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

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

增加復(fù)雜度的轉(zhuǎn)向：引入 RAG

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

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

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

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

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

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

1）邏輯漏洞與邊界情況

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

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

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

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

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

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

不同的賬戶登錄，看到的報(bào)告和問答記錄必須完全獨(dú)立。

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

3）被邊緣功能拖垮

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

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

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

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

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

反思與總結(jié)

最終我選擇果斷放棄。

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

雖然心痛，但也算交了學(xué)費(fèi)。

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

如果是個(gè)人或小團(tuán)隊(duì)的提效工具，其實(shí)只需要做透兩件事：

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

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

這就足夠解決業(yè)務(wù)痛點(diǎn)了。

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

本文來自作者：玉澤