比完几家商拍工具，那张表没告诉我们要不要自己做

做 Smart Photo 前后，我比过一轮商拍工具：PhotoRoom、Pixelcut 这类海外的，美图设计室、稿定这类国内的，还有阿里、亚马逊平台自带的 AI 商拍。截图有了，功能逐项对过了，上传、生成、导出的流程也画出来了。表做得挺满，勾完还是那个问题：它为什么这样做，我们要不要跟。

我不觉得截图没有价值，做界面和交互分析时它就是证据。让我不满足的是，材料停在了描述上：别人有什么，我们没有什么。到了 AI 产品，这种落差更明显。两个产品都支持生成商品图，背后的准备、约束、检查和修改，可能完全不一样。

这篇把我对竞品分析的思路重新捋一遍。保留直接竞品、间接竞品、市场技术功能体验这些基本维度，也补上模型参与之后值得看的部分。目的不是替竞品猜一个很厉害的技术架构，是让分析能影响手上的产品决定。

我可能把谁算漏了

直接竞品仍然值得认真看。目标用户相近、任务相近的产品，输入、付费意愿、使用条件和自己更接近，差异也更有参考意义。“有 AI 抠图”这一个勾，装不下差别：是用户主动选一张图，还是系统到处提示生成？结果能不能局部采用？原图会不会被覆盖？我想比较的是用户完成任务多了什么便利，又增加了什么操作，不是比谁的页面上出现更多 AI 按钮。

间接竞品，是用户已经在用的另一条路。对一个 AI 工具，用户坚持用 Photoshop 或者找外包不一定是落后，很可能是那里已经有模板、协作和交付习惯，新工具只解决了中间一小步。我会把这些替代方式列出来，甚至包括表格、人工服务、找同事帮忙。

潜在变化先当成问题看。跨界的产品和新的模型能力值得留意，但我不想把每个新发布都当成“行业要被颠覆”。GitHub、Hugging Face 上的开源项目能帮助发现能力变化，Star 数和榜单只是线索。真正要追问的是，这项能力降低了哪一段实现成本，让谁可能用一种新办法完成同一件事。留下少数可能改变任务路径的方向，持续看就够了。

四个维度，看实一点

技术，哪些能观察，哪些只能推测。技术文档、官方说明和公开报告可以提供依据。没有披露的部分，我会明确写不知道，不凭一次输出就认定对方用了哪家模型。可观察的指标倒可以认真记：第一次出现反馈用了多久，完整结果什么时候到，在哪类输入上失败。最好保留输入、版本、时间和设置，相同任务多试几次。

商业，价格看得到，成本往往看不全。订阅、按量、限制次数、积分消耗都能观察。用户买到的到底是什么，也值得拆开：一次生成、一个成功任务，还是一段时间内有限额度的使用权？我会特别看重试怎样收费。一个结果要生成多次才可用，标价很低也未必省钱。要测算自己的方案，可以根据公开价格、预计输入输出、失败重试做区间估算，那是一份有假设的测算，不是竞品真实毛利。

功能，沿着一项任务比较。功能表可以保留，但除了有无，我会多记三列：适用条件、完成质量、用户还要补什么。给分也需要说明标准，没有共同标准的零到五分，可能只是把感觉伪装成精确数字。人的介入尤其值得看：生成后可以局部修改，还是每次重来？这比只看首轮效果，更能看出产品是否适合重复使用。

体验，正常结果和出错都要看。模型能力进入产品以后，界面往往承担着解释状态、核对内容、让人接手的工作。一个简单按钮可以封装复杂提示词，但按钮旁边应该让人知道会改哪些内容，原稿是否保留；失败了能否重新尝试，还是只能看见一句“请稍后再试”。

一张不只打勾的表

拿 AI 商品图工具举例。假设要用同一张商品原图、同样的场景要求出图，我会尽量固定输入，再比较两款产品。第一轮先不为了迁就某个产品去补不同的提示，否则很难看出默认路径的差异；之后再记录各自优化后的效果。

其中一款首轮效果更好，但用户改一个背景，它把商品也重新生成了；另一款画面稍平，却能锁定商品不动。这时不能只给一个总分说前者更强，要看目标用户更常遇到哪种任务。

我也会保留相同任务里的反例。第一次表现差，调整输入后变好，可以说明引导存在问题；多次都在同一类商品上出错，可能说明当前能力有稳定缺口。分析到这里，才有机会提出“需要改输入方式”或“需要补校验”，而不是泛泛地建议接更强的模型。

报告可以分三层写：亲眼观察到的行为，据此作出的解释，准备验证的方案。“修改背景后商品也变化”是观察，“产品可能没有保留局部编辑状态”是解释，“我们的编辑应支持锁定商品”是待评估方案。这几层不分开，讨论很容易把推测当作竞品事实，随后又把竞品事实当成自己的需求。

最后还得回到资源条件。竞品做了一套完整编辑器，不等于我们当前也需要。能不能先支持一个最常用的修改动作，投入是否合适，这才是分析对自己有用的地方。

给谁用，写法不一样

负责人、研发、运营关心的事情有交集，也有差别。我更愿意留一份共同的事实底稿，再分别展开。

给负责人看，可以用 SWOT 帮忙整理，但每一项要有具体依据。“竞品用 API，我们自建就能赢”这种判断太快，自建也要付硬件、运维、模型更新和质量维护的成本。比较后发现先用 API 更适合当前阶段，也完全正常。和研发讨论，把任务输入、失败输出、已查到的技术信息放在一起。和运营讨论，看新用户第一轮怎么开始、示例怎样组织、失败时如何解释。

真正动手时

先问这次分析要解决什么。新产品立项和一个功能的迭代，需要的材料不同。我会先写一句问题，比如“用户是否需要在生成过程中锁定商品”，然后检查后面的每一项观察能否帮助回答它。

选少数可比较的对象。一个行业标杆、几个直接对手，再加一条不同形态的替代路径，比铺二十个名字更容易深入。版本、套餐、地区和设备条件也要记下来。

使用同一批任务，保留过程。正常任务、信息不完整、需要修改等情况都测。一组输入最好重复几次，一次失败值得记录，一次成功也不代表以后都会成功。截图、录屏、原始输入输出放在一起，结论才方便复核。

AI 可以帮我做的，是持续收集变化、整理公开反馈、准备测试用例、提出可试的提示方案。这些环节会省下一部分整理时间，但都不是零成本，来源是否完整、摘要是否准确，仍然要检查。看到竞品某种输出组织得好，让模型提议几种提示写法，是在帮助构造一个可能的实现，不是在还原竞品秘密。

报告最后要回答的一句话

做完之后，我想能说清楚：这次分析，让我对手上的哪个决定改变了看法。

可能是发现不需要增加一个功能，先把已有结果的修改做好；也可能是确认一个新的能力值得做小实验。若还不能下结论，就把证据不足写下来，说明下一步要看什么。

那几家的截图和功能表依然可以留下。只是我希望它们后面有一段自己的判断，而不只是把别人的产品又描述了一遍。