AI竞品分析工具的稳定落地远比想象中艰难。从数据采集对齐、审查反馈结构化到系统级评测体系建设，作者通过数百次测试迭代揭示了自动化分析背后的技术深坑与产品哲学。本文将带你穿透VLM识别、多Agent协同等前沿技术，直击AI产品从能跑到稳跑的关键突破点。

根据之前对【AI 竞品分析】的复盘，我已经把AI 竞品分析基础版做出来了。

复盘文章链接：https://www.woshipm.com/ai/6375644.html

AI 竞品分析基础版：

但是，能跑通是一回事，能“稳定地”跑通完全是另一回事。为了提高稳定性，为了让它生成报告和审查能“一次过审”，我这几天简直是经历了非人的折磨，跑了数百次，不断地测试新问题，不断地去校正。

本篇文章就把这个山路十八弯的过程和所有的细节，分享出来。

一、先说一下AI 竞品分析自动化流程

第一阶段：触发与采集

1. 用户输入： 用户在前端输入目标竞品的“名称”及“URL 链接”。
2. 页面快照抓取： 系统接收指令后，调度自动化无头浏览器打开该 URL，并完成网页的全局截图。
3. 前端源码抓取： 在同一个浏览器实例中，系统同步提取该 URL 页面下的所有原始 HTML 文本数据。

第二阶段：数据预处理

1. 图片压缩：对抓取到的网页原始截图进行自适应压缩。
2. 文本降噪清洗： 对抓取到的网页原始文本进行代码清洗，剔除 HTML 标签、脚本等无效代码，仅保留核心的业务与内容信息。

第三阶段：AI 生成与审查闭环

1）物料统一输入： 将压缩后“网页截图”与“清洗后的文本”打包，统一喂给生成器（生成 AI），大模型支持VLM识别，由其输出《竞品分析报告》。

2）自动审查与打回： 报告生成后，流转至审查器（审查 AI）进行校验：

• 校验通过： 结束流转，准备输出。
• 校验不通过： 审查器输出具体的“审查失败原因/修改建议”。系统将此反馈连同原始文章再次打回给生成器，强制重新生成。

第四阶段：兜底与输出

重试机制与最终输出：系统在生成与审查之间循环迭代，直至审查器判定通过。

兜底策略： 若循环重试达到 3 次仍未通过审查，系统将强制熔断，输出当前版本的分析报告，并明确打上“低置信度”的标签标识，向用户提示该结果存在风险。

二、细节里全是“坑”

为了让这条分析链路可以尽快稳定的产出质量过关的竞品分析报告，进行了小批量测试后，竟然查出了一堆设计上的低级问题。

1. 统一“证据包”，解决上下游信息不对齐。

排查连续三次“低置信度”报告后，我发现了一个严重的底层漏洞：生成 AI 和审查 AI 看到的上下文根本不一致。生成器看的是“压缩截图 + 清洗文本”，而审查器看的是“截图提取的纯文本 + 清洗文本”。

起初为了省成本，想将截图转成文字供上下游复用。但这完全违背了截图的初衷——纯文本直接丢失了页面的设计、交互和排版布局等关键视觉信息，导致大模型其实是个“半盲”。

解法：抽象出全局唯一的“证据包”（原始截图+压缩截图+原始文本+清洗文本）作为标准底座，要求生成、审查以及后期复盘全链路必须共用同一套数据，彻底消除信息差。

2. 使用JSON结构化传递审查反馈，消除模糊。

起初，审查AI找出问题后，为了把修改意见传给生成AI，我直接把审查反馈追加写到了报告的 Markdown 文档里，连同初版报告一起打回。

但这导致了一个极其“坑爹”的漏洞——信息的模糊传递与压缩。经过 5~6 次实测我发现，这种把反馈混在长文本里的做法，每次大概只能把真实意图传递过去 70%~80%。既然反馈本身都被“模糊化”了，生成 AI 拿去重新修改时，自然也是隔靴搔痒，改不到位。

解法：我果断放弃了把反馈“写进文档”的粗暴做法，改用 JSON 结构化的方式，把被打回的“真实原因”、“修改建议”精准且独立地传递回去。在多智能体（Agent）的交互链路中，用结构化替代自然语言传递指令，真的太重要了！

3. 数字档案袋解决报告与截图“串台”问题。

老报告和新截图居然会“串台”。比如正文明明是针对“飞书”产品的第3次竞品分析生成的，里面引用的却变成了第10次最新抓取的截图。归根结底，是因为系统在存储思路上比较松散，没有给正文和图片建立严密的映射绑定关系。

解法： 引入“专属档案袋”的机制。现在每一次生成报告，系统都会自动为它配建一个独立的档案袋，在这个档案袋里明确锁定三个维度的信息：报告属于谁（竞品名称）、这是哪一次的版本（版本号+时间戳）、以及这份报告对应的具体截图存放在哪个确切的路径。通过这种在底层把图文映射关系彻底“写死”的方式，实现了物理级别的强绑定，再也没有出现过张冠李戴的奇怪Bug。

4. 被 50 次连败教做人，设计反复重连机制

前面我觉得业务逻辑改得差不多了，就信心满满地一口气跑了 50 次测试想看看效果。结果直接被打脸——50 次只成功了6次，其他44次全部报错！

赶紧去排查日志，发现真不是我代码写得烂，而是频繁调外部大模型的时候，网络稍微一波动，或者路由器抽个风，它就直接给你断连了。

解法：之前是遇到连接失败直接判死刑，现在改成允许重试3次。断掉之后先过1秒重连一次，如果再断就过 2 秒再连，最后再等 4 秒连一次。只有当这 3 次梯次重连全部失败后，系统才最终向外抛出失败结果，加上这个“减震器”后，几乎再没出现过类似的问题。

三、确定评测指标体系与产品底线

把前面的暗坑全填平后，我一度以为自己已经“神功大成”，准备直接跑大批量测试。但马上心里就没底了：跑完之后，我怎么客观评价它到底是好是坏？稳定到了什么程度？

回想之前那 50 次连败，还好满屏都是同一个网络报错，我才能迅速定位。如果当时报的错千奇百怪，我又没有数据统计，那绝对两眼一抹黑，根本不知道从哪下手排查。

这时候我才惊醒，必须立刻建立一套系统的评测指标。作为产品，这事儿其实在项目初期写 PRD 时就该想清楚的。好在现在亡羊补牢，为时不晚！

3.1 搭建“双层架构”的系统级评测指标体系

第一层：线上真实任务监控层（看总盘子与追根溯源）

这意味着用户每跑一次真实的业务分析，不管最后是成是败，工作流结束时系统都会自动记一笔账。而且这条记录绝不是粗暴地只记“成功/失败”，它包含了能精准定位问题的核心字段：

• 基础信息：开始/结束时间、耗时、最终状态、置信度高低。
• 死在哪一步：明确标出是截图环节、抓文本环节、页面判断环节，还是生成或审核环节挂了。
• 死因分类：是遇到不该分析的无效页？还是采集失败？或者大模型接口抽风？
• 置信度低的病根：到底是事实出错了?还是结构不完整?或者是质量太差？

这套数据落盘时，我设计了一张JSON明细表和一张JSON汇总表。这带来的直接好处就是：我既能一眼看清系统总体的健康度，也能随时回头去查某一次任务到底“死”在了哪一步。

第二层：固定测试集回归层（拿固定题库验证真稳定）

光有线上监控不够，我得主动出击去验证稳定性。为此我专门写了一个批量跑测试的脚本，把一组固定样本写死在系统里，让它自己一轮一轮地跑回归测试。

这个测试“题库”不是乱选的，我提前定义好了标准答案：

• 正样本： 产品首页、功能页、定价页等。期望结果：顺利生成高置信度报告。
• 负样本： 登录页、404 页、不相关网页。期望结果：精准识别类型并果断拦截。

这套批量测试跑完，我只盯四个核心硬指标：正样本成功率、正样本高置信度率、负样本拦截率、负样本误放行率。

有了这双层数据体系兜底，我就不再是凭着直觉拍胸脯说“感觉系统很稳”了，而是拿着连续的真实运行数据和严谨的回归测试结果来说话。

3.2 确立产品底线：为后续接入 RAG 知识库“死守标准”

设计一个产品，不能只盯着眼前的这一步，还得给未来的扩展性留足空间。我接下来的大动作，是打算做一个 AI 竞品分析问答知识库。到那个时候，用户连报告都不用看了，直接对着系统提问，AI 就能把关注的答案精准地找出来。

但在奔向这个目标之前，我面临一个极其纠结的决策，脑子里打了好几架：那些“低置信度”的报告，到底要不要放进 RAG 知识库？

不写进去吧，怕用户提问时查不到，觉得系统“没内容”；写进去吧，我自己都心虚——万一 AI 拿着这些残缺甚至有误的信息信誓旦旦地误导用户，该怎么办？

最后，我拍板了：阻止它进知识库！宁可牺牲“全”——也就是用户明明分析了竞品，却可能问不到对应的某些问题，也要保证系统是“可信”的。绝对不愿意把这种不确定的信息给到用户，造成决策上的损失，这个责任谁也承担不起。因为对于一个 AI 产品来说，一次事实错误，信任就崩塌了。

为此，我把“置信度”分了三个层次来判断：

第一层：能不能信？（事实性审查） 这是根基，主要查内容跟证据有没有出入，能不能信。

第二层：全不全？（完整性审查） 该有的章节有没有？关键维度漏没漏？证据不足的是不是明确标了“待核实”？

第三层：质量高不高？（质量审查） 是不是太空太泛像宣传稿？是不是照搬内容？有没有针对性的价值分析？结构好不好读？

我现在的要求是：至少要满足前两个（事实没问题+该有的结构全），才算高置信度，才能放行进库。质量那块，虽然我也加了要求，但现阶段为了保核心的可信度，暂时没把它作为拦路的硬指标。

四、关关难过关关过

接下来继续测试，继续出现问题…

4.1 迭代“生成AI”的提示词

我开始拿具体的 Bad Case 来一点点扣提示词。然后发现了一堆共性问题：

• 强行续写：比如原文证据里只有 A 功能，AI 会自作聪明地把 A 功能拆成 A1、A2、A3，然后根据它自己理解的上位功能强行续写一波。
• 生搬硬套：竞品分析模板有点像“八股文”，有些明明没有的信息，AI 为了凑字数和结构，强行捏造出来，这又是个典型的幻觉。
• 给自己“加戏”：我之前在开头设定了“你是一个有经验的产品经理”，结果它写东西的时候动不动就着重强调产品判断，给自己疯狂加戏。
• 翻译损耗：很多功能原本是英文的，AI 偷懒把它改写成中文了。虽然意思没大变，但功能的原始说法被破坏了。所以我强调必须尽可能引用原句。

除了依据Bad Case狂改提示词，我还发现一个现象：英文版的提示词好像比中文版的执行得更精准一点。于是我一咬牙，把提示词全改成了英文！跑了十轮小规模数据测试，发现稳定性大概提升了 10% 左右。蚊子再小也是肉啊！

4.2 抓取顺序与检查顺序的盲区

1、前端渲染的“时差坑”

这个坑藏得极深：最初系统截图去请求了一次 URL，抓取文本时又单独请求了一次。虽然请求的是同一个地址，但现在一些网站都是前端异步请求 JSON数据后再进行动态渲染的。这就导致了一个致命的时间差——如果抓文本的那次请求页面还没渲染完，抓回来的就是一个毫无价值的“空壳子代码”。

解法：强制先等待页面完全加载并完成截图，随后立刻在当前状态下提取文本。

2、审查器先入为主的“半盲误判”

在测试中出了个极其诡异的问题：有些报告明明写得很好（比如评价竞品“交互顺滑，页面布局合理”），却被审查器无情打回，直接判定为生成器在胡编乱造。

深挖日志后我发现，这纯粹是大模型在“偷懒”。对于大模型来说，文字是“亲儿子”，图片是“干儿子”，又因为注意力机制更倾向于在就近的文本中寻找答案。审查器在纯文本里没搜到“交互”、“布局”这些纯视觉属性的字眼，当场就急着下结论判负了，它根本就没有往后去看哪怕一眼截图！

解法：强制要求它必须完整对照完文本和截图双端证据之后，才能下最后结论。

4.3 绕了超级坑：被AI 写的“正则”误杀正常页面

为了卡住输入质量、省下不必要的大模型 Token 成本，我在系统最前面加了一道“门卫”。我的初衷是：如果抓回来的页面结构稀烂、文本极短，或者明显是个 404、登录拦截页，就直接阻断，别往后跑了。

但我直接掉进了一个巨坑！测试时发现，很多正常的竞品首页居然被频频拦截。排查日志一看，失败原因竟然是：页面右上角有一个“点击登录”的按钮。

我跑去扒底层的判断代码，这才发现纯纯是被 AI 写代码给坑了！ 当时我让 AI 助手帮忙写这段拦截逻辑时，它直接“偷懒”，给我写了一套最死板的“正则匹配”——只要文本里命中了“登录”、“验证”这些关键词，就执行一刀切拦截。它根本就没有用到 AI 去做视觉和语义的综合判断！

解法：放弃“正则”，用AI打败AI。截图和文本清洗完成后，先专门把图和文喂给一个专属的前置裁判 AI。让它像真人一样，通过 VLM 视觉去判断：“这是正常业务页面，还是登录验证注册这种无意义的页面？”虽然这样做每次会增加一点成本，但这是为了省下后续更多的无效 Token 成本，以及保证竞品报告质量。

五、大批量测：真刀真枪见分晓

解决了前面几个底层的基础设施坑后，我又觉得我行了。依托刚建好的评测体系，我拿出精心准备好的测试集，10 个一组直接连跑了 3 组（共 30 次）。结果跑下来，数据统计帮我揪出了一批深藏不露的共性问题。

跑测的最终分布如下：

• 稳如老狗的 5 个： 飞书首页、Notion 首页、Notion AI、Stripe 文档、Shopify 博客。
• 稳定失败/被拦的 5 个： Slack 价格、Notion 登录、Slack 登录、飞书 404、百度首页。

5.1 学会放手：Slack 价格页为何全军覆没？

排查 Slack 价格页的日志时，我发现抓到的根本不是真实内容，而是一个“浏览器不支持”的拦截页。这是因为对方网站防爬虫，精准识别并拦截了我们的自动化无头浏览器环境。

我试着用 Playwright 换了自带的浏览器引擎去硬刚，结果还是不行。

结论：果断放手，绝不死磕。 我做的是竞品分析工具，不是专业突破反爬的黑客软件。只要确认系统的“异常阻断逻辑”能正常识别出这种残缺页面，并将其成功拦截、不往下游浪费生成 Token，这就够了。我换了个样本，直接放过了它。

价格页正常访问页面：

5.2 首页与文档页的“第一版诅咒”

在跑测中，Notion 首页和 Stripe 文档经常出现一个折磨人的小毛病：第一稿报告总是不通过，非得被打回重写第二稿才行。

仔细一琢磨，是因为这两类页面走向了两个极端：

• 官方首页： 信息太庞杂、太泛，导致模型非常容易“嗨”，一不小心就脑补写过头。
• 官方文档： 信息太偏、太窄，很难满足竞品分析模板里要求的“结构完整度”。

解法：两手抓。 对首页强力压制脑补，老老实实有什么写什么；对文档页则坦然接受缺失，缺了就写缺了，不再强求所谓的“结构完整”。

5.3 提示词里的“左右互搏”与三大最终解法

顺着上面的问题深挖，我发现我在写提示词时，埋下了一个巨大的逻辑冲突：我既要求大模型“绝对不准脑补”，又要求它“把报告写得完整、漂亮”。这根本就是让马儿跑又不给马儿吃草，逻辑完全互斥了。

更坑的是，之前审查器的提示词非常死板。报告里一旦出现“待核实”这三个字，审查器就觉得“你没输出完整报告”，直接给判负。这就带来了一个极其糟糕的后果：倒逼生成模型为了过审，强行把“待核实”改写成了“确认”，极大地增加了幻觉！ 其实站在客观角度，面对网上的残缺信息，“待核实”这三个字才是最准确、最负责任的结论。必须排好优先级：“禁止脑补”的铁律，永远凌驾于“写得完整”之上。 为此，我打出了三大最终解法：

• 解法一：消除被逼出来的幻觉。 立刻修改审查提示词，赋予 AI 承认“不知道”和“缺失”的合法权利。
• 解法二：完整性标准“客观化”。 废除审查器觉得“写得不够丰满就打回”的主观判断，改成清单式的死标准：“有证据就写，没证据就明确承认缺失”。只要不瞎编说明白了，就不再打回。
• 解法三：终结“价格幻觉”。 价格太重要了绝不能瞎编！我把逻辑从“让模型自由写”改成了“先单独抽取价格证据，再按证据固定输出”。审查器也改了，只认这份独立的价格证据。

为了彻底管住大模型，我还总结了一套极其强硬的 8 条提示词军规：

1. 未确认价格一律禁止写成确定事实。
2. 视觉观察必须显式打标签。
3. 缺失信息必须显式落字（承认没有）。
4. 总结区禁止升级表述事实。
5. 禁止补全“看起来合理”的商业信息。
6. 对“文档页式材料”强制允许不完整。
7. 输出前增加一轮自检清单对照。
8. 把高频错误写成明确的禁句。

加上这几板斧跑了 20 轮，后端产出终于算是稳如泰山了！

六、交付与隐患：把“后端的稳”变成“前端的爽”

6.1 隐患备忘录：为 RAG 知识库留下的技术债

虽然整个流水线跑通了，后端也算稳如老狗，但为了接下来真正落地 RAG 知识库，我还欠着两笔必须得还的“后端债”：

• 内存存储的脆弱性： 现在运行数据全存在内存的 JSON 里，服务器一重启，正在跑的任务直接灰飞烟灭。现阶段自己跑测试还能凑合，后续绝对不行。
• 玩具级的向量检索： 目前只是用“本地 FAISS + JSON”自己硬拼了一个向量数据库环境，纯属单机版的过渡方案，扛不住什么并发。下一步做大知识库，底层存储基建必须重构。

6.2 前端体验重塑：让用户真正感知到“稳”

后端的逻辑再严密，如果前端还是老样子，用户根本感知不到系统有多牛。为了把底层的“稳”具象化，我顺手把前端彻底翻新了一遍，做了四大改造：

1. 报告渲染大升级： 告别了以前粗糙的纯文本展示。现在的输出变成了“审查摘要 + 报告目录 + 截图 + 正文”的立体结构，同时深度优化了 Markdown 样式，让列表、层级和代码块终于不再乱版了。

2. 完成页改造： 以前只扔给用户一个干巴巴的“高/低置信度”。现在，我把后端的页面判断、页面类型、审查结果、知识库状态，全翻译成大白话亮在台面上，让用户一眼看懂这次分析的成色。

3. 失败页“说人话”： 以前系统报错，抛出来的都是一堆天书般的内部代码。现在改成了结构化说明，直接告诉用户失败类型（如：404 错页、访问受限、被登录页拦截、空白页），并给出“建议更换页面”的提示，极大降低了用户的挫败感。

4. 数据大屏“秀肌肉”： 我干脆把后端的统计接口接到了前端，单独做了一个“稳定性监控面板”。总任务数、成功/失败数、高/低置信度、平均耗时、失败原因、最近运行记录全部可视化。这不仅是给自己排雷用的，更是系统稳定性的最强力证！