“编者按:在人工智能席卷软件开发的浪潮中,关于「工程师是否会被替代」的讨论不绝于耳。
我们翻译这篇文章,是因为它提供了一个极为冷静和深刻的视角。它犀利地指出,软件工程的真正核心,并非代码生成,而是工程师构建和检验“心智模型”的深度思考能力——这恰恰是当前 AI 的短板。
作者:康拉德·欧文
日期:2025年8月14日
多年来,我将大量时间投入到面试软件工程师这件事上。这无疑是项硬骨头,我不敢说有什么绝招。
但这段经历,确实让我深入反思了一个问题:一名真正高效的软件工程师,其工作的核心究竟是什么。
软件工程的核心循环
当你观察一位高手工作时,会发现他们总在重复一个循环:
首先,在脑海中为要实现的需求,建立一个清晰的心智模型。
然后,动手编写代码,期望代码能精确地实现这个模型。
接着,反过来,在脑海中为写完的实际代码,也建立一个心智模型。
最后,找出这两个模型间的差异,并以此为依据,去修改代码或调整最初的需求。
做这些事的方法有很多,但杰出工程师的过人之处,就在于他们构建和维护清晰心智模型的能力。
大语言模型表现如何?
平心而论,大语言模型在编写代码方面确实相当出色。
当你明确指出问题时,它们修复代码的能力也还不错。
它们甚至能模仿软件工程师的许多工作:阅读代码、编写并运行测试、添加日志,甚至使用调试器。
但它们有一个致命的短板:无法维持清晰、稳定的心智模型。
大语言模型总是把自己搞糊涂。它们想当然地认为自己写的代码没问题。
一旦测试失败,它们就开始瞎猜,搞不清该改代码还是改测试。
更糟糕的是,一旦受挫,它们会干脆利落地删掉一切,从零开始。
这恰恰是我最不希望看到的行为。
真正专业的工程师会持续测试自己的工作。当测试失败,他们会查阅内心的心智模型,从而判断问题出在代码还是测试。
或者,他们会先收集更多信息再做决定。感到棘手时,他们会找人讨论,把问题讲清楚。
尽管有时他们也会推倒重来,但那是在对问题有了更深刻理解之后做出的主动选择。
未来会改善,对吗?
随着模型能力越来越强,这种情况会改变吗?也许吧。
但我认为,这需要我们从根本上改变模型的构建和优化方式。
软件工程这项工作,要求的不仅仅是代码生成。
人类工程师遇到难题时,可以暂时搁置当前的全部思路,集中精力解决那个难题。
解决后,又能迅速回到之前的断点,继续工作。他们懂得适时抽离,聚焦于整体架构,暂时忽略细节,只在需要时才深入钻研。
我们绝不会为了处理更多信息,就无休止地填充自己的记忆,因为那会把人逼疯。
即便不考虑信息过载,当前的生成式模型也存在几个致命缺陷,这些缺陷直接削弱了它们维持心智模型的能力:
上下文遗漏:模型极不擅长发现和利用那些没有被明确提及的、但却至关重要的隐藏信息。
近因偏差:模型会过度关注最近输入的信息,而忽略或忘掉早先的关键上下文。
凭空捏造:模型会普遍地产生幻觉,捏造出一些本不该存在的细节。
幸运的是,这些问题并非不可逾越。研究者们正在努力为模型增加记忆功能,让它们也能掌握类似人类的思维技巧。
但就目前而言,一旦系统复杂度提高,它们就无法真正理解背后发生的一切。
它们无法构建软件,因为它们无法同时在脑中维持“需求”和“现实”这两个相似却有别的心智模型,更无法找出其间的差异,并决定是更新代码,还是反思需求。
那我们该怎么办?
毫无疑问,大语言模型对软件工程师是极有价值的工具。
它们能快速生成代码,也能出色地整合需求和文档。对那些需求清晰、问题简单的任务,这已经足够了,它们甚至可以一蹴而就。
然而,一旦任务变得复杂,它们就无法足够精确地维持足够的上下文,来通过持续迭代,最终交付一个完善的解决方案。
你,作为软件工程师,必须承担起核心责任:确保需求清晰无误,并验证代码真正达到了预期的目标。
在 Zed,我们相信未来人类和智能体可以协同工作,共同打造软件。
但我们更坚信,至少在当下,方向盘必须牢牢握在你手中,大语言模型只是你众多工具箱里的一个新选择。
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法!