AI 时代需要有想象力

我在很长一段时间里，把“工程能力”理解为把事情做对。

接口要有校验，数据库要有事务，goroutine 要能退出，线上问题要找到根因。它们都很重要，也是我过去几年工作里花时间最多的部分。

AI 工具普及之后，我慢慢感觉到，只有“把事情做对”可能还不够。

因为实现正在变便宜。

过去为了验证一个想法，可能要先搭项目、查 SDK、写一批样板代码，很多念头在真正开始前就放弃了。现在可以在很短时间里得到一个粗糙原型。原型不一定可靠，但它足以让人看见：这件事做出来大概是什么样子。

当实现门槛降低以后，人的差距有一部分会前移到更早的地方：

你有没有想到另一种可能？

想象力并不等于追逐宏大的概念。对我来说，它常常来自工作里的不舒服。

手写 DataX JSON 很容易错，于是会想，能不能让用户只描述同步目标，系统负责生成配置。

一张设备矩阵需要查询很多地方，于是会想，能不能把它看成由事件持续更新的当前视图。

多个 PLC 共享设备导致删除异常，于是会想，页面虽然画的是树，数据是不是早已变成图。

这些想法都不神奇。它们只是比“在原来的代码上再补一个判断”多往前走了一步。

AI 会奖励问题，也会放大问题

如果问题定义清楚，AI 可以帮忙搜索仓库、生成原型、补充测试、比较方案。一个人能够尝试的方向明显变多了。

如果问题本身含糊，它也可以迅速制造大量无用代码。代码甚至可以编译，目录也很整齐，但系统并没有因此更接近真正目标。

这让我越来越在意提问之前的工作：

AI 没有让思考变得不重要。恰恰相反，它缩短了从想法到实现的距离，因此一个模糊想法也能更快地变成昂贵的错误。

想象力如果没有工程能力，会停在演示里。

设备会离线，消息会重复，数据库会迁移失败，用户会在任务执行一半时关闭页面，模型也会自信地给出错误答案。最终仍然需要有人定义状态、处理异常、设置权限并验证结果。

我不认为 AI 时代的工程师会变成只负责“想点子”的人。更可能的情况是，我们一边需要更大胆地想象系统还可以怎样工作，一边需要更严格地判断生成结果是否可信。

这两种能力看起来相反：一种向外扩张，一种向内收紧。

但它们应该同时存在。

工具会继续变化。今天熟悉的模型和产品，几年后可能已经不是主流。具体语法、框架甚至编程方式都会被重新包装。

我希望自己保留的，不只是使用某个工具的熟练度。

还有对问题的好奇，对现实细节的耐心，以及看到一种旧流程时，仍然愿意问一句：

它一定只能这样吗？

技术让想象比过去更容易落地。

而我们最终做出什么，仍然取决于能够想象什么，又愿意为什么负责。