编程并不特殊：为什么程序员不承认自己是艺术家？(译文)

原文：Programming Isn’t Special，作者：Glyph Lefkowitz（Python 著名异步框架 Twisted 创始人、Deferred 发明者）

创意工作：全行业的抵制与程序员的妥协

好莱坞编剧曾为了在劳资合同中设立抵御「AI」的防护条款而举行大规模罢工。数以千计的艺术家签署了反对 AI 爬取内容的联名公开信。创意行业针对 AI 的版权诉讼铺天盖地，甚至有人专门建立了一个全网 AI 版权诉讼追踪网站。知名 YouTube 博主们对它深恶痛绝；如果他们恰好还是音乐创作者，那态度简直就是极度唾弃。纵观所有的创意行业，人们都在发起一场整齐划一的抵抗运动，试图将这项技术拒之门外。

然而，在所有的创意领域中，程序员的表现几乎算得上是一个孤例：大量经验丰富的程序员依然坚信，在编程中使用「AI」并没有什么大碍。大家似乎也讨厌它，它让大家深感职业倦怠与痛苦，也反感它正在对整个软件行业所做的一切，但根据最新的开发者调研结果，大家依然在一边忍受一边使用。

程序员这种妥协与屈从背后的主要托词，往往归结为：「编程又不是艺术」。大家认为，如果工具能够把活干完，而这项工作纯粹只是功能性的，那用什么工具又有什么关系？

但在作者看来，这至关重要。其核心逻辑在于：我们本就不该用 AI 去生产艺术，而编程本身就是艺术。

艺术亦可世俗且平凡

很多人会反驳说：程序不可能成为艺术，因为程序是功能性的，而非表达性的；程序是世俗平庸的，而艺术是超然神圣的。

作者指出，这种观念建立在对「究竟什么是艺术」的严重扭曲之上。

在约翰·伯格的艺术批评经典著作《观看之道》中，他将这种扭曲形象地称为「神秘化」，即人为制造高深莫测的崇高感。伯格在书中列举的案例既令人忍俊不禁，又极为发人深省：

某位艺术史学者在描述一幅受托绘制的官员集体肖像画时，使用了极其堆砌华丽的辞藻，赞美其「深邃而闪烁的黑色具有微妙的调和」、「达成了和谐的融合」，用近乎出神狂热的语调将这幅画捧上了崇高圣坛。

但伯格揭示了这幅画作背后极其世俗的真相：一位穷困潦倒的老画家急需一份工作糊口，而几位当权官员觉得挂一幅官方群像挺体面。于是官员们付了一笔钱，老画家画完了画，大家得到了一幅画作。这是一幅技艺扎实的群像画，甚至称得上美观；但归根结底，它不过是出于十分平淡务实的目的而承接的定制行活，并且恰如其分地完成了它的使命。它过去不是，现在也绝非什么天赐的神圣遗物。

在文化惯性上，我们极易将绘画、雕塑、电影和音乐盲目神秘化。我们为它们附会各种「玄妙的微调」，却往往忽略了它们骨子里的实用属性，人类之所以需要它们，本就是出于装饰、消遣和转移注意力的世俗诉求，我们只顾着凝视它们带来的情感震撼。

作者澄清道：他绝非反对美学哲学。深入探究我们对艺术品的心理共鸣、通过媒介批判来理解文化与自我是一件极具价值的事，我们甚至应该做得更多。但这绝不意味着此类作品的诞生过程具有某种不可言说的神秘性，也不代表它们应当被凌驾于其他任何人类劳动之上。

尤其是那些与「纯艺术」近在咫尺、但在社会文化中并未被捧上神坛的劳动形态。人们往往极度神化小说家的创作，却对新闻记者的文字嗤之以鼻。而现实中，记者笔下那些讲求实效的报道散文同样至关重要，丝毫不失其应有的尊严。

在大众的刻板认知中，即便新闻记者远未能企及小说家那种高蹈出尘的境界，记者所获得的社会尊重与光环，也远远多于那些普通的商业文案撰稿人。然而，「小说家」与「文案撰稿人」之间根本不存在某种先验的神圣界限；两者所依赖的核心技艺大体相通，两者的身份分野无非是商业机制与个人际遇的偶然而已。

事实上，历史上许多著名作家在崭露头角之前，都曾做过商业文案撰稿人。这绝非巧合！以职业化的态度与文字打交道，哪怕处理的只是平淡世俗的词句，恰恰是日后在纯艺术语境下驾驭文字的绝佳练兵场。因为即便是最平凡琐碎的创造力，其底色依然是艺术性的。

代码之美与现实主义的碰撞

早在一千个「互联网年」之前，当作者还处于十几岁的青年时期时，他曾在一封邮件签名和个人简介里自称是一名「代码诗人」。这一举动在当时遭到了周围人无情的嘲弄，用今天年轻人的流行语来说当时的情况简直「尬到抠脚」，人们批评他「矫揉造作、装腔作势」。

最后迫于巨大的同侪压力，作者妥协了，从签名档中删掉了这一称谓。

为什么软件圈子会对「代码诗人」和「艺术」如此反感？在一场讨论中，有网友说出了业内的残酷真相，这位拥有三十年经验的资深工程师指出：艺术家最珍视的是「独创性」，但在过去三十年里，绝大多数程序员对独创性毫无兴趣，甚至从心底质疑软件是否存在所谓的独创。相反，程序员热衷于快速复制已有的成熟方案，甚至以此为荣，比拼谁能以更快的速度把别人验证过的点子实现出来。

在工程文化层面上，行业内部更充斥着要求服从「规范与惯例」的巨大同侪压力。大家普遍排斥那些行事特立独行、以自己「独创」风格编码的同行，从众是主流，独立思考并不受欢迎。正如这位网友所言，确实有极少数人将编程升华到了艺术的高度，但这绝非主流，更无法代表普通程序员的日常行为。

面对这种普遍的从众压力，作者虽然表面上顺从了社交现实，承认把写代码比作写诗在世俗看来十分滑稽，但在心底，他从未真正放弃过对美学的执念。

作者在软件工程界最广为人知的成就，莫过于在 Python Twisted 框架中发明了 Deferred。而这项发明的诞生契机，纯粹源于一种对代码美学的执念与审美反弹：在当年编写 RPC（远程过程调用）客户端/服务端时，作者极度厌恶每个调用都必须死板地传递 callback 和 errback 两个回调参数的冗长与笨拙。这两个回调在功能上确实毫无问题，能够完美交差；但它们不仅「丑陋」，而且使用起来令人抓狂。

Deferred 是一首针对异步任务编排精心构思的诗篇，它的设计从一开始就带着对问题美感及开发者人体工程学的深思熟虑。它之所以能在技术史上产生深远影响，正是因为其对美学维度的专注。

作者谦虚地表示，无意过分吹捧这项微小贡献有多么深奥伟大或历久弥新。一首诗的存在，并不等同于它必定是一首传世杰作，但它切切实实是一首诗。

在作者看来，软件圈内部的审美文化，更像是一种民间史诗歌谣，而非高不可攀的纯艺术殿堂。因此，这一贡献的真正价值不在于它自身能否永恒长存，而在于它对后续技术演进的启发与链式反应：从 MochiKit.Async 到 jQuery Deferred，再到 JavaScript Promises，直至现代编程语言中随处可见的 async/await；这是一条由一代代工匠不断融入自身巧思的长链，直到最初的形式逐渐融入演进的洪流之中（作者也坦言自己并非最初的绝对原创，同样大量借鉴了 E 语言中的 Promise 等设计）。

要想让代码成为一种深思熟虑的艺术表达，开发者必须在问题领域中沉浸良久。如果没有亲身经历过手动传递成百上千个回调参数的苦痛与枯燥，作者既不可能具备抽象出这一设计的功力，更不可能拥有大费周章去创造它的原动力。

不可否认，那位网友的观察指出了现实的另一面：绝大多数日常业务代码不需要、也没机会达到这种高度。绝大多数代码都只普通程序员「搬砖」是的产物。

但正如前文所述，大多数日常写作也成不了文学经典，绝大部分只是广告宣传；绝大部分视觉作品只是商品海报；绝大多数现场音乐只是嘈杂酒吧里无人留意的背景噪音。然而，那些真正倾注了美学自觉与架构美感的代码，在技术与社会演进的历程中，往往扮演着决定性的关键角色。

其实在软件工程的传统中，我们从来不缺乏「自我审美品味」的积淀：

• 计算机科学经典《SICP》作者哈尔·阿贝尔森曾留下一句振聋发聩的话：「程序首先必须是写给人读的，只是顺便让机器来执行。」
• 我们长期以来都承认程序具有极高的表达性，即便我们有时对它们究竟表达了什么、向谁表达争论不休。
• 我们会诗意地探讨 Unix 哲学的深层意蕴；Python 社区沉淀出了著名的《Python 之禅》（PEP 20）；Perl 社区也曾进行过类似的哲学求索。
• 软件的美学特质不仅体现在阅读源码或设计 API 上。例如科技评论家 Federico Viticci 每年针对苹果全新操作系统的万字详评，本质上就是一场严谨的美学批评。如果软件无法在用户体验层面唤起审美共鸣，这种评测便无立足之地。
• 更不用说，当今的每一篇电子游戏测评，归根结底都是一次深度的软件审美测评。

捍卫平凡的日常练兵场

这就引出了全篇最核心的交锋点：

为什么当生成式 AI 席卷而来时，程序员群体如此容易缴械投降？前述网友的观点恰好解释了这一现象：既然整个行业的现实文化本就热衷于「快速复制既有解」、讲求快速交差与服从标准规范，那么能够迅速拼凑样板代码的 AI，自然就精准迎合了这种实用主义诉求。

但作者在此提出了最振聋发聩的警告：

如果我们任由 AI 抹去所有的初级文案、平面设计，抹去所有平淡乏味的世俗艺术，抹去所有枯燥普通的 WordPress 主题定制开发，我们实质上是在连根拔起所有人通往卓越所必需经历的海量「刻意练习」与「沉思」的土壤。

任何手艺人真正的心智成长与技能蜕变，历来都是在真实工地上摔打出来的，正如披头士乐队在汉堡地下酒吧每日演奏 8 小时、最终淬炼出神级默契的 10,000 小时传奇那样。

这并不意味着程序员必须抗拒抽象与自动化。编程本就是关于「抽象的艺术」，去理解如何将微小的思想构件拼装成宏大的系统，去理解如何掌握小规则的自洽与组合，从而掌控大系统的自动化运转。

然而，当我们使用「AI」去消解这种深层理解而非提升抽象层级、去彻底摧毁这一创造性决策体系的时候，我们既是在背叛身为程序员的职业尊严，也是在背叛我们的终端用户与下游协作者。

这就像一个视觉画师或音乐家，为了交差而将自动生成的填充物打包塞给观众一样，毫无敬畏之心。

「垃圾就是垃圾，无论载体是什么。」

每一个看似琐碎平庸的日常工程项目，其实都有着极其微小的概率（哪怕只有 0.1%）孕育出真正卓越的架构突破。如果我们偶尔用 AI 应付某个单独的项目，确实无伤大雅，因为那个项目本来也不大可能成为定义开发者一生的代表作；但如果我们习惯成自然，将所有项目都全盘外包给 AI，我们就会让那些闪耀高光时刻的出现概率，彻底从「必然偶发」变成「绝无可能」了。

工程规范和标准件固然能维系现有的工业协作，但真正推动软件世界前行的架构革命，无论是 Unix 管道、Twisted 的 Deferred、还是 React 的声明式 UI，无一不是在深入凝视问题本质后、出于对丑陋现状的不满而完成的艺术性创造。如果新手工程师从入行起就将所有的困惑与试错外包给 AI，这个行业或许能多出一批熟练装配工，却再也无法培养出能够打破常规、创造下一个时代的「数字艺术家」。

在所有的软件开发环节中，究竟该以何种精确的姿态去抵抗 AI 的侵蚀，显然超出了这篇随笔的篇幅。你个人能抵抗多少、在哪些特定场景下选择坚守，取决于你自己的判断。

但在软件领域发起抵制，其价值丝毫不亚于在绘画、文学或音乐等任何传统创意媒介中所发起的抵抗。

编程并不特殊。它就是艺术，而艺术是人类最本真、因而也最普遍的事物。