为什么我能审好代码却写不了好代码

AI 驱动的编程正在带来日益沉重的认知债务。

……我一直以自己的专业能力为傲。我能迅速发现错误，高效完成代码审查，也能很快识别出不同系统之间的共通模式。但自从学会使用 AI 之后——大概是在 2024 年年中，我从 2018 年入行时起，一直采用的还是传统开发方式——我开始让 AI 编写大量代码。

而且我一直以为自己仍在学习。

直到有一天，我坐下来，想从零开始用 Go 编写一个 HTTP handler，却突然僵住了……那种恐惧，我很难用语言形容。

并不是因为我不理解 HTTP，也不是因为我不懂 Go。因为下面这些模式，我一眼就能认出来：

func (s *Server) handleJobNext(w http.ResponseWriter, r *http.Request) {
    // ...
}

我能审查这段代码，找出错误，讨论它的设计。但从零开始写呢？我发现自己脑子里冒出来的却是：“等等……是 http.HandleFunc 吗？还是 ServeMux？服务器要怎么启动来着？”

就在那一刻，我意识到出问题了。我终于看清自己掉进了怎样的陷阱，也意识到必须做点什么。

识别不等于产出

AI 最容易让人陷入的巨大幻觉，就是以为“我理解这个”和“我能把它写出来”是一回事——因为这两种感觉实在太相似了。

我也想澄清一点：这个问题并不是 AI 最先带来的。Stack Overflow、复制粘贴的框架代码和各种教程，早就制造了这个问题；AI 只是在加速拉大两者之间的距离。

识别出一个解决方案，只是一种能力。习惯之后，你的大脑会极其擅长模式匹配，而且这个过程远比你想象的轻松。你看到 http.HandleFunc，心想：“没错，路由就是这么注册的。”于是便觉得自己掌握了它。

但如果让你完全不参考任何东西，从头提取并组织这些知识，那就是另一个层次了。它们依赖的是完全不同的神经通路。因为审查代码、评估设计与架构的能力，和凭记忆把代码写出来，并不是同一种能力，绝不能混为一谈。

我非常擅长代码审查——可能擅长过头了。我又快又高效，能够批评架构、发现边界情况、提出正确的问题，甚至可以围绕这些内容展开一场仿佛酒吧醉谈般滔滔不绝的讨论。

可你知道吗？尽管我能做到这一切，真正让我害怕的是：我竟然无法凭记忆写出一个 HTTP handler。

我的确在练习某些能力。

只是某些能力而已。

只是并不是我以为自己正在练习的那些能力。

认知鸿沟，以及我为何开始这个系列

这里还隐藏着一个危险的自信陷阱：你会说服自己，认为自己仍在学习，因为你扮演的是“架构师”或“审查者”的角色。你在做决策，也理解整个系统。

但如果你知道，在不参考任何东西的情况下，自己根本写不出 AI 生成的代码，你会有什么感受？

这就是那道鸿沟。

总之，几个月前，我开始完全从零用 Go 编写分布式系统算法，每种算法各自放在独立的 repo 中。不使用 AI。所有代码都由我亲自完成，写完之后再让 AI 审查。不得不说，这种体验非常有成就感！

我做这个系列有两个原因：

• 它能帮助我加强 Go 技能。我很喜欢 Go，但它也是我使用最少的语言之一，同时又是一门非常重要的语言。

• 我希望帮助更多人理解分布式系统中的算法。我会尽可能用简单的方式实现它们，同时又不遗漏边界情况和故障模式。许多开发者其实一直在不知不觉中使用分布式系统，却不明白为什么他们看似简单的代码，会在别人多部署一个后端实例后立刻造成数据损坏。

每完成一个项目，我都会逐篇发布相关文章，记录整个过程中经历的每一层地狱和每一只“塔斯马尼亚恶魔”。除了脏话会有所过滤，其他内容一律不加掩饰。

经验无法下载

优秀的软件并不是从完美的代码中诞生的，而是从一次次熬过糟糕代码的经历中诞生的。

工程直觉来自犯错、失败的设计、凌晨两点的调试、那些本不该存在的边界情况，以及多年后仍让你耿耿于怀的取舍。最终的代码只是留下来的产物，真正的教育来自那些伤疤。

以 PostgreSQL 这样的系统为例，它代表了几十年积累下来的工程决策。

我之所以特别提到 Postgres，是因为我看到有人尝试借助 Agent，几乎完全使用 Rust 重写 Postgres。这并不是一件坏事。事实上，它正在极大地改进 Postgres：借助 Rust，它正从历史悠久的 process-per-connection 模型转向 thread-per-connection，带来了巨大的性能提升，也解决了 Postgres 长期以来的一些痛点。

你可以重写它，也可以复现它的行为。但你无法复现形成这些理解的整个历程——那些被修复的 bug、从性能问题中吸取的教训，以及迫使人们采用特定设计的种种约束。

如果让 Agent 编写一切，你得到的是最终产物，却没有留下那些伤疤。

而真正的专业能力，恰恰存在于这些伤疤之中。

你练习的能力会不断成长；你外包出去的能力则会逐渐衰退。

我把写代码外包了出去，于是我的编写能力开始萎缩。我在代码审查和架构方面变得更强，却失去了一些重要的东西。

现在，我会有意识地做出选择：分布式系统算法，用 Go，从零开始，由我亲自编写。

并不是因为我比 AI 更强，而是因为我在主动选择要锻炼哪些肌肉——这个选择很重要。

AI 并不坏。我每天都在使用它。说真的，我工作时依然会用它，因为与几年前相比，如今企业设定的截止期限已经达到了不切实际的程度。

代码审查依然是至关重要的工作。

AI 也依然是我的思考伙伴和力量倍增器。在做决策时，我仍会不时向它咨询。它帮助我成长，让我成为更好的开发者，也让我能更快做出决策——因为当身边没有其他人时，思考的不再只有我自己。

我真正想说的是：你必须有意识地决定，允许专业能力中的哪些部分发生改变。

每一种工具都会重新塑造工程师需要掌握的知识。我们的目标并不是永远保留手工敲代码这件事，而是确保那些你希望真正掌握的工程能力，仍然由你亲自练习。

如果你想保持编写代码的敏锐度，就必须挑选一部分代码，坚决不把它们外包出去。

因为专业能力永远追随着练习。

问题并不在于，没有 AI 时你是否还能编写代码。

真正的问题是：你还愿意写吗？

部分评论可能仅对已登录的访客可见。登录后即可查看全部评论。

如果需要采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。