Transformer架构的崛起正在颠覆产品经理的传统工作范式——从追求确定性到拥抱不确定性，从设计功能清单到划定能力边界，这场思维革命远比想象中来得猛烈。本文深度拆解AI时代PM的四大角色转变，揭示如何通过设计输入输出约束、能力抽象和失败兜底机制，驯服AI这头不可预测的'猛兽'。

引言：当 AI 不再“按流程办事”，PM 还能只管功能和流程吗？

最近一直在想一个事儿，就是我们这些做产品经理的，到底每天在跟什么东西打交道

以前，我觉得这事儿特清楚，就是跟功能和流程死磕。用户点这个按钮，就应该跳到那个页面；用户填完这个表单，数据就应该存到那个库里。一切都明明白白，写在PRD里，画在流程图上，像一个精密的机械表，每个齿轮咬合得分毫不差

我记得刚入行的时候，前辈教我，一个好的PM，就是要能把所有可能性都想到，把所有路径都堵死，让用户只能按照你设计的“唯一正确”的道路走下去。那时候，我们追求的是确定性，是系统的可预测性。我点什么，你就得给我什么，这是天经地义的

可现在，情况全变了

你面对一个基于 Transformer 架构的产品，比如一个智能助手，一个内容生成工具。你跟它的交互，不再是点按钮，而是说一句话。你说“帮我规划一个周末去海边的行程”，它不会弹出一个让你选“出发地”“目的地”“预算”的表单

它会“想一下”，然后给你一段看起来头头是道的话，里面可能包含了交通建议、住宿选项，甚至还有几家餐厅的风格描述。它好像“理解”了你的意图，而不是执行了一个固定的程序

这个“想一下”的过程，就是一切变化的开始。它意味着系统的行为不再是百分之百可预测的。你用同样的话问两次，它给的答案可能都不完全一样。它可能会给你惊喜，也可能会给你惊吓

这时候，你手里的功能列表和流程图，突然就显得有点不够用了。你没法再用一张图来穷尽所有用户的路径，因为路径是动态生成的。你也没法再用一个功能清单来定义产品，因为产品的能力是涌现出来的，而不是被严格限定的

我感觉，我们这些PM，第一次被逼着去正视一个过去我们极力回避的东西：不确定性

过去，不确定性是Bug，是异常，是需要被处理掉的麻烦。现在，它成了系统的固有属性，甚至是一种魅力。我们的工作，不再是消灭不确定性，而是要去设计它，管理它，引导它

Transformer 的出现，让 PM 第一次需要正视「不确定性」本身，成为设计对象

这个转变太大了，大到我觉得我们整个工作的地基都被动摇了。我们还能只盯着功能和流程吗？显然不能了。那我们的工作边界，到底在往哪里移动呢

这就是我今天想跟你聊聊的话题

一、从「定功能」到「定能力边界」

以前做产品，最核心的工作之一就是“定功能”。这个需求做不做，这个功能要不要上，优先级是高是低。我们就像一个守门员，把守着产品的功能清单，每一个功能的加入都要经过深思熟虑，因为它意味着研发成本、维护成本，也定义了产品的形态

功能清单（Feature List）是我们跟研发、测试、运营沟通的共同语言。一个功能，有明确的输入、处理逻辑和输出。做了，就是做了；没做，就是没做。界限非常清晰

可到了 Transformer 时代，这套玩法突然失灵了

你面对一个大模型，它好像什么都能做一点。你让它写诗，它能写；你让它写代码，它能写；你让它扮演一个角色跟你聊天，它也能做到。它的能力不是一个清单，而是一个巨大的、模糊的能力空间

这就带来一个全新的问题：模型什么都“好像能做一点”，但我们的产品，真的能允许它什么都做吗

答案显然是否定的。一个定位为“专业法律文书助手”的产品，你不能让它去跟用户聊八卦、写情诗。一个面向儿童的教育产品，你必须严防死守，不能让它生成任何不适宜的内容。即便是一个通用聊天机器人，也必须有它的红线和禁区

所以，AI PM 的第一个核心职责变化，就是从“定功能”转向了“定能力边界”

我们不再是问“这个功能做不做”，而是问“这个能力应该开放到什么程度”。我们的工作，从加法变成了划定范围。我们不再是砌砖，而是在一片广阔的土地上画出我们家园的篱笆

这个“能力边界”具体包括什么呢

业务场景边界

这可能是最重要的一条。我们需要明确，在哪些业务场景里，AI 可以被启用，可以发挥作用。比如，在一个电商导购产品里，AI 可以用来做商品推荐、回答用户关于商品的咨询。但它能不能处理用户的售后投诉呢？可能就不行，因为这涉及到订单状态、退款流程等强规则系统，而且用户情绪激动，AI 的不确定性回答很可能火上浇油

定义场景边界，就是为AI的能力寻找最合适的“用武之地”。在合适的场景里，它是神兵利器；在不合适的场景里，它就是个麻烦制造者

用户角色边界

同一个产品，不同的用户，能用到的AI能力也应该是不一样的。一个普通用户和一个付费的专业用户，他们能调用的模型版本、能使用的深度功能、每天的调用次数上限，都应该有所区别

比如，一个写作辅助工具，免费用户可能只能用它做一些基础的润色和纠错。而付费的专业作家，或许可以解锁更高级的功能，比如深度情节分析、人物弧光建议、或者根据他的写作风格进行续写。这既是商业模式的需要，也是产品层次感的体现

风险边界

这是最严肃，也是最需要我们投入精力去定义的一块。模型的输出是生成式的，它不知道什么是对的，什么是错的，什么是“不该说”的。它只知道基于概率，下一个最可能出现的词是什么

这就要求我们必须建立一套严格的风险边界，也就是我们常说的“护栏”。哪些话题是绝对禁止讨论的，哪些词语是必须被拦截的，哪些类型的生成内容是高风险、需要人工审核的。这包括了法律法规的红线、道德伦理的底线，以及品牌形象的防线

我记得有一次，我们测试一个内部的知识库问答机器人，有人问了一个关于某个历史事件的敏感问题，模型竟然一本正经地胡说八道，编造了一些完全不符合事实的细节。当时我们团队所有人都惊出一身冷汗。从那以后，我们就把风险边界的定义和测试，提到了最高优先级

这件事让我深刻地认识到：在 AI 产品中，“不让模型做什么”，和“让它做什么”同样重要

甚至在很多时候，前者比后者更重要。因为它决定了你的产品是可靠的，还是一个随时可能爆炸的定时炸弹。定义边界，就是在驯服这头能力强大的猛兽，让它能为我所用，而不是反噬我们

这种工作，比过去画功能列表要模糊，也更考验PM的判断力和系统思考能力。你需要对业务、用户、技术和风险都有深刻的理解，才能画好那一道道看不见却至关重要的边界线

二、从「定流程」到「定输入输出约束」

聊完了功能，我们再来聊聊流程

传统产品经理的另一项核心技能，就是流程设计。用户注册流程、购物流程、发布内容流程……我们用Visio或者别的什么工具，画出各种各样的流程图，精确到每一个步骤、每一个分支、每一个异常状态

我们为什么这么痴迷于流程图？因为我们相信，用流程可以控制结果。只要用户按照我们设计的步骤一步步走，就能最大概率地达到我们想要的目标，同时也能最小概率地犯错。流程图是我们控制系统确定性的最强武器

但在 Transformer 产品里，这套逻辑又行不通了

你没法给模型设计一个“流程图”。你不能告诉它：“你收到用户的问题，第一步做A，第二步做B，第三步做C”。模型的工作方式是一个黑箱，它不会严格地“按流程走”。它会根据整体的输入，直接生成一个它认为最合适的输出

这是否意味着PM就彻底失去了对过程的控制力呢

也不是。我慢慢发现，虽然我们不能控制模型的“思考过程”，但我们可以强烈地影响它的行为。通过什么呢？通过设计它赖以生存的土壤：输入和输出

PM的角色，从一个设计“每一步怎么点”的建筑师，变成了一个设计“模型怎么被喂信息、怎么交付结果”的营养师和沟通教练

这听起来有点玄，我具体说说

输入约束：你喂给模型什么，它就长成什么样

模型的每一次响应，都不是凭空产生的，而是基于你给它的输入。这个输入，就是我们作为PM可以大做文章的地方。我们常说的 Prompt Engineering，本质上就是一种输入约束的设计

我们可以设计提供给模型什么信息。比如，当用户问一个商品怎么样的时候，我们不能只把用户的问题扔给模型。我们应该在后台，把这个问题和商品的详情页信息、用户评价、甚至是一些搭配建议，一起打包喂给模型。这样，模型才能言之有物，而不是空泛地回答“这个商品看起来不错”

我们也可以设计不提供给模型什么信息。比如，在处理一个医疗咨询的场景时，为了避免模型给出不负责任的诊断，我们可以在输入端就过滤掉用户的个人身份信息和过往的详细病历，只提供脱敏后的症状描述，并强制模型在回答时强调“本建议不能替代专业医生诊断”

还有信息的结构化程度。同样的信息，用自然语言喂给模型，和用JSON格式喂给模型，得到的结果可能天差地别。结构化的输入，能让模型更准确地理解信息之间的关系，输出也更稳定。什么时候用结构化，什么时候用非结构化，这本身就是一种产品设计

输出约束：给模型的表达戴上“镣铐”

如果说输入是给模型提供原料，那输出约束就是给它一个模具，让它把结果塑造成我们想要的形状

最直接的输出约束就是格式。我们可以要求模型必须以Markdown的表格形式返回结果，或者必须以一个可被程序解析的JSON对象来回答。这对于需要进行后续处理的场景至关重要。比如，一个行程规划助手，如果它返回的是一段散文，那前端就很难把它解析成一个个独立的行程点。但如果我们约束它必须返回一个包含日期、时间、地点、活动的结构化数据，那整个产品体验就会流畅很多

输出的长度也是一个重要的约束。有时候我们希望模型侃侃而谈，有时候我们又希望它言简意赅。通过在Prompt里明确“请用不超过100字回答”，就能有效地控制输出的篇幅，避免用户被信息淹没

还有一个更有意思的约束，是输出的确定性。我们可以引导模型，是给出一个“唯一答案”，还是给出“几个选项”。比如，当用户问“我应该学什么编程语言”时，一个好的AI产品不应该直接说“你应该学Python”。它更应该给出几个选项，比如“如果你想做数据分析，可以考虑Python；如果你想做前端开发，可以考虑JavaScript”，并说明各自的优劣，把最终的决定权交还给用户。这种建议性的、非结论性的输出，本身就是一种更高级的产品设计

所以你看，我们虽然画不了流程图了，但我们有了新的武器库，Transformer 时代，流程不再写在 PRD 里，而是写进输入与输出的约束中

我们通过精心设计这些约束，像一个导演在给演员说戏，虽然不能控制演员的每一个表情，但可以通过剧本、场景和要求，引导他最终演出我们想要的效果。这种“间接控制”的艺术，成了AI PM的新必修课

三、从「需求拆解」到「能力抽象」

“需求拆解”这个词，对每个PM来说都刻在骨子里了。用户说“我想要一个社区”，我们就开始拆：需要有发帖功能、评论功能、点赞功能、用户个人主页……一个模糊的需求，被我们庖丁解牛一样，拆解成一个个可以被开发、被测试、被排期的功能点。这是我们把想法落地为产品的核心路径

这套方法在过去非常有效，因为它符合软件工程的逻辑。把一个大问题，分解成一堆小问题，然后逐个解决

但在AI产品里，我发现这套方法经常碰壁

为什么呢？因为用户面对一个强大的AI时，他自己也不知道自己需要哪个“功能”。他只有一个模糊的目标。比如一个市场分析师，他的目标是“我想了解一下最近年轻人对咖啡的消费趋势”。

按照传统思路，我们可能会去拆解：是不是要做一个“关键词搜索”功能？一个“数据图表生成”功能？一个“报告模板”功能？但这样做出来的产品，很可能非常笨重，用户需要像操作一个复杂的软件一样，先去A功能搜集数据，再去B功能制作图表，最后去C功能撰写报告

用户会觉得很累。他会想：我明明有了一个这么聪明的AI，为什么还要我自己动手做这些繁琐的事情？我想要的，就是你直接帮我把“了解消费趋势”这件事做好

这就暴露了传统需求拆解方式在AI时代的局限性。我们不能再满足于把需求翻译成功能点。PM的新工作重点，是向上一步，把用户模糊的目标，抽象成模型能够理解并执行的“能力”

这个“能力抽象”到底是什么意思呢

它意味着我们要从用户的最终目的出发，去思考模型需要具备哪些核心的、可组合的技能，来完成这个任务。它不是一个个孤立的功能，而是一套解决问题的组合拳

还是拿“了解咖啡消费趋势”这个例子来说。我们可以把这个模糊的目标，抽象成几个模型需要具备的核心能力：

首先，是“多渠道信息检索与整合”的能力。模型需要能去不同的地方，比如社交媒体、新闻报道、行业报告，抓取相关信息，并把这些碎片化的信息整合起来

其次，是“核心观点提炼与洞察”的能力。面对海量的信息，模型需要能识别出哪些是关键的趋势，哪些是重要的消费者声音，哪些是潜在的商业机会，并把它们提炼出来

最后，是“结构化报告生成”的能力。模型需要能把这些洞察，按照一个清晰的逻辑结构，比如“市场概览”、“核心发现”、“人群画像”、“未来趋势”，组织成一篇可读性强的报告

你看，我们没有去定义“搜索按钮”或者“图表类型选择器”。我们定义的是“信息整合”、“观点提炼”、“报告生成”这三个更高维度的能力。这才是AI产品应该提供的价值

一个好的能力抽象，有几个特点：

它需要有明确的任务目标和成功标准。比如，“报告生成”能力的成功标准，不是看它写了多少字，而是看它是否准确回答了用户最初的问题，是否提供了有价值的洞察

它还要允许有可失败、可修正的中间状态。一个复杂的任务不可能一步到位。好的能力抽象，应该让模型可以逐步逼近正确结果。比如，模型可以先生成一个报告大纲，让用户确认，然后再去填充内容。或者在生成报告后，允许用户追问：“你刚才提到的‘燕麦奶拿铁’这个趋势，能再多给我一些数据支撑吗？”。这种可迭代、可修正的过程，比一次性给出一个“看起来对”的答案要重要得多

这种从“需求拆解”到“能力抽象”的转变，对PM的要求更高了。你需要有更强的业务理解力和逻辑思维能力，才能从用户纷繁复杂的需求中，提炼出那些真正核心、可复用的能力

AI PM 不再是需求翻译官，而是把人类目标翻译成机器可执行能力的人

我们成了连接人类意图和机器智能之间的那个关键桥梁。这个角色，比以往任何时候都更具挑战性，也更有创造力

四、从「异常处理」到「失败兜底机制设计」

在传统软件的世界里，“失败”是一个很明确的概念。通常就是系统报错，页面崩溃，或者一个操作无法完成。比如你提交表单，服务器没响应，弹出一个“网络错误，请重试”的提示。这就是一次失败

我们作为PM，会花很多时间去设计这些“异常处理”流程。404页面怎么设计，断网状态下应该怎么办，服务器返回错误码500时前端要如何提示用户。我们的目标，是尽可能地捕获所有已知的异常，给用户一个明确的交代

但Transformer系统的失败，完全是另一回事

它的失败，往往不是“崩了”或者“不动了”，而是以一种更隐蔽、更迷惑人的方式出现

最典型的就是“幻觉”。模型会一本正经地编造事实，自信满满地给出错误的答案。它会告诉你一个不存在的函数用法，或者引用一篇根本没发表过的论文。它看起来说得头头是道，逻辑自洽，但内容却是错的

还有一种失败，是“表面合理，实际不可用”。比如你让它帮你写一段代码，它给你的代码看起来语法完全正确，也能运行，但就是实现不了你想要的功能，或者在某些边界条件下会出问题。你很难一眼就判断出这是“失败”的

这种新型的、难以捉摸的失败，给PM带来了全新的挑战。我们必须接受一个残酷的现实：在AI产品中，失败是不可避免的，是常态，而不是异常。因为幻觉是模型的内生特性，不是一个可以被“修复”的Bug

既然失败不可避免，那我们的工作重点就不再是“防止失败”，而是设计一套完善的“失败兜底机制”。关键在于，要让失败变得“可控、可感知、可恢复”

这听起来有点抽象，我分享几种我们实践中常用的兜底方式

不确定性提示

这是最基本，也是最重要的一招。当模型对自己的答案不太自信时，产品就应该明确地告诉用户。比如，在答案旁边加一个“本内容由AI生成，可能存在不准确之处”的提示，或者用不同的颜色、字体来标识那些它不确定的信息。这就像在地图上标注出“前方路段可能湿滑”一样，是提前管理用户的预期，降低他们对模型百分百信任的风险

主动澄清

当用户的指令模糊不清时，与其让模型去猜，不如让它主动反问。比如用户说“帮我找一家好吃的餐厅”，一个好的兜底设计是让模型反问：“好的，请问您喜欢什么菜系呢？比如川菜、粤菜还是日料？您的预算大概是多少？”。这种主动澄清的交互，可以极大地降低因为理解偏差导致的失败概率

降级为规则或人工

AI不是万能的。在某些高风险或者AI不擅长的领域，我们需要有预案，及时地从AI模式降级。比如，在一个智能客服系统中，当AI连续三次无法理解用户的问题，或者当用户的问题涉及到退款、投诉等敏感操作时，系统应该自动触发降级机制，提示用户“正在为您转接人工客服”。这就像给自动驾驶的汽车配备了人类驾驶员，在关键时刻可以随时接管

给用户“下一步建议”

当一次交互失败后，最糟糕的体验就是让用户愣在原地，不知所措。一个好的兜底设计，应该在失败的同时，给用户提供有建设性的“下一步建议”。比如，模型生成的内容不符合用户预期，我们可以在旁边提供几个按钮，比如“换个角度重新生成”、“让内容更简洁一些”、“增加一些具体案例”。这些建议给了用户一个修正和继续探索的路径，把一次失败的交互，变成了一次共同调试的过程

我越来越觉得，AI产品的体验好坏，很大程度上不取决于它在顺利时有多惊艳，而取决于它在失败时有多得体

在 AI 产品中，真正的安全感来自「失败时的体验设计」

为失败设计，意味着我们承认了系统的不完美，并选择与用户站在一起，共同面对和解决这种不完美。这种坦诚和赋能，比任何华丽的功能都更能赢得用户的信任

五、PM 为什么必须理解模型的“长处与幻觉”

聊了这么多工作边界的变化，背后其实都指向了一个对PM的新能力要求：你必须得懂点模型

我一说这个，可能很多PM朋友就会头大。大家会说，我一个产品经理，又不是算法工程师，我为什么要懂那些复杂的模型原理？我只要会用，知道它能干什么不就行了吗

以前我也这么想。我觉得技术细节是工程师的事，我只要负责提需求、画原型就好了。但做了AI产品之后，我发现这个想法是极其危险的

为什么AI PM不能只“会用模型”？因为如果你不理解模型的一些基本特性，你很可能会设计出风险极高、体验极差的交互。你会在一个不该用AI的地方用了AI，或者用一种错误的方式去引导用户和AI互动

举个例子，如果你不理解模型的“幻觉”是常态，你可能会设计一个“AI法官”产品，让模型直接对一个案件的是非曲直做出“判决”。这是一个灾难性的设计，因为它把一个充满不确定性的生成结果，包装成了一个权威的、不容置疑的结论，这可能会造成无法挽回的后果

我不是要求PM都去读论文、推公式，成为算法专家。那不现实，也没必要。但我们至少要知道一些模型的“脾气”，对它的行为有一个基本的预期

具体来说，我觉得PM至少要知道这几件事

模型擅长什么

大语言模型本质上是一个“文本补完”大师，它最擅长的是那些和语言组织、模式识别相关的工作。比如，总结归纳，把一篇长长的文章，提炼出几个核心要点。比如，内容生成，根据你的要求写一首诗、一个故事、一篇营销文案。再比如，联想和发散，从一个点子出发，帮你做头脑风暴，提供各种相关的想法

知道它擅长什么，我们就能把好钢用在刀刃上，在这些领域里设计出能让用户惊叹的产品体验

模型不擅长什么

同样重要的是，要知道它的短板。模型不擅长，甚至说完全不能胜任的，是那些需要精确事实判断和强约束执行的任务。它不是一个数据库，记不住所有事情，而且经常张冠李戴。所以，你不能把它当成一个事实核查工具来用。它也不是一个计算器，简单的数学计算都可能出错。它更不是一个流程引擎，无法保证百分百按照你的指令步骤来执行

知道了它的短板，我们就能在产品设计中主动规避。需要精确事实的地方，我们就应该去调用知识图谱或者数据库，而不是让模型自己去“想”。需要强流程保障的业务，我们就应该继续使用传统的、基于规则的系统，而不是盲目地用AI去替代

幻觉不是Bug，而是特性

这一点我必须反复强调。很多刚接触AI的PM，看到模型胡说八道，第一反应就是“这里有个Bug，快让算法去修一下”。这是一个根本性的误解

幻觉，是模型生成式本质所带来的内生特性。它之所以能有创造力，能写出优美的诗歌，就是因为它不是在“查找”答案，而是在“生成”答案。这个生成的过程，充满了随机性和可能性，也就必然伴随着“脱离事实”的风险。创造力和幻觉，是同一枚硬币的两面

理解了这一点，你就不会再想着去“消灭”幻觉，而是会去思考如何“管理”幻觉，如何设计产品来容纳和引导这种不确定性。你的整个设计思路都会发生根本性的变化

对模型行为有预期，是AI PM的必备素养。这就像一个赛车手，他不需要自己会造发动机，但他必须对自己的赛车在不同路况下的性能、极限和脾气了如指掌，才能做出正确的驾驶决策

不理解模型幻觉的 PM，本质上是在用不确定系统，做确定性承诺

这无异于在悬崖边上跳舞，既不专业，也不负责。所以，别再把“我不懂技术”当借口了。花点时间，去了解你每天打交道的这个“伙伴”吧，这会让你成为一个更合格的AI产品经理

六、如何设计「不确定性交互」

前面我们聊了，AI产品的核心特征之一就是不确定性。这就带来一个直接的问题：我们该如何为这种不确定性设计交互？过去那些基于确定性逻辑的交互范式，很多都不再适用了

什么是不确定性交互？我自己的理解是，它是一种承认结果并非唯一、过程比结果更重要的交互方式。它的核心，不是替用户完成任务，而是辅助用户更好地完成任务

这要求PM在设计思路上有一个巨大的转变：从“告诉用户结果”，转变为“和用户一起逼近结果”

过去我们做搜索，用户输入关键词，我们给他一个结果列表，交互就结束了。我们是在“告诉”用户答案。但现在，一个好的AI产品，应该是在用户提出一个模糊的想法后，通过多轮对话、澄清、修正，一步步地帮助用户明确自己的需求，并共同创造出最终的成果。我们是在“陪伴”用户寻找答案

这种“陪伴式”的交互，有几个我自己在实践中总结的设计原则，想分享给你

渐进式确认

不要试图一次性给用户一个完美的最终答案，那几乎是不可能的，而且风险很高。更好的方式是，把一个复杂的任务分解成几个阶段，在每个阶段都和用户进行一次确认

比如，用户想让AI写一篇关于“低碳生活”的演讲稿。AI可以先不着急写正文，而是先生成一个大纲，问用户：“您看这个结构可以吗？第一部分讲低碳生活的意义，第二部分讲具体方法，第三部分发出呼吁。您想对哪个部分进行调整？”

用户确认了大纲之后，AI再开始填充内容。在生成内容后，还可以再问：“我为您准备了三个不同的开头，您喜欢哪一个？”

这种一步一确认的方式，就像在盖房子的时候，每砌一层墙都用水平仪校准一下。虽然慢了一点，但能确保最终的房子不会盖歪。它把一次性的“豪赌”，变成了一系列小步快跑的“微调”，大大提高了最终结果的可用性

人机协作

好的AI交互，不是让机器取代人，而是让人和机器各自发挥长处，形成互补。我们要思考的，不是“AI能为用户做什么”，而是“AI和用户在一起，能做什么”

AI擅长发散、生成和关联，但不擅长判断、审美和把握分寸。而这些恰恰是人类的长处。所以，交互设计的核心，就是建立一个能让用户方便地对AI的生成物进行“再加工”的场域

比如，AI生成了一张图片，产品应该提供方便的工具，让用户可以局部重绘、调整构图、修改色彩。AI生成了一段文字，产品应该允许用户像编辑普通文档一样，随意修改、增删。用户应该是那个最终的“主编”和“导演”，AI只是一个能力超强的助手

对了，还有个事情想说，这种协作感非常重要。它让用户感觉自己是掌控者，而不是一个被动的接收者，这对于建立信任和长期使用意愿至关重要

可回退、可修正

既然AI的输出不总是对的，那我们就必须给用户充分的“后悔药”。任何一步操作，都应该是可逆的

这不仅仅是一个“撤销”按钮那么简单。它意味着要保存好交互的上下文和历史记录，让用户可以随时回到之前的某个状态，从那里重新开始。比如，在一个AI辅助编程的工具里，用户尝试了AI给出的一个方案，发现行不通，他应该可以一键回退到修改之前的代码状态，然后告诉AI“这个方案不行，我们试试别的思路”

这种可回退、可修正的设计，给了用户探索和试错的勇气。他知道自己可以大胆地尝试AI的各种建议，因为即使走错了路，也总能找到回来的路。这种安全感，是不确定性交互设计的基石

我越来越相信，好的 AI 交互，不是替用户做决定，而是陪用户做决定

我们的角色，从一个高高在上的“上帝之手”，变成了一个在用户身边，随时准备搭把手、出主意的“副驾驶”。这种角色的转变，需要我们放下对“完美”和“终极”的执念，拥抱过程、拥抱合作、拥抱不确定性本身

结语：Transformer 之后，PM 正在设计可控的不确定性系统

写到这里，我们一起回顾了AI时代PM工作边界的几个重要移动

我们的工作重心，从定义具体的功能，转向了划定更宏观的能力边界。我们不再纠结于画出每一个步骤的流程图，而是专注于设计影响模型行为的输入与输出约束。我们不再满足于将需求拆解为功能点，而是致力于将用户的模糊目标抽象为机器可执行的核心能力。我们也不再将失败视为需要消灭的异常，而是开始为不可避免的失败设计周全的兜底体验

这些变化的背后，贯穿着一条清晰的主线：我们正在从设计一个“确定性”的系统，转向设计一个“不确定性”的系统

这个转变，从根本上重塑了产品经理这个角色

过去，我们是功能的管理者，是流程的守护者，是确定性的捍卫者。我们像一个精密的钟表匠，确保系统的每一个齿轮都严丝合缝，准确无误

现在，我们更像一个生态系统的设计师，或者一个乐团的指挥。我们不再直接控制每一个元素的具体行为，而是通过设定规则、提供养分、营造环境，来引导整个系统涌现出我们期望的、和谐而富有生命力的结果。我们追求的不再是绝对的稳定，而是动态的、可控的平衡

我们正在从一个功能管理者，蜕变为一个真正的智能系统设计者

这无疑对我们提出了更高的要求。我们需要懂一点技术，理解模型的脾气；我们需要懂一点认知心理学，理解用户在面对不确定性时的反应；我们更需要有强大的系统思维和抽象能力，才能在模糊和混沌中，找到构建产品的脉络

这很难，充满了挑战，也让我时常感到焦虑和迷茫。但同时，我也觉得前所未有的兴奋

因为我们正处在一个前所未有的创造性时刻。我们手中的工具，不再是冰冷的、固定的逻辑，而是充满了可能性、能够与我们共同创造的“伙伴”。我们设计的，也不再是一个个被动响应的程序，而是一个个能够主动理解、生成、甚至带来惊喜的“智能体”

我想，这就是我们这一代产品经理的机遇和使命

Transformer 时代，PM 的核心价值，不是消除不确定性，而是让不确定性变得可理解、可干预、可承担

当我们能够设计出这样一个系统，它既能发挥AI强大的创造力，又能被人类的智慧和价值观所驾驭，让每一次不确定的探索，都成为一次安全而愉快的旅程。到那时，我们才算真正完成了自己的角色进化

这条路还很长，我们都还在摸索。希望今天的分享，能给你带来一些启发