[{"data":1,"prerenderedAt":349},["ShallowReactive",2],{"article-ai-native-main-flow\u002F":3},{"id":4,"title":5,"body":6,"cover":310,"date":311,"description":312,"draft":313,"extension":314,"faq":315,"featured":313,"meta":328,"navigation":329,"path":330,"readingTime":331,"seo":332,"seoKeywords":333,"stem":340,"summary":341,"tags":342,"type":346,"updated":347,"video":347,"__hash__":348},"articles\u002Farticles\u002Fai-native-main-flow.md","用三个问题判断，你的产品算不算 AI Native",{"type":7,"value":8,"toc":298},"minimark",[9,16,19,22,25,32,37,40,52,61,66,73,76,80,83,86,91,97,111,114,117,121,124,127,133,136,141,145,148,156,159,164,170,183,187,190,195,198,201,209,215,223,231,236,240,243,246,252,255,258,262,269,272,285,288,291],[10,11,12],"blockquote",{},[13,14,15],"p",{},"拿掉 AI 之后，你的产品是少了一个按钮，还是主流程直接走不通？",[13,17,18],{},"这半年，我一直在做一个内部产品，用户是运营和业务同事：有明确业务目标，但不会开发。",[13,20,21],{},"他们要不停地产出各种页面。这次是活动宣传页，下次是课程内容页，再下次是报名页。看着都叫「页面」，实际差别很大：交互不一样，要接的业务数据也不一样，宣传页要接活动库存和报名状态，内容页要接课程目录和进度。人手就那么多，需求却一个接一个。",[13,23,24],{},"传统工具的解法是把这些差异做成功能、表单和配置项，稳定，但越用越重，用户还得先学会这套配置。另一种解法是接大模型，说一句话直接生成一个页面，灵活，可一旦要求「这块按我们的规范改」「这里接真实的报名数据」，它就只在演示里成立。",[13,26,27,28],{},"我要的其实很简单：",[29,30,31],"strong",{},"让用户带着自己的业务判断，跟 AI 一起把原来得找开发才能做的事做完。",[33,34,36],"h2",{"id":35},"先重定义交付结果再谈-ai","先重定义交付结果，再谈 AI",[13,38,39],{},"传统工具交付的是操作能力：选功能、填信息、调细节。可用户真正要的，是一个符合目标、满足规范、能交付的结果。",[13,41,42,43,51],{},"Des Traynor 提出，Jobs to be Done 要放到完整流程层去看，别停在功能层。",[44,45,50],"a",{"href":46,"rel":47,"target":49},"https:\u002F\u002Fideas.fin.ai\u002Fp\u002Fai-native-product-thinking",[48],"nofollow","_blank","原文"," 放进我的产品里，用户真正在做的一件事，是把一句模糊的活动需求，变成能挂上线、接得上数据、符合规范的页面。澄清需求、选方案、生成初稿、调整、检查、交付，在他眼里本来就是一件事。",[13,53,54,55,60],{},"投资机构对 AI-native 的定义更宽，强调 AI 应在应用体验的核心而非外围辅助。",[44,56,59],{"href":57,"rel":58,"target":49},"https:\u002F\u002Fsapphireventures.com\u002Fblog\u002Fai-native-applications\u002F",[48],"评估框架"," 我把它收紧成一句能当场检验的话：",[13,62,63],{},[29,64,65],{},"拿掉 AI，产品只是少了一个辅助按钮，那是 AI-enabled；拿掉 AI，用户就很难完成核心流程，才更接近 AI Native。",[13,67,68],{},[69,70],"img",{"alt":71,"src":72},"左边是 AI 作为侧边栏功能贴在业务旁边，右边是 AI 进入业务主流程","\u002Fa\u002Fai-native-main-flow\u002F01-ai-feature-vs-ai-native.png",[13,74,75],{},"这只是个诊断标准，不分高下。很多优秀产品就该停在 AI-enabled。但你要是奔着后者去，就得认下这件事：AI 不能只待在侧边栏。它得从任务一开始就参与，弄清目标、背景和约束，中途跟着干，产物出了问题还得接着修。",[33,77,79],{"id":78},"别把-context-当附件它是基础设施","别把 Context 当附件，它是基础设施",[13,81,82],{},"AI 一进主流程，问题立刻出现：它不知道现场发生了什么。",[13,84,85],{},"用户选中一个对象说「把这里调一下」，AI 不知道「这里」是什么。用户刚确认过一套要求，又得复制进对话框。检查报错了，还要把错误搬进去，再把答案搬回来。",[13,87,88],{},[29,89,90],{},"人变成了上下文搬运工。",[13,92,93],{},[69,94],{"alt":95,"src":96},"上下文由谁搬运：人肉复制粘贴，还是产品主动把现场翻译给 AI","\u002Fa\u002Fai-native-main-flow\u002F02-context-carrier.png",[13,98,99,100,105,106],{},"成熟工具早就不这么干了。某编程助手会看着项目状态，自动把相关文件、终端输出和规则塞进上下文。",[44,101,104],{"href":102,"rel":103,"target":49},"https:\u002F\u002Fcursor.com\u002Flearn\u002Fcontext",[48],"官方说明"," 某设计工具也说得很直白：设计上下文是用户、业务、设计系统、技术约束这一堆层次叠起来的东西，一条提示词根本装不下。",[44,107,110],{"href":108,"rel":109,"target":49},"https:\u002F\u002Fwww.figma.com\u002Fresource-library\u002Fdesign-context-ai\u002F",[48],"资料库文章",[13,112,113],{},"所以我把 Context 当成产品基础设施：产品要把用户目标、当前阶段、正在处理的对象、工作规则、可用材料、历史决策、检查结果和版本差异，组织成 AI 能理解的任务现场。",[13,115,116],{},"但塞得越多也不见得越好。给少了，AI 靠猜；给多了，重点被噪声淹掉；信息还会过期，还有权限管着。怎么选、怎么压、什么时候更新、改了能不能追溯，这是 AI Native 产品要一直折腾的事。",[33,118,120],{"id":119},"让工作空间成为-ai-能感知的环境","让工作空间成为 AI 能感知的环境",[13,122,123],{},"我的做法是把整个工作空间开放给 AI。",[13,125,126],{},"任务开始时，系统整理目标、参考和限制条件。进入工作区后，用户选中某个对象，系统就把对象及相关信息带进对话，AI 自然知道「这里」是什么。任务推进时上下文跟着变：前期关注目标和参考，中期关注产物和约束，后期关注检查、版本与交付状态。",[13,128,129],{},[69,130],{"alt":131,"src":132},"工作空间即 Context：分层存在，也随任务阶段变化","\u002Fa\u002Fai-native-main-flow\u002F03-workspace-as-context.png",[13,134,135],{},"讨论、方案、产物、验收、交付，在传统产品里被拆成几个模块。对 Agent 来说，这应该是一条连着的任务链。",[13,137,138],{},[29,139,140],{},"所以「产品向 AI 开放」，光给几个 API 是不够的。真正要开放的，是工作对象、过程状态和历史产物，让 AI 能准确引用到它们。",[33,142,144],{"id":143},"能看见还不够ai-还要能行动","能看见还不够，AI 还要能行动",[13,146,147],{},"光让 AI 读懂现场还不够。它要是只能给建议，用户还得自己把建议一步步点出来，那它就还是个顾问。",[13,149,150,151],{},"某模型厂商把 Agent 概括为能代表用户完成任务的系统，由模型、工具和指令组成：模型推理，工具行动，指令定义规则和边界。",[44,152,155],{"href":153,"rel":154,"target":49},"https:\u002F\u002Fopenai.com\u002Fbusiness\u002Fguides-and-resources\u002Fa-practical-guide-to-building-ai-agents\u002F",[48],"实践指南",[13,157,158],{},"落到产品里，要回答的是：AI 能读什么、改什么、调用哪些能力、如何判断完成、越界时谁拦住。在授权范围内，Agent 应该能修改真实产物、调用产品已有能力，并把结果写回工作空间。",[10,160,161],{},[13,162,163],{},"聊天框只是 AI 的嘴。Context 是眼睛和记忆，工具是手，业务规则决定这双手能伸到哪里。",[13,165,166],{},[69,167],{"alt":168,"src":169},"聊天框只是 AI 的嘴，Context 是眼睛和记忆，工具是手","\u002Fa\u002Fai-native-main-flow\u002F04-agent-anatomy.png",[13,171,172,173,177,178,182],{},"这里容易误读一点：给 AI 行动能力，不等于让它去点界面。我在",[44,174,176],{"href":175},"\u002Farticles\u002Fagent-cli-vs-gui","《对 Agent 操作 GUI 说不》","里写过，GUI 是给人用的慢接口，该开放的是底层能力。光把能力接口丢过去也不行，Agent 还得知道什么时候用、按什么规矩用，这正是 ",[44,179,181],{"href":180},"\u002Farticles\u002Fskill-vs-mcp","Skill 比单纯工具接口多出来的东西","。",[33,184,186],{"id":185},"业务逻辑该不该都交给-ai","业务逻辑该不该都交给 AI",[13,188,189],{},"现在流行一种说法：业务逻辑会整体迁到 AI 层，后端退化成随时可换的数据库。我不太同意，准确说，这个判断漏了一个前提。",[13,191,192],{},[29,193,194],{},"AI 该不该进业务逻辑，得看这段流程本身是什么性质。",[13,196,197],{},"路径固定、要求每次都一样的流程，纯代码跑又快又稳，塞给模型等于花钱买不确定。格式校验、权限控制、资源可用性、交付前检查，这些都有标准答案，让模型凭感觉判断，贵还不靠谱。",[13,199,200],{},"真正难办的是那些量大又多变的长尾需求，你不可能把它们一条条穷举成分支和配置项。这时候才轮到 AI 进业务逻辑，让它当调度员：听懂需求、挑合适的能力、在各个业务节点之间把活转起来。",[13,202,203,204],{},"另一家模型厂商分 workflow 和 agent，讲的是同一件事：路子明确的任务交给 workflow，得临场判断的开放任务才交给 agent。",[44,205,208],{"href":206,"rel":207,"target":49},"https:\u002F\u002Fwww.anthropic.com\u002Fengineering\u002Fbuilding-effective-agents",[48],"工程博客",[13,210,211],{},[69,212],{"alt":213,"src":214},"按任务性质重新划分确定性程序、Agent 与人的责任","\u002Fa\u002Fai-native-main-flow\u002F05-division-of-labor.png",[13,216,217,218,222],{},"这跟我在",[44,219,221],{"href":220},"\u002Farticles\u002Fagent-ui","《给产品装了个 AI 入口》","里的判断是一回事：高频固定的走界面和代码，长尾多变的走 AI。AI 进了主流程，也不代表每点一下都要过一遍模型。",[13,224,225,226,230],{},"人同样不用盯着每道工序，守住几个关键门就行：方向立不立得住、对外的东西敢不敢署名、这步操作能不能撤回。这三类节点我在",[44,227,229],{"href":228},"\u002Farticles\u002Fhuman-ai-cowriting-gate","《人机双写》","里拆得很细，这儿只留一句：活可以交给模型，责任交不出去。",[13,232,233],{},[29,234,235],{},"模型越自由，产品越需要清楚的地面。没有地面，Agent 只是飞得很高。",[33,237,239],{"id":238},"能生成不算完事能交付才算","能生成不算完事，能交付才算",[13,241,242],{},"东西生成出来了，活还没结束。它得真能交出去。",[13,244,245],{},"Agent 动完手，变化要回到工作空间；检查出的问题要进下一轮对话；修完还得再检查一遍。整个回路是这样转的：意图进产品，AI 动手，真实环境给反馈，结果回到 Context，人随时能插手或者回滚。",[13,247,248],{},[69,249],{"alt":250,"src":251},"生成不是终点：意图、行动、反馈、验收在同一条链路上","\u002Fa\u002Fai-native-main-flow\u002F06-delivery-loop.png",[13,253,254],{},"这比「回答得像不像专家」更接近生产力。真实工作从来就不是一轮 prompt 的事：提要求、看结果、发现偏了、改、再确认能不能交。",[13,256,257],{},"这条链路我也还有一堆没解决的：检查结论怎么跟最新产物严格绑定，上下文怎么保持新鲜，长期记忆怎么让用户能改，哪些权限该默认开放。说到底，AI Native 不是一个「接入模型」的项目，它是把产品基础设施重做一遍。",[33,259,261],{"id":260},"我现在如何定义-ai-native","我现在如何定义 AI Native",[10,263,264],{},[13,265,266],{},[29,267,268],{},"AI Native 产品，是把工作空间、业务对象、规则、工具和反馈，组织成 AI 可感知、可行动、可验证的环境，让人和 AI 一起完成产品主流程。",[13,270,271],{},"判断一个产品是否接近它，我只问三个问题：",[273,274,275,279,282],"ol",{},[276,277,278],"li",{},"AI 能否感知用户所处的真实任务现场？",[276,280,281],{},"AI 能否调用产品能力，对真实业务对象行动？",[276,283,284],{},"结果能否被验证、追踪、撤回，并在高风险节点由人把门？",[13,286,287],{},"这三件事没发生，聊天框做得再漂亮，AI 大概也还在业务旁边站着。",[13,289,290],{},"这个内部工具还在做，谈不上标准答案，就是我的一块试验场，用来把那些抽象概念落成能设计、能开发、能验证的产品问题。但开头那句检验，我一直在用：",[10,292,293],{},[13,294,295],{},[29,296,297],{},"AI 是被贴在业务旁边，还是已经进入业务主流程？",{"title":299,"searchDepth":300,"depth":300,"links":301},"",3,[302,304,305,306,307,308,309],{"id":35,"depth":303,"text":36},2,{"id":78,"depth":303,"text":79},{"id":119,"depth":303,"text":120},{"id":143,"depth":303,"text":144},{"id":185,"depth":303,"text":186},{"id":238,"depth":303,"text":239},{"id":260,"depth":303,"text":261},"\u002Fa\u002Fai-native-main-flow\u002Fcover.webp","2026-09-19","接了大模型不等于 AI Native。真正的分界线是 AI 有没有进入产品主流程：能否感知任务现场、对真实业务对象行动、结果能否被验证和撤回。",false,"md",[316,319,322,325],{"q":317,"a":318},"AI Native 和 AI-enabled 有什么区别？","看拿掉 AI 会发生什么。拿掉后产品只是少了一个辅助按钮，主流程照常运转，那是 AI-enabled；拿掉后用户很难完成核心任务，才更接近 AI Native。区别在于 AI 处在业务旁边还是业务主流程里。",{"q":320,"a":321},"为什么说 Context 是产品基础设施而不是提示词技巧？","因为 AI 进入主流程后，它必须知道用户目标、当前阶段、正在处理的对象、工作规则、历史决策和检查结果。这些信息应由产品主动组织成任务现场，而不是让用户反复复制粘贴。上下文也要选择、压缩、更新并受权限约束，不是越多越好。",{"q":323,"a":324},"业务逻辑应该全部迁到 AI 层吗？","不应该。判断依据是任务性质：路径固定、强调一致性的流程用确定性代码执行，更快也更可靠；大量多变的长尾需求才适合把 AI 迁入业务逻辑，让它做调度员，在各个业务节点之间流转。格式校验、权限控制和交付前检查仍归程序。",{"q":326,"a":327},"判断一个产品是不是 AI Native，具体看什么？","三个问题：AI 能否感知用户所处的真实任务现场；AI 能否调用产品能力，对真实业务对象行动；结果能否被验证、追踪、撤回，并在高风险节点由人把门。三件事没发生，聊天框做得再漂亮，AI 也还在业务旁边。",{},true,"\u002Farticles\u002Fai-native-main-flow",6,{"title":5,"description":312},[334,335,336,337,338,339],"AI Native 产品","AI Native 判断标准","AI-enabled 区别","AI 产品 Context","Agent 业务逻辑层","AI 进入主流程","articles\u002Fai-native-main-flow","AI Native 产品把工作空间、业务对象、规则、工具和反馈，组织成 AI 可感知、可行动、可验证的环境。判断标准不是聊天框做得多好，而是拿掉 AI 后主流程还能不能走完。",[343,344,345],"AI 洞察","产品思考","AI 应用","article",null,"WSQJtvoxLfoWhFRH9IcdjYJtLH_a4SYR2DOBj-6AwT4",1793028248146]