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

推荐订阅源

Recent Announcements
Recent Announcements
雷峰网
雷峰网
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Hugging Face - Blog
Hugging Face - Blog
博客园 - 司徒正美
人人都是产品经理
人人都是产品经理
博客园 - 【当耐特】
量子位
有赞技术团队
有赞技术团队
博客园 - 三生石上(FineUI控件)
博客园 - Franky
M
MIT News - Artificial intelligence
U
Unit 42
Last Week in AI
Last Week in AI
酷 壳 – CoolShell
酷 壳 – CoolShell
The Cloudflare Blog
J
Java Code Geeks
V
Visual Studio Blog
Engineering at Meta
Engineering at Meta
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
MyScale Blog
MyScale Blog
T
Tailwind CSS Blog
T
The Blog of Author Tim Ferriss
V
V2EX

人人都是产品经理

为什么你的产品找不到差异化?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协议