13：AI Native 产品设计：概率系统如何提供确定体验

前面 12 篇，我们已经从底层一路走到了工程系统：

Token
↓
预测下一个 token
↓
Transformer 与 Attention
↓
训练、对齐、推理
↓
RAG、Tool Use、Agent
↓
KV Cache、成本、部署与可观测性

但当大模型真正进入产品，我们会遇到一个更棘手的问题：

模型是概率系统；
用户需要确定体验。

模型可以生成多个可能答案。

用户却想知道：

这件事能不能做？
做到什么程度？
结果可信吗？
我什么时候需要确认？
出错了能不能恢复？
我能不能撤回？
它会不会越权？

这就是 AI Native 产品设计的核心矛盾。

不是把一个聊天框塞进产品。

也不是把所有按钮都换成 prompt。

而是：

如何把一个不确定的概率生成系统，
设计成用户可以理解、控制、信任和复用的任务系统。

这篇文章就从这条线展开。

一、AI Native 不是「加一个聊天框」

很多产品第一次接入大模型时，会自然想到一个方案：

加一个 AI 聊天入口。

用户输入问题，模型输出回答。

这当然有价值。

但这还不一定是 AI Native。

因为聊天框只是交互形式，不是产品范式。

从第一性原理看，一个产品是不是 AI Native，不取决于它有没有聊天界面，而取决于 AI 是否改变了产品完成任务的方式。

传统软件通常是：

用户理解界面
↓
用户拆解任务
↓
用户点击功能
↓
系统执行确定规则
↓
用户检查结果

AI Native 产品更接近：

用户表达目标
↓
系统理解意图
↓
系统组装上下文
↓
模型生成候选方案
↓
工具或工作流执行
↓
系统验证结果
↓
用户确认、修正或接管

注意这里的变化。

用户不再只是在功能之间导航。

用户开始把「目标」交给系统。

系统也不再只是响应按钮点击。

系统开始参与任务拆解、上下文整理、方案生成、动作执行和结果校验。

所以 AI Native 的关键不是：

有没有 AI 输入框。

而是：

产品的基本单位，是否从功能操作变成了目标任务。

这会改变产品设计的几乎所有问题。

二、第一性原理：概率核心，确定外壳

大模型的底层，是根据上下文预测下一个 token 的概率分布。

这意味着它天然不是传统意义上的确定性函数。

同一个输入，在不同温度、不同上下文、不同模型版本下，可能产生不同输出。

这不是 bug。

这是生成式模型的基本性质。

但产品不能把这种不确定性原封不动地丢给用户。

用户不关心模型内部有多少可能路径。

用户关心的是：

我能不能放心把这一步交给你？

所以 AI Native 产品的第一性原理可以这样说：

模型负责生成可能性；
产品负责定义边界、控制风险、验证结果和交付确定体验。

也可以更短：

概率核心，确定外壳。

这里的「确定外壳」不是假装模型永远正确。

而是产品要明确回答几个问题：

能力边界：系统能做什么，不能做什么；
输入边界：用户需要提供什么，系统会补充什么上下文；
输出边界：结果以什么格式出现，是否可编辑；
证据边界：哪些结论有来源，哪些只是建议；
动作边界：哪些动作可以自动执行，哪些必须确认；
责任边界：出错时系统如何解释、撤销和恢复。

如果这些边界不清楚，AI 产品会让人焦虑。

用户不知道它会不会乱做。

也不知道什么时候该相信它。

更不知道失败后应该怎么补救。

所以一个 AI Native 产品，首先不是一个「更聪明的输入框」。

它是一份产品契约：

我可以帮你完成哪些任务；
我会使用哪些上下文；
我会在哪些步骤请求确认；
我会如何展示证据和不确定性；
我会如何让你修改、撤回和接管。

这份契约越清楚，用户越敢把任务交给系统。

三、从命令到意图：用户不想写 prompt，用户想完成事

传统软件里的用户输入，通常是命令式的。

比如：

点击「导出」；
选择「PDF」；
筛选「过去 30 天」；
把表格按销售额排序。

用户需要知道功能在哪里，也需要知道自己要怎么操作。

大模型带来的变化是，用户可以直接表达意图：

帮我整理一下这个月销售异常的原因；
把这份会议纪要变成一封给客户的邮件；
找出这些用户反馈里最值得优先修的问题；
根据这个 PRD 生成一个可执行的开发任务拆分。

这看起来像 prompt。

但从产品视角看，它其实不是 prompt。

它是任务意图。

用户真正想要的不是「写出完美提示词」。

用户想要的是：

系统理解我要完成什么，
并帮我把模糊目标变成可执行步骤。

因此，AI Native 产品不能把 prompt 写作能力当成用户门槛。

好的产品应该帮助用户完成三件事：

表达目标；
澄清约束；
补全缺失信息。

比如用户说：

帮我写一份增长分析。

系统不应该立刻生成一篇看起来很完整、但不知道基于什么数据的报告。

它应该先判断缺什么：

分析哪个产品？
时间范围是什么？
核心指标是什么？
和哪个周期对比？
要给谁看？
需要结论优先，还是过程详细？
是否允许读取业务数据？

这里的产品设计重点，不是让模型多问几个问题。

而是把「模糊意图」转成「可执行任务规格」：

目标
输入
约束
数据源
输出格式
验收标准
执行权限

这就是 AI Native 产品和普通聊天机器人的区别。

普通聊天机器人回答用户的一句话。

AI Native 产品要把用户的一句话，变成可以推进的任务。

四、上下文就是界面：模型看见什么，产品就是什么

在传统软件里，界面主要由按钮、表单、菜单、页面和状态组成。

在 AI Native 产品里，还有一个新的界面层：

上下文。

用户看见的是一个输入框。

模型真正看见的可能是：

系统提示词；
当前页面内容；
用户选中的文本；
上传文件；
历史对话摘要；
用户偏好；
组织知识库；
检索证据；
工具返回结果；
权限和安全规则。

所以对 AI 产品来说，设计界面不只是设计用户看见什么。

还要设计模型看见什么。

这件事非常关键。

因为同一个模型，在不同上下文下会变成完全不同的产品。

如果上下文只有用户一句话，它像通用聊天机器人。

如果上下文包含当前文档、评论、修订记录和写作目标，它像写作助手。

如果上下文包含客户资料、合同、历史工单和权限规则，它像客户成功助手。

如果上下文包含代码仓库、测试结果、issue 和部署日志，它像工程 Agent。

所以 AI Native 产品设计要回答：

哪些上下文应该自动带入？
哪些上下文需要用户显式选择？
哪些上下文不应该被模型看到？
上下文太长时如何摘要、裁剪和排序？
哪些证据需要展示给用户？
哪些记忆可以长期保存？
用户如何查看、修改和删除这些记忆？

这里有一个重要原则：

上下文自动化越强，权限和可解释性越重要。

如果系统悄悄读取很多信息，用户会不安。

如果系统完全不读取上下文，模型又会答得很空。

好的设计要在中间建立信任：

告诉用户使用了哪些信息；
允许用户增删上下文；
在关键结论旁边展示来源；
在敏感数据进入模型前做权限检查；
让用户知道记忆是否会被保存。

上下文不是后台细节。

上下文是 AI 产品的第二界面。

五、控制权设计：自动化不是越多越好

AI Native 产品很容易陷入一个诱惑：

既然模型能做更多事，那就尽量让它自动做。

但真实产品里，自动化不是越多越好。

自动化越强，用户对控制权的要求也越高。

尤其是当系统可以调用工具、修改数据、发送消息、创建订单、发布内容、操作代码或影响金钱时，产品必须设计清楚：

哪些动作可以直接做；
哪些动作要先预览；
哪些动作必须确认；
哪些动作需要审批；
哪些动作永远不能自动做。

可以把 AI 自动化分成五级：

这张表的重点不是分级本身。

重点是：产品要让用户知道自己在哪一级。

用户最害怕的不是 AI 不能自动化。

用户最害怕的是不知道 AI 会不会突然越权。

所以控制权设计至少要包括：

预览：执行前看见将要发生什么；
确认：关键动作必须得到授权；
撤销：执行后可以回滚；
暂停：长任务可以随时停下；
接管：用户可以从 AI 手里拿回控制；
审计：事后能看见系统做了什么；
权限：不同用户、任务、数据有不同边界。

AI 产品的高级感，不来自「全自动」。

而来自：

系统知道什么时候该自动，
也知道什么时候应该停下来等人。

六、可靠性不是模型属性，而是系统属性

很多人会把 AI 产品的可靠性等同于模型能力。

模型越强，产品越可靠。

这只对了一部分。

更准确地说：

模型能力决定上限；
系统设计决定可用性。

一个强模型，如果上下文混乱、权限不清、输出没有校验、工具失败不处理，也会做出不可靠的产品。

一个没那么强的模型，如果任务边界清楚、上下文干净、输出结构化、动作可验证，也能在特定场景里非常好用。

从产品系统看，可靠性至少来自七层：

任务边界：只承诺适合 AI 做的任务；
上下文质量：给模型正确、足够、不过量的信息；
结构化输出：让结果能被程序检查和后续处理；
证据约束：重要结论尽量绑定来源；
工具验证：用确定性系统检查事实、格式和状态；
失败回退：低置信度、超时、工具失败时有备用路径；
持续评估：用真实任务样本不断测试和监控。

这也是为什么 AI Native 产品设计必须和工程设计绑在一起。

例如，一个合同审阅助手不能只靠模型说「这条有风险」。

它还需要：

标出原文位置；
说明风险类型；
引用内部政策或历史模板；
给出可编辑修改建议；
区分确定问题和可能问题；
允许法务确认；
记录最终采纳情况。

又比如，一个数据分析助手不能只生成漂亮结论。

它还需要：

展示 SQL 或查询逻辑；
说明数据时间范围；
标出缺失数据；
区分事实、推断和建议；
让用户能追溯图表来源；
在指标异常时给出置信边界。

可靠性不是让模型永远不犯错。

可靠性是：

让错误更少发生；
让错误更容易被发现；
让错误发生后更容易恢复。

七、界面形态：聊天只是其中一种

因为 ChatGPT 太成功，很多人会默认 AI 产品就应该长成聊天界面。

但聊天并不是唯一形态。

更重要的是，不同任务适合不同界面。

1. 对话：适合探索和澄清

对话适合：

需求还不清楚；
用户需要逐步表达；
系统需要反问；
答案可以通过自然语言消费。

比如咨询、解释、头脑风暴、学习和轻量分析。

2. Copilot：适合在现有工作流里增强

侧边栏、浮层、快捷操作和内联建议，适合用户已经在做某件事。

比如：

在文档里润色一段话；
在代码里解释一个函数；
在 CRM 里总结客户状态；
在表格里生成一个公式。

用户不需要离开当前上下文。

AI 只是把当前工作流变快。

3. 画布：适合复杂内容的共创

当任务产物很长、结构复杂、需要反复编辑时，纯聊天会变得低效。

这时画布更合适。

比如：

写报告；
做方案；
改网页；
设计流程图；
生成数据仪表盘。

聊天负责意图和反馈，画布负责承载产物。

4. 工作流 / Agent：适合多步骤任务

当任务需要读取数据、调用工具、等待结果、重试、审批和交付时，界面就不能只是对话。

它需要展示：

计划；
步骤；
状态；
中间结果；
失败原因；
下一步动作；
用户待确认事项。

这更像任务控制台，而不是聊天窗口。

所以界面选择的第一原则不是「哪种最 AI」。

而是：

用户要完成的任务，需要什么样的可见性、可编辑性和控制权。

八、反馈闭环：AI 产品要从真实任务中学习

传统产品也需要数据分析。

但 AI 产品的反馈闭环更重要。

原因是，AI 产品的问题经常不是「功能有没有被点击」。

而是：

模型有没有正确理解任务；
上下文有没有组装对；
输出有没有被用户采纳；
工具调用有没有成功；
用户是不是需要大量修改；
哪类任务经常失败；
哪些失败来自模型，哪些失败来自产品流程。

所以 AI Native 产品不能只看普通指标：

DAU；
留存；
点击率；
会话数。

还要看任务级指标：

任务完成率；
输出采纳率；
用户修改率；
重新生成率；
人工接管率；
确认后撤销率；
每个成功任务成本；
从目标到交付的耗时；
失败原因分布；
高风险动作拦截率。

这些指标能帮助团队判断：

是模型不够强？
是上下文不够好？
是工具太慢？
是任务边界太宽？
是用户不知道怎么控制？
还是产品没有给出足够的证据？

更进一步，真实任务反馈应该进入评估集。

也就是说，AI 产品要把线上失败沉淀成离线测试：

收集失败样本；
标注期望结果；
复现上下文；
测试不同模型、prompt、检索和工具策略；
把修复后的案例纳入回归评估。

这会让 AI 产品从「凭感觉调 prompt」走向「基于任务样本迭代系统」。

AI 产品的迭代对象不只是界面。

还包括：

模型选择；
提示词；
上下文组装；
工具 schema；
检索策略；
确认流程；
失败回退；
评估样本。

这也是 AI Native 产品团队和传统产品团队很不一样的地方。

他们不是只优化漏斗。

他们还要优化一个会生成、会行动、会失败、会被评估的智能系统。

九、常见误解

误解 1：AI Native 就是聊天框

聊天框只是输入方式。

AI Native 的本质，是产品从功能操作转向目标任务。

如果 AI 不能访问上下文、不能参与工作流、不能交付任务结果，那它更像一个嵌入式问答入口，而不是产品范式变化。

误解 2：模型足够强，产品设计就不重要了

模型越强，能做的事越多。

但能做的事越多，边界、权限、控制权、验证和失败恢复就越重要。

强模型不会自动带来好体验。

强模型只会让产品设计问题变得更大。

误解 3：不确定性应该被完全隐藏

用户不一定需要看见模型概率。

但用户需要知道哪些结果是确定事实，哪些是推断建议，哪些需要自己确认。

好的产品不是隐藏不确定性。

而是把不确定性转成合适的提示、证据、确认和回退。

误解 4：用户都想要全自动

用户想要的不是全自动。

用户想要的是少操心但不失控。

在低风险、可回滚、重复性强的任务上，自动化很有价值。

在高风险、不可逆、责任重的任务上，确认、预览和审批更重要。

误解 5：Prompt 就是产品规格

Prompt 很重要，但它不是完整产品规格。

一个 AI 产品还需要上下文策略、工具协议、权限规则、输出结构、评估样本、监控指标和失败处理。

只把 prompt 当产品，最后往往会得到一个难以稳定复用的 demo。

十、产品和工程含义：AI Native 产品栈

如果把这一篇浓缩成一个产品栈，AI Native 产品大致可以拆成六层：

体验层：目标表达、预览、编辑、确认、撤销、接管
编排层：任务拆解、计划、状态、工作流、Agent 循环
上下文层：文件、记忆、RAG、用户偏好、业务数据、权限
工具层：API、数据库、搜索、代码执行、消息发送、审批系统
模型层：模型选择、路由、prompt、结构化输出、成本控制
治理层：安全、审计、评估、监控、日志、合规和回退

传统软件当然也有体验层、数据层和业务逻辑。

但 AI Native 产品多了几个关键变化：

任务不再完全由用户拆解；
界面不再只是用户可见界面，还包括模型上下文；
输出不再天然确定，需要验证和证据；
动作不再只是按钮触发，还可能由模型规划；
失败不再只是接口报错，还可能是理解错、检索错、工具错、判断错；
评估不再只是功能测试，还要覆盖真实任务样本。

所以产品经理、设计师和工程师都要问新的问题。

产品经理要问：

用户愿意把哪类目标交给系统？
哪些任务值得 AI 参与？
成功标准是什么？
哪些失败可以接受，哪些不能？
什么时候需要人确认？

设计师要问：

用户如何表达意图？
系统如何展示上下文和证据？
用户如何预览、编辑、确认、撤销和接管？
不确定性应该如何被呈现？
长任务如何展示进度？

工程师要问：

上下文如何组装？
工具如何被安全调用？
输出如何结构化和校验？
如何做模型路由和降级？
如何记录任务轨迹？
如何评估线上效果？
如何控制每个成功任务的成本？

这些问题合在一起，才是 AI Native 产品设计。

十一、一句话总结

AI Native 产品设计，不是给软件加一个会聊天的入口。

而是把大模型这个概率生成系统，放进一套有边界、有上下文、有控制权、有验证、有反馈闭环的产品系统里，让用户可以把目标交给它，并在关键时刻理解、确认和接管。

一句话：

AI Native 产品的本质，是把概率能力设计成确定体验。

下一篇，我们会继续往商业层走：当 AI 产品不再只是卖软件席位，而是越来越接近「交付结果」，SaaS 的商业模式、定价方式和组织边界会发生什么变化？