AI 产品设计方法

flowchart LR
  A["AI 产品设计方法"]
  A --> B["分类：产品与设计"]
  A --> C["关键词：AI Product"]
  A --> D["关键词：产品设计"]
  A --> E["关键词：AI-first"]
  A --> F["关键词：用户价值"]

不是所有产品都需要 AI。真正值得做的 AI 产品，不是“接上一个模型”，而是用新的能力重构任务完成方式，同时认真处理它的不确定性、成本和边界。

延伸阅读：

Nielsen Norman Group: AI UX Guidelines —— AI UX 指南

AI Product Institute —— AI 产品方法论

这篇文章会讲什么

过去很多所谓的 AI 产品，本质上只是给已有界面加了一个对话框，或者把“生成”按钮塞进原本并不需要它的流程里。短期看像在追热点，长期看却很容易暴露出几个问题：价值不明确、体验不稳定、成本失控、用户不信任。

这篇文章想回答的不是“怎么给产品接入大模型”，而是更前面的问题：

什么样的问题值得用 AI 来解
AI 到底给产品带来了哪类独特价值
为什么 AI 产品的设计方法和传统软件不一样
面对不确定输出，产品应该如何建立信任，而不是消耗信任
在真实工程里，模型、流程、交互、评估该怎样一起设计

如果把这套方法想清楚，你做出来的东西才更像一个完整产品，而不是一个“模型能力展示页”。

AI-first vs 给现有产品加 AI

先看定义：AI-first 不是“产品里有 AI”，而是“产品的核心任务完成方式因 AI 而改变”；给现有产品加 AI，则是在既有价值链里寻找增量效率。

这两条路径都成立，但它们解决的问题不同，风险也不同。

两种路径的本质区别

维度	AI-first	给现有产品加 AI
起点	从用户任务重构产品形态	在现有流程中寻找可增强环节
核心问题	AI 是否让任务有了新的完成方式	AI 是否显著提升现有体验
交互形态	可能重做主界面、主流程、主心智	通常叠加在已有功能之上
价值来源	新能力、新工作流、新品类	效率提升、门槛降低、体验补强
主要风险	用户教育成本高、路径验证难	容易沦为“可有可无”的附加项
适用场景	新任务、新人群、新品类	成熟产品、成熟流程、已有用户基础

两种路径都常见，但不要混淆

一个很常见的误区是：团队嘴上说自己在做 AI-first，实际上做的是“给原产品加个聊天入口”；或者反过来，明明只是做局部提效，却试图讲成“新范式”。

这会直接影响产品判断。

因为 AI-first 要回答的是：如果没有 AI，这个产品还成立吗？ 而“给现有产品加 AI”要回答的是：如果把 AI 拿掉，核心产品是否仍成立，但效率明显下降？

这两个问题完全不同。

更实用的判断方式

不要急着给自己贴标签，先问三个问题：

AI 是否进入了主任务闭环，而不是外围功能？ 如果 AI 只负责润色文案、生成推荐词、总结说明，很可能只是局部增强；如果 AI 决定了用户如何发现信息、完成创作、推动决策，它才更接近产品核心。
没有 AI 时，用户的完成路径是否会明显变形？ 若去掉 AI 后，产品只是“慢一点”“麻烦一点”，这通常是增强；若去掉 AI 后，核心价值就无法成立，才更接近 AI-first。
AI 带来的，是效率改进还是能力跃迁？ 效率改进值得做，但不要误判成能力跃迁。两者在定价、体验、容错、增长叙事上都不同。

一个更稳妥的观点

两条路径没有绝对优劣。对成熟产品来说，先做增强往往更稳：用户已有心智、数据和场景也更明确，适合快速验证 ROI。对新产品来说，AI-first 有机会打开新的交互和新品类，但也意味着更高的不确定性。

真正重要的问题始终只有一个：

AI 解决了什么传统方案很难解决，或者解决成本明显更高的问题？

如果这个答案说不清，产品通常也做不清。

从确定性到概率性：产品范式的根本转变

先看定义：传统软件主要在“逻辑正确性”上竞争，AI 产品还要在“概率可用性”上竞争。

传统软件更像精密机器：输入、规则、输出之间关系清晰，可重复、可验证、可追责。而 AI 产品，尤其是基于 LLM 的产品，更像“高能力但不完全稳定的合作者”：多数时候有帮助，少数时候会误解、遗漏、幻觉、跑偏，甚至在看起来很自信时给出错误答案。

这不是一个局部差异，而是产品方法论层面的变化。

确定性产品 vs 概率性产品

特性	确定性产品	概率性产品（AI）
输出	可预测、可复现	有波动，受上下文和提示影响
错误来源	规则错误、实现 bug、数据问题	模型能力边界、语义歧义、上下文缺失、检索噪声
修复方式	修代码、补规则、修数据	降低错误概率、改流程、加约束、做人机协同
用户预期	“系统应该永远按规则工作”	“系统通常能帮我，但不应盲信”
质量保证	单测、集成测试、回归测试	离线评估 + 在线观测 + 人工复核 + 场景化验收
体验目标	正确执行	可用、可信、可纠偏

为什么这件事很重要

因为一旦产品从确定性系统变成概率性系统，很多以前默认成立的东西都不再成立：

不能再用“功能是否存在”代替“结果是否可用”
不能再只看点击率、使用时长，而忽略任务成功率
不能再把异常当成边角问题，因为“偶发错误”本身可能就是系统常态
不能再只做功能交付，而不做预期管理与失败兜底

从工程上看，AI 产品设计不只是“多了个模型模块”，而是需要重新定义什么叫可用、什么叫可靠、什么叫完成任务。

一个经常被忽略的事实

AI 产品里，错误不等于 bug。

有些错误当然来自工程实现，比如 prompt 拼接错了、检索召回错了、工具调用参数错了。但还有一类错误，即使工程都做对了，也仍然会发生：模型对复杂语义的误判、知识缺口、推理失真、对用户真实意图的过度猜测。

这意味着你不能只靠“修一次”解决问题，而要把“错误会持续存在”当成设计前提。

这也是为什么 AI 产品比传统产品更需要系统设计：不仅要想“成功路径”，还要想“出错路径”。

为不确定性而设计

先看定义：好的 AI 产品不是让用户感觉“它永远正确”，而是让用户在它不完全正确时，仍然能顺利完成任务。

很多团队会把“不确定性”当成一个模型问题，仿佛只要模型再强一点、prompt 再调一下，产品问题就会消失。现实里，不确定性是模型、数据、检索、工具调用、上下文长度、任务表述、人类输入质量共同作用的结果。

所以“为不确定性而设计”，本质上是把错误当成一等公民来设计。

四个关键设计原则

1. 让系统的把握程度可感知

不是所有场景都适合直接显示一个分数化的 confidence score。很多时候，那样的数值反而会制造伪精确感。更实用的做法是让用户通过界面和内容结构，理解“这次回答建立在什么基础上”。

常见方式包括：

明示来源、引用、检索依据
区分“事实总结”和“生成建议”
标出模型假设、缺失信息、需要确认的前提
让系统承认不知道，而不是硬答

重点不是“展示一个置信度”，而是让用户判断这段输出值不值得信。

2. 用户必须能纠正它

AI 不是一次性吐答案的机器，而应该是可调整的协作者。用户要能：

改写指令
局部修改结果
重新生成某一段，而不是重来全部
指定风格、约束、优先级
明确告诉系统哪里错了

这点非常关键。因为大多数真实任务不是“生成一次就结束”，而是一个逐步收敛的过程。产品如果不给用户控制点，AI 就会从“助手”变成“阻碍”。

3. AI 失败时必须可降级

这是很多 Demo 型产品最薄弱的地方。它们在成功路径上很惊艳，一旦失败就只剩一句“请重试”。

更成熟的产品会提供降级路径，例如：

回退到传统搜索、筛选、表单流程
给用户展示原始材料，而不是只给总结
转人工审核或人工接管
给出可执行的下一步，而不是让用户自己猜

AI 不是非黑即白的。产品不该只在“完全成功”时可用，也应该在“部分失败”时仍可推进任务。

4. 反馈必须能形成闭环

点赞/点踩本身价值有限，除非它能进入真正的优化闭环。有效反馈通常包括三类：

显式反馈：用户指出错在哪、为什么不满意
隐式反馈：用户是否采纳、编辑了多少、是否绕过 AI 完成任务
结果反馈：AI 产出是否真的帮助任务成功，而不只是被点击过

很多团队收集了大量反馈按钮，却没有定义反馈如何影响模型选择、prompt 设计、检索策略和产品流程。那反馈就只是装饰。

不确定性不只体现在“答案错了”

一个成熟的 AI 产品还要处理这些更微妙的问题：

看起来合理，但关键细节错了
总体正确，但格式或粒度不适合直接用
回答太长，掩盖了真正重点
为了看起来聪明，补充了用户并未要求的内容
在缺信息时擅自脑补
在多轮对话中逐渐偏离原任务

这些问题未必会在传统错误指标里直接体现，但它们会强烈影响用户信任和实际任务完成率。

反例是什么

最危险的设计不是“AI 会出错”，而是：

把 AI 输出包装成权威答案
用过度自信的语气掩盖模型边界
让用户只能全盘接受或全盘拒绝
把失败归因给“用户不会提问”
缺少来源、缺少修改入口、缺少兜底路径

这类产品短期可能因为“看起来聪明”获得关注，但长期很难建立稳定信任。因为用户真正记住的，不是它答对了多少次，而是它在关键时刻错得有多离谱，以及错了之后用户有没有退路。

AI 产品的用户价值框架

先看定义：AI 产品的价值，通常不止是“更智能”，而是让用户更快、更稳、更有能力地完成任务。

“智能”本身不是用户价值。用户不会为模型参数量买单，也不会为“这是多模态大模型”而持续使用产品。用户真正感知到的，是任务层面的结果变化。

一个更实用的分类方法，是把 AI 产品价值分成三类：省时间、少出错、做以前做不到的事。

三类核心价值

价值类型	含义	典型场景
省时间	缩短完成任务的时间，降低认知和操作负担	代码补全、邮件起草、会议纪要、文档总结
少出错	降低人为遗漏和一致性问题，提高审查覆盖度	合同检查、规则校验、翻译校对、代码 review
新能力	让普通人完成过去门槛高、成本高或几乎做不到的任务	跨语言沟通、大规模个性化、复杂信息整合、创意辅助

这三类价值并不等价

1. 省时间最容易启动，也最容易被替代

“省时间”是最常见的 AI 价值主张，因为它最容易被用户理解，也最容易量化。比如“10 分钟写完会议纪要”“把初稿时间从 2 小时降到 20 分钟”。

但这类价值也最容易被通用模型能力吞噬。如果你的产品只是把现成模型包装成一个“帮我生成”的按钮，差异化往往很弱。

所以做“省时间”类产品，关键不是单次输出效果，而是：

是否深度嵌入用户已有工作流
是否理解任务上下文，而不是只会泛化生成
是否减少后续编辑成本，而不是把时间从“写”转移到“改”
是否在高频场景中持续稳定可用

2. 少出错更难做，但壁垒通常更高

“少出错”看起来不如“省时间”性感，因为用户不一定会立刻感知到一条错误被避免了。但在高价值场景里，它往往更接近真实业务价值。

例如：

法务不是需要“更会写”，而是需要“少漏风险点”
客服不是需要“更像人”，而是需要“少答错政策”
工程不是需要“更多代码”，而是需要“减少引入新 bug 的概率”

这类价值对产品提出更高要求，因为你不能只展示漂亮结果，还要建立可验证的可靠性机制。通常会涉及：

明确规则边界
对高风险内容增加审查层
使用来源、比对、结构化约束
对关键输出做人工复核或工具校验

3. 新能力最有想象空间，也最需要用户教育

AI 真正有机会创造新品类，往往来自“新能力”而不是“老流程提速”。例如，把多源资料压缩成一个可交互的研究入口；把复杂工具变成自然语言驱动；把原本需要专家经验的分析过程部分普及给普通用户。

但新能力类产品常见的问题是：用户不一定知道它能为自己做什么。这就意味着产品除了要有能力，还要有非常好的任务引导、案例化展示和首轮体验设计。

否则，强能力会被感知成“什么都能做，也什么都说不清”。

设计前必须回答的一个问题

你的产品到底主打哪一类价值？

可以兼有，但必须有主次。因为这会影响：

首页怎么讲价值
首次体验怎么设计
指标怎么定义
错误容忍度如何设定
价格策略如何成立

比如“省时间”型产品可以强调速度、频率、嵌入式体验； “少出错”型产品更需要可追溯性、审查流和风险提示； “新能力”型产品则更需要教育和示范，帮助用户形成新心智。

很多产品做不起来，不是因为模型不行，而是因为价值主张模糊：既想讲效率，又想讲创造力，还想讲专业可靠，最后没有一个点讲透。

不要只问“AI 能不能做”，要问“这个任务该怎样被重构”

AI 产品设计里，一个非常常见但代价很高的误区是：拿到一个用户需求后，先问“模型能不能完成这个任务”。

这还不够。

更关键的问题其实是：

这个任务在 AI 介入后，是否应该被拆分、重排、局部自动化，甚至改变交互顺序？

因为很多任务并不适合“用户提问，AI 一次性回答”的模式。真实工作流往往包含：

收集信息
理解目标
设定约束
生成候选方案
比较和筛选
编辑和确认
执行或交付

如果你把一个多阶段任务粗暴压缩成一次生成，用户往往会得到一个看起来完整、实际上难以直接使用的结果。

一个更接近工程现实的任务拆解视角

设计 AI 产品时，可以把任务拆成四层：

信息层：用户需要哪些输入材料、背景上下文、约束条件
推理层：哪些部分适合模型归纳、判断、生成、转换
控制层：哪些环节必须让用户确认、修改、选择
执行层：结果如何被落地到系统、文档、流程、工具中

很多失败产品的问题，不是模型能力不够，而是把四层混成了一层。

比如：

该让用户补充约束的地方，直接生成了
该让用户做最后确认的地方，自动提交了
该给原始证据的地方，只给了结论
该结构化输出的地方，用长段自然语言糊过去了

好的 AI 产品，常常不是“更聪明”，而是更会拆任务、分责任、给控制点。

AI 产品设计流程

先看定义：不是“先接模型，再调提示词”，而是从问题定义、可行性验证、交互原型、评估体系、上线观测一路闭环。

比起传统功能，AI 产品更不适合“需求评审通过 → 开发 → 上线”这种线性流程。因为其中有一段关键环节无法靠想象完成：你必须先知道模型在真实任务上到底行不行。

一个更稳妥的流程，可以分为五步。

五步流程

1. 识别痛点 → 2. 验证 AI 适配性 → 3. 设计最小闭环 → 4. 真实场景测试 → 5. 迭代优化与上线观测

1. 识别痛点：先确认值得做的任务，而不是先找模型用武之地

要回答的不只是“用户有没有需求”，而是：

这个任务是否高频或高价值
用户当前怎么做，哪里最痛
痛点来自时间成本、理解门槛、错误率，还是协调成本
这个任务是否有足够稳定的输入和输出形态
用户是否真的愿意为更好的完成方式付费或迁移习惯

AI 很适合处理“复杂但模式可抽取”的任务，不适合所有看起来费劲的任务。有些任务之所以难，不是因为信息处理难，而是因为责任归属、利益冲突、业务规则经常变化。对这些问题，AI 未必是主解法。

2. 验证 AI 适配性：在做产品前，先做任务可行性验证

这是最容易被跳过，也最值得投入的一步。

这里不是问“模型能不能偶尔做出来”，而是问：

在你关心的任务分布里，成功率是否够用
失败主要发生在哪些子场景
失败后是否有可接受的补救成本
响应速度、上下文长度、调用成本是否支撑商业可行性
数据权限、隐私、合规是否允许这样做

一个务实的方法是先拿出一批代表性样本，做小规模离线验证。不要只测“最容易成功”的例子，也不要只看几个惊艳案例。要故意纳入：

模糊输入
缺上下文输入
长文本、脏数据、矛盾信息
真实高风险样本
用户最常见但最无聊的样本

因为产品上线后，真正吞掉成本的，往往不是那些漂亮案例，而是大量普通甚至混乱的请求。

3. 设计最小闭环：不是最小功能，而是最小可完成任务

很多 AI 原型只做到“模型能出结果”，却没有闭环。例如，能生成摘要，但用户无法校正；能提建议，但无法应用到下一步；能回答问题，但没有证据和操作入口。

更好的原型目标是： 让用户在一个具体场景里，从输入到输出再到采纳，完整走通一次任务。

这一步应该重点设计：

输入如何获取：用户手输、上传文档、历史数据、系统上下文
输出如何呈现：全文、结构化结果、候选方案、差异比对
用户如何控制：重试、编辑、选择、确认、拒绝
结果如何落地：复制、应用、保存、发送、执行

4. 真实场景测试：不要只看“喜欢不喜欢”，要看“任务是否成功”

AI 产品的测试不能只做传统可用性测试，也不能只问用户“觉得智能吗”。更重要的是：

用户是否完成了原本想完成的任务
AI 是否真的减少了操作和思考负担
用户在关键节点是否知道该相信什么、修改什么
失败时是否有自然退路
用户会不会在第二次、第三次仍愿意使用

尤其要注意首轮体验和持续体验的区别。很多 AI 产品首轮惊艳，是因为用户把它当演示看；真正决定留存的，是第 5 次、第 20 次使用时，它是否仍然稳定、省力、可信。

5. 迭代优化与上线观测：上线不是结束，而是开始知道问题在哪

AI 产品很难在上线前把所有问题想清楚，因为很多问题只会在真实流量、真实任务、真实数据脏度下暴露出来。

上线后至少要持续观察：

任务成功率
用户采纳率与二次编辑率
错误类型分布
不同场景下的质量波动
请求成本、响应时间、失败重试率
用户对不同失败模式的容忍度

这一阶段的优化也不该只盯着 prompt。很多时候，真正有效的优化来自：

收窄任务边界
改写输入结构
补充上下文
拆分生成步骤
增加校验器或规则层
修改交互流程，减少误用

工程视角：AI 产品不是一个模型接入项目，而是一套系统设计

先看定义：用户感知到的是“产品好不好用”，不是“模型强不强”；而这个差异，通常来自系统设计而非单点模型能力。

很多文章谈 AI 产品设计时，容易停留在交互层和文案层。但只要产品进入真实使用，你会很快发现，体验质量取决于一整套系统协同：

模型选型
提示策略
检索质量
工具调用
上下文管理
缓存与成本控制
评估与观测
权限与安全策略
人工兜底机制

这也是为什么 AI 产品经理、设计师、工程师之间需要更紧密协作。你设计的不是一个按钮，而是一条“用户任务 → 系统理解 → 生成或检索 → 用户修正 → 执行落地”的链路。

在系统层，至少要想清楚这几件事

1. 模型是能力来源，不是全部能力

不要把所有问题都寄托在“换更强模型”。更强模型可能带来更高质量，也可能带来更高成本、更高时延、更难控输出。

很多场景的正确解法不是更大模型，而是：

更好的检索
更明确的输入结构
分步骤生成
更窄的任务定义
工具化执行代替自然语言猜测

2. 上下文比“会不会提问”更重要

现实里，用户不是不会提问，而是没有耐心一次次补充背景。所以优秀产品会主动利用已有上下文：

当前文档内容
历史操作
用户角色
团队知识库
当前页面状态
已选中的对象或片段

很多“提示词技巧”其实是产品没有把该提供的上下文准备好，最后把系统责任转嫁给用户。

3. 成本、延迟、质量必须同时权衡

这是 AI 产品与普通 SaaS 很不一样的地方。一次看起来质量更高的调用，可能意味着：

响应时间长 3 倍
请求成本高 5 倍
并发扩展性显著变差

而在真实场景里，用户未必愿意为那点质量增益多等几秒。因此产品必须思考：

哪些场景值得使用高成本模型
哪些步骤可以异步化或后台化
哪些结果可以缓存
哪些请求可以先给草稿再逐步完善
哪些任务只需要“够用”，不需要“最强”

4. 高风险环节不能只靠自然语言承诺

模型说“我会谨慎”，并不等于系统安全。如果产品涉及合规、执行动作、重要业务决策，就要在系统层增加约束，例如：

工具调用白名单
参数校验
权限控制
审批确认
敏感操作二次确认
输出后置校验

这不是在削弱 AI，而是在把 AI 放进可管理的系统里。

什么时候不该用 AI

先看定义：当传统方案更简单、更便宜、更稳定，或者问题的核心不在“智能处理”时，就不该硬上 AI。

这不是保守，而是产品判断。

不适合 AI 的典型场景

场景	为什么不适合	更合适的方案
高确定性、低容错的核心执行环节	需要严格可预测、可追责	规则引擎、工作流、人工复核
规则清晰且边界稳定	用 AI 反而增加不确定性	表单、校验器、固定逻辑
数据极少且难形成有效上下文	AI 缺乏判断依据	人工流程、模板、专家配置
极端实时响应场景	延迟预算不允许复杂推理	预计算、缓存、本地规则
大规模低价值请求	单次价值覆盖不了调用成本	批处理、传统算法、搜索
用户需要的是“可查”而不是“可生成”	生成可能掩盖原始信息	搜索、筛选、检索展示
高风险决策直接自动化	错误代价过高	决策支持 + 人工确认

一个简单但有效的判断问题

去掉 AI，传统方案能否做到 80% 的效果？

如果答案是能，而且更便宜、更稳定，那么优先用传统方案。因为产品不是技术选美，目标是以合理成本解决问题。

不过这个判断还有后半句，经常被忽视：

那剩下 20% 是否恰好是用户最在意、也最愿意为之付费的部分？

有时 80% 不够，因为剩下 20% 正是差异化价值所在。比如把海量资料整理成可追问、可引用、可压缩的研究入口，这可能就是旧方案难以达到的关键增量。

所以别把“能不能不用 AI”理解成否定 AI，而是把它当成一个价值校准动作。

常见误区：很多 AI 产品不是死于模型不够强，而是死于产品判断不成立

误区一：把“能生成”当成“有价值”

模型能生成一段内容，不等于这段内容对任务有帮助。很多产品 demo 看起来厉害，是因为“生成”本身具有表演性；但真实用户关心的是：

我是否因此更快完成任务
我是否因此更少出错
我是否因此得到过去得不到的能力

如果没有这些变化，“能生成”只是技术现象，不是产品价值。

误区二：把首轮惊艳当成长期留存依据

AI 产品特别容易在首次体验上得高分。因为用户会觉得新鲜、神奇、好玩。但真正决定产品生命力的，是高频使用后的稳定性：

质量是否波动太大
用户是否需要频繁重写提示词
修改成本是否高于自己做
是否有越来越多“不如我自己来”的时刻

所以一定要区分“展示价值”和“持续价值”。

误区三：把用户不会提问当成失败借口

“你要学会更好地 prompt”在某些专业工具里成立，但不能成为大众产品的默认前提。如果一个产品只有在用户极会提问时才好用，说明产品还没有把复杂性吸收掉。

成熟产品应该尽量减少用户的提示工程负担，而不是把系统设计责任外包给用户。

误区四：一味追求全自动

很多团队会本能地把“自动化率”当成最重要目标，仿佛 AI 产品的成熟度等于“人类参与越少越好”。

现实里并非如此。

在大量高价值场景中，更优解往往是：

AI 先做草稿
人类快速审阅和修正
系统记录反馈，下次更准

也就是所谓的人在回路（human in the loop）。不是因为 AI 不够强，而是因为任务本身包含责任、偏好、语境和风险管理，天然需要人类把关。

误区五：只优化 prompt，不优化系统

提示词当然重要，但它通常不是第一瓶颈。如果结果不稳定，更可能是：

任务定义太宽
输入上下文不足
检索召回质量差
输出格式不适合下游使用
缺少校验和兜底
成功标准没有定义清楚

把所有问题都归因于 prompt，通常意味着产品还没有进入真正的系统优化阶段。

一些更接近真实世界的失败模式

AI 产品设计里，失败通常不是“完全不能用”，而是以很多细小但持续的方式侵蚀体验。

1. 表面节省时间，实际上把成本转移到后编辑

最常见的情况是：AI 5 秒生成一大段，但用户要花 10 分钟清理。这在写作、总结、表格填充、客服回复里很常见。

如果产品只统计“生成时间”，就会高估价值。真正该看的是从开始到可交付的总完成时间。

2. 输出平均可用，但关键时刻不可信

很多产品在普通样本上表现不错，一到复杂、边缘、高风险样本就失真。如果系统没有识别这些高风险输入的能力，就会把最不该出错的地方变成最危险的地方。

3. 任务边界不清，导致用户不知道该不该用它

当产品宣称“什么都能帮你做”，用户往往反而不知道从哪里开始。好的 AI 产品通常会先在一个明确任务上建立可信度，再扩展边界。

4. 检索和生成耦合得太死

在 RAG 或知识助手场景中，一个典型问题是：检索质量不好，但界面只展示最终答案。这样用户既看不到原始证据，也不知道问题到底出在检索还是生成。

更合理的做法是适度暴露中间结构，让用户知道系统基于什么回答。

5. 多轮对话带来“渐进式漂移”

单轮时还不错，多轮之后逐渐偏题、遗忘约束、混淆上下文，这是很多对话式产品都会遇到的问题。如果任务其实更适合表单、步骤化流程、结构化编辑，而不是纯聊天，就不要执着于“对话感”。

对话只是交互形式，不是产品目标。

优秀 AI 产品可以借鉴什么

这里不想把案例写成“成功学清单”，更重要的是看它们到底做对了什么。

Notion AI

核心价值：省时间 + 新能力它不是单独做一个“AI 写作网站”，而是把 AI 放进用户已经发生写作、整理、总结的地方。
真正值得学的地方：不是“它能生成文本”，而是它把 AI 变成了一个顺手的局部动作：续写、改写、整理、提炼，尽量不打断原本工作流。
设计含义： AI 在很多场景里更适合成为“嵌入式助手”，而不是把用户拉去另一个独立界面重新开始。

GitHub Copilot

核心价值：省时间它解决的不是“不会编程的人一键做软件”，而是让已有开发者在熟悉环境中更快完成局部工作。
真正值得学的地方：建议出现的时机很关键；接受和拒绝成本很低；生成结果与当前上下文强绑定。
设计含义：好的 AI 产品，往往不是让用户频繁发起请求，而是在合适时机给出足够贴近上下文的候选结果。

Perplexity

核心价值：新能力 + 少出错它不是把“聊天”和“搜索”简单相加，而是把“回答”与“证据”绑定，让用户在获取总结的同时，仍能追溯来源。
真正值得学的地方：它把“我为什么信你”设计进了界面，而不是把可信度留给品牌背书。
设计含义：在信息不确定、知识密集的场景里，来源展示不是附加功能，而是产品可信度的一部分。

这些案例的共同点

它们并不是因为“用了 AI”而成立，而是因为它们同时做对了几件事：

价值主张足够明确
AI 深度嵌入真实任务，而不是漂浮在外围
用户保留控制权
失败不会立刻让流程断掉
产品对“信任”有明确设计，而不是回避它

如何判断一个 AI 产品设计是否成熟

在真正进入实现前，或者做完一轮原型后，可以用下面这组问题自检：

价值层

这个产品到底是在省时间、少出错，还是提供新能力？
这个价值是否足够强，能抵消学习成本和不确定性？

任务层

我们服务的是一个清晰任务，还是一个模糊概念？
任务是否被合理拆解，而不是粗暴地一次生成？

交互层

用户是否知道系统能做什么、不能做什么？
用户能否方便地修正、重试、局部编辑和回退？

系统层

质量波动来自哪里？模型、检索、上下文还是流程设计？
成本、延迟、质量之间是否做过明确取舍？

信任层

用户为什么应该相信这次输出？
系统在不知道、没把握或失败时，会不会诚实地表现出来？

业务层

这个方案在真实使用频率和调用成本下，商业上是否成立？
如果用户规模扩大十倍，体验和成本会发生什么变化？

如果这些问题答不清，通常说明产品还停留在“技术能力展示”阶段。

小结

AI 产品设计的核心，不是“把模型接进来”，而是围绕真实任务重构产品：

从用户痛点出发，而不是从模型能力出发
先验证 AI 适配性，再谈大规模产品化
接受系统是概率性的，并围绕不确定性做设计
用清晰的价值主张定义产品，不贪多，不空泛
把模型、检索、交互、校验、兜底当成一个整体系统来设计
在高价值场景里，重视人机协同，而不是盲目追求全自动

一句更凝练的话是：

好的 AI 产品，不是让用户惊叹“它真聪明”，而是让用户在关键任务上，稳定地感到“它真的帮到我了”。

这也是整个系列想反复展开的主线： AI 产品不是“传统产品 + 一个模型接口”，而是一套新的产品、交互和系统设计问题。