AI 生成代码：看起来对≠真的对

几个月前，我注意到一件事，足以让我最终为此写一本书。

AI 编程工具现在确实很好了。Copilot、Claude、Cursor——你描述一个功能，几秒钟内就能看到可用的代码出现。这不是炒作，这是事实。但我一直在自己的工作中以及与其他开发者的交流中遇到同样的模式：在能生成代码和能判断这段代码是否真的好之间，存在着越来越大的鸿沟。

不是报错——报错很容易。它抛出错误，你注意到，然后修复。我指的是更隐蔽的失败模式：代码能运行、看起来合理，却在某个细微之处是错的——而这种错误只有在你已经理解"正确"应该是什么样的时候才能发现。一个没有索引的数据库列，在 10 条数据时没问题，在 10 万条时就会崩溃。一个授权检查在理想情况下工作正常，却在 null 值溜进来的瞬间悄悄泄露数据。一个组件有三份状态，其实一份就够。

AI 不会阻止你交付这些代码。它会愉快地生成它，信心满满，大约四秒钟。

所以当我坐下来写一本前端开发书的时候，我做了一个深思熟虑的决定，我认为这与目前大多数"AI 编程"内容的写法相反：在基础扎实之前，完全不用 AI。HTML、CSS、JavaScript、React、Next.js——手工构建，完全理解，犯错误、用慢速的方式调试。只有在这个基础存在之后，书才会引入 Copilot、Claude 和 Cursor——而且即使如此，框架也不是"教你如何提示 AI 完成一个应用"。而是"教你如何阅读 AI 给你的代码，并自己判断它到底对不对。"

我在写这本书时反复回到的那句话是：

先动手构建。理解你构建的东西。然后用 AI 更快地构建。

我不想让读者在读完这本书后想到"现在我知道怎么让 AI 帮我写东西了"。我希望他们在读完时想到的是"现在我理解了这些东西是怎么构建的，我可以使用 AI，而不会放弃我作为开发者的思考和判断能力。"

这本书的压轴项目是一个小应用——Recipe Box（食谱盒）——用三种不同的方式构建了三次：一次用纯 HTML/CSS/JS 手工完成，一次用 React，一次用 Next.js。看着同一个问题用三种不同的方式解决，最终比我预期的更好地教会了我东西。它让工具之间的差异变得明显，而不是抽象的概念。

我刚写完第二本书，继续用同一个项目延伸到后端——服务器、数据库、认证、真實部署——应用同样的规则。后端错误比前端错误更隐蔽，也更昂贵，所以如果"理解后再加速"有任何地方最重要，那就在后端最重要。

我真的很好奇这里的其他开发者是如何应对的。你是在以类似的先基础后 AI 的顺序教学或学习 AI 辅助开发，还是从第一天起就跟着基础知识一起学工具效果更好？我不认为现在有一个明显正确的答案——现在还足够早，我们都在公开地摸索。

如果有人想深入了解，我在两本系列书中更详细地写了这些——Frontend 和 Backend，每本从不同的技术层次讲述同样的理念。我很想知道这在每天都在经历这种矛盾的人心中反响如何。