竞品分析，本应帮助我们理解市场，却正在成为越来越多团队停止独立思考的起点。而到了 AI 时代，这种依赖不仅没有减弱，反而可能因为“获得答案”变得过于容易，而进一步放大。

最近，我负责了一个中资跨国企业官网重塑项目。整个项目持续了三周，在此期间，我重新梳理了网站整体的信息架构（Information Architecture），完成了 User Center、Design Center 两个核心模块的诊断与重构，并围绕导航体系、内容组织、用户访问路径以及业务承载能力进行了全面分析。

这是一个典型的大型企业官网项目。产品线复杂，业务覆盖多个国家和地区，同时涉及销售、市场、产品、研发、解决方案等多个团队。正式进入设计之前，我们进行了多轮沟通，希望先充分理解业务，再讨论设计方案。

真正让我印象深刻的，并不是项目本身的复杂程度，而是整个设计讨论过程中一种反复出现的工作方式。几乎每讨论一个功能、一个页面，甚至一个交互细节，都会有人提出同样的问题：“有没有竞品可以参考？”

讨论导航结构，需要找竞品；讨论用户中心，需要找竞品；讨论解决方案中心，需要找竞品。甚至在业务目标尚未完全明确的时候，也有人建议：“先看看同行是怎么做的。”

整个沟通过程中，我听到最多的一句话就是：“这一部分，我们参考的是 XX 竞品的 XX 模块。”有时参考的是导航结构，有时参考的是会员中心，有时参考的是解决方案页面，甚至细化到某一个卡片样式、某一段交互流程，或者某一个功能入口。

渐渐地，我开始意识到，团队讨论的重点已经不是“这个方案是否适合我们的业务”，而是“这个方案有没有竞品作为支撑”。竞品不再只是用来验证方案的外部信息，而逐渐变成了设计决策能够成立的依据。

项目进行到一半时，我突然意识到一件让我不安的事情：如果今天所有竞品都不存在，这个项目还能继续推进吗？

如果答案是否定的，那么真正值得警惕的就已经不是“参考了太多竞品”，而是组织正在逐渐失去独立分析问题和建立产品判断的能力。对于一家拥有复杂业务体系的跨国大型企业来说，这远比一次页面设计失误更加危险。

因为竞品能够告诉你别人昨天做了什么，却无法告诉你，你的产品明天应该走向哪里。

而在 AI 时代，这个问题正在变得更加值得警惕。

过去，一个团队要模仿竞品，至少还需要经历搜索、整理、分析、画原型和开发验证的过程。今天，把一个竞品页面截图交给 AI，几分钟就可以得到页面结构分析；把几个网站地址交给大模型，可以迅速生成竞品矩阵；描述一个类似的产品功能，AI 可以直接生成 Wireframe、UI 甚至可运行的前端代码。

我们获得“答案”的速度越来越快了。

但问题在于：如果一开始问错了问题，AI 只会帮助我们更快地把错误的答案做出来。

竞品分析，本来不是为了告诉我们应该怎么做

我并不反对竞品分析。事实上，在任何成熟的产品设计流程中，竞品分析都是非常重要的一环。

它帮助团队快速了解市场现状，理解行业已经形成的认知模式，学习成熟产品经过验证的实践经验，同时避免重复踩坑。优秀的竞品分析能够帮助我们回答很多重要问题：这个行业已经有哪些成熟方案？用户已经形成了哪些使用习惯？哪些设计是真正经过长期验证的最佳实践？哪些功能又只是某一个业务阶段和商业环境下形成的历史产物？

这些信息都具有重要价值。

但我们必须清楚一点：竞品分析的价值，在于帮助我们理解别人为什么这样设计，而不是告诉我们也应该这样设计。

前者是在研究问题，后者是在复制答案。

真正成熟的设计流程，应该先理解自己的业务、用户、组织能力和现实约束，再研究其他企业如何解决类似问题。竞品应该成为验证、比较和校准设计假设的工具，而不是产品方向本身。

遗憾的是，很多团队正在不知不觉完成一种角色倒置：竞品分析从 Research 的组成部分，逐渐演变成了 Decision Making 的替代品。

这也是为什么一些竞品研究看起来异常完整：几十页 PPT、功能矩阵、页面截图、流程对照、优缺点分析一应俱全，但最终你仍然回答不了一个最基础的问题——所以，我们为什么要这样设计？

如果这个问题没有答案，那么再完整的竞品报告，也只是一份资料汇编。

我们真正依赖的，不是竞品，而是确定性

很多人会把这种现象归因于设计师能力不足。我并不完全认同。至少在大型企业里，竞品依赖首先是一个组织决策问题，其次才是设计能力问题。

产品设计本身就是一项充满不确定性的工作。新的导航结构是否更加符合用户认知？重新规划的信息架构是否真的可以降低寻找成本？新的任务流程能否提升业务效率？新的入口是否会影响另外一类用户？很多问题在设计阶段不可能拥有百分之百确定的答案。

而引用竞品，可以快速制造一种确定性。

“Apple 是这样做的。”

“Salesforce 也有这个功能。”

“竞争对手已经上线了类似模块。”

“这套 Dashboard 是参考行业头部产品设计的。”

这些说法能够迅速降低决策成本。一个原本需要通过业务逻辑、用户证据和设计推导来证明的方案，现在只需要一个足够知名的案例，就好像拥有了某种天然的正确性。

对于大型组织而言，这种做法尤其具有吸引力。大型企业部门多、利益相关者多、决策链条长，任何创新方案都意味着解释成本和责任风险。相比之下，“行业领先企业也是这么做的”是一种极其低成本的组织语言。

所以我们真正依赖的，很多时候并不是竞品，而是竞品带来的决策安全感。

问题是，安全感并不等于正确性。

更严重的是，当组织越来越习惯借助竞品完成决策，团队就会越来越少讨论“我们的用户到底是谁”“用户为什么需要这个功能”“这个业务问题究竟发生在哪里”，而越来越多讨论“别人有没有”“别人放在哪里”“别人怎么做”。

产品设计由此发生了一个很隐蔽的变化：团队不再从问题寻找答案，而开始从答案反推问题。

AI 正在进一步降低“停止思考”的成本

AI 给产品设计带来的最大变化之一，是大幅降低了生产成本。但同样需要警惕的是，它也大幅降低了“不经过充分思考就开始生产”的成本。

以前，一个产品经理提出“我们也需要一个 Dashboard”，设计团队至少还需要经过需求梳理、信息整理、原型设计和开发评估。这个过程本身会制造一些必要的阻力，迫使团队不断回答：Dashboard 里到底放什么？谁会用？什么信息最重要？

今天，可以直接把几个竞品截图交给 AI，然后要求：“结合这三个竞品，帮我设计一个更好的 Dashboard。”

几分钟以后，一个看起来相当完整的方案就出现了。

问题在于，完整并不意味着正确。

AI 特别擅长生成“像一个成熟产品应该拥有的东西”。它知道 SaaS Dashboard 通常有什么，知道 Enterprise User Center 长什么样，知道常见导航结构、卡片布局、搜索、筛选、Quick Actions 应该放在哪里。通过大量已有模式，它能够快速生成一个形式上相当合理的平均答案。

但 UX 设计最困难的问题，从来不是“一个 Dashboard 通常应该有什么”，而是：这个用户今天来到这里，最需要解决的任务究竟是什么？

如果这个问题没有被充分研究，那么 AI 生成的越完整，团队反而越容易提前进入 Solution Space，并误以为问题已经得到解决。

这是一种新的 UX 风险：Solution First。

过去，设计师可能因为看了太多 Dribbble 或 Behance 而过早进入视觉方案；今天，我们可能因为 AI 太容易生成产品方案，而在真正理解 Problem Space 之前，就已经拥有一个能够运行的 Prototype。

速度提升了，但判断并没有同步提升。

真正危险的，不是页面越来越像，而是产品开始失去自己的逻辑

很多人认为，过度参考竞品最大的风险，是产品越来越同质化。我认为这只是最终呈现出来的表象。真正危险的是，产品开始逐渐失去属于自己的设计逻辑。

任何成熟产品，都不是一组页面的简单组合，而是一套围绕用户目标构建的系统。信息架构、导航体系、页面层级、功能关系、业务规则和交互方式，需要共同服务于一套连续的产品逻辑，而这套逻辑最终的目的，是帮助用户以符合自身认知的方式完成任务。

这也是 User Journey（用户旅程）和 Task Flow（任务路径）存在的根本价值。

设计导航，并不是为了让栏目显得完整；设计页面，并不是为了让界面更加丰富；设计信息架构，也不是单纯为了把已有内容重新分类。这些工作的本质，是建立用户对系统的理解，让用户能够判断“我现在在哪里”“这里可以做什么”“下一步应该去哪里”，并逐渐形成稳定的 Mental Model（心理模型）。

一个用户进入企业官网，可能是为了寻找产品、比较解决方案、确认兼容性、下载技术文档、申请报价、管理订单或者获取技术支持。这些看似分散的动作，本质上都是任务。成熟的体验设计应该围绕这些任务建立连续关系，让信息、功能和服务共同构成可以理解、可以预测的路径。

但是，当竞品成为设计的基本单位时，User Journey 很容易失效。

导航参考 A，用户中心参考 B，解决方案中心参考 C，Design Center 参考 D，Dashboard 再参考 E。每一个模块单独拿出来都可能拥有足够优秀的行业案例，也能够通过 AI 快速总结出“这样设计的五个理由”。

但问题是，A、B、C、D、E 背后实际上是五套完全不同的商业模式、用户模型、产品体系和组织结构。

它们的信息架构服务于自己的产品矩阵，它们的任务路径服务于自己的用户，它们的账户体系映射自己的商业规则，甚至很多看似普通的栏目名称和页面层级，背后都可能存在多年形成的组织结构和运营方式。

这些设计本来是一个系统，却被我们当成了可以随意拆装的零件。

于是，一个很荒谬的情况出现了：每一个局部都有依据，整个产品却没有逻辑。

这种问题不会首先表现为视觉上的“不统一”，而会直接作用于 User Journey。一个原本连续的用户任务被拆到多个模块，用户需要不断切换认知模型；产品分类使用一套逻辑，解决方案使用另一套逻辑，账户中心又使用第三套逻辑。用户刚刚理解“这个网站是怎么工作的”，下一步又需要重新学习。

久而久之，用户就不再通过理解系统自主解决问题，而开始依赖搜索、客服、帮助中心、销售人员或者站内 AI 助手。

值得注意的是，AI 甚至可能把这里原本存在的 UX 问题暂时掩盖掉。

当越来越多企业在网站中加入 AI Search、Copilot 或 Conversational Assistant 时，一个很容易产生的误解是：既然 AI 可以帮助用户找到答案，信息架构是不是就没那么重要了？

恰恰相反。

如果底层产品结构本身是混乱的，AI 只是给一个混乱系统增加了新的访问入口。它可能帮助用户绕过糟糕的导航，却并没有修复糟糕的产品逻辑。

搜索能够弥补 Findability，却不能替代 Information Architecture；AI 可以帮助用户找到某个功能，却不能自动让整个产品形成一致的 Mental Model。

当用户必须依赖 AI 才能理解一个系统如何工作时，我们首先应该问的也许不是“AI 助手做得够不够聪明”，而是：为什么这个系统已经复杂到无法让用户自己理解？

所谓的“竞品安全感”，正在用局部正确换取整体失控

这种局面最讽刺的地方在于，团队往往反而会获得很强的安全感。

因为每一个局部方案都有出处：导航参考行业标杆，User Center 借鉴国际领先企业，解决方案页面采用成熟结构，AI Assistant 又参考当前最热门的产品。每一个局部都能够拿出截图、竞品分析甚至 AI 总结报告证明自己的合理性。

但这种安全感并不是来自用户体验已经得到验证，而是来自设计决策拥有了可以引用的案例。

这两者完全不同。

用户不会分别体验导航、User Center、Design Center 和 AI Assistant，他们体验的是一个完整系统。他们并不会因为四个模块分别来自四个领先产品，就认为体验更加先进。他们只会发现：为什么完成一件简单的事情，需要在多个系统之间跳转？为什么刚刚理解一种结构，进入下一个区域以后逻辑又发生了变化？为什么同一个产品里不同模块对于“项目”“方案”“订单”“服务”的定义都不完全一致？

过度依赖竞品真正的危险，不是产品越来越像别人，而是产品越来越不像自己。

最终，团队用竞品提供的局部“安全感”，换来的是整个用户体验系统被拆得支离破碎。

而 AI 的加入，会让这种拼接发生得更快。过去复制五套设计可能需要几个月；现在设计师可以借助 AI，在非常短的时间内完成结构提取、UI Remix、Prototype 甚至前端实现。

AI 没有制造这个问题，它只是取消了过去阻止这个问题快速发生的成本。

AI 时代真正成熟的设计，更应该从用户任务开始

这也是为什么我认为，AI 时代的 UX 设计反而应该更加重视 Problem Framing、User Journey 和 Task Model，而不是因为页面生成越来越容易就弱化这些工作。

过去，设计师的大量时间被消耗在 Wireframe、视觉细节、组件整理和原型制作上。现在这些环节正在快速被 AI 压缩。这本应是一件好事，因为设计师终于可以把更多时间重新投入到真正困难的问题上：理解用户、理解业务、发现矛盾、建立假设、设计验证方式以及做出判断。

如果 AI 帮我们节省了 70% 的执行时间，最错误的使用方式，就是把省下来的时间用于再生成 70% 的页面。

真正值得做的是，把这些时间重新投入到问题本身。

在复杂产品设计中，我们优先回答的，不应该是“这个页面应该长什么样”，而应该是“用户为什么来到这里”“他试图完成什么”“什么阻碍了任务”“系统需要理解哪些上下文”“哪些事情应该由用户决定，哪些事情未来可以交给 AI Agent 执行”。

尤其到了 AI 产品阶段，传统的 User Journey 本身也正在发生变化。

过去很多数字产品的 Task Flow 是相对确定的：用户点击 A，进入 B，填写 C，然后完成 D。但在 AI Agent、自然语言交互和 Context-aware Interface 中，用户完成任务的路径可能越来越动态。用户不一定需要知道功能在哪里，而是直接表达 Intent；系统可能根据权限、历史数据、上下文和模型推理完成多个步骤。

这意味着 UX 设计师需要理解的已经不仅是 Page Flow，还包括Intent、Context、System State、Agent Capability、Human Control 和 Feedback Loop。

如果这时候我们仍然只是问“竞品的 AI Assistant 放在哪个位置”“竞品聊天框长什么样”“竞品 Copilot 的按钮是什么颜色”，那么我们复制的依然只是下一代产品最表层的 UI。

真正需要研究的问题应该是：哪些任务适合交给 AI？什么时候 AI 应该主动？什么时候必须等待用户确认？用户如何理解 AI 做了什么？出现错误以后如何恢复？权限边界在哪里？AI 的答案依赖哪些企业数据？传统导航和 Conversational Interface 应该是什么关系？

这些问题几乎不可能通过简单参考某一个竞品得到答案，因为它们高度依赖企业自身的数据、业务规则、组织责任以及用户风险。

AI 产品越深入业务，UX 就越不能依赖表面竞品。

AI 可以成为研究工具，但不能成为判断的替代品

当然，AI 对竞品研究本身具有非常大的价值。

过去设计团队可能需要花一周时间浏览几十个网站、记录功能、截图和整理差异。今天完全可以利用 AI 完成第一轮信息抓取、聚类、模式识别甚至建立初步的 Feature Matrix，把大量机械劳动交给机器。

问题不在于是否使用 AI，而在于把 AI 放在什么位置。

我更愿意把 AI 看作一个Research Accelerator，而不是 Design Authority。

它可以帮助我们快速回答：“市场上有哪些做法？”“不同企业如何组织这类功能？”“有哪些重复出现的模式？”甚至可以主动帮助我们寻找反例。

但在此之后，设计团队仍然要重新回答：“这些模式为什么出现？”“它们背后的商业前提是什么？”“哪些条件与我们相同？”“哪些条件根本不存在？”“如果完全不采用这些方案，我们还有什么选择？”

尤其要警惕 AI 制造出来的“多数共识”。

如果十个竞品有八个采用 Dashboard，AI 很容易总结为“Dashboard 是行业最佳实践”。但八家公司都这样做，并不意味着你的用户也需要 Dashboard。它可能只说明，这个行业过去十年形成了一种相似的产品范式。

真正有价值的设计，有时恰恰来自于质疑这种范式。

因此，一个成熟的 AI 辅助竞品分析流程，不应该只是让 AI 帮我们寻找更多相似案例，还应该要求它寻找反例、失败案例、不同商业模式下的替代方案，以及那些“行业普遍这么做，但用户体验依然存在问题”的部分。

AI 最有价值的地方，不是帮助我们证明自己是对的，而是帮助我们更快发现自己可能错在哪里。

如果没有竞品，我们还会怎样设计？

这些年，我越来越喜欢在项目开始阶段问一个问题：如果今天市场上没有任何竞品，我们会如何解决这个问题？

这并不是鼓励为了创新而创新，更不是否定成熟经验，而是强迫团队暂时关闭 Solution Library，重新回到 Problem Space。

用户真正要完成什么任务？这个任务为什么困难？现有系统的问题究竟发生在哪里？哪些复杂度来自业务本身，哪些只是历史遗留？组织具备什么能力？哪些用户行为有真实数据和研究证据支持？如果从用户目标重新出发，最自然的任务路径应该是什么？

在 AI 时代，还应该再增加几个问题：如果 AI 能够替用户完成其中一部分任务，哪一部分真正值得自动化？自动化以后用户还需要知道什么？AI 出错时用户如何重新获得控制？我们是在用 AI 解决真实问题，还是仅仅因为竞品都有 AI，所以自己也需要一个 AI 功能？

完成这些问题之后，再去研究竞品，竞品分析才真正回到它应该处在的位置。

这时它不再是答案，而是证据；不再是模板，而是校验。AI 也不再是替我们快速复制页面的生产机器，而成为帮助我们扩大研究范围、挑战假设和加速验证的工具。

换句话说，竞品和 AI 都应该服务于判断，而不是替代判断。

AI 时代，设计真正创造价值的地方，是提出问题和建立判断

互联网发展到今天，绝大多数成熟场景已经存在大量优秀案例。随着生成式 AI、设计生成工具和 Design-to-Code 能力继续发展，任何一个设计师都可以越来越快地完成过去需要数天甚至数周才能完成的竞品研究、原型和界面生产。

“会不会做”正在迅速贬值。

真正稀缺的，正在变成“为什么这样做”。

设计师未来的竞争力，不会是知道更多案例，也不会是生成更多方案，而是面对复杂业务、复杂组织、复杂用户和越来越强大的 AI 能力时，仍然能够建立清晰的问题模型并做出判断。

什么问题值得解决？什么需求其实并不存在？哪些步骤应该被简化？哪些权力不应该交给 AI？哪些行业最佳实践只是历史惯性？哪些看似先进的设计其实不符合我们的用户？这些问题无法单纯通过生成更多页面得到答案。

设计也从来不是把市场上最优秀的产品拼接在一起。真正优秀的产品体验，不是不同竞品方案的平均值，更不是 AI 对行业现有模式做出的统计平均。

对于大型企业来说，这一点尤其重要。大型企业拥有更加复杂的产品组合、客户类型、业务流程、数据体系和组织结构。如果只是把不同竞品的局部最佳实践不断搬进来，再借助 AI 加快复制和实施速度，最终得到的很可能不是“集大成者”，而是一套越来越复杂、越来越难维护，也越来越难让用户理解的系统。

真正让我担心的，并不是企业参考了太多竞品，而是如果拿掉竞品，它是否还能够独立定义问题、建立假设并做出设计判断。

而 AI 出现以后，这个问题变得更加尖锐：如果 AI 也拿掉那些已有案例和行业范式，我们还知道自己为什么要这样设计吗？

当一家企业的设计决策必须依赖竞品才能成立时，真正值得担心的已经不是有没有竞品，而是组织是否还具备独立判断的能力。对于一家跨国大型企业来说，这远比一次设计失误更加危险。

因为 AI 和竞品都非常擅长告诉我们世界已经有什么。

但产品设计真正需要回答的问题始终是：

接下来，我们应该创造什么？

写在最后

写这篇文章，并不是为了反对竞品分析，也不是为了否定 AI 在产品设计中的价值。

恰恰相反，我认为 AI 会让竞品分析变得前所未有地高效，也会释放设计师大量过去被重复劳动占据的时间。但也正因为如此，我们更需要重新确认：究竟哪些工作应该交给 AI，哪些能力才真正属于设计师。

搜索案例、整理截图、生成竞品矩阵、总结模式、绘制 Wireframe、生成 UI，甚至实现 Prototype，这些工作的门槛都会继续降低。设计师真正需要承担的部分，则越来越集中在理解用户、定义问题、建立系统、判断取舍和验证结果上。

真正值得研究的，也不只是竞品的页面、功能和交互，而是它背后的商业逻辑、用户任务、组织能力、产品战略，以及为什么最终形成了今天这套设计。

优秀的设计师不会因为看过更多竞品而优秀，也不会因为掌握更多 AI 工具就自然拥有更好的设计能力。真正重要的是，能够使用竞品而不依赖竞品，使用 AI 而不把判断交给 AI；能够借鉴行业经验，同时仍然愿意回到自己的用户、业务和问题重新开始。

因为 AI 时代的产品设计，真正稀缺的已经不是答案。

答案正在变得前所未有地廉价。

真正昂贵的，是知道应该问什么问题，以及面对大量看似正确的答案时，依然知道为什么应该选择其中一个，或者一个都不选。

如果有一天所有竞品都消失了，我们是否还知道应该如何设计？

而当有一天 AI 可以帮我们生成所有竞品的“最优平均方案”时，我们又是否还有能力说：

这不是我们真正需要的答案。

这可能才是 AI 时代判断一个产品团队是否真正具备设计能力的最好问题。

大家好，我是麦柯 Michael

设计师 / 开发者 / 摄影师

长期在设计、AI与工程的交汇处工作

持续探索 Context Engineering 与 AI 辅助设计工作流

和我一起用Vibe Code构建属于自己的产品！