AI 时代的软件工程

原文：Software Engineering in the Age of AI

AI 翻译仅供学习参考，点击文末可阅读原文。

太长不读

一句话总结：AI 虽然能高效生成代码，但它正在将软件工程从一项充满创造力和「心流」的活动，剥削成令人疲惫且被动的机器代码审核工作，长此以往可能导致人类核心工程能力的丧失。

• • 传统的软件工程是一项深度思考的创造性工作，能够给开发者带来沉浸式的「心流」体验。
• • 在 AI 时代，开发者变成了 AI 生成代码的「编辑」和「审核员」，工作内容从主动创造变成了被动挑错，成就感大幅降低。
• • 就像美国海军为保留造船技艺而坚持造舰一样，过度依赖 AI 可能会阻断初级开发者的成长路径，导致未来无人能处理极其复杂的系统级工程难题。
• • 即使编程的创造力被剥夺，我们仍应在业余时间保护自己的大脑，将精力投入到写作等能够激发人类想象力和心流的活动中。

以下为原文的全文翻译：

如果你还不了解我，当我不写小说的时候，我的日常身份是一名词代码的软件工程师。如今的软件行业已经严重依赖人工智能（AI）。因为它学习了数万亿行的开源代码，因为写代码本身就是在解决有明确对错的测试问题，更因为代码从一开始就是为了让计算机理解而设计的结构化语言，AI 已经变得非常擅长写代码了。

在程序员开始使用 AI 之前，典型的工作流是这样的：

1. 1. 有人要求你为现有的程序添加一个新功能（Feature）。
2. 2. 你写下一份关于这个功能的正式定义，描述它应该（和不应该）做什么，用户如何访问它，以及如何测试它是否正常运行。
3. 3. 你花时间研究哪些数据结构、算法、代码库和外部服务最适合实现这个功能。
4. 4. 你开始写代码来构建新功能，编写测试用例以确保它符合预期，并编写文档告诉用户如何使用，同时告诉其他工程师在维护和 Debug 时需要了解哪些信息。
5. 5. 你创建一个「Pull Request（PR）」，邀请团队里的其他工程师来审查（Review）和评论你的新代码，并最终批准将其合并到产品中。

现在，既然 AI 已经能够稳定输出相当不错的代码，软件开发者的工作流变成了这样：

1. 1. 你写一段提示词（Prompt），让 AI 来创建这个新功能。
2. 2. 你 Review AI 写的代码，根据自己的判断进行修改，或者让 AI Agent 代劳。
3. 3. 你要么自己把新代码合并到现有的代码库中，要么创建一个 PR 让别人来 Review 并合并它。

在过去的工作流中，创造过程主要发生在你自己的大脑里。在新的流程中，你变成了主管，监督着 AI 内部运作机制中展开的「创造过程」。你确实花了一些心思去推敲一段简明、周密且准确的 Prompt，好让 AI 开始干活，但你并没有像亲自写代码时那样进行深度思考（Hard thinking）。当你收到 AI 返回的代码时，你本质上是在扮演一个「编辑」的角色。因为，尽管 AI 会写代码，但它无法像你一样始终纵观项目的全局（Big picture），而你需要确保这段新代码不会捅娄子。

AI 并不知道它刚刚添加的代码是否违反了你的产品必须遵守的某些法律合规要求。它不知道它向外部系统发出的请求需要 10 毫秒还是 10 分钟才能完成。它不知道这段代码的行为是否会与你队友三周后准备上线的新功能产生冲突。它更不知道它刚写的函数，在与你上个月写的那个处理敏感信息的函数交互时，是否会引入新的安全漏洞。

但一位资深开发者（Senior developer）知道这些。这就是为什么他们需要对那些表面上看起来「能跑（Just work）」的 AI 代码进行审查，并经常加以修正。在资深开发者眼里，AI 就像是一个能力不错、干活很快的初中级开发人员：只要指导得当，它大多能交出靠谱的代码，但它缺乏团队的制度化知识（Institutional knowledge），也缺乏你过去二十年积累下来的深厚广博的系统级认知。

现在，让我们退一步打个比方。假设你是一位历史小说家。你的工作流是什么样的？可能类似于这样：

1. 1. 你脑海中浮现出一个场景：1760 年，两位政治家在伦敦圣保罗大教堂外发生争执。你开始思考如果要准确地写好这场戏，你需要了解哪些细节，包括服装、街道氛围以及当时的政治局势。
2. 2. 你翻开几本参考书，开始针对以下问题做笔记：
1. 1. 根据他们的社会经济地位和角色，你的角色会穿什么样的衣服？
2. 2. 街上还有谁和他们在一起？小贩？赶马车的车夫？他们长什么样？那个时间点扫烟囱的人出来了吗？性工作者和执法官呢？
3. 3. 你的角色争论的主要政治人物是谁？他们目前的立场是什么？
4. 4. 最近几周或几个月有哪些相关的历史事件？它们将如何影响你角色之间的争论？
3. 3. 你回到写作中，将这些历史事实编织进你用想象力构建的场景里。

小说家和软件开发者在这里有很多共通之处。现实中，小说家在动笔之前往往已经做了大量的历史调研；同样，软件开发者凭借多年的经验，在准备写新功能时，大脑里就已经知道哪些数据结构、算法、缓存以及数据库类型是最合适的。

这两种职业的共同点在于：他们对自己正在创造的内容都有一种强烈的「参与感」。他们完全沉浸在自己的工作中，以至于经常忘记时间。无论是在写小说还是写代码，我和我的许多同行都经常经历这样的时刻：看一眼表，一头扎进问题里，等感觉只过了「十分钟」再看表时，发现四个小时已经过去了。

这就是心理学家米哈里·契克森米哈赖（Mihaly Csikszentmihalyi）在他 1990 年的畅销书《心流》（Flow）中所描述的「最优体验（Optimal experience）」状态。当时间和环境允许时，作家、软件开发者、画家、音乐家以及所有其他创意工作者都会进入这种状态。很多软件工程师之所以喜欢在下班后回家继续写代码，恰恰是因为非工作时间没有会议和杂事的打扰，能让他们顺利进入心流。

现在，让我们把这位历史小说家放在软件开发者的位置上。她接到出版商的电话，说他们找到了一种方法，能让她每年出版四本书，而不是之前的两年憋出一本。他们招募了一批顶尖的高中生和大学生，每个人每天都能以极低的成本量产出五页质量还算过关的文章。出版商希望这些历史小说能保持原作者的卓越水准，或者至少相差不远，因此他们决定留用她，不过是作为一名「编辑」。

小说家现在的工作变成了去修改这群学生的作业。每个学生都得到了经过精心编排的 Prompt 指令，只要稍微费点心思，他们写的书页就能被拼凑成连贯的章节。

任何批改过高中生或大学生作业的人都知道，这通常不是一份有成就感的工作。如果你曾经不得不在一周内批改一百份试卷，你就知道那是怎样一种折磨。

这位小说家，就像现在的软件工程师一样，不再深深地参与到她的作品中。编辑不是创造。你不再把自己的身心交给想象力。你不再将自己的思想和情感沉浸在发明创造的过程中。相反，你在做的只是纠错排雷——试图清理笨拙的措辞和多余的描述。心流状态消失了。你现在只是一个庞大流程中的一个齿轮，而这个流程根本不关心你的创造力，也不在乎你是否需要锻炼这种能力。

更糟糕的是——在审阅了几个月的 AI 生成代码后，我对此有深切的体会——你的技能正在断崖式下降。当一个新问题出现时——比如需要实现一个新功能，或者修复一个棘手的 Bug——如果还要我自己花上好几个小时去死磕，我甚至会觉得这是一种耻辱。既然 Claude 可以在五分钟内定位 Bug 并开始起草修复方案，我凭什么还要自己去扒那些屎山代码？

是啊，凭什么呢？既然机器人可以代劳，为什么你我还要把脑力投资在我们曾经真心喜欢、现在却感觉像是一件苦差事的事情上？

和 AI 一起工作了几个月后，我明显变得更懒、更笨了，至少在写代码这件事上是这样。（我写作时从不用 AI，原因很简单：写作本身就是整理和澄清我自己思想的行为。让机器人替我写字，就像是花钱雇别人替我健身，还指望自己能练出腹肌一样荒谬。）

我在工作中也变得更加不耐烦，尤其是当我收到同事发来的、明显是 AI 代写的邮件时。这些邮件经常还附带一些同样是 AI 写的长篇文档让我 Review。这总让我忍不住想吐槽：「既然你都懒得自己写，我凭什么要浪费时间读？」

我确实也会用 AI 来回答一些基础问题。想知道亚马逊的托管数据库与微软和 Digital Ocean 的产品相比如何？Claude 的聊天机器人是一个快速获取高层级概览的好帮手。了解大概后，你可以再去找源头资料深入细节。

但我认为，从长远来看，创意工作者选择将自己最具想象力、最能产生心流的思考过程拱手让给一群机器人，将是一个严重的错误。这些 AI 机器人的所有知识都来源于我们——来源于我们的代码、白皮书、诗歌、小说、新闻报道、传记，以及成千上万的人花了数十年时间，用辛勤汗水换来的 Stack Overflow 回答。

机器人们吞噬了所有这些曾经免费的数据，现在又把它们打包卖回给我们。不再有人去 Stack Overflow 上回答问题了，因为大家都把问题抛给了 Claude 和 ChatGPT。像 Stack Overflow 这样免费使用的服务里曾经沉淀的公共知识正在干涸，这也让 AI 机器人在回答未来的技术问题时，可供喂养的语料越来越少。

软件公司解雇了所有的初级开发人员，因为 AI 机器人更便宜，前提是你还得留着技术高超的资深开发人员来管理它们。但是，如果没有初级开发人员在人才梯队里「吃苦头」去学习如何解决那些真正复杂、宽泛且具有深度的问题（这类问题的范围往往太大，AI 根本处理不了），那么明天的资深开发人员将从何而来？五年后，谁还有资格来管理这些机器人？

我所说的这种复杂、宽泛且具有深度的问题，体量大到根本塞不进 AI 的「上下文窗口（Context windows）」。你现在无法，未来可能也永远无法将以下所有信息喂给 AI 并指望它完全理解：你的产品在一百个不同国家必须遵守的每一条法律法规、你的产品需要交互的每个相关代码库中的细微差别，以及构成你产品的数百万行代码中嵌入的每一条商业规则。一个由开发者和管理者组成的团队可以理解并应用这些合规要求和制度化知识。这当然需要付出艰苦的努力，成本高昂。处理复杂性总是如此。

但是，如果我们把所有这些工作都推给机器人，会发生什么？将来还有谁能具备足够的知识，去验证机器人干出来的活儿到底是对是错？

几年前，我读过一篇文章（现在已经找不到了）^[1]，讲的是美国海军如何说服国会拨款建造一艘海军当时并不急需的航空母舰。「我们为什么要为这个买单？」参议员和众议员们质问。

海军回答说：「因为建造航空母舰所需的技能是经过几十年的艰苦摸索才掌握的，如果我们现在不造一艘，十年后我们可能就会彻底忘记该怎么造了。」

海军希望那些老手——那些曾经建造出其他国家无法匹敌的世界级战舰的工程师和工匠们——能把建造地球上独一无二巨舰的技能传承给年轻一代。而实现这一目标的唯一途径，就是真正去动手实践，让整个团队完整地经历设计和组装这艘舰艇的每一个步骤。

国会最终为这个项目拨了款，因为尽管我们总是抱怨他们效率低下、党派争吵不断、总体上碌碌无为，但他们确实比我们的大多数企业更有远见。他们没有盯着下个季度的财报，而是把目光投向了几十年后的未来。

软件行业的公司，从超级巨头到初创企业，都在把创造性的工作推给机器人，因为短期回报极其丰厚。既然可以在 Claude 或 Codex 的帮助下雇四个人每年量产十个产品，为什么还要花钱养十个开发者每年只憋出一个产品？

在管理者和投资者眼中，这显然是双赢。但命运的账单很快就会寄来。维护数百万行代码的成本是极其高昂的，尤其是当根本没有人真正理解这些代码（因为没人真的亲手写过）时。修复 Bug、添加新功能以及将新技术整合到现有的代码中，这都是苦差事。将来这些活儿也都会丢给机器人。长此以往，我们的社会将不可避免地依赖于那些非人类创造、且人类根本无法理解的系统。

至于我，一个曾经为了进入创造性心流状态而每天努力挤出大段不受打扰时间的开发者，现在觉得软件开发的过程再也无法带来曾经的那种成就感了。我不再深深沉浸在工作中。我不再像过去那样在工作中学习成长。我对待机器人给出的代码建议和 PR，就像大多数人机械地回复电子邮件和 Slack 消息一样。我的工作变成了「被动响应（React）」，而不是「主动创造（Create）」。

随着我在软件工程领域的职业生涯逐渐步入尾声，我想起了 20 世纪中叶的那些手工艺人——那些眼睁睁看着塑料制造业的兴起如何无情地击溃他们饭碗的木匠和铁匠们。他们遭遇了不可逆转的打击。确实，那些工匠们亲手制作的玩具、工具和乐器，蕴含着流水线上的塑料模型永远无法企及的专注与心血。但这又怎样呢？对大众来说，一个「足够好用」的塑料玩具就够了。即使它半年后就坏了，也没关系，因为它便宜到你随时可以再买一个。

而那数以百万计的塑料废品，如今正在污染着我们的海洋。「太平洋垃圾带」的面积现在已经是法国的三倍大了^[2]。

这正是我们互联网的现状与未来。AI 在处理一些确实有用的工作的同时，每天也在源源不断地量产着数字世界里的「百万吨级塑料垃圾」。

虽然计算机编程曾经是一项充满创造力的事业，但如今它已经沦为一项「看管机器人」的差事。但请记住，在你的业余时间里，你的大脑依然是自由的，你可以把它的能量倾注到任何你喜欢的事情上。我依然尽可能多地写作，每次从那种心流状态中苏醒过来，我都感觉自己从大脑的深处带回了一些新的东西。那些曾经只是一闪而过的模糊念头，现在变得更加清晰可见。每一次的表达，都是一次向上攀登的阶梯，让我触及到那些如果缺乏写作实践、我根本无法准确表达甚至从未触及的思想境界。

在选择如何分配你的时间时，请做出明智的抉择。你家书房里的书多到你一辈子都读不完。你的朋友和家人们拥有机器人永远无法理解的心思与渴望。而你的大脑，一旦屏蔽掉这个喧嚣世界的噪音，依然具备无尽的想象力、创造力，依然能奔涌出美妙的心流。

去找到它吧！

References

[1] 海军因技能退化而流失关键工程技术能力的问题:https://www.defensenews.com/opinion/2024/11/08/the-us-navy-is-at-risk-of-losing-vital-shipbuilding-skills/

[2] 太平洋垃圾带: https://en.wikipedia.org/wiki/Great_Pacific_Garbage_Patch