第 35 篇 AI Native 应用从零设计 AI 优先的产品小系列〔产品形态进阶〕第 2 篇 · 定位不是给旧产品加功能而是从零设计 AI 优先的产品衔接《第 02 篇八步落地》的先定义好与《第 11 篇交互设计》的信任设计。一、AI Native 的定义与识别信号AI Native 不是产品里加了 AI 按钮而是拿掉 AI产品就不存在。它的价值主干由模型能力生成而非模型只是既有流程的加速器。区别这一点先要能识别信号——哪些是天然 AI Native哪些只是套壳。信号天然 AI Native套壳传统产品AI 点缀核心价值来源价值由生成/理解/推理产生价值由确定性功能产生AI 只做润色拿掉模型产品失去存在的意义产品照常运作只是少了辅助交互主体自然语言/意图驱动为主表单、按钮、菜单为主输出形态非结构化、千人千面固定页面、固定字段失败处理概率性错误是一等设计对象错误按传统异常分支处理套壳的典型样子是一个本来点三下就能完成的 CRUD 工具加了个AI 助手浮窗本质没变。判断方法很直接——问一句这个产品十年前没有大模型能做吗。能做就多半不是 AI Native只是借了 AI 的皮。这不是贬低套壳很多套壳商业上很成功但它决定了你该用哪套方法论套壳用旧产品加功能的流程AI Native 要用从任务反推架构的流程。还有一个判别维度常被忽略AI Native 的原生性体现在它是否把概率性当产品的一等公民。套壳产品把模型输出当成确定性功能的补充错了就走传统异常处理真正 Native 的产品从第一天就把可能错、可能多样、可能要人把关设计进核心流程——例如输出天然带置信度、带来源、带可编辑层。你可以用一句话测试团队认知“如果模型明天开始有 5% 概率答错我们的产品会崩吗“套壳团队答会所以我们要压到零”Native 团队答不会因为那 5% 本来就在设计里被兜住”。后者才是真 Native前者只是借了 AI 的皮。二、从用户任务反推架构而非堆功能清单传统 SaaS 的起手式是功能清单列我们要做哪些模块。AI Native 不能这么起手因为模型能力是连续的、非模块化的硬切成功能清单会切碎它最值钱的部分。正确推导链是任务 → 能力 → 数据 → 模型 → 交互。推导步骤要回答的问题产物任务用户到底要完成什么结果不是要什么功能任务陈述可观测的结果能力完成它需哪些 AI 能力生成/检索/推理/多模态能力清单与边界数据这些能力靠什么数据喂、私域还是公域、质量如何数据需求与治理要求模型能力由哪类模型承担、自研还是调用、成本结构模型选型与成本公式交互用户如何表达意图、如何纠错、如何接管交互范式与兜底界面这一步衔接《第 02 篇八步落地》的先定义好在写任何代码前把任务钉死。一个常见翻车是反过来——先定了我们要用 Agent、要用 RAG再去想能做什么任务结果做出来的东西功能很酷但没人需要。任务在前技术在后是 AI Native 立项的第一条纪律。反推链里最易跳步的是数据和模型两环被合并。很多团队直接想调个大模型就行忽略了数据才是 AI Native 的分水岭同样的能力喂公域通用数据只能做平庸的通用品喂私域专有数据才能做出别人抄不走的差异化。所以数据要单独成环明确私域数据从哪来、质量怎么保证、用户愿不愿意给。模型环则要算清成本公式——单次服务成本 输入 token × 输入单价 输出 token × 输出单价 × 步数Agent 场景这一步直接决定毛利天花板很多 AI Native 死在演示惊艳、一算账亏。把成本公式写进立项画布是避免盲目上马的最便宜动作也是和老板谈商业化时最硬的底牌。反推链还有一个常见失败模式叫能力先行团队先被某个模型新能力如刚出的某多模态接口兴奋反过来编造一个任务去适配它。这种技术 push做出来的产品任务往往是伪需求——用户并没有这个待完成的结果只是被能力带着走。破法是回到任务陈述的可观测性如果写不出用户完成后的可观测结果是什么就说明任务没成立能力再炫也先搁置。立项画布里任务一栏必须填具体结果填不出就退回这是反推链纪律里最硬的一条能挡掉大多数为技术找场景的伪项目。产品方法论的意义恰恰在于让技术服务于真问题而不是让真问题去迁就技术的新鲜感。三、容错即设计假设 AI 会错产品要兜住AI Native 建筑在概率性系统上错是常态不是异常。呼应《第 11 篇交互设计》的信任设计用户信任的不是AI 永远对而是错了我能很快发现、很快纠正、代价很小。把容错当成功能的一环而不是上线后的补丁。错误类型产品兜底方式事实性错误幻觉给出可点击的来源与引用关键结论强制带证据意图误解执行前复述理解、低价动作可预览、高价动作须确认格式/结构错结构化输出契约 解析失败自动重试/降级价值观/合规越界前置护栏 越界即拦截并解释不进入主链路能力边界外明确这事我做不了并转人工或给替代路径容错设计的四条原则可验证让结论带证据用户能自己核对、可回退任何 AI 动作可一键撤销、可定位错了要知道错在哪一步便于复盘、可纠给用户低成本纠错入口且纠错回流成改进数据。最危险的是假装没错——把低置信结果当成高置信展示用户一旦被坑一次信任归零且难重建。容错设计的落地还要分事前、事中、事后三道关。事前是护栏与约束把明显越界在生成前挡掉事中是过程可见让用户在执行中就能发现不对并打断事后是纠错与回流用户改完的错误变成下次的评测与训练样本。三道关里最贵的是事后——一旦错结果已经落到用户真实业务里发出去的邮件、写进的文档挽回成本远高于前两关。所以容错要前移能用事前约束解决的绝不拖到事后。这也解释了为什么 AI Native 要把可验证放在容错四原则之首——带证据的输出让错误在传播链路最前端就被用户抓住而不是等污染扩散到下游才暴露那时代价已是乘法级的。四、人机协作新范式用户角色变了AI Native 把用户从操作者变成审核者/指挥者。过去用户一步步点按钮完成流程现在用户下指令、AI 执行、用户把关。角色变化要求产品重新设计交互语言。从操作者到指挥者用户表达意图而非执行步骤产品要把意图翻译成动作链并透明展示。从精确输入到自然语言交互语言从填表单变成说需求但要让用户能逐步收敛多轮、追问、约束追加。从结果消费到过程监督用户在关键节点介入产品要暴露AI 现在在想什么、做到哪了。新鸿沟自然语言门槛。不是所有人会问对问题产品要提供模板、示例提示、渐进引导降低表达意图的成本。这个范式转移解释了为什么很多 AI Native 产品演示惊艳、日常不用——它假设用户已经是合格的指挥者但多数用户还停留在操作者习惯里。填平这道沟是 AI Native 留存的关键工程。新交互语言还带来提示工程的下放问题。过去写 prompt 是工程师的事AI Native 把怎么问的部分责任转嫁给用户。产品不能假设用户会写提示要提供意图脚手架把常见任务做成可点选的模板、把复杂需求拆成可填的槽位、把模糊说法用追问收敛成精确指令。更进一步产品可以代写提示——用户用大白话描述系统把它重写成模型更易执行的精准指令再把重写结果展示给用户确认。这层人机之间的翻译本身就是 AI Native 的核心能力值得作为一等功能投入而不是让用户裸奔去和模型对话。把表达意图的成本压到最低才谈得上人人都是指挥者。指挥者范式还有个组织副作用支持成本上升。当用户用自然语言下指令客服收到的不再是按钮点不出来的确定问题而是它没理解我的意思的模糊问题排障难度更高。产品要前置降低这种模糊——在用户提交指令前做意图预览“我理解你要做的是……对吗”把模糊在产生前收敛。同时新手和专家要分两条引导路径新手给模板与示例任务专家给自由指令与快捷命令。把用户会不会下指令当成独立的产品模块来设计而不是默认用户天生会指挥是 AI Native 能否规模化的隐藏变量很多团队栽在这里却归结为模型不够强。意图表达是能力不是天赋需要产品去教、去托底而非假设它天然存在。五、冷启动与增长特殊性AI Native 的增长曲线和传统 SaaS 不同呼应《第 30 篇增长与留存》的框架但有自己的特殊性。阶段特殊性产品动作获客靠演示传播wow 时刻易裂变但点击≠留存让首次价值可截图、可分享首体验用户不会下指令需要脚手架给示例任务、模板提示、渐进引导冷启动个性化数据少初期效果平庸用公域能力兜底私域数据逐步积累留存novelty 消退快靠持续价值而非新鲜把个性化数据做成飞轮越用越准扩展网络效应弱靠个体价值深化从单任务扩到工作流提升迁移成本关键提醒AI Native 的首体验和留存最容易脱节。演示能拉来海量试用但用户若卡在不会问或第一次结果一般次日留存会很惨。冷启动期要容忍效果不完美用公域通用能力先托住体验再靠私域数据慢慢拉开差距。数据飞轮用户纠正→模型/记忆变好→用户更满意是 AI Native 少数真正的护城河。冷启动还有个隐蔽陷阱叫首因效应用户第一次用的结果质量基本决定了他留不留。但冷启动期恰好是私域数据最薄、效果最平的时期于是很多产品卡在第一次不好、走了、永远没机会变好的死循环。破法有三种一是用公域强能力先把首次体验托到及格线以上私域只做加分二是设计低门槛高确定的首次任务如一个几乎不会错的总结让用户先建立它靠谱的印象再逐步开放高风险能力三是把首次价值做成可分享物一张图、一段可转发的结果借首因效应反哺获客而不是只闷在账户里。冷启动的本质是用体验托底换数据积累的时间数据厚了飞轮才转得起来。六、案例拆解框架拿到一个 AI Native 产品怎么分析面对一个 AI Native 产品不要只看界面要沿下面框架拆它的地基。拆解维度关键问题任务定义它声称帮用户完成什么结果可观测吗能力架构用了哪些 AI 能力如何组合RAG/Agent/多模态数据闭环私域数据从哪来、怎么积累、是否形成飞轮容错设计错了怎么兜底用户能否发现并纠正交互范式用户是指挥者还是操作者表达意图成本多高评测体系它怎么知道自己变好没有无可量化指标成本结构单次服务成本公式毛利是否被长任务吞噬增长机制靠演示还是靠留存护城河是数据还是网络这套框架的价值是把好不好用的模糊感受拆成八个可独立判断的零件。一个产品可能交互惊艳但无数据飞轮另一个可能粗糙但成本结构极佳——框架让你看清它强在哪、脆在哪而不是被演示带着走。拆解时别被技术名词带偏。很多产品爱标榜我们用了多 Agent、用了图检索但框架里能力架构这一维要看的是这些能力是否真的服务那个任务而不是堆技术。一个用多 Agent 却任务只需单 Agent 的产品在架构差异一维上反而扣分——它复杂度虚高、成本虚高、可控性更差。同样“评测体系一维若答不出我们怎么知道自己变好没”无论交互多炫都不合格因为 AI Native 的效果会漂移没有持续评测等于盲飞。框架的八个维度是相互印证的短板会拉垮长板所以拆解结论应是最短板决定上限而非最长板决定估值。看产品要看木桶不是看最高的那块板。架构差异还有一点对可解释性的要求不同。传统 SaaS 的逻辑是确定的出了问题能逐行 debug 到确切原因AI Native 的输出由概率过程生成同一输入多次可能不同出错了很难复现。这要求产品层额外设计溯源每次产出附带用了哪些数据、走了哪些能力、模型与 prompt 版本让错误可事后追因而不是面对一句模型抽风了束手无策。可解释不是模型的事是产品要给用户的承诺——尤其在出错成本高、需审计的场景溯源链是上线的前置条件没有它再强的模型也不敢接进关键业务。把不可复现的概率系统变得可追因是 AI Native 相对于黑箱模型最该补的工程闭环也是合规与信任的共同底座。七、与传统 SaaS 的架构差异AI Native 不是 SaaS 加 AI底层架构有几处根本不同产品经理必须懂才能和工程对齐。维度传统 SaaSAI Native状态确定性状态机输入定输出概率性同输入可能异输出不确定性当作 bug 消灭当作一等公民产品层兜住评测功能测试通过后即上线评测集是持续资产上线后也要测成本算力成本可忽略单次成本随模型调用累积须计入毛利数据数据是记录数据是能力来源与护城河可解释逻辑可追溯需额外设计溯源与证据链最重要的差异是评测作为一等公民。传统产品测一次功能就完了AI Native 的模型会随版本、随数据漂移效果可能悄悄变差而界面毫无变化。所以评测集含真实用户轨迹必须和产品代码同生命周期维护上线后持续跑指标异常即告警。把评测当临时任务是 AI Native 上线后用着用着就傻了的根源。架构差异还带来组织层面的含义AI Native 团队不能沿用纯 SaaS 的研发节奏。SaaS 的需求—开发—测试—发版里测试是上线前关门AI Native 要把评测变成上线后永不开门的常态化动作因为模型、数据、用户行为都在变昨天的达标今天可能不达标。这意味着团队要常设评测与数据角色持续维护评测集、盯指标漂移、把线上失败回流成新用例。把这部分当临时项目产品会在无人察觉中缓慢劣化——用户不会投诉你变傻了只是悄悄流失。这点是 AI Native 和传统 SaaS 在怎么养一个产品上最根本的不同也解释了为什么很多团队能做出惊艳 DEMO却养不出长久好用的产品。AI Native 产品立项画布AI Native 产品立项画布填写后用于立项评审 ───────────────────────────────────── [问题] 用户要完成的结果是什么非功能可观测 示例把一段会议录音变成可执行的决策清单 [任务] 该结果拆成哪些子任务哪些必须 AI 能力 任务陈述________________ 非 AI 可替代部分________________ [能力] 需要哪些 AI 能力生成/检索/推理/多模态及边界 能力清单________________ 明确不做________________ [数据] 喂能力的数据源私域/公域质量与治理要求 数据源________________ 飞轮机制________________ [模型] 自研/调用成本公式输入×单价输出×单价×步数 选型________________ 单次成本上限________________ [容错] 五类错误幻觉/误解/格式/越界/超界各自兜底方式 可验证____ 可回退____ 可定位____ 可纠____ [交互] 用户是指挥者还是操作者意图表达成本如何降低 脚手架________________ 过程可见性________________ [指标] 价值指标非 vanity与 holdout 对照方式 核心指标________________ 评测集维护责任________________一页速查AI Native 应用 · 一页速查 ───────────────────────────── 识别拿掉模型产品是否还存在是→Native否→套壳(用旧方法论) 反推链任务→能力→数据→模型→交互任务在前技术在后 任务要钉死可观测结果别从要用Agent/RAG反推需求 容错四原则可验证(带证据)|可回退(一键撤)|可定位(知错步)|可纠(低门槛) 五类错幻觉(给源)|误解(执行前复述)|格式(契约重试)|越界(前置护栏)|超界(转人工) 角色变化操作者→指挥者填表单→说意图结果消费→过程监督 新沟用户不会问对问题要模板/示例/渐进引导 冷启动演示拉试用、首体验卡不会问用公域能力托底私域做飞轮 增长护城河在数据飞轮与迁移成本不在网络效应 拆解八维任务|能力|数据|容错|交互|评测|成本|增长 架构差异状态概率/不确定性一等公民/评测即资产/成本入毛利/数据即壁垒 纪律评测集与代码同生命周期错当常态不当异常别假装没错。常见坑把套壳当 AI Native用加 AI 按钮的思路做错失从任务反推架构的机会。先定技术要用 Agent/RAG再找任务做出炫技但无人要的东西。任务没钉成可观测结果需求飘在智能化提效等空话上。假装 AI 不会错低置信结果当高置信展示信任一次归零难重建。错了无法定位到步骤用户只知道它傻了却无从纠错和反馈。假设用户已是合格指挥者无脚手架无示例提示首体验卡在不会问。冷启动期私域数据空又无公域能力托底首次体验平庸致留存崩。成本不计入毛利长任务多步调用累积吞噬利润规模越大越亏。评测当临时任务上线后模型漂移无人持续测用着用着悄悄变傻。只追演示 wow 与曝光无 holdout 对照价值增长靠 novelty 不靠留存。结语AI Native 不是给旧房子装智能门锁而是按人会犯错、价值由生成而来重新打地基——地基里最硬的那根是把容错和评测当一等公民。本文为「AI 产品经理入门与进阶」系列第三季·小系列〔产品形态进阶〕第 2 篇总第 35 篇。数据来源本篇识别信号表、反推链表、容错表、案例拆解框架、架构差异表与立项画布均为可操作框架示例数值已标注示例数据非真实业务。具体数值单次服务成本、留存基线、评测集规模等随技术迭代与业务差异变化请以最新数据为准。