本文来自微信公众号： 人人都是产品经理 ，作者：玉泽，原文标题：《做 AI 竞品分析失败了：一次被 Bug 和需求膨胀拖垮的尝试》
狂砸了200多块钱的Claude API调用费，结果最终还是失败了。非常心痛，于是写下这篇文章。总要有点收获，不能钱砸进去之后，什么都没剩下。
最初的设想与技术链路
刚开始我对AI竞品分析的设想非常简单：输入一个目标链接，系统自动分析页面内容，并按照固定的Prompt输出一篇结构化的竞品分析报告。
为了实现这个闭环，我设计了一条包含多节点的处理链路：
1）信息抓取（爬虫脚本）：拆分为两个独立的脚本执行。一个专门负责对网页进行全局截图；另一个负责把网页里的HTML源码和全量文本提取出来。
2）多模态识别（VLM Agent）：引入视觉模型，对第一步抓取到的网页截图进行识别，将图片中的视觉信息转化为文本描述。
3）数据清洗（Clean Agent）：负责处理乱序文本，将HTML源码里无用的标签和乱七八糟的冗余代码全部清洗掉，只保留干净的纯文本数据。
4）报告生成（Generator Agent）：将压缩后的截图与清洗后的纯文本，一并交给负责撰写分析报告的Agent进行归纳输出。
5）审查与兜底（Review Agent）：这是解决“AI幻觉”和信任问题的核心机制。报告写完后，由审查Agent将生成的文字与原始图片及内容进行交叉验证，核实内容是否基于事实。如果不合格直接打回重写，设置重试上限为3次。如果3次后仍不达标，则在最终报告上明确标记“置信度较低”。
为了控制成本（省Token）和提升效果，我在链路中应用了明确的工程策略：
1）图片压缩：截图直接丢给模型非常消耗Token，必须在前端先进行压缩处理。
2）模型路由（大模型分发）：不同任务调用不同能力的大模型。多模态识别、报告生成和最终审查，调用能力强、价格高的模型以保证质量；而数据清洗这种机械工作，则分配给便宜的“小模型”处理。
3）结构化输出控制（Prompt Engineering）：为了保证不同Agent之间数据传递的稳定性，我放弃了让模型输出自然语言长文，而是通过Few-Shot（少样本提示）和明确的Prompt约束，强制“报告生成Agent”以严格的JSON格式（如包含核心功能、定价、目标客群等字段）输出。这使得下游的“审查Agent”能够进行字段级的精准核对，而不是在长篇大论中迷失。
增加复杂度的转向：引入RAG
后来我觉得，如果作为日常使用的工具，每次都要盯着长篇幅的分析文档看，效率太低。最符合直觉的交互应该是“问答”——等系统分析完，我直接就我关心的细节提问。
于是，我决定在产品里引入RAG（检索增强生成）：
向量化存储：竞品分析报告生成后，直接转化为向量（Embedding），存入向量数据库中。这里的切片策略定为800字一切块，保留10%的重合度，以保证上下文的语义关联性。
检索与问答：前端提问时，系统将当前问题与历史对话作为上下文一并发给向量数据库，按相关性优先级排序召回片段，最后由大模型总结并回答。单纯这一步的开发成本其实并不高。
噩梦的开始：陷入伪需求与Bug丛林
但正是由于加入了问答机制和想要“产品化”的冲动，各种不顺利接踵而至，场景复杂度直线上升。
1）逻辑漏洞与边界情况
问答功能极度依赖意图识别。
如果我问了与竞品无关的问题，系统需要专门的逻辑去拦截处理；
如果我问的是数据库里还没有抓取过的竞品，Agent也得准确识别并返回“库中暂无该数据”。
想把这些边界情况处理得足够智能化，工程量非常大。
2）需求膨胀与业务系统
我想把它做成一个完整的SaaS产品部署上线给朋友们用，就必须做账号登录注册、多租户的数据隔离。
不同的账户登录，看到的报告和问答记录必须完全独立。
此外，还得做一套Token消费的账单计费系统。
3）被边缘功能拖垮
结果是，系统淹没在了Bug里。
最开始，我用Gradio（一个专门做Python Demo的框架）搭MVP的核心逻辑，一天不到就跑通了。
但后来为了优化UI界面、做成真正的产品，我把前端重构成了Next.js+React，接着开始加账号、账单、数据隔离这些外围系统。
为了修这些边缘业务的Bug，我花了整整三天，且依然报错不断。
这已经彻底背离了我最初“用AI节省时间成本”的初衷。
反思与总结
最终我选择果断放弃。
开发AI核心业务逻辑连50块钱都没花到，但修周边系统的Bug却消耗了三倍以上的金钱和精力，关键是还没修好。
虽然心痛，但也算交了学费。
如果让我重新操盘这个项目，我会摒弃掉所有花哨的技术堆砌，完全从实用主义和成本角度出发。
如果是个人或小团队的提效工具，其实只需要做透两件事：
初次基建：抓取网站原始信息，生成一篇高质量的基线竞品分析报告。
定期追踪：定期（如每周/每月）执行抓取，结合原始资料和上一次的报告，专注输出“对比分析”（明确指出了增加了什么新功能、修改了什么核心文案）。
这就足够解决业务痛点了。
至于RAG问答、复杂的多账户系统，在项目早期根本不是核心需求，纯粹是锦上添花的负担。