编程并不特殊

创作

作家们正在罢工，要求针对“AI”获得保护。数千名艺术家签署公开信，抗议“AI”。创意产业团体针对 AI 提起的版权诉讼多到专门有一个网站来收录。知名 YouTuber 绝对讨厌它。如果他们同时还是音乐人，那他们更是恨透了它。在所有创意行业里，都有一股齐心协力拒绝这项技术的浪潮。

然而，在创意领域当中几乎独一无二的是，许多资深程序员仍然坚信，把“AI”用于编程没什么问题。我们似乎确实讨厌它，而它正让我们所有人痛苦不堪，也讨厌它对我们这个行业所做的一切，但我们还是在用它。

为这种认命找的借口，很多似乎都归结为：编程不是艺术。如果工具能把活干完，而这活本来就只是功能性的，那又有什么关系？

关系是有的。关系在于，我们不该用 AI 来创作艺术，而编程就是艺术。

艺术可以是平庸的

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

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

在 John Berger 的《观看之道》中，他把这类扭曲称为“神秘化”。他举的那个例子既好笑又能说明问题。建议你把它完整读一遍。

不过概括一下：Berger 批评了一位艺术史学家描述一幅受托绘制的群像画时所用的华丽辞藻，包括“深沉而灼热的黑色那微妙的层次变化”和“和谐的融合”之类的说法。这幅肖像被用近乎狂喜的措辞形容为崇高。

Berger 揭示出，这幅肖像的现实是：一个穷困的老画家需要接点活干，而某些官员大概觉得有幅官方肖像也不错。于是他们付了点钱给这个穷老头，他画了出来，然后他们有了一幅画。这是一幅画得不错的群像。甚至可以说很美。但它是为相当平庸的目的而受托完成的工作，并且很好地满足了那个目的。它过去不是、现在也不是什么神圣的遗物。

在文化上，我们习惯于把绘画、雕塑、电影和音乐神秘化。我们赋予它们“微妙的调制”，却无视它们的功能性——我们想要的是装饰、消遣和分心——而把注意力放在它们的情感冲击上。

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

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

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

尽管在我们集体的想象中，记者可能远远够不上小说家所栖居的空灵境界，但即便是记者，也比卑微的文案撰稿人获得更多尊重，因而也被更多地神秘化。然而，“小说家”和“文案撰稿人”之间并不存在什么超越性的区别；许多技能是相同的，区别不过是商业和机遇的偶然产物。

事实上，许多著名作家都曾同时身兼这两种角色。这不是偶然！以文字为业，即便是（或许尤其是）那些平淡无奇的文字，也是极好的练习，为的是在更纯粹的艺术语境中驾驭文字，因为即便是平淡无奇的创造力，也依然是艺术。

代码可以是美的

一千个互联网年以前，我快二十岁的时候，会把自己描述为一名“代码诗人”。我因此被无情地嘲笑，用今天年轻人的话说就是“很尬”，而当时则被称为“装”。

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

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

我最广为人知的东西——Deferred 的发明——恰恰是一种美学上的回应，针对的是在 RPC 客户端/服务器应用里，每一次远程过程调用都要传递 callback 和 errback 这两个参数所带来的乏味。那两个回调完全能把活干好。但它们丑，用起来烦。

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

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

我们围绕程序的美学文化更像民间史诗，而不是纯艺术，所以这个贡献的影响力，与其说在于它自身持久的生命力，不如说在于它对后来者的影响；从 MochiKit.Async 到 JQuery Deferred，到 JavaScript Promises，最终到 async/await；一长串不同的匠人各自添上一点自己的东西，直到最初的那个几乎完全消融。（而且我在这里也不是那个“最初”，因为我大量借鉴了 E 语言的 Promises，以及其他东西。）

要把代码变成一种有意为之的艺术表达，你必须花相当多的时间去琢磨问题域。如果没有经历过手动传递上千个回调参数的乏味，我既不会有那个本事，也不会有那个动力去费心造出这样一件东西。

当然，大多数代码不必是这样。大多数代码也没资格是这样。大多数代码是功能性的、工作日式的代码。大多数代码没法让一位女士落泪。如果你愿意的话，它只是文案写作。

正如我之前解释过的，大多数写作也做不到那一点。大多数写作也只是文案写作。大多数视觉艺术是广告。大多数现场音乐演出是酒吧里基本无人理会的背景音乐。

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

在软件领域，我们确实有一些自我神秘化的传统。正如 Abelson 那句令人难忘的话：“程序首先是写给人读的，只是顺便让机器执行。”所以，我们长期以来对程序有一种高度表达性的构想，尽管我们并不总能就它在表达什么、向谁表达达成一致。我们偶尔也会就某个软件的哲学意涵抒发一番诗意。这也不是某一个软件独有的现象；不止一个社区曾沉溺于类似的哲学思辨。

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

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

关于软件素养的一点题外话

让我有点难过的是，软件社区里几乎没有什么批判性阅读的传统。Literate Programming 常被称赞，却很少被实践。

更让我难过的是，用户对软件是怎么做出来的只有一团模糊的概念，编程素养相当低，而现代编程实践又常常刻意制造出关于软件在做什么的错误心智模型，让用户更难理解。软件的美学体验，往往与其内部状态严重脱节。

这些问题全都早于 AI 多年、甚至几十年就存在了，但这不是我们热情地把它们变得更糟的理由。

捍卫平凡

如果我们用 AI 抹掉所有文案写作、所有平面设计、所有无聊平凡的艺术，当然还有所有无聊的定制 WordPress 主题开发，那么我们也就抹掉了大量练习和沉思的实践机会——而人们正是靠这些才能把技艺提升到最终做出伟大作品的程度。教育很好，但真正的技能成长大多发生在工作之中，历来如此。

我们并不是说不能用抽象或自动化来让工作更轻松。编程本就是一门抽象的艺术——理解如何把小想法组合成大想法，理解如何通过掌握自动化小系统的规则、再把这些规则组合起来，从而理解一个更大系统的自动化。

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

垃圾就是垃圾，不分媒介。

每一个平凡的项目都有微小的机会——比如说，大约 0.1%——成就伟大。如果我们用 AI 只做一个项目，那无所谓，那个项目几乎不可能正好成为某位工程师职业生涯的决定性时刻。但如果我们养成习惯，所有项目都这么做，我们就等于把那些伟大时刻的总体概率从“有时确实会有”变成“永远不会有”。

要精确地说出该如何抵抗 AI 对软件开发各领域的侵蚀，远不是这篇短文所能容纳的。你能抵抗到什么程度、哪些具体用途该抵抗，由你自己决定。但在软件领域，抵抗确实值得，就像在任何创造性媒介中一样值得。

编程并不特殊。它只是艺术，而艺术是世上最人性的——因而也是最普遍的——东西。