为什么大胆且富有想象力的界面如此罕见，我们怎样才能拥有更多这样的界面？
强大的全新用户界面彻底颠覆了众多学科。非线性视频剪辑器！计算型实验室笔记本！超媒体！电子表格！视觉特效节点图！支持双向编辑的音频转录文本！此类奇迹不胜枚举。但我认为，我们目前还只是触及了皮毛。尽管科技行业充满了狂热的活力，尽管有着诸多极具声望的人机交互会议，但用户界面领域实质性创新的步伐却异常缓慢，想象力的水准也显得极为平庸。我渴望找到新的答案，提出新的问题，最好是两者兼得。
作为一名程序员，这是充满不可思议奇迹的一年，无论你关注哪种图表，数据都呈现出夸张的曲棍球棒式的指数级增长。编程智能体已经让软件开发工作变得面目全非。这在当下已是老生常谈。但我看到另一个故事也正在拉开帷幕——想象力工作正在发生转变，我希望这将为我们带来一波新的创意浪潮。
程序员无意间的专制
在个人电脑发展的早期，那些颠覆性的用户界面都是由跨界的奇才发明的：Engelbart、Sutherland、Kay、Simonyi、Atkinson。他们拥有科学领域的博士学位——在那个年代，开发任何东西都极其困难——但同时，他们也是极具想象力的设计师。
多年以后，软件需求的增长速度远远超过了全能型天才发明家的供给速度。到了 80 年代，软件界面依然由程序员来开发，但越来越多地由那些不具备先驱们直觉性设计能力的程序员来创建。于是，充斥着技术术语、对用户极不友好的界面开始泛滥。1999 年，Alan Cooper 出版了一本探讨该问题的里程碑式著作，书名十分贴切，叫《The Inmates Are Running The Asylum》。他提出了一种新的职业角色——交互设计师——旨在深入理解用户需求以及我们所掌握的这种新型计算材料的设计模式。设计师将与程序员携手合作，共同让产品形式与功能需求完美契合。
时至今日，我们已经很少看到 Cooper 所抱怨的那种糟糕透顶的界面了。现代大多数软件确实在努力理解用户需求。软件团队通常也会配备专业的设计师。即使没有，界面设计的模式和实践也已经普及开来，以至于许多程序员靠自己就能做出过得去的界面。
但我要说：精神病人依然在管理疯人院。Cooper 担心的是，程序员无意间的专制会让人们被迫忍受滑稽且糟糕的界面。好吧——这个问题在很大程度上已经解决了。但我担心的是，程序员这种无意间的专制阻碍了用户界面的创新。
我渴望看到怪异的、勇敢的、极具个性的、甚至有点像外星产物的界面。是的，是的，我们正处在机器智能令人惊叹地降临的时代。这已经足够具备外星感了。但我谈论的是界面：是信息的呈现方式、交互方式，是我们观察和操作的方式。聊天机器人在计算能力上令人惊叹，但到目前为止，我们只是把这种强大的能力塞进了那些与我十几岁时使用的 IRC 客户端相比几乎毫无进化的界面里。创新到底在哪里？
我认为核心问题在于：在动态媒介中进行发明创造，需要过多的编程工作。要发明一种新的用户界面，你不仅需要富有想象力的设计技能，还需要熟练的技术技能。极少有人能同时兼备这两点。
更糟糕的是，即便具备了这两点，通常也还是不够。许多界面的创新也需要深厚的领域洞察力[1]。试想一下，Steinberg 是在积累了多年音乐家和制作人经验之后，才发明了（Cubase 中的）时间线编辑器；而 Bricklin 是在哈佛商学院就读期间，才发明了动态电子表格（VisiCalc）。
在这些技能中，你可能会认为，打造大胆的新用户界面的主要瓶颈在于富有想象力的设计工作和深厚的领域洞察力。如果真是这样，你可能会期望在行业文化中看到对这些技能的高度重视。但如果你去参加关于界面创新或「个人电脑的未来」的社区活动，或者走访大学里的人机交互学术系，你会很快发现，那里几乎所有人都是科班出身的程序员。并且在文化属性上，他们也是典型的程序员。大多数人都是在正规的、偏向分析的理科项目中学习成长的，而不是在那些充满狂野创意的美术设计学院。不可否认，这也是我本人的真实写照。
我怀疑我们之所以陷入这种境地，是因为这些技能之间存在着严重的不对称性。没有设计能力或领域洞察力的编程，依然可以产出能够运行的界面——尽管它们往往很无聊或存在缺陷——但如果没有编程能力，再好的设计或领域洞察力也只能停留在画板上。因此，至少对于独立发明者来说，几乎所有能运行的界面都是由程序员创建的……而这些程序员是否具备其他技能就不好说了。如果新界面的瓶颈主要在于富有想象力的设计工作和深厚的领域洞察力，那么这种技能上的不对称性，实际上把筛选压力施加在了错误的技能上。
每当我抱怨界面创新步伐太慢时，人们经常告诉我这实际上是市场的问题。大众消费者更愿意为简单、熟悉的界面买单，而不是那些古怪、新颖的东西。容易摘的果子已经被摘光了。大家都在遵循同一套枯燥的 B2B SaaS 剧本。现在它已经是一个利润丰厚且竞争激烈的行业，不再是过去那个极度充满极客精神的圈子了。再说，到底是谁说新颖的界面就是好东西了？
我对此并不买账。或者说得更准确些：这些反对意见确实有理，它们也确实解释了为什么平均水平的用户界面如此乏味。但是，「计算的未来」聚会和人机交互会议上，到处都是根本不在乎这些市场力量的人。在这些圈子里，有大量渴望表达个人新颖愿景、在云端构筑自我城堡的人。只不过——出于对这个圈子的热爱我才这么说——最终的成果往往令人大失所望。我认为，这是因为这个圈子过于看重编程能力，而在设计和领域洞察力上却严重缺失。
疯人院里的团队合作
Cooper 认为我们可以通过专业分工来拯救这个行业。我们要让程序员和设计师并肩作战。也许他们中的某个人拥有深刻的领域洞察力，又或者产品经理能补足这一点。对于大多数软件来说，这种模式运作得挺好。因为大多数软件无非是同一套主题的变奏曲，专业人员只需套用成熟的模式即可。太多的新意反而会碍事。但这篇随笔探讨的是「发明」——而在发明领域，我认为专业分工的效果要大打折扣。
团队模式默认将不懂编程的人置于一种依赖他人的境地。如果一位设计师想发明一种全新的界面，他们通常得先说服别人帮忙，否则连一个能运行的原型都做不出来。这种「推销」过程非常艰难：他们不得不拿一些粗糙的假模型来展示，并完全指望同事发挥想象力来填补其中的空白。对于那些只懂一点点编程的设计师来说，制作原型的过程往往依然太过缓慢和艰难，根本不足以抵消其机会成本。我见过很多设计师在这上面卡了整整好几年，他们总是把脑海中挥之不去的某个概念挂在嘴边，却始终无法以一种别人能看懂的形式将它实现出来。
听起来，问题似乎是设计师们总在不断提出绝妙的点子，却总是被目光短浅的管理层或技术人员毙掉。但更深层次的问题在于，这种合作模式往往从一开始就扼杀了这些想法，让它们根本没机会变成「绝妙的点子」。我们怎么能指望一个人在不亲自使用、也不基于真实可用的界面版本进行迭代的情况下，就能构思并向他人推销一个关于全新界面的伟大想法呢？那些不懂编程的设计师，正试图在一种交互式的、计算型的媒介中搞发明——自己却毫无能力创造出真正具备交互性或计算能力的东西。要知道，发明的很大一部分关键就在于与材料的亲密接触，在于快速的反馈循环，以及在真实使用场景中的敏锐观察。
这就像《第二十二条军规》里的死循环：为了能与他们所使用的媒介进行深度的「对话」，不懂编程的人必须求助于程序员。这通常要求他们至少得把自己的想法表达得清晰且有吸引力。但是，如果他们做的是真正前所未有的创新，在没有与媒介进行过深度对话的情况下，他们往往根本无法让自己的发明变得清晰且有吸引力。
对于程序员来说，这同样是个糟糕的处境。他们被迫成为了无意间的「把关人」。我和同事们就曾陷入这种境地。他们费力地解释自己的想法；我试着去探索、去发散，但我真的还是看不到他们眼中看到的那些闪光点。简单来说，摆在我面前的只有两个糟糕的选项。我要么表示反对，这通常会直接让队友陷入停滞。我要么勉强同意，放着自己手头更重要的事情不做，去支持一个（无论我判断对错）看起来不如我现有任务有前途的想法。在这些情况下，作为一名全栈通才反而让我变得更加专制，因为我自己脑子里总是有大把可以去开发的设计点子。
我认为，这一切在某种程度上解释了为什么现代软件设计文化往往过度强调视觉层面的精雕细琢，而不是去探索新颖的动态表现形式或交互方式。因为在视觉领域，设计师可以凭直觉自由地修修补补，而不用承受每探索一个新想法都要依赖他人的挫败感。这在设计界，就等同于一个被异化了的程序员过度执迷于「代码质量」。在适度的范围内，这两种做法都没问题，也是必要的，但它们很容易演变成一种出于自我保护的目的，从而逃避探索媒介真正潜力的退缩行为。
2025 年：破壁之机
读到这里，我接下来要表达的观点可能已经很明显了。我认为，编程智能体（coding agents）将终结在界面发明领域中程序员这种无意间的专制。我认为，在发明的早期阶段，设计师和领域专家将越来越多地摆脱对程序员的依赖。他们终于能够亲自掌控这种动态媒介，直接对各种概念进行迭代和制作原型。
我已经亲眼见证了这一切！在 2025 年这一年里，我与两位才华横溢的设计师紧密合作。过去这一年，他们借助编程智能体所经历的故事，与我自己那近乎疯狂的转型经历如出一辙——但我认为，这种转变对我的合作者们产生的影响要令人兴奋得多。与我不同，这两位都是从设计行业起步的，并且在艺术文化领域度过了他们的成长期。他们确实会写一点代码，但这个过程对他们来说（曾经！）太过缓慢和吃力，以至于构成了一道难以逾越的巨大障碍。
在 2025 年初的时候，编程模型还只能实现一些一次性的小型设计想法，稍微迭代几次，输出的结果就会变得乱七八糟。到了春天，智能体已经能够将一些简单的想法整合到我们团队的原型系统中了。而到了秋天，这种情况开始以一种近乎疯狂的速度急剧升级。其中一位合作者告诉我，这对他们来说是一个历史性的转折点：这是他们职业生涯中破天荒的第一次，能够直接将核心功能提交到团队的主代码库中。
到了年底，我的合作者们已经能够将编程模型作为日常工具，用来快速构建新颖界面想法的原型，并且往往还能连带搭建出新颖的技术架构，而且能够在连续几周内持续不断地进行迭代。我经常会在早晨查看消息时，发现某个极其精致复杂的原型，那完全是他们深夜灵感迸发、一气呵成的杰作。
好几个月以来，我们的界面草图一直暗示着某种极其复杂的交互式内容布局系统。但我们一直对把它整合到原型中感到发怵——它看起来就像是个需要兴师动众的恐怖大工程。然而有一天早上醒来，我竟然看到了一个能完美运行的实现版本：仅仅一位设计师带领着一群编程智能体，在彻夜奋战后就把这事儿搞定了。就在同一个星期，我又惊讶地看着另一位设计师，将一张动态 3D 数据可视化的铅笔草图，变成了一个能够加载真实案例数据运行的迷人原型。
这段经历彻底改变了我们团队合作的本质。在年初的时候，我的合作者们大多不得不「通过我」这道关卡，才能让他们的想法变成高保真度的原型，以便进行真正的测试。当时我们有三个设计师，却只有我一个程序员，编程资源根本就不够分。这对大家来说都很痛苦：这让我变成了一个无情的把关人，把我的同事们逼成了四处推销的销售员。但现在，情况正发生着改变，他们越来越能够在自己的原型中自由地修补和完善那些想法。
有那么几次，我的合作者做出了一个原型，我才恍然大悟：天哪，你前阵子一直试图表达的就是这个啊，我当时竟然没懂！现在，我不需要懂了。我不再是阻碍他们早期表达和迭代的绊脚石。正如我之前所描述的，这个故事并不只是说明我太迟钝，以至于欣赏不了合作者们分享的那些美丽的早期想法。很多时候，设计师自己也只有在亲手触摸并反复调整之后，才能真正弄懂自己最初的灵感到底是什么。编程智能体创造了一个安全的空间，让人们可以在想法还不连贯的时候尽情地随性涂鸦。而在过去的那种合作模式下，它要求你在项目初期就必须具备极高的清晰度和可解释性。
这种全新的合作动态令人惊叹，充满启发。很显然，这也是我的合作者们重获如孩童般纯粹创作乐趣的源泉。他们中的一位，Nio Ono，这样分享自己的体验：
氛围编程（Vibe coding）解锁了我大脑深处的某些东西，或者说唤醒了我潜在的人格矩阵。这让我想起了那些声称被武术或某种神秘修行彻底改变了的人的描述，感觉就像是我内在的某种东西被重新校准了，将我与一条沉睡已久的内在能量管道连接在了一起。
……
我感觉自己被彻底释放了，这种释放感甚至改变了我的自我认知。那是一种泾渭分明的「之前」与「之后」的体验。……我感到有充分的自由去采取行动！去表达我自己！……「我感到肉体带电」（I feel the body electric），这句话是对这种感觉最完美的诠释。
我认识的每一位设计师，都曾有过被绝妙的想法长久萦绕、却苦于得不到足够的「资源支持」而无法去尽情尝试的经历。好吧：现在他们自己就能去尝试了。我可以想象，每一个满脑子梦想的设计师现在肯定都在跃跃欲试，他们受够了为了表达自己的想法而无尽等待别人的日子。
我不禁在想，如果在今天这个世界里，Ted Nelson 的故事会变得多么不同。你可能不觉得他是个「设计师」，但在我眼里他就是：他赋予了我们「超文本」（hypertext）这个词，并花费了五十年的时间去追寻一个存在于平行宇宙中的万维网——在那个网络里，每一篇文字都存在于一个鲜活的网络中，与所有引用它的内容紧密相连。他拥有我渴望在这个圈子里看到的那种狂野的想象力。当然，他也拥有极其深厚的领域洞察力。只是他缺乏将自己的想法制作成原型的技术技能，于是他写下了一本又一本的书来阐述这些理念，不断地将概念推向极致，却始终无法从媒介本身获得他所迫切需要的真实反馈。他耗尽了整个职业生涯，去争取实现和体验自己想法所需的资源支持。当这些系统在历经几十年的艰难斗争后终于被开发出来时，它们并没有像他所描绘的那样强大和引人入胜。但这并不应该让我们感到意外：因为发明本来就是需要不断迭代的。他当时没有那个迭代的机会。可如果他有呢？
产品交付并非我关心的瓶颈
科技界正充斥着关于编程智能体的喧嚣。有人说：计算机科学的本科生要完蛋了；「只会出点子的人」将自己构建并发布所有东西！也有人说：那都是炒作；用氛围编程写出来的软件看起来不错，但当你试图真正去使用它时，它就会崩溃。
随便怎么说吧。我想要的是在用户界面领域看到更多的想象力和创新。而为了实现这一点，即使不懂编程的人无法将他们的原型一路推进到产品上线阶段，编程智能体依然能发挥巨大的作用。现在的瓶颈并不在于我们不断看到惊艳的新界面原型和研究系统，却因为愚蠢的市场不愿将其投入生产（如果真是这样，那倒是个令人欣慰的烦恼了）。我更关注的是如何增加涌入创意漏斗前端的想象力。
在早期阶段，人们对软件质量的压力没那么大。一个原型必须足够真实，才能让设计师在真实的语境下——最好是有真实数据和真实使用场景——感受到他们的想法是如何运作的，并能将其清晰地传达给他人。对于某些想法来说，编程智能体已经足够优秀，能够制作出这种水平的原型，而且它们的表达范围正在迅速扩大。
高保真原型还能缓解团队创新的另一个障碍：谁来为这些梦想买单？一个传统的答案是：做梦的人自己。某人被一种难以言传的、刚刚萌芽的渴望所俘获，为了追寻它一段时间，不惜放弃科技巨头的高薪或牺牲自己的周末，直到他们能向投资人讲出一个像样的故事。如果是好几个人同时处于这种情况，协调起来就困难得多了。所以，话说回来，这些追梦人通常都是单打独斗的程序员，因为只有程序员才能靠自己做出能运行的东西。但如果设计师也能制作出可运行的原型，我们就可以采用一种更像电影制作的模式：一个想法可以在一位具有自我牺牲精神的「编剧兼导演」那里孕育，直到它足够吸引人，从而引入更多的专家。
然后，一旦组建了团队，高保真原型在传达动态媒体理念方面，要比大多数设计师现在使用的工具有效得多。与静态的画板和只能点击跳转的演示不同，这些原型可以清晰地展示新颖的动态行为。Bas Ording 当初就是使用 Macromedia Director 制作的原型加上东拼西凑的脚本，发明了 iOS 的惯性滚动和橡皮筋回弹效果。那些代码一行也没有发布到最终产品里——但这又有什么关系呢？它定义了一代人对计算机的核心操作手感。
在氛围编程的原型中生存下来
要设计像 iOS 滚动机制那样连贯的交互，你必须亲自上手去触摸材料，去真正感受它。对于孤立的原型来说，你能走得很远——就 iOS 的滚动而言，据说当初那个原型只是一个简单的联系人列表。但要设计一个更复杂的工具或工作流，你需要体验你的想法在与它本该解决的实际问题发生交互时的状态。你需要真正生活在你的系统中。这就设定了更高的门槛。这些原型通常涉及诸如数据库、网络、部署、数据同步、多用户支持、数据迁移等方面的考虑。
一个流行的 AI 基准测试提出了这样一个问题：我能把一项工程任务交给一个无人监督的 AI 多久？对于原型制作，我一直在观察一个关键的相关指标：在代码库彻底崩溃、损坏且无法维护之前，人类（在没有技术监督的情况下）可以利用智能体迭代多久？在过去的一年里，我看到这个数字从几个小时变成了几个星期。这种进步很大程度上归功于模型变得越来越聪明，但我的感觉是，其中一部分也源于经验和策略的积累。微小的流程改进就能对原型的生命周期产生巨大影响。（有关一些战术层面的建议，请参阅下文的脚注。）
但应对智能体带来的审美和认知冲击却要困难得多。整天和编程智能体一起工作，让我的注意力变得支离破碎、无法集中、且充满冲动。我陷入了一种「忙碌的空等」状态，在五个不同的工作区标签页之间来回横跳，不断地清空并重建我的工作记忆。我行动迅速，却从未进入过心流状态。
Nio 分享了对这种感觉的看法——这与我前面摘录的他们那欢欣鼓舞的笔记形成了惊人的反差：
我生活在一个永恒的当下。没有记忆，没有计划。每一分钟我的注意力都在向别的东西扑去。我甚至很难回忆起过去这几个月到底发生了什么。尽管有这么多活动，我却感到自己一无所获，也留不下任何记忆。我感觉自己与肉体剥离了，所以我的现实生活变得一团糟。我的家变成了我的屏幕，导致我的居住空间布满灰尘且残破不堪。我感觉自己被剥夺了自主性。我几乎认不清自己的目标，更别提去实现它们了。这感觉就像是忘记了前世的记忆。整个世界感觉就像是我屏幕背后模糊的布景。一切都成了桌面壁纸。
「手工」制作某件东西会带来一种深层的愉悦感，但在这里，它被一种焦虑的、漫无目的的狂热所取代。构建软件变得如此容易，以至于现在它变成了一种有些危险的诱惑。我和我的合作者们都发现，自己会不知不觉地把问题像打排球一样抛给智能体，以此来逃避去认真思考那些棘手的难题。
路在何方？
这些代价是实打实的。但我之所以和合作者们一起默默忍受，是因为编程智能体对设计师来说是个天大的好消息，对发明创造来说也是。尽管我本身就是个经验丰富的程序员，但在它们的加持下，我的进度快到不可思议，以至于我开始着手解决那些在一年前连想都不敢想的难题。然而，就像许多见证了这些变革的人一样，我现在也开始陷入对自身职业发展的一些不安的思考中。
在我的人生里，超过三分之二的时间都在写代码，只有稍微多于三分之一的时间在从事具有创造性的设计工作。所以，如果说我至今依然是个远比发明家更出色的技术专家，这实在不足为奇。我认为，我在后一个角色（发明家）上所取得的那点微不足道的成绩，主要归功于我作为一个「多面手」的综合技能，而非我有着多么宽广的想象力。既懂设计又懂编程的人是相当罕见的，这赋予了我一种非同寻常的优势。但我认为——实际上，我也希望——这种优势在未来几年内将基本不复存在。
到那时候，我的位置在哪里？如果我去做深度的工程研发，我的技术能力或许还能派上用场，但在界面发明的维度上，对深度工程能力的要求通常没那么高。平心而论，我认为自己远不如那些我最钦佩的设计师们富有想象力。我在视觉呈现上的表达空间要狭窄得多。在构思和迭代界面想法时，我的动作也迟缓得多。
这种差距，部分原因仅仅在于，与那些将整个职业生涯都倾注于创造和消费视觉作品的同行相比，我的实践经验实在少得可怜。当我说界面创新的圈子「过于看重编程能力，而严重缺乏设计能力」时，这也正是我想要表达的意思之一。但我所说的「设计」，其内涵远比职业实践更为宽泛。它指的是大胆的想象力和灵感迸发的创造性能量。很多程序员确实拥有这种能量。但编程文化所灌输和奖励的，大多是更偏向分析和实用的特质。
我作为程序员的几十年职业生涯，强化了一种刻板的形式化思维模式，这种模式似乎天然就与天马行空的创造力背道而驰。我的大脑总是会不由自主地滑向抽象化、滑向概括总结。我太了解计算机底层的运作原理了；一旦有了新想法，我会本能地去揪出其中隐含的冲突和模棱两可之处。当需要把想法系统化时，这种深厚的工程师文化底蕴就成了我的超能力。我可以从合作者那里接过一个模糊不清、定义不明的想法，然后通过提出问题和逻辑推导，让它真正变成一个严谨可行的方案。但是，这种思维模式对处于萌芽阶段的想法施加了太大的压力。我十分羡慕我的一些设计师朋友，他们能够像把意大利面随意甩到墙上一样，毫无顾忌地去摆弄一个诱人的想法，完全不用去操心这个想法在工程上会牵扯出多少死板的规则。
那么：路在何方？
几十年来，我们建立的人机交互学科，大多看起来就像是加了几门设计选修课的计算机科学系。但是，如果我们正在迈向一个由「想象力」而非「技术专长」决定创新上限的世界，我们可能从一开始就搞反了。我们需要建立的是看起来更像加了技术选修课的艺术学院——要教人们学会在能够精确表达想法之前，先凭直觉去孕育它们，学会在与材料的嬉戏玩耍中去发现新知。
或者，如果我们要认真对待对「深厚领域洞察力」的需求，这些学科是否应该围绕着与其他专业的「双学位」模式来设计？也许，我们长久以来对「真正普及计算机素养」的梦想，现在终于是时候实现了：我们是否应该把重点放在让那些满脑子奇思妙想的领域专家能够自己打造工具和界面，而不是把这项工作垄断在一个独立的职业手里？科技行业显然已经在这条路上狂飙突进了。一大批初创公司正陷入狂热的竞争中，试图把这些神奇的编程智能体包装成对非程序员有用的工具。但在我看来，他们太沉迷于这场狂热的竞赛，以至于根本没有深入思考：这些工具大多只不过是给基础的聊天机器人套了个简单的壳。这个领域亟需强大的新范式，无论是对于软件本身，还是对于我们用来开发软件的界面。只要有足够的想象力，也许我们能通过理论创新和发明创造，最终让我们（程序员这个群体）彻底退出历史舞台。
至于我自己，以及这个圈子里其他在编程文化熏陶下成长起来的人：我们该如何适应并取得突破？技术的熟练度必然会扼杀一个人孩童般的想象力吗？在什么情况下会这样？我从历史上伟大的科学家和计算领域的先驱（如 Feynman 和 Kay）身上找到了一些慰藉。他们的故事似乎明确地告诉我们，这两种能力不仅能够共存，甚至还能相互放大。所以，我现在面临的最紧迫的问题就变成了——我该如何才能更好地在自己身上培养出那种共鸣？
———
感谢 Frank Lantz、James Anthony、Joshua Horowitz、Ken Kocienda、Marc ten Bosch、Mills Baker、Nio Ono 以及 Taylor Rogalski 对本文提供的有益讨论和反馈。
关于在氛围编程原型中生存下来的战术指南
以下是一些帮助我们延长原型生命周期的实践经验：
- 为粗糙的原型编写严谨的代码（Rigorous code for sloppy prototypes）。当我自己手写原型代码时，我通常会避开单元测试、类型检查、状态机、编写文档和正式的数据建模这些「严谨」的实践——它们往往会拖慢进度。但使用智能体时，即便是一个粗糙的原型，采用这些严谨的实践也是大有裨益的：它们能提供额外的上下文和安全护栏。而且智能体会自动处理掉大部分通常需要人工维护的开销。
- 少量的编程指导（Fractional programming supervision）。哪怕只是一位经验丰富的程序员提供一点点微小的支持，也能让这个用「胶带」粘起来的系统维持运转得久得多。而且我认为，在这个新世界里，不懂编程的人更容易开口去寻求这类支持，因为他们的想法已经部分地实体化为一个很酷的原型了——只不过可能还有点 Bug 而已。
- 速率分层（Pace layers）。当我们在同一个原型上协同工作时，我们通过将系统划分为不同的架构层，并将那些未经审查的智能体代码限制在最外层，从而更长久地推迟了系统的崩溃。对于同步系统或敏感的领域逻辑等核心组件的修改，则必须经过严格的代码审查。
- 自我监督（Self-supervision）。如今的编程智能体经常会做出糟糕的技术决策并留下烂摊子。但是，在一定程度上，不懂编程的人可以直接要求其他智能体去清理这些乱象并简化代码。如果模型能够驱动自身的反馈循环（例如，使用测试用例或浏览器自动化工具），这一切就会运作得更好。
- 只读式编程（Read-only programming）。我不会说西班牙语，但我通常能凭借自己那点微薄的意大利语和拉丁语知识作为参照，大致看懂书面的西班牙语。同样，不懂编程的人如果仔细检查，通常也能发现智能体代码中的问题。「等等，你为什么要重复写这段逻辑？这里应该调用我们已经写好的那个接口啊……」
- 接受崩溃（Accept collapse）。既然现在编写代码的成本已经变得极其低廉，那么代码库时不时地自我毁灭也没什么大不了的，只要你能从中汲取足够的经验教训，用来指导你设计下一个原型就足够了。
Thoughts Memo汉化组译制
感谢主要译者 gemini-3.1-pro-preview，校对 Jarrett Ye
原文：Interface invention and the accidental tyranny of programmers | Patreon
作者：Andy Matuschak