# 能力模型：高级与专家的分水岭

> 高级程序员解决被定义好的问题，专家程序员判断该不该解、解到什么程度，并让团队在没有自己的时候也能做对。三者的差距不在编码速度，而在**问题空间、决策半径、组织杠杆**。

## 一、三个维度

| 维度 | 高级 | 专家 |
| --- | --- | --- |
| 问题空间 | 需求清楚，边界明确，负责「怎么实现」 | 需求模糊，需要自己定义边界「到底要解决什么」 |
| 决策半径 | 一个模块/服务，影响单条业务线 | 一个系统/技术域，影响多条业务线与后续几年的演进 |
| 组织杠杆 | 自己交付得好 | 让 10 个人交付得好；标准、工具、判断被复用 |

三个维度不是并列的，是递进的：**问题越模糊，越需要判断；判断影响越广，越需要把判断讲清楚；讲清楚之后，才能变成别人的默认动作。**

## 二、同一件事的两种做法

| 场景 | 高级的做法 | 专家的做法 |
| --- | --- | --- |
| 需求评审 | 评估工作量，指出技术风险 | 先问「不做会怎样」「有没有更便宜的解法」「这个需求和现有能力是否重复」 |
| 故障处理 | 快速定位并修复，恢复服务 | 先止血、再定位、后修复；同时判断是不是同类问题会再次发生 |
| 技术选型 | 对比 3 个框架的文档与性能 | 先明确约束（团队、成本、合规、演进），再判断哪个约束是真约束；准备退出路径 |
| 代码评审 | 指出 bug 与不规范写法 | 判断改动是否让系统更难改；指出设计层面的隐患；把问题变成规则 |
| 排期 | 给出人天估算 | 给出关键路径与风险缓冲；提前暴露「这个时间点做不到什么」 |
| 带人 | 答疑、帮改代码 | 让对方自己得出结论；把重复问题沉淀成文档与检查项 |

差别不在「谁更懂技术」，而在**是否在更高一层定义问题**。

## 三、四个能力陷阱

**1. 熟练的无能**
在一个技术栈里做了八年，熟练度极高，但换一个约束条件（成本、团队、合规）就失灵。熟练让人停止提问，而专家恰恰是靠持续提问保持判断力。

**2. 局部最优**
把自己模块的性能优化到极致，但整体链路因为这一段而变复杂。系统的价值在端到端，不在单点。判断标准是「用户感知的指标有没有变好」，不是「我的服务 P99 降了多少」。

**3. 技术自嗨**
用新技术解决一个用现成方案就能解决的问题。专家会问：这个方案带来的复杂度，是否小于它解决的问题？如果团队没人能维护，收益就是负的。

**4. 救火英雄**
越是能救火的人，越容易被留在救火的位置。专家会把「救火」变成「不出火」：补监控、改流程、加约束。救火能力值得尊重，但它不是成长方向。

## 四、从高级到专家的三条杠杆

**杠杆一：复用——把解法变成资产**
同一个问题解三次，就该抽象成库、模板或流程。判断标准：下一次同类需求，团队里任何人都能自己完成。

**杠杆二：抽象——把个案变成模型**
处理完一个线上问题，能归纳出「这一类问题的触发条件、观测信号、处置动作」。模型的价值在于**预测**：下次还没出事，你就知道该看哪里。

**杠杆三：影响——把判断变成默认**
你不在评审现场，团队依然会用你的标准做决定。做到这一点靠三样东西：写下来的原则、可执行的检查项、以及你带出来的人。

## 五、五个问题，判断自己到没到专家级

1. 最近半年，你有没有**否决**过一个需求或方案？理由是什么？
2. 你负责的系统，如果明天你休假两周，会出什么问题？
3. 你做的技术决策，有没有写下「当时的约束」和「被否决的方案」？
4. 团队里有没有人因为你的影响，做出了比你更好的判断？
5. 你能说出自己方案在什么条件下**不成立**吗？

五个问题里少于三个能答，说明还在高级阶段——这不是问题，问题是不承认。

## 六、12 周练习方向

| 周期 | 练什么 | 产出 |
| --- | --- | --- |
| 第 1—3 周 | 定义问题 | 每次需求评审写一段「问题陈述」：为谁、解决什么、不解决什么 |
| 第 4—6 周 | 做取舍 | 每个方案写 1 页对比：约束、选项、代价、被否决的理由 |
| 第 7—9 周 | 建模型 | 复盘三次故障，归纳共同的触发条件与观测信号 |
| 第 10—12 周 | 扩影响 | 把一条判断写成规范/检查项，推动团队采用并观察执行率 |

## 七、自检清单

- [ ] 我能用一句话说清当前系统的**核心约束**（成本？合规？交付速度？）
- [ ] 我的方案里写明了「不做什么」，而不只是「做什么」
- [ ] 我知道自己系统最可能出问题的三个地方，以及对应信号
- [ ] 我做的决策有书面记录，半年后能还原当时的判断依据
- [ ] 我评审代码时，至少提一条设计层面的意见，而不只是风格与 bug
- [ ] 我能说出团队里每个人的成长卡点，并给过具体建议
- [ ] 我最近一次拒绝新技术的理由，是复杂度而不是「不想学」
- [ ] 我的排期里包含风险与缓冲，且明确说出「做不到的部分」
- [ ] 我留下的文档，新人能独立照着做完一件事
- [ ] 我休两周假，系统不会因为我离开而出事