我目前在 Google 做 LLM inference / GPU、TPU performance optimization，level 是 L4。最近我和团队里一位 L5 在一个 customer workload 上发生了比较明显的 ownership overlap。 之前 manager 已经明确分工：我负责 investigate 一个 kernel issue，这位 L5 负责另一个 workload。我也在 team chat 里公开说过自己正在做这个 kernel，并在上周五 share 了结果，当时在 customer 实际 workload 上已经达到约 85% HBM bandwidth，之后进一步做到约 90%。 但这位 L5 周末 independently 开始做同一个 kernel，没有提前和我沟通，并很快写了一份 customer-facing document 发给了客户。这不是第一次出现类似的 ownership overlap，只是我不想展开之前的 case。 后来我检查这份 document，又发现两个问题。 第一，一个 XLA flag 被专门写进 document 说明没有 improvement。但这个 flag 原本只是 external collaborator 在和我进行 exploratory technical discussion 时给我的 suggestion，并不属于之前的 customer discussion。CE 后来也独立指出这个内容不应该写进去，manager 已同意删除。 第二，document 中部分 performance results 我目前无法 reproduce。他提供了 kernel code，但没有完整 benchmark setup。根据我的测试，他的 implementation 在 customer 实际 workload 上大约只有 50–60% HBM bandwidth，而接近 90% 的结果似乎来自另一个 shape。由于缺少完整 benchmark script，我现在不能百分之百确认，所以只把它视为一个需要验证的 significant discrepancy。 因为已经存在 ownership overlap，我不希望再直接去 challenge 或帮助他 debug 这份工作。我更倾向于把 discrepancy 告诉 manager，让 result owner 自己重新 verify customer-facing numbers；如果可能，也不需要特别告诉他这个 concern 是我提出的。 这种问题怎么办
提问
把问题拆成两件独立的事：客户文档里的数字是否可复现，属于结果正确性；谁该负责这个 kernel，属于分工与协作。前者优先，后者用一次对齐解决。
数字对不上，先按结果正确性处理
客户文档里的性能数字如果无法复现，风险不在谁做的，而在客户拿到的结论可能站不住。你测到 50–60%、他写接近 90%，差异可能来自 shape 不同、benchmark setup 不同，或测量口径不同——在你拿到完整 benchmark script 之前，这仍是待验证的 discrepancy，不是已确认的错误。处理这类问题时，把可复现性当作独立于人的标准：谁能复现、用什么 setup 复现，比谁先做更重要。一个可试的做法是，先只向 manager 陈述你观察到的现象和你的复现条件，让 result owner 在相同 setup 下重跑，而不是由你直接下结论说数字错了。这样既保护客户，也避免把技术分歧变成人际冲突1。
分工重叠要靠一次明确对齐，不靠回避
AI推演你已经在 team chat 公开说明在做这个 kernel，manager 也有明确分工，说明问题不在信息缺失，而在分工没有被当作约束执行。回避直接沟通、只让 manager 转达，短期能减少摩擦，但可能让重叠继续发生，也让 manager 反复处理同一类问题。更稳的做法是把两件事分开：数字 discrepancy 走结果验证流程；ownership 走一次和 manager 的明确对齐，说清哪些工作由你负责、边界在哪、下次遇到重叠希望怎么处理。这属于影响他人和争取认可的一部分，需要主动 earn，而不是等对方自觉2。
现有材料没有直接讨论大厂内 ownership 冲突或客户文档纠错的具体流程，以上是从结果验证和影响他人两个角度做的推演，不构成对 Google 内部流程的判断。
回到2份原文
讲评价标准应由任务决定、演示条件不等于你的工作条件，适合核对为什么数字差异要先看 setup 和比较对象。
讲 leadership 关注度需要主动 earn、有用的观点比埋头分析更重要，适合思考分工对齐和向上沟通的方式。