开发者 Glyph：编程并不特殊，本质上仍是艺术

艺术家们明白 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都会对苹果的新操作系统做一篇评测，其中（除其他方面外）也包含美学批判。如果软件没有给用户带来美学上的影响，这样的项目就不可能存在。

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

关于软件素养的简短插话

软件社区里缺乏批判性阅读的传统，这确实让我有些难过。文学化编程经常受到赞扬，却鲜少付诸实践。

更让我难过的是，用户对软件的制作过程只有相当混乱的认知，编程素养普遍偏低，而且现代编程实践常常刻意营造出关于软件运行方式的错误心智模型，使用户更难以理解。软件的美学体验往往与其内部状态严重脱节。

尽管所有这些问题都比 AI 早出现了几年甚至几十年，但这并不能成为我们热情地让它们雪上加霜的理由。

为平凡辩护

如果我们用 AI 来抹去所有的文案撰写、所有的平面设计、所有无聊而平凡的艺术，以及——没错——所有无聊的定制 WordPress 主题开发，那我们便会移除人们提升技艺、最终成就伟业所必需的大量实践与沉思机会。教育固然好，但真正的技能发展大部分发生在工作中，历来如此。

这并不意味着我们不能使用抽象或自动化来让工作更轻松。编程正是抽象的艺术，是理解如何将较小的理念组合成更大的理念，也是理解如何通过掌握让较小系统自动化的规则并理解如何组合它们，从而把握较大系统的自动化。

当我们用"AI"来消除这种理解，而非将其提升到更高的层次，乃至彻底摧毁那种创造性决策过程时，我们既辜负了作为程序员的自己，也辜负了我们的用户。视觉艺术家若以自动生成的填充物代替自己的创作，便是辜负了观众；音乐家若如此，便是辜负了听众——我们对用户和下游同行开发者所做的事，本质上与此并无二致。

无论何种媒介，糟粕终归是糟粕。

每个平凡的项目都有那么一丁点可能性——姑且假设是 0.1% 左右——能够取得伟大的成就。如果我们只用 AI 做某一个项目，那么好吧，无所谓，那个项目几乎不可能成为某个工程师职业生涯中那个决定性的高光时刻。然而，如果我们将所有项目都养成那样做的习惯，那么这些高光时刻出现的总可能性就会从「偶尔会有」变成「绝无可能」。

精准恰当地抵抗 AI 对所有软件开发的侵蚀，其方法远远超出这篇短文的讨论范围。你能在多大程度上抵抗，以及应当具体抵抗哪些用途，取决于你自己。但值得抵抗的，在软件领域如此，在任何创造性领域也同样如此。

编程并不特殊。它只是艺术，而艺术是最贴近人性——因此也是最具普遍性——的事物。

致谢

感谢我的赞助者们对本博客创作的支持。如果你喜欢这里的内容，希望看到更多，或者愿意支持我的各类开源事业，可以通过赞助我的工作来支持我！