AI本该赢得人心

2026年6月，Pew Research Center发布了一份关于美国公众使用和看待AI的调查。里面有一组很难忽略的反差：49%的美国成年人表示使用过AI聊天机器人，高于2024年的33%；约四分之一的人已经每天使用。但在同一份调查中，63%的人认为AI发展得太快，40%预计AI会对社会产生负面影响，只有16%预计影响会是正面的。

如果只看前一组数据，AI的普及速度相当可观。把后一组数据放进来，问题就变了：AI正在被更多人使用，却没有因此获得更多人的认同。

TechCrunch记者Sarah Perez在《AI本该赢得人心，但它没有》中抓住的正是这层矛盾。文章没有否认AI的能力和增长，而是在追问：当AI已经进入搜索、办公、创作、客服和各种终端之后，为什么普通用户仍然觉得自己得到的好处不够明确，付出的代价却越来越具体？

文章提到的代价并不抽象。工作机会、个人信息、内容真实性、能源消耗，以及人与人之间的连接，都已经进入公众对AI的判断。Airbnb CEO Brian Chesky把问题说得更直接：行业需要做出普通人真正喜欢的产品。Anthropic CEO Dario Amodei则把它称为一场信任危机，并承认行业做出的大承诺还没有充分兑现。

我读完后更在意的，不是“公众开始讨厌AI”这个情绪结论，而是产品团队可能一直在用一套更容易获得的指标，替代用户真正的接受：覆盖了多少人、调用了多少次、默认开启了多少功能，却没有回答用户为什么愿意继续使用。

普及不等于接受。对产品经理来说，这个区别会改变五项基本判断：有没有真实需求，哪些步骤应该自动化，用户为什么不用，价值最终属于谁，以及信任怎样进入产品。

一、用户用上了，不等于产品找到了需求

AI产品最容易制造的一种误判，是把“用户碰到了AI”当成“用户需要AI”。

这种误判并不完全来自团队自我安慰，而是来自AI进入产品的方式。搜索结果自动出现AI摘要，办公软件在侧边栏增加助手，客服流程默认先经过机器人，企业统一采购账号并要求员工使用。它们都能迅速增加曝光、调用和活跃，却不一定包含用户的主动选择。

Pew的调查提供了一个很典型的例子：60%的美国成年人表示读过搜索结果顶部的AI摘要。但用户看到摘要，可能只是因为平台把它放在最上面。这能证明AI已经广泛进入信息获取流程，不能单独证明用户更愿意相信它，更不能证明用户希望它替代原来的搜索过程。

产品经理需要先把几个经常混在一起的状态拆开：

接触
：用户在产品里看到了AI能力；
尝试
：用户点击过一次，完成了首次体验；
使用
：用户在某些场景中调用了它，其中可能包含默认触发和组织要求；
接受
：即使可以选择原来的方式，用户仍然愿意继续使用；
授权
：用户愿意让AI参与更重要的判断和执行。

前面三个状态可以通过分发、运营和组织要求快速提高，后面两个才更接近产品是否真正成立。

ToC产品要防止“默认开启”污染需求判断

在消费产品里，AI功能经常被直接放进主链路。入口更显眼、原功能被折叠、结果默认生成，都会带来使用量增长。

这类数据当然有价值，它说明用户有机会体验产品。但要证明需求，还需要观察几个更严格的行为：

如果AI默认关闭，用户是否会主动开启；
如果原来的操作方式仍然存在，用户是否会继续选择AI；
第一次使用之后，用户是否会在下一次相似任务中主动回来；
AI生成的结果是否被采用，而不是看完后全部重做；
用户关闭功能后，是否还会重新开启。

这里最关键的不是给指标换一个名字，而是为用户保留真实选择。没有替代路径，就很难区分“用户选择了AI”和“用户只能经过AI”。

ToB产品要防止把采购完成当成一线接受

企业产品里的误判更加隐蔽。许可证数量、开通账号、部门渗透率和模型调用量，常常受到采购合同、管理要求和培训计划影响。

管理层决定引入一套AI系统，不等于一线员工认为它有用。员工每天登录，也可能只是因为流程规定必须登录；大量生成内容，也可能在后续被人工重新核对和制作。

因此，ToB产品除了看席位和调用量，还要继续追踪结果有没有进入业务：

客服是否采用了AI建议，而不是只打开过建议面板；
销售是否直接使用AI整理的客户信息，还是回到原系统重新查找；
审核人员的处理时间是否真的下降，还是多了一轮检查；
业务结果是否改善，还是工作量从一个角色转移到了另一个角色。

如果结果没有进入下一步，仅仅完成一次模型调用，并不等于完成了用户任务。

原文说“普及没有换来接受”，对产品经理最直接的提醒就是：需求不能由覆盖率证明。真正值得追踪的是，在默认设置、组织要求和新鲜感都退场之后，用户是否仍然愿意选择它。

二、技术能够自动化，不代表用户希望它自动化

原文把复古硬件、线下体验等“减少算法介入”的消费趋势放在一起讨论，试图说明一部分人正在重新寻找更直接、更具参与感的体验。

这些现象可以被当作文化信号，但不足以证明年轻人购买一台旧相机、使用纸笔或者参加线下活动，就是因为反对AI。把相关性直接写成因果关系，文章在这里下得有些快。

不过，它提出了一个产品经理必须认真面对的问题：当技术可以替用户完成更多事情时，产品是不是就应该自动化更多事情？这要看任务本身。

我们以前讨论自动化，常用的判断是效率：能不能减少步骤、缩短时间、降低人力成本。AI进入产品后，还需要增加三个变量：这个过程对用户有没有意义，错误会造成多大后果，以及用户是否愿意把决定权交出去。

第一类：纯操作负担，可以优先自动化

重复录入、格式转换、信息归类、固定规则下的检查，通常不是用户希望保留的体验。只要准确率和失败恢复达到要求，AI替用户完成得越彻底，价值越直接。

例如，把会议录音转成结构化记录，把多份材料中的固定字段提取出来，或者根据明确规则完成初步分类。用户关心的是结果，不会因为少点了几个按钮而觉得自己失去参与感。

第二类：包含判断的步骤，更适合辅助和确认

当任务开始涉及取舍、承诺和责任，产品就不能只追求自动化率。

AI可以整理合同风险、生成回复建议、提出诊断方向，但最终选择哪一项，往往需要结合它无法完整掌握的上下文。更合适的设计，是让AI压缩信息和提供候选，把影响结果的判断留给用户确认。

这不是对能力缺乏信心，而是对后果进行分级。一个错误的标题建议和一封错误发送的客户邮件，不应该使用同一套自动化策略。

第三类：过程本身有价值，应该保留人的参与

创作、学习、表达和社交中，有些“低效率”并不是缺陷。写作时形成判断，学习时经历推导，与他人交流时组织语言，这些过程本身就是用户想获得的东西。

如果产品只看到最终产物，就很容易把有意义的过程也当成等待优化的步骤。结果可能更快出现，但用户没有形成理解，也不认为产物代表自己。

因此，自动化程度不应该跟着模型能力单向提高，而应该由四个条件共同决定：任务价值、错误成本、用户意图和可恢复性。

AI产品经理真正要定义的，不是“这个任务能否被AI完成”，而是“这个任务的哪一部分应该交给AI，哪一部分必须由用户保留”。模型能力决定上限，产品判断决定它在什么位置停下来。

即使这条边界画得合理，用户仍然可能不采用功能。接下来要分清的，是他没有理解产品，还是产品没有完成任务。

三、用户不使用AI，是不会用，还是产品没有用？

面对AI功能使用率不高，团队最常见的解释是：用户还不会提问，不了解能力，也没有养成使用习惯。

这个解释有时成立。问题在于，它太容易把产品问题改写成用户教育问题。

原文对此给了一个重要的反方：行业以为自己需要把AI讲得更清楚，但消费者也可能已经理解得足够多，只是认为当前收益不值得所付代价。对产品团队来说，这两种判断不能混为一谈。

Pew在2026年的调查中专门询问了没有使用AI聊天机器人的成年人。83%的人把“没有兴趣”视为原因之一，79%提到个人信息如何被使用，76%担心答案不准确；相比之下，55%把“不知道怎么使用”列为原因。这个调查不能直接证明某个具体AI产品没有价值，但至少说明：不会使用只是原因之一，产品团队不能默认只要把教学做得更完整，用户就会留下。

先判断用户是否完成了任务，再判断他是否理解产品

“不会用”和“没有用”在数据上可能都表现为低频、低留存，但对应的产品动作完全不同。

如果用户找不到入口，不知道可以输入什么，第一次尝试也无法得到可用结果，这是可发现性和上手问题。产品可以通过场景入口、任务示例、首次引导和默认模板降低门槛。

如果用户已经知道怎么使用，也成功完成过一次，却没有再次回来，就不能继续只改引导。此时更应该检查，AI有没有把他的任务真正向前推进。

这里可以用一个简单的判断区分两者：

第一次在引导下成功使用，主要检验产品是否容易理解；第二次没有提醒仍然主动使用，才开始检验产品是否有价值。

模型给出了内容，不等于用户得到了结果

很多AI功能的完成指标停在“生成成功”。但用户通常不是为了获得一段生成内容而来，而是为了完成后面的事情。

会议纪要的任务不是生成一篇通顺文本，而是让参会者知道结论、负责人和截止时间；客服辅助的任务不是提供一段像样回复，而是帮助客服更快解决问题；数据分析的任务也不是生成图表，而是支持下一步判断。

如果用户需要花同样的时间核对、重写和补充，模型即使生成成功，产品也没有完成任务。

因此，产品经理应该把评估位置从“AI有没有输出”向后移动：

用户是否完成了原本的任务；
AI结果是否被采纳；
用户下一次是否主动使用；
用户是否回到了原来的流程；
人工修改和复核成本是否真的下降。

还有一个很实用的检查方法：暂时把需求文档里的“AI”两个字删掉，重新描述产品。

如果删掉以后，只剩下“智能生成”“自动分析”“一键处理”这样的能力词，需求可能还没有找到具体任务。只有当团队能说清楚谁在什么场景下少做了什么、提前完成了什么、避免了什么错误，产品价值才真正落地。

用户不会用，要改善引导；用户会用却不再使用，就要重新检查产品。把这两类问题分开，才能避免团队用更多教程掩盖更根本的需求问题。

四、产品已经有效，但价值究竟属于谁？

假设产品已经通过了前面的检验：用户能顺利使用，AI也确实提高了任务效率。问题仍然没有结束。

《AI本该赢得人心，但它没有》反复提到一种公众感受：AI带来的收益更多被公司获得，普通人却更直接地感受到工作变化、隐私风险、内容真实性和基础设施成本。原文讨论的是行业层面的价值分配，产品经理很难单独解决这些宏观问题。但同样的不平衡，也可能缩小后出现在一条具体产品链路中。

ToB产品里，“企业有效”不等于每个角色都受益

一套企业AI产品通常至少涉及四类人：

采购和决策者，关心预算、效率和整体ROI；
管理者，关心产能、质量和过程可见性；
一线使用者，关心自己的任务是否更容易完成；
审核与责任承担者，关心错误、合规和追责。

同一项功能可能让前两类人看到明显收益，却让后两类人增加工作。

例如，AI批量生成销售沟通内容，可以提高团队的表面产出；但如果一线销售需要逐条核对客户事实，法务还要承担错误承诺的风险，所谓“整体提效”可能只是把生产成本转成了复核成本。

采购者愿意付钱，说明商业价值可能成立；一线员工愿意持续采用，才说明产品价值也成立。两者不能互相替代。

ToC产品要区分平台价值和用户价值

消费产品加入AI，可能帮助平台增加停留时间、获得更多行为数据、降低内容和服务成本。这些都是合理的商业目标，但不能自动写成用户收益。

用户得到的价值需要单独回答：他是否更快完成任务，结果是否更好，是否减少了重复劳动，是否获得以前无法获得的能力。

如果AI让平台降低了客服成本，却让用户更难找到人工服务；让内容生产更快，却让用户花更多时间判断真假；提供了个性化体验，却要求交出更多个人数据，那么产品创造了价值，但主要受益者未必是用户。

这并不意味着AI功能必须让所有角色同时获得同等收益。现实产品很少能做到这一点。产品经理需要做的是把分配关系写清楚，而不是只用一个“整体效率提升”盖过去。

在评审一项AI功能时，可以追问四件事：

谁获得了最主要的收益？
谁因此多做了一项工作？
谁承担错误结果和后续责任？
谁真正拥有是否使用的选择？

这四个问题能帮助团队发现，使用阻力究竟来自保守心态，还是来自一个更实际的处境：要求使用AI的人获得了收益，真正使用AI的人却承担了成本。

产品经理无法为整个AI行业重新分配利益，但至少不能在自己的产品里复制同样的失衡。产品要长期留下，团队不仅要证明它“总体有效”，还要让实际使用者获得足够明确的价值。

当这笔价值账能够说清，剩下的问题才是：用户敢不敢把更重要的任务交出去。

五、信任不是品牌态度，而是一项需要设计的产品能力

即使AI产品已经有用，实际使用者也获得了价值，用户依然可能不愿意把重要任务交给它。

原文引用Dario Amodei的判断，把当下的公众态度称为一场信任危机。他的解释是，行业做出了很多宏大的承诺，却还没有交付足以匹配这些承诺的成果；他给出的解决方向，是兑现类似“治愈癌症”这样的重大承诺。

这个判断在行业层面没有错。但对产品经理来说，等待AI完成一次足够重大的突破，并不能解决具体产品里的信任问题。用户是否愿意让AI参与一项任务，通常由更具体的事情决定：它会做什么，可能在哪里出错，出错后能不能发现，结果生效前能不能干预，事情搞砸后能不能恢复。

产品里的信任不能靠一句“请放心使用”获得，它来自用户能够感知到的控制能力。用户不必确信AI永远正确，他需要知道即使AI出错，事情也不会立即失控。

用户不是不信任AI，而是不知道可以信任到哪一步

真实任务里的信任很少是二元选择，它更像一层层扩大的授权：

允许AI提供信息和参考；
允许AI生成方案或者草稿；
允许AI在用户确认后执行；
允许AI在约定范围内自主执行。

用户可能愿意让AI整理会议纪要，却不愿意让它代表自己发送邮件；愿意让AI分析合同，却不会允许它直接修改条款；愿意听取诊断建议，却坚持保留最终决定。

这不能简单归结为“用户不信任AI”。更准确的说法是，用户只愿意把当前任务授权到某一个层级。

如果一个产品刚开始就要求用户开放全部数据、交出执行权限，并接受不可撤回的结果，它是在信任尚未建立之前，提前索取最高等级的授权。问题未必是能力不够，而是授权顺序错了。

把信任做进流程，而不是写进文案

第一，说明能力与数据边界。

产品需要让用户知道AI正在处理什么、使用哪些信息、数据将如何被使用，哪些内容只是推测，哪些结果仍然需要人工判断。隐藏边界能让首次体验看起来更顺畅，却会让一次超出预期的错误摧毁用户对后续结果的判断。

第二，让重要结果可以被检查。

低风险任务可以只展示结果，任务越重要，越需要提供引用来源、数据范围、修改记录或者执行步骤。产品不必证明AI绝对正确，但要让用户有机会发现它可能错在哪里。

第三，把确认和权限放在后果重大的节点。

AI可以生成内容，不代表它应该自动发布；可以生成回复，不代表它应该自动发送；可以识别异常，也不代表它应该直接完成处罚。权限应该遵循任务所需的最小范围，确认则应该放在结果真正生效之前。

第四，让错误可以撤回和恢复。

如果AI修改的内容可以恢复，执行的操作可以撤回，自动化任务可以暂停，用户会更愿意尝试和扩大授权。相反，如果一次错误就意味着数据被覆盖、消息已经发出、业务流程无法回滚，再高的平均准确率也很难消除顾虑。

第五，为失败准备清楚的接管路径。

在ToC产品中，这意味着用户可以关闭AI、返回人工操作或者重新编辑结果；在ToB产品中，则意味着人工复核、角色权限、操作日志、异常升级和责任追踪。最糟糕的情况不是AI失败，而是AI失败后，用户不知道发生了什么，也不知道该找谁处理，只能从头再来。

信任也需要指标，但不能只问“你是否信任AI”

同一个用户可能信任AI推荐餐厅，却不信任它处理转账；信任它起草文案，却不信任它直接发布。脱离任务询问信任，答案很难指导设计。

产品经理更应该观察：

用户愿意把任务交给AI做到哪一步；
AI建议和结果的采纳率；
哪些节点频繁发生修改、撤回和人工接管；
出现一次错误后，用户是否还会再次使用；
随着使用次数增加，用户是否愿意开放更多权限。

原文对“信任危机”的方向判断是成立的，但“兑现更大的承诺”只能回答一部分问题。日常产品中的信任，不是靠一次宏大成果从外部注入的，而是在一次次稳定、可检查、可干预、可恢复的交付中形成的。

用户不是先信任AI，再愿意使用产品。更常见的顺序是，他先在低风险任务中确认产品没有失控，然后才愿意多交出一步。

结语：AI产品要争取的是留在任务中的许可

回到开头的反差：AI用得越来越多，产品经理却更难证明用户真正需要它。

增长数据没有失效，只是AI让“使用”变成了一个更复杂的状态。默认开启、平台分发和组织要求，可以让AI快速进入一条流程；只有真实需求、合理分工、明确收益和可控后果，才能让它留下。

所以，一项AI功能进入需求评审之前，产品经理至少应该回答五个问题：

如果不默认开启，用户还会主动选择它吗？
这一步适合被自动完成，还是用户需要保留判断和参与？
用户不使用，是因为没有理解产品，还是产品没有完成任务？
主要收益、额外工作和错误后果分别落在谁身上？
用户能否检查、干预、撤回，并在失败后恢复？

这五个问题不能保证产品成功，但能避免团队把模型能力当成需求，把调用量当成接受，再把产品问题解释为用户需要被教育。

AI不需要先赢得所有人的人心。用户完全可以在一个场景里依赖AI，在另一个场景里拒绝它；可以接受AI帮助整理信息，却坚持自己完成表达；也可以愿意尝试，但始终不开放自动执行权限。

对产品经理来说，更现实的成功标准是：当用户拥有完整的选择权，知道产品可能出错，也清楚自己可以随时退出时，他仍然愿意让AI下一次继续出现。

AI已经赢得了分发。接下来真正需要赢得的，是留在具体任务中的许可。

参考资料

Sarah Perez, TechCrunch, AI was supposed to win people over by now — it hasn’t, 2026-08-19.
Pew Research Center, Americans and AI 2026: Chatbots, Smart Devices and Views on Impact, 2026-06-17.
Pew Research Center, Why don’t people use chatbots?, 2026-06-17.