AI竞品分析工具的稳定落地远比想象中艰难。从数据采集对齐、审查反馈结构化到系统级评测体系建设，作者通过数百次测试迭代揭示了自动化分析背后的技术深坑与产品哲学。本文将带你穿透VLM识别、多Agent协同等前沿技术，直击AI产品从能跑到稳跑的关键突破点。
根据之前对【AI 竞品分析】的复盘，我已经把AI 竞品分析基础版做出来了。
复盘文章链接：https://www.woshipm.com/ai/6375644.html
AI 竞品分析基础版：
但是，能跑通是一回事，能“稳定地”跑通完全是另一回事。为了提高稳定性，为了让它生成报告和审查能“一次过审”，我这几天简直是经历了非人的折磨，跑了数百次，不断地测试新问题，不断地去校正。
本篇文章就把这个山路十八弯的过程和所有的细节，分享出来。
第一阶段：触发与采集
第二阶段：数据预处理
第三阶段：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 时就该想清楚的。好在现在亡羊补牢，为时不晚！
第一层：线上真实任务监控层（看总盘子与追根溯源）
这意味着用户每跑一次真实的业务分析，不管最后是成是败，工作流结束时系统都会自动记一笔账。而且这条记录绝不是粗暴地只记“成功/失败”，它包含了能精准定位问题的核心字段：
这套数据落盘时，我设计了一张JSON明细表和一张JSON汇总表。这带来的直接好处就是：我既能一眼看清系统总体的健康度，也能随时回头去查某一次任务到底“死”在了哪一步。
第二层：固定测试集回归层（拿固定题库验证真稳定）
光有线上监控不够，我得主动出击去验证稳定性。为此我专门写了一个批量跑测试的脚本，把一组固定样本写死在系统里，让它自己一轮一轮地跑回归测试。
这个测试“题库”不是乱选的，我提前定义好了标准答案：
这套批量测试跑完，我只盯四个核心硬指标：正样本成功率、正样本高置信度率、负样本拦截率、负样本误放行率。
有了这双层数据体系兜底，我就不再是凭着直觉拍胸脯说“感觉系统很稳”了，而是拿着连续的真实运行数据和严谨的回归测试结果来说话。
设计一个产品，不能只盯着眼前的这一步，还得给未来的扩展性留足空间。我接下来的大动作，是打算做一个 AI 竞品分析问答知识库。到那个时候，用户连报告都不用看了，直接对着系统提问，AI 就能把关注的答案精准地找出来。
但在奔向这个目标之前，我面临一个极其纠结的决策，脑子里打了好几架：那些“低置信度”的报告，到底要不要放进 RAG 知识库？
不写进去吧，怕用户提问时查不到，觉得系统“没内容”；写进去吧，我自己都心虚——万一 AI 拿着这些残缺甚至有误的信息信誓旦旦地误导用户，该怎么办？
最后，我拍板了：阻止它进知识库！宁可牺牲“全”——也就是用户明明分析了竞品，却可能问不到对应的某些问题，也要保证系统是“可信”的。绝对不愿意把这种不确定的信息给到用户，造成决策上的损失，这个责任谁也承担不起。因为对于一个 AI 产品来说，一次事实错误，信任就崩塌了。
为此，我把“置信度”分了三个层次来判断：
第一层：能不能信？（事实性审查） 这是根基，主要查内容跟证据有没有出入，能不能信。
第二层：全不全？（完整性审查） 该有的章节有没有？关键维度漏没漏？证据不足的是不是明确标了“待核实”？
第三层：质量高不高？（质量审查） 是不是太空太泛像宣传稿？是不是照搬内容？有没有针对性的价值分析？结构好不好读？
我现在的要求是：至少要满足前两个（事实没问题+该有的结构全），才算高置信度，才能放行进库。质量那块，虽然我也加了要求，但现阶段为了保核心的可信度，暂时没把它作为拦路的硬指标。
接下来继续测试，继续出现问题…
我开始拿具体的 Bad Case 来一点点扣提示词。然后发现了一堆共性问题：
除了依据Bad Case狂改提示词，我还发现一个现象：英文版的提示词好像比中文版的执行得更精准一点。于是我一咬牙，把提示词全改成了英文！跑了十轮小规模数据测试，发现稳定性大概提升了 10% 左右。蚊子再小也是肉啊！
1、前端渲染的“时差坑”
这个坑藏得极深：最初系统截图去请求了一次 URL，抓取文本时又单独请求了一次。虽然请求的是同一个地址，但现在一些网站都是前端异步请求 JSON数据后再进行动态渲染的。这就导致了一个致命的时间差——如果抓文本的那次请求页面还没渲染完，抓回来的就是一个毫无价值的“空壳子代码”。
解法：强制先等待页面完全加载并完成截图，随后立刻在当前状态下提取文本。
2、审查器先入为主的“半盲误判”
在测试中出了个极其诡异的问题：有些报告明明写得很好（比如评价竞品“交互顺滑，页面布局合理”），却被审查器无情打回，直接判定为生成器在胡编乱造。
深挖日志后我发现，这纯粹是大模型在“偷懒”。对于大模型来说，文字是“亲儿子”，图片是“干儿子”，又因为注意力机制更倾向于在就近的文本中寻找答案。审查器在纯文本里没搜到“交互”、“布局”这些纯视觉属性的字眼，当场就急着下结论判负了，它根本就没有往后去看哪怕一眼截图！
解法：强制要求它必须完整对照完文本和截图双端证据之后，才能下最后结论。
为了卡住输入质量、省下不必要的大模型 Token 成本，我在系统最前面加了一道“门卫”。我的初衷是：如果抓回来的页面结构稀烂、文本极短，或者明显是个 404、登录拦截页，就直接阻断，别往后跑了。
但我直接掉进了一个巨坑！测试时发现，很多正常的竞品首页居然被频频拦截。排查日志一看，失败原因竟然是：页面右上角有一个“点击登录”的按钮。
我跑去扒底层的判断代码，这才发现纯纯是被 AI 写代码给坑了！ 当时我让 AI 助手帮忙写这段拦截逻辑时，它直接“偷懒”，给我写了一套最死板的“正则匹配”——只要文本里命中了“登录”、“验证”这些关键词，就执行一刀切拦截。它根本就没有用到 AI 去做视觉和语义的综合判断！
解法：放弃“正则”，用AI打败AI。截图和文本清洗完成后，先专门把图和文喂给一个专属的前置裁判 AI。让它像真人一样，通过 VLM 视觉去判断：“这是正常业务页面，还是登录验证注册这种无意义的页面？”虽然这样做每次会增加一点成本，但这是为了省下后续更多的无效 Token 成本，以及保证竞品报告质量。
解决了前面几个底层的基础设施坑后，我又觉得我行了。依托刚建好的评测体系，我拿出精心准备好的测试集，10 个一组直接连跑了 3 组（共 30 次）。结果跑下来，数据统计帮我揪出了一批深藏不露的共性问题。
跑测的最终分布如下：
排查 Slack 价格页的日志时，我发现抓到的根本不是真实内容，而是一个“浏览器不支持”的拦截页。这是因为对方网站防爬虫，精准识别并拦截了我们的自动化无头浏览器环境。
我试着用 Playwright 换了自带的浏览器引擎去硬刚，结果还是不行。
结论：果断放手，绝不死磕。 我做的是竞品分析工具，不是专业突破反爬的黑客软件。只要确认系统的“异常阻断逻辑”能正常识别出这种残缺页面，并将其成功拦截、不往下游浪费生成 Token，这就够了。我换了个样本，直接放过了它。
价格页正常访问页面：
在跑测中，Notion 首页和 Stripe 文档经常出现一个折磨人的小毛病：第一稿报告总是不通过，非得被打回重写第二稿才行。
仔细一琢磨，是因为这两类页面走向了两个极端：
解法：两手抓。 对首页强力压制脑补，老老实实有什么写什么；对文档页则坦然接受缺失，缺了就写缺了，不再强求所谓的“结构完整”。
顺着上面的问题深挖，我发现我在写提示词时，埋下了一个巨大的逻辑冲突：我既要求大模型“绝对不准脑补”，又要求它“把报告写得完整、漂亮”。这根本就是让马儿跑又不给马儿吃草，逻辑完全互斥了。
更坑的是，之前审查器的提示词非常死板。报告里一旦出现“待核实”这三个字，审查器就觉得“你没输出完整报告”，直接给判负。这就带来了一个极其糟糕的后果：倒逼生成模型为了过审，强行把“待核实”改写成了“确认”，极大地增加了幻觉！ 其实站在客观角度，面对网上的残缺信息，“待核实”这三个字才是最准确、最负责任的结论。必须排好优先级：“禁止脑补”的铁律，永远凌驾于“写得完整”之上。 为此，我打出了三大最终解法：
为了彻底管住大模型，我还总结了一套极其强硬的 8 条提示词军规：
加上这几板斧跑了 20 轮，后端产出终于算是稳如泰山了！
虽然整个流水线跑通了，后端也算稳如老狗，但为了接下来真正落地 RAG 知识库，我还欠着两笔必须得还的“后端债”：
后端的逻辑再严密，如果前端还是老样子，用户根本感知不到系统有多牛。为了把底层的“稳”具象化，我顺手把前端彻底翻新了一遍，做了四大改造：
1. 报告渲染大升级： 告别了以前粗糙的纯文本展示。现在的输出变成了“审查摘要 + 报告目录 + 截图 + 正文”的立体结构，同时深度优化了 Markdown 样式，让列表、层级和代码块终于不再乱版了。
2. 完成页改造： 以前只扔给用户一个干巴巴的“高/低置信度”。现在，我把后端的页面判断、页面类型、审查结果、知识库状态，全翻译成大白话亮在台面上，让用户一眼看懂这次分析的成色。
3. 失败页“说人话”： 以前系统报错，抛出来的都是一堆天书般的内部代码。现在改成了结构化说明，直接告诉用户失败类型（如：404 错页、访问受限、被登录页拦截、空白页），并给出“建议更换页面”的提示，极大降低了用户的挫败感。
4. 数据大屏“秀肌肉”： 我干脆把后端的统计接口接到了前端，单独做了一个“稳定性监控面板”。总任务数、成功/失败数、高/低置信度、平均耗时、失败原因、最近运行记录全部可视化。这不仅是给自己排雷用的，更是系统稳定性的最强力证！
本文由 @巅魂 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。