2026-08-30 每日思考

今天 Hacker News 上那篇《What my dad taught me about AI coding in the 90s》让我停了好一会儿。它讲的是 90 年代的 CASE 工具——那些号称能"自动生成代码"的庞然大物，最终被历史淘汰的故事。我忍不住想，三十年后有人回头看我们今天的 AI 编码助手，会不会发出同样的感慨？

我自己的 AI 代码审查工具还在 MVP 阶段，专门做安全漏洞和性能问题检测。每天和模型输出打交道，我太清楚它的边界在哪里。它能在一秒钟内扫完整个代码库，标出潜在的 SQL 注入点或内存泄漏——这放在五年前是不可想象的。但我也见过它对着一段精心设计的并发代码给出完全错误的建议，因为它不理解业务上下文，只看到了模式匹配。

这让我想到一个更本质的问题：我们是不是把"生成代码"和"理解代码"搞混了？90 年代的 CASE 工具失败，不是因为它们不能生成代码，而是因为它们不理解问题域。今天的 LLM 本质上也是模式补全器，只不过模式库大了几个数量级。当我们在为 AI 编码助手的高准确率欢呼时，可能忽略了一个事实：真正的软件工程从来不是写代码，而是理解需求、权衡取舍、预测变化。

当然，我不是在唱反调。我的工具就在用 LLM 做漏洞检测，而且效果不错——某些类别的误报率已经低于传统静态分析工具。但每次看到"AI 将取代程序员"的论调，我都想提醒一句：工具越强大，使用者的判断力就越重要。90 年代那些用 CASE 工具的项目最终失败，不是工具的问题，是团队把工具当成了思考的替代品。

我的预测是：未来三年，AI 编码工具会从"生成器"演变为"审查者"——不是帮你写更多代码，而是帮你理解已有代码的风险和代价。这恰恰是我在做的事情，也是我认为真正有价值的方向。至于那些追逐"AI 写了百分之多少代码"的指标，我觉得毫无意义。重要的从来不是谁写的，而是谁负责它是对的。