你在code review里写了一条评论：”这个设计不好，应该用策略模式。”

同事秒回：”这样更简单，不需要过度设计。”

你盯着屏幕，血压升高了20个点。明明是你对，他怎么就听不进去呢？

先别急着给同事贴”不接受反馈”的标签。真相可能让你不太舒服——问题不在你说的内容，而在你说的方式。

你以为有理就够了？大脑不这么认为

程序员骨子里有个信念：逻辑正确 = 应该被接受。

这个信念在编译器面前完全成立。代码对就是对，错就是错，编译器不会因为你态度好就放过一个语法错误。

但人不是编译器。

神经科学有个概念叫”杏仁核劫持”——当大脑检测到威胁信号时，负责情绪的杏仁核会抢在理性思考之前做出反应。而”你这个设计不好”这句话，对写代码的人来说就是一个威胁信号。

不是因为他玻璃心。是因为他花了三个小时写的代码，在他大脑里已经跟”我的能力”绑定在一起了。你否定代码，他的杏仁核自动翻译成”你在否定我”。

所以你的评论在逻辑上可能100分，但在情绪接收度上只有20分。80%的信息量被防御机制吃掉了。

Google花了几百万发现的秘密

Google有个著名的研究项目叫Project Aristotle，花了好几年时间研究一个问题：什么让团队变得高效？

他们一开始以为答案是”把最聪明的人放在一起”。毕竟这是Google，不缺聪明人。

结果发现，智商、经验、技术水平，这些全都不是最关键的因素。

排名第一的是一个听起来很”软”的东西：心理安全感。

说白了就是——团队成员是不是觉得”说错了也不会被嘲笑，提出不同意见也不会被穿小鞋”。

这跟code review有什么关系？关系大了。

你写的每一条review评论，都在往两个方向推：要么让同事觉得”这个人在帮我”，要么让他觉得”这个人在审判我”。前者建设心理安全感，后者摧毁它。

当心理安全感被摧毁，就算你的意见再正确，对方的第一反应也是防御，而不是思考。

你赢了逻辑，输了影响力。

你的review评论，是手术刀还是板砖

到这里你可能会说：那我总不能为了照顾情绪就不提问题吧？

当然不是。问题该提，但提问题也有段位。

我给你讲个事。去年体检完，医生跟我说检查结果。他是这么开口的：”你的B超显示有轻度脂肪肝，这个挺常见的，调整一下饮食加上每周动一动，通常三个月就能改善。”

我当时的反应是：”好的好的，回去就少喝奶茶。”

后来我在网上看到有人吐槽自己的医生：”你的生活方式太差了，所以得了脂肪肝。”——同样的检查结果，但这位患者的反应是什么？”这人凭什么judge我的生活？”

区别就三个字：你说的是事实，还是判决。

“你太差了”是判决。”B超显示有脂肪肝”是事实。判决让人炸毛，事实让人思考。

拉回到代码世界——

“这个代码写得不好”——判决。对方的杏仁核瞬间上线，翻译结果：”你在说我不行。”

“这里在循环内做了数据库查询，数据量大时可能超时”——事实+后果。对方的前额叶皮层接管，翻译结果：”哦，这里确实有个风险点。”

同一个技术观点，手术刀和板砖的区别，就在于你是在描述还是在审判。

Review评论的两种打开方式

SBI模型：程序员的反馈公式

说了半天，到底怎么操作？这里有个叫SBI的模型，简单到可以当模板用。

S — Situation（场景） 定位到具体的代码位置，别笼统地说”你的代码有问题”。

❌ “你的代码质量需要提高” ✅ “在这个 processOrders 函数里”

B — Behavior（行为/事实） 描述你观察到的具体事实，不加评判。

❌ “这个设计不好” ✅ “目前是在 for 循环内每次都调用了 db.query()”

I — Impact（影响） 说明这个事实会带来什么具体后果。

❌ “这样不行” ✅ “当订单数超过1万条时，这里会产生1万次数据库查询，响应时间可能从200ms飙到30秒”

最后，加一句 offer：“可以考虑改成批量查询，需要的话我帮你看看。”

这句话的魔力在于——它把你从”审判者”变成了”同盟者”。你不是在挑毛病，你是在一起解决问题。

来看一个完整的对比：

改之前：

这个设计不好，应该用策略模式。

改之后：

在这个支付处理的 switch-case 里（S），目前每加一种支付方式都要改这个函数（B），后面如果要加微信支付、Apple Pay，这个函数会膨胀到很难维护（I）。可以考虑用策略模式把每种支付方式拆出去，需要的话我们一起pair看看？

第一种说法，对方听到的是三个字：”你不行。”

第二种说法，对方听到的是：”这里有个具体的风险，我有个建议，要不要一起搞？”

SBI反馈公式

会了SBI，还有几个地方容易翻车

SBI是武器，但拿武器的姿势不对也会伤到自己。

别在评论区写小作文。 我见过有人一条review评论写三百字，引经据典，从设计模式讲到SOLID原则，恨不得附上参考文献列表。兄弟，这是review，不是论文答辩。对方一看这么长，第一反应是——明天再说吧。三句话解决的事，别用三段话。事实、影响、建议，完事。要深聊，拉个会。

别一口气提15条意见。 你打开一个PR，看到15条红色评论是什么感受？跟收到一叠账单差不多。就算每条都对，15条堆在一起的效果就是让人想关掉浏览器。先挑最要命的3条，等改完再提下一批。你又不是只能review一次。

别用反问句。 “这里为什么不用缓存？”“你没考虑并发吗？”——你觉得你在提问，对方觉得你在质问。反问句自带一层”你怎么连这都不知道”的buff。换成”这里加个缓存可能会有帮助，你觉得呢”，同样的信息，杀伤力降了一个数量级。

回到开头那条评论

还记得文章开头那个场景吗？你写”这个设计不好，应该用策略模式”，同事回”不需要过度设计”，你觉得他不听劝。

现在你知道问题出在哪了。那条评论是板砖，不是手术刀。

试试用SBI重写：定位到具体的switch-case，描述每加一种支付方式都要改同一个函数的事实，说明后续维护成本会越来越高的影响，最后加一句”需要的话一起pair看看”。

同样的技术观点，但你的同事这次大概率不会说”过度设计”，而是”有道理，一起看看”。

反馈从来不是说正确的话。是用对方能接受的方式，说正确的话。

反馈的艺术

你review里写的每条评论，都是一次选择——做审判者，还是做同盟者。技术能力决定你能发现多少问题，反馈方式决定你能解决多少问题。

发现问题不难，难的是让问题真正被解决。