问题不在 AI 用了多少
前几天在一个产品群里，大家聊到 AI Native 产品。这个词现在太常见了，常见到它已经开始变得不太有信息量。有人说，所谓 AI Native，就是用 AI 重新做一遍过去的 SaaS。有人问，那到底怎么判断一个产品是不是 AI Native？有人说看 AI 参与比例，有人说看架构，有人说是不是一打开 App，50% 的操作都要烧 token。
我当时的直觉是，这些说法都碰到了现象，但没有碰到根上。
AI Native 不应该用 AI 参与比例来定义。一个产品里 80% 的页面都接了模型，也可能只是一个更贵的表单系统。反过来，一个产品只有少数关键环节调用模型，但它改变了用户和产品之间的关系，也可能非常 AI Native。调用次数、token 消耗、模型链路复杂度，本质上都是实现层指标，不是产品定义。
我更愿意用一个问题来判断：AI 有没有成为产品的控制面？
所谓控制面，不是说 AI 有没有参与某个功能，也不是说界面上有没有一个聊天框，而是用户到底在操作功能，还是在委托结果。
从功能集合，到目标委托
过去的 SaaS 产品，大多是功能集合。用户的工作方式是：我知道我要达成什么结果，然后我把这个结果拆成一串操作，再在产品里找到对应功能，一个个执行。产品负责提供能力，用户负责组织能力。哪怕这个 SaaS 做得再好，本质上仍然是一个精致的工具箱。
比如做营销活动，传统产品会给你人群筛选、素材管理、投放配置、A/B 实验、数据看板、复盘报告。每个模块都可能很强，但用户仍然要自己判断先做什么、怎么组合、哪里有问题、下一步如何调整。产品提供的是功能，控制权在用户手里。
很多所谓 AI 化的产品，只是在这些功能旁边加了一个“帮我生成”按钮。帮我写标题，帮我总结数据，帮我生成一段 SQL，帮我改一版海报文案。这当然有价值，但它更像是功能增强，不一定是 AI Native。因为用户仍然在原来的工作流里，只是某些节点变快了。用户还是那个调度者，AI 只是一个局部打工人。
真正的变化发生在控制权转移的时候。
当用户不再需要明确知道每一步该点哪里，而是可以把目标交给系统，比如“帮我把这个产品的次日留存提升 10%，先从新用户激活链路找机会”，系统能够理解目标、拆解任务、调用工具、生成方案、执行实验、监控结果、发现异常、提出下一轮动作，这时候 AI 才开始成为控制面。
这时产品的核心不再是“这里有多少功能”，而是“它能不能替我承担一段目标闭环”。用户不再是在操作功能，而是在委托结果。
这也是为什么我不太认同“AI Native 等于 AI 参与比例高”。如果一个 App 里一半操作都要烧 token，但用户仍然要自己点按钮、填参数、选模板、判断下一步，那它只是一个 token 密集型 SaaS。AI 用得多，不代表产品形态变了。很多时候甚至相反，真正好的 AI Native 产品，不一定让用户感知到处处都有 AI，它应该让用户感知到“我不用再管那么细了”。
旧 SaaS 加 Copilot，不等于 AI Native
控制面这个视角也能解释，为什么“用 AI 重做 SaaS”这句话只说对了一半。
用 AI 重做 SaaS，不是把 CRM、BI、OA、客服、营销平台都塞进一个聊天框里。聊天框只是入口，不是答案。更本质的是，过去 SaaS 把企业流程模块化、表单化、权限化、报表化；AI Native 则可能把这些流程重新组织成目标驱动、上下文驱动、代理执行、持续反馈的系统。
所以不是“旧 SaaS + Copilot”，而是“任务控制权重新分配”。
拿搜索举例，传统搜索引擎已经非常强，但它的基本交互还是用户输入关键词、浏览结果、打开网页、比较信息、综合判断。控制面在用户脑子里。用户要把自己的真实问题翻译成搜索词，再从网页碎片里拼回答案。
而更 AI Native 的搜索或地图类产品，用户更可能说的是“我下周带爸妈去杭州，住在西湖附近，想安排一个不太累但有当地感的半日路线，避开太商业的地方”。系统要做的不只是检索，而是理解约束、调用地图、判断距离、结合营业时间、处理偏好冲突，最后给出可执行安排。这里的差异不是有没有 AI，而是用户有没有把“组织信息并形成决策”的控制权交出去。
这也是我觉得今天很多 AI Native 讨论容易跑偏的地方。大家很容易讨论模型、Agent、RAG、多模态、工具调用、工作流编排。这些都重要，但它们是结果，不是定义。一个产品之所以需要这些架构，是因为它要承接更复杂的委托。不是因为用了 Agent，所以它 AI Native；而是因为用户把结果委托给它，所以它不得不具备 Agent 化的能力。
产品定义要先于技术形态。
真正的门槛，是可托付
我自己更在意的是责任边界。传统软件的责任边界通常停在“我给你功能，你自己用”。AI Native 产品的责任边界会往前推一步，变成“你告诉我目标，我来组织过程”。这一步很重，因为它意味着产品要承担更多不确定性，也要承担更多结果压力。
这也是为什么“做出来”和“被使用”完全是两回事。
做一个看起来像 AI Native 的 Demo 不难。做一个用户真的愿意把工作委托出去的产品，很难。因为委托的前提不是炫技，而是信任。用户要相信它理解目标，相信它不会乱执行，相信它知道什么时候该问人，什么时候该自己做，相信它能解释关键判断，也相信它犯错时可控。
所以 AI Native 的难点不只是智能，而是可托付。
这点在企业场景里尤其明显。企业用户不是不想省事，而是不敢把控制权交出去。因为很多业务动作背后都有成本、风险、责任和组织协作。一个销售线索该不该自动跟进，一个额度策略该不该调整，一个客诉该不该升级，一个营销预算该不该重新分配，这些都不是简单生成答案的问题。AI 要成为控制面，就必须进入权限、审计、反馈、回滚、评估这些系统深处。
这可能也是为什么现在很多产品处在 SaaS 到 AI Native 的过渡期。就像从诺基亚到 iPhone，中间不会只是键盘手机换成触摸屏，而是交互范式、开发生态、分发方式、商业模式一起变化。今天 AI Native 的 SDK、工具生态、评估体系、权限模型、记忆机制、Agent 协议都还没有完全长起来，所以大量产品看起来像是旧世界长出了 AI 插件。
这不奇怪。每一次新范式刚出现的时候，最早被重做的往往都是旧产品的外壳。真正新的东西，要等底层生态、用户习惯和组织信任一起成熟，才会慢慢显形。
判断标准：看它接管哪段控制回路
但即便如此，我觉得现在已经可以有一个比较清晰的判断标准。
不要问一个产品有多少 AI 功能，而要问它替用户接管了哪一段控制回路。
它只是帮用户更快完成一个动作，还是能理解用户为什么要做这个动作？
它只是生成一个结果，还是能判断这个结果是否达成目标？
它只是响应用户指令，还是能在上下文里主动发现下一步？
它只是一个更聪明的按钮，还是一个可以被委托的系统？
这里面最关键的分水岭，是用户心智的变化。传统软件让用户想“我要点哪个功能”。AI Native 产品让用户想“我要交付什么结果”。前者是操作界面，后者是委托界面。
所以我会把 AI Native 理解成一种新的产品契约：用户交出目标，产品承担过程。
人退回到判断的位置
这不意味着用户完全不参与。恰恰相反，越重要的场景，越需要人参与关键判断。但人的角色会变化。人不再是每一步操作的执行者，而更像是目标设定者、约束提供者、关键节点审批者和最终责任人。AI 则在中间承担理解、规划、执行、反馈和迭代。
也因此，一个真正 AI Native 的产品，不一定看起来很“AI”。它可能没有夸张的聊天界面，也不一定处处生成文本。它甚至可能很安静。好的控制面往往不是不断刷存在感，而是让用户少做无意义的选择，把注意力留给真正需要人判断的地方。
这也是我现在看 AI 产品时越来越在意的一点：它到底是在增加一个新功能，还是在减少用户对功能的依赖？
如果一个产品只是把原来十个按钮变成十个 AI 按钮，它当然更快，但仍然没有跳出旧范式。如果一个产品能让用户不再关心这十个按钮，而是直接表达目标，并且系统能可靠地组织它们，那才是更深的变化。
AI Native 不是 AI 比例问题，也不是模型调用次数问题，甚至首先不是架构问题。它是产品控制权的问题，是责任边界的问题，是用户从操作功能到委托结果的问题。
这也是我愿意继续关注这件事的原因。AI 产品真正值得做的，不是让软件显得更聪明，而是让人从不必要的操作里退出来，把精力放回目标、判断和发心上。