先看见自己的念头，再看见用户的需求：AI 产品经理的觉察练习

一个产品最危险的时刻，可能是它还没有用户，团队却已经能把它的价值讲得无懈可击。

演示做出来了，功能清单列好了，商业故事也讲顺了。用户为什么需要、市场为什么足够大、未来为什么值得投入，每个问题都有答案。唯独那个最朴素的问题，被留到了最后：到底是谁，在什么情况下，非解决这个问题不可？

对 AI 产品经理来说，这种危险尤其值得警惕。模型可以参与整理材料、生成方案、制作原型，也可以帮我们把一个未经验证的想法，写成一份逻辑完整的需求文档。表达上的完整，很容易掩盖证据上的空白。一旦开始相信自己的故事，我们听用户说话的方式也会改变。对方说“挺有意思”，我们听成“有需求”；对方说“可以试试”，我们记成“使用意愿强”；对方提出顾虑，我们开始解释为什么这些顾虑不是问题。需求访谈还没结束，产品经理已经变成了销售。

这里想讨论的就是判断发生之前的那一刻：当一个念头出现时，我们能不能先看见它，再决定是否跟随它？

《当下的力量》提供了一个值得借用的视角——观察自己的思维，不急着把念头当成事实。把这个视角放进产品工作，并不需要我们停止分析。相反，它要求我们更仔细地分辨：哪些来自用户，哪些来自证据，哪些只是自己希望事情如此。

本文涉及的研究和作者观点均附有来源；“AI 周报工具”是贯穿全文的假设案例，用来展示判断过程，不对应某家公司的真实项目或经营数据。

一、AI 改变了产出速度，也让我们需要重新审视判断过程

1. 方案写得出来，不代表问题已经想清楚

先设想一场需求评审。

有人提出：“我们可以做一个 AI 周报助手，自动读取工作记录，生成周报。”

接下来，团队很容易进入熟悉的讨论：接哪些数据，怎么组织提示词，要不要支持多种语气，能否一键发送，付费功能如何划分。这些问题都值得讨论，但它们共同接受了一个尚未检验的前提：用户写周报的主要困难，是缺少一个生成文本的工具。也许是这样。也许用户真正费时间的地方，是从聊天记录、文档和任务列表里找回自己做过的事。也许材料都在，但他不知道哪些成果值得汇报。也许他并不讨厌写周报，只是不愿意把工作资料交给另一个系统。

如果前提不同，应该做的产品就不同。

从产品判断的角度看，AI 带来的一个变化是：我们可以更快地把想法变成像样的东西。但“像样”与“成立”之间，仍然隔着真实用户、实际任务和使用结果。这意味着，产品经理应该把更多精力放在检查前提上。否则，交付速度越快，只会越快地把未经检验的判断变成代码。

2. 技术能力不能直接折算成业务价值

哈佛商学院相关研究与波士顿咨询公司合作，对 758 名咨询顾问进行了实验。研究提出，AI 的能力边界并不整齐：它在某些任务上表现很好，在另一些任务上则未必可靠。这个研究支持的是按具体任务评估人机协作，而不是笼统地判断“用了 AI 就会更好”。研究采用当时的模型和特定任务，不能直接作为今天所有产品的效果预测。

对产品经理的启发很具体：会总结会议，不等于能准确判断谁应承担责任；会生成营销文案，不等于知道哪些承诺可以向客户做出；能写一份周报，不等于理解一个组织如何评价工作。技术展示回答的是“它可以做什么”。产品判断还要回答“这一步做对了，用户能得到什么；做错了，谁来承担后果”。这两个问题之间的距离，需要我们亲自走完。

二、从《当下的力量》借来的，是一个暂停判断的机会

1. 念头出现了，不必马上服从它

艾克哈特·托勒在其官方文章中谈到，可以观察自己的想法，在自己与念头之间留出空间，不必相信每一个出现的念头。这与《当下的力量》中关于观察思维的讨论相呼应。

这里需要划清边界：这是作者提供的觉察视角，不是已经证实能提高产品成功率的科学结论。接下来介绍的方法，是把这个视角用于产品工作的实践建议。它最直接的用法，是把一句肯定判断，改写成一句可以检查的陈述。

“用户一定需要这个功能”，可以改成：“我现在认为用户需要这个功能。”

只多了几个字，问题却显露出来了：为什么是这样认为？依据来自哪里？有没有其他解释？同样，“这个反馈说明方向对了”，可以改成：“我把这个反馈解释成了对方向的支持。”这时候，你就有机会重新看一眼原话。用户究竟是在评价演示效果，还是在描述自己的困难？他赞同的是解决问题的愿望，还是你提出的具体方案？

观察思考，就是给这种重新检查留出机会。

2. 专注当下，在访谈里意味着把注意力还给对方

想象用户正在描述一次工作经历，你听到“整理资料很麻烦”，脑中立刻出现了文档上传、自动摘要、智能归类的界面。

你还在点头，但注意力已经离开了对话。用户后面说的“其实最麻烦的是有些记录我没有权限看”，可能因此被轻轻带过。可这句话足以改变产品方案：真正的阻碍涉及资料获取和组织权限，文本处理能力只能解决其中一部分。

在这个场景里，专注当下是一件很朴素的事：察觉自己已经开始设计，然后把注意力带回用户尚未讲完的经历。你可以在纸上记下“自动归类”这个想法，暂时放在旁边。接着问：“你刚才说没有权限，最近一次是什么情况？”

想法不会因为晚几分钟处理就失去价值，用户提供的关键线索却可能在一次打断中消失。

三、需求被看错，常常始于几个没有被察觉的念头

1. “这个技术很强，总能找到用处”

技术兴奋本身没有问题。它让产品经理愿意学习、尝试和想象。

问题在于，我们可能顺着这种兴奋，把“能做”直接推成“值得做”。先决定要用某种能力，再去用户身上寻找证明，访谈就容易变成一场配对游戏：哪句话能放进我的方案里？一个简单的检查方法是：暂时不许自己提 AI，也不许提功能名称，只描述用户原本的困难。如果拿掉技术词汇后，只剩下“提高效率”“优化体验”，说明问题仍然太模糊。

你至少要能说清楚：哪类人，正在完成什么事，卡在哪一步，这一步带来了什么损失。

2. “竞品已经做了，我们不能没有”

竞品上线一个功能，是一条市场信息。它能提醒你去研究，却不能替你完成判断。

对方服务的用户、拥有的数据、原有的使用习惯，未必与你相同。一个功能也可能承担演示、获客、试验或客户承诺等不同任务。仅凭发布页面，你很难知道它实际解决了什么问题。这时值得观察的，是自己的紧迫感来自哪里。如果来自明确的客户流失，就去核实流失原因；如果来自销售连续收到的要求，就去区分客户类型和具体用途；如果只是看到别人发布后的不安，也应如实承认。

不同来源的紧迫感，需要不同动作。把它们统一写成“市场刚需”，只会让团队失去判断依据。

3. “我已经投入这么多，应该继续做”

当一个方案已经承载了自己的时间、声誉和公开承诺，否定它会变得困难。

用户说不好用，我们可能解释为不会用；没人回来，我们可能归因于引导不足；效果没有达到预期，我们可能继续增加功能。这些解释有时成立，但不能因为它们能保住方案，就优先相信它们。决策前可以问自己：假如今天第一次看到这个项目，没有历史投入，也不需要维护任何人的面子，我还会建议继续投入吗？

这个问题不会自动给出正确答案，但能把已经花掉的成本，与下一步是否值得做，暂时分开。

4. “AI 也这么说，我的判断应该没错”

当我们把自己的需求判断交给 AI，请它扩写、论证、补全商业逻辑，最后得到的材料可能比最初的想法更有说服力。但这仍然不等于增加了用户证据。

2025 年，来自微软研究院和卡内基梅隆大学等机构的研究者调查了 319 名知识工作者，收集了 936 个工作使用实例。研究发现，对生成式 AI 更有信心，与较少的批判性思考相关。需要注意，这主要是自我报告调查，不能据此断言 AI 导致人变笨，更不能直接推断中国产品经理群体的状况。我更愿意把它当成一个工作提醒：当一份分析读起来格外顺畅时，要检查它是否只是把自己的前提重复了一遍。

让 AI 写出十条支持理由，不如要求它指出：结论依赖哪些尚未证实的假设，哪些地方需要回到原始材料核对。

四、真实需求，要从一次具体经历里找

1. “我要一个 AI 周报工具”，只是调查的起点

回到我们的假设案例。

用户提出：“我希望有个工具，自动帮我写周报。”此时至少存在几种可能：他找资料很费时间；他不知道如何组织内容；他担心漏写成果；他写作困难；他需要满足统一格式。这些可能性可以同时存在，也可能一个都不是主要矛盾。产品经理不能挑出最适合 AI 的那个，就宣布找到了“深层需求”。所谓挖掘，并不是钻进用户心里，替他说出一个更高级的动机。它是逐步弄清事情如何发生，以及什么改变会对他有帮助。

用户研究机构 Nielsen Norman Group 区分了访谈与可用性测试：访谈主要收集受访者报告的经历、看法与感受，测试则观察用户如何操作设计。两者回答的问题不同，应根据研究目的选择或结合使用。

因此，既要听他说，也要尽可能看他做过的东西、如何完成任务。

2. 把“通常怎么样”换成“最近一次怎么样”

你可以请用户打开最近一次周报，以及当时使用的资料，按顺序还原过程：

“你从哪里开始？”

“这一段内容是怎么找出来的？”

“这里为什么改了几次？”

“交出去以后，有没有人让你补充？”

这些问题的价值，在于把讨论拉回可以描述、可以追问的行为。假如你发现，用户写正文很快，大部分时间都在翻找聊天记录，那么优先生成正文可能没有碰到主要困难。假如他资料齐全，却反复删改一段成果描述，就需要进一步了解他难以判断的究竟是什么。

不要看到停顿就立即解释成焦虑，也不要看到修改就立即判断为表达能力不足。先问发生了什么，再确认自己的理解。

3. 对情绪保持敏感，也对自己的解释保持克制

心理学视角能提醒产品经理关注任务之外的感受，但也容易被用过头。

比如，用户反复修改周报，你便认定他“渴望认可”；用户拒绝自动发送，你便认为他“缺乏安全感”。这些解释听起来深刻，却可能离事实很远。他可能只是需要核对一个数字，或者公司规定所有汇报必须本人确认。可以问：“这部分如果不改，会有什么影响？”也可以问：“你最想确认的是什么？”

用户愿意谈到感受时，认真听；他描述的是流程限制时，也尊重这个答案。没有必要把每个功能诉求都解释成人格或心理问题。

真实需求不一定藏得很深。有时候，它就是把三份材料准确地合在一起。

4. 找到问题之后，还要判断值不值得解决

一个问题存在，不代表值得单独开发产品。

还要看发生频率、后果、现有办法和改变成本。用户每月才遇到一次的小麻烦，与每天都会耽误交付的问题，优先级可能完全不同。一个看似耗时的步骤，也可能承担了用户不愿丢掉的检查作用。仍以周报为例，整理工作记录可能顺便帮助用户回顾项目。如果全部自动完成，他是否需要另一种方式确认遗漏？如果工具要求先把资料整理成规定格式，是否只是把原有工作搬到了生成之前？

这些问题必须放进完整过程里看。需求的重要性，不能只按用户说“麻烦”时的语气来判断。

五、做好 AI 产品，必须把核对、修改和失败算进去

1. 先测完整任务，再谈节省时间

一个周报工具几秒钟生成文本，这几秒钟很容易被拿来展示。

但用户真正付出的时间，还包括找资料、上传、解释要求、等待、核对、修改、复制到工作系统。出错时，还要回头找原因，甚至重新做一遍。因此，我建议把效率评估的起点设在用户开始准备任务时，终点设在结果达到可交付标准时。假设生成本身很快，但检查和修改比原来写作还费力，产品就没有实现承诺的节省。这里不需要争论模型究竟够不够聪明，先把完整时间记下来就能开始判断。

质量也必须一起看。更快地交出一份遗漏关键项目的周报，未必是用户愿意接受的改进。

2. 不同错误，要对应不同的产品动作

语气不合适，可以改写；遗漏一个项目，需要补充；捏造一个成果，可能影响工作评价；把不该共享的信息写进报告，则需要在使用流程中提前处理。

如果所有错误都交给一句“请自行核对”，产品经理实际上没有完成任务分配。要继续问：用户是否知道该检查哪里？能否方便地看到原始记录？发现错误后能不能局部修改？没有足够资料时，系统是否应该明确留下空缺？对周报工具来说，与其把段落写得更漂亮，不如优先验证这些设计是否有用：每项成果附上对应资料入口；无法确认的内容单独列出；发送前保留清楚的检查步骤。

这些并非所有 AI 产品都必须采用的标准配置，而是根据具体错误代价提出的候选方案，仍需测试。

3. 使用者觉得好，不等于产品就能进入组织

面向企业工作场景时，还需要分开识别使用者、采购者、管理者，以及负责资料权限的人。

员工希望少花时间，负责人可能关心信息能否比较，采购者会评估价格和现有工具是否重复，资料管理者需要确认内容如何访问。几方要求可能一致，也可能冲突。如果访谈只找愿意试新工具的员工，就容易漏掉实际采用时的阻碍。这不意味着产品经理要一次解决所有人的问题，而是要把采用条件写清楚：谁同意才能开始，接入要做哪些准备，用户个人愿意用之后还差什么。

有需求、有使用价值、能够被采用、能够形成业务，是几个相互关联但需要分别验证的问题。

六、觉察不能只靠个人自律，还要写进团队的工作方式

1. 让证据和解释在文档里分开出现

如果需求文档只保留最终结论，团队很难看见结论是怎么来的。

“用户需要更强的智能总结能力”究竟来自多少次访谈，原话是什么，观察到了什么行为，是否有人给出相反反馈？这些内容不该被压缩成一句“调研发现”。可以采用一种简单写法：先列事实，再列解释，最后列行动。

事实是：“这位受访者在演示过程中，多次返回聊天记录查找项目进展。”

解释是：“资料分散可能是他的主要耗时来源。”

行动是：“继续观察其他同类用户，并比较资料整理与正文撰写各自的负担。”

解释可以大胆，证据必须诚实。两者分开，别人才能挑战你的推理，而不必先怀疑你有没有认真做调研。

2. 允许“改变判断”成为有价值的工作

如果团队只认可功能上线，却把停止一个方向视为失败，成员就有理由不断为原方案寻找解释。

负责人可以在评审中多问一个问题：“这次调查，让我们放弃了哪个原来的想法？”这能让需求工作的产出更完整。发现某类用户并不需要，发现现有功能已经足够，发现问题主要来自内部流程，这些都能减少后续浪费。当然，“我们学到了很多”也不能成为没有结果的借口。每次改变判断，应对应具体材料，以及资源安排上的变化。

要能说清楚：哪条证据使我们决定先不开发自动发送，把时间用在资料整理上。这样的学习才影响了产品。

3. 别让“活在当下”变成拒绝规划的理由

产品经理需要考虑未来，需要比较方案，也需要在信息不完整时作决定。

觉察不要求永远等待确定性。它要求你知道自己在哪里做了推测，并为推测安排验证。一个诚实的决定可以是：“目前证据还不够，但这个问题值得用一周做小范围试验。”它也可以是：“有几位用户愿意尝试，但接入成本超过了当前可投入资源，暂时不做。”清楚承认不确定，反而更容易行动。因为你知道下一步是在验证什么，也知道什么情况出现时应该调整。

七、让 AI 参与研究，同时保留证据的来路

AI 可以帮助整理访谈记录、比较不同说法、提示遗漏的问题。关键在于，不要让整理过程抹平原始材料的差异。

例如，一位用户说“我不太愿意上传资料”，另一位说“我们公司不能上传资料”，看起来都属于接入障碍，但前者可能涉及个人选择，后者涉及组织限制。把两句话统一概括成“用户缺乏信任”，就损失了对方案有用的区别。使用 AI 整理时，可以给出明确要求：“逐条保留原话及对应位置。把直接陈述、观察记录和推测分开。对同一解释列出支持与相反材料；没有证据的地方写‘尚不清楚’，不要补写用户动机。”

生成之后，产品经理还要回看原文。尤其是那些改变需求方向、影响优先级的结论，不能只读摘要。同样，模拟用户可以用来练习提问、寻找假设，但模拟回答不能计入真实访谈结果。它没有经历过你的客户流程，也没有为选择付过成本。对 AI 最有价值的用法之一，是请它帮助暴露推理漏洞：“除了资料分散，还有哪些解释能说明这个行为？分别需要什么证据才能区分？”

这些解释仍然是候选答案。下一步，是带着更好的问题回到用户那里。

八、把方法带回工作：一张记录表、一次访谈、一轮试验

下面这套方法是本文提出的工作建议，目的是把觉察变成可以执行和检查的动作。它不保证项目成功，但能让判断过程更清楚。

第一步：访谈前，写下自己最想证明的三件事

用五分钟，写出当前最强的三个判断。例如：

“用户写周报主要耗时在组织语言。”

“自动生成后，用户愿意每周使用。”

“用户愿意提供足够的工作记录。”

每条后面补两句：我为什么这样认为？看到什么事实时，我会承认这条不成立？

不要写“用户不喜欢就说明不成立”这种空话。尽量具体：如果观察发现，大部分准备工作发生在资料收集阶段，就需要重新检查以写作为中心的方案。

写下来不是为了约束用户回答，而是让自己知道哪些地方最容易听偏。

第二步：访谈中，用三栏记录，避免把推测写成事实

这张表最重要的地方，是中间那栏明确写着“我的解释”。

它提醒你：你可以推断，但需要继续验证。也允许团队成员提出其他解释，而不必先争论谁更懂用户。

访谈时不必忙着填满所有格子。先让对方讲完，缺少的内容可以在结束后整理。

第三步：把需求写成一句没有技术词汇的话

可以使用这个句式：

“对于____，当____发生时，他们需要____，以便____；目前主要受阻于____。”

在周报案例里，一个待验证的版本可以是：

“对于同时参与多个项目的运营人员，当周五准备汇报时，他们需要快速找回本周完成事项及依据，以便准确说明进展；目前主要受阻于记录分散。”

这句话没有预先要求聊天窗口、自动写作或智能助手。它给方案留下空间。随后要写出依据与空白：哪些部分已经在材料中出现，哪些仍是推测。只写一句漂亮的需求描述，不会自动让需求成立。

第四步：先验证最可能推翻方案的那个假设

不要平均验证所有问题。

如果连工作资料都无法获取，先验证接入条件；如果资料完整但输出很难检查，先验证核对成本；如果用户现有办法已经足够好，先验证改变工具是否值得。试验可以很小。用简单原型完成一次真实任务，观察从准备到交付的全过程。必要时先由人工补足尚未开发的部分，但要说明人工参与，并记录这部分成本，避免把人工完成的效果算成系统能力。

先解决最可能让方案不成立的问题，才能知道后续开发是否值得继续。

第五步：试验前写好评价标准和停止条件

评价标准至少覆盖三件事：任务完成得怎样，用户付出了多少额外工作，失败后是否容易恢复。

对应周报工具，可以记录完整耗时、关键事项遗漏、需要修改的内容，以及到下一次真实写周报时是否继续使用。不要只问满意不满意，也不要把首次试用当成持续需要。观察周期应与任务发生频率匹配，每周发生的任务就需要等到后续周次再看。停止条件也应提前写。例如：接入准备长期超过目标用户可以承担的时间；关键内容无法方便核实；效果提升主要依赖大量人工协助，而成本无法接受。

具体阈值由业务条件决定，没有一组适合所有产品的数字。

第六步：复盘判断变化，明确下一步

复盘不只记录“功能完成了什么”，还要回答：

最初认为用户需要什么？后来看到什么？哪条判断被推翻了？方案因此发生了什么变化？仍然不知道什么？最后给出一个明确动作：继续验证、缩小用户范围、修改方案，或停止投入。

如果复盘结束后，所有原有判断都得到了支持，可以再检查一次：试验是否有机会让我们发现自己错了？

AI 产品经理当然需要理解模型能力、设计使用流程、安排评估，也需要承担进度和业务责任。但这些工作最终都会回到同一个地方：你如何判断眼前的问题，如何知道自己的判断值得相信。一个念头可以成为好产品的起点，也可以成为漫长返工的起点。区别要靠之后的工作建立。

下次用户说“我想要一个 AI 工具”，先别急着打开原型。

请他讲讲，上一次遇到这个问题时，到底发生了什么。然后听完。