推文

@kafkaup · 2026-10-15 03:08

AI 产品和传统产品在竞品分析上的区别 传统产品的竞品分析，更多是在看它“有什么”。但 AI 产品的竞品分析必须再往下一层，去分析这个产品“在什么条件下能做到什么”，以及这件事情的成本是怎样的。传统产品里的功能矩阵、用户流程、定价、交互、渠道、商业模式等维度当然还要看，但放到 AI 产品里明显不够用了。 AI 产品有几个非常特殊的地方： 1. 功能存在不等于能力成立 比如两个产品的官网都会写支持“合同审查”或“自动生成分析报告”，表面上看功能一模一样，但实际可能完全不是同一个东西。必须拿真的一批 case 去跑，才能知道它的实际准确性、面对复杂输入会不会崩溃、上下文表现如何、工具调用的成功率，以及最后需要人工修改的比例大概是多少。 所以 eval 本身就是 AI 产品竞品分析的一部分。甚至最好自己做一个小型的 eval set，用同一批输入、同一套标准，尽量控制变量，再去对比各自的质量、延迟、成本和稳定性。一个产品效果极佳，但单次任务要跑 5 分钟且成本极高；另一个产品效果可能低 3%，但 20 秒就能完成：这两者完全是不同的产品逻辑。 2. 功能边界不再是静态的 传统的 SaaS 今天有没有某项功能通常相对稳定。但 AI 产品的表现如何，可能和模型、prompt、RAG、tool、推理预算，甚至是第三方模型的更新都直接相关。 因此竞品分析不能只记录“A 产品支持智能检索，B 产品不支持”，必须向下深挖一步： • A 的智能检索是靠什么实现的？ • 在什么 query 下表现更好，什么时候会失败？ • 这个能力究竟构成了它的产品护城河，还是只要换个更好的模型其他产品就能轻易补齐？ 这一点至关重要。现在很多 AI 产品的 feature 很容易被抄袭，真正值得分析的是其效果背后的来源：究竟是来自模型本身、专有数据、workflow、领域知识、eval 体系，还是工程交付能力？这会把传统的功能分析推向“能力来源分析”。 3. 必须单独评测时间和成本 AI 产品的成本和延迟已经不再单纯是后台工程问题，它会反过来直接决定产品设计（相关的逻辑我之前在文章里也提到过）。一个 agent 一次任务调用 20 次模型还是 3 次模型，前端用户或许无法直接感知，但底层的商业模式截然不同。 因此，把单次任务时长、需要交互的轮次、人工介入的次数、是否经常需要重跑、调用工具的复杂度，以及最终用户是否愿意为节省的这部分时间付费，统统纳入竞品分析的范畴。 在面对 To B 产品时，最大的痛点是很多数据既测不到也拿不到。对此不能强求把所有维度都量化，可以把结论分为三档：未知的、可以推断的、已经明确的。 To B 产品真正值得分析的远不止终端效果，它至少包含三层： • 第一层：产品能力。它解决什么任务，workflow 怎么设计，agent 介入哪一步，人又在哪一步接管。 • 第二层：工程与企业级能力。包括数据权限、能否对接企业内部系统、是否有审计与 trace、是否支持人工复核与权限隔离等。 • 第三层：交付与商业能力。具体卖给谁、销售周期多长、是否需要大量定制实施、是否有标准化交付能力，以及客户案例集中在哪些行业。 To B AI 产品真正的竞争力往往藏在第三层。在模型能力拉不开绝对差距的情况下，A 产品可能两周就能嵌入客户系统并跑通，而 B 公司却需要驻场三个月，这就是巨大的商业壁垒。 总结来说，我们可以围绕场景、能力、eval、成本、延迟、工程、数据安全、交付和商业模式这几个维度来做综合评测。其中能实测的部分去做 benchmark，测不到的 To B 能力则去建立证据等级。 AI 产品竞品分析最重要的转变，是去判断某个能力是否能够“稳定地、经济地”进入真实业务场景。这或许就是它与传统产品分析最大的分水岭。

曝光 110 · 评论 1 · 点赞 0 · 书签 0