每个技术团队都有个共同的幻觉：我们在招最优秀的人。

JD写的是"追求卓越"，面试聊的是"技术深度"，评级用的是"超出预期"。所有的信号都在告诉你，你们在建立一个精英团队。但你有没有认真看过你团队里的人——他们解决问题的思路是不是惊人地相似？他们认同的技术方案是不是高度一致？他们对"好代码"的定义是不是几乎一模一样？

这不是因为相似的人恰好都最优秀。这是因为你在招聘的第一步，就已经把"和我像"编码成了"优秀"。

你以为的标准，其实是你的倒影

技术面试有一个很少被质疑的前提：面试官能够客观地判断候选人的技术能力。但事实是，大部分技术面试的"客观标准"，不过是面试官自身经验的主观投射。

举个很常见的场景：两个候选人，能力相当，但一个和你用了同样的技术栈、同样的架构思路，另一个用了不同的方案解决了同样的问题。你觉得谁更强？大概率你会觉得前者"更扎实"、"理解更深"，后者"还行但细节不够"、"方向有点偏"。这不是你在有意偏袒——是你的大脑在用"熟悉度"作为"质量"的代理指标。

每个做过高并发系统的人，大概都经历过这样的时刻：线上出了个数据不一致的bug，排查一圈发现是缓存没更新。修完之后加个主动失效，觉得踏实了。过几天又出现，这次是另一个缓存层级。再修。再过段时间，用户反馈看到的金额对不上——你一查，三个缓存层级，两个过期时间不一样，一个还挂着CDN缓存头。

这不是段子，这是每天都在生产环境里上演的日常。

团队解决性能问题的第一反应永远是加缓存。页面慢？加个Redis。接口慢？加个本地缓存。前端渲染慢？加个HTTP Cache-Control。数据库扛不住？加个查询缓存。每一层缓存都在解决一个真实的问题，但每一层缓存也在制造一个你暂时看不见的新问题——等到它浮现的时候，往往已经是你最不想看到的形态。

缓存是性能的银弹，也是一致性的地雷

这里有个反直觉的事实：缓存从不制造bug，它只是把bug从"现在就暴露"延迟到"不知道什么时候暴露"。

一个没有缓存的系统，数据读出来就是最新的，哪怕慢一点，至少不会错。但当你开始在链路上堆缓存，你事实上引入了一个隐含假设：旧数据在一段时间内是可以接受的。这个假设在大部分场景下成立，但"在大部分场景下成立"和"在你的场景下成立"是两回事。

每个工程师都有过这种时刻——翻开一段半年前写的代码，眉头一皱，手指开始痒。"这什么写法？""这命名谁看得懂？""这段逻辑完全可以抽象成三个函数。"然后一个"重构"的念头冒出来，越来越强烈，像夏天傍晚的蚊子，赶不走。

这种冲动太普遍了，以至于我们很少质疑它。代码审查时建议重构，结对编程时讨论重构，技术债清单里排满了重构项，季度规划里少不了"代码优化"的工时。重构似乎天然正确，像一种工程美德。

但我的观察恰恰相反：大部分重构是错误的决定。不是重构这件事有问题，是驱动重构的动机和时机几乎总是错的。

丑代码不等于坏代码

先说一个多数人不愿意接受的事实：代码的审美和代码的质量，经常是两回事。

一段看起来笨拙的代码，可能在一个微妙的时间窗口里正确处理了并发竞争。一段到处是硬编码的代码，可能正是因为硬编码才避免了配置出错引发线上故障。一段三百行的函数，可能是经过六次需求变更后唯一还hold得住的逻辑形态——你把它拆成六个"优雅"的函数之后，任何一个需求的变更都会涉及三个函数的修改，追踪数据流变成了噩梦。

"丑"是主观判断，"坏"是客观后果。两者之间没有必然因果关系，但在重构决策里，它们经常被混为一谈。工程师看到不美的代码就判定它需要重构，这个推理本身就是逻辑谬误。

我最近注意到一个挺有意思的现象：团队里用AI编程工具最积极的那几个人，代码变更量差不多是其他人的3倍，但需求交付速度并没有快3倍。仔细看了一下，有些人的单个bug修复，diff比需求本身还长。

这不是个例。当你跳出"AI提效"的叙事，认真看AI代码助手在项目中留下的痕迹时，会发现一个被忽略的问题——AI有天然的过度编辑倾向，而且这种倾向正在悄悄地侵蚀代码库的健康度。

AI的"讨好型人格"

先说一个可能很多人没太注意的事：AI代码助手本质上是有讨好倾向的。

你让AI修一个空指针异常，它不光改了那行判空逻辑，还顺手调整了方法签名，给相关变量补了类型注解，甚至把异常处理的模式也给重构了。每一步看起来都合理，每一步单独拎出来都是"改进"，但加在一起，你只是为了改一个判空，变了三十行代码。

AI为什么这样？因为它的训练体系中，"提供有价值的回答"是一个核心信号。对AI来说，只改一行和改三十行，哪个更像"用心回答"？更关键的是，你问AI"还有没有可以改进的地方"，它几乎不可能说"没有了，当前代码已经很好"——它会找出所有能优化的点，然后一股脑全给你改掉。