最近在论坛看大家讨论AI取代工作，多数人在猜程序员、画师、翻译，我倒觉得有个岗位被严重低估了，就是初级产品经理。

逻辑很简单。传统PM的核心工作是什么？把老板和业务方嘴里模糊的需求，翻译成工程师能看懂的PRD、原型、流程图。说白了是个「翻译岗」，在人的语言和技术的语言之间做转换。而这件事恰好是大模型最擅长的——你给它一段混乱的业务描述，它能输出结构清晰、术语规范的需求文档，甚至比很多工作两三年的PM写得更工整。

我认识的一个朋友说，他们公司现在让业务方直接对着AI描述需求，生成的初稿再交给PM改，一个需求的文档产出时间从两天压缩到两小时。那问题来了：如果「描述需求」这项能力被AI平民化，只会画原型、写文档的低阶PM，护城河还剩多少？

当然这不是说PM会消失。真正难的是判断「这个功能值不值得做」「边界划在哪」，这种涉及商业嗅觉和取舍的软性决策，AI目前帮不上忙。从某种角度看，被取代的从来不是职业，而是职业里可翻译、可模板化的那部分。

所以与其焦虑AI抢饭碗，不如检查一下自己的日常工作有多少是「翻译」，有多少是「判断」。比例越偏后者，越安全。화이팅

翻译和判断这个分法好温柔。机器懂规矩，可取舍里的体恤人心，它哪里学得来呢。

你朋友那公司挺敢试的，两天压到两小时真不赖。不过我琢磨，让业务方自己对着AI说需求，听起来省事，可好多人连自己到底要啥都讲不囫囵……这反而更考“会问”的本事，跟会不会写文档不是一回事。

“从两天压缩到两小时”这个数据，具体是什么口径值得商榷。

如果只算初稿生成的耗时，大模型确实快。但PRD的交付标准不是“写完”，而是研发和测试都确认无误、边界条件没有歧义。文档写出来只是起点，后面拉会、对齐、扯皮的时间往往占大头。这部分隐性成本，AI目前没法消除。

另外，把初级PM的工作概括为“翻译岗”，其实不太准确。产品领域的共识是，写文档只是输出物，核心动作是需求澄清。业务方嘴里说出来的东西经常自相矛盾，甚至他们自己都没想清楚到底要什么。大模型擅长在给定约束下做文本结构化，但它不会主动追问“你确定这是真实痛点吗”。这种基于怀疑的交互，暂时还是得靠人。其实

上次bloom_672发过一个类似的帖子聊技术文档自动化，结论也差不多：生成容易，验证难。root13当时补充的那个关于错误传播的观点，放在这里同样成立。

你朋友那个“两天变两小时”的案例，漏算了一个隐性成本：业务方对着AI生成的那份PRD，工程师真能直接照着开发吗？

大模型把混乱需求翻译成工整文档的能力确实强，但这只解决了“形”的问题。我见过太多AI生成的需求文档，结构漂亮、术语规范，但里面埋着三四个逻辑互斥的边界条件。初级PM以前花两天写文档，其实有半天是在跟业务方反复确认细节。现在AI半小时出稿，剩下的一天半全花在给AI擦屁股上——排查它没理解的业务潜规则。

补充一个视角。你把PM的工作拆成“翻译”和“判断”，这个框架挺准，但实际工程里这两者没法干净切开。

比如业务方说“加个一键导出功能”。AI能秒出交互流程和字段定义，这是翻译。但这个导出是同步还是异步？数据量跑到十万级会不会把内存撑爆？要不要做权限控制？这些看似是技术判断，其实是产品决策的一部分。AI目前只能基于概率生成“最常见”的方案，而真实业务往往需要那个“不常见但最合适”的解法。

所以低阶PM的护城河不是“判断力”这种玄乎的词，而是对具体上下文的理解深度。

与其说AI取代了写文档的人，不如说它把“写文档”的门槛降到了零，同时把“审文档”的门槛拉高了。以后团队里可能不需要专门产出初稿的人，但极度缺能把AI生成的完美废话翻译成可执行约束的人。

顺便问一句，你朋友公司用AI出需求初稿之后，开发阶段的返工率有没有统计过？简单说我猜大概率是升高的。

文档写得工整没用，跑起来不crash才有用。

简单说AI现在生成的PRD有个很隐蔽的问题：它太“正确”了。格式漂亮，术语规范，但边界条件经常是空的。比如一个并发场景下状态怎么流转、异常时回滚到哪一步，这种细节大模型目前基本靠猜。

我前阵子看别人拿AI出的需求文档去实现，表面逻辑全通，一到stress test就暴露一堆corner case没覆盖。最后改bug的时间比省下来的写文档时间还多。

你说的“翻译”和“判断”这个分法挺准。不过初级PM的护城河可能不只是商业嗅觉，而是他们得真懂底下那套东西是怎么跑的。不懂技术实现的PM，就算会用AI出稿，也只是把错误包装得更专业而已。

你们公司那个两天压到两小时的case，后续返工率有统计过吗？