前两天有个老同事找我喝酒，聊到一半他突然冒出一句：“我现在每天打开需求文档就心烦，感觉自己就是个翻译官，把产品的话翻译给开发，再把开发的话翻译给老板。等哪天 AI 把翻译这活干完了，我是不是也该滚蛋了？”他说完这句话，我沉默了一会儿。因为他不是个例，我最近见到的 PM 和开发，多多少少都在聊同一件事：到底什么能力才是真正扛得住时间、扛得住行业变动的？
我自己写代码写了十几年，也带过不少团队，见过大量所谓“只会写 CRUD 的码农”和“只会写文档的 PM”。标题这句话听起来有点刺耳，但它不是标题党，而是这两年行业真实在发生的变化。这篇文章我想把这些观察摊开来讲，不贩卖焦虑，也不提供什么一夜逆袭的万能药，只聊一些我自己踩过坑之后才明白的道理。适合正在做后端、全栈、或者产品岗的朋友看，也适合刚入行、正在犹豫自己该往哪个方向积累的新人。
1. 先聊聊 CRUD 这个词，以及它为什么成了贬义词
1.1 CRUD 的本义是什么
CRUD 是程序员最熟悉也最容易被忽略的一个缩写，它代表 Create、Read、Update、Delete，也就是增、删、改、查。一个最典型的业务系统，无非就是用户注册（Create）、浏览列表（Read）、修改资料（Update）、删除订单（Delete）。从纯功能实现的角度看，大部分 To B、To C 的后端接口都逃不过这四个操作。
我刚工作的头几年，天天做的就是这些事。给某个管理后台写一个用户列表接口，给 App 端写一个下单接口，数据库里 insert 一条记录，再写个 update 语句修改状态。那时候我真心觉得写代码挺容易的，无非是 Controller、Service、Mapper 三层，对着表结构写字段映射，再套一层 try-catch，一个接口就出来了。直到后来系统出了几次线上事故，数据对不上、性能扛不住、权限被人绕过，我才意识到 CRUD 只是“代码”里最表面的一层。
1.2 为什么“只会 CRUD”会成为一个问题
问题的关键不在 CRUD 本身，而在“只会”这两个字。如果你做增删改查做了三年，却讲不清楚这个增删改查背后服务的业务怎么赚钱、数据哪里来、哪些字段影响核心指标、哪个操作在极端并发下会崩，那你的可替代性就会变得非常高。
为什么会高？因为 CRUD 是高度模式化的工作。一个系统只要结构清晰，照着现有代码的风格再写一个增删改查接口，对很多中级开发者来说，半天时间足够。更别说现在大量辅助编程工具已经能根据数据表结构直接生成接口代码，甚至把常用的 CRUD 逻辑自动生成得比手写还规范。当一项工作可以被标准化、被工具化的时候，单纯靠“我会写”来吃饭，饭碗必然越来越小。
这里要澄清一点：不是所有写 CRUD 的人都危险。危险的是把 CRUD 当作全部的人。如果你能在增删改查之外，说清楚索引要怎么建、事务边界在哪、缓存怎么失效、消息丢了怎么补偿、业务状态机怎么流转，那 CRUD 只是表达手段，真正值钱的是你脑子里的判断。就像会用锅铲炒菜的人很多，但不是每个人都能在食材变了、火力变了、客人要求变了的时候，依然端得出一桌稳定的菜。
2. 从需求文档到提交流程：PM 的文档困境
2.1 只会写文档的 PM 做了什么
很多 PM 的日常工作，看起来特别忙：竞品分析、画原型、写 PRD、开评审会、排期、跟进上线、写会议纪要。一天下来七八个会，邮件和 IM 消息回不完。但如果你问他们一个最基础的问题：这个功能上线后，预期改变哪个业务指标？判断成功的标准是什么？如果数据不及预期，下一步怎么办？很多人的回答会变得非常模糊。
只会写文档的 PM，典型表现是文档永远很长，长到开发不愿意看；流程图永远很细，细到连异常分支都画了一百个；但是文档里讲不清楚“为什么要做这件事”，以及“怎么判断做得好不好”。需求评审会上，开发问得最多的不是“怎么做”，而是“这个场景数据从哪来”“这个逻辑跟现有用户权限怎么兼容”“如果同时满足 A 和 B 条件，优先级如何处理”。能把这三个问题当场答清楚的 PM，十个里面不到三个。
2.2 写文档和做判断之间的差距在哪里
差别就在“判断”两个字。文档是判断的产物，不是判断本身。你写十页 PRD，本质上是你已经做了决策：做这个不做那个，先做这个再做那个，这个按钮放在这里，那个流程走五天。真正有价值的是这些决策对不对，而不是那十页纸排版好不好看。
我前几年带过一个项目，业务方希望在订单列表页增加一个“批量退款”功能。当时负责的 PM 很勤快，两天就产出了一份非常详细的原型和状态流转图。但评审的时候我问了一句：批量退款和单笔退款在资金渠道上有什么区别？如果 50 笔里面混了一笔已经部分退款的订单，系统是要全部失败，还是跳过这一笔继续退？她当场愣住了，因为她没有做过任何资金方面的调研。后来这个项目其实不需要做批量退款，真正的需求是“财务对账效率太低”，我们改用了一个导出明细、按模板批量导入的方式，只花了两天就上线了。
这个例子说明什么？说明只会把别人说的需求翻译成文档，本质上是没有增加任何价值的。真正增加价值的是：你发现了问题的真正焦点，选择了成本更低的方案，说服了相关方接受你的判断。这个能力，AI 目前很难替代，因为它需要理解人情、预算、技术约束、用户心理，甚至还要在各方利益之间找到一个都能接受的妥协点。
3. 真正被市场认可的两种能力
3.1 对业务结果的 ownership
我先说一个现象：同样的技术岗位，有些人三年后能带项目、能跟业务对线、能参与公司战略拆解，有些人三年后还在抱怨需求变来变去、产品不懂技术、测试提 bug 不严谨。差距在哪里？不在于谁智商高，而在于谁把“问题”当成了自己的问题。
写 CRUD 本身没有错，错的是交差心态。你写完一个接口，测试通过了，任务状态改成“已解决”，然后就结束了。这是大多数人的行为模式。但有 ownership 的人会继续想：这个接口的响应时间会不会在数据量变大后恶化？异常情况下数据库的一致性和用户体验之间的平衡怎么取舍？这个字段的上游数据是谁在维护，如果上游给了脏数据，我这边要不要做兜底？这些追问乍一看不是 KPI，但恰恰是这些追问，决定了一个人在团队里是“执行的人”还是“扛事的人”。
PM 也是一样。你发版之后，功能上线了，但没人用，活跃度很低。你是写一份“上线总结”然后等下一个需求，还是会自己去看数据、做用户回访、找原因，并且主动提出下个版本怎么调？前者是一个文档员，后者才是产品经理。我见过很多优秀的产品负责人，他们并不是文档写得最好的人，但他们对结果负责的态度确实让人印象深刻。出了问题第一反应不是甩锅给开发或者运营，而是“我来想办法”。
3.2 对技术复杂度的掌控力
对码农来说，第二个稀缺能力是面对复杂系统的掌控力。CRUD 之所以简单，是因为它在确定的环境里做确定的事。但真实系统是什么样的？是突然流量翻倍、多个服务互相调用、某个第三方接口超时、缓存和数据库的数据不一致、历史脏数据需要迁移、权限体系要兼容五个旧版本。
这个时候，单纯靠“写代码”是不够的，你需要在脑内构建一套全链路图景：请求怎么进来，鉴权在哪层做，数据落在哪个库，缓存更新顺序是什么，失败之后有哪些补偿路径，日志能不能支撑问题定位。这个图景没法靠背面试题获得，只能靠一次次线上问题、一次次压测分析、一次次代码走查积累。你说这些是“CRUD 之外的东西”，但它才是决定项目成败的东西。
对 PM 来说，“技术复杂度”可能不是自己能动手写代码，而是需要理解技术约束如何影响产品决策。比如灰度发布意味着用户会看到不同的版本，你不能在文档里假设所有人看到的界面都一样；比如第三方登录在海外环境会有不同的合规要求；比如老系统的数据字段可能连不上一张漂亮的报表。了解这些不是为了让自己变成技术专家，而是为了在决策时不提荒唐的方案。
4. 实操建议：从 CRUD 工程师到能扛事的人
4.1 每天多问三个问题
如果你现在的工作主要是 CRUD，我建议你不要急着辞职，先做一个很小的改变：每天在写完代码之后，多问自己三个问题。
第一，这个功能的数据流是什么？用户在前端点了一下，请求经过哪些服务，到哪张表，返回以后前端又做了什么？第二，如果数据量变成现在的十倍，这个接口还能不能扛住？哪里会先出现瓶颈？第三，如果不做这个功能，有没有更简单的办法能达到同样的业务目标？这三个问题看起来很朴素，但坚持半年，你对系统的理解会明显不一样。我见过不少被提拔很快的同事，并不是因为他们写了多花哨的代码，而是他们能在需求评审里说出“这个功能其实可以用现成的标签系统实现，不用新建一套”，这种人对团队的价值远大于闷头写接口的人。
4.2 从接口文档里走出来，去看数据流
很多人的代码知识是“点状”的：会写接口、会调接口、会查表，但系统一旦跨服务就蒙了。我建议你找一个自己参与的项目，画一张真实的数据流图：客户端发起请求，经过网关、鉴权、业务服务、消息队列、定时任务、数据仓库，最终变成报表上的一个数字。把这些环节对应的代码、日志、关键字段全部标出来。
画完这张图，你会发现很多以前没注意到的问题。比如某个数据统计不准，是因为上游在埋点的时候把参数顺序搞错了；某个报表查得慢，是因为报表系统直接查了业务库，而不是走数仓；某个定时任务重复执行，是因为没有做幂等。这些问题都不是“加一个索引”或者“改一个 SQL”能解决的，它们需要你理解整个链路。而能理解全链路的人，在任何团队里都是稀缺的。
4.3 把项目当成你自己的产品
这个建议听起来有点像鸡汤，但我说的不是态度问题，而是操作方式。你可以试试在启动新需求的时候，自己先写一份“一句话说明书”：这个功能是给谁用的？他原来怎么解决这个问题？我做的方案为什么让他更爽？注意，要写你的真实理解，而不是抄 PRD 里的背景介绍。
比如你在做一个订单列表的筛选功能，一句话说明书可以是：“运营人员每天需要筛选出昨天未发货的高金额订单，以便优先处理异常，之前他们只能一行行看，因为筛选条件不支持组合，我的改进让筛选条件支持保存，并支持一键导出两类符合规则的订单。” 当你能写出这句话的时候，你写的筛选条件就不会只是为了应付产品需求，而是真正服务于一个场景。这个思维方式一旦养成，你会自动注意到异常状态、边界条件、空数据展示等产品细节，而你写出来的代码也会从“能用”变成“好用”。
4.4 PM 版本的操作建议
PM 如果不甘于只当翻译官，也可以做几个具体动作。
第一个动作是需求评审之前，自己先做一次“拦截式提问”：这个需求可以不做吗？做它要付出多少开发资源？最简可行方案是什么？第二个动作是上线之后主动看数据，而不是等别人告诉你。哪怕你是后端团队的 PM，你至少要知道这个功能有没有被用，用的人在里面卡在哪个步骤。第三个动作是把“文档”的地位降下来，把“决策记录”的地位升上去：一份三页纸的决策备忘录，列出当时的问题背景、备选方案、选型依据、风险点，比一份二十页的 PRD 更值钱。你会发现当你开始这样工作的时候，开发更愿意跟你开会，因为你提出的每个需求都像是“想清楚了”的，而不是“拍脑袋”的。
5. 踩坑实录与转型误区
5.1 我见过最可惜的职业弯路
我先讲两个真实例子。第一个是前几年招过的一个后端，进来的时候我就知道他基本功不错，但有个很明显的特点：他喜欢接“好写的需求”，排斥“难缠的需求”。给他排一个登录接口，他效率很高；给他排一个跨系统的数据同步任务，他总说这不是他熟悉的活。结果两年后，他还是那个只能处理简单 CRUD 的人，而同期进来的另外一个同事已经能把线上复杂的重构项目扛下来了。这不是能力差异，而是选择差异。
第二个是之前合作过的产品运营转岗 PM。她很会写文档，每次发版说明都排版精美，流程图里连一个异常分支都不放过。但是连续三个版本上线后，核心指标都没变化。别人问她有没有什么发现，她说“我按流程执行了”。她把“写文档”当成了“做产品”，但产品不是文档的集合，是决策的集合。她后来离开了那个团队，去了一个偏执行的公司，仍然写很漂亮的文档，但我知道她内心是焦虑的，因为她也意识到自己在做可以轻易被工具替代的事情。
5.2 常见问题速查表
我自己也被问过很多次“到底怎么才能不被淘汰”，整理成一张速查表供参考。
| 典型症状 | 真实问题 | 调整方向 |
|---|---|---|
| 代码能跑，但讲不清为什么这么设计 | 停留在实现层，没有设计判断 | 每次写代码前先写一段“方案说明”，列出两个备选方案并给出理由 |
| 需求来了就做，做完就等下一个 | 没有业务目标感 | 主动问产品经理：这个需求的成功指标是什么，怎么衡量 |
| 文档写得长，评审会开得多，但决定迟迟下不来 | 把文档当结果，回避判断风险 | 强制自己给出“我建议做A，因为B和C，风险是D”的结构化结论 |
| 看报错只会搜错误码，不懂从链路里排查 | 缺乏全链路意识 | 挑一个真实故障，从入口到出口完整复盘，写一篇 postmortem |
| 提到业务就不耐烦，只喜欢技术挑战 | 过度迷恋技术本身，忽略价值 | 找自己系统的用户问一次：你用这个功能的时候最难受的是什么 |
| 明明很努力，每天加班，却没有长进 | 用高强度劳动替代深度思考 | 每周留两小时不写代码，只做回顾：哪个决策可以做得更好 |
| 总担心被替代，但一直不敢跳出舒适区 | 焦虑而没有行动 | 选一个与日常工作略有距离的活，比如重构模块、优化性能、写自动化测试 |
这张表不是标准答案，但它给了一个自检的方向。你要是发现自己中了三条以上，大概率需要停下来想想了，这是警报，不是坏事。
5.3 一些判断自己是不是正在被“清退”的信号
除了上面那几条症状，还有一些更隐蔽的信号。比如你发现自己的经验并没有随时间增值：半年前你解决一个问题需要一天，半年后遇到同类问题，你还是需要一天。如果你没有更快，说明你没有真正从经验里抽象出规律。再比如你发现你负责的模块可有可无：离职交接只需要半天，其他人接管也不会有太多学习成本，这说明你的积累大多藏在系统已有模式里，而不是你自己的判断里。还有一条很扎心但真实：年会或者部门调整的时候，你的名字没有被任何一个人想起来，因为你没有做过任何跨团队拉通、争议拍板或者救火的事情。
这些都是我这些年观察下来的真实感受。它们不代表你马上会被淘汰，但确实说明你在“低价值区”待了太久。低价值区不是没有价值，而是竞争太充分、替代成本太低。
6. 最后一点个人体会
写到这里，我想说一句真心话。我不认为这个时代会把认真做事的人清退，但它一定会把“只做表面动作的人”清退。CRUD 本身不丢人，文档也不丢人，丢人的是以为做完这些就是完成了一个职业的全部。股神巴菲特那句“当潮水退去，才知道谁在裸泳”用在这里很贴切。以前行情好，什么人都能分到一杯羹；现在潮水退了，真正留下的不是最会写代码的，也不是最会写文档的，而是最会解决问题的人。
我个人体会最深的，是把自己从一个“接需求的人”变成“对结果负责的人”之后，那种焦虑感会明显下降。因为你不再依赖外部给自己定义价值，你能清楚地看到一个问题，在脑子里形成方案，然后组织资源把它落地。这个能力，是可以跨行业、跨岗位迁移的。最后一个实用小建议：无论你是 PM 还是开发，每月月底花半小时，记录一下本月你做的哪些事情是“只有你能做”的。如果连续三个月这个清单都是空的，那你真的要警惕了。这个简单的习惯救过我，我也希望它能帮你。
