AI来了，产品设计该重启了
AI来了，产品设计该重启了
2023年到2024年，AI产品经理这个岗位的招聘需求涨了将近八倍。但与此同时，一个反直觉的现象也在悄悄发生：大量"AI功能"上线即沉没，七日留存跌到个位数。我们见过太多产品，把大模型接进系统，套一个对话框，就对外宣称"我们All in AI了"。结果用户在第三天就把那个对话框关掉了，甚至比没装AI之前用得更少。
这不是AI的失败，这是产品设计的失败。
本章要解决一个核心问题：当AI从"功能"变成"产品本身"，传统的产品设计方法论为什么失灵了？我们会从三个真实的产品翻车案例讲起，揭示一个尴尬的现实：很多团队把AI当作一个高级按钮贴上去，而不是重新设计产品。然后我们会拆解AI原生（AI-Native）与AI赋能（AI-Enabled）的本质区别——前者是从底层架构到交互范式都为AI而生的产品，后者只是在传统产品里加了一个AI功能。最后，我们会梳理产品设计需要被"重启"的五个层面，并抛出一个贯穿全书的思维实验。
这一定调的一章会建立全书的核心视角：AI不是功能的加法，而是范式的重构。
三个真实翻车案例：贴AI思维为什么必死
在正式开始拆解之前，我们先看三个真实发生过的产品翻车故事。这三个案例分别来自电商、内容、办公三个赛道，巧合的是，它们都是2023年下半年"AI+传统产品"浪潮中的典型样本，团队都花了真金白银，也都对外发过新闻稿。
案例一：某头部电商的"AI智能客服"
这家公司的客服系统原本有一套相对成熟的人工客服+知识库方案，转型时被要求"全量接入大模型"。团队的解法很直白：把用户问题直接丢给模型，让模型从知识库检索后生成回答。压力测试的时候效果不错，准确率超过90%，领导很满意。
上线两周后，客诉率暴涨三倍。
问题出在哪里？我们回溯了上千条失败对话，发现三类典型死法：第一类，模型在多轮对话中丢失上下文，用户问"我上周买的那件衣服"，客服第一轮答了，第二轮就忘了那件衣服是什么；第二类，模型为了"看起来更专业"，编造了知识库里不存在的退换货政策，用户拿着聊天记录来投诉，发现根本不是官方说法；第三类，模型对情绪识别不到位，用户已经在骂人了，客服还在微笑地说"亲，这边建议您……"。
最讽刺的是，用户找到的终极解决方案是：输入"转人工"。AI客服从一个降本工具变成了一个增本工具——它先把用户气一遍，再把人工客服累一遍。
案例二：某笔记应用的"AI写作助手"
这是一款有上千万日活的笔记产品，团队在2023年Q3上线了一个AI助手按钮，位置放在编辑器右上角，点击后弹出一个对话框，文案是"问问AI助手"。交互非常简单，符合当时市面上所有产品的标准做法。
然后呢？上线一个月，日均使用率不到3%。
我们去看用户访谈记录，最经典的一条反馈是用户说："我打开它问了一句'你是谁'，它回答'我是AI助手，请问有什么可以帮您'，然后我关掉了。"另一位用户的反馈更直接："我写笔记写得好好的，为什么要点那个按钮？点完之后我还得想怎么提问，然后它给我的答案我还得复制粘贴回来，整个流程比我自己写还累。"
这个案例暴露出的问题是：AI被当作一个外挂工具，而不是工作流的一部分。用户的主任务是写笔记，AI是一个被强行塞进来的"嘉宾"，它既不懂用户当前写到哪了，也不知道用户的写作风格，更没办法主动提供价值。一个只能回答"我是AI助手"的AI助手，本质上就是没做用户研究的产品经理的遮羞布。
案例三：某办公软件的"AI一键生成PPT"
第三个案例来自办公协同赛道。某头部产品上线了"AI一键生成PPT"功能，宣传语是"输入主题，10秒生成专业演示文稿"。从技术指标看，模型确实能在10秒内吐出一份20页的PPT，标题、配图、动画一应俱全。
但用户实际用下来，抱怨集中在三点：第一，生成的PPT内容空洞，每一页都是正确的废话，没有真正的观点和结构；第二，配图经常出现与主题无关的图片，AI会一本正经地在"季度复盘"里放上一张沙滩排球的照片；第三，用户修改的成本极高，因为AI生成的内容不是结构化的，而是一整块文本，想改某一句话得在AI生成的版本和原始版本之间反复复制粘贴。
最后团队的复盘报告里有一句非常到位的话："我们的AI生成的不是PPT，是PPT的尸体。"
为什么"贴AI"必然失败？
三个案例背后是同一个底层错误：团队把AI当作一个高级按钮，贴在现有产品上，期待它"魔法般地"提升体验。但AI不是按钮——按钮是确定性的，AI是概率性的；按钮的输入输出是工程师定义的，AI的输出是模型基于概率分布生成的；按钮的失败模式是可枚举的，AI的失败模式是发散的。
当你用确定性产品的思维去集成一个概率性系统时，你会遇到三堵墙：
第一堵墙是控制感墙。传统产品的设计师习惯于控制每一个像素、每一条文案，但AI的输出天然就带有随机性。你没办法像要求按钮颜色必须是#1890ff一样要求AI的回答必须包含某个关键词。
第二堵墙是责任墙。传统产品里，出了bug就修bug；AI产品里，模型"编造"了一个不存在的政策，这算谁的锅？产品经理、算法工程师、还是模型供应商？这是一个责任链完全不同的领域。
第三堵墙是用户预期墙。用户对AI的预期是"无所不能"，对按钮的预期是"按一下出结果"。这种预期错位会让用户的失望感被放大十倍。
这三堵墙共同决定了：在传统产品上"贴"AI，不是改良，是降维。
AI-Native vs AI-Enabled：六维对比框架
贴AI之所以失败，根本原因是混淆了"AI赋能（AI-Enabled）"和"AI原生（AI-Native）"这两类完全不同的产品形态。AI赋能是在传统产品上"加"一个AI功能，AI原生是从零开始"为"AI设计整个产品。这两者的差异不是程度问题，而是范式问题。
我们提出一个六维对比框架，从底层架构、交互范式、数据流向、价值交付、错误处理、商业模式六个层面来拆解这个差异。
维度一：底层架构
AI赋能产品的底层架构是"传统系统+AI模块"的拼贴结构。AI模块通常以一个微服务或外部API的形式存在，通过HTTP调用嵌入到主流程中。数据库、缓存、日志、监控这些基础设施都是为确定性系统设计的。
AI原生产品的底层架构是"模型优先"的设计。数据存储、状态管理、工具调用、记忆机制都是围绕模型的能力边界和推理过程来设计的。一个典型的AI原生架构会包括：向量数据库用于长记忆、工具注册中心用于能力扩展、规划器用于多步推理、可观测系统用于追踪每一轮推理的输入输出。
打个比方，AI赋能产品像是在一辆燃油车上加装了一个电动辅助系统，AI原生产品则是从一开始就按电动车平台来设计——电池布局、车身配重、热管理系统全部重构。
维度二：交互范式
AI赋能产品延续了图形界面（GUI）的交互范式——按钮、菜单、表单、对话框，AI只是其中一个新组件。用户的操作流程仍然是"选择-输入-确认-查看结果"，AI只是把"输入"这个环节替换成了自然语言。
AI原生产品则拥抱一种新的交互范式，我们称之为"对话式+生成式"的混合范式。交互不再是由UI元素驱动的，而是由意图（intent）驱动的。用户表达意图，AI主动拆解任务、调用工具、生成内容、组织呈现。这种范式下的界面更像是"驾驶舱"——人类负责表达目标和监督结果，AI负责执行和中间过程。
这种差异在用户体验上非常明显。AI赋能产品里，AI是一个工具，你"使用"它；AI原生产品里，AI是一个协作者，你"与它共事"。
维度三：数据流向
AI赋能产品中，数据是单向的：用户输入→前端→后端→数据库→返回。AI只是其中一个加工环节，数据不参与模型训练或微调。
AI原生产品中，数据是闭环的：用户每次交互产生的数据都会回流到模型层，用于效果评估、prompt优化、模型微调甚至重新训练。数据是产品迭代的燃料，而不仅仅是状态记录。
这个差异决定了AI原生产品具有"用得越多越好用"的特性，而AI赋能产品往往停留在"用得越多bug越多"的水平。
维度四：价值交付
AI赋能产品的价值交付是"功能点"——AI能做什么，是一个个独立的feature。营销话术往往是"我们支持AI写作、AI翻译、AI总结……"。
AI原生产品的价值交付是"结果"——AI负责完成一个完整的、端到端的任务。营销话术往往是"你只需要说一句话，剩下的AI帮你搞定"。
这个差异听起来像是文案游戏，但它直接决定了用户的认知成本。在AI赋能产品里，用户要学习每一个AI功能的使用方法；在AI原生产品里，用户只需要学会"如何表达自己的目标"。
维度五：错误处理
这是最容易被忽视的差异。AI赋能产品对错误的处理方式是"降级"——AI功能出问题时，回退到传统方案。比如AI总结失败，就显示"摘要生成失败，请阅读原文"。
AI原生产品对错误的处理方式是"协商"——AI会主动询问用户、调整方案、重新尝试。比如AI生成了一份不满意的PPT，它会说"你想要更正式还是更活泼的语气？需要我增加数据图表吗？"
这种差异背后的哲学是：AI赋能产品把AI当作一个"有时候会坏的工具"，AI原生产品把AI当作一个"有时候会错的伙伴"。对工具的失败是终止，对伙伴的失败是沟通。
维度六：商业模式
AI赋能产品的商业模式往往无法从AI功能中直接获利——AI功能被当作获客手段或留存工具，免费提供给用户，靠其他增值服务赚钱。
AI原生产品则更容易构建"AI即服务"的商业模式——按调用量、按时长、按结果质量计费。AI本身就是核心商品，而不是赠品。
这个差异会影响产品决策的每一个细节：AI赋能产品的PM会问"这个AI功能上线后能不能带动DAU"；AI原生产品的PM会问"这个AI交互是不是真的为用户节省了时间"。
```mermaid flowchart TD subgraph TR[传统产品开发流程] A1[需求调研] --> A2[PRD撰写] A2 --> A3[UI设计] A3 --> A4[开发与测试] A4 --> A5[上线发布] A5 --> A6[用户使用固定功能] end
subgraph AN[AI原生产品开发流程] B1[用户场景定义] --> B2[模型能力探查] B2 --> B3[Prompt与工具编排] B3 --> B4[小范围用户验证] B4 --> B5{效果评估} B5 --> B6[迭代优化] B6 --> B3 B5 --> B7[能力扩展与外化] B7 --> B2 end ```
这六维对比不是说AI赋能就一定是"低级的"——在很多场景下，AI赋能是合理的、经济的、够用的。但我们必须清楚地认识到：当你面对的是一个真正由AI主导价值交付的产品时，AI赋能的思路会让你做出系统性的错误决策。
产品设计需要重启的五个层面
理解了AI-Native与AI-Enabled的本质差异后，下一个问题就是：如果我们要做AI原生产品，传统产品设计的哪些层面需要被"重启"？我们梳理出五个层面，这五个层面不是独立的，而是相互关联的——重启其中一个，必然牵动其他四个。
第一层：信息架构的重启
传统产品的信息架构是"分类树"——一级菜单、二级菜单、三级菜单，逻辑清晰、路径明确。这是为"用户知道自己要什么"设计的。用户带着明确目的进入产品，沿着预设路径找到目标功能。
AI原生产品的信息架构是"任务流+语义网"。用户带着意图进入产品，AI帮用户规划路径、调用工具、组合信息。信息的组织方式不再是分类树，而是围绕"用户的任务目标"动态生成的结构。
举个例子。在传统电商App里，"找一款适合夏天的连衣裙"需要用户自己走路径：女装→连衣裙→夏季新款→筛选→浏览。AI原生电商可能会这样：用户输入"我想买一件适合海边度假的裙子，预算500以内"，AI直接调用筛选、推荐、搭配能力，呈现一个组合方案。
这种信息架构的重启对团队的挑战是：放弃"控制感"。你不再能100%控制用户看到的每一个信息点，你只能控制AI的决策框架和知识边界。
第二层：交互范式的重启
这一层在六维对比中已经讨论过，这里重点说"重启"的具体动作。
交互范式重启的核心是：从"事件驱动"转向"意图驱动"。传统产品的每一次用户操作都是一个"事件"——点击、滑动、长按。AI原生产品的每一次用户表达都是一个"意图"——可能是模糊的、不完整的、甚至是矛盾的。
这意味着设计师要重新思考"输入"这件事。文本框不再是唯一输入方式，语音、手势、上传文件、上下文行为（你当前在看什么、你之前做过什么）都可以成为意图的载体。AI要能够从这些零散的信号中提取出真正的目标。
第三层：用户角色的重启
传统产品里，用户是"操作者"——他点哪里，产品就反应什么。AI原生产品里，用户的角色发生了变化，他既是"决策者"（定义目标、设定约束），也是"监督者"（审查AI的输出、纠正AI的偏差），还是"协作者"（与AI多轮互动、共同完成任务）。
这种角色变化带来了全新的设计挑战。比如，用户作为监督者时，他需要"可解释性"——AI要能告诉他"我为什么这么做"。用户作为协作者时，他需要"可干预性"——AI要允许他在中途改变方向、调整策略。
这要求产品必须为"过程"留出空间，而不是只关心"结果"。传统产品可以只交付结果，AI原生产品必须把过程显性化，让用户参与到过程中来。
第四层：价值度量的重启
传统产品的价值度量是清晰的：DAU、留存、转化率、GMV。AI原生产品的价值度量必须被重新定义。
一个最直接的挑战是：如何度量AI输出的"质量"？传统功能可以枚举成功/失败，AI功能很难——同一个回答，对用户A是满意，对用户B可能就是不满意。你不能简单地用"成功率"来度量，必须引入"用户反馈"和"任务完成度"等更复杂的指标。
另一个挑战是：长周期价值 vs 短周期价值。AI原生产品往往有"越用越好"的特性，用户的长期价值（LTV）会随着交互次数增加而提升。这要求产品团队把度量周期从"日/周"扩展到"月/季度"，并设计相应的留存机制。
我们建议的度量框架是"四指标体系"：任务完成率（Task Completion Rate）、用户满意度（CSAT）、交互深度（Engagement Depth）、长期留存（Long-term Retention）。这四个指标分别对应了AI的"能力"、"质量"、"粘性"、"价值"。
第五层：商业模式的重启
最后一层是最现实的。传统产品的商业模式往往是"功能定价"——基础功能免费、高级功能付费、增值服务订阅。AI原生产品如果沿用这套模式，会遇到一个根本问题：AI能力的成本是"调用一次收一次"，而功能开发的成本是"开发一次反复用"。
这意味着AI原生产品必须重新设计收费模型。我们看到业内已经出现了几种模式：
第一种是"按结果付费"——AI完成了某个具体任务（如生成了10张可用的图）才收费。Notion AI的部分高级功能就在尝试这种模式。
第二种是"分层订阅"——基础模型能力订阅制，深度定制功能按项目计费。这适合B端产品。
第三种是"AI作为成本中心"——AI不直接产生收入，但通过提升效率带动其他业务指标（转化率、ARPU）的提升。这适合AI赋能型产品。
模式选择不是本章的重点，但产品经理必须意识到：商业模式不是产品上线后才想的事，而是从第一天就内嵌在产品设计里的。一个好的AI原生产品，其商业模型和用户体验模型是同构的。
砍功能思维实验与AI-Native成熟度自评
有了上面五个层面的分析框架，我们就可以进入本章最落地的一个部分：如何评估你自己的产品距离AI原生还有多远？我们设计一个"AI-Native成熟度自评表"，同时配一个贯穿全书的思维实验——"砍功能"。
贯穿全书的思维实验：砍功能
在进入第二章之前，我想请你做一个小小的思维实验。请闭上眼睛，想象明天早上老板告诉你：我们要彻底AI原生化重做这个产品，过去的功能模块可以全部推翻。你现在需要做的第一件事，是找出"第一个应该被砍掉的功能"。
这个问题看起来简单，实际上非常深刻。它逼迫你回答三个底层问题：
第一，谁是你的用户？ 这个问题之所以重要，是因为AI原生产品对用户的定义通常更窄、更深。不是"所有人"，而是"那一群有特定高价值任务的人"。比如Notion AI的核心用户不是"所有记笔记的人"，而是"那些把Notion当作工作流中枢、每天要写大量文档的知识工作者"。
第二，什么是你提供的核心价值？ 如果你提供的是"信息检索"，AI可能根本不需要一个"搜索框"；如果你提供的是"内容创作"，AI可能不需要一个"模板库"。砍掉什么、保留什么，本质上是在重新定义你的价值主张。
第三，AI的"原生优势"是什么？ AI比传统软件强的地方在于：理解模糊意图、生成动态内容、跨任务协同。如果你的某个功能模块正好需要这些能力，那就是AI应该大放异彩的地方；反过来，如果某个功能是高度结构化、高频重复、确定性强的，那它可能根本不应该被AI化。
这个"砍功能"思维实验我们会在每一章的开头重新拿出来用。到本书结束的时候，你应该能够系统性地画出一张"砍掉什么、保留什么、重构什么"的迁移路线图。
AI-Native成熟度自评表
为了让你能定量地评估自己的产品，我们设计了一个五级成熟度模型。每个评估维度都从L1到L5打分，L1是"完全传统"，L5是"完全AI原生"。
| 评估维度 | L1 贴AI | L2 集成AI | L3 AI赋能 | L4 AI驱动 | L5 AI原生 | | --- | --- | --- | --- | --- | --- | | 架构层 | 传统架构+AI API | 引入向量库 | 模型嵌入主流程 | 模型编排+工具调用 | 模型优先全栈设计 | | 交互层 | 加一个对话框 | 自然语言搜索 | 多轮对话支持 | 意图驱动+主动建议 | 任务流+语义网 | | 数据层 | 数据单向 | 收集用户反馈 | 数据回流评估 | 数据驱动微调 | 闭环自学习系统 | | 价值层 | AI是噱头 | AI是辅助 | AI是效率工具 | AI是核心交付 | AI是产品本身 | | 度量层 | DAU/留存 | AI功能使用率 | 任务完成率 | 用户满意度+长期价值 | 多维生态指标 |
使用这个表的方法很简单：让你的核心产品团队（PM、技术、设计、数据）对每个维度独立打分，然后取平均。得分加总之后，你就能大致判断产品的AI原生化进度。
一般而言：
- 总分5-10：贴AI阶段，建议从战略层面重新思考AI定位
- 总分11-15：AI赋能阶段，方向正确但需要深化
- 总分16-20：AI驱动阶段，已经走在正确的路上
- 总分21-25：AI原生阶段，可以对外输出方法论
根据我们的经验，**大多数声