AI 时代工程师角色和工作方式转变思考

人的「meraki」与自动化速度之争

我曾犹豫要不要写下这些。

不是因为我对软件工程中的 AI 没有看法，而是因为，有时想围绕这个话题展开细致、深入的讨论，似乎正变得越来越困难。

我曾在一个将“AI native”视为自身身份认同一部分的环境中工作。当一项技术成为公司身份认同的一部分时，质疑它甚至会让人感到不适。讨论很快就会从“它能在哪里创造价值？”变成“我们怎样才能把 AI 塞进所有地方？”

但我认为，我们需要更多坦诚的讨论。

AI 很强大，这一点毋庸置疑。

它能帮助我更快地编写代码，帮助我探索代码库中不熟悉的部分，也能减少重复性工作，加速实验过程。

但有一件重要的事，我们不应该忘记：

速度并不等同于进步。

并非所有事情都需要 AI

事实是，并非每个问题都需要人工智能。

并非每家企业都需要 AI，并非每款产品都需要 AI 功能，也并非每次交互都需要被优化或自动化。

尤其是在那些以人为核心的行业中。

以酒店与服务业为例，其本质在于人与人之间的连接。一个人最终记住的，往往不是幕后那套自动化流程，而是那个真正关心他、留意到他的需求、向他伸出援手，并愿意多做一步的人。

我很喜欢一个希腊词：meraki。

它意味着把自己的一部分倾注到所做的事情中，带着热爱、创造力与用心去完成一件事。

我认为，这一理念对于软件工程正变得越来越重要。

代码背后的匠心

当你真正关心自己的工作时，你不会只想着消除其中每一个令人不便的部分。

恰恰是在困难之中，你才会成长。

阅读令人困惑的代码，调试生产环境中的诡异问题，接受队友的反馈，讨论架构，犯错并从中吸取教训。

正是这些经历塑造了工程直觉。

过去几年，软件工程发生了翻天覆地的变化。AI 辅助开发正在成为我们日常工作流的一部分，我也相信它蕴含着巨大的价值。

但 AI 今天之所以能让我变得更优秀，是因为早在它出现之前，我就已经学习了那些基础知识。

我学习过系统如何运行，学习过在没有现成答案自动生成给我的情况下如何调试，学习过如何质疑解决方案，而不是盲目接受。我通过反馈、协作以及多年来解决问题的经历不断成长。

AI 能够放大已有的知识，却无法凭空创造工程判断力。

当我们把思考外包出去，会发生什么？

我担心的事情之一，其实并不是 AI 本身。

而是我们可能抵挡不住诱惑，把工程中那些真正让我们成为工程师的部分外包出去。

探索架构，展开技术讨论，理解各种权衡，质疑既有假设，共同设计解决方案。

公司并不只是一台把需求转化为代码的机器。

公司是由一群拥有不同经历、视角和专业能力的人组成的。最好的解决方案，通常诞生于交流、分歧与协作之中。

如果我们把所有探索工作和架构决策都交给 Agent，团队的集体智慧会发生什么变化？

那些不再培养直觉的工程师又会怎样——因为他们从未不得不经历挣扎？

如果人们从未深入理解自己正在解决的问题，那么他们创造出来的产品又会变成什么样？

我们或许会变得极其擅长高效生产软件，却没有任何人真正与这些软件产生连接。

构建有意义的软件

我怀念那种亲手构建有意义之物的感觉。

我怀念对架构决策提出挑战，怀念深入的技术讨论，也怀念与一群真正关心结果的人共同解决难题时的兴奋。

因为最好的软件，并不是由那个打字最快、写下最多代码的人创造出来的。

它来自这样一群人：他们理解问题、关心用户，并把自己的经验融入每一个决策之中。

我热爱构建有用的产品。我喜欢看到客户因为我们创造的东西解决了真实问题而感到开心。我热爱软件工程，因为它是一门手艺。

AI 可以帮助我们更快地创造，帮助我们探索更多可能，也可以减少过程中的阻力。

但我们必须谨慎，不要把那些让软件构建变得有意义的东西一并消除。

工程的未来不应该是人类与 AI 之间的对抗。

它应该是人类使用 AI，同时守护好奇心、匠心与主人翁意识。

因为一旦失去这些，我们就不再是在构建软件，而只是在生成输出。

感谢你读完这些凌乱的想法。今天，我因为公司希望成为 AI native 而被裁员，所以我觉得，现在正适合向一群素未谋面的陌生人分享我对未来的担忧。

部分评论可能只有登录后的访客才能看到。登录后即可查看全部评论。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。