AI 竞品分析项目复盘：因过度追求产品化与需求膨胀导致失败

事件概述

一位开发者在尝试构建 AI 竞品分析工具时遭遇失败。该项目初衷是利用 AI 自动化生成结构化竞品报告，但在实施过程中，因过度追求“完整 SaaS 产品”的功能完整性，导致需求膨胀和技术债爆发，最终在核心逻辑仅消耗少量资金的情况下，因边缘功能（如账号系统、Bug 修复）消耗了数倍的时间和金钱成本而被迫终止。

核心信息与技术链路

1. 初始设计：高效闭环

项目初期采用多节点处理流程，旨在以最低成本实现高质量输出：

• 信息抓取：分离执行网页全局截图与 HTML/文本提取脚本。
• 多模态识别：利用视觉语言模型（VLM Agent）将截图转化为文本描述。
• 数据清洗：通过 Clean Agent 去除 HTML 冗余代码，保留纯净文本。
• 报告生成：结合压缩后的图片与清洗文本，由 Generator Agent 输出结构化报告。
• 审查兜底：引入 Review Agent 进行交叉验证，防止 AI 幻觉，若三次重试不达标则标记“置信度较低”。

成本控制策略：

• 图片压缩：减少 Token 消耗。
• 模型路由：关键任务调用高能力高价模型，机械清洗任务分配给廉价小模型。
• 结构化输出：强制 JSON 格式输出，便于下游精准核对字段。

2. 转折点：RAG 引入与需求膨胀

为提升交互效率，开发者决定引入检索增强生成（RAG）支持问答功能：

• 向量化存储：报告切片存入向量数据库（800 字/块，10% 重合度）。
• 检索逻辑：前端提问时召回相关片段并由大模型总结回答。

问题爆发点：

• 意图识别难题：需处理无关问题拦截、库中无数据等边界情况，工程量巨大。
• 伪需求拖累：为上线 SaaS 版本，强行加入账号登录注册、多租户数据隔离及 Token 计费系统。

3. 失败原因与数据对比

• 技术栈重构陷阱：从快速原型框架 Gradio 转向 Next.js+React 重构，导致边缘功能 Bug 修复陷入泥潭。
• 成本倒挂：
  • 核心逻辑：实际 API 调用成本仅约 50 元。
  • 边缘功能：账号、账单、Bug 修复等非核心需求消耗 150 元（3 倍资金）及 3 天时间。
• 背离初衷：过度追求产品化功能牺牲了 AI 工具本应具备的效率优势。

复盘与建议

1. 聚焦基线需求

对于个人或小团队提效工具，仅需实现以下两点即可解决 80% 业务痛点：

• 初次基建：抓取网站原始信息，生成高质量的基线竞品分析报告。
• 定期追踪：定期执行抓取，结合历史资料输出“对比分析”（明确新功能增加或文案修改）。

2. 警惕过早优化

• 暂缓非核心功能：RAG 问答、复杂的多账户系统属于“锦上添花”，在验证核心价值前应暂缓开发。
• 避免过度工程化：不要为了追求“完整产品形态”而牺牲开发效率和核心功能的稳定性。