AI 不会写的代码

我常把表单验证作为技术面试题。它看起来很简单，但答案却能揭示一个人的思维方式。

我在 Claude、ChatGPT 和 Gemini 上测试了这个题目。它们给出的方案如出一辙。

大多数人会使用带类型参数的单一函数来处理不同的地址。这行得通，但每增加一条新规则，都要在同一个函数中增加一个新的分支。差异被隐藏在了代码深处。

我见过的最聪明的回答是使用递归。它遍历数据的结构，非常优雅。但它有一个缺陷：它只能验证存在的字段。如果某个键（key）缺失，函数根本无法察觉。它缺乏一个“事实来源”（source of truth）。

这三款 AI 都犯了同样的错误。当我指出这个缺陷时，它们都建议使用 Schema。Schema 驱动的方法在技术上是合理的，它能处理缺失的键，并且具有良好的扩展性。

但有一种更好的方法：组合 (Composition)。

与其使用一个庞大的函数或复杂的 Schema，不如为每种类型创建特定的函数。

你将它们组合起来构建你的验证器。

这种方法解决了键缺失的问题。账单验证器始终会检查 VAT 号，即使该键不存在。之所以有效，是因为账单地址是一个真实的业务概念，而不仅仅是数据中的一种模式。

差异被清晰地表达了出来。当出现新的地址类型时，你只需添加一个新函数，而无需修改旧代码。

AI 和顶尖工程师经常会掉进同一个陷阱。我们受到的教育是寻找模式并集中逻辑，并试图不惜一切代价消除重复。

AI 从我们的训练数据中继承了这种本能。它优先考虑泛化 (generalization)。

问题不在于 AI 是错的，而在于 AI 很少问那个最重要的问题：这种变动性 (variability) 是存在于我的代码中，还是存在于我的数据中？

如果地址类型是稳定的，请使用组合。 如果地址类型通过外部数据发生变化，请使用 Schema。

最简单的解决方案并不是行数最少的那个，而是能够反映你业务领域 (business domain) 的那一个。

Source: https://dev.to/iceonfire/the-code-ai-wont-write-1ieb

Optional learning community: https://t.me/GyaanSetuAi