软技能系列第 4 章。技术沟通难，不是难在「说不清楚」，是难在立场冲突时还能把事往前推：评审会上方案被否、产品要一个技术上很蠢的需求、同事坚持一个你认为有问题的设计。这章讲冲突场景下的沟通方法。
争论三原则：把「对人」转回「对事」
- 先复述对方观点，再表达自己：「你是说先上线看数据再决定，对吧？」——被准确复述的人，防御会降一半。这条在情绪升温时最有效。
- 分歧要落到「可验证的点」：争论「微服务好不好」永远吵不完；争论「按我们的流量，拆了之后独立扩缩容能不能省 30% 成本、怎么验证」才有结果——把分歧翻译成可以验证的问题，是技术争论最值钱的一步。
- 可以认输，但要认在事实上：「你这个数据我没想到，我收回刚才的判断」不丢人，反而加分；嘴硬到底才丢人。技术沟通里没有赢家，只有更接近事实的一方。
需求博弈四步：产品要 A，你说该做 B
- 第一步：确认目标，不接任务书就动手。先问「这个需求要解决什么业务问题」，把讨论从「做什么功能」拉到「解决什么问题」。
- 第二步：给出代价，不替对方做决定。别只说「这样不好」，给出你的估算：「按 A 方案做，改动涉及 3 个模块，要 2 周且风险高；按 B 方案，1 周能覆盖 80% 的需求」——把决策权还给对方，用代价说话。
- 第三步：提供替代，不空手拒绝。每次说「不要做 X」都带上「可以做 Y 或 Z」，空手拒绝只会把关系做僵。
- 第四步：达成共识要留痕。结论写进需求文档/IM 记录，避免「当时说好的」变成「我没说过」。
心法：需求博弈的目标不是「我赢」，是「业务目标被最合理地实现」。当你和产品都在为同一个业务目标说话时，博弈就变成了合作。
拒绝不合理需求：Say No 的三个姿势
- 拒绝的是「方式」，不是「目标」：「这个功能要支持，但用这种实现方式会有 XX 代价，我建议换一种」——先接住目标，再否掉方案。
- 拒绝要带「下一步」：不做 A，那 A 背后的诉求怎么满足？给出替代路径，你的拒绝才有建设性。
- 红线要提前亮：会影响线上稳定性、数据安全、合规的需求，不是「可以商量」的，是「必须拦」的——这类拒绝不需要委婉，但需要把理由讲透、留记录。
落地清单
- 争论前先复述对方观点
- 分歧翻译成可验证的问题
- 需求博弈：确认目标 → 给代价 → 给替代 → 留痕
- 拒绝带替代方案，先接目标再否方式
- 红线需求提前亮明并记录