评审冲突实战场景

• 能否用事实与影响说服强势的资深同事
• 能否给出"先沟通、再升级"的路径
• 能否在升级中保持专业、对事不对人

面对资深同事的强势拒绝，先"用事实而非对抗"推进。第一步：把"明显设计问题"量化为"具体影响"——这个设计在什么场景下会造成什么问题（性能、维护、扩展、bug），用事实和复现支撑，说"我不是质疑你的判断，而是想确认这个场景下会不会有问题"。第二步：如果对方仍拒绝，提议"小范围验证"或"请架构师/第三方一起看"，把"你我对立"变成"共同验证"。第三步：若仍无法解决且是严重问题，升级路径为"先和对方 line 对齐 → 再和架构师/组长 → 最后到 leader 或仲裁"。话术要点："对事不对人、用事实说话、请求共同验证、说明升级是出于质量考虑而非针对你"。核心是"先事实沟通、再共同验证、走清晰升级路径，全程对事不对人"。

强势拒绝时先脱敏成"事实+影响"，用共同验证化解对抗，走清晰升级路径。话术关键是对事不对人、说明升级出于质量而非针对。升级要有理有据。

• 能否界定"本次改动"与"重构"的边界
• 能否论证"边界清晰"的价值
• 能否设计"边界对齐"的沟通

被要求做超出范围的大重构，第一步是"先把边界说清楚"。做法：把"本次改动要解决什么、交付什么"写清楚（需求、验收标准、涉及范围），与"大重构（额外优化）"区分开，用文档/PR 描述对齐"本次边界"。然后论证：超出范围的重构会引入高风险、难 review、延期，应"单独成任务"而非塞进本次 PR。达成一致的方法：一是"列出本次范围与重构项"的清单，让 reviewer 看到哪些是本次、哪些是建议单独做；二是"把重构单独立 ticket/PR"——承认重构有价值，但应独立评估排期，不阻塞本次上线；三是"和 reviewer 对齐目标"——如果 reviewer 认为重构是本次的必要前提，就讨论"必要性"，否则推迟。核心是"用文档明确本次边界、把重构单独立项、和对齐必要性，达成'本次不塞重构'的共识"。

大重构超出本次范围，先明确边界（本次 vs 重构），把重构单独立项，论证风险与延期。达成"本次聚焦、重构单列"的一致。

• 能否用具体攻击场景把"不会有人攻击"变成"风险可见"
• 能否论证"安全漏洞"的潜在代价
• 能否给出低成本修复方案

对方认为"不会有人攻击"，是因为"风险是抽象的"。推动修复的关键是"把风险具体化、可复现"。做法：一是"演示攻击路径"——用实际案例/复现说明这个漏洞如何被利用（如构造一个输入触发注入、窃取数据），让对方看到"攻击不是不可能"；二是"量化代价"——说明一旦被攻击的后果（数据泄露、账号被盗、合规罚款、声誉损失），把"风险"变成"代价"；三是"低成本修复"——说明修复这个漏洞的标准方案成本很低（参数化查询、加 HttpOnly 等），不修复的成本远高于修复；四是"引用规范/案例"——参考行业安全规范和真实漏洞案例，说明"没人攻击"是侥幸。核心是"用可复现攻击、量化代价、低成本修复、行业案例，把'不会有人攻击'变成'风险真实且代价高'"。

安全漏洞不能靠"不会有人攻击"侥幸，用可复现攻击、量化代价、低成本修复、行业案例推动。让抽象风险具象化、可感知。

• 能否理解"被否决"的评审反馈
• 能否用数据与证据重新论证
• 能否保持开放、接受合理部分

方案被资深同事否决，不要急于辩解，先"理解否决点"——他否决是反对"方案本身"还是"方案的某个方面"？然后"用数据与证据重新论证"：收集你的方案的数据（性能测试、成本、用户场景、权衡），用事实回应否决点，而不是"我觉得对"。做法：一是"重构论证"——把方案的核心论据用数据/场景/对比表呈现，让否决者看到"我没考虑到的维度"；二是"承认合理部分"——如果否决有道理，主动吸收那部分，调整方案，体现开放；三是"请第三方见证"——如果分歧仍大，请架构师或第三方一起评估数据，用客观依据裁决。核心是"用数据与证据重新论证、承认合理部分、请第三方见证，让方案之争回到事实而非立场"。

被否决后用数据与证据重新论证，而非情绪化辩解。理解否决点、用事实回应、承认合理部分、必要时候第三方见证。让分歧回到事实。

• 能否识别"只有 nit"背后的评审文化问题
• 能否论证"实质评审"的价值
• 能否设计"深度评审"改进机制

评审长期只有 nit 没有实质问题，说明评审"流于形式"——评审者只挑小的、不深入看逻辑，或"不想得罪人、不敢提实质问题"。这背后的文化问题是"评审等于走过场、提实质问题有风险"。改进方向：一是"引导深度评审"——用 checklist 要求评审覆盖正确性、安全、性能、边界等实质维度，而不仅是风格；二是"鼓励实质意见"——营造"提实质问题被认可"的氛围，表彰"拦住 bug 的评审"，让深度评审有价值；三是"示范"——资深评审者先做深度评审，展示"实质评审的样子"，为团队立标杆；四是"评审不是互挑刺"——明确评审的目的是"一起把代码做对"，实质问题不是"挑刺"而是"合作"。核心是"用 checklist 引导深度、鼓励实质意见、示范标杆、重塑评审目的，把'只有 nit'的走过场变成实质评审"。

只有 nit 说明评审走过场或不敢提实质问题。用 checklist 引导深度、鼓励实质意见、示范标杆、重塑评审目的，让评审聚焦实质质量。

• 能否识别"不回复不修改"的冷暴力
• 能否论证"有效沟通"的破解方式
• 能否设计"升级/求助"路径

新人给资深同事提意见被"冷暴力"（不回复不修改），先不要对抗，而是"用对的方式破解"。做法：一是"私下沟通"——私下用聊天/1:1 直接问"我提的几点，你看是否考虑？"给对方一个软性的回应机会，避免当众对立；二是"把意见讲清楚"——确保意见"问题+影响+建议"清晰，让对方无法以"没看懂"回避；三是"寻求支持"——如果私下沟通仍无效，找 mentor 或 leader 帮忙，说明"意见合理但未获回应"，请他们协调；四是"利用规则"——若不阻塞，把问题交回 SLA/评审机制，让问题显性；五是"保持专业"——不被冷暴力带偏情绪，继续专注把事情做对。核心是"先私下有效沟通、确保意见清晰、必要时求助 mentor/leader、利用规则，保持专业不被冷暴力打垮"。

新人遇 Review 冷暴力，先私下沟通、确保意见清晰，必要时求助 mentor/leader 并利用规则。保持专业，不情绪化对抗。

• 能否理解"抽象 vs 简单"的权衡
• 能否论证"以需求与场景裁决"的价值
• 能否设计"裁决方法"

两个评审意见相反（一个要抽象、一个要简单），常常是"两个都对但视角不同"。裁决方法：一是"回到需求"——用当前需求、未来需求、复杂度判断：如果需求明确且短期，简单优先；如果需求会持续演化和扩展，适度抽象更值；二是"权衡代价"——抽象带来"可扩展"但增加复杂度，简单带来"易理解"但可能难扩展，用"当前与未来成本"权衡；三是"折中"——取"适度抽象"（该抽象的地方抽象，不该的地方简单），而不是两个极端；四是"请仲裁"——如果仍僵持，请架构师或第三方裁决，并记录决策。核心是"用需求与场景、成本权衡裁决，取适度抽象折中，必要时请仲裁，避免被两个极端意见拉扯"。

抽象 vs 简单是"扩展 vs 易理解"的权衡，用需求场景、成本权衡裁决，取适度抽象折中。绝不是两个极端谁对谁错。

• 能否识别"明显不合理"的评审意见
• 能否论证"坚持正确 + 不伤关系"的沟通
• 能否设计"对事不对人"的表达

评审意见明显不合理，直接否定会伤关系，但盲从又违背正确方向。处理方式：一是"先确认理解"——用"我理解你的意见是……"复述，确认自己没有误解，也给对方一个"也许我理解偏了"的台阶；二是"用事实表达"——"这个方案我考虑过不支持 XXX，是因为……"，用理由而非否定回应；三是"给出替代"——如果意见不合理，提出更合理的替代方案，让"否定"变成"共同优化"；四是"求同存异"——如果意见不阻塞、纯属偏好，可协商搁置；五是"升级或仲裁"——如果意见明显不合理且影响正确性，保留意见并请权威确认。核心是"复述确认、用事实表达、给替代方案、求同存异、必要时仲裁，坚持正确方向又不破坏关系"。

坚持正确方向又不伤关系，靠复述确认、事实表达、给替代、求同存异。把"否定意见"变成"共同优化"，避免对立。

• 能否理解 AI 评审与人工评审的差异
• 能否论证"以人工判断为准"的原则
• 能否设计"AI 辅助 + 人工裁决"的机制

AI 评审（自动评论）和人工评审冲突时，裁决原则是"AI 是辅助、人工是主裁判"——AI 擅长发现"模式化、可枚举"的问题（风格、常见 bug、覆盖率），但不懂"业务上下文、设计意图、权衡"；人工评审能理解上下文做最终判断。裁决方式：一是"AI 意见作参考"——AI 的自动评论作为"提示"，不自动作为"必须改"的依据；二是"人工复核"——对 AI 意见，人工评审判断"是否合理、是否符合上下文"，合理的采纳，不合理的忽略；三是"冲突时以人工为准"——AI 和人工冲突时，由理解上下文的人工评审决定；四是"AI 帮助找，人工帮判断"——AI 负责"发现"，人工负责"决策"。核心是"AI 辅助发现、人工审查裁决，AI 意见作参考、人工理解上下文做最终判断"。

AI 评审发现模式问题、人工评审理解上下文，冲突时以人工为准。AI 是辅助，人工是主裁判。AI 负责发现，人工负责决策。

• 能否在当众否定时管理情绪
• 能否论证"情绪管理 + 专业应对"的价值
• 能否设计"危机后修复关系"的方法

被当众否定方案，情绪上是难受的，但专业应对是"先稳住情绪、再处理问题"。做法：一是"当场不辩解"——不要当场情绪化对抗，先记下反对点，说"我理解你的顾虑，我回去再想想"，给情绪冷却和思考空间；二是"事后理性复盘"——会后冷静分析反对是否合理，合理的接受，不合理的用事实再沟通；三是"私下对齐"——对关键分歧，私下和对方 1:1 沟通，比当众继续争更利于维持关系；四是"情绪管理"——把"被否定方案"和"被否定个人"分开，被否定的是方案不是你；五是"修复关系"——事后主动沟通，表明"我理解不同意见，我们共同把方案做对"，用专业化解尴尬。核心是"当场不辩解、事后理性复盘、私下对齐、情绪与方案分离、主动修复关系，在被否定中维持专业关系"。

当众否定时先稳住情绪、不辩解，事后理性复盘、私下对齐、情绪与方案分离、修复关系。被否定的是方案，不是人。

• 能否识别"AI 生成代码"的质量问题
• 能否论证"不冒犯"的沟通方式
• 能否设计"对代码不对来源"的评审

AI 生成代码质量堪忧，但直接说"这是 AI 写的，很烂"会冒犯同事。正确做法是"对代码不对来源"——不评论"这是 AI 写的"，只评论"这段代码的问题"（如逻辑、边界、风格），把关注点从"来源"移到"质量"。做法：一是"评估代码本身"——用和评审普通代码一样的标准，指出"这段代码逻辑有漏洞、边界没处理、测试缺失"，不涉及"是不是 AI"；二是"给改进建议"——具体指出怎么改、哪里不好，让改进可执行；三是"提醒把关"——如果 AI 生成代码普遍质量差，可以建议"AI 生成后要人工 review 和测试验证"，从"流程"角度提醒，而非指责个人；四是"保持尊重"——承认 AI 是工具，同事用它没错，关键是"用 AI 也要保证质量"。核心是"对代码不对来源、按标准评审、给可执行建议、从流程提醒把关，不冒犯地提升 AI 代码质量"。

AI 生成代码质量差的评审，关键是"对代码不对来源"。按标准评审代码、给建议、从流程提醒把关，不针对"是不是 AI 写的"。

• 能否识别这类冲突的"层级"（风格/架构/顺序）
• 能否论证"按层级化解"的原则
• 能否设计"分而治之"的化解策略

评审冲突分不同层级，化解策略不同：一是"代码风格"——这种冲突最低级，用工具（formatter/lint）和团队规范统一，不靠个人争论；二是"架构"——这是最高级、影响最大的冲突，用需求、成本、风险权衡，必要时请架构师或仲裁，做决策记录；三是"合并顺序"——这是"流程"冲突，用拆分、依赖顺序、短命分支等机制解决，不掺杂风格或架构。化解的原则是"分而治之"——风格用工具、架构用裁决、顺序用流程，别把不同层级的冲突混在一起。核心是"按冲突层级分而治之：风格用工具规范、架构用权衡裁决、顺序用流程机制，避免混为一谈"。

评审冲突分风格、架构、顺序层级，应分而治之。风格用工具、架构用裁决、顺序用流程，避免把不同层级冲突混在一起。

• 能否识别"各说各话"的评审标准缺失
• 能否论证"统一标准"的价值
• 能否设计"跨团队标准"的建立

跨团队评审"各说各话"，是因为双方没有统一的评审标准（每个团队用自己的尺度、术语、优先级）。建立统一标准的方法：一是"对齐评审维度"——双方共同定义评审要覆盖的维度（正确性、安全、性能、可维护性、测试），用 checklist 统一框架；二是"统一优先级"——明确 blocker/should/nit 的判定标准，让"什么必须拦"有共识；三是"共享术语"——对齐术语和表达，避免"说不同的话"；四是"建立跨团队评审约定"——把标准写成文档，作为双方评审的共同依据，并定期回顾更新。核心是"用共同 checklist、统一优先级、共享术语、文档化约定，建立跨团队一致的评审标准，消除各说各话"。

跨团队各说各话源于标准缺失。用共同 checklist、统一优先级、共享术语、文档化约定建立统一标准，让评审有共同语言。

• 能否理解"权威对抗"的沟通难点
• 能否论证"事实与数据"的说服力
• 能否设计"数据化论证"的沟通

面对权威（资深同事）的对抗，靠"权威压人"或"情绪"都无效，最有力的是"事实与数据"。做法：一是"准备数据"——用数据支撑你的观点（性能测试、成本、用户数据、对比结果），让"我觉得"变成"数据显示"；二是"用事实表述"——"我们可以用这个数据验证一下"或"我做过一个测试，结果是……"，用可验证的事实沟通；三是"展示权衡"——用数据呈现方案的权衡（成本、收益、风险），让权威也能看到"你的方案在数据上更优"；四是"邀请验证"——提议"我们做个验证/试点看数据"，用结果说话，而不是口头争。核心是"用数据和事实替代立场对抗，展示权衡、邀请验证，让权威也服从事实"。

权威对抗中数据最有力。用数据支撑、事实表述、展示权衡、邀请验证，让说服回归事实而非立场。数据能突破权威的防御。

• 能否识别"何时该升级仲裁"的边界
• 能否论证"升级仲裁"的必要条件
• 能否设计"升级机制"

评审冲突不能一有分歧就升级，但也不能无限僵持。需要仲裁的边界：一是"双方无法达成一致"——经过多轮沟通仍无法收敛；二是"影响重大"——冲突涉及关键架构、安全、核心功能、大范围影响；三是"有实质后果"——如果继续僵持会阻塞交付、带来风险或返工；四是"一方坚持明显有风险"——其中一个方案有重大风险但另一方坚持。具备这些条件时该升级仲裁。仲裁方式：请架构师/技术负责人/leader 作为仲裁者，基于需求和证据做决策，并记录决策（ADR）。不该升级的情况：只是风格、小 nit、可协商的偏好，应自行解决。核心是"分歧大 + 影响重大 + 有实质后果时升级仲裁，小分歧自行解决，用架构师/leader 裁决并记录"。

升级仲裁的边界是"分歧大、影响重大、有实质后果、僵持"。小分歧自行解决。用架构师/leader 裁决并记录，避免无限僵持或过度升级。

• 能否识别"评审冲突不留痕"的后果
• 能否论证"记录 + 跟进"的闭环价值
• 能否设计"闭环"机制

评审冲突如果不记录、不跟进，会"吵完就忘、下次再吵、结论无法追溯"。闭环的做法：一是"记录冲突与结论"——把冲突点、双方观点、最终裁决写进评审记录/ADR，让"为什么这么定"可追溯；二是"行动项跟进"——冲突产生的行动项（改哪、谁改、何时改）明确 owner 和截止日期，跟踪落地；三是"定时复查"——过段时间复查冲突是否解决、裁决是否有效，避免"裁决了但没执行"；四是"沉淀经验"——把冲突的类型和化解方式沉淀，减少同类冲突。核心是"记录冲突与结论 + 行动项跟进 + 定时复查 + 沉淀经验，让评审冲突有记录、有执行、有闭环"。

评审冲突不闭环会重复、无追溯。记录结论、行动项跟进、定时复查、沉淀经验，让冲突有始有终、可追溯、可复用。

• 能否定义 blocker/should/nit 的判定标准
• 能否论证"优先级标注"对作者的价值
• 能否设计"统一标注"的评审习惯

给评审意见标注优先级（blocker/should/nit），是为了让作者"知道先改什么、哪些可讨论"。定义：blocker（必须改）——影响正确性、安全、性能、架构的关键问题，不改正无法合并；should（建议改）——影响质量但不阻断，建议改进；nit（可讨论）——风格、小优化、可协商。落地方式：一是"每条意见标优先级"——用标签或前缀（如 [blocker]/[should]/[nit]）让作者一眼看清；二是"给理由"——blocker 要说明为什么必须改（影响），should/nit 说明价值；三是"团队统一标准"——让团队对 blocker/should/nit 的判定有共识，避免"你是 blocker 我是 nit"的歧义；四是"review 结束汇总"——评审结束时汇总"必须改的"和"可协商的"，给作者清晰的下一步。核心是"用统一优先级定义 + 每条标注 + 给理由 + 团队共识，让作者明确改什么、可讨论什么"。

blocker/should/nit 标注让作者聚焦优先级。定义判定标准、每条标注、给理由、团队共识，让评审意见可执行、可讨论。