在AI产品开发中，技术能力的飞速扩张与用户体验的有限性形成了鲜明对比。本文深入剖析了这一结构性矛盾，拆解了认知负荷、信任建立和情感需求三个维度的天花板，并分享了如何在技术狂飙时代，找到与用户真实需求同频共振的产品设计方法论。
这句话不是我从哪本书里读来的，也不是某次顿悟的产物。它是我在做 AI 产品的过程里，被一个反复出现的现象逼出来的结论。
现象很简单：技术能做的越来越多，用户用到的越来越少。
这不是个别项目的问题，而是我在 ToB 和 ToC 的不同项目里都遇到过的规律。每次功能上线，技术侧的完成度很高，但用户侧的反应总是和预期有落差。一开始我以为是产品设计的问题，后来慢慢意识到，这个落差本身就是一种结构性的东西——不是某个环节出了错，而是技术扩张的速度和人类接受体验的速度，本来就不在同一个轨道上。
技术无限，人类体验有限。说的就是这件事。
在 AI 产品这个语境里，”技术无限”不是一种夸张，而是一种工作状态的描述。
模型能力在持续迭代，每隔一段时间就会有新的技术可能性出现。从早期只能做模板化的内容生成，到多轮对话、多模态输入、实时联网、复杂推理……每一次迭代，工程侧能实现的事情都在扩张，产品侧的”可以做”列表也随之变长。
这带来一种很自然的工作惯性：技术能做的，就应该做进产品里。
这个逻辑本身没有问题，但它有一个隐含的前提——用户的接受能力会随着技术能力同步扩张。而事实上，这个前提并不成立。
技术的可能性空间是在指数级扩张的，但用户处理信息的方式、建立信任的速度、对意义感的需求，这些东西几乎没有随着 AI 的发展发生任何变化。它们是人类认知结构里更底层的东西，不会因为模型版本更新就自动升级。
这就是”技术无限”真正值得警惕的地方——不是技术本身有什么问题，而是它扩张得太快，快到很容易让人忘记用户那一侧的边界还在原地。
我参与过一个 ToC 的 AI 效率工具，上线时一共做了十几个功能模块，每一个单独看都有合理的用户场景。但上线之后，用户行为数据显示，绝大多数人只会使用其中一两个功能，其余的对他们来说几乎不存在。
用户访谈里有人说了一句话，我觉得说到了本质：”功能太多，我不知道哪个是给我用的。”
这不是设计问题，而是认知结构的基本事实。人在面对超过一定数量的选项时，大脑不会努力分析哪个最优，而是倾向于放弃选择，或者退回到最熟悉的那一个。选项越多，决策成本越高，用户反而越容易什么都不做。
我们后来做了改版，把十几个模块收进统一入口，首页只保留三个最高频的场景。没有删掉任何功能，只是改变了用户遇见它们的方式。改版后的次日留存有明显提升。
这件事让我意识到一个反直觉的结论：产品做加法是技术在扩张，产品做减法才是在真正理解用户。技术给了用户一百种可能，但人在面对太多选择的时候，往往会选择什么都不做。
在一个 ToB 的 AI 辅助决策工具项目里，我遇到了一个更难处理的问题。
产品的核心功能是根据业务数据自动生成分析报告。技术层面，准确率在内部测试中相当高。但上线之后，用户会用这个功能生成报告，却几乎不会直接拿去对外提交——他们会把内容复制出来，重新排版，甚至逐字改写一遍再用。
访谈里一个用户说的话我记了很久：”不是说它不准，它其实挺准的。但我没办法跟我老板解释这个结论是怎么来的。”
这句话揭示了一个技术层面解决不了的问题：用户对 AI 的信任，不只是”我相信这个结果是对的”，还包括”我能不能为这个结果负责”。准确率是技术指标，但”能不能背书”是社会关系里的问题，两者不在同一个维度。
更麻烦的是，信任一旦受损，恢复的速度远慢于技术修复的速度。那个项目里，模型出过一次输出错误，技术团队两天内修复了，但用户的使用率下降持续了将近半年。
技术能力的提升是跳跃式的，但用户信任的建立是线性的，而且极其脆弱。这个不对称性，是做 AI 产品时最容易被低估的风险之一。
后来我们在产品里增加了推理过程可见的设计，加了数据来源引用，在报告显眼位置加了”以下内容由 AI 辅助生成，请结合实际情况判断”的提示。很多人觉得这是在贬低产品，但用户反馈告诉我们，这行字反而让他们更愿意用。我们花了很多力气证明 AI 有多强，结果用户最需要的，是我们主动承认它也可能出错。
这是三个维度里最难被量化的一个，也是最容易在产品决策里被忽视的。
我参与过一个面向创作者的 AI 写作工具。核心功能是输入主题，AI 自动生成完整文章。生成质量在盲测中相当高。但上线之后，用户的反应非常分裂：一部分人持续在用，另一部分人试了几次之后就不再回来了，给的理由是”感觉不像是我写的”、”发出去有点心虚”。
我做了用户分层分析，发现那些流失的用户，写作对他们来说不只是一个生产任务，而是一种表达，甚至是一种自我确认。AI 帮他们写出了一篇好文章，但那篇文章里没有他们自己的选择和取舍，所以那篇文章对他们来说就不是自己的。
这让我开始认真区分两件事：AI 替用户做完一件事，和 AI 帮用户做好一件事，这两者对用户的体验是完全不同的。前者剥夺了过程，后者保留了参与。
我们后来把”一键生成”改成了”协作写作”——AI 提供结构建议和素材参考，用户自己来组织和写，AI 在旁边做实时润色。这个模式的留存比”一键生成”好，尽管它在技术上更保守。技术可以替用户做很多事，但有些事用户需要自己做，不是因为他们不信任 AI，而是因为那个过程本身对他们有意义。
做 AI 产品的 PM，要同时面对两个方向截然相反的压力，而且这两个方向几乎总是同时存在的。
技术团队的逻辑是”能做就做”。每次有新的技术能力出来，都会有人问：这个要不要加进产品？这不是刁难，而是真实的工作惯性。如果我说”先不加”，就需要解释为什么一个”技术上可以实现的功能”不值得做，这个解释在技术文化里往往很难被接受。
业务和管理层的逻辑是”竞品有的我们要有”。功能数量和技术先进性，是他们评估产品竞争力最直觉的方式。”做减法”在他们听来，很容易变成”我们要落后”。
用户的声音，通常通过用研报告、数据、客服反馈间接传递过来，它在会议室里的优先级，往往是最低的那个。
这个结构性困境没有简单的解法。我在这里面待过一段时间之后，慢慢学会了一件事：把用户体验的有限性，翻译成技术团队和业务团队能听懂的语言。不说”用户不喜欢这个功能”，说”这一步的流失率是 65%”；不说”功能太多了”，说”首页所有功能里，前三个占了 89% 的点击量，其余加起来不到 11%”。数据是 PM 在这个夹缝里最有效的工具，不是因为它能说服所有人，而是因为它能把主观感受变成可以被讨论的东西。
这些年下来，我形成了几个对自己有用的工作习惯，不是方法论，只是一些思维方式上的调整。
第一，每次只让用户感受到一个变化。技术能力再强，每次迭代我都会问自己：如果这次只能让用户感受到一个不同，哪一个最值得？用户对产品建立好感的方式，往往是一个接一个的小惊喜，而不是一次被二十个功能淹没。
第二，在用户现有的认知框架里设计，而不是试图升级他们的认知框架。我见过很多产品，预设了一个”理想用户应该怎么用 AI”的模型，然后用教程、引导、弹窗试图把用户教育成那个理想用户。这条路几乎没有成功过。用户不会因为产品足够强大就改变使用习惯，他们只会在产品符合自己已有习惯的时候才真正用起来。
第三，给用户留一个”这是我做的”的出口。不管自动化程度多高，我都会在流程里设计一个让用户感到参与的节点。哪怕只是一个确认按钮，哪怕只是让用户改一个标题，这个节点的存在会让用户对最终结果产生归属感。这不是技术上需要的设计，是心理上需要的设计。
第四，把用户对 AI 的信任当成一个需要主动维护的东西。我现在在做产品规划时，会专门想：用户现在对这个功能的信任程度在哪里？这次迭代会让它变高还是变低？这个问题没有标准答案，但把它放在心里，会让很多决策多想一步。
“技术无限、人类体验有限”，对我来说不是一个已经想清楚的结论，而是一个持续有效的提醒。
技术还在跑，而且会一直跑下去。每隔一段时间就会有新的”我们现在能做这个了”出现，我也还是会在那之后，习惯性地问那个扫兴的问题：用户准备好了吗？
人类处理信息的带宽、建立信任的速度、对过程中意义感的需求，这些东西几乎没有随着 AI 的发展发生变化。它们是更底层的东西，不会自动升级。技术和人之间的这条缝隙，不会因为模型更强就自动消失，它需要有人站在里面，想办法让两边靠近一点。
我没有觉得这个问题已经有了答案。但我觉得，持续把这个问题放在心里，本身就是做 AI 产品最重要的事之一。
最后留一个我一直没想清楚的问题：当技术的速度持续超过人类适应的速度，我们到底在为谁设计？
还在被用户持续教育中。
本文由 @van ner 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Pexels，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。