艺术家明白 AI 有害艺术，为何程序员不明白我们也是艺术家？编剧罢工争取针对 AI 的保护，数千艺术家签署公开信抗议 AI，创意产业对 AI 的版权诉讼多到有专门网站。知名优兔（YouTube）创作者很厌恶它，若还是音乐人更痛恨。创意行业合力抵制该技术，但程序员几乎例外：许多资深程序员仍认为用 AI 编程没问题；我们似乎也讨厌它，它让人痛苦、冲击行业，却仍用它。

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

创意工作

编剧曾罢工，以争取针对“AI”的保护。数千名艺术家签署公开信，抗议“AI”。创意产业团体针对 AI 提起的版权诉讼如此之多，以至于有一个专门的网站来汇总。热门 YouTuber 绝对憎恨它；如果他们同时也是音乐人，那就更是恨之入骨。在所有创意产业中，都出现了拒绝这项技术的协同行动。

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

这种听之任之的理由，多半是认为编程不是艺术。如果工具能完成任务，而任务又只是功能性的，那又有什么关系呢？

但这很重要。重要的是，我们不应该用 AI 来生产艺术，而编程就是艺术。

艺术也可以是平凡的

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

这基于对艺术究竟是什么的扭曲理解。

在约翰·伯格（John Berger）的《观看之道》（“Ways of Seeing”）中，他把这种扭曲称为“神秘化”。他举的例子既有趣又有说明性，建议大家去读全文。

简单说：伯格批评了一位艺术史学家描述一幅受委托创作的团体肖像时所用的华丽辞藻，比如“深沉、发光的黑色中微妙的层次变化”和“和谐的融合”。那幅肖像被形容得近乎令人陶醉，非常崇高。

但伯格揭示，这幅肖像的真相是：一个贫穷的老画家需要接活，一些官员可能觉得有幅官方肖像不错。于是他们付钱给这个可怜的老人，他画了，然后他们就有了一幅画。这是一幅执行得很好的一群人的肖像，甚至可以说美。但它只是为相当平凡的目的而委托的工作，并且恰好适合那个目的。它不是，也从来不是神圣的遗物。

在文化上，我们倾向于把绘画、雕塑、电影和音乐神秘化。我们给它们注入“微妙的层次变化”。我们忽略它们的功能性——我们想要装饰、娱乐和消遣——只关注它们的情感冲击。

别误会：我其实很喜欢好的美学哲学。认真审视我们对艺术作品的反应，并通过媒介分析来更深入地理解文化与自我，这非常棒；如果说有什么不足，那就是我们还需要做得更多。

但这并不意味着这类作品的创作是神秘的，或者应该被尊崇到高于任何其他劳动的地位。

更不用说那些与纯艺术相邻、却没有被同等文化尊崇的其他劳动了。我们倾向于把小说家的工作神秘化，却贬低记者的工作。实际上，记者那种功能性的写作同样重要，也值得同样的尊重。

尽管在集体想象中，记者所处的领域远低于小说家那缥缈的国度，但即便是记者，也比卑微的文案撰稿人获得更多尊重，因而也被更多神秘化。然而，“小说家”和“文案撰稿人”之间并没有超验的界限；许多技能是相同的，区别只是商业和机会造成的偶然。

事实上，许多著名作家都曾众所周知地身兼这两种角色。这不是偶然！职业性地与文字打交道，即便是（也许尤其是）平凡的文字，也是在更纯粹艺术语境下与文字打交道的绝佳练习，因为即便平凡的创造力仍然是艺术性的。

代码可以是美的

一千个互联网年前，在我十八九岁的时候，我会把自己称作“代码诗人”。我当时因此被没完没了地嘲笑，用今天年轻人的话说是“尬”，在当时则被称为“装模作样”。

我屈服于同辈压力，把它从邮件签名和简介里去掉了。虽然我仍然强烈相信其中的相似之处，但我接受了——至少在社交层面——把代码比作诗歌、甚至比作艺术，是件傻事。

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

我最为人所知的事情，即 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 的侵蚀，远远超出了这篇短文的篇幅。你能抵制多少、应该抵制哪些具体用途，取决于你自己。但在软件领域，这确实值得抵制，就像在任何创意媒介中值得抵制一样。

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

这场讨论迅速陷入对立：核心分歧是编程到底只是一种产出结果的工业/工程活动，还是带有作者意图的艺术或工艺，以及 AI 生成代码是否摧毁了这种意图。此外，不少人不满原文被 flag，觉得话题已经像政治口水一样令人疲惫。

认为编程是工业/工程活动，绝大多数代码不是艺术

• 编程的目的是交付价值和利润，不是表达自我；用户和公司只在意程序结果，不在意代码是否优雅，更不会把代码当展品。日常企业开发更接近会计或做香肠，只要正确、可读、可维护，代码由人写还是 LLM 写并不重要。（较多人）
• 多数代码就像多数插画，只是谋利或解决问题的手段；只有 demoscene、Advent of Code 或纯粹为乐趣而写的小众代码才可能算艺术。（较多人）
• 自动化本来就是开发者的宿命：消灭重复劳动、让自己被淘汰；若 AI 能更省时省资源地产出可用程序就该采用，人类则退居为操控者，未来甚至会出现指挥 AI 的新角色。（较多人）
• 也有人反驳原文的推论：不能因为程序员也拿钱做事，就跳到“编程和音乐绘画一样是艺术”；为钱工作并不自动把工程变成艺术。（少数人） > 编程是工业流程，不是艺术形式；十年后“程序员”会像“计算机”一词在 1940 年代后的演变一样，用来指机器和机械过程，而不是人。（@bitwize）

认为编程可以是艺术，但只属于窄众场景且需要训练才能欣赏

• 编程确实能带来美学体验：类型系统把可能的运行时事故挡在编译期、把一百行代码缩成十行、初学 Haskell 时的震撼，都让作者觉得代码接近艺术；但这种美不像音乐或绘画那样直观，必须经过刻意训练才能体会。（少数人）
• 编程可以像数学一样被视为“逻辑观念的诗歌”，只是对外行而言像天书；优雅解法能被程序员欣赏，却很难像艺术品那样被大众直接感受。（少数人）
• 代码是否算艺术要看场景：日常上班写业务代码几乎不可能是艺术，但 demoscene 作品、为乐趣而写的个人项目，或为练习而做的 Advent of Code，才更接近艺术。（少数人）

认为编程只是媒介，是否成为艺术取决于使用者

• 同一个媒介既能写诗也能写枯燥手册：是否被当作艺术，取决于使用者是想表达观念，还是只想解决问题。（少数人） > 对艺术家，编程是黏土；对工程师，编程是建材；纸笔可以写诗，也可以写枯燥的手册，媒介不自动等于艺术。（@sausagefeet）

认为 AI 让代码失去可辨识的作者意图，因而不再是艺术

• 在 AI 出现前，确实有些代码库因设计之美可被视作艺术；但现在无法知道代码由谁、为何写成，看起来漂亮也只是无意图的随机产出，而且迟早会被不在乎美感的流程重构殆尽。（少数人）

认为 AI 反而抬高了人类艺术的地位

• AI 把“是否用过 AI”变成了分界线：只要没有用 AI，人类作品就自动带上独特性和某种神圣光环，反而全都被抬进精英艺术殿堂。（少数人）

认为程序员和艺术家对 AI 态度不同，源于激励结构相反

• 程序员内部也分成“追求过程、抽象与美学”和“只想解决问题”两种文化，它们对 AI 的反应自然南辕北辙；而艺术家群体更常处在零和收入竞争里，因此对 AI 的敌意天然更强。（少数人）

认为真正的风险不是被取代，而是 AI 让人产出缺乏监督的垃圾代码

• 程序员并不主要是恐惧失业；他们担心没能力的人借助 AI 批量生成没人好好审查的糟糕应用，把“能跑”误当成“够好”。（少数人）
• 即使很多人嘴上讨厌 AI，也会照样用它；其他行业也一样，不能因为讨厌就假设人们不会用。（少数人）

有价值的补充

• 同人圈类比：程序员文化最接近 GPL 理想，欢迎别人一起做、甚至帮自己自动化；艺术家则更常把别人做同样作品视为抢收入，因此对 AI 敌意更强；而对 AI 同人“虽烂但偶有佳作”的宽容，反倒和程序员看待 AI 代码的态度很像。（@NooneAtAll3）
• 程序与代码的区分：编程同时产出“代码”和“程序”，用户消费的是程序；代码只是给程序员看的副产品，因此程序的有效与体验比代码优雅更重要。（@bambax）
• 代码或解法步骤难成展品：能进博物馆的是程序、装置或具历史意义的实物，而不是一段优雅的求解步骤或代码行。（@shotgan）