培养下一代：工程师的 Mentorship 艺术

那个让我困惑的 1:1

四年前，我成为 Tech Lead 后的第一个月，和我的 mentor 有一场对话。

我说：「我每天花 4 小时写代码，产出很高。但团队其他人进度慢，我要不断帮他们 debug。我是不是应该减少自己的编码时间？」

他反问：「你一个人写代码快，还是 5 个人都写得快更重要？」

我愣住了。

他又问：「如果你不在，团队能正常运转吗？如果你休假两周，项目还能推进吗？」

那一刻我意识到：我的价值不在于我写了多少代码，而在于我培养了多少能独立解决问题的人。

这就是 mentorship 的本质——不是让自己变得不可或缺，而是让自己变得可替代。

为什么要做 Mentor

从个人角度

1. 强制学习的最佳方式

「如果你不能简单地解释它，你就还没有真正理解它。」—— 费曼

教别人是最高效的学习。当你需要向一个新人解释「为什么这样设计」时，你会被迫理清自己模糊的认知。

2. 影响力的放大器

影响方式	范围	持续时间
自己写代码	1x	代码存活期
code review	10x	项目周期
设计系统	100x	系统生命周期
培养人	1000x	整个职业生涯

你培养的人，会带着你的思维方式去影响更多的人。

3. 领导力的试金石

Mentorship 是低风险、高反馈的领导力训练。你可以在相对安全的环境中练习：

• 如何激励他人
• 如何给予反馈 n- 如何处理冲突
• 如何建立信任

从团队角度

1. 知识传承

没有 mentorship，知识只存在于少数人的大脑中。当他们离开，知识就消失了。

2. 文化传递

价值观不是写在墙上的，是通过每一次对话、每一个决定传递的。

3. 梯队建设

健康的团队应该像一支球队——有老将、有中生代、有新秀。Mentorship 让梯队自然形成。

Mentorship 的三种模式

模式一：问题导向（Problem-based）

场景： mentee 遇到具体问题，寻求帮助。

典型对话：

Mentee: "这个 bug 我 debug 了两天，找不到原因。"
Mentor: "给我看看你的思路。你排除了哪些可能性？"

关键点：

• 不直接给答案，而是引导思考
• 帮助建立 debug 的系统方法
• 总结可复用的经验

适用：技术问题、具体实现困难

模式二：成长导向（Growth-based）

场景：定期 1:1，讨论职业发展和技能提升。

典型对话：

Mentor: "过去一个月你觉得自己在哪方面成长最多？"
Mentee: "可能是分布式系统的设计能力。"
Mentor: "接下来你想重点提升什么？"

关键点：

• 聚焦长期成长，而非短期任务
• 帮助识别优势和短板
• 制定可执行的提升计划

适用：职业迷茫期、准备晋升、技能转型

模式三：项目导向（Project-based）

场景：在一个具体项目中，mentor 作为技术负责人，mentee 作为执行者。

典型对话：

Mentor: "这个项目你需要独立完成 API 设计。我的角色是 reviewer，不是 implementer。"
Mentee: "如果我遇到困难怎么办？"
Mentor: "先尝试解决，卡住 2 小时以上再来找我。"

关键点：

• 给明确的责任边界
• 允许犯错，控制犯错成本
• 事后复盘，提取经验

适用：大型项目、新人 onboarding、架构实践

建立有效的 Mentor 关系

第一步：设定期望

第一次 1:1 的必谈话题：

## Mentorship 契约

### 目标（Goals）
- Mentee 的目标：未来 6 个月想达成什么？
- Mentor 的目标：能投入多少时间？希望 mentee 达到什么状态？

### 时间（Time）
- 频率：每周/每两周 1:1
- 时长：30-60 分钟
- 紧急联系方式：何时可以打扰？

### 范围（Scope）
- 技术问题：可以问什么级别的问题？
- 非技术问题：职业发展、人际关系、工作压力？
- 边界：什么是 mentor 不会帮助的？

### 评估（Evaluation）
- 如何衡量 mentorship 的成功？
- 何时结束正式 mentor 关系？

关键：书面化期望，避免后期失望。

第二步：建立信任

信任建立的四要素：

要素	Mentor 的行动	示例
能力（Competence）	展示专业能力	在关键时刻提供有价值的建议
善意（Benevolence）	真心为对方着想	为 mentee 争取机会，挡掉不合理需求
诚信（Integrity）	言行一致	承诺的 1:1 从不取消
脆弱（Vulnerability）	展示自己的不完美	分享自己曾经的失败和教训

最快的信任建立方式：分享你的失败。

「我三年前犯过同样的错误，当时我以为…，结果…，我学到了…」

第三步：诊断现状

新人能力评估框架：

技术能力                    软技能
├── 编码能力                ├── 沟通能力
├── 系统设计                ├── 协作能力
├── 调试能力                ├── 学习能力
└── 工具使用                └── 问题解决能力

每个维度：1-5 分
1 = 需要手把手教
3 = 能独立完成标准任务
5 = 能指导他人

常见误区：只看技术能力，忽视软技能。很多 junior 工程师的技术问题，根源在沟通或学习方法。

第四步：制定计划

IDP（Individual Development Plan）模板：

## 个人发展计划

### 当前状态
- 优势：代码质量高，逻辑思维强
- 短板：系统设计经验不足，沟通时容易陷入细节

### 6 个月目标
- 能独立设计中等复杂度的系统
- 能在会议上清晰表达技术方案

### 行动计划
| 行动 | 资源 | 时间 | 衡量标准 |
|------|------|------|----------|
| 完成系统设计课程 | 内部培训资源 | Q1 | 通过课程项目 |
| 主导一个小型项目 | Mentor 提供项目机会 | Q1-Q2 | 成功上线 |
| 每月做一次技术分享 | 团队分享会 | 持续 | 获得正面反馈 |
| 参加 Toastmasters | 公司报销 | 持续 | 完成 3 次演讲 |

### 支持需求
- Mentor 每月 review 项目设计文档
- Mentor 在技术分享前做预演听众
- 推荐参与跨团队项目的机会

有效的 Mentorship 技巧

技巧一：苏格拉底式提问

不要给答案，要引导思考。

直接给答案	苏格拉底式提问
”这个问题可以用缓存解决。"	"如果数据库挂了，系统会怎么样？"
"你应该用策略模式。"	"如果明天要支持第三种支付方式，现在的代码需要改多少？"
"这个方案性能不好。"	"这个 API 的 QPS 是多少？瓶颈可能在哪里？”

好处：

• Mentee 自己得出的结论，印象更深
• 培养独立思考能力
• 避免 mentor 成为「拐杖」

技巧二：情景模拟

在安全环境中练习困难场景。

Mentor: "假设明天的会议上，产品经理要求你一周完成一个原本需要三周的功能。你怎么回应？"

Mentee: "我会说时间不够。"

Mentor: "好，他反问你『为什么需要这么久？』"

Mentee: "呃...我会说有很多技术细节..."

Mentor: "他打断你，说『我觉得很简单啊，不就是一个按钮吗？』"

...

适用场景：

• 艰难的对话（绩效反馈、需求 push back）
• 高压决策
• 冲突处理

技巧三：影子学习（Shadowing）

让 mentee 观察 mentor 如何处理实际工作。

实施方式：

• Mentor 处理复杂问题时，带 mentee 一起
• 实时讲解思考过程
• 事后让 mentee 复盘「我会怎么做，有什么不同」

关键：不只展示「怎么做」，更要展示「为什么」。

技巧四：反向导师（Reverse Mentoring）

Mentor 向 mentee 学习。

示例：

• 年轻工程师教资深工程师使用新的开发工具
• 新人分享他们在学校学到的新技术
• 跨代际的知识交流

好处：

• 打破层级感，建立平等关系
• Mentor 保持学习心态
• Mentee 获得自信

技巧五：失败复盘

专门花时间讨论失败，而不是只庆祝成功。

复盘模板：

## 失败复盘

### 发生了什么
[客观描述事件]

### 我的预期 vs 实际
- 预期：...
- 实际：...

### 关键决策点
1. [决策1] - 当时的选择：[A] - 如果选择 [B] 会怎样？
2. [决策2] - ...

### 学到了什么
1. ...
2. ...

### 下次会怎么做
...

常见的 Mentorship 陷阱

陷阱一：微观管理

症状：

• 每天检查进度
• 代码还没写完就开始 review
• 不给试错空间

后果：Mentee 变得依赖，不敢独立决策。

解药：

• 设定清晰的目标，而非规定方法
• 关注结果，而非过程细节
• 允许可控的失败

陷阱二：过度保护

症状：

• 不让 mentee 接触复杂任务
• 遇到困难立刻出手相救
• 不让他们参与困难的会议

后果：Mentee 成长缓慢，缺乏实战经验。

解药：

• 「Stretch assignment」——给有挑战的任务
• 在旁支持，但不代替解决
• 事后复盘，而非事前阻止

陷阱三：投射偏见

症状：

• 「我当年是这样学的，你也应该这样」
• 把自己的职业规划强加给 mentee
• 忽视 mentee 的独特优势和兴趣

后果：Mentee 失去自我，成为 mentor 的复制品。

解药：

• 了解 mentee 的目标，而非假设
• 尊重不同的学习风格
• 帮助 mentee 成为更好的自己，而非第二个你

陷阱四：忽视软技能

症状：

• 只关注技术能力提升
• 不讨论沟通、协作、时间管理
• 忽视职业倦怠信号

后果：技术强但无法协作，或早早 burnout。

解药：

• 1:1 中主动询问非技术话题
• 分享软技能的重要性
• 推荐相关资源（书籍、培训）

陷阱五：期待线性成长

症状：

• 期待每个月都有明显进步
• 对停滞期感到焦虑
• 过早放弃或过度施压

现实：成长是非线性的，有平台期，也有顿悟期。

解药：

• 拉长评估周期（看季度，而非周）
• 关注努力过程，而非只看结果
• 接受平台期是积累的必要阶段

不同阶段的 Mentorship 重点

应届毕业生（0-1 年）

核心需求：建立基础，融入团队

Mentor 重点：

• 帮助熟悉技术栈和工具链
• 建立良好的编码习惯
• 理解业务上下文
• 建立自信

典型任务：

• 结对编程
• 代码 review 反馈
• 帮助理解项目历史（为什么做成这样）

初中级工程师（1-3 年）

核心需求：提升独立能力，寻找专长

Mentor 重点：

• 培养独立解决问题的能力
• 帮助识别技术兴趣方向
• 提升系统设计能力
• 建立技术影响力

典型任务：

• 主导小型项目
• 技术分享准备
• 跨团队协作

高级工程师（3-5 年）

核心需求：从执行到影响，从个人到团队

Mentor 重点：

• 提升架构设计能力
• 培养 mentee 成为 mentor
• 推动技术决策
• 建立行业影响力

典型任务：

• 主导大型项目
• 技术布道（对内和对外）
• 参与招聘和面试

Staff+ 工程师（5 年+）

核心需求：影响组织，定义方向

Mentor 重点：

• 战略思维
• 跨团队协调
• 组织影响力
• 培养下一代领导者

典型任务：

• 技术战略制定
• 组织架构设计
• 文化建设

Mentorship 的成果评估

Mentee 成长指标

技术能力：

• 独立完成任务的比例
• 代码 review 中需要 major changes 的频率
• 解决复杂问题的能力

软技能：

• 沟通表达的清晰度
• 协作中的反馈
• 学习和适应能力

影响力：

• 开始帮助其他同事
• 主动承担额外责任
• 技术分享的频率和质量

Mentorship 关系质量

• Mentee 是否愿意分享脆弱（承认不懂、讨论失败）
• Mentee 是否开始主动寻求反馈
• Mentee 是否开始 mentor 其他人

Mentor 的收获

• 教学相长的新视角
• 领导力的实际锻炼
• 团队影响力的提升
• 职业满足感

建立团队的 Mentorship 文化

组织层面

1. 正式的 Mentor 配对

• 新人在入职时分配 buddy（前 3 个月）
• 6 个月后分配长期 mentor
• 允许 mentee 选择或更换 mentor

2. 奖励 Mentor

• 在绩效评估中认可 mentorship 贡献
• 提供 mentorship 培训
• 为优秀 mentor 提供成长机会（如培训预算、会议演讲）

3. 建立知识库

• 鼓励 mentor 写 onboarding 文档
• 录制技术分享视频
• 建立 FAQ 和 playbook

个人层面

1. 成为主动的学习者

如果你是被 mentor 的人：

• 带着具体问题来
• 主动更新进展
• 感谢 mentor 的时间

2. 成为可教的 mentor

如果你在做 mentor：

• 保持学习心态
• 承认自己的局限
• 从 mentee 那里学习

3. 扩散影响

• Mentee 成为 mentor，形成 chain
• 分享 mentorship 经验
• 建立学习小组

结语

Mentorship 是一项长期投资。你今天投入的时间，可能不会立即看到回报。但三年后，当你看到你培养的人独立主导项目、指导新人、推动技术决策时，那种成就感远超任何个人技术成就。

最好的 mentor，最终让自己变得不再必要。

当你培养的工程师对你说「谢谢你，但现在我可以自己处理这个了」，这是 mentorship 成功的最高标志。

“We make a living by what we get, but we make a life by what we give.” — Winston Churchill

开始你的 mentorship 旅程吧。找一个你可以帮助的人，也找一个可以帮助你的人。

---

给不同阶段 Mentor 的建议

第一次做 Mentor：

• 从一对一的 1:1 开始
• 专注于倾听多于讲述
• 不要害怕说「我不知道」

有经验的 Mentor：

• 尝试同时 mentor 多个人
• 建立系统化的培养流程
• 培养你的 mentee 成为 mentor

想做但没时间：

• 从每周 30 分钟开始
• 结合工作（如 code review 时多解释 why）
• 写文档，一次投入，多人受益

---

推荐阅读

书籍：

• 《The Manager’s Path》Camille Fournier
• 《An Elegant Puzzle》Will Larson
• 《Radical Candor》Kim Scott
• 《The Mentoring Manual》Julie Starr

文章：

• On Being a Mentor by Camille Fournier
• Mentoring Engineers by Kate Heddleston
• The Art of Mentoring by The Pragmatic Engineer

---

你有没有 mentor 过别人？或者被 mentor 的经历？最大的收获是什么？

本文是我过去五年 mentor 20+ 工程师的总结。感谢每一位 mentee，你们的问题和挑战让我成为更好的工程师和 leader。