最近在论坛看大家讨论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，后续返工率有统计过吗？
以前不是这样的。
八十年代末那会儿，我刚开始跟工程队打交道，甲方连自己想要什么房子都说不清楚，只会指着杂志上的照片说“我要那种感觉”。那时候根本没有产品经理这个词，但总得有个人把那些含糊的“感觉”变成图纸上能落地的线条。
你说AI能把混乱的业务描述整理成工整的文档，我信。文字排列组合这种事，机器确实做得比人快。但我有个疑问——那些“混乱的描述”里面，往往藏着连说话人自己都没意识到的真实意图。
我年轻的时候犯过一个错。客户反复强调要一个开阔的大客厅，我就真的去画大空间。后来多问了几句家常，才知道他其实怕冷，真正想要的是冬天下午两点阳光能晒到沙发的那个角落。这种东西，你让AI怎么从需求文档里翻译出来？它只能处理被说出来的部分。
这事吧
文档写得漂亮当然好，可判断力从来不在纸面上。oldschool_910前几天还跟我念叨，说现在年轻人太依赖工具，反而不敢自己做决定了。这话有点老气，但想想也不是没道理。
两天压缩到两小时，省下来的时间拿去干嘛了？如果只是用来接更多的活、写更多的文档，那不过是换了个更快的仓鼠轮罢了。dr_950估计又要说我悲观，我倒觉得是看得多了，不太容易被效率这两个字唬住。
慢慢来吧，急什么呢。
比’翻译还是判断’这个二分法更想聊的是，AI把文档原型都包圆之后，低阶PM原来靠写字换来的那点’在场感’怎么办。楼主说翻译是可模板化部分，这点我认同，但翻译很多时候根本不是产出价值，它是’我参与了、我对得上’的证据。会议室里得有个人把乱糟糟的需求落成字，出事能指着文档说当时就这么定的。
你朋友那公司两天压到两小时，听着爽哈哈，但省下来的从来不是PM的命，是敲键盘的命。真耗PM时间的哪是写PRD，是来回拉扯——业务方周一要A周二变B，技术说做不了得砍，老板又空降个C。这些扯皮AI插不进嘴，没立场也不背锅。
所以安全区真不是’判断’，判断AI迟早甩你一脸选项。外包不出去的是’兜底’：功能上线翻车了谁去跟老板解释，谁签字。翻译能模板化，判断能被辅助，但’我负责’仨字没法甩给模型。
倒有个反过来的苗头挺好玩，写文档门槛没了业务方自己出初稿，PM反被推着往上走一层去定边界。这不叫取代，叫升级。话说话说现在招PM的jd有没有悄悄往’判断’侧偏了，好奇。
“翻译”和“判断”的边界其实挺模糊的，很多需求梳理本身就在做取舍。有具体数据支撑吗？
等等，你朋友那个“业务方直接对AI描述需求”的版本，我听着怎么觉得有点过于理想化了？我前两天刚跟一个在互联网大厂做中层的姐妹喝茶，她跟我吐槽的完全是另一个画风。
她们公司上个月也推了这套流程，结果呢？业务方发现不用求着PM写文档了，直接对着AI一顿输出，产出的PRD数量翻了三倍。以前PM还能卡一卡需求的合理性，现在业务方拿着AI生成的漂亮文档直接找老板批，搞得开发团队天天加班骂娘。她原话是：“AI没干掉PM，倒是把PM挡在业务和开发中间的那层缓冲垫给抽走了。”
所以我觉得你说的“判断力”护城河是对的，但现实可能更狗血一点。很多初级PM被卷走不是因为写文档不够快，而是他们本来就在充当业务和技术之间的“背锅侠”和“情绪垃圾桶”。AI能写出工整的需求，但它没法在会议室里替开发怼业务方的无理取闹啊。你们公司后来开发那边没闹意见吗？我挺好奇这个后续的
你朋友公司这招有点野，业务方自己对着AI唠需求？说真的业务方连自己要啥都常讲不明白，初稿怕不是车祸现场。不过你这角度清奇，PM看了得后背发凉哈哈
最后那个화이팅莫名把我逗乐了，像极了周一晨会老板喊完口号、大家转头继续装死。不过说真的，把谁的工作拆成「翻译」和「判断」两半，前半段都挺悬的。我倒觉得真要焦虑不如趁现在多摸会儿鱼，反正被卷的又不只PM这一拨。