这两年我一直在做技术团队的管理前后也面试过几百人。说实话2024年下半年之后我明显感受到一个变化市场上最不缺的就是“只会写文档的PM”和“只会写CRUD的码农”。听起来很残酷但现实比这更坦白。前阵子有个做产品的朋友跟我说他手下的一个PM写PRD写得极其工整流程图、用例、状态机说明样样齐全但一旦被问到“这个功能到底解决什么问题”、“上线后用什么指标衡量成败”就哑火。另一边我见过不少后端开发三年经验CRUD增删改查写得很溜Controller、Service、Mapper三件套手到擒来但你要是问“这条数据链路如果扛不住峰值流量你打算怎么拆”他只能支支吾吾。警报确实已经拉响了但我要先说清楚时代清退的从来不是岗位而是那些无法在价值链条上往前迈一步的人。这篇文章不贩卖焦虑我是想把“为什么偏偏是这两类人”讲透再给出真正能落地的转型路径。无论你现在是文档写得麻利的PM还是CRUD写得飞快的开发这篇文章都适用尤其是那些开始对当前状态感到不安、却不知道劲往哪儿使的人。1. 先说清楚为什么偏偏是这两类人站在清退名单上1.1 文档PM的真实处境写了无数PRD却没碰过真正的业务决策我觉得有必要先给“只会写文档的PM”画个像别对号入座完还觉得跟自己无关。这类PM的工作模式通常是这样的业务方提了一个需求他组织开会、记录结论、画原型、写PRD文档里把页面字段、交互细节、异常流程描述得清清楚楚。到了评审会上他能把文档从头到尾念一遍。但一旦业务方反问一句“这个需求你觉得值不值得做”或者“如果我们只能投入一半的资源哪个功能可以先砍掉”他就开始含糊其辞。问题的本质不在“写文档”这个动作本身而在于他把自己定位成了需求的转录机。转录机做的事情是把一段话从口语转成书面语从会议纪要转成PRD。这件事在过去是值钱的因为沟通成本高、信息损耗大能把模糊的想法变成开发同事看得懂的文档确实是一种能力。但今天的AI工具比如各种AI写作助手已经能非常高效地完成“把零散想法结构化”的工作。你说几句要点它就能生成一份结构完整的PRD初稿。当“转录”这件事的成本趋近于零时只会转录的人自然就被置于危险境地。更扎心的是这类PM在团队里的真实话语权也很弱。研发不重视他因为他不能拍板业务不尊重他因为他只传话不带判断。一个既没有决策权也没有判断力的人本质上就是一个“票据中转站”少了他流程照走有了他也不多产出。这才是被清退的根本原因。1.2 CRUD码农的困境天天在写代码但代码里没有“思考密度”再看技术侧。“只会写CRUD的码农”这个说法在圈子里已经快变成一个梗了。但我们要拆开看CRUD本身只是数据操作的最基本四件事增加Create、查询Read、更新Update、删除Delete。任何一个业务系统归根结底都是这四件事的组合。问题从来不在“要不要写CRUD”而在**“你的工作是不是只有CRUD”**。我面试过一个候选人简历上写着三年Java后端经验项目经历是做内部管理系统里面全是订单管理、用户管理、权限管理这类模块。我问他“你们的订单表是怎么设计的为什么状态字段用了整数而不是枚举”他说这是历史遗留没想过。我又问“订单列表页接口为什么分页用offset不用cursor如果数据量到千万级别这个接口还能用吗”他沉默了。那一刻我很遗憾因为我知道他不是不聪明而是过去三年里他的工作模式就是产品给原型、他照着建表、写增删改查、自测通过就提测。他的代码只是在执行需求并没有承载任何设计决策。这样的代码AI当然可以替代。现在的AI辅助编程工具输入一个表结构、写清楚字段含义生成一套标准CRUD接口已经是白菜级的能力低代码平台更不用说拖拖拽拽就能生成一个管理后台。当“增删改查”这种规则清晰、输入输出明确的编码活动变成商品化服务时只掌握这个层级能力的人议价空间就会被无限压缩。1.3 被清退的底层逻辑AI最擅长替代“确定性执行层”把两类人放在一起看会发现一个共同点他们都在做**“边界清晰、规则明确、反馈直接”**的工作。写PRD的格式规范是明确的字段描述是明确的写CRUD的表结构是明确的接口返回格式是明确的。这类工作有一个共同特征只要把规则讲清楚一个足够聪明的工具就能做而且做得不比人慢。我用一个生活化的类比来解释。餐馆里的传菜员他的工作是把后厨的菜端到对应的桌上。这件事规则清晰、流程固定所以它是最先被自动送餐机器人替代的岗位。但研发新菜品的厨师不会被替代因为他需要判断“哪种食材跟哪种酱汁搭配口感更好”这是一个依赖味觉经验、市场洞察和创造力的判断过程。AI时代的替代优先级就是从“传菜员”这类确定性执行层开始的。文档整理是传菜增删改查也是传菜。如果你在价值链上做的事恰好只是“把一个确定的输入按照确定的规则转成一个确定的输出”那你本质上就是一个可以被脚本化、自动化、甚至被Agent代替的执行单元。警报拉响拉的就是这个位置。2. 换个视角不是岗位死了是价值锚点移了2.1 PM的新锚点做对的事而不是把事情写对如果把“写文档”看成PM的下限那新版PM的上限应该锚定在**“做对的事”**上这也是我反复跟团队强调的一个转变思路。什么叫“做对的事”就是当你面对一堆待办需求时你有能力判断哪一个投入产出比最高哪一个可以让用户真正留下来哪一个应该直接砍掉。这种判断力来自三个方向对用户的理解、对业务逻辑的理解、对数据的敏感度。有了这三样能力之后你会发现写PRD只是水到渠成的一件事因为你已经知道该做什么、为什么做文档只是把判断结果固化下来。落到具体动作上新版PM在需求评审会上应该问出这些问题而不是念文档这个需求的用户场景是什么是一级场景还是低频偶发我们要解决的是不是用户最痛的那件事有没有数据支撑做这个功能的机会成本是什么如果不上这个我们能做什么更划算的事上线之后第一周看什么指标什么情况下我们应该回滚这五个问题问完PM的角色就已经从“记录员”切换成了“决策参与者”。哪怕是同样在写文档你写的角度也会完全不一样你不会再机械地罗列功能点而是会写清楚“为什么是现在做”、“为什么是这样设计”、“我们如何验证成功”。这种文档业务方看得进去研发愿意跟你讨论因为里面包含了判断和依据。2.2 开发的新锚点构建会成长的系统而不是交付一批功能开发侧的新锚点也类似从“交付功能”转向“构建会成长的系统”。什么意思CRUD开发者关心的是“这个功能怎么做出来”而系统构建者关心的是“这个系统怎么在一年后、三年后还能低成本地演进”。举个例子同样是做一个订单超时自动取消的功能。CRUD开发者的思路是加一张表记录订单和超时时间然后写一个定时任务每分钟扫一遍把超时的单子状态改成已取消。这个方案能跑通正常量级下没问题。但系统构建者会多问几个问题订单量涨到每天百万级每分钟扫全表的做法还能撑住吗超时取消的延迟怎么保证在用户可接受的范围内如果订单服务挂了取消逻辑会不会跟着失效如果支付已经完成、但订单还没取消要不要补发通知一旦开始思考这些问题方案就变成了用延迟队列或时间轮来调度超时任务用事件驱动替代轮询扫描通过消息重试机制保证最终一致性。同样是实现一个功能前者的代码只是在完成业务规则后者的代码是在构建系统韧性。这个转变最大的困难不在于技术栈而在于视角。你不再把自己看成“需求单的执行者”而是这个系统的owner你要对它的性能、稳定性和演进空间负责。系统出问题不是先去甩锅给产品需求不清楚而是先复盘设计方案在哪个环节缺失了深度。2.3 共同的新红线效率不再值钱判断才值钱把PM和开发的新锚点放在一起看背后其实是一条很清晰的线“正确性”正在变得廉价“取舍”正在变得昂贵。文档写得正确、代码写得正确这些都是下限。AI可以帮你把正确性做到80分甚至95分但“这个需求到底做不做”、“这条技术路线到底选A还是选B”、“系统复杂度到什么程度就该停下”这类问题需要的是对业务上下文的理解、对成本和收益的权衡以及对未来变化的预判。这套东西没法靠一个提示词就获得它需要你长期扎在业务里、扎在用户里、扎在生产环境的事故里。所以我的判断是真正危险的不是“你的title叫PM还是开发”而是你在整个产品价值链条上所处的位置是否过于靠下游。越靠近“执行”的位置越容易被替代越靠近“判断”的位置越安全。3. 落地实操我给两类人分别列了一份转型行动清单3.1 PM转型路径从需求传声筒到业务操盘手如果这篇文章能对你有一点实际的帮助那最好体现为这份清单能让你动起来。我不是要你辞职去读MBA下面这些动作是你在当前岗位上就能逐步做起来的。第一步学着拆需求真伪。下次业务方再提一个需求时别急着进会议室排期先问三个问题这是谁的需求有多少用户真实遇到解决它能带来什么可量化的变化我见过最典型的伪需求是某个管理后台想加一个“数据导出Excel的多样化格式配置”业务方说了一堆使用场景结果一问实际提出这个需求的用户就一个而且他已经有替代方案了。浪费了三周的迭代资源最后功能上线两个月没人用。学会用“用户数、频次、业务影响”这三个维度去过滤需求你的价值立刻显现。第二步建立你的指标体系。任何一个需求上线前都要回答一个问题怎么定义成功或失败。不用整得很复杂一个北极星指标加两三个辅助指标就够。比如做“订单超时自动取消”这个功能北极星指标可以是“超时订单关闭率”做得好的标准是“超过X分钟未支付的订单90%以上能自动关闭并释放库存”。上线第一周你要做的是盯这块数据而不是急着提下一个迭代。这个习惯一旦养成你就不再是“提完需求就跑”的工具人而是会为结果负责的操盘手。第三步画流程而不是画页面。文档PM画原型画得再细也只是描述了“页面长什么样”。业务操盘手更关注“业务是怎么流转的”库存什么时候被锁定支付成功之后哪个环节触发发货退款和取消之间竞态怎么处理我建议你从自己负责的模块入手画出完整的业务流程图标注异常分支。当你对业务流程的理解超过研发时没人敢把你当传声筒。这三步走下来你再回头写PRD会发现文档只是你思考过程的自然输出而不是你工作的全部。真正的价值发生在“思考过程”里文案只是副产品。3.2 开发转型路径从数据搬运工到系统架构师开发侧的转型我建议从三个方面同步推进。第一个方面模型思维先于表结构。CRUD开发的惯性是“先想表怎么建”。这个惯性已经不适合今天的复杂度了。你应该反过来先用领域模型去描述业务订单是一个聚合它包含商品明细、支付信息、履约状态订单状态的变化不是随便update一个字段而是由领域事件驱动。你可以不引入复杂的DDD框架但建模思考方式可以先切换。我建议你挑一个自己最熟悉的业务模块尝试把状态的if-else堆砌改成状态机或状态模式用事件表达状态流转。这一个改造做完你对“代码设计”的理解会上一个台阶。第二个方面非功能需求不能只看文档。这是CRUD开发者最陌生的领域。在实现任何一个接口前都主动问自己四个问题这个接口预估QPS是多少单条数据多大允许的响应时间是多少数据需要保证多强的一致性不用你去做压力测试至少你要在方案设计里把这个维度的思考写进去。举个例子一个订单列表接口在数据量3万条时用offset分页没问题到300万条时你应该主动提出改用基于游标的分页方式并且说明为什么——因为深分页的偏移量会导致数据库扫描大量无用行。这种主动性和技术判断力才是区分“码农”和“工程师”的分水岭。第三个方面拥抱AI工具但保持架构控制权。现在AI代码生成质量已经很高基础的CRUD代码生成效率远超手写。我的建议是AI能干的活你就不用重复造轮子把省下来的时间投入到系统设计、技术调研、代码 review 和质量保障上。但有一点要注意AI生成的代码你不是不能review的甩手掌柜你要能看懂它生成的代码在干什么、为什么这么写、有没有安全隐患。架构选型和数据模型设计这些关键决策永远不要全权交给AI。3.3 团队如何系统性降低“清退风险”讲了个人层面的转型我还想给带团队的管理者一点建议。因为个人焦虑往往是系统问题的一个投影。如果你的团队里大量存在“只会写文档的PM”和“只会写CRUD的开发”不是这些人天生不行而是组织机制没有逼他们向上走。如果你想改变这个状况可以试试在三件事上做调整。第一考核指标从“交付量”转向“业务结果”。PM的考核不该是“输出PRD的数量和速度”而应该是“所负责功能上线后的核心指标变化”开发的考核不该是“提了代码的行数和接口数”而应该是“线上事故率、接口性能、技术债务的化解节奏”。第二评审会上多问“为什么”。管理者要主动示范提问这个需求为什么排这个优先级这个方案为什么不用消息队列如果管理者都不关心答案下面的人自然也不会去思考。第三设立轮岗和跨岗位沟通机制。让PM参与数据分析和用户访谈让开发参与需求评审和线上值班打破岗位隔离区大家才会开始用全链路的视角看问题。4. 转型路上我踩过的坑4.1 转型失败案例访谈学了AI工具、买了一堆课还是没有安全感聊完了该怎么做我更想说说实际转型过程中大家容易踩的坑。我见过不少年轻同事意识到危机之后很努力——买了一堆AI课程天天刷技术文章收藏夹里存了几十个学习链接但三个月后还是在原地打转。为什么因为他们走进了一个误区把“学工具”当成了“重建价值”。使用AI工具本身不会让你变得更安全。就像十年前会打字不会让你变成不可替代的高手今天会用几个AI提示词也不会。真正让你值钱的是你观察业务、定义问题、做出取舍的能力这些能力不在任何一门“AI实战课”里而在你一次次参与真实项目、拆解真实问题的过程里。我另一个同事踩过的坑是转型动作太猛直接从一个极端跳到另一个极端。他是做后端CRUD的看完这篇文章的话题后立刻开始学微服务、学DDD领域驱动设计、学各种高并发中间件试图把自己凹成一个“资深架构师”。结果呢实际项目里业务复杂度根本不需要这些技术他学的那些知识全变成屠龙之技讨论方案时提了一堆过度设计的主张反而让团队反感。转型不是越复杂越好而是越匹配越好。你应该先从当前系统的真实瓶颈出发解决的问题优先级是线上稳定性、核心代码的可维护性、关键接口的性能。解决这些问题的过程中需要什么就学什么用真实问题牵引学习而不是反过来。4.2 常见十大问题与避坑建议这里针对两类人群最常遇到的十个问题做一份速查式的解答都是我实际带人或交流中反复遇到的问题。问题我的回答和建议我是PM但公司业务很传统没什么数据可看怎么办数据不一定是埋点平台里的指标。Excel表格导出的订单记录、客服群里的反馈、竞品的产品变更都是数据。先建立自己的信息收集习惯可以从每周一份业务观察记录开始。我是开发学了很久新技术但工作中根本用不上怎么办用不上不是因为你不需要而是你没有尝试把它用到小场景中。状态机改造、缓存优化、异步消息解耦甚至一个接口的重构都算落地实践。先从小处动手往大了扩展。我所在的岗位本身就很边缘只能写文档/写CRUD怎么破在你的职责边界上多主动做一步。PM主动去访谈用户开发主动去监控页看线上日志。先证明自己能做超出“转录”和“搬运”的事再慢慢争取话语权。现在公司有裁员的传闻我该立刻投简历吗行动上可以保持市场关注但心态上别把自己放在“避难”模式。先去提升自己的价值锚点否则从这个坑跳到另一个坑本质没有变化。AI现在这么强基础代码还需要自己看吗大部分常规代码AI可以代劳但核心判断你得自己做。AI帮你生成代码后你要能reviewAI给你一个方案时你要能说出这个方案的优劣势和适用边界。PM需要学技术吗学到什么程度学技术的目的不是为了写代码而是为了理解约束。你不需要会写Java但你应该能看懂状态流转、数据结构因为技术约束会影响产品方案不懂约束的你做出来的方案可能是一张废纸。转型总是失败是不是我天赋不够大概率不是你天赋不够而是你目标定得太大、周期太短。Value迁移本来就是以季度甚至年为单位的复利过程。我建议你定一个12个月的项目每季度只做一件事。我只会SQL和CRUD年龄也不小了还来得及吗来得及但姿势要对。不要跟年轻人拼学习速度拼你的业务经验和对现有系统的熟悉程度。深挖一个领域把你对业务域的理解和系统设计能力结合起来这就是不可替代性。AI是不是真的会取代程序员取代一些重复性的编码执行工作是这个趋势的一部分但AI很难取代那些能定义“什么不该做”、“怎么做得更好”的人。换句话说取代不会写代码的写代码者。我转型的最终目标是什么无论你是PM还是开发最终目标都是成为具有业务判断力的系统设计者。只是产品侧和工程侧的表达不同但内核一致能把复杂问题结构化能把取舍讲明白。4.3 我的最终建议与其被清退不如自我拉响警报你看到这里其实“警报拉响”这四个字已经被我拆开了。警报不是外界给你的而是自己给自己的信号。我在团队里最怕看到的不是有人承认自己不会而是有人觉得自己“就这样了”。真正的清退很多时候不是某一天HR找你谈话而是在你停止成长的那一天就已经开始了。从这个角度讲被时代清退的从来不是某个岗位而是持续停留在价值链下端的那种状态。只要你在动在往前迈你的位置就不会丢失。我个人的体会是转型过程中最难的从来不是学会新东西而是放下旧的自我认知。PM要学会承认自己过去三年写的文档其实有大量是为了交差开发要学会承认过去写的CRUD代码虽然能跑但并没有太多设计含量。承认了之后再去重建自己的价值体系反而会走得更稳。这条路没有捷径该啃的业务数据、该画的架构图、该承担的事故责任一样都逃不掉。最后分享一个我的小判断标准在招人面试时我最在意的不是候选人会什么工具、能写什么框架而是他能不能把一件小事讲出深度。比如问他“你负责的模块里最让你头疼的一个技术问题是啥”如果他能讲清楚问题的背景、他做了什么取舍、代价是什么、如果重来会怎么选——这种人AI替不掉。这个标准你也可以拿来自我审视。