裁员潮里，我对”技术人的护城河”的新理解

一、寒冬的真实感受

2022 年夏天，有个大学同学发消息问我，他们公司在谈补偿，他想聊聊接下来怎么办。

他在一家互联网公司做后端，工作了五年多，技术方向是公司内部的业务中台。我们聊了一个多小时，他说的一句话我印象很深：他们中台的技术方案都是公司特有的，外面几乎用不上，投了几份简历，面试问的东西他都没怎么接触过。

那段时间这样的消息不少。有人是主动离职在找机会，有人是被优化，有人是因为部门整合被”平移”到了一个没什么前途的岗位上。行业在降温，这件事对所有人来说都是真的，不是谣言，不是夸大。

我也开始认真审视自己的处境。

二、我观察到的规律

被影响最大的，大致有这样几类特征：

技术过于垂直单一。 只用过公司内部的框架和工具，比如某个公司自研的 RPC、配置中心，离开这家公司这些技能没有流通价值。

停留在执行层，未参与决策。 做了很多年，但一直是接任务、写代码，没有参与过设计方案、技术选型或者业务判断。一旦需要向外部证明自己的能力，能展示的只有”我在 XX 公司做了 XX 项目”，而不是”我能设计 XX 类型的系统”。

知识依赖特定上下文。 熟悉某个业务的每一个细节，但这些细节是公司特有的业务知识，不是可以迁移的技术判断力。换一个业务场景，需要重新从零学起。

留下来或者找到好机会的，普遍有几个共性：对通用技术理解比较深（数据库、缓存、消息队列的原理不只是会用）；做过有一定规模的系统设计；有外部可见度，比如技术博客、开源贡献、社区里认识的人。

三、反思自己

我在本子上列了两列：

可迁移的（换了公司、换了业务域还能用）：

• MySQL 调优、慢查询分析、索引设计
• Redis 选型与用法（缓存、分布式锁、限流）
• Spring Cloud 微服务架构经验
• Docker / K8s 基础运维
• 领域驱动设计的基本实践
• 技术方案设计与评审能力

高度依赖当前环境的：

• 公司内部的中台业务规则和数据模型
• 内部 CI/CD 流水线的操作方式
• 公司特有的监控看板和告警体系

诚实地看，可迁移的部分还算扎实，但”外部可见度”这一块很薄——我没有什么公开的输出，除了这个刚起步不久的博客，别人没有办法从外部判断我的水平。

四、我的应对策略

那段时间做了几件具体的事：

继续认真写博客。 不是为了流量，是为了把自己的判断外化出来。一篇把技术问题分析清楚的文章，比任何简历描述都更能说明你真正懂什么。

主动参与技术方案设计，而不只是实现。 遇到新需求，开始养成习惯：先写一份设计文档，把选择了什么方案、为什么、有什么取舍，都写清楚。这不只是对公司有价值，对自己的积累也是。

把技术深度放在通用能力上。 这段时间花了比较多时间在 MySQL 原理、Redis 内部机制这些方向，不是最前沿的技术，但理解了，在任何公司都用得上。

护城河这个词，我以前的理解是”你会的别人不会”。经历了 2022 年这段，我的理解变了：护城河是在你离开当前环境之后，还能带走的那部分能力。可带走的，才是真的有价值的。