惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

A
About on SuperTechFans
Y
Y Combinator Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Microsoft Security Blog
Microsoft Security Blog
aimingoo的专栏
aimingoo的专栏
I
InfoQ
C
Check Point Blog
IT之家
IT之家
MyScale Blog
MyScale Blog
Apple Machine Learning Research
Apple Machine Learning Research
Vercel News
Vercel News
Last Week in AI
Last Week in AI
GbyAI
GbyAI
P
Proofpoint News Feed
量子位
Stack Overflow Blog
Stack Overflow Blog
Microsoft Azure Blog
Microsoft Azure Blog
月光博客
月光博客
阮一峰的网络日志
阮一峰的网络日志
人人都是产品经理
人人都是产品经理
B
Blog
T
The Blog of Author Tim Ferriss
H
Help Net Security
云风的 BLOG
云风的 BLOG

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
意图驱动:让产品承担”意图 → 步骤”的翻译,而不是用户 – 人...
巫师Sorcerer · 2026-06-17 · via 人人都是产品经理

AI正在颠覆延续六十年的软件交互逻辑,从『用户替机器读心』转变为『机器为用户读心』。Nielsen Norman Group将其定义为六十年来首个真正的新交互范式——基于意图的结果描述。本文将深入解析这一范式转变如何重构产品设计逻辑,揭示从命令驱动到意图驱动的关键转折点,以及产品经理如何在这场变革中重新定义用户体验。

过去六十年,我们一直在教用户怎么操作软件:点这个菜单、填那个表单、记住第三步藏在哪个二级页面里。

整个软件设计史,本质上是一部”教人类替机器读心”的历史:用户得把自己心里那个模糊的”我想要什么”,亲手翻译成机器听得懂的一连串精确操作。

AI 第一次让这件事反了过来。用户只说”我想要什么”,软件自己去想”该怎么做”。

Nielsen Norman Group 把这叫做约六十年来第一个真正全新的交互范式。它的代价是控制权,它的红利是:用户终于不用再替机器读心了。

这个判断分量很重。他们说”六十年来第一个”,意思是从命令行到图形界面、从鼠标到触屏,那些我们以为的大革命,在交互范式的层面其实是同一回事,都是”用户发出命令、系统执行命令”。而这一次不一样。

范式转变的本质:从下命令到说结果

旧范式叫 command-based,命令驱动。

你得知道每一个命令是什么、在哪、按什么顺序敲。Photoshop 抠个图你要会用钢笔工具,Excel 算个数你要记住函数名。软件的能力再强,也被锁在”你会不会操作它”这道门后面。

新范式 NN/g 称之为 intent-based outcome specification,基于意图的结果描述。用户说出他想要的结果,系统自己去找实现路径。

控制权从用户那一侧,移向了 AI 这一侧。

这个移动是双刃的。

它让能力的门槛塌掉了,你不会用钢笔工具,但你会说”把这个人从背景里抠出来”。

但它也意味着,用户交出了对”具体怎么做”的精确把控。

这笔交易划不划算,取决于这件事用户在不在乎过程。

翻译成本,从用户身上挪到了产品身上

我想把这件事讲透一点,因为它是整个范式转变里最该被产品经理记住的一句。

在”你点我做”的世界里,”意图 → 步骤”这道翻译,是用户自己在做。

用户心里想”我要给孩子找点学电子学的入门材料”,但他得把这个意图,翻译成一串搜索关键词、翻译成在哪个分类页里筛选、翻译成对比七八个商品详情页。这道翻译的全部成本,压在用户头上。

在”你说我做”的世界里,这道翻译应该由产品来承担。

Amazon 的 Rufus 是个干净的例子:用户直接说”我想教我的孩子学电子学”,而不是自己去搜一堆零散关键词再人肉拼凑。

产品接住了那句模糊的意图,自己完成了”意图 → 一组合适的商品和方案”的翻译。

这正是我一直说的那件事:产品替用户读它自己的”心”,消除读心成本。

过去是用户费劲替机器读心,把意图翻译成机器能懂的操作;现在反过来,产品有义务去读懂用户那句含混的话,主动把它翻译成步骤。

谁承担这道翻译,谁就承担了复杂度。好产品的标志,就是它替用户扛下了这份复杂度。

你拿订机票这件事,能很清楚地看到这道翻译挪了多少活。

旧范式里用户要走的步骤是:打开 App,搜出发地和目的地,选日期,在二三十个航班里按价格和时段筛,比对中转还是直飞,再核对行李额、退改签规则,最后才下单。

这一长串里,”我想周五下午去趟上海、别太贵、别太折腾”这个真实意图,是用户自己一格一格翻译成筛选条件的。

意图驱动之下,用户只说那一句”周五下午去上海,别太贵别太折腾”,产品接住后,自己去把”别太贵”翻译成一个价格区间、把”别太折腾”翻译成优先直飞且时段合适,自己跑完整个筛选,最后端上来两三个候选。中间那十几步翻译,从用户的脑子里挪进了产品的逻辑里。

用户付出的,从”学会怎么操作并亲自操作”变成了”说清楚我要什么”。这一挪,就是产品价值真正发生的地方。

这里有个产品经理特别容易踩的坑:以为”接住意图”就是加一个聊天框。装个对话入口,让用户随便说,剩下的丢给大模型,自己什么都没多做。

这不叫意图驱动,这叫把翻译的活儿从用户身上挪走、又原封不动甩给了模型,中间那段最该你下功夫的”把这句意图稳定地翻译成正确步骤”,你跳过了。

真正的意图驱动,难就难在你得为模型布置好上下文、设计好它读不懂时怎么追问、规划好它翻译错了用户怎么纠正。

一个聊天框是十分钟的事,让那个聊天框真的接得住用户的意图、还接得稳,是几个月的事。这两者之间的距离,就是普通 AI 功能和好 AI 产品的距离。

设计重心,从编排界面转向编排结果

这件事一旦想通,设计的发力点就变了。

过去产品设计的核心活儿是”编排界面”:这个按钮放哪、这个流程几步、这个状态怎么提示。设计师的功力体现在把一个复杂流程,拆成用户能一步步走完的界面序列。

意图驱动之下,重心转向”编排用户目标与最终结果”。NN/g 把这套思路叫 generative UI 和 outcome-oriented design。界面不再是预先固定好的,而是按用户当下的意图动态生成。你今天问的问题和明天问的问题,可能看到的根本不是同一个界面。

设计师设计的不再是一个个固定页面,而是一套”根据意图生成合适呈现”的规则。

它动摇了一批旧的 UX 信条

这里得说句实话:意图驱动跟我们奉了多年的一些 UX 老法则,是冲突的。

一致性、可预测性、无缝性,这些写进每一本交互设计教材的原则,在动态生成界面面前都被动摇了。界面每次都不一样,”一致性”从何谈起?系统自己决定怎么做,”可预测性”还剩多少?学术界已经意识到这个断层,CHI 2024 上专门有人为生成式 AI 应用提出新的设计原则,因为旧原则确实不够用了。

代价里最尖锐的一条是:当意图被误读,用户更难发现到底是哪一步错了。在旧范式里,你点错了一步,你知道是哪一步,回退就行。在意图驱动里,你说了一句话,系统在背后做了十步,结果不对,你连它哪一步理解偏了都不知道。debug 的能力,被一起拿走了。

意图驱动不等于取消控制

所以好的意图驱动,一定保留纠偏入口。这不是可选项,是底线。

把它接到信任阶梯上看就明白了:意图越大、系统替你做的越多,就越需要可审、可改、可回退。用户说一句话,产品翻译成五步去执行,那这五步得让用户看得见、拦得住、改得了。

意图驱动的爽,建立在”我随时能把方向盘抢回来”的安全感之上。没有这个安全感,用户根本不敢说那句大而模糊的话。

但是,模糊性是要交税的

反过来说,意图驱动有一笔绕不开的”模糊性税”。

自然语言表达意图,天然是含混的。”帮我弄得好看点”——好看是多好看?什么风格的好看?系统只能猜。猜对了皆大欢喜,猜错了,用户反而失去了”精确操作”的能力,比自己一步步做还挫败。NN/g 自己也提醒:纯意图交互对新手特别友好,但对那些追求精确控制的专家用户,可能是一种退步。

一个用了十年 Photoshop 的修图师,你让他对着 AI 描述”把这里再调暖一点点”,远不如他自己拉一下色温滑块来得准。

所以边界是清楚的:高精度、高风险的任务,仍然需要保留步骤级的控制。意图驱动和精确操作不是替代关系,是共存关系。最好的产品,是让小白能用一句话办成事,也让专家能在需要时下钻到每一个旋钮。

把这个”共存”做好,有个常被忽略的设计要点:意图驱动和精确操作之间,必须留一条平滑的下钻通道,而不是两套割裂的产品。我见过不少 AI 产品的做法是,给新手一个聊天框、给专家一套传统界面,两边老死不相往来。这其实没接住意图驱动的精髓。

更好的形态是同一条流里能自由切换层级,用户先用一句话让产品生成一个方案,对大方向满意,但想把其中某一步再精调,这时候产品应该让他能就地点开那一步、露出底层的旋钮,调完再合上、继续用自然语言往下走。

意图是入口,精确控制是随时可以下潜的深水区,两者是一条连续的坡道,不是两个互不连通的房间。能不能在”说一句话”和”亲手拧一下”之间无缝切换,是区分一个意图驱动产品做得糙还是做得细的关键。

现在就能做的一件事

找你产品里一个”用户必须走 5 步才能完成”的流程,试着重新设计成”用户说一句话,产品在背后翻译成这 5 步”。

设计完,立刻追问自己一个问题,当产品猜错了,用户怎么把方向盘抢回来?答不上来这个问题,这个意图驱动就还不能上线。

好产品的标志,是用户说”我想要什么”,而不是被迫学”机器要我怎么做”。

意图驱动不是让用户少按几个键,是把”读心”这笔成本,从用户身上,挪回到产品身上。

本文由 @巫师Sorcerer 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议