「Prompt 就是 AI 时代的 PRD。」
AI 时代的产品设计该如何做？微软首席产品官 Aparna Chennapragada 近期在接受 Lenny’s Podcast 的访谈时，分享了当下对于 AI 驱动产品开发的看法。
Aparna 提到，Prompt 正在取代传统的 PRD，成为构建产品的起点；NLX（自然语言交互） 将成为新的用户体验设计范式；同时， Aparna 用自主性、复杂性、自然交互解释了 Agent 的核心特征。
Aparna 认为，Agent 本质上是一种工具，未来可以把更多任务交给 Agent 来做。「好品味」 和 「编辑能力」 才是产品经理的关键。
TLDR:
我认为，自主性、复杂性和自然交互，这三点至少是构建优秀 Agent 的产品设计原则。
未来，如果 AI 的推理能力继续提升，我们就可以把更多任务交给 Agent 来做。所以我认为，Agent 本质上是一种 「能够自主执行任务的独立软件进程」，它已经不仅仅是完成那些细碎的操作或需要你一步步指导的事情了。
在当下这个时代，如果你在做一个东西，却没有原型验证、没有实际动手去试，那你就是走偏了。我现在常说，Prompt 就是新的 PRD。我会特别要求团队在推进新项目或功能时，不光要写文档，还要拿出原型和对应的提示词集合。
我觉得 「品味」 和 「编辑能力」 会变得越来越重要。在一个创意和原型数量都大幅增加的世界里，你必须思考，谁来做内容的筛选和编辑？所以这会让产品经理的门槛变得更高。
如果你正在做一个从 0 到 1 的新东西，太早设定指标反而是种 「伪精确」。比如说点击率（CTR），你只有一千个用户，这指标根本没意义；留存率也一样，不一定能说明问题。所以我经常提醒大家，要小心那些 「看起来很专业、很成熟的指标」。
不管是在硬件还是软件上，想要做出一个真正好的产品，通常至少要满足下面三个关键转折点中的两个。第一个是技术层面的飞跃，第二 是用户行为的变化，第三是商业模式的变化。
构建优秀 Agent 的三个原则
主持人：现在有一个很重要的主题就是 Agent。我知道你现在在微软也主要在负责这块。现在感觉如果一家 AI 公司不搞 Agent，就好像根本不是一家 AI 公司。很多人其实还搞不太清楚，这到底意味着什么？它会带来哪些改变？你能不能帮我们稍微描绘一下，在一个到处都是 Agent 的世界里，你觉得会有哪些不同？
Aparna：我觉得这件事要分短期和长期来看。现在很多人热衷讨论那种遥远的未来，但我更倾向从 「实际做产品」 的角度来思考。说到底，Agent 本质上还是一种工具，对吧？当然，它们的底层不是传统的那种确定性编程模型，而是基于概率的随机模型（stochastic models）。
你大概能看出我是学计算机出身的，种思维方式确实深深影响了我看待这类技术的方式。在我看来，短期内我们正处于一个过渡期，从 「应用程序」 时代进入到 「助手」 时代。现在还是人类掌控主导权，但 AI 已经在充当强力辅助，就像我们现在所说的 Copilot 一样。
我觉得我们现在处于一个 「人类坐在驾驶座、AI 在副驾协助」 的阶段。但未来，如果 AI 的推理能力继续提升，我们就可以把更多任务交给 Agent 来做。所以我认为，Agent 本质上是一种 「能够自主执行任务的独立软件进程」，它已经不仅仅是完成那些细碎的操作或需要你一步步指导的事情了。
你只需要告诉它目标：「我要达成这个目标」，它就能自己去搞定。
比如说，我们最近在做一个职场研究型 Agent。昨天晚上我跟它说：「我接下来要开一个很重要的领导层会议，我想展示几个框架，还有这份产品路线图。你去看看参会的每个人都是什么背景，他们在这个议题上有什么观点，然后帮我想想我该怎么去说服他们。」它的 「神奇」 之处不仅仅是节省时间。
以前我们说 AI，主要是说它可以帮你总结文档、节省时间，对吧？但这个不一样，它像是在帮我打通我脑子里没有连上的「突触」，给我带来了新的见解，甚至可以说，是给了我 「超能力」。我觉得这就是 AI 很自然的发展方向。
所以当我思考 Agent 这个概念时，我脑中会浮现三件事。
第一，是越来越高的自主性和独立性，你可以把更高级的任务交给它。
第二，是任务的复杂性。它不再只是 「一步到位」 地做个图、写段文案或总结个文档，而是可以帮你做更复杂的事，比如说：「帮我做一个能表达我这个增强现实 App 想法的原型」。这就是复杂任务。
第三，就是异步性。这些工具可以在你不工作的时间继续运行。我觉得这是它们另一个巨大的优势——你不必一直坐在它面前盯着它。
主持人：你刚刚说的这三点，其实就回答了 「什么是 Agent」 这个问题。你能再简单重复一下是哪三点吗？
Aparna：当我思考 Agent 的时候，我主要关注这三点。
第一是「自主性」，而且这是一个连续谱，不是非黑即白的问题，关键是我能把什么样的任务委托给它。
第二是「复杂性」，Agent 不是那种一次性任务，比如 「总结这篇文档」 或者 「生成这张图片」。而是可以完成像 「给我做一个原型」 或者 「帮我把这场会议搞定」 这样更复杂的事情。
第三是 「自然的交互方式」。这不只是打字聊天，而可能是我和 Agent 一起开个会，实时讨论问题，或者我可以直接指出我希望修改的地方。
所以我认为，自主性、复杂性和自然交互，这三点至少是构建优秀 Agent 的产品设计原则。
自然语言交互，
其实没那么简单
主持人：你之前还跟我提过一个缩写词 NLI。我想聊聊这个，它和 Agent 有什么关系？为什么现在很多人还没重视这个？
Aparna：这是我现在脑子里老在想的一件事情。NLI 代表自然语言界面（Natural Language Interface），我觉得它是新的终极用户体验（UX）。
我们以前之所以会非常认真地去设计图形用户界面（GUI），是因为图形界面不够自然，它们必须被明确设计出来，但也因此比较僵硬。而自然语言或对话式界面就灵活多了，但这不代表它们不需要设计。
我经常听产品经理说：「AI 出来了，模型主导产品就行了。」 但实际上不只是 「你和它聊天」 这么简单。你看，我们现在是在播客里对话；我等会儿在微软开会，那也是一种对话。
对话也是有 「语法」 的，有 「结构」 的，也有 「界面元素」，虽然这些东西是看不见的。
所以我特别感兴趣的一件事是：在自然语言成为界面的今天，有哪些新的设计原则和新组件正在出现？
举几个例子，其实现在很多初创公司和大公司都在尝试这些东西。首先，提示词本身就是一个新的设计组件。它就像过去的下拉菜单或者导航栏一样，是一个全新的用户界面元素。
对于 Agent 来说，另一个新的交互组件是 「计划」。当你给它一个宏观的目标，它会生成一个 「计划」，而且最好这个计划是可以修改的，这本身就是一种全新的交互方式。
还有一个我经常思考的点是 「展示过程」。也就是 Agent 的思考过程要不要给你看？你现在已经能在很多产品中看到这点，比如 Copilot、ChatGPT 或者 DeepSeek，它们会 「边想边展示」 自己的思路。
但问题是：展示多少才合适？如果说得太多，就像在看一个跑脚本一样，会让人烦；但如果太少，又会让用户没有信心、不知道它到底在干嘛。所以这些都是新的设计元素。对一个产品设计师来说，这块真的是一个非常有趣的新领域。
主持人：大多数人在和聊天机器人对话时，可能会觉得 「这天生就是这样」。但其实这是你们精心设计的交互细节，比如 「到底展示多少思考过程」、比如 「该不该先展示一个计划，问问用户觉得怎么样」。我觉得很多人听了会很惊讶，原来这些看起来简单的对话背后，有这么多设计在里面。
Aparna：是啊，还有一个很好的例子就是 「追问」 功能。比如你问我一个问题，然后我可以接着追问一些相关的细节问题，这些 「追问」 其实也是要被明确设计出来的。
如果我说：「帮我生成一张图片」，结果生成的是一张黑白剪影风格的图，那系统应该主动问我：「你是想要彩色的吗？」 或者 「你要换风格吗？」 这些追问是可以预测到的。但如果它问太多问题，就会让人觉得烦；但如果完全没有追问，那就等于放弃了引导用户走向理想结果的机会。
主持人：这个让我想到之前我们采访 Kevin Weil（OpenAI CPO） 的时候，他也聊到这个问题，「到底要展示多少 AI 的思考过程」。有趣的是，DeepSeek 选择了全部展示，用户反而觉得很好。
Aparna：对，我觉得这是当前阶段的一种适应方式。因为现在这些系统本质上还是黑盒，所以就像你能 「偷偷看它内部在想什么」，哪怕它说得很多，用户也会觉得 「我大概知道它在干嘛」，尤其是它推理过程还挺慢的。如果什么都不展示，系统安静几秒，我就会感到不安。
所以现在这个阶段，展示过程确实能提升体验。但从长远来看，我觉得这里会有很大的个性化空间。就像人与人之间的交流，我的 「接口偏好」 可能和你的完全不一样。有些人可能就喜欢直接给个 TL；DR（总结），而不是那种 「我先去这儿，然后又去了那儿」 的详细描述。
Prompt 就是新的 PRD
主持人：现在我们讲到了为对话体验设计界面、讲到了 Agent，但如果我们把视角再放大一点，回到整个产品开发流程的未来。你现在站在很多未来工具的前沿，而你的团队也在用一些别人还接触不到的新工具。你怎么看未来的产品开发会和现在有什么不一样？产品经理应该怎么准备，才能在未来做出成功的产品？
Aparna：我想先说一句我在公司内外反复强调的话，而且我自己也在认真践行。在当下这个时代，如果你在做一个东西，却没有原型验证、没有实际动手去试，那你就是走偏了。
我现在常说，「Prompt 就是新的 PRD（产品需求文档）」。我会特别要求团队在推进新项目或功能时，不光要写文档，还要拿出原型和对应的提示词集合。
这并不是说每个人都要变成更厉害的软件工程师，而是说：你现在已经可以用最快的方式把脑中的想法变成可见的、可体验的东西，这是一种信息密度更高的沟通方式。
我觉得这可以大大加快产品开发中的反馈迭代速度。这是第一点。以前有人说，「Demo 优先于 Memo（文档）」，我完全同意。
第二点可能稍微复杂一些，就是我现在看到的一个趋势：从想法到第一个 Demo 的时间变短了，但从 Demo 到全面上线的时间却变长了。所以节奏是 「不均匀」 的。以前你可能花几周时间做个功能，然后上线。但现在，从原型、迭代，到用 AI 做用户研究，这一套 「内部循环」 会变得很快。
真正要做到大规模上线，门槛也会更高。你可以把它想象成创意和原型的 「供给量」 大幅上升了。这当然是件好事，它提升了 「基础水平」，但同时也拉高了 「优秀的门槛」。
在这样的环境里，如果你想真正脱颖而出，就必须确保你做的东西能突出重围、不被淹没在噪音中。所以不能每个点子都去追，这是我想讲的第二点。
第三点是现在大家都在讨论 「全栈构建者」 这个概念，未来的产品团队会是什么样子？我认为在原型设计和早期探索阶段，确实会有一些 「界限模糊」 的人，他们可以在设计、产品、工程之间自由切换，扮演品味决策者的角色。
与此同时，团队中还是可以有很多人参与实验。但越是这样，就越需要有一两个 「核心判断者」，能够把控方向和品味。否则，你很容易做出一个四不像的「拼接怪物产品」。
最后我想额外补充一点。很多人现在会说 「以后都不需要学计算机了」「写代码已经没用了」。我完全不同意。实际上，计算机编程本来就是一直在往更高抽象层演进。我们早就不写汇编了，大多数人连 C 都不怎么用了，现在都是在更高层抽象上开发。
未来你依然需要告诉计算机你想让它干什么，只不过这种表达方式会更高阶。这很好，它可以让更多人参与到软件构建中来。未来可能会出现更多 「软件指挥者」 而不是 「软件工程师」。
但这不代表你就不需要理解计算机科学。因为编程不仅是一种技能，更是一种思维方式和认知模型。所以我非常不同意 「Coding 已死」 这种说法。
主持人：我很喜欢这个说法。 你刚才说的 「软件指挥者」，是这个意思吗？
Aparna：对，我就是随口说出来的（笑）。
主持人：很酷。你刚才说 「原型设计」 现在已经变成了产品构建的核心部分之一，那在微软，你们有没有什么机制来让这变成一种标准流程？比如说，是靠文化推动？还是说你真的会要求团队在跟你汇报之前必须先做出原型？
Aparna：我觉得吧，就像那句话说的，「未来已经到来，只是分布不均匀」，就连在微软内部也是这样。但确实现在文化上有一个很明显的趋势和动力，那就是我们越来越倾向于看实际的演示和原型，甚至把原型当作一种沟通方式。我个人认为这很重要。
虽然不是所有情况都能做到，比如说，如果你要改动的是 Excel 深层结构里的东西，那产品已经非常成熟了，你很清楚该怎么做，也不需要再去做原型。但如果你是在做新的产品、新的功能，那当然应该做原型。
产品经理：
要学会AI 的本能式使用
主持人：自从这些 AI 编码工具出来之后，很多人就开始担心产品经理是不是要被淘汰了，觉得我们自己就能写代码做产品了，还要 PM 干嘛？但我发现，实际情况正好相反。
现在代码更容易写了，反而更重要的问题变成了：我们该做什么？为什么要做？这个解决方案对不对？我们该怎么推动它落地？而这些正是产品经理最擅长的事。
所以我反而觉得，PM 的价值更高了，当然角色也会变化。你怎么看未来产品管理的走向？你觉得这个岗位会被淘汰，还是会变得更重要，或者会转型？
Aparna：我的看法是这样，如果你只是一个天天填 TPS 报告、只做流程管理的 PM，其实很多公司也确实会把产品管理和流程管理、项目管理混淆，那在这种情况下你确实得问问自己，你的价值到底在哪里？
特别是现在 AI 能读写五万条会议记录、能跟踪任务、发邮件等等。但从另一个角度看，我觉得 「品味」 和 「编辑能力」 会变得越来越重要。在一个创意和原型数量都大幅增加的世界里，你必须思考，谁来做内容的筛选和编辑？所以这会让产品经理的门槛变得更高。
但我在自己参与的初创公司，甚至在我所在的公司内部，也观察到一个有意思的现象：以前大家总觉得有什么点子都得先问产品经理，产品经理像是在 「把关」。现在这种情况变了，产品经理想要有决策权，不是因为你的头衔是 「产品经理」，而是得靠真本事。
现在很多聪明的工程师、用户研究员、设计师，他们以前可能缺乏某些技能，但现在有了 AI 这样的 「随身专家」 作为补充，他们就能把自己的点子完整地表达出来了。我觉得这真的非常棒。
主持人：确实，我现在和一个工程师一起合作项目，他甚至会用 ChatGPT 帮他优化表达方式，比如 「把这个点子写成一个能说服 Lenny 的版本」。
Aparna：说到这个，其实我自己也经常用这个方法，我给它起了个名字叫 WWXD，意思是 「What Would X Do」，「X」 是某个人名。
比如我经常会问：「Satya（微软 CEO）如果看到我们这组讨论或这个提案，他会怎么想？」 我觉得这就是 「推理能力」 加上 「上下文」 的结合。这就像你说的那个工程师，他了解你，所以他能用 AI 把信息包装得更适合你。
主持人：要是每个人都像 Satya 一样有那么多公开信息就好了（笑）。当然，你也可以导入他们的邮件、会议记录或别的资料，用现有工具建立起那种 「理解」。
Aparna：对，我觉得这正好呼应了你刚才提到的观点。我们现在的挑战之一是，AI 能力在短时间内大幅跃升，就像一个被压缩的弹簧突然释放了 「智能过剩」。而我们在做产品开发时，其实需要重新训练自己的思维方式来适应这种变化。
Shopify 的 CEO Tobi 提出过一个概念，叫 「AI 的本能式使用」，我觉得这其实挺难做到。我也一直在想为什么会这样。
就拿我自己来说，我装了一个挺土的 Chrome 插件，每次打开新标签页，它都会弹出来问我一句：「你现在要做的事，有没有可能让 AI 来帮你完成？」听起来挺傻的，但它确实能让我停下来想一想：「我现在到底在做什么？」
但我发现这之所以难，是因为 「更新你原有认知」 真的非常难。比如说，一年前这些模型还做不到很多事：图像生成老是拼错字、推理能力也很弱、数据分析几乎不行。所以你对它的印象是 「几个月前我试过，不行」。
但现在你需要推翻那个印象，重新认识它，这其实是很反直觉的。就像你得强迫自己忘掉 「它是个婴儿」，因为它现在已经像是 「一个一夜长成的 15 岁少年」。
主持人：我觉得你最后这个点特别重要。过去我们试用这些工具，常常觉得 「不行」「不够好」，久而久之就放弃了。但其实，它们已经变得非常厉害，只是我们没意识到而已。
Aparna：对，所以我觉得如果你是一个产品人，这是一个特别有价值的 「信息套利」 机会。你要敢于 「反常识」 一点，不要被过去的失败经验拖住脚步。哪怕你之前试了不行，也要敢于重新尝试，对 AI 提出更高的要求。你越敢期待它，越能激发它的潜力。
主持人：这个做法真有前瞻性，我很喜欢。
Aparna：没错。
主持人：我们回到你那个 「很土」的插件，说说更多细节。这个插件就是在每个新标签页上显示一句自定义提示，而你设置的是 「你能不能用 AI 来完成你现在要做的这件事？」
Aparna：对，就是这么土，但它确实有用。过去几周我一直在做个小实验，想看看我在工作和生活中能不能更充分地使用 AI。每当我准备做一件手动的事情，我就问自己：我是不是应该让 AI 来帮我完成？
主持人：太酷了。你还记得这个 Chrome 插件的名字吗？
Aparna：不记得了，我没记录下来。
主持人：是你自己做的插件？太酷了，用 AI 做的吗？
Aparna：当然是啦。我整天泡在 GitHub 上，用的就是 GitHub Copilot。我就想 「行吧，那我来写个 Chrome 插件」，然后就搞定了。
主持人：你打算把它开放给大家用吗？
Aparna：没有啦，但有意思的是我只花了 10 分钟就做完了。
做 0 到 1 的事情时，
不要着急扩大规模
主持人：在你做产品的过程中，有没有什么你学到的经验是特别反直觉的，和主流创业或产品开发理念相反的？
Aparna：我不确定这算不算真正意义上的 「反直觉」，但它确实不像听起来那么明显。我学到的一个教训是：当你在做一件从 0 到 1 的新事情时，人们总是很容易急着去考虑怎么扩大规模。就像《南方公园》里那集说的那样：第一步，弄清楚问题是什么；第二步，收集内裤（笑）。
主持人：哈哈，对，内裤那集。
Aparna：对吧（笑）？所以我一直在跟我的团队说，要 「先解决问题，再谈规模」。这两个阶段的姿态和工作方式完全不同。解决问题的阶段和产品已经找到 PMF 或者至少大致方向的时候，做法是完全不一样的。
我举几个例子吧。在 「解决问题」 的阶段，一切都很混乱，你必须接受并适应这一点。比如你第一天还在做 「植物识别工具」，到了第 15 天你发现这项技术其实更适合用来翻译外语。
这不是我瞎说的，这确实是我们当时在做 Google Lens 时经历过的。我们当时就在想，技术到底最适合用在哪儿？在外人看来这可能是一团混乱，但其实你不但要容忍这种混乱，我觉得你还得 「喜欢」 它。
因为最糟糕的情况就是你太早就把方向定死了，结果爬上了一座 「局部最优的小山」，最后被困在上面。很多初创公司、产品团队，甚至大公司都会犯这样的错。等到三年后回头看，才意识到 「糟了，当初走错路了。」
所以我觉得这就是一个非常关键的认知，你得搞清楚自己现在处于哪个阶段，是在 「解决问题」，还是在「扩大规模」。
我学到的另一个教训是要警惕 「指标」 的误导性。如果你曾经做过搜索或者 Office 产品，你可能非常清楚这些产品的关键指标是什么，有输入指标、有输出指标、一整套体系。
但如果你正在做一个从 0 到 1 的新东西，太早设定指标反而是种 「伪精确」。比如说点击率（CTR），你只有一千个用户，这指标根本没意义；留存率也一样，不一定能说明问题。所以我经常提醒大家，要小心那些 「看起来很专业、很成熟的指标」。
这个阶段你应该更关注一些 「定性的反馈」 或者 「用户的真实动作」。
比如你看看 Alexa、Siri、Google Assistant 这些语音助手，它们本来提供的是一个很通用的交互入口，你可以说任何话。但真正让用户觉得好用的，其实就那么一两项：设定时器、播放音乐、做个小问答游戏。所以你得先把这些核心功能打磨好，再去谈 「它可以干任何事」。否则就是一种误导。
主持人：这正好就是我用 Google Home 的方式，真的很基础。
一款好的产品要满足这三点
主持人：你之前还提到过一个类似的话题，就是关于如何从 0 到 1 开始做一件事。你好像有一套小框架，可以帮人判断某个想法是不是时候开始做了。你是怎么考虑这个问题的？
Aparna：对，当你思考 「解决问题模式」 时——这也跟我之前讲的 「活在未来一年」 这个思路有关——我自己非常倾向于做从 0 到 1、属于 「解决阶段」 的产品，专注于构建全新类别的产品。
我发现，不管是在硬件还是软件上，想要做出一个真正好的产品，通常至少要满足下面三个关键转折点中的两个。
第一个转折点是技术层面的飞跃，这一点其实相对明显。比如在 Google Lens 项目中，深度学习就是一个很大的技术突破。又比如语音识别技术的发展，是推动对话式搜索的关键。对 Robinhood（一个免费的股票 App） 来说，它的关键点在于代际更替，以及手机成为主力设备，金融服务开始可以通过移动 App 来完成。
所以，你要去观察这些技术转折点。现在的例子当然就是 LLM 和推理模型，它们引发了当前的技术飞跃。但光有技术还不够。
第二个要素是用户行为的变化。举个例子，我们当初在做 Google Lens 的时候就发现，用户最初拍照主要是为了分享，比如自拍、拍风景。但当手机的存储空间基本免费，人人随身带着手机时，人们就开始随手拍一切。于是我们有了大量的照片，摄像头也变成了人们与现实世界交互的 「键盘」。
这就说明了一个用户行为的巨大变化。当照片数量呈指数级增长，人们自然希望能从中获得更多价值，而 AI 正好可以应用到这个场景中。
我认为第三个转折点，尤其是在企业场景中，但在消费领域也同样重要，就是商业模式的变化。有没有在商业模式上的自然转变？
比如说，从搜索广告到竞价机制（second-price auction），从点击付费（CPC）开始，这就开启了新的商业模式。又比如 SaaS 的崛起，也让我们可以用全新的方式向企业收费。而在 AI 时代，我们的变现方式又会是完全不同的。
现在我们可能只是刚刚开始探索，比如按照 「座位数」 收费，或者按照使用量收费，甚至可能出现 「按结果付费」 的模式，你帮我解决了问题，我再付钱。所以这三种转折点都很关键，但至少你得占两个，才能支撑起一个好产品。
主持人：你说的其实就是投资人常问的 「为什么是现在」 这个问题。你的建议是可以从三个角度来看这个问题：第一，是否有新的技术出现并使这个产品成为可能；第二，用户行为是否发生了改变；第三，是否存在或你是否发明了一种新的商业模式，让你比别人有优势。说得太好了。刚才你还提到 Robinhood，这也是个很好的例子。
Aparna：对，Robinhood 的商业模式也是一个关键因素，比如 「零佣金」。再加上前面提到的其他因素，这些组合在一起才能真正释放出潜力。你不能只靠一个更漂亮、更直观的界面，就指望用户会因此转换过来。
大公司落地 AI，
要鼓励 「先行者」
主持人：你职业生涯的大部分时间都在消费级互联网公司工作，比如 Google 和 Robinhood，你还是 eBay 和 Capital One 的董事会成员，现在到了微软。我挺好奇的，在微软这样的公司里做产品，和你过去的经历相比，最大的不同是什么？
Aparna：说实话，我原本就知道企业级业务会不一样，尤其我现在在微软关注的重点是企业和生产力领域，还有如何通过 AI 让公司实现转型。
我觉得有两点特别不同。第一，我前几天刚发了个帖子讲这个事情，在做消费类产品时，你好像有一本 「说明书」 可以照着来，让功能能用，让人们喜欢产品。但在企业场景下，每次你以为只是在做一个功能，其实你得同时处理两件事：不仅要让这个功能好用，还要确保它在治理和合规方面也能站得住脚。
就拿 「分享一个文档链接」 这么简单的事来说吧，你当然希望这个过程顺畅、无障碍，但你同时也得保证它是安全的，有权限控制、有审计能力等等。很多时候，当你从消费级产品转向企业级产品时，很容易掉入一个陷阱：要么完全忽视这些合规问题，只关注用户体验；要么为了合规把用户体验彻底牺牲掉。
所以，这里面其实也有一套方法论，是一种兼具艺术与科学的方法，这是我在这过程中学到的一个重要经验。
第二个很不同的点，尤其是在 AI 时代，对我来说就像这样，你还记得 2010 年左右那个很有名的广告吗？ 尚格·云顿站在两辆正在行驶的卡车之间劈叉的那个。
主持人：我记得。
Aparna：对，就是那个。我觉得现在很多公司，尤其是科技公司，还有我接触到的各类企业，也都处在这种状态。一方面，我们正经历史上节奏最快的技术变革周期，从前是以年、十年为单位，现在是按 「周」 和 「月」 在推进。你想想看，从移动互联网、云计算到现在的智能化发展，整个技术进步速度飞快。
但与此同时，还有另一面，那就是人类的行为习惯，比如工作效率相关的习惯，其实很难改变。企业内部的变革管理也是一个难题，你不能操之过急。
所以说，未来的发展不会在每个人或每个团队中同时发生，哪怕在同一家公司内部，也会有人走在前头，有人还在后面。
主持人：尚格·云顿站的另一辆卡车，治理、推广和行为改变这块，关于如何推动这部分进展，你有没有什么经验或者教训？
Aparna：我学到的一件事就是：千万别拖住那些 「早期采用者」 的脚步。我觉得这是特别重要的。
实际上，我们最近在做的一件事就是尝试 「两手抓」，一方面是着眼长期，稳妥地做变革管理；同时也做了一个叫 Frontier 的项目，推出一些前沿的、实验性的功能。里面有我们刚刚构建的一个全球领先的 Agent，是一个为工作场景打造的深度研究 Agent，专门针对工作场景做了后训练。
当然，这个工具现在还有很多不完善的地方，但如果企业里或者外部有愿意尝鲜的用户，我们就希望能让这些人先用上它，而不是非要等到整个公司都准备好了再上线。这样也能慢慢培养出一套新的能力。
主持人：你刚刚提到的这个 Frontier 项目，我想多聊一聊。这个想法是不是说，让人们在一个 「有未来感」 的环境中工作？它到底是怎么运作的？
Aparna：核心想法正是这样。我希望能把我个人 「活在未来一年」 的工作方式变成一种制度化、可执行的模式。比如你可以想象有一家名叫 Frontier Consulting Group 或 Frontier Inc 的公司。
如果你真的生活在这样一个环境里，拥有所有 AI 工具和非常先进的深度研究智能系统，你会提出什么样的问题？你会做什么样的工作？你的一天会怎么安排、工作方式会怎么变化？这就是这个项目的出发点。你可以从个人角度来看它带来了什么变化。
但从更长远来看，我们也想探索一下：一个 「前沿团队」 到底长什么样？我们现在常常谈论 「前沿实验室」 和 「前沿模型」，模型这一层当然非常厉害，而且它正是推动所有产品构建发生的基础。
但我想进一步推进我们的思考，那个 「前沿产品」 应该是什么样？更重要的是，「前沿的工作方式」 是什么样的？比如一个只有三个人的团队，配备强大的计算资源和 AI 工具，它的工作模式该是什么样？
主持人：那它具体是怎么运作的？是微软内部有一个团队，他们的职责就是用最新的工具去构建产品吗？
Aparna：没错，这就是我们目前正在做的事，我们才刚刚开始这套设定没多久。但同时，我们其实已经设立了一个外部的 「虚拟公司」，然后我们说：嘿，如果你是那种想来体验最前沿科学项目的人，想当个研究型 Agent、或 「职场 Agent」，那就来这里一起「玩」吧。
主持人：哇，才进行几周啊，好吧，那还要看接下来会怎么发展。
Aparna：是的。其实这背后还有一个更大的思路转变。在传统模式下，不管是在哪家公司、哪个行业，推出新产品通常都是采用 「宏观式发布」 的方式：你先把产品开发完成，再逐步推出，等到达所谓的 「全面可用（GA）」 阶段，再正式推广。
这种方式当然也非常重要，特别是我们的客户里包括像制药公司、律所这样的企业，他们对这些工具的依赖性非常高，所以我们肯定还是会继续沿用这种方式。
但与此同时，考虑到 AI 发展节奏极快，我们也得思考，怎么让人们先体验到 「未来一年」 的工作方式。
Copilot 的护城河：
大家都会回到 Github
主持人：现在有一些公司，比如 Cursor、V0、Lovable、Bolt、Replay，它们的增长速度可以说是史无前例的。我刚看到 Cursor 在两年内 ARR（年度经常性收入）达到了 3 亿美元。
有意思的是，其实你们原本在 AI 编码工具这个领域拥有非常明显的先发优势。你们最早推出了 Copilot，是全球第一个涉足这个领域的工具，起步比谁都早；你们还开发了 VS Code，如今很多公司都是基于它做二次开发；再加上你们有顶级的 AI 基础设施和人才资源。
按理说，这块市场应该属于你们才对。后来发生了什么？
Aparna：这个问题的角度挺有意思的。其实我自己就是 GitHub Copilot 的重度用户。我觉得我们可以来拆解一下：代码生成已经成为了 LLM 带来的一个非常强大的新能力。
所以这股热潮本身是件好事，它让原型设计成为现实，从一个想法，到代码，再到一个可以点按交互的原型，只要几分钟时间。这就是代码生成所能带来的强大支持。
而在我看来，我们在 GitHub 所做的事情，不只是开发一个产品或一组功能，而是在构建一个系统。
比如说，GitHub 本身就是为开发者准备的仓库平台。你可以在这里用自动补全、聊天等助手功能，而现在我们还引入了 「Agent 模式」，这是我们反馈最积极的功能之一。
所以，当你构建的是一个系统时，你追求的不只是某个功能本身的成长，而是整个上下文，你的代码仓库是什么？你在哪些领域具备专业能力？这个系统要能适配不同用户的水平，比如你是高级开发者，它就应该为你提供更高级的助手能力；你是前端开发者，也要一样适用。这就是我们为 GitHub 所设定的发展方向，而且现在发展得很好。
主持人：这个思路很有意思。也就是说，最后无论开发者用什么工具，他们最终都还是会回到 GitHub，对吧？
Aparna：对。而且我觉得，代码生成的崛起会催生出一整套全新的开发产品。竞争者做的并不是完全一样的事。但只要你是在为企业生成代码、让代码真正落地运行，你就必须有一个完整的系统支持。这不仅仅是自动补全，不仅仅是聊天功能，也不仅仅是一个你要手把手指导的 Agent，而是所有这些东西要一起协同工作。这正是 GitHub 产品所要实现的目标。
主持人：所有的路，最终都通向 GitHub。说到这个问题的另一面，大概已经有五千家创业公司试图颠覆 Excel，但微软这边总能稳稳地守住。说明这里确实有些东西做得非常对。
Aparna：你说这个太有意思了。我刚加入微软的时候，作为一个 Excel 爱好者，我还专门去找了一位资深的 Excel 产品老员工聊天。我问他，到底是什么让这个产品这么特别？他说了两点让我印象特别深。
第一，他说 Excel 是最有力的证明，说明不写代码的人，其实也需要编程。编程是一种非常强大的能力，而 Excel 就是把这种能力交到了非程序员手里。我觉得这个观点特别打动我。
第二个我觉得特别酷的是，我之前完全不知道，直到两年前才知道，原来世界上还有 「Excel 世界锦标赛」，参赛者们用 Excel 能做出非常神奇的东西。
这让我意识到一个很重要的点：有些工具虽然上手门槛高，学习起来可能有点陡峭，但一旦掌握，它们的使用体验就非常好。所以 Excel 是一个典型例子，它的学习曲线可能一开始有点难，但那是因为它真的有强大的功能和深度。
主持人：太有意思了，我从来没把 Excel 当作一种编程语言来看，但想想其实也说得通。我感觉一旦你习惯了它，它就成了你默认的工作方式，其他工具基本只能模仿这个模式，但很难做的同样好。
Aparna：是啊，我觉得这也归功于团队几十年来持续不断的投入与打磨，这是复利效应的体现。产品之所以强大，是因为有一群每天依赖它的人不断在给出高质量的反馈。
构建能「跟得上趋势」的
创新产品很重要
主持人：好，现在我们来聊聊你个人的职业路径。我发现很多人都会在某个时刻经历一次真正改变职业轨迹的关键转折点。可能是遇到了一位重要的经理，可能是参与了某个项目，或是得到了某份工作。对你来说，哪一个瞬间最具转折意义，最终促成了你成为微软的首席产品官？
Aparna：确实有那么一个时刻对我来说是转折点。当时我还在 Google，正在做一个我特别看好的项目，我觉得这个点子理应能成。
我当时想，手机正在兴起，个性化一定会变得很重要。我在这个方向整整钻研了一年，但就是做不出来效果。比如用户在搜索时输入一个查询，个性化其实并不会对结果产生太大影响。最终我们解散了这个团队。
但后来我开始做一个叫 Google Now 的产品，它是对之前方向的一个转变。我们不再只是想 「用搜索做个性化」，而是认为手机端可以主动推送内容。
比如说你有一趟航班，那系统就该能自动识别出来，并根据交通情况提醒你什么时候该出发；或者你特别喜欢冷幽默的单口喜剧演员，那系统就应该推给你 Mitch Hedberg（美国的单口喜剧演员）。这种智能提醒才是 「智能手机」 应该具备的能力。
我带领这个产品经历了从 0 到 1 的整个早期阶段。这个经历让我意识到两件事：
第一，我真的很喜欢 「看见转角后的未来」，喜欢去构建那些能 「跟得上趋势」 的产品，而不是继续维护一个已经成型的产品。
第二件事虽然听起来有点残酷，但我确实体会到 「太早」 其实和 「做错了」 是一样的。那时候还没有 LLM，还没有深度学习，我们其实已经在设想 「预测下一个词」 的这种智能体验了，但那时候我们没有足够的算力，智能跟不上。界面已经很不错了，但智能还没到位。
第三点让我印象深刻的是，我有机会跟一群非常聪明的人一起共事。现在大家都在讲 「人才密度」，而我在那个团队就真实感受到了。这些人后来都去做了非常厉害的事，那让我第一次体会到 「少数人可以创造巨大影响」。
主持人：这个故事太棒了，因为它本质上是一个 「失败的经历」。Google Now 最终也没留下来，对吧？但我对这个产品印象很深，它真的很棒，让人觉得又实用又愉快。我在播客里有个固定板块叫 「失败坐标系」，嘉宾可以分享一个失败经验，以及它带来了什么。我觉得你的故事刚好兼具两者。
Aparna：是啊，说实话，这种经历确实挺痛苦的。你脑子里已经构想出了一个很美好的愿景，但现实却达不到。限制可能是技术，也可能是时间点太早了。有时候你需要等五年、十年技术才真正成熟。而有时候也许只差那一两步，产品就能突破。所以你得学会判断自己到底处在哪种情形。
主持人：那你从开始做这个项目，到决定放弃，中间持续了多久？
Aparna：其实我不觉得那是完全结束。好的一面是，它为后来的 Google Assistant 奠定了基础。而现在 LLM 实现了技术飞跃，比如 Gemini 就让这些设想变成现实。我觉得这就是一种延续，你要找出那些 「不会变的要素」，把它们带到下一个版本的产品中。有时候你得重启，但也有时候，是在原来的基础上继续。
主持人：说起来，Google Now 就像是 「Agent 之前的第一个 Agent」。给人的感觉是它早就想做这件事了。
Aparna：对，这的确就是当时的想法。有趣的是，那时候我们的问题刚好和现在反过来。你看所有语音助手，其实当时的问题是，界面设计得很好，但智能跟不上。而现在正好相反，我们拥有了非常强大的智能，但界面却还停留在 「拨号时代」 的 Chatbot 模式。
未来产品体验的新趋势：
人与 Agent 协作
主持人：我问了很多和你共事过的人，想知道他们觉得我应该问你些什么、你有哪些特别之处。有一件事大家都不约而同提到了，而且我猜很多人其实并不了解，那就是你其实很喜欢做单口喜剧（stand-up comedy），而且还挺认真的。到底有多认真？它在你生活中占了多大部分？最重要的是，它怎么帮助你打造更好的产品？
Aparna：我算是个认真对待 「搞笑事业」 的人。我确实会看，也会表演单口喜剧。我去过 Open Mic（开放麦，一种练习脱口秀的活动），也参加过一些正式演出。我现在正在准备一个新的段子，当然是跟 AI 有关的，讲 AI、科技和硅谷的那些事儿。
其实这是我偶然发现的一件事。我一直都很喜欢看 SNL（《周六夜现场》）和各种喜剧节目。后来有一次我儿子去参加 Open Mic 唱歌，他跟我说：「妈妈，你也上去试试看吧。」 我就试了一下，结果发现我不仅很享受这个过程，而且好像还挺擅长的。
你问到这对我做产品有没有帮助，其实我觉得两者都讲求 「PMF（产品市场契合度）」，开玩笑地说就是 「笑点市场契合度」（punchline market fit）。不过说真的，这里面确实有很多共通点。
比如在 Open Mic 上试段子时，迭代速度非常快。你把段子讲出来，观众会立刻给你反应，就像是实时用户反馈。有时候反馈还挺残酷的。但对产品经理来说，这种快速试错、获取反馈的能力特别重要。
很多时候你推出的产品都有一个很好的愿景，但第一个版本往往体验很差。Reid Hoffman（风险投资家，LinkedIn 联合创始人） 就说过，如果你发布第一个版本时不觉得尴尬，那说明你发布得太慢了。所以，能不断应对从理想到现实的落差，并想办法把它逐步缩小，这会锻炼出一种 「韧性」。
主持人：我以前从没发现这两者之间有这么多相通之处。我也不知道你真有演出，还打磨段子。我本来没打算让你讲个段子，但既然你正在准备一个关于 AI 的内容，有没有小段子可以跟我们分享一下？
Aparna：可以分享一个笑话吧，人们总说这些 AI 聊天产品像 「女人」，因为你根本不知道它们在想什么，像个黑盒，看不透。但其实也可以说它们更像 「男人」，因为它们老是出现幻觉，而且还不太靠谱。
主持人：还特别自信。
Aparna：没错，它们就算不知道答案，也会胡诌一通，而且还说得特别笃定。
主持人：今天我们聊了很多话题，在结束前，我想问一个问题：你有没有什么想分享的观点，或者想留给听众的最后一句话？
Aparna：我现在最感兴趣的一个问题是，人和 Agent 之间到底该如何协作。我觉得我们可以重新想象一整套产品和使用体验。这是我最近脑海里的另一个 「罗马帝国」 式的执念，我们能不能有一个 「人和 Agent 的共创空间」？在这里，人类和 Agent 共同工作，创造出远超任何单一个体或小团队的成果。
主持人：我很好奇，你想象中的这个 「人和 Agent 共创空间」 到底是什么样？它是像 Microsoft Teams 这样的工具，还是一个有小机器人在跑来跑去的实体空间？
Aparna：我倒还没往实体空间那方面想（笑），但我最近确实在思考这个问题。
现在的产品体验大多是 「单人模式」 的，但我觉得我们可以设想 「未来一年」 的场景：我们不仅和人协作，也和 Agent 协作。我们可以把哪些任务委托出去？哪些需要人来检查？信息如何在个体之间流动，而这些过程又可以由 Agent 来协调？这背后还有很多值得探索的可能。
