我是住在首尔的新西兰人。这篇写的是从内部看到的韩国开发现场，坐在招聘桌两边看到的东西，以及我想对考虑来韩国工作的人说的话。

我是怎么来的

#

入口是读研。在新西兰怀卡托大学读完本科，又在一家电信公司做了一年网络运维之后，我于 2017 年 3 月到 2019 年 2 月在庆熙大学读计算机科学硕士。实验室每学期都会去参加韩国国内的两个计算机学术会议 KSC 和 KCC。2018 年在平昌举办的 KSC，赞助商里有好几家韩国大型科技公司，还设了面向求职学生的招聘展位。如果你是在韩国读研的外国学生，这一点值得知道。

之后的经历是这样的：

工程是熟悉的那一半。在那家客服初创公司我才明白，交付软件的很大一部分其实是运维；创作者平台的后端跑在比我今天会选的多得多的技术栈上。韩国特有的差别都在边边角角。Naver 是你必须在意的搜索引擎：我给 Kiwi Alumni 上线新网站的时候，SEO 是按 Google 和 Naver 两边一起做的。韩国平台的爬虫名字你很难猜到（Naver 的爬虫叫 Yeti，KakaoTalk 的链接预览来自一个叫 kakaotalk-scrap 的东西）。还有，韩国的网上银行到现在还要你在电脑上装它们自己的安全软件。

不过这些都不是难的部分。

눈치是什么，为什么不是「optics」

#

눈치是一种感觉：不靠别人说了什么，而是从情境里察觉别人在想什么、要什么、期待什么。눈 是「眼睛」的意思。用 2019 年的《The Power of Nunchi》一书把눈치介绍给英语世界的 Euny Hong，把这个词译成「eye-measure」，也就是「用眼睛量」。它出现在不少日常说法里。说一个人「눈치가 빠르다」（눈치快），是说他很会看场合；说一个人「눈치가 없다」（没有눈치），是说他完全看不懂，这可不是夸人。而「눈치를 보다」（看눈치）是一直留意别人的反应，通常是上级的，好让自己站在不被讨厌的那一边，相当于中文的「看眼色」「看脸色」。

英语里大家这时候会拿出来的词是「optics」，我觉得用错了。optics 讲的是不管实际如何，从外面看起来怎样，比如「在裁员的同一周宣布发奖金，optics 很难看」。它关乎外表，管理它的是被看的那个人。눈치大多指向相反的方向：重点不是你在别人眼里怎么样，而是你把别人看得有多清楚。两者唯一的交点是「눈치를 보다」：观察所有人，好管理自己在他们眼里的样子。外媒写韩国职场时写到的，正是这个版本。

那些文章举的例子大同小异：不要比组长先下班，真要休年假（연차）时得看的눈치，聚餐（회식）时什么时候可以走，以及要反驳上级的话，是在会上说还是会后私下说。不管你怎么看这些例子，它们的形状是一样的：每一条都是所有人都遵守、却没人说出口的规矩。

而且这和语言是两回事。韩语在话里，눈치在话以外的一切里。

눈치在开发团队里出现在哪儿

#

开发团队靠的正是这种形状。第一次当经理几个月后，我写了一篇关于团队规范的文章，开头是这样的：我处理的摩擦大多不是技术问题，而是大家对一些事各有各的默认假设，比如代码评审该多快回、「完成」到底指什么、催第二次算不算没礼貌。那时我没用这个词，但那张清单每一行都是눈치要读的东西。每一条都是团队心照不宣的约定，新人只能靠观察学会。

同一篇里我还抱怨过，新人学规范是「当成口口相传的民间故事」，而不是在入职时被明确告知；也抱怨过跨国团队默认自己的标准就是所有人的标准。要描述눈치靠什么运转，我找到的最好的英语词就是 folklore，民间故事。如果团队里只有你一个外国人，偏离标准的就是你，而那些「故事」哪儿都没写下来。

代价最大的地方是站会。2023 年我写过自己负责的一个项目落后了，我却一直等着有人来问。三周后终于有人问了，那时已经是一场灾难。눈치好也解决不了这个问题。会看场合，你就知道哪些话没人想听；可它不会告诉你照样要说。我从中得到的习惯正好和等待相反：在别人问之前，先用文字说出来。「这件事比我预想的要久，现在估计要 8 到 10 天，不是 5 天。要砍范围，还是推迟截止日期？」

当你成了被读的那个人

#

2024 年 2 月，我开始在首尔一家软件公司带一个工程团队，눈치的方向就此反了过来。当开发的时候，是我在看场合；当了经理，我自己就是场合。我在会上说了什么、没说什么，回消息有多快，几点下班，全都成了别人可以读的东西。

我当项目负责人时写过的很多东西，当了经理之后更加适用。如果大家不敢放心地告诉你哪里出了问题，你就会是最后一个知道的人。信息捂得太久，大家是能感觉到的，你留下的沉默会被小道消息填满。会上五个人等着你回答时，「我不知道」感觉像是失败，而这恰恰是它值得说出口的原因。还有我反复想起的一句话：别人读不到你的意图，只读得到你的话。在一个靠눈치运转的团队里，他们照样会去读：读你的表情、读你跳过了什么、读你几点走。所以最好少给他们留猜的余地。

我靠的都是些不起眼的做法。和每个人做一对一，聊的是这个人而不是这个 Sprint，再问一个能解决大部分问题的朴素问题：「有没有什么需要我或者团队帮忙，好让你的工作更顺利？」

一份简短的团队规范，三到五条，写在所有人都看得到的地方，包括经理违反了规范会怎样。主动去问那些在八个人的会上永远不会开口的人，而不是等他们开口。再就是用一句坦白的「不行，原因是这样」，代替一句之后再也不会被提起的「再看看」，因为含糊的回答只是又多了一件需要察言观色的事。我入职一个月左右时，产品团队的团建是从一家咖啡馆开始的，先做了一个关于彼此价值观和团队规范的工作坊。一家公司能给눈치的回答，很少有比这更直接的：花一整个上午，把平时不说出口的东西说出来。

作为外国人被招进去

#

我没有一套针对韩国求职的打法。我有的是招聘经理那一边的经验，由此得出的建议，就是在签合同之前，先对公司用一用눈치。

我当经理招人的时候，最想招的开发者从来不在招聘网站上；而且我以前也写过，创始人更愿意招自己已经共事过的人。所以最好的入口，是任何能让别人在招你之前先看到你怎么干活的地方。小公司的实习经常会悄悄变成一份正式工作邀约。黑客松能让人看你一整个周末：2023 年，我和另外三个人组队，拿下了由 Lunit Global 主办的 Seoul Tech Impact Hackathon 冠军，做的是一个应用，用来找韩国那些没有地址的路边小吃摊。

然后是咖啡聊天。我写过，一个人在轻松的聊天里怎么表现，比一场排练过的面试更能说明和他共事是什么样子，而且这是双向的。对候选人来说，这是进去之前读懂一个团队的唯一机会。如果坐在候选人的位置，我会问：团队现在面临的最大挑战是什么？你为什么加入，又是什么让你留下来？在这里工作有什么可能会让我意外的事？最后一个问题，是在礼貌地请对方提前把눈치告诉你。如果对方在人员流动或公司方向的问题上含糊其辞，这本身就说明了很多。

如果你要招外籍开发者

#

如果你在韩国带团队，准备招一个从别的地方来的开发者，最有用的一件事就是那篇团队规范文章里的一句话：把隐性的东西变成显性的。别让他们把你的规矩当民间故事去学。第一周就告诉他们：评审一般多久回、「完成」指什么、催第二次算不算没礼貌、大家实际几点下班、休假除了填表还有没有别的讲究。最后两条是典型的눈치问题，团队里的人连想都不会想到要说。

之后就是一些让人少猜一点的无聊习惯。在别人问之前先说：周五给相关人员发一封三行的邮件（这周上线了什么、接下来做什么、有什么担心的），只要十分钟。会上别等安静的人开口，直接去问他们。给真正的答复，包括「不行」，并且附上理由。还有，用同样的问题、同样的评分标准面试每一个候选人。这一条我花了些时间才学会，但这是公平比较人的唯一办法，否则你会偏向最近聊过的那个人。这也意味着，不懂你团队潜规则的候选人，和懂的人被问到的问题一模一样。

这里的新西兰社群

#

2018 年我还是学生的时候，在 Kiwi Chamber 的一场领导力早餐会上负责拍照，事后写道，我非常喜欢为促进两国关系的活动做志愿者。2020 年 1 月起，我担任 Kiwi Alumni 的主席。这是一个面向在韩新西兰人，以及在新西兰读过书、如今在韩国生活工作的人的社群。这是志愿职位，大部分是和人打交道的工作：组织活动，和新西兰驻韩大使馆及各教育机构建立关系，还有一些不起眼的活儿，比如新 logo，比如一个会员真能找到东西的网站。2023 年我们和大使馆一起办了 Kiwi Alumni Night，还上了 KTV。

那晚之后我写下的一句话，最接近这篇文章的主旨：在韩国和新西兰都生活过的人，知道怎么在两者之间架桥，因为两种文化他们都经历过。如果你来韩国工作，不管你来自哪里，去找这样的人。他们会用大白话告诉你，那个场合到底在说什么。

在首尔做自由职业

#

辞掉经理的工作后，我在 2025 年 10 月开始做自由职业。实际做的是合同制的 DevOps 和 MLOps 工作，大多是本地部署：先搭了一个高可用 PostgreSQL 集群，然后在同一批硬件上搭 LLM 推理服务。做下来发现，质量把控比铺管道多：盯着 trace 和多轮对话，找模型输出从哪里开始跑偏。2026 年 2 月起，我还在另外做一款自己的集市加社区应用。

做自由职业并不能让你摆脱눈치，只是换了要读的对象。不管到哪个团队，我最先看的都是监控，因为它比 README 更能说明一个团队。这算是对系统用的눈치：读的不是团队说自己在做什么，而是它实际在做什么。

想对考虑来韩国的人说的话

#

1. 从一扇能让人在招你之前先看到你干活的门进来。我走的是读研这条路。黑客松、小公司的实习，或者你自己国家在这里的社群，作用都一样；而在社群里，你能找到两边都生活过的人。
2. 别把小公司排除在外，我职业生涯的大部分时间都在小公司。十个人的公司里，没人可以让你把无聊的活儿推给他，而你做的东西真的会上线。
3. 加入之前先读懂团队。用好咖啡聊天，问问在这里工作有什么会让你意外的事，对方在人员流动上含糊其辞，要当回事。
4. 别等别人来问。估算要延期、改动有风险、别人在等你做决定：先说，用文字说。
5. 把没写下来的规矩大声问出来：评审多久回、「完成」指什么、催第二次算不算没礼貌。如果没人写下来，主动提出你来写。
6. 学会你技术栈周边的那一圈。在这里，Naver 和 Kakao 的重要性，是你的 Google 习惯覆盖不到的。

工程是你来之前就能准备的那一半。눈치是你在工作中才学得会的另一半，而我知道的最快的学法，是请别人把没说出口的那部分说出来，并且自己先说。

咖啡聊天就是 30–45 分钟的非正式对话，在咖啡馆或视频通话里都行。没有白板，没有面试官团，没有陷阱题。我讲我们在做什么、为什么做，对方讲自己在做什么、接下来想要什么，聊完双方就知道值不值得继续深谈。招聘与其说是筛选问题，不如说是匹配问题，而要交换匹配所需的信息，我不知道还有什么比这更快的办法。

我为什么坚持做这件事

#

我已经不把这些聊天当成招聘了。它们就是聊天，只是每隔一阵子，其中一场会变成一次入职——有时是十八个月之后，对方的处境变了。能稳定产出好员工的管道，是靠这样的关系一点点垒起来的，不是靠职位广告。

它还解决了职位描述的老问题。JD 天生只能写得笼统。喝着咖啡，候选人可以问真正要紧的问题：头六个月做到什么算成功？我会和谁一起工作？团队眼下最棘手的技术难题是什么？听到诚实回答的人，会自己做出正确的取舍。

另外，聊天是在“演示”你的文化，而不是“描述”它。你有没有做功课、是不是真的好奇、尊不尊重对方的时间，这些比任何招聘页面都有说服力。反过来也一样——一个人在放松的对话里的样子，比排练过的面试更能告诉你和他共事是什么感觉。

咖啡聊天最见效的几个场景：接触没在找工作的人；在正式流程之前给内推热热身；以及和正在考虑职业转向的人聊聊——从 IC（个人贡献者）转管理、从创业公司去大厂，或者反过来。在人才紧张的市场里，你想要的人多半都属于其中一类。

我怎么安排一场咖啡聊天

#

第一条消息决定一切。模板化的开场白只会被删掉。先做功课，再坦白来意：

“你好 Sarah，我看了你在 QCon 上关于分布式系统的演讲，也读过你写事件溯源的博客。我们在 [公司] 扩展支付基础设施时正遇到类似的挑战。愿不愿意来一场 30 分钟的咖啡聊天？没有面试议程——只是想听听你的看法，也分享一下我们在做的事。”

这样写有效，是因为它具体、不藏目的，而且给出了价值（一次关于有趣问题的交流），而不是单方面索取时间。接下来是把麻烦留给自己：多给几个时间选项，选对方方便的地点（线上就用不需要下载的视频工具），发一封信息完整的日历邀请，别让对方猜。

聊天本身有个松散的形状就够了。开头几分钟是真诚的寒暄，说清楚为什么找对方。然后听对方讲：现在的工作、喜欢什么、烦什么、下一步想要什么——这一段你的任务主要是听。再讲你们的事：使命、团队真实的难题，包括难啃的部分，因为候选人尊重坦诚，而且对推销的味道极其敏感。最有价值的是接近尾声的开放环节：什么条件成立，对方才会考虑挪动？最后把下一步说清楚，哪怕下一步只是“保持联系”。

聊完 24 小时内发一条简短的感谢，提到对话里某个具体细节；答应过的东西——引荐也好、链接也好——尽快兑现。这段无聊的收尾，才是公司文化的现场演示。

如果你打算长期做，就用一个简单的表格记下聊过的人，隔段时间问候一下，哪怕手上没有空缺。这也不必是管理者的专利——很多最好的聊天，发生在你的工程师约自己圈子里厉害的人喝咖啡的时候。好的内推往往就是这么来的。

值得一问的问题

#

我常问的：

• “你最近做过的最有意思的问题是什么？”
• “下一份工作里，你希望有什么不一样？”
• “你喜欢怎样学习？希望怎样在职业上成长？”
• “有什么问题是你想问的、能帮你判断这里合不合适的？”

如果我坐在候选人那一侧，我会问：

• “团队现在面临的最大挑战是什么？”
• “这个职位的成功怎么衡量？”
• “晋升路径是什么样的？”
• “你当初为什么加入？为什么留下来？”
• “关于在这里工作，有什么事是会让我意外的？”

如果你是被邀请的那一方

#

搜“咖啡聊天是什么”的人，大多其实坐在我对面：有人约了他们，他们想知道自己要面对的是什么。下面是我站在发邀请这一侧，想告诉你的话。

它不是面试。没人给你打分，也没有测试，所以不用准备标准答案。但它终究是第一印象，所以把它当成见一位未来的同事，而不是朋友的朋友。和面试不同的是，你可以尽管好奇，而且对方期待你问的和答的一样多。

穿你平时在那家公司上班会穿的衣服。拿不准的话，商务休闲永远不会错。如果是视频通话，打开摄像头，找个安静的房间，这比穿哪件衬衫重要得多。

准备大约半小时就够了。看看这家公司做什么，以及对方写过或做过的东西。准备一个两分钟的版本，讲讲你现在在做什么、接下来想做什么，因为这个问题一定会来。再带上两三个自己的问题，上面那份清单就是个不错的起点。

至于聊什么：你的工作、你喜欢它哪里、你对他们的工作好奇什么。薪资先放一放，除非对方主动提起。问一句他们心里有没有具体的职位、如果有的话流程会是怎样，完全没问题。

一般是发起邀请的人买单。你可以主动提一下，但别为这个推来推去。一天之内发一条简短的感谢，提到你们真正聊过的某件事，你就已经比大多数人做得好了。

如果你自己也想约一场，那就开口。消息写短一点，说清楚为什么找的是这个人，让对方容易答应：“我一直在关注你们团队做的新搜索功能，我自己也在考虑转去做平台工程。接下来几周你有没有 30 分钟，喝杯咖啡或者打个电话？时间按你方便来。”这么具体的请求，大多数人都会答应。

把它搞砸的几种方法

#

最快的一种是把它变成暗中面试。一旦开始考察技术能力、往里塞行为面试题，那份默契就破了——这些留给正式流程。其次是用力过猛地推销：留得住的员工，都是把难处看清楚之后才加入的人。毫无准备地出现，或者聊完就消失，伤害更隐蔽——每一场聊天都在决定这个人会怎么向自己的圈子描述你的公司。

站在我这一侧，警报信号是：对什么都没有好奇心的候选人，纯粹交易感的对话，以及用同一种怨气描述每一任前雇主的人。候选人也该有自己的清单：说不清这份工作为什么重要的对接人，谈到流失率或公司方向就闪烁其词的回答，还有那种比起理解你更热衷于推销的人。

不是每场咖啡聊天都有下文，事实上大多数没有，这没关系。关键在于，下次要填一个重要岗位时，你不是从一页空白的招聘启事开始，而是从一摞真实的对话开始。发出去的应该是一句“喝杯咖啡吗”，而不是一份职位描述。

延伸阅读

#

本站相关文章：

• 开发者面试中的 STAR 方法 —— 聊天进入正式面试流程后用得上
• 刚当上工程经理，我先做这三件事 —— 团队靠什么运转，正是你在匹配的东西
• 为什么你应该去创业公司实习 —— 和考虑去创业公司的人聊天时的有用背景

外部资源：

• First Round Review：工程师招聘 —— 经验丰富的创业公司操盘手写的招聘指南
• Lara Hogan 的“第一次 1:1 该问的问题” —— 本是为 1:1 写的，用在咖啡聊天里同样好使
• Patrick McKenzie 谈薪资谈判 —— 值得一读，帮你理解候选人那一侧的处境
• Who: The A Method for Hiring —— Geoff Smart 和 Randy Street 的系统化招聘框架
• 哈佛商业评论：招聘专题 —— 有研究支撑的人才招募文章

今年开始带工程团队之后，绩效评估从“发生在我身上的事”变成了“我要负责主持的事”。写这篇文章一半是为了理清自己的思路，所以请把它当成摸索中的笔记，而不是标准答案。

到底为什么要做绩效评估

#

不管什么级别，目的归根结底就两条：让人能持续成长，让表现超出角色期望的人真正得到回报。

很多小公司说自己没时间没资源做评估，于是默默退回到只看工龄：谁待得久，谁就“该升了”。我认为这是个错误，而且不只因为工龄是个偷懒的指标。跳过评估，等于砍掉了公司和员工之间的双向沟通渠道，工作关系会因此变质。

这是双向的。工程师可能真心相信自己在用对公司最好的方式工作，但习惯、方法、沟通风格却在不知不觉中跑偏，没有反馈，就没人能发现。反过来，从不通过正式渠道听员工说话的公司，会舒舒服服地对员工的真实想法一无所知。

双方各自该带着什么期待进场

#

员工这边的清单并不复杂。他们想知道自己的工作和团队目标怎么对上，哪里做得好，哪里要改进，而且要具体，不是一句“加强沟通”。他们希望贡献被认可，希望认真聊聊职业发展和培训机会，希望整个流程公平、看工作本身而不是办公室政治。

站在我这边，我期待每个人带着自我评估来：自己觉得哪里做得好、哪里不行。我希望看到的是对反馈的开放态度，而不是辩护律师的开场陈词；希望能认真讨论未来目标，也希望听到他们对自己在团队中位置的真实感受。评估同时也是我做规划的时候：团队构成、潜在的晋升、谁需要哪种成长机会。

一套框架套不住所有工程师

#

工程团队里的人文化背景、经验、专长各不相同，同一份评估剧本不可能对每个人都有效。“一视同仁”和“公平对待”不是一回事，方式必须随个人的需要、职业阶段和贡献而调整。底线是：每位工程师的角色和职责都清晰明确，并且和薪酬真正匹配。

最容易出问题的地方是头衔和薪水。当有人对自己的职级感到模糊，或觉得自己该晋升了，含糊的鼓励就是毒药。有效的是具体：一起商定作为下一级别基准的具体挑战或项目目标，让晋升有客观标准，而不是靠感觉。薪酬同理。如果有人觉得报酬偏低，或想承担更多责任，就把可衡量的目标写进他的计划，写清楚下次评估前要做到什么才能支撑这个变化。然后到了下次评估，双方都得对着这份约定说话。

改进类的反馈也一样。针对具体短板的具体培训、工作坊或项目，有用；“继续提升技能”，没用。

基准从第一次面谈就开始定

#

和新下属的第一次评估面谈，主要就是定基线：这个角色到底包含什么、怎么支撑团队和公司目标；用哪些可衡量的结果来评判表现；近期和长期目标分别是什么。这也是聊公司文化和行为规范、反馈的频率和方式、可用的资源和导师支持、以及这个位置能看到的职业路径的好时机。没有一样是激动人心的，但做了这些，后面每一次评估都会轻松。

之后我用的议程

#

1. 闲聊。听起来不重要，但它能把房间里的紧张感卸掉，后面的对话会诚实得多。
2. 过一遍议程，谁都不会被某个话题打个措手不及。
3. 上次评估以来的成长。把进步明确说出来，人往往看不见自己的进步。
4. 当前表现，先讲优点。
5. 需要改进的地方，每一条都配上具体、现实的目标。
6. 职业规划，以及现在的工作是否真的朝着那个方向。
7. 下次评估前的目标和行动项。

KPI只有因人而设才有效

#

产品团队里工程师的KPI，必须同时贴合团队目标和个人。前端、后端、全栈的职责不同，初级和资深的差别更大。提交量也许能说明一个初级开发者的状态，但对一个主要产出是架构决策的资深工程师毫无意义。所以KPI要在对话中商定，而不是从模板里抄。

我关注的几个方面：

• 代码质量：错误率、编码规范的遵守程度、返工修bug的频率
• 项目交付：里程碑和期限的达成
• 创新与解决问题：效率改进、真正啃下来的硬问题
• 协作：代码评审、对团队目标和讨论的贡献
• 个人成长：学习目标的完成、认证、新掌握的技术
• 客户影响：用户反馈、上线功能的使用情况

在可量化这一侧，我最近对单元测试越来越感兴趣。InfoQ的这篇文章讨论了怎么把单元测试纳入绩效评估，既讲落地的机制，也讲它对团队文化的影响，主张用定性加定量的方式衡量代码健康度。如果你在找不把工程师简化成代码行数的KPI，值得一读。

不管选什么，都要在评估或1:1里一起商定，并随着角色、项目、技术的变化及时调整。没人认可过的KPI，只是一根用来敲打人的棍子。

我填的模板

#

我给每个人建一份文档，每次评估往里加一节，这样所有记录都在一个地方。骨架是这样的：

## 绩效评估：[姓名]，[周期]

**角色和职级：** [头衔，以及这个职级在本团队意味着什么]
**上次评估定下的目标：** [从上一节复制过来]

### 自评（工程师提前填写）
- 做得好的地方，举一两个例子
- 做得不好的地方，以及换作现在会怎么做
- 一年后想在做什么

### 上次目标的进展
- [目标]：达成 / 部分达成 / 未达成，附依据

### 优点（具体例子）
- [做了什么、什么时候、带来了什么改变]

### 待改进（每项配一个目标）
- [行为或技能] → [“更好”是什么样子]，截止 [日期]

### 职业发展与职级
- 对照下一个职级现在处在什么位置，还差什么

### 到下次评估前的目标
1. [可衡量的目标]
2. [可衡量的目标]

### 商定的行动项
- [谁] 在 [何时] 前 [做什么]

自评在面谈前一两天交上来，绝不在面谈时当场写。先读过它，谈话就不一样了：有一半的时候，我准备提的事工程师自己已经点出来了，面谈就可以直接用来商量怎么办。

自评问题

#

下面是我提前发出去的问题。它们故意问得很开放，这样回答告诉我的是一个人怎么看待自己的工作，而不只是做了哪些事：

• 上次评估以来，你最自豪的是什么？为什么是它？
• 你在哪里卡住过？什么能让你早点脱困？
• 队友或代码评审者给过你的哪条反馈，让你一直记着？
• 上次定的目标里，你觉得哪些达成了？哪些想放弃或调整？
• 接下来想学什么？现在的工作给了你这个机会吗？
• 作为你的经理，我哪些地方应该换个做法？

最后一个问题换来的尴尬沉默最多，换来的有用回答也最多。

具体的反馈是什么样子

#

大多数糟糕的评估反馈并不刻薄，而是含糊。区别看下面，右边是我努力去写的那种：

每一条具体的反馈都点出一件事，说明它带来了什么变化，再指向这个人接下来能做的事。这样写更费时间，所以我逼自己整个季度随手收集例子，而不是评估前一晚才拼命回想。

写下来

#

面谈结束后，写一份纪要：讨论的要点、提出的问题、行动项、双方认可的目标。听着很官僚，但正是这份书面记录，能避免六个月后那句“我们当时没这么说吧”。写下来的问题会被持续跟进而不是蒸发，行动项直接成为下次评估的开场议程，落在纸面上的目标也会被认真对待。

说到底，整个体系就这么几条：第一天就把期望讲清楚，KPI贴着人来定，凡事留记录，每个行动项都跟进到底。缺少双向对话和可衡量结果的评估就是走过场，而工程师从收到日历邀请那一刻起，就能闻出走过场的味道。

我自己很快就要走这一步了，所以最近一直在找过来人聊，能找到的书也都翻了翻。目前最清晰的一条结论是：从工程师到工程经理，不是往上走一级，而是横着跨进一份完全不同的工作。你的产出不再是代码，而是团队做出来的一切。这话人人都说，但据说人人都还是低估了它的分量。

到底变了什么

你不再亲手解决技术问题，转而去解决人的问题。日历被 1:1、计划会议和跨团队协调填满，招聘和绩效评估也落到了你桌上。工作的重心变成：确保团队拥有干活所需的东西——背景信息、清晰的优先级，以及尽可能少的干扰。

别扭的地方在于，你还得保持足够的技术水平，能在架构讨论里站得住脚、做出靠谱的技术判断，同时又要接受"写代码的人不再是我"这个事实。我见过几个两头都想抓的经理，结果多半是两头都做砸。

工程师和工程经理，放在一起看

过来人提醒得最多的，就是反馈周期这一行。当工程师时，你几乎每天都能拿到一点小小的成就感。当了经理，成就是真的，但来得很慢，你得习惯在一段时间里都不知道某个决定到底对不对。

看起来最要紧的几项能力

沟通占了大头。你成了团队、产品和管理层之间的翻译，光是确认这三拨人在聊同一件事，就能耗掉多得惊人的时间。比任何流程都管用的是信任：如果大家不敢告诉你哪里坏了，你就会是最后一个知道的人。日历是真的会把人活吞的，守住思考的时间、留给团队的时间，是一场没有尽头的仗。还有，你得明白公司到底想干成什么，否则你根本没法把团队带向一个有意义的方向。

头衔到手之前的准备

我反复听到、也能亲自作证的一条建议：在别人给你头衔之前就开始带。带一个项目，指导一个人，牵头做点什么。过去一年我一直在做项目负责人的角色，这段经历比任何一本书都管用。当然书也有用——Camille Fournier 的 “The Manager’s Path” 是人人都推荐的那本，读完确实明白为什么。技术也别放下，架构之争永远不会停。最后，找一位已经完成这个转变的导师，他们能帮你绕开那些事后看来"这也能踩？“的坑。

取舍

你对"东西怎么造"的影响力变大了，但很少再亲手去造。我猜有些日子会觉得很爽，有些日子会想写代码想得不行。过来人都说这很正常。半年后再来问我吧。

最近常想起这件事，因为我自己也开始带项目了，那种想蒙混过去的冲动是真实存在的。开会时被问到一个问题，五个人等着你的答案，这时候说"我不知道"感觉像认输。其实不是。多数时候，这恰恰是最有底气的一步棋，前提是后面跟上下一步：去问谁，或者什么时候给答复。

装懂迟早穿帮

#

软件这行变化太快，没有谁能把所有东西都装进脑子里。而工程师对装懂的嗅觉出奇地灵。只要被团队抓到一次不懂装懂，之后你说的每一句话都会被暗暗打折扣。反过来，一个承认自己有盲区、然后老老实实去补上的管理者，说出来的答案大家反而信——因为大家分得清什么是真答案。

“我不知道"是起点，不是终点

#

关键在后面那半句。说完"我不知道"就没了下文，那叫甩手。好的管理者会接着问出更好的问题——“和我们现在用的方案比怎么样？““如果这个假设错了，会坏在哪里？"——然后把问题抛给对的人。每个团队里都有那种几乎住在数据库里的人，或者把前端所有恶心的边界情况都摸透的人。你不需要什么都懂，你需要知道谁懂，并且真的去问。

职场上怎么说"我不知道"才不显得没准备

#

我给自己定的规矩是：别让"我不知道"成为一句话的结尾。下面几种说法，都是真能说出口的：

• “这个我暂时不清楚，周四之前我查清楚给你答复。”
• “这块小李比我熟，我们直接拉他问一下。”
• “我没有十足的把握，倾向于是 X，但拍板之前我想先确认一下 Y。”
• “具体数字我手上没有，会后我发到群里。”
• “这个我还没仔细研究过，不想瞎猜，明天给你准话。”

说"我不知道"算不算不礼貌？只要带着下一步，就不算。真正让人不舒服的，是一句"不清楚"之后就没了下文，或者一个信心满满、事后发现是编出来的答案。面试也是一样：不知道就直说，然后讲讲你会怎么去弄清楚。这比硬猜一个答案更能让面试官看清你。

决策质量会变好

#

软件领域的决策往往影响深远，所以值得诚实地区分"哪些我有把握，哪些是在猜”。提前承认自己的盲区，就能在拍板之前而不是之后把缺的信息补齐，也让持反对意见的人敢开口——而那恰恰是你最需要听到的声音。定了就把理由讲清楚；错了就认。没有什么比一个不肯认错的管理者更能扼杀团队的坦诚。

这些道理一点都不复杂：多问，多听比你懂的人讲（永远有人比你懂），在猜的时候承认自己在猜。“我不知道，但我们一起查查"这句话给我攒下的信用，比任何一次蒙混过关的回答都多。

没人喜欢被问"进展怎么样了？"。可作为在公司带项目的人，我又不能不知道进展。我的折中办法是Git提交图：先看图，再决定要不要问人。大多数时候，答案已经在图里了。提交活动、分支、合并一眼可见，谁也不用为此开会。

从图里到底能看出什么

#

如果你没仔细看过：图上每个节点是一次提交，每条岔开的线是一个分支，整张图就是项目的时间线。这个布局里的信息量出乎意料地大：

• 扫一眼就知道有几个活跃分支、提交频率如何。
• 突然安静下来的分支，或者几个星期没合并的分支，多半是有人卡住了。这种预警很值钱。
• 合并频率反映团队的协作方式。合并勤快，说明工作在持续集成；分支活得太久，往往意味着有人在孤军奋战。

打扰更少，对话更好

#

明面上的好处是：不打断任何人也能掌握进度。更大的好处在真需要谈的时候：谈话从图出发，而不是从猜测出发。“这个分支从周二就没动过，有什么卡住了吗？“比"有什么进展吗？“强太多了。

把节奏挑明也有帮助。我的习惯是大多数早上扫一眼，每周认真看一次。团队知道这个节奏，所以谁也不会觉得突然。

别把它变成监控

#

这一条我得反复提醒自己。提交数不等于价值——一次深思熟虑的提交可能顶五十次刷存在感的提交。能看到每次提交，不代表有资格质疑每个决定；要信任团队，只在模式真正不对劲时才介入。而且把图带进谈话时，它是反馈的起点，不是起诉的证据。

在终端里看图

#

只要装了Git就行：

git log --graph --oneline --all --decorate

各个参数的作用：

• --graph：在左侧画出分支和合并的线。
• --oneline：每个提交只占一行，显示短哈希和提交信息的第一行。
• --all：显示所有分支和标签，包括远程分支，而不只是当前所在的分支。
• --decorate：把分支名和标签名标在它们指向的提交旁边。新版Git在输出到终端时默认就会显示，但加上这个参数，用管道传给别的命令时名字也不会丢。

每天早上敲一遍这么长的命令太累，设个别名：

git config --global alias.graph "log --graph --oneline --all --decorate"
git graph

历史长的仓库，整张图怎么滚都滚不到头。几种缩小范围的办法：

git graph --since="2 weeks ago"    # 只看最近两周
git graph -20                      # 只看最近20个提交
git log --graph --oneline main..feature                # feature有、main还没有的提交
git log --graph --oneline --left-right main...feature  # 两边都显示，用 < 和 > 区分

最后两条是对比两个分支。这里用的是普通的git log而不是别名，因为别名里的--all会把其他分支全都带回来。两个点显示feature有而main没有的提交；三个点加上--left-right，会把两边各自独有的提交都列出来，一眼就能看出一个长期分支已经跑偏了多远。

在VS Code里看图

#

VS Code自带提交图。打开源代码管理视图（Ctrl+Shift+G），里面有一个Source Control Graph分区，这是1.93版（2024年8月）加入的。默认只跟踪当前分支和对应的远程分支，用图标题栏上的分支选择器可以加上别的分支。随手看一眼的话，这就够了。

想一次看全所有分支，就装mhutchie开发的Git Graph插件（在扩展视图里搜"Git Graph”）。打开方式有三种：状态栏上的Git Graph按钮、源代码管理视图顶部的Git Graph图标，或者在命令面板里运行 Git Graph: View Git Graph (git log) 。点一个提交可以看它改了哪些文件；先点一个提交，再按住Ctrl/Cmd点另一个，就能对比这两个提交。不过这个插件从2021年起就没有发过新版本，所以自带的提交图也值得会用。

如果看不到Git Graph按钮，多半是插件没找到仓库。它默认只检查你打开的那个文件夹本身，不会往子文件夹里找。直接打开仓库所在的文件夹，或者在设置里调大git-graph.maxDepthOfRepoSearch就行。

其他工具

#

大多数Git工具都能看图。gitk --all是Git自带的历史浏览器。GitHub、GitLab、Bitbucket的仓库页面都有"network"或"graph"视图。桌面客户端里，SourceTree（Atlassian出的免费工具）、GitKraken、Tower，以及Windows上的TortoiseGit，也都能画提交图。

选哪个都行，目的只有一个：看懂进度，而不是数提交。