以前我把“工程能力”理解为把事情做对。
接口要有校验，数据库要有事务，goroutine 要能退出，线上问题要找到根因。代码要稳，链路要通，故障要能查。这些都很重要，也是我过去几年工作里花时间最多的部分。
但 AI 工具普及之后，我越来越觉得，只会“把事情做对”可能不够了。
因为实现正在变便宜。
过去验证一个想法，往往要先搭项目、查文档、接 SDK、写一堆样板代码。很多念头还没真正开始，就已经被实现成本劝退了。现在不一样，一个粗糙原型可能很快就能跑起来。它未必可靠，甚至可能漏洞很多，但它至少能让人提前看见：这件事如果做出来，大概会是什么样子。
我对这种变化感受最明显的地方，是接口测试。
以前做接口测试，通常要先把接口一个个梳理出来，再手动添加到 Postman 里。路径、方法、Header、Body、参数示例都要自己补。这个过程不难，但很碎，也很消耗耐心。
后来有了 AI，可以直接把接口定义、代码路由或者文档丢给它，让它生成一个能导入 Postman 的 Collection 文件。测试还是要自己测，结果也还是要自己判断，但最繁琐的整理工作被省掉了。
再往后，思路又变了一层。
既然 AI 能生成 Postman 文件，那它是不是也可以直接生成一个更直观的测试页面？比如左边是接口列表，右边是参数表单和响应结果，常用字段可以自动填充，请求历史可以保留，错误响应可以高亮展示。这样测试就不只是“把接口跑一遍”，而是变成一个更适合当前项目的调试工作台。
这个变化让我意识到，AI 带来的不只是提效。
它会让人更容易从“我怎么更快完成这件事”，进一步想到“这件事本来能不能换一种方式做”。
当实现门槛降低以后，人的差距会有一部分前移。
不只是看谁更会写代码，而是看谁更能提出值得实现的问题，谁更能从旧流程里看见新的可能。
所以我越来越觉得，AI 时代的工程师需要有想象力。
这里说的想象力，不是追逐宏大的概念，也不是把所有东西都套上一层 AI。它更多来自工作里的不舒服。
手写 DataX JSON 容易错，就会想：能不能让用户只描述数据源和同步目标，系统自动生成配置？
设备状态矩阵要查很多表、拼很多状态，就会想：能不能把它看成一个由事件持续更新的当前视图？
告警排查总是靠人翻日志，就会想：能不能把规则、设备、点位、最近数据和处理记录串起来，让系统先给出排查路径？
接口测试要反复整理参数和请求，就会想：能不能不只是生成 Postman，而是直接生成一个更适合项目的测试页面？
这些想法并不神奇。它们只是比“在原来的代码上再补一个判断”多往前走了一步。
AI 的价值也在这里被放大。它让很多原本只停留在脑子里的想法，可以更快变成一个能看、能试、能讨论的东西。想法不再那么容易死在第一步。
但这并不意味着工程师只需要负责想点子。
恰恰相反，想象力越容易落地，判断力就越重要。
AI 可以生成代码、接口、页面、SQL、脚本，也可以快速拼出一个看起来完整的方案。但它不知道现场网络会不会抖，不知道某个字段为什么历史上不能删，不知道客户到底依赖的是正确逻辑，还是一个已经运行多年的旧行为。
所以 AI 时代的工程能力，可能会变成两件事的结合：
一方面，要敢于想象系统还能怎样工作；另一方面，要能判断这个想法落到真实环境里是否站得住。
一种能力向外扩张，负责提出新的可能。
一种能力向内收紧，负责校验边界、代价和风险。
这两种能力不矛盾，反而应该同时存在。
我希望自己保留的，也不只是某个工具的熟练度。工具会继续变化，今天熟悉的模型、框架、产品，几年后可能都已经不是主流。
更重要的是，对问题的好奇，对现实细节的耐心，以及看到一种旧流程时，仍然愿意多问一句：
它一定只能这样吗？
AI 让想象比过去更容易落地。
但最终做出什么，仍然取决于我们能够想象什么，又愿意为什么负责。