用三个问题判断，你的产品算不算 AI Native

拿掉 AI 之后，你的产品是少了一个按钮，还是主流程直接走不通？

这半年，我一直在做一个内部产品，用户是运营和业务同事：有明确业务目标，但不会开发。

他们要不停地产出各种页面。这次是活动宣传页，下次是课程内容页，再下次是报名页。看着都叫「页面」，实际差别很大：交互不一样，要接的业务数据也不一样，宣传页要接活动库存和报名状态，内容页要接课程目录和进度。人手就那么多，需求却一个接一个。

传统工具的解法是把这些差异做成功能、表单和配置项，稳定，但越用越重，用户还得先学会这套配置。另一种解法是接大模型，说一句话直接生成一个页面，灵活，可一旦要求「这块按我们的规范改」「这里接真实的报名数据」，它就只在演示里成立。

我要的其实很简单：让用户带着自己的业务判断，跟 AI 一起把原来得找开发才能做的事做完。

先重定义交付结果，再谈 AI

传统工具交付的是操作能力：选功能、填信息、调细节。可用户真正要的，是一个符合目标、满足规范、能交付的结果。

Des Traynor 提出，Jobs to be Done 要放到完整流程层去看，别停在功能层。原文 放进我的产品里，用户真正在做的一件事，是把一句模糊的活动需求，变成能挂上线、接得上数据、符合规范的页面。澄清需求、选方案、生成初稿、调整、检查、交付，在他眼里本来就是一件事。

投资机构对 AI-native 的定义更宽，强调 AI 应在应用体验的核心而非外围辅助。评估框架 我把它收紧成一句能当场检验的话：

拿掉 AI，产品只是少了一个辅助按钮，那是 AI-enabled；拿掉 AI，用户就很难完成核心流程，才更接近 AI Native。

这只是个诊断标准，不分高下。很多优秀产品就该停在 AI-enabled。但你要是奔着后者去，就得认下这件事：AI 不能只待在侧边栏。它得从任务一开始就参与，弄清目标、背景和约束，中途跟着干，产物出了问题还得接着修。

别把 Context 当附件，它是基础设施

AI 一进主流程，问题立刻出现：它不知道现场发生了什么。

用户选中一个对象说「把这里调一下」，AI 不知道「这里」是什么。用户刚确认过一套要求，又得复制进对话框。检查报错了，还要把错误搬进去，再把答案搬回来。

人变成了上下文搬运工。

成熟工具早就不这么干了。某编程助手会看着项目状态，自动把相关文件、终端输出和规则塞进上下文。官方说明 某设计工具也说得很直白：设计上下文是用户、业务、设计系统、技术约束这一堆层次叠起来的东西，一条提示词根本装不下。资料库文章

所以我把 Context 当成产品基础设施：产品要把用户目标、当前阶段、正在处理的对象、工作规则、可用材料、历史决策、检查结果和版本差异，组织成 AI 能理解的任务现场。

但塞得越多也不见得越好。给少了，AI 靠猜；给多了，重点被噪声淹掉；信息还会过期，还有权限管着。怎么选、怎么压、什么时候更新、改了能不能追溯，这是 AI Native 产品要一直折腾的事。

让工作空间成为 AI 能感知的环境

我的做法是把整个工作空间开放给 AI。

任务开始时，系统整理目标、参考和限制条件。进入工作区后，用户选中某个对象，系统就把对象及相关信息带进对话，AI 自然知道「这里」是什么。任务推进时上下文跟着变：前期关注目标和参考，中期关注产物和约束，后期关注检查、版本与交付状态。

讨论、方案、产物、验收、交付，在传统产品里被拆成几个模块。对 Agent 来说，这应该是一条连着的任务链。

所以「产品向 AI 开放」，光给几个 API 是不够的。真正要开放的，是工作对象、过程状态和历史产物，让 AI 能准确引用到它们。

能看见还不够，AI 还要能行动

光让 AI 读懂现场还不够。它要是只能给建议，用户还得自己把建议一步步点出来，那它就还是个顾问。

某模型厂商把 Agent 概括为能代表用户完成任务的系统，由模型、工具和指令组成：模型推理，工具行动，指令定义规则和边界。实践指南

落到产品里，要回答的是：AI 能读什么、改什么、调用哪些能力、如何判断完成、越界时谁拦住。在授权范围内，Agent 应该能修改真实产物、调用产品已有能力，并把结果写回工作空间。

聊天框只是 AI 的嘴。Context 是眼睛和记忆，工具是手，业务规则决定这双手能伸到哪里。

这里容易误读一点：给 AI 行动能力，不等于让它去点界面。我在《对 Agent 操作 GUI 说不》里写过，GUI 是给人用的慢接口，该开放的是底层能力。光把能力接口丢过去也不行，Agent 还得知道什么时候用、按什么规矩用，这正是 Skill 比单纯工具接口多出来的东西。

业务逻辑该不该都交给 AI

现在流行一种说法：业务逻辑会整体迁到 AI 层，后端退化成随时可换的数据库。我不太同意，准确说，这个判断漏了一个前提。

AI 该不该进业务逻辑，得看这段流程本身是什么性质。

路径固定、要求每次都一样的流程，纯代码跑又快又稳，塞给模型等于花钱买不确定。格式校验、权限控制、资源可用性、交付前检查，这些都有标准答案，让模型凭感觉判断，贵还不靠谱。

真正难办的是那些量大又多变的长尾需求，你不可能把它们一条条穷举成分支和配置项。这时候才轮到 AI 进业务逻辑，让它当调度员：听懂需求、挑合适的能力、在各个业务节点之间把活转起来。

另一家模型厂商分 workflow 和 agent，讲的是同一件事：路子明确的任务交给 workflow，得临场判断的开放任务才交给 agent。工程博客

这跟我在《给产品装了个 AI 入口》里的判断是一回事：高频固定的走界面和代码，长尾多变的走 AI。AI 进了主流程，也不代表每点一下都要过一遍模型。

人同样不用盯着每道工序，守住几个关键门就行：方向立不立得住、对外的东西敢不敢署名、这步操作能不能撤回。这三类节点我在《人机双写》里拆得很细，这儿只留一句：活可以交给模型，责任交不出去。

模型越自由，产品越需要清楚的地面。没有地面，Agent 只是飞得很高。

能生成不算完事，能交付才算

东西生成出来了，活还没结束。它得真能交出去。

Agent 动完手，变化要回到工作空间；检查出的问题要进下一轮对话；修完还得再检查一遍。整个回路是这样转的：意图进产品，AI 动手，真实环境给反馈，结果回到 Context，人随时能插手或者回滚。

这比「回答得像不像专家」更接近生产力。真实工作从来就不是一轮 prompt 的事：提要求、看结果、发现偏了、改、再确认能不能交。

这条链路我也还有一堆没解决的：检查结论怎么跟最新产物严格绑定，上下文怎么保持新鲜，长期记忆怎么让用户能改，哪些权限该默认开放。说到底，AI Native 不是一个「接入模型」的项目，它是把产品基础设施重做一遍。

我现在如何定义 AI Native

AI Native 产品，是把工作空间、业务对象、规则、工具和反馈，组织成 AI 可感知、可行动、可验证的环境，让人和 AI 一起完成产品主流程。

判断一个产品是否接近它，我只问三个问题：

1. AI 能否感知用户所处的真实任务现场？
2. AI 能否调用产品能力，对真实业务对象行动？
3. 结果能否被验证、追踪、撤回，并在高风险节点由人把门？

这三件事没发生，聊天框做得再漂亮，AI 大概也还在业务旁边站着。

这个内部工具还在做，谈不上标准答案，就是我的一块试验场，用来把那些抽象概念落成能设计、能开发、能验证的产品问题。但开头那句检验，我一直在用：

AI 是被贴在业务旁边，还是已经进入业务主流程？