Code Review时你写过"这段代码写得有问题"吗？事故复盘会上你说过"这是你们组的锅"吗？跨组沟通时你心里想过"这人怎么这么不配合"？如果答案是"有"，那《非暴力沟通》这本书可能是你今年最需要的书。
为什么技术团队特别需要非暴力沟通？
马歇尔·卢森堡在《非暴力沟通》中揭示了人类冲突的根源：
大多数冲突不是因为"信息错误"，而是因为"沟通方式"触发了对方的防御反应。
技术团队的沟通环境有几个特殊挑战：
- 对错思维根深蒂固——代码要么能跑要么不能跑，bug要么修了要么没修，这种二元思维很容易迁移到人际沟通中
- 线上压力导致情绪化——P0事故、deadline逼近时，人的沟通质量急剧下降
- 书面沟通占比高——IM、邮件、PR评论中缺少语气和表情，极易被误读
非暴力沟通的核心：四步法（OFNR）
| 步骤 | 英文 | 含义 | 技术团队中的理解 |
|---|---|---|---|
| O | Observation | 观察 | 客观描述事实，不加评判和推测 |
| F | Feeling | 感受 | 表达自己的真实感受，而非指责 |
| N | Need | 需要 | 说明自己的需求和关注点 |
| R | Request | 请求 | 提出具体、可执行的请求 |
第一步：观察 vs 评判
这是最关键的一步，也是最难的一步。
| 评判（暴力沟通） | 观察（非暴力沟通） |
|---|---|
| "你这代码写得太乱了" | "这个函数有150行，包含了3个不同业务的逻辑分支" |
| "你总是不回复消息" | "昨天下午3点发的消息到今天上午还没有收到回复" |
| "你们组的接口太慢了" | "调用XX接口的平均响应时间是2.3秒，P99是8秒" |
| "你从来不写文档" | "最近3个上线的功能都没有对应的接口文档" |
区分标准：评判带有主观定性词（太、总是、从来不），观察只有客观可验证的事实。
第二步：感受 vs 想法
| 想法（伪装成感受） | 真正的感受 |
|---|---|
| "我觉得你不重视这个项目" | "我对项目进度感到焦虑" |
| "我觉得你在敷衍我" | "我没有被理解的感觉" |
| "我觉得你能力不行" | "我对代码质量感到担忧" |
关键词：感受通常用"焦虑/担心/沮丧/困惑/无力"等情绪词；想法通常用"觉得你XX/认为你XX"。
第三步：需要 vs 策略
| 直接跳到策略 | 先表达需要 |
|---|---|
| "你必须今晚把这个bug修了" | "我需要确保明天上线前这个问题被解决，因为……" |
| "以后每次发版前必须跑一遍回归测试" | "我需要保证发版质量，减少线上事故，因为……" |
| "你能不能认真点" | "我需要准确的排期评估，因为这影响下游5个团队的计划" |
为什么要先说需要？ 因为当对方理解了"为什么"之后，他更愿意主动配合你提出的策略，甚至可能提出更好的方案。
第四步：请求 vs 命令
| 命令 | 请求 |
|---|---|
| "你必须今天改完" | "你能在今天下班前完成修改吗？如果时间不够，我们可以讨论一下优先级" |
| "以后不要这么写了" | "下次遇到类似场景，可以尝试用XX方式实现，你觉得怎么样？" |
| "把文档补上" | "能不能在周三之前补充一下接口文档？如果需要模板我可以发你一个" |
区分标准：命令不接受"不"作为回答；请求允许对方说"不"，并愿意协商替代方案。
四步法在技术场景中的实战
场景一：Code Review
暴力版：
❌ "这段代码有性能问题，你为什么不用缓存？而且命名也不规范，变量名完全看不懂。"
非暴力版：
✅ "我注意到这个查询在循环中执行了N次（观察），让我对接口性能有些担忧（感受）。我希望关键路径的响应时间能控制在200ms以内（需要）。你觉得把这部分改成批量查询是否可行？或者你有其他优化方案吗？（请求）"
场景二：事故复盘
暴力版：
❌ "这个问题很明显是你们组上线前没有做压测。每次都是这样，从来不提前验证。"
非暴力版：
✅ "我观察到这次事故中，容量评估环节缺失了（观察）。看到线上用户受到影响，我感到很遗憾（感受）。我们需要确保类似的上线操作有充分的验证流程（需要）。我建议我们针对这类变更制定一个标准的上线checklist，你觉得这个方向可以吗？（请求）"
场景三：跨组协作
暴力版：
❌ "你们排期排不上也不能一直拖着啊，我们的功能等着依赖你们的接口呢。"
非暴力版：
✅ "我了解到你们目前排期比较满（观察），但我对我们功能上线时间感到有压力（感受），因为下游的发布计划已经确定了（需要）。如果本周排期确实有困难，我们可以先用Mock数据联调，下个迭代再对接正式接口，你觉得这个临时方案可行吗？（请求）"
自我沟通：先搞定自己再搞定别人
《非暴力沟通》有一个常被忽略的章节——对自己也要非暴力沟通。
程序员最容易对自己进行的"暴力对话"：
| 暴力自我对话 | 非暴力自我对话 |
|---|---|
| "我怎么这么蠢，这种低级bug都能犯" | "我犯了一个低级错误（观察），我感到很沮丧（感受），因为我希望自己的代码质量是可靠的（需要），我需要建立一个更好的自测流程来避免类似问题（请求）" |
| "我面试又挂了，我肯定不行" | "这次面试在XX环节表现不理想（观察），我感到失落（感受），因为我希望能拿到这个机会（需要），我需要针对这个环节做更多练习（请求）" |
核心转变：从"评判自己"变成"理解自己的需求"。 这不是自我安慰，而是让自己从情绪中快速恢复，聚焦到可执行的行动上。
日常练习：21天非暴力沟通打卡
第一周：觉察——每天记录3次你在沟通中使用了"评判"而非"观察"的时刻
第二周：转换——尝试把记录的"评判"改写为"观察"
第三周：四步法——至少每天在一个正式沟通中完整使用OFNR四步法
一页纸总结
非暴力沟通四步法 = 观察(O) → 感受(F) → 需要(N) → 请求(R)
观察 vs 评判 = 客观事实 vs 主观定性
感受 vs 想法 = 情绪词 vs "觉得你XX"
请求 vs 命令 = 允许对方说"不" vs 不接受拒绝
对自己也要非暴力沟通 = 从评判自己变成理解自己的需求
