作者：吴知
我们花了两周写的PRD，AI两小时就能跑出一个能点击的原型——这不是效率问题，是整个产品工作方式的结构性崩塌
先说一件我们团队真实发生的事
三个月前，我们在做一个用户反馈聚合功能。
按照正常流程走：需求调研、竞品分析、写PRD、评审、排期、开发、测试、上线。整个周期预估六周。
PRD写了将近二十页。需求评审开了两轮，第二轮因为某个交互逻辑的分歧又推了一周。
就在我们争论”反馈标签应该由用户自定义还是系统预设”的那个下午，我们团队里一个做过一点点开发的运营同事，用Claude Code鼓捣了两个多小时，跑出来一个能点击的原型。
功能不完整，UI很粗糙，但核心流程是通的。
他拿着这个原型去问了五个目标用户。两小时后，他拿回来一个结论：用户根本不在乎标签是谁定的，他们最想要的是”反馈提交之后能看到处理进度”。
这个需求，在我们二十页的PRD里，只有半句话。
那一刻我有点沉默。
不是因为”AI要抢走PM的工作”——这个话题我已经听了两年，早就免疫了。
我沉默是因为我意识到：我们花了三周时间在争论一个用户根本不在乎的问题。而找到用户真正在乎的东西，只需要一个粗糙原型加两小时用户访谈。
PRD没有错。排期没有错。评审也没有错。
错的是：我们用一套为”执行速度是瓶颈”而设计的工作方式，去应对一个”执行速度已经不再是瓶颈”的新世界。
这不是个案，是整个行业正在发生的事
就在上周，Anthropic发了一篇文章，作者是他们Claude Code的产品主管Cat Wu。
她在文章里说，Anthropic的产品团队已经改变了工作方式。具体怎么改的？四句话：
用短期冲刺替代长期路线图。
用演示替代文档。
随每次模型更新去精简旧功能。
只做简单有效的事，不为AI的局限打补丁。
注意，这不是一家初创公司在分享”敏捷开发的最佳实践”。
这是目前全球增速最快的AI公司之一，在用自己做产品的真实经验，告诉你他们的PM是怎么工作的。Claude Code的年化收入已经超过25亿美元，他们不是在纸上谈兵。
不止Anthropic。
Zapier全公司89%的员工都在用AI，内部部署了超过800个AI Agent。他们的设计团队现在怎么做用研？在客户访谈进行的同时，用Claude实时生成交互原型，让用户当场体验，当场反馈，当场迭代。
以前这个流程是：访谈→整理洞察→出设计稿→评审→开发原型→再次用研，最短两到三周。
现在是：访谈和验证同时发生。
这背后有一个关键的结构性变化，我觉得大部分人还没有真正想清楚：
当”想法到原型”的周期从三周压缩到三小时，产品经理的核心工作对象就变了。
传统PM的核心交付物是：需求文档——开发可以照着做的那种。
这个交付物存在的前提是：开发是瓶颈，所以要把需求想清楚写完整，让开发能高效执行，减少返工。
但现在，AI已经可以帮你在几小时内跑出一个可以被用户点击的版本。执行不再是瓶颈了。
那瓶颈在哪里？
瓶颈在于：你有没有在正确的时间，问了正确的用户，验证了正确的假设。
这个事情，二十页的PRD帮不了你。
需求文档不是在变轻，而是在变成错误的投资
我想说一个可能会让人不舒服的判断：
很多团队的PRD，本质上是一份给”执行团队”看的文件。它的主要价值，是减少沟通成本、对齐理解、明确边界。
这些价值是真实的。但这份文件有一个隐含的前提：你在写它的时候，你认为自己已经知道用户想要什么了。
问题是，你真的知道吗？
在没有快速验证工具的时代，这个问题很难回答，所以只能靠经验、靠调研、靠数据，然后尽量想清楚。PRD的厚度，某种程度上是对”我认为我想清楚了”的信心背书。
但当你可以在两小时内跑出一个原型、然后拿给五个真实用户点击的时候——你还需要先写二十页来证明你”想清楚了”吗？
还是说，那二十页，其实是一种让自己安心的仪式，而不是真正的验证？
我说这个不是要否定文档的价值。
我在团队里还是会写文档，尤其是涉及复杂系统逻辑、跨部门协作、合规要求的时候，文档不可替代。
我想说的是：文档的位置变了。它不应该出现在”验证之前”，而应该出现在”验证之后”。
先跑一个原型，拿到真实用户的反馈，确认方向是对的——然后再写文档，把这个已经被验证过的方向说清楚。
这时候的文档，写起来其实更快，因为你不需要猜了。
这时候的文档，也更有价值，因为它记录的不是”我们的假设”，而是”被验证过的事实”。
那什么能力变得更重要了？
说清楚了什么在变轻，要说什么在变重。
第一个：构建可验证假设的能力，而不是写完整需求的能力。
可验证假设是什么？是一句可以被真实数据证伪的话。
比如：
“用户在反馈提交后会主动返回查看处理进度，且查看频率超过每两天一次”
“如果标签由用户自定义，标签使用率会比系统预设高30%以上”
这两句话，都可以在原型验证阶段被检验。
而不是：”用户希望有灵活的标签管理系统，支持自定义分类和批量操作，同时提供系统推荐标签供快速选择……”
后者是需求描述，不是假设。你无法从它里面提炼出一个可以被验证的真伪判断。
构建假设的密度，决定了你能以多快的速度逼近真相。
第二个：知道什么时候停止迭代的判断力。
AI让原型变得极其便宜。便宜到什么程度？Rakuten的工程师让Claude Code在一个有1250万行代码的巨型仓库里自主工作了7个小时，一次性完成了一项复杂任务，数值精度与参考方法匹配99.9%。
这意味着”再改一版看看”的成本极低。
但低成本迭代会带来一个新问题：你可能永远在改，永远在优化，但永远没有到达”足够好了，可以上线”的那个判断。
这个判断，AI给不了你。
什么时候停，为什么停，停在哪里，这是只有人能做的决策。
它需要你对用户、对业务、对资源约束有综合理解——不是数据分析，是判断。这是PM在AI时代最不可替代的事情之一。
第三个：能直接跑起来一个最小可验证版本。
这个能力以前不是PM的标配，但我认为接下来会变成。
不是说PM要学会写代码。而是说PM要能用Claude Code、Cursor这类工具，在不需要排开发人员的情况下，把一个核心流程跑起来，让真实用户能点击。
Anthropic自己法务团队的一个没有编程经验的律师，用Claude构建了一套合同分流工具，把原来2到3天的营销内容审查周期缩短到24小时。她没有写一行代码，但她解决了一个真实的业务问题，而且不需要排工程师的开发队列。
这件事之所以值得被一个产品经理认真对待，不是因为”PM也能写代码了”，而是因为：
当你可以自己把想法跑起来，你和用户之间的反馈循环，就不再需要经过开发这个中间层了。
这改变的不是工作量，是你获取真实信息的速度。
但有一件事，我需要说清楚
Anthropic工程师说过一句话，我觉得是这个时代关于AI能力判断最诚实的一句话：
“我主要在我知道答案应该是什么样子的时候才使用AI。这种判断力是我通过’笨办法’积累出来的。”
这句话翻译成产品语言是：AI放大的是你已有的判断力，不是凭空创造判断力。
你越清楚一个好产品应该是什么样，你就越能用好AI。
反过来，如果你对用户没有真实的理解，对业务逻辑没有清晰的认知，对什么是”好”没有标准——AI给你一个粗糙的原型，你也看不出问题在哪里，更不知道下一步该往哪里改。
所以这不是一篇”AI让PM更轻松”的文章。
AI让行动变得更便宜了，但判断变得更贵了。
以前你写完PRD，还有两周的开发周期来做缓冲，有时间发现错误、纠正方向。
现在原型两小时就能跑起来，你有没有判断力，立刻就会被放大——如果判断力强，验证速度惊人；如果判断力弱，你会以惊人的速度验证错误的东西。
回到那个下午
我们的运营同事拿着那个粗糙原型回来的时候，有个开发问他：这东西你花了多长时间？
他说：两小时多一点。
然后开发沉默了一下，说：那咱们是不是可以先把这个给用户用着？
这句话很重要。不是因为它说明了AI多厉害，而是因为它说明了一件事：
这个团队里，第一次有人在开发介入之前就获得了真实用户的验证。
这在以前是不可能发生的。因为在以前，”能让用户点击的东西”需要工程师来做，而工程师的时间从来都是稀缺资源。
现在不是了。
这个变化如果只停留在”工作效率提升”的层面，它是一个工具层面的改变。
但如果你认真思考它的含义——谁能在最快的时间内，用最真实的方式，获得用户的真实反馈——它是一个关于整个产品工作方式的结构性重塑。
你，一个产品经理，站在这个变化里，会怎么选？
一个可能让你不舒服的结尾
我不会说”赶快学Claude Code，不然就被淘汰”。这种话说起来容易，但它没有告诉你真正值得思考的问题。
真正值得思考的问题是：
你上次在没有写任何文档的情况下，直接把一个想法给到真实用户验证，是什么时候？
如果你的答案是”很久了”，或者”好像没有”——不是因为你不想，是因为以前的工具成本不允许你这么做。
现在允许了。
你的工作方式，准备好跟上了吗？
网配查提示：文章来自网络，不代表本站观点。
