设计这个产品的产品经理，真的会用这个产品吗？

前段时间，有个同事跟我聊起他用纯 AI 工作一个月以后的感受。他说自己现在已经有点不知道该怎么评价这件事了。

按理说，效率应该是提高了。以前要花半天整理的资料，现在几分钟就有初稿。一个想法刚冒出来，页面、文案、流程，甚至一些能跑的实现，都可以很快摆在面前。可他越用越觉得不对。答案来得太容易，人反而不太会继续往下想。遇到问题的惯性也变成了先让 AI 跑一版，跑出来以后再改。

但麻烦也在这里。

如果 AI 一开始理解错了，它会沿着那个错误的前提继续往下做，把一个不完整的想法补成一份看起来很完整的方案。它当然也可以被要求反问、找漏洞、扮演反方。但这件事不会像原来的人际协作那样自然发生，既然反问这个环节没有被设计进流程里，输出就仍然会围绕眼前交给它的任务展开。

最后同事说，“仿佛又回到了 Showcase 做完以后不上线，直接开始重构的日子”。

我一开始还挺认同这个感受。AI 给答案太快，人就容易少想一点。它会顺着不完整的前提往下写，把错误路线推进得更远。等模型更强一点，记忆更长一点，上下文理解更准确一点，这类问题大概就会慢慢减少。但后来仔细想想，这个解释反而有点太轻松了，就像是武断的下一个结论，AI 就是没有办法代替人类，就是会存在它的缺陷与短板。

如果问题只是 AI 还不够聪明，那我们换一个更聪明的模型就够了。可我看到的不是这样。很多返工其实不是 AI 把东西做错了，而是我们太快把最早出现的答案，当成了问题本身。

假如 AI 没有出现，那需求从产品经理手里交给开发，再到最终变成结果的过程是相当漫长的。

开发会问状态怎么流转，权限怎么区分，异常情况谁来处理，要让产品输出一些 ER 图或时序图。设计会问用户在这里到底想完成什么，哪里是重要的哪里是不重要的。测试会问边界条件在哪里。在以往工作里这些问题有时候确实让人觉得烦，明明需求已经写完了，怎么还要被拉回去补背景，为什么团队里建立一些已知的工时就这么难，就需要产品不断去花时间解释那些“自以为”已经定下来的细节。

但现在回头看，那些反问并不只是协作里的摩擦，它其实是一个团队或者组织缓慢建立共识的过程。产品、设计、开发和测试看到的是同一个系统的不同侧面，一个方案如果没有想完整，很难毫无阻力地一路往下走。以前很多讨论之所以显得慢，其实并非因为“慢”本身有什么价值，而是因为里面藏着不断的追问，重复验证和确认。

当然，那些等待、重复传递和职责不清，也没有什么好怀念的（这些东西本来就应该被尽早丢弃）。AI 能把这些东西一起省掉。真正不能被一起省掉的，是有人愿意在方案看起来已经足够完整的时候，再问一句，这个问题到底是不是这样。

AI 进入流程以后，产物生成变快了，就像是你刚点了部署立马就看到链接的感觉一样。一个问题刚刚被描述出来，AI 就能给出一份足够完整的方案，它可以把流程写得很顺，把文案补得很全，把页面和原型很快摆到你面前。在这个鬼哦成之下，人就很容易产生一种感觉，事情已经被理解了，下一步只是继续把它做出来。但实际上产品工作里最难的部分，往往发生在答案出现之前。

用户说一个页面不好用，可能是交互不清楚，可能是功能没有抽象做减法，也可能是用户压根就不该走到这里。一个投诉看起来像缺少某个其他 App 里面都设计了的功能，但背后可能是流程设计、业务规则，甚至角色分工出了问题。答案出现得太早，会让人误以为问题已经被找到了。

说到这里，好像很容易把这篇文章写成是一篇“AI 还是谨慎一点用”的流水文，但回到原点，我们还是可以对比一下到底 AI 带来了什么变化？AI 让我兴奋的地方，恰恰是它把很多原本被岗位、工具和协作成本切碎的动作重新接了起来。以前产品经理有一个想法，很多时候只能先把它写成需求，再等设计、开发、测试，一层层往下走。这个过程里，判断很容易停在文档里，也很容易被资源、排期和协作成本切开。

而现在，很多东西都不一样了。

产品经理可以自己查资料，自己做原型，自己跑一段流程，甚至很快把一个还不成熟的想法交给用户看，再根据反馈继续改。以前你可能只能写一份需求，等几周以后再看到它到底长什么样，现在你可以在一个下午里，先做出一个能拿给人讨论的东西，它可能被用户真正使用，也可能很快被推翻，过去被不同岗位切碎的那些能力，好像终于有机会重新连起来了。

以前分散在不同岗位里的动作，终于有机会变成一个真的可以循环往复的过程。从现场看见问题，形成判断，做出一个可以验证的东西，再把它带回真实用户那里。这才是我觉得 AI 真正改变产品工作的地方。它让产品经理有机会更快把一个问题带到真实反馈面前，而不只是把它翻译成一份文档，一个需求，一个 Jira 或者 Tapd 的链接。

而且这个反馈还集合了来自设计、研发和测试等不同角色的各自不可替代的判断，产品经理能更早把一个还不成熟的想法做成真正能讨论的东西，这些判断也能更早进入讨论。团队再从真实反馈里决定，它到底值不值得继续做下去。

再来说说验证和确认的部分。有些工作规则稳定，输入完整，结果又容易检查。AI 确实能把生成和验证的成本一起省掉。它擅长把一段已经说清楚的工作跑得更快。但产品里的很多问题其实并非如此。它们表面上看很小，一个按钮的位置，一段看不懂的文案，一次多出来的操作。可真正往下看，它们常常连着状态模型、权限规则、数据归属和不同角色之间早就形成的工作习惯，甚至是历史的一些选择习惯，品味共性，或者是一些其实不正确但依然可以持续坚持的选择。

这些复杂性原本就在那里。局部修改的成本降下来以后，团队更容易跳过诊断，直接进入解决。有时候最危险的不是一个方案做不出来，而是它太容易做出来了。如果团队只看产物出现得有多快，就容易把局部答案当成全局改善，然后在后面不断循环补背景、补边界、补测试、补例外情况，然后再吐槽原本省下来的时间又花在了返工和重构里。

而且说句实在的，很多时候我们一开始理解的问题，本来就不完整。很多人总觉得刷短视频会进入信息茧房，但在日常工作里也会有无数的茧房。我们每天看到的需求、数据、客服反馈、会议结论和管理目标，大多都是真的。但这些信息加在一起，依然未必等于完整的现实。人会自然关注自己负责的指标，重视熟悉的用户，记住支持既有判断的信息。但随着时间越来越久，我们可能越来越熟悉文档和报表，却越来越不熟悉真正使用产品的人。

所以才会有那句很刺耳的吐槽，“设计这个产品的产品经理，真的会用这个产品吗？”

它问的肯定不只是产品经理有没有点开过页面，或者有没有花时间去体验这里的实际流程。它真正想问的是，做决定的人有没有持续接触真实用户的摩擦，有没有理解真实业务里的限制，也有没有看见自己的方案落地以后，到底给谁增加了麻烦。当缺少了这些真实的摩擦之后，AI 就会让这个问题变得更加明显。

如果我们只把已有的资料交给 AI，让它总结、润色、补全和论证，它会把原本不完整的信息整理得更完整，也会把原本未经验证的判断写得更像结论。它一面放大效率，一面放大我们已经选择看到的那部分信息。

所以我现在反而去刻意让 AI 做一些不那么顺手的事情。除了让它帮我写方案，我也会让它找一找这个方案依赖了哪些假设，列一列可能反对它的用户，提醒我哪些人还没有被放进讨论，或者把历史决策和新证据放在一起看看有没有冲突。它不见得每次都说得对，甚至有时候会出现一些在起初就应该被忽略的问题，但至少这个过程（有一点像 grill me 的那个 skill）能让我发现，原来有些问题一开始就被我选择性忽略了，在这一类工作里，AI 其实是会更像一面镜子。

它能映出我带进来的假设，至于从来没有接触过的用户、场景和证据，还是要由我自己带回来。

有一段时间我常常在想，使用 AI 和使用车辆的辅助驾驶其实像是一个意思。这里不是要硬把产品工作套进 L１ 到 L５ 的定义里，我是觉得它提供了一个挺合适的思路：驾驶不只有全程自己开和完全交出去两种状态，人可以逐步把一部分动作交给系统，但交出去多少，取决于眼前的路况，也取决于自己是否知道什么时候该接管。

人和 AI 的协作也一样，现在很多团队都说自己已经是“全栈 AI，全角色 AI，全流水线 AI，全岗位 AI 等等”，但我其实不太关心一个团队到底怎么做才算是会用 AI。这个问题太大了，也太容易变成一种姿态。我会觉得可以通过查看不同团队和 AI 合作的流程，来梳理一份“AI 协作授权层级”：一项具体工作里，AI 能够自主推进到哪里，人又应该在哪个节点重新介入。

在 L１ 和 L２，AI 更像一个能力更强的助手。它帮忙检索、整理、生成初稿，或者完成一段边界清楚的产出，但人还会逐项确认关键结果。到了 L３，团队才可以尝试把一段限定流程交给 AI 去跑，前提是目标、上下文、边界和验收方式都已经说清楚，人不再盯住每一步，但会在关键节点检查它有没有跑偏。L４ 再往前一点，AI 可以跨过几个步骤推进一段稳定工作流，处理已知情况。人只在例外发生时接管，也会定期回头看这条链路有没有积累新的问题。

至于 L５，我更愿意把它看成一条提醒边界的虚线。执行可以越来越自动，但方向怎么定，什么结果算好，哪些后果不能接受，始终还是需要人来回答。但这个流程里的授权层级最多只能衡量人机协作的边界与范围，判断好不好还要看任务本身。

同一个团队，完全可以让会议纪要整理进入很高的自动化层级，却让一次产品方向判断长期停在较低层级。规则稳定、结果容易验证、错误能够撤回、影响范围有限的事情，本来就适合交出去更多。问题还没有定义清楚、真实信息不足、一个局部改动就可能影响整个系统的事情，则需要保留更多人的判断。

我现在自己在把任务交给 AI 之前，会尽量先想清楚几件事。它应该依据哪些真实信息工作，它不能越过哪些边界，我靠什么判断它做对了，它遇到不确定情况时又应该把问题交还给谁。这些东西不一定要专门做成一张表，很多时候就是写在一段提示词里，或者在项目讨论的时候多说几句。

这几件事越早说清，AI 推进得越快，团队越不容易把不确定性一起带进后面的工作。

说到这里，其实我想我们都应该能理解那种和 AI 协作过程中的“累”了。那种累，很多时候来自以前藏在追问、交叉验证和反复确认里的工作，变成了需要我们主动补回来的事情。AI 把产物生成得更快以后，这些事情不再会自然发生了。所以以后再遇到一个看起来很简单的问题，我们其实可以先用几分钟确认问题来自哪里，谁会承担改动带来的影响，什么证据能证明方案有效，再让 AI 参与生成。

这几分钟未必能省掉后面的所有返工，但能提醒我们自己再想一下，自己要解决的还是不是那个问题。