技术说服与评审
一、如何让方案被接受：证据、故事与逻辑
说服不是「我觉得好你就该同意」，而是让听众自己得出类似的结论。三个支柱：证据（数据、案例、基准测试、业界实践）、故事（场景化的问题与结果，让人有代入感）、逻辑（从问题到方案到结论的推理链，无漏洞）。证据撑腰、故事抓人、逻辑服人；缺了证据容易被认为是拍脑袋，缺了故事容易枯燥难共鸣，缺了逻辑容易被人挑刺。
二、技术评审的流程与礼仪
评审要有流程：提前发材料、限定范围与时间、明确「评审目的」（是决策通过、还是收集意见、还是共识会）。会上：礼仪包括控制时间、让各方有机会发言、对事不对人、结论与待办写清楚。主持人要控场：跑题时拉回、争执时叫停并约定「会下再对齐」、结束时总结「通过/不通过/待补充」与下一步。
三、写评审意见与口头反馈的技巧
评审意见要具体、可操作、对事不对人。避免「这不行」「写得烂」；改为「这里缺少错误处理，建议在 XX 分支加 try/catch 或返回明确错误码」。口头反馈时：先肯定再提建议、分「必须改」与「建议」、允许对方解释或澄清。建设性反馈能帮助改进；人身攻击或泛泛的否定只会引发防御心理、不利于共识。
具体、可操作、对事不对人；分「必须改」与「建议」；允许解释与澄清。
- 「这里缺少超时与重试，建议加 2s 超时、1 次重试」
- 「建议」：可选项，不强制
泛泛否定、人身攻击、不可操作；易引发防御、难以达成共识。
- 「这设计不行」「谁写的，太烂了」
- 无具体改进点，对方不知怎么改
四、接受批评与迭代方案
自己的方案被批评时，先听清再回应：不要急于辩解，把对方的关切和论据听完整；区分「对事的异议」与「对表述的误解」，前者可讨论取舍，后者可澄清。能接受的批评就纳入迭代，并在下一版中体现；不能接受的要有理由与证据回应，而不是情绪化反驳。接受批评不是认怂，而是把评审当成改进机会；迭代后的方案往往更稳、也更容易获得支持。
接受批评的要点
- 先听清： 不急于辩解，听完整关切与论据；可简要复述确认理解。
- 区分异议与误解： 异议讨论取舍、误解澄清表述；对事不对人。
- 能接受的纳入迭代： 下一版体现改进，并说明「根据 XX 意见已调整」。
- 不能接受的要有理由回应： 用证据与逻辑说明，而非情绪化反驳。
五、在代码评审与架构评审中的实践
代码评审（CR）：关注正确性、可读性、测试与边界情况；意见具体到行或函数；区分 blocking 与 nit。架构评审：关注边界、依赖、风险、可演进性；决策点与取舍要写清；可结合 ADR。两者都遵循「流程清晰、反馈建设性、结论与待办闭环」；架构评审更偏「是否通过、有哪些前提与后续」，代码评审更偏「改完再合」。
正确性、可读性、测试与边界；意见具体到行/函数；区分 blocking 与 nit；改完再合。
- Blocking：必须改才能合
- Nit：可选，不阻塞
边界、依赖、风险、可演进性；决策与取舍写清；结合 ADR；结论为通过/不通过/待补充及后续。
- 通过前提、遗留项、谁跟进
要点： 说服靠证据、故事、逻辑；评审靠流程与礼仪；反馈要建设性、具体、可操作；接受批评要听清、区分、迭代或有理回应；CR 与架构评审各有侧重，但都追求结论清晰、待办闭环。
反例：无证据硬推、评审变吵架、反馈伤人。
某次方案评审，主讲人只说「我们觉得这样设计好」，没有数据、没有对比、没有推理链；被问「和现有方案比有什么优势」时答不上来，评审悬而未决。再如：评审会上有人直接说「这设计根本不行」，没有具体指出问题，作者觉得被否定人格，当场争执起来，会议不欢而散。还有：CR 里写「这段代码写得太烂了」，没有说哪一行、该怎么改，作者不知道如何下手且感到冒犯。正确做法：方案带上证据（压测、对比、案例）和逻辑链；评审意见具体、可操作、对事不对人；有分歧时会下对齐或约定升级，不在会上人身攻击。技术说服与评审目的是达成共识与改进，不是争输赢。
小结： 让方案被接受靠证据、故事与逻辑；技术评审要有流程与礼仪（发材料、控场、结论与待办、跟进）；评审意见与口头反馈要建设性、具体、对事不对人；接受批评要听清、区分异议与误解、迭代或有理回应；在代码评审与架构评审中实践上述原则，各有侧重但都追求闭环。
六、小结
技术说服与评审是架构师的基本功。用证据、故事、逻辑让方案被接受；用流程与礼仪做好评审；用建设性反馈帮助改进；接受批评并迭代方案；在代码评审与架构评审中落实。下一章讲写作与演讲：把想法说清楚，写好博客、RFC 与提案，做好汇报与 Q&A。