一个“多余”的问题
这次共创的起点，是一封看似多余的邮件。
客户Leslie在购买了4-Port 8K 60Hz HDMI 2.1 KVM后，第一封邮件中没有抱怨，没有故障描述，而是非常谨慎地问：
“为了测试我的设备，我可以只接一台PC到切换器上吗……这听起来像是个多余的问题，但我只是想覆盖所有可能性。”
这句话本身提醒了我们一件事：对客户来说，产品“是否安全、是否可被正确理解”，和性能参数同样重要。
我们如实回答了：可以只接一台PC，不会损坏设备。
但对话没有停在“问题已解决”。
从“能用吗”到“为什么能/不能”
几天后，Leslie主动提出了一个完全不属于常规支持范围的问题：
“KVM内部发生了什么，导致它无法支持超宽屏显示器？”
他不是在问“能不能用”，而是在追问原理：
- EDID是不是不同格式？
- 协议是不是不一样？
- 是容量不够，还是信息更多？
这是一个典型的真实用户声音：不是投诉，而是对行业模糊说法的不信任。
在回复这个问题的过程中，我们第一次系统性地把以下原本只存在于工程师内部讨论的内容，用用户能理解的方式完整讲清楚：
- EDID base block
- Extension block（CTA-861 / DisplayID）
- EDID emulation vs. pass-through
- 带宽瓶颈 vs. EDID丢失
客户指出了我们的成长方向
Leslie在下一封邮件中明确告诉我们：
“我建议你们把这个解释加到FAQ里。”
“有些KVM厂商虚假宣传支持21:9，实际上根本不能用。”
这一刻，我们意识到一件非常重要的事：
客户不是只在使用我们的产品，而是在替整个行业“纠错”。
他不是要求我们修一个bug，而是用自己的经验告诉我们：
- 市场上“支持21:9/ultrawide”的说法存在大量误导
- 用户真正需要的不是一句“支持”，而是“为什么不支持、会在哪些情况下出问题”
第一次共创成果（服务与内容层面）
我们开始把“EDID / 超宽屏 / 带宽限制”的解释，作为必须公开、必须写进FAQ的内容，而不是藏在技术支持邮件里。
从“客户在排查”到“客户在教我们测试世界”
接下来发生的事情，彻底改变了我们对“客户角色”的理解。
Leslie并没有简单地说“不行”，而是提供了极其系统的真实测试数据：
- x79 / x99 / x299 三代芯片组
- NVIDIA vs. AMD
- Windows vs. SUSE Linux
- HDMI 2.1 vs. DisplayPort
- 5120×2160 @ 180Hz / 120Hz / 60Hz
- BIOS / POST / OS 切换阶段的行为差异
他一步步推导出结论：
“当切换器接入后，它变成了一个不同的硬件……在启动过程中，刷新率会被重置为原生180Hz……”
这个结论，不是我们给他的，而是他通过真实使用环境“教会”我们的。
第二次共创成果（产品与验证层面）
因为这次反馈，我们第一次清晰地意识到：
高刷新率超宽屏 + 旧平台BIOS，在boot阶段与EDID pass-through结合时，会暴露出我们在实验室里几乎不可能覆盖的边缘场景。
这些并不是“产品坏了”，而是产品在真实世界中的极限行为。
我们因此把以下组合正式加入内部验证和未来设计的关注清单：
“旧平台 + 高刷新率超宽屏 + KVM链路中的BIOS/boot行为”
客户不仅指出问题，还给出了改进方向
在长期交流中，Leslie明确指出了一个真实使用痛点：
“唯一的改进点是——如果键盘能在BIOS界面中保持可用就好了。”
并且进一步提出了具体、可执行的改进想法：
- USB share port如果在BIOS阶段能保持键盘可用
- 同时支持hotkey
- 将极大改善多平台、多主机用户的体验
第三次共创成果（产品设计层面）
这不是一句泛泛的“体验不好”，而是一个直接影响下一代产品设计取舍的输入。
共创的结果：我们被改变了
从这次共创中，我们真正获得的成长是：
产品层面
- 更清楚EDID pass-through在极端场景下的边界
- 意识到高刷新率超宽屏 + 旧平台BIOS是一个必须正视的组合
- 将BIOS阶段HID行为作为未来设计的重点方向之一
服务与内容层面
- 把“为什么不能支持”讲清楚，而不是只写“支持/不支持”
- 将复杂技术问题转化为用户可理解、可判断的决策信息
- 避免行业常见的“参数式误导”
认知层面
- 客户不是“问题来源”，而是真实世界的测试环境
- 共创不是我们“帮客户”，而是客户在推动我们变得更专业、更诚实
这次共创没有停在“问题已解决”。它让我们重新理解了一件事：
最好的产品，不是没有边界的产品，而是愿意和用户一起，把边界讲清楚的产品。
