Netflix 最近分享了如何重新设计其实时服务依赖地图，核心不是技术细节，而是拆分决策的时机和方式。做了很多年技术管理，我发现架构该不该拆、什么时候拆、怎么拆，是最考验技术管理者判断力的问题。多数团队在两个极端之间摇摆：要么忍着不动直到系统崩溃，要么一上来就大规模重构然后烂尾。

最近看到一条数据让我有点恍惚——Sonar 的2026年开发者调查报告显示，AI 已经占了提交代码的42%，但96%的开发者并不完全信任这些代码。拿了就用，用了又不信，整个行业陷入了一种奇怪的拧巴状态。

我挺能理解这种拧巴的。上个月我们团队做了个内部统计，工具生成的代码在PR里占比确实越来越高，但真正的问题不是"AI能写多少代码"，而是——写了之后，谁来确认这些代码是对的？

贡献者退场，守护者上场

做了这么多年技术面试，回头看，最贵的成本不是招错一个人，而是你根本不知道自己错在哪里。

早期我面试有个执念：能把算法题写出来的人，工程能力不会差。这个信念让我错过了一些人，也让我招错了一些人。直到有次被现实教育——一个面试表现非常出色的候选人，入职三个月就让我开始怀疑自己的判断力。

第一次看走眼

那个候选人来的时候，我们聊了两个小时。从系统设计到编码细节，他都能接住。我问他一个并发场景怎么处理，他几乎是脱口而出地给了三种方案，还主动比较了优劣。

面试结束我就跟团队说，这个人我要了。

入职后呢？代码确实写得不错，Review也能过。但慢慢地问题浮出来了：跟产品对需求理解有偏差时，他不会主动澄清，而是按自己的理解做完再说。跟后端联调遇到接口不一致，他倾向于等别人改而不是沟通解决。分配任务时，他永远选技术最有趣的那个，而不是业务最紧急的那个。

三个月后我开始反思：我在面试里到底看到了什么？

答案是：我看到了一个"面试能力强"的人，但没看到一个"工程能力强"的人。这两个东西，重叠度远没有我想象的高。

"流畅"的陷阱

上个月，一个朋友在群里吐槽：他们的在线文档产品要加多人协作功能，技术负责人评估了一下，给了个方案——用 WebSocket 广播所有编辑操作，冲突了就提示用户"文档已被他人修改，请刷新后重试"。

我问他，你们打算让用户刷新多少次才能写完一段话？

这不是段子。在我见过的技术选型里，"广播 + 冲突提示"仍然是很多团队处理实时协作的第一反应。理由很简单——实现成本低，逻辑好理解。但这条路的尽头，是一个永远填不完的坑。

冲突不是边缘情况

想象一个场景：两个人同时编辑同一份文档的同一行。A 把"用户协议"改成了"服务条款"，B 在同一位置加了个逗号。两个操作几乎同时发生，网络延迟让它们到达服务器的顺序不确定。

传统做法要么让 A 的修改覆盖 B 的（后到的覆盖先到的），要么把文档锁住让 B 等 A 改完。前者丢数据，后者体验差。

CRDT（Conflict-free Replicated Data Type，无冲突复制数据类型）提供了第三条路：从数学上保证，只要操作满足交换律和结合律，无论网络传输顺序如何、延迟多长，所有客户端最终都会收敛到同一份数据。不需要中心服务器仲裁，不需要锁，不需要用户手动解决冲突。每个操作本身就是一个独立的、可传播的、可合并的单元。

从论文到产品的距离