编程不是艺术？程序员为何该像艺术家一样拒绝 AI

艺术家们明白 AI 对艺术有害。为什么程序员不明白我们也是艺术家？

创造性工作

编剧们罢工，以争取针对“AI”的保护。数千名艺术家签署公开信，抗议“AI”。创意产业团体针对 AI 提起的版权诉讼如此之多，以至于有一个专门的网站来记录它们。知名 YouTuber 绝对讨厌它。如果他们同时也是音乐人，那他们真的恨透了它。在所有创意产业中，都有一股协同一致的推动力在拒绝这项技术。

然而，在创意领域中几乎独一无二的是，许多经验丰富的程序员仍然坚信，将“AI”用于编程没什么问题。我们似乎确实讨厌它，它让我们所有人都痛苦不堪，也看到了它对我们的行业做了什么，但我们还是在用它。

这种认命态度的大量理由，似乎是因为编程不是艺术。如果这个工具能完成工作，而工作只是功能性的，那又有什么关系呢？

但这确实有关系。有关系，是因为我们不应该用 AI 来创作艺术，而编程就是艺术。

艺术可以是平凡的

有人会说，程序不能成为艺术，因为程序是功能性的，而不是表达性的。程序是平凡的，而艺术是超越性的。

这种看法建立在对艺术究竟是什么的扭曲理解之上。

在约翰·伯格的《观看之道》中，他把这类扭曲称为“神秘化”。他举的例子既有趣又极具说明性。我鼓励你把它完整读一遍。

不过，概括来说：伯格批评了一位艺术史学家描述一幅受委托创作的群像画时所用的华丽辞藻，包括“深沉、发光的黑色中微妙的调制”和“和谐的融合”之类的措辞。这幅肖像被用近乎狂喜的语言描述为崇高之作。

伯格揭示出，这幅肖像的现实是：一个贫穷的老画家需要接点活干，而一些官员大概觉得有幅官方肖像也不错。于是他们付给这个可怜的老人一些钱，他画了这幅画，然后他们就有了一幅画。这是一幅画得很好的群像，甚至很美。但它是为相当平凡的目的委托创作的作品，而且很好地满足了那个目的。它过去不是，现在也不是什么神圣的遗物。

在文化上，我们很容易把绘画、雕塑、电影和音乐神秘化。我们赋予它们“微妙的调制”。我们忽视它们的功能性方面——我们想要装饰、娱乐和消遣——而专注于它们的情感冲击。

别误会：我喜欢好的美学哲学。我认为，认真审视我们对艺术品的反应，并试图通过媒介分析更深入地理解我们的文化和自我，是很棒的。要说的话，我们真的需要做得更多。

这并不意味着这类作品的创作是神秘的，或者它应该比其他任何类型的劳动都更受尊崇。

尤其是那些与美术相邻、但在文化上不如美术受尊崇的其他劳动。我们倾向于把小说家的工作神秘化，却贬低记者的工作。实际上，记者那种功能性的文字同样重要，也同样值得尊重。

尽管他们可能远不及我们集体想象中小说家所栖身的空灵境界，但即便是记者，也比卑微的文案撰稿人获得更多尊重，因而也被赋予更多神秘色彩。然而，“小说家”与“文案撰稿人”之间并无先验的区分；许多技能是相同的，区别仅仅是商业与机遇的偶然产物。

事实上，许多著名作家都曾身兼这两种角色。这并非偶然！专业地与文字打交道，即便是（或许尤其是）平凡的文字，也是为在更纯粹的艺术语境中运用文字所做的绝佳练习，因为即便是平凡的创造力，也依然是艺术的。

代码可以是美的

一千个互联网年以前，当我还在十几岁末期时，我会把自己描述为一个“代码诗人”。我因此被无情地嘲笑，用今天年轻人的话说就是“令人尴尬”，而在当时则被称为“自命不凡”。

我屈服于同辈压力，把它从我的电子邮件签名和个人简介中删掉了。尽管我仍然坚信这种类比，但我接受了——至少在社会层面——将代码比作诗歌，或者比作艺术，是一件愚蠢的事。

然而，在我心中，我从未放弃这个想法。

我最广为人知的成就，即Deferred的发明，恰恰是对在RPC客户端/服务器应用中向每一个远程过程调用传递callback和errback参数这种乏味做法的美学反应。那两个回调函数完全能胜任工作。但它们丑陋，用起来令人厌烦。

Deferred是一首关于异步任务执行的有意为之的诗，刻意着眼于问题的美学以及使用它的体验。它之所以有影响力，正是因为它对美学的关注。

我不想夸大这一微小贡献的美感或深度，也不想夸大它的持久性。一首诗的存在并不意味着它是一首伟大的诗，仅仅意味着它是一首诗。

我们围绕程序的审美文化更像是民间史诗，而非高雅艺术，因此这一贡献的影响力，与其说在于其具体的持久力量，不如说在于它对后续事物的影响；从MochiKit.Async到JQuery Deferred，再到JavaScript Promises，最终到async/await；一长串不同的工匠各自添加了自己的东西，直到原作几乎完全消融。（而且我也不是这里的“原作”，因为我大量借鉴了E语言的Promises，以及其他东西。）

为了让代码成为一种刻意为之的艺术表达，一个人必须花费相当多的时间思考问题领域。如果没有经历过手动传递上千个回调参数的乏味，我既不会有技能，也不会有动力去费心创造这样的东西。

如今，大多数代码不必如此。大多数代码无法如此。大多数代码是功能性的、日常工作的代码。大多数代码无法让女士落泪。如果你愿意，它只是文案写作。

正如我之前所解释的，大多数写作也做不到这一点。大多数写作也只是文案写作。大多数视觉艺术是广告。大多数现场音乐表演是酒吧里基本被忽视的背景音乐。

然而，那些确实经过刻意美学设计的代码，往往在社会和技术上都很重要。

我们在软件领域确实有一些自我神秘化的传统。正如Abelson 那句令人难忘的话所说：“程序必须首先为人阅读而写，只是顺便为机器执行而写。”因此，我们长期以来一直认为程序具有高度的表达性，即使我们并不总能就它们表达的是什么、向谁表达达成一致。我们偶尔会就某个特定软件的哲学意涵大发诗兴。这也不局限于单个软件；不止一个社区曾沉溺于类似的哲学思辨。

软件的表达性和美学品质也不局限于阅读源代码或通过 API 与其他程序员交互。例如，每年 Federico Viticci 都会对 Apple 的新操作系统做一次评测，这（除了别的以外）也是一种美学批评。如果软件没有对其用户产生美学影响，这样的项目就不可能存在。

更不用说每一篇电子游戏评测同时也是一篇软件评测。

关于软件素养的简短插叙

让我有点难过的是，软件社区并没有多少批判性阅读的传统。文学化编程常被称赞，却很少被实践。

此外，让我难过的是，用户对软件是如何做出来的有着相当混乱的认识，编程素养相当低，而且现代编程实践常常刻意制造出关于软件在做什么的糟糕心智模型，让用户更难理解。软件的审美体验往往与其内部状态极度脱节。

虽然所有这些问题都早于 AI 数年甚至数十年，但这并不是热情地让它们变得更糟的理由。

捍卫平凡

如果我们用 AI 抹去所有文案写作、所有平面设计、所有无聊平凡的艺术，是的，还有所有无聊的定制 WordPress 主题开发，那么我们就会移除大量练习和沉思的实践机会，而人们正是需要这些来提升技艺、最终成就伟大之事。教育固然很好，但大部分真正的技能发展都发生在工作之中，历来如此。

这并不意味着我们不能使用抽象或自动化来让工作更轻松。编程是抽象的艺术，是理解如何将更小的想法组合成更大的想法，是如何通过理解自动化更小单元的规则并理解如何组合它们，来理解一个更大系统的自动化。

当我们用“AI”来消除这种理解，而不是把它提升到更高层次，去彻底摧毁那个创造性决策过程时，我们既伤害了作为程序员的自己，也伤害了我们的用户。我们就会像一位视觉艺术家用自动生成的填充内容代替自己的创作输出、从而辜负其观众，或一位音乐家用自动生成的填充内容代替自己的创作输出、从而辜负其听众那样，辜负我们的用户和下游的开发者同行。

垃圾就是垃圾，无论媒介是什么。

每个平凡的项目都有微小的机会——比如说，大约0.1%——成就伟大。如果我们用AI只做一个项目，那么当然，无所谓，那个项目几乎不可能成为为参与其中的工程师创造职业生涯决定性时刻的爆款。然而，如果我们习惯于用这种方式做所有项目，我们就把那些伟大时刻的总可能性从“肯定有时会有”变成了“永远不会有”。

以何种精确恰当的方式抵抗AI对所有软件开发的侵蚀，远远超出了这篇简短文章的范围。你能抵抗到什么程度，以及哪些具体用途你应该抵抗，取决于你自己。但在软件领域，它确实值得抵抗，就像在任何创意媒介中一样值得抵抗。

编程并不特殊。它只是艺术，而艺术是最具人性——因而也是最普遍——的存在。

致谢

感谢我的赞助人们支持我在这个博客上的写作。如果你喜欢在这里读到的内容，并且想读更多，或者你想支持我的各种开源事业，你可以作为赞助者支持我的工作！