在团队中，有一句话会被工程师悄悄说出来，通常是在经历过它的缺席之后：“在这里，我可以说出我真正想说的话。”听起来简单，实际上很稀有——却极为宝贵。让这一切成为可能的条件不会自己出现，而是由那些选择善意的人，一次次互动中慢慢建立起来的。
不是好好先生式的“nice”，而是真正的善意（kind）。两者的区别比初看起来重要得多，搞混了会让团队付出惨重代价。
本文是对善意工程实践意义的深入探讨——在代码审查、事故响应、反馈对话，以及我们如何对待共事之人这些日常时刻里的具体体现。这里的很多思考源于 kind.engineering，这是一个我向所有关心构建健康团队的人推荐的资源。以下的想法是我自己的综合与实践；那个网站是必读的延伸阅读。
善意（kind）不等于好好先生（nice）
把善意和好好先生混淆，是造成许多功能失调团队的根本原因之一。“好好先生”令人舒适——它抚平了尴尬时刻，维持了表面和平，感觉温暖。但它往往是空洞的。好好先生式的人会在 demo 有严重缺陷时告诉你效果很棒；会为了避免看起来批评人而批准 pull request；会在会议上同意，并在糟糕的决策推进时保持沉默。
善意则不同。善意告诉你真相，因为它在乎你。它说出难说的话，但以一种让你想要成长而不是想要躲藏的方式说。kind.engineering 的作者对此有精彩的描述：“好好先生”带来蛋糕；善意的人会去找你的经理说“这个人的工作非常出色——请把他提名为下一个 lead 候选人”。一个行动轻松不费代价，另一个需要为别人的未来付出努力和投入。
| 情境 | 不友善 | 好好先生 | 善意 |
|---|---|---|---|
| 面对有问题的 PR | “这完全是错的。” | 为了避免摩擦，不留评论就批准。 | “我觉得第 24 行有竞态条件——这是我会尝试的做法。” |
| 生产事故之后 | “谁写的这个？这是怎么通过审查的？” | 继续前进，不再提起这件事。 | 进行无责事后复盘；问“是什么让这件事发生了？”而不是“谁让这件事发生了？” |
| 对设计方案给出反馈 | “这说不通。” | “看起来不错！”——即便它有真正的问题。 | “我不确定缓存策略在我们的负载下是否能撑住——我们能过一遍预期的读取模式吗？” |
| 说“不” | “这不是我的问题。” | 对所有事说好；然后精力耗尽或交付不足。 | “这个 sprint 我接不了，但我可以在某个时间接，或者这里有个人现在可能可以帮上忙。” |
| 认可他人的工作 | 完全不承认。 | 在团队频道里给出模糊的赞美。 | 公开点名具体的贡献；向领导层为其争取可见度。 |
注意善意始终是三者中最难的那个。它要求你同时做到诚实、用心和投入。“好好先生”很廉价。善意需要付出。而不友善，无论短期效率如何，几乎总是让事情随着时间推移变得更糟。
“好好先生”优化的是你的舒适——避免说出难说之事的不适。善意优化的是他们的成长。两者经常相互对立。善意工程意味着持续地选择成长而非舒适。
为什么善意是力量倍增器
如果善意只是一种“最好拥有”——一种道德追求但不是实际杠杆——它仍然值得追求。但对高绩效团队的研究和实践经验表明，它远不止于此：它是工程产出的真正力量倍增器。
其机制通过心理安全感发挥作用——这个概念来自组织研究者 Amy Edmondson，后被 Google 的 Project Aristotle 推广。她的研究结论在多个行业的团队中得到证实：团队效能的最大预测因素，不是成员的平均智商，不是流程的精妙程度，也不是工具的质量。而是团队成员是否感到可以承担人际风险：问一个“愚蠢”的问题，承认自己不知道某件事，在还没确定之前指出一个潜在问题，或者对资深同事提出异议。
在心理安全的团队中，一个怀疑存在 bug 的初级工程师会说出来。一个不理解某个设计决策的工程师会去问，而不是花三天时间构建错误的东西。一个发现了高风险部署选择的人会在审查会议上发言，而不是希望有其他人会说。这些不是勇气的壮举，而是日常的信息流动，区分了能早期发现问题的团队和在生产环境中才发现的团队。
善意构建心理安全感。当你在回答问题时没有任何居高临下，你让那个人——以及所有旁观者——在未来更安全地提问。当你进行无责事故复盘时，你让人们在下次更安全地报告险情。当你给出诚实、关怀的反馈而接受者从中成长时，整个团队都学到了反馈是礼物而非威胁。
实际的回报很快就会积累：
- bug 更早浮现。当人们不害怕显得无能时，他们会在半成型的担忧变成真正事故之前就提出来。
- 学习加速。问题得到提问，知识得到分享，初级工程师成长更快。
- 离职率降低。人们不会离开让他们感到被尊重和被投入的团队，他们会离开让他们感到渺小的团队。
- 决策改善。多元视角真正得到表达，而不是因为房间里被最大声的声音主导而被自我审查。
善意的实践
哲学层面的讨论很有用，直到你需要在周五下午四点给一个 pull request 留评论。以下是善意工程在真正重要的时刻是什么样子的。
在代码审查中
代码审查大概是工程中善意测试频率最高的地方。做好了，它是团队拥有的最有价值的实践之一。不友善地做，它会成为一种恐惧来源，让人们回避提交工作、因为积怨而拖延审查，或者完全脱离。
几个持续改善互动氛围的原则：
- 在评论之前先理解为什么。在发表判决之前先提一个开放性问题。“我很好奇为什么这里用轮询而不是回调——是有什么我不知道的限制吗？”邀请对话。“这里应该用回调”则关闭了对话。
- 给你的细节打标签。“Nit：我会在这里用更有描述性的变量名，但完全可以不改。”这一个词告诉作者：这是可选的，我不会为此阻断，我真正重要的评论才是值得你认真关注的。
- 区分代码和人。“这个函数做了几件事”是对代码的反馈。“你总是写做太多事的函数”是对人的反馈。一个有用，另一个只是令人不快。
- 对于大量反馈，切换到同步对话。如果你对一个方案有六个主要顾虑，一堵评论墙会感觉像公开训斥。十分钟的通话更友善、更快，也更有可能真正解决问题。
你也可以查看关于如何善意地审查代码的同系列文章，深入了解这个话题。
在事故响应中
事故是团队文化的压力测试。在压力和真实后果下，每一个习惯——好的和坏的——都被放大。最善意也最有效的团队进行无责复盘：假设人们在当时的信息和工具条件下做了他们能做的，当系统失败时，需要改变的是系统——而不是个人。
这不是降低问责。而是理解同样的错误很少是孤立发生的。有人部署了错误的配置，是因为部署流程不需要第二双眼睛。有人错过了告警，是因为那天早上有四十个告警同时触发。找到一个人来指责感觉像是有了结论，但什么都修不了。无责事后复盘找到的是那个让人“踩坑”的流程漏洞——然后修复它。
在会议中
善意的工程师创造空间。他们注意到谁还没有发言，并邀请他们加入。他们不会用快速连珠炮一样的发言把安静的思考者淹没。他们总结决策，让所有人——而不仅仅是最积极发言的人——能带着同样的理解离开。他们跟进承诺，让人们的时间和言语被认真对待。
在说“不”的时候
反直觉地，早而清晰地说“不”往往比说“好”然后交付不足更善意。当你接受了自己无法完成的工作，提出请求的人会花时间等待，并围绕一个不会实现的承诺做计划。当你说“我到 15 号之前接不了这个，但这里有个人可能现在就能帮上忙”——这是有用的信息，让他们能做出真实的决策。
在粘合工作和赞助中
一些最善意的工程工作几乎是无形的：写好入职文档让下一位新人不必困惑三天的人；在规划会议上替初级工程师的想法发声、不让它被忽略的人；告诉同事的经理关于一项值得被认可的工作的人。这是赞助——主动投入在他人的成长和可见度上。成本相对较低，但会产生巨大的复利效应。
每周问自己：这个团队里有没有谁的好工作没有被看见？然后在合适的场合、向合适的人说出关于它的具体话。这是善意工程师做的最有影响力的事之一——而几乎没有人能坚持做到。
善意不意味着软弱
这是最常见的反对意见，值得直接回答。善意工程与高标准完全相容——事实上，它需要高标准。目标不是让所有人舒适；而是让诚实、建设性的参与成为可能。这是两件不同的事。
善意地坚守高标准意味着：清楚地说明标准是什么，解释为什么它重要，并帮助那个人达到它——而不只是指出他们没达到。“我不能在没有测试的情况下合并这个，因为我们的覆盖率是我们和六个月前那次事故之间的防线”是高标准而善意的。“这没有测试，这显然是不可接受的”是高标准而不友善的。你想要的结果是一样的；到达那里的路径却截然不同。
好好地不同意也是善意的。当你不同意一个决策时，清楚地说出来、附上你的理由，是一份礼物——尤其是如果你随后接受了决策。不善意的是被动的不同意：在会议上同意，然后之后破坏结果，或者因为发声感觉尴尬而沉默、任由糟糕的决策推进。
善意的工程师也会保护他们的团队。这有时意味着与利益相关者进行关于不切实际时间线的艰难对话，或者推回一个会让无法在那个场合为自己辩护的人精疲力竭的要求。这不是“好好先生”——这是真实的关怀，以一定的个人代价来实践。
如果你发现自己从不给出批评性反馈、从不在回顾中提出顾虑、总是把事情抚平——那不是善意。那是用善意作伪装的冲突回避。对方值得你的诚实。他们并不像你所担心的那么脆弱。
对自己善意
对自己不善意的工程师，往往也对他人不善意。长期过度工作、拒绝寻求帮助、随时需要表现得能力十足——这些不是美德。它们是消耗性的模式，侵蚀判断力，造成积怨，让真正的协作更难。
英雄文化——颂扬那个为了修复事故而熬了一整夜的人、单枪匹马重写了组件的人、永远在线并永远交付的人——有诱惑力但也很危险。它让英雄感到不可缺少，同时悄悄给其他所有人施加巨大压力，要求他们以同样的方式表现。它还会危险地集中知识，当那个人不在时，团队就变得脆弱。
可持续的节奏不是低志向的标志。它是让你能清晰思考、给出好反馈、在对话中真正在场、并持续好几年而不是几个月就精疲力竭地工作的条件。对自己善意的工程师——设立边界、寻求帮助、承认不确定性——往往是同事们最想共事的人。脆弱性，结果证明，会建立信任；表演坚不可摧则做不到这一点。
这也意味着早早寻求帮助，而不是拖到很晚。在卡住两小时后提出的问题，对你和对被问的人都是善意的——它提供了有用的上下文和一个可解决的问题。同样的问题在沉默挣扎了两天后提出，对所有人来说都更难。
善意如何随角色和团队规模而变化
善意工程的表现形式会因你所在的位置和组织规模而有所不同，但核心保持不变。
作为独立贡献者（IC），你的大多数善意是局部的：代码审查、结对编程、你在 Slack 中回答问题的方式、你是否把刚搞清楚的东西记录下来让下一个人不必重新摸索。这些时刻单独来看很小，积累起来却巨大。一个把上述内容视为工作一部分的团队，比不这样做的团队明显是更好的工作场所。
作为技术负责人，你对团队规范有着不成比例的影响力。你给反馈的方式成为了反馈被给出的方式。如果你用问题而不是判决，其他人也会。如果你颂扬早早提出问题的人而不是批评他们的错误，你让所有人更安全地早早提出问题。你最有价值的善意投入是设定团队互动的文化——做到这一点最快的方法是在每一次代码审查和每一次会议中以自身为榜样。
作为管理者，杠杆发生了变化。心理安全感现在包括：如果我说这个，我会失去工作吗？这是很多人真实的顾虑，需要被主动解决——通过言语、通过对冒险行为的反应、通过当人们带来坏消息时你的做法。一个对坏消息反应沮丧的管理者，训练他们的团队隐瞒坏消息。一个回应“谢谢你早早告诉我，我们一起想想这个”的管理者，训练他们的团队早早告诉他们。结果的差异是巨大的。
在大型组织中，善意的规模化往往意味着创建让善意行为成为默认选项的结构：无责事后复盘模板、工程手册中明确的代码审查规范、揭示人际关系模式的 360 度反馈流程、将一个人如何培养和支持队友纳入晋升标准——而不只是他们单独交付了什么。
核心要点
- 善意不等于好好先生：“好好先生”回避不适；善意告诉真相，因为它在乎对方的成长。
- 心理安全感是机制：当人们感到可以安全发声时，问题更早浮现，学习加速，团队表现更好。
- 善意有其实践：在审查中先问问题再作判断；进行无责复盘；清晰地说“不”；为他人争取可见度。
- 高标准与善意相容：清楚说明标准，解释为什么它重要，帮助人们达到它——不要只是指出差距。
- 对自己善意不是可选的：英雄文化是脆弱文化；可持续的节奏、寻求帮助和承认不确定性都建立善意所需的信任。
- 你的角色决定你的杠杆：IC 在日常互动中塑造规范；负责人在团队层面树立榜样；管理者通过对风险和坏消息的反应创造结构性安全。
- 延伸阅读：本文中的想法受到 kind.engineering 的启发——这是一个关于工程团队中沟通、诚实和心理安全感的深思熟虑、实用的资源。
善意会复利增长。每一次友善落地的诚实审查，每一个没有居高临下地回答的问题，每一次真正找到漏洞的无责事后复盘——每一次都是对整个团队共同依赖的信任账户的一次小小存款。随着时间推移，这个账户是区分感觉像真正好工作发生的地方的团队和不是的团队的东西。值得用心建立。
如果你想在某个特定实践上深入，本系列的下一篇文章探讨了如何写一个出色的 Pull Request的技艺——这本身也是对你的审查者的一种善意。