题干与适用场景
请讲一次你与依赖团队对 API 契约存在分歧的经历。对方认为你的方案会增加维护成本，而你担心不改会影响可靠性。你如何澄清事实、达成决策并交付？
这道题考察跨团队协作、技术权衡和影响力。Atlassian 的工程面试指南明确关注问题解决、学习敏捷性、协作与沟通；好的回答应呈现真实约束、可验证证据、共同决策和结果，而不是把对方描述成阻力。
面试官考察点
面试官会看你能否把分歧转成共同目标，区分事实与偏好，说明兼容性、可靠性、成本和时间的权衡，记录决策与责任边界，并在新证据出现时调整方案。还会关注你是否保护了依赖团队的交付节奏。
回答前需要澄清的问题
确认 API 的消费者、版本、SLO、数据敏感性、上线窗口和不可接受的失败；确认分歧是字段语义、错误契约、兼容周期还是运营责任。准备双方都能验证的日志、流量、故障样本、迁移成本和回滚条件。
30 秒回答框架
“我先把争论改写为共同目标：在上线窗口内满足可靠性和维护成本约束。然后分别列出已知事实、假设和未知量，邀请依赖团队共同确认。我们比较两种契约的兼容、观测、迁移和回滚成本，并用小范围验证降低不确定性。最后写下决策、负责人、截止时间和触发回滚的指标；交付后复盘是否达到目标，并把经验沉淀为模板。”
分步骤深入解答
第一步：先对齐用户和服务目标
不要从“谁的字段设计正确”开始。先写出用户影响、可靠性目标、上线时间和维护边界，确认双方都在优化同一个结果。若目标冲突，明确由谁做产品或架构取舍。
第二步：把意见拆成事实、假设和偏好
列出实际调用量、失败率、兼容客户端、迁移工作量和支持窗口。对没有数据的说法标注为假设，并安排一次可逆验证。避免用资历、团队规模或声音大小代替证据。
第三步：比较契约选项
至少比较现状、最小兼容改动和长期方案。对每个方案记录字段语义、错误码、版本策略、观测、性能、维护成本和回滚方式。让依赖团队一起填写成本，减少“你要求我改”的对立。
第四步：设计可逆的试验
可以先增加可选字段、双写、影子流量或消费者契约测试，再观察真实结果。试验要有时间盒、成功指标和停止条件，不能把临时兼容层无限期保留。
第五步：做出并记录决策
在 ADR 或项目记录中写清背景、选项、理由、风险、负责人、截止日期和回滚触发器。不同意的人可以保留异议，但必须知道何时重新打开决策。
第六步：保护依赖团队的交付
主动提供迁移示例、测试夹具、兼容窗口和联调时间。若你的改动会增加对方工作，说明你承担的配套工作；不要把未完成的迁移责任隐含地推给消费者。
第七步：用指标管理上线风险
上线前定义错误率、延迟、未知字段比例、回滚耗时和消费者成功率。分阶段扩大流量，发现指标越过阈值就暂停或回滚，而不是等到双方互相归责。
第八步：复盘并改变系统
交付后检查结果是否符合假设，记录哪些证据改变了决策。把契约模板、评审清单、兼容测试或责任矩阵纳入团队流程，让下一次分歧更早暴露。
高质量示范回答
在一次订单状态 API 迁移中，消费者团队担心新增错误层级会增加客户端维护，我则担心继续返回模糊错误会让重试放大故障。我先与对方对齐目标：不改变当前上线窗口，同时把可重试和不可重试情况区分清楚。我们整理了过去 30 天的错误样本、客户端版本和重试量，发现真正的问题集中在两个状态。于是先增加向后兼容字段，并用契约测试和影子流量验证；我负责示例 SDK、迁移文档和观测面板，对方负责两个高流量客户端。我们在 ADR 中记录方案、负责人、两项暂停指标和回滚路径，分阶段放量。上线后重复请求率下降，未发现旧客户端解析失败；复盘时把错误契约模板加入评审清单。这个过程没有要求对方接受我的偏好，而是用共同指标和可逆步骤推进决策。
常见错误
把对方说成“不懂技术”
依赖团队通常掌握消费者约束。贬低对方会掩盖真实迁移成本，也无法证明你能建立信任。
只讲最终方案，不讲被否定的选项
面试官需要看到你如何比较权衡。至少说明两个选项、关键证据和为什么放弃另一方案。
没有明确结果和自己的责任
“大家最后同意了”不是结果。给出可验证指标、时间范围、你承担的工作和遗留风险。
追问及应对
对方仍不同意，你会怎么做？
先确认争议是否有新事实，再邀请架构或产品负责人按既定决策权作出选择。记录异议、风险和复核时间，继续提供可逆的最小交付。
如果上线窗口只剩两天怎么办？
缩小范围，优先保护不可逆风险和关键消费者；采用兼容字段、开关或影子验证，明确哪些改动延期，不能用口头承诺替代回滚方案。
你如何证明自己的方案没有过度设计？
说明删除了哪些非必要能力，比较实际流量和故障成本，设置时间盒并计划移除兼容层。让需求证据决定复杂度，而不是预设一个完整平台。
如果数据推翻了你的判断呢？
公开承认假设错误，更新 ADR 和指标阈值，选择更安全的方案，并说明你如何把新证据传给受影响团队。
如何防止同类分歧再次发生？
把契约、版本、错误、兼容窗口和负责人写成模板，加入消费者契约测试和发布清单，在编码前安排短评审。
这个故事怎样体现影响力而非控制欲？
强调你促成了共同目标、证据和可逆决策，并承担了配套工作；结果来自团队共同选择，而不是你压过对方。