40岁技术人最贵的能力，不是会新技术，是会定义问题

作者：小蒋
邮箱：wei_wei10@163.com
音频版：https://xima.tv/1_XpVvzf?_sonic=0

【小蒋聊技术】关注技术成长，深挖业务价值。大家好，我是小蒋。

写在前面

最近和一个差不多同龄的朋友吃饭，他比我还焦虑。

他说：

「现在年轻人用 AI，一天能搭个系统出来。」
「云原生、大模型、各种新框架，我学不过来。」
「四十了，再卷技术栈，身体和精力都跟不上。」

这话我听懂了。因为这不只是他的问题，是很多 80 后技术人共同的处境。

大家默认的解药通常是：

再报一门课，再学一门新技术，再追上这一波。

但我越来越觉得，这条路对四十岁前后的人，性价比正在快速变低。

---

一、大家以为：不会新技术，就会被淘汰

这个误区很普遍。

领导问：你会 Kubernetes 吗？
市场问：你用过大模型吗？
招聘写：熟悉云原生优先。

于是技术人很容易得出一个结论：

我值钱，是因为我会的技术够新、够多。

年轻时，这个逻辑大致成立。
那时候行业缺人手，会一门主流技术，就能换岗位、换薪水。

但到了三十五岁、四十岁附近，战场变了。

企业真正缺的，往往不是「又能写一种中间件的人」，而是：

• 能把含糊需求拆清楚的人
• 能挡住错误项目的人
• 能在业务、技术、组织之间做权衡的人
  

新技术当然有用。
但对这个阶段的人来说，它不再是主战场。

---

二、冲突来了：公司要的，和你练的，不是一回事

我在项目里常见这样一种局面。

业务说：

「我们要做一个数字化平台，先把流程线上化。」

技术负责人想的是：

「用微服务还是单体？上不上中台？要不要上 AI？」

一线同学忙的是：

「接口怎么设计，表怎么建，页面怎么赶。」

领导最后问的是：

「上线后效率提升了多少？问题有没有真解决？」

四拨人，四个目标。

如果这时候你最擅长的是「把功能做出来」，你会很勤奋，也很容易做成这样：

系统上线了，功能齐了，演示也漂亮了——
但业务不买账，一线不用，领导觉得钱花了、事没成。

问题出在哪？

不是代码写得不够快。
是一开始就没把问题定义清楚。

---

三、小蒋判断

先给结论：

40岁技术人最贵的能力，不是会新技术，是会定义问题。

会新技术，解决的是「怎么做」。
会定义问题，解决的是「该不该做、先做什么、做成什么样才算值」。

前者越来越便宜。
后者越来越稀缺。

---

四、为什么「定义问题」突然变贵了？

1. AI 正在把「实现」打成白菜价

以前，把一个想法做成系统，本身就很贵：排期、开发、联调、上线。

现在，AI 能显著降低这部分成本。
会写 CRUD、会搭页面、会调框架，护城河变薄了。

于是市场开始重新定价：

谁能在一堆诉求里，找出真正值得做的那一个，谁更值钱。

2. 企业不缺系统，缺「做对的事」

很多单位不是没系统，而是系统太多：

• 每个部门一套
• 每个项目一个平台
• 每个领导一波新概念

结果是系统越上越多，协同越来越难，数据对不上，责任说不清。

这时候再学一个新技术去「再做一套」，常常是在加速浪费。

3. 四十岁拼体力学框架，回报曲线变差了

不是不能学。
是同样 100 小时，投在「新技术栈」和投在「问题判断」上，回报已经不一样了。

年轻人可以用时间换技能宽度。
你更应该用经验换判断厚度。

---

五、什么叫「会定义问题」？看一个典型场景

假设业务提了一句：

「我们要做个报表面板，领导要看经营数据。」

技术执行者容易直接开干：

选 BI、接数据、出图表、赶演示。

会定义问题的人，会先停一下，问四件事：

1. 领导要看的，是数字，还是要做决策？
   如果只是「看起来有数据」，项目价值很薄。

2. 现在决策卡在缺数据，还是卡在口径不统一、流程不闭环？
   很多时候系统不是解药，治理才是。

3. 成功标准是什么？
   是上线一个页面，还是缩短决策周期、减少扯皮、降低差错？

4. 如果流程、组织、权责不改，系统上了会不会没人用？
   这个问题不问，后面大概率返工。

你看，真正拉开差距的，不是你会不会某个报表组件，
而是你敢不敢、会不会把「要个系统」翻译成「要解决的业务问题」。

---

六、一个可抄作业的模型：问题定义四问

以后再接到需求，先别急着排期，先过这四问：

四问	你要逼出来的答案	答不上来时意味着
1. 谁痛？	真正受益/买单的角色是谁	需求可能只是「听说要数字化」
2. 痛在哪？	卡在流程、数据、组织，还是单纯缺页面	容易做错解法
3. 何谓成？	可观察的结果，而不是「系统上线」	项目必然变成验收游戏
4. 先改什么？	先改规则/流程，还是先上系统	系统容易变成新债

我把这套东西叫：问题定义四问。

你会写代码，是合格开发。
你会这四问，才开始像个能扛事的技术负责人或架构师。

---

七、那新技术还要不要学？

要，但换个学法。

不是为了「简历好看」去追全集。
而是围绕你正在解决的问题，按需补工具。

比如：

• 问题是发布不稳，你再补 CI/CD 和可观测
• 问题是数据口径乱，你再补数据治理和主数据
• 问题是需求总变，你再补领域拆分和边界设计

技术是锤子。
问题定义，是先看清要钉的到底是不是钉子。

AI 时代更是如此：

实现变便宜后，乱做的成本不是下降了，而是上升了——
因为错误方案会被更快地做出来，更快地铺开，更快地形成沉没成本。

---

八、给 80 后技术人的三条实操建议

1. 把「学习时间」切一块给「判断训练」

每周留固定时间，复盘一个真实需求：

• 当时大家以为问题是什么
• 后来发现真正问题是什么
• 如果重来，你的四问怎么问

这比刷一门新框架课，更接近你下一阶段的竞争力。

2. 在会上少先报方案，多先对齐问题

下次评审，先别急着画架构图。
先争取 10 分钟，把「谁痛、何谓成」钉死。

很多人怕这样显得「不会做」。
恰恰相反，这才是成熟技术人的样子。

3. 让你的经验可对外表达

四十岁以后，经验如果只停留在你脑子里，市场给不出价。
要把它变成：

• 判断框架
• 复盘文章
• 能帮企业避坑的方法

你才可能从「被安排做系统的人」，变成「被请来定问题的人」。

这也是我做「小蒋聊技术」的原因之一：
聊技术，但不止技术；把现场里那些贵的判断，讲清楚。

---

最后的思考

如果让我给同龄技术人一句不中听、但值钱的话，我会说：

别再用「我是不是又落后一个技术栈了」折磨自己。

真正该问的是：

我有没有变得更会定义问题？
有没有更敢在错误需求面前停下来？
有没有让业务因为我的判断，少走弯路？

新技术可以学，也值得学。
但四十岁前后，最贵的资产不是又多会一门框架，
而是你能不能把混沌需求，变成可决策、可落地、可验收的问题。

这能力练出来了，你才站在 AI 时代涨价的那一侧。

---

如果你也卡在「技术还会，但越来越慌」的阶段，欢迎在评论区留下你现在最难定义清楚的一个需求场景。
我后续会挑典型问题，继续拆：怎么问、怎么挡、怎么收口。

---

我是小蒋。
一个在企业一线做数字化建设的架构师。
技术解决的是系统问题。
架构解决的是企业问题。
我们下期继续聊技术，也聊技术背后的那些事。

小蒋聊技术
用架构师的视角，理解技术、理解企业、理解未来。