能看懂代码不代表能写出代码

前两天在公司复盘代码逻辑，有个挺扎心的瞬间：面对一个基础的 Go HTTP handler 逻辑，我竟然盯着屏幕发愣，甚至开始怀疑 http.HandleFunc 的具体用法。这种感觉很诡异——我能一眼看出 AI 生成的代码里有没有逻辑漏洞，甚至能跟它讨论架构设计的优劣，但一旦让我脱离补全插件从零开始敲，我发现自己只会“模式识别”，而失去了“生产能力”。

这就是典型的“识别”与“生产”的错位。AI 把这种差距拉得极大：以前我们查 Stack Overflow 或看文档，起码还有个检索和理解的过程；现在 AI 直接把结果喂到嘴边，让你产生一种“我懂了”的错觉。其实你只是在做模式匹配，你的大脑在识别模式，而不是在构建逻辑。

在公司推行 AI 辅助编程时，我发现团队里这种“虚假繁荣”很普遍。大家写代码的速度确实快了，Review 的效率也高了，但底层的工程直觉正在退化。如果你习惯了当一个“审查员”而非“生产者”，一旦脱离工具，你会发现那种处理边缘 case、应对分布式系统复杂故障的能力，根本没长在脑子里。

我最近在尝试换个搞法，不再让 AI 直接写，而是自己先硬着头皮手撸分布式算法逻辑，写完之后再把代码丢给 AI 做 Review。这种“先苦后甜”的流程虽然慢，但确实能把那种由于过度依赖工具而产生的技术断层给补回来。

毕竟，代码只是结果，那些凌晨两点修 Bug 留下的“伤疤”才是真正的经验。靠下载指令拿不到工程直觉。