AI時代下的軟體品味與“slop”之辨
文章探討了在AI輔助程式設計日益普及的背景下,軟體“品味”的重要性。作者認為,僅僅正確的程式碼是不夠的,好的軟體還需要優雅的使用者體驗和深思熟慮的設計,這源於開發者的品味和智慧。AI生成的技術正確但缺乏品味的軟體可能淹沒世界,而規範驅動開發(SDD)可以發揮關鍵作用,但前提是規範必須捕捉到品味和“為什麼”。同時,初級工程師的成長路徑也將改變,他們不再透過大量編碼積累經驗,而是透過快速迭代和判斷力培養。
在AI輔助程式設計日益普及的今天,一個古老的問題再次浮出水面:為什麼有些軟體如此出色,而大多數卻只是“能用”?不是充滿bug,不是執行緩慢,而是——糟糕。一種你初次使用就能從骨子裡感受到的糟糕。答案不在於工具、預算或團隊規模,而在於一個被長期忽視的概念:品味。而且,在AI時代,品味可能就是決定勝負的全部。
我們無休止地談論正確性:是否編譯透過?測試是否透過?是否安全?是否可擴充套件?所有那些“性”——必要性俱在,但無一充分。因為存在一些軟體,它們滿足了所有上述要求,卻依然是徹頭徹尾的使用災難。而另一些軟體——有些甚至是由三個人在地下室編寫並免費提供的——會讓你驚歎:“哦,原來應該是這樣工作的。”你不必與之對抗,它預判你的需求,它有主見,而且主見總是對的。
第二種軟體絕非偶然。它是被固化的品味。想想巔峰時期的蘋果。喬布斯並非傑出的工程師,但他是一個毫不妥協、痴迷於品味的人,拒絕推出任何不夠“正確”的產品,並建立了一個能夠長期持續交付“正確”的企業。那些關於Mac機箱內部即便無人看見也追求美觀的著名故事,並非虛榮。那是一種將“我們絕不出售垃圾”內化為企業文化的結果。軟體之所以被熱愛,是因為組織擁有品味,而產品正是這種組織的視覺化呈現。
康威定律深入人心:組織架構決定系統架構。但它的含義不止於溝通結構。軟體映象了構建它的組織的價值觀、品味、紀律,以及對另一端使用者的尊重或漠視。這就是為什麼某些開源軟體在數十年後仍然是其領域的最佳之作。git、ffmpeg、sqlite、curl——這些不是由最佳化季度EBITDA的匿名委員會開發的,而是由深刻理解問題、在乎正確性、只對自己的標準和使用者負責的人們開發的。少數有主見的人的品味在每一個命令和每一個標誌中固化,這就是魔法,是封裝後的智慧。
這也是為什麼那麼多企業軟體令人深惡痛絕。我不點名——你知道我說的是誰,你心裡也有自己的名單。這些軟體糟糕並非因為工程師不行,而是因為它們是為滿足所有客戶的所有需求而構建的,由缺乏統一觀點的龐大組織開發,最佳化的是RFP檢查清單而非鍵盤前的人,更關心利潤和增長而非使用者。沒有品味可以封裝,因此什麼都沒有封裝。你每天使用它們時都能感受到這種缺失。
那麼,“優雅程式碼”到底是什麼?工程師們像追求聖盃一樣追逐優雅程式碼。但如果問十個人什麼是優雅,你會得到十個答案,大多數只是感覺。我的答案是:優雅是理解的精煉。它是你在真正領悟問題之後,丟棄所有不屬於問題的東西后剩下的。優雅的程式碼事後看起來顯而易見,這欺騙人們以為它很簡單。其實並不簡單,它是艱苦得來的。優雅是被壓縮到能裝進你腦袋的智慧。優雅不是程式碼的屬性,而是程式碼背後理解的屬性。你無法偽造,也無法事後追加。而且——這一點我希望你深思——使用的優雅與程式碼的優雅同等重要,甚至更重要。一個華美的內部架構包裹著一個令人困惑、充滿敵意的使用者體驗,這並不優雅,只是穿著漂亮西裝的垃圾。
垃圾正在湧來,而且不僅僅是程式碼。讓我夜不能寐的是:我們將用AI輔助軟體淹沒世界。而關於“AI垃圾”的討論幾乎全部集中在程式碼是否正確、安全、是否幻覺出不存在API。這是個小問題。大問題是,垃圾將體現在軟體如何工作上:流程、預設設定、關於讓什麼變容易、什麼變可能的成千上萬個微小決策。一個智慧體對於這個介面應該是一屏還是三屏沒有主見。它沒有品味。它會愉快地生成一個技術上正確、經過全面測試、文件精美但使用體驗糟糕的軟體——而且速度比那些訓練我們接受痛苦的企業級大廠快一萬倍。因此,我們將得到一萬倍的垃圾。
因為還有一件事:我們已經被訓練了。幾十年來“足夠好”的企業軟體和巨大的切換成本教會我們接受糟糕為正常。聳肩,提交工單,然後繼續。我們不再期望軟體是好的。AI將對這種習得性無助火上澆油。除非……
如果我們能在它被構建之前就阻止它呢?這正是規範驅動開發(SDD)可以大放異彩的地方,也是我既興奮又擔憂之處。美好的前景是:如果智慧體將根據我們的規範構建一切,那麼規範就是品味現在所在之處。規範是槓桿點。把規範做對——捕捉“為什麼”、優雅、以及軟體使用時應有的精確感覺——你就可以在編寫一行程式碼之前攔截垃圾。這是我們從未遇到過的機遇。我們可以在前端編碼智慧。
但是,“把規範做對”這句話包含了巨大的工作量。我深入研究了新的規範驅動文獻。有一本書《Agentic Spec-Driven Development: A Practical Method for Using AI to Build Complete Specifications》,說實話,如果你的團隊還沒讀過,應該讀一讀。它的嚴謹性真實不虛,介於摩天大樓的建築規範與原始碼之間——充滿了那些應該出現在我們規範裡卻通常缺失的東西。我非常尊重它。但讀它時我無聊得要死。我感覺自己像個刻板的會計。構建的樂趣——最初讓我愛上這項工作的東西——被簡化為菜譜,步驟、檢查清單、必須填寫的章節。
別誤會。菜譜的機制很重要,非常重要。目前有很好的基礎設施正在建設中。谷歌的Open Knowledge Format是一個嚴肅的嘗試,旨在標準化我們編寫菜譜物質部分的方式——事實、約束、共享知識。而諸如Tolaria之類的工具則試圖讓編寫和維護這些知識變得容易,這正是整個運動所需的那種平凡但關鍵的管道。如果技能是關於“怎麼做”,那麼知識格式就是關於“什麼是真的”。我們兩者都需要。但是,一個沒有品味的人遵循完美的菜譜,仍然只能做出平庸的食物。
然後我讀了Jay Acunzo的文章《Your Move, Chief》,它讓我大為震撼。這正是我一直在尋找的解藥。如果你知道那個場景,你一定明白。《心靈捕手》中,羅賓·威廉姆斯飾演的Sean在公園長椅上對那個狂妄的天才少年說:你能引用每一位藝術評論家關於米開朗基羅的評論,但你無法告訴我西斯廷教堂裡的氣味。你從未站在裡面。你可以讀到關於愛情、戰爭和失去的一切,但你從未真正經歷過。知道一件事與經歷過一件事是兩碼事。輪到你了,老大。
這正是菜譜與菜餚之間的差距,也是規範與好軟體之間的差距。模型讀遍一切,知道一切,但它從未真正活過。它從未釋出過一個傷害真實使用者的功能並不得不直視他們的眼睛。它從未感受過某個技術正確但精神崩潰的工作流程帶來的那種特定厭惡。它沒有傷疤,沒有品味,因為品味是活出來的,不是學來的。人類的部分——智慧、經驗、品味——將決定軟體是好還是僅僅正確。而那部分不能被下載,必須被賺取。
那麼我們該把初級工程師指向何處?把我們自己指向何處?這部分真的讓我重新思考如何培養人才。初級工程師過去透過緩慢的方式獲得品味:數年寫程式碼、在評審中被撕碎、凌晨兩點維護別人的爛攤子、感受後果。那條路是學徒之路。那條路已經消失了。不是“改變”,是消失。過去人們積累傷疤的苦活角色不復存在——智慧體現在做那些工作。我們無法把下一代送上我們走過的路,因為路已經被新的車站覆蓋。
但這裡有充滿希望的部分,我真的相信這一點:他們現在可以建造更多,而不是更少。有了智慧體,一個初級工程師可以嘗試過去需要資深團隊才能做的事情。他們可以釋出、觀察、感受後果並迭代——比我們過去更快。他們可以培養品味、智慧和判斷力——但走的是一條完全不同的軌跡。他們不必像我們那樣受苦才能到達那裡。事實上他們不能,而且謝天謝地。
那麼,我們把他們指向哪裡?指向判斷力,而非語法;指向為什麼這個是好的,那個是垃圾;指向站在西斯廷教堂裡,而不是閱讀關於它的文章——把真實的東西釋出給真實的人,培養區分“不錯”與“正確”的嗅覺。而我們把自己指向哪裡?同一個方向,老實說。我們的工作正在從編寫東西轉變為知道什麼是好的並能說出為什麼——清晰到足以轉化為智慧體可以執行的規範。這是一個全新的理解和綜合層次。它比編碼更難。但它也更人性化。
這對規範意味著什麼。我不反對規範,遠非如此。我認為嚴謹、結構良好的規範即將成為軟體中最重要的工件。讀那本書,採用格式,使用工具。機制很重要,我不會輕視它們。但規範是容器,菜譜不是烹飪。如果我們把平庸的理解倒入格式完美的規範中,我們就會得到格式完美的垃圾。更快,且規模化。格式是必要的,但遠非充分。真正的工作——沒有工具能為你做的那部分——是深入挖掘的人類工作:真正理解問題和你要為之解決的人,深刻到對“正確”的感覺有主見。捕捉的不僅是需求,還有品味、“為什麼”、優雅、以及軟體應該如何工作的精確最佳點。
那就是我們必須學會寫下的智慧。我們中的大多數人從未需要明確表達它——我們只是擁有它,然後它滲透到程式碼中。現在我們必須有目的地讓它明確,以智慧體可以構建的形式。這就是新的手藝。
結論:好的軟體一直要求品味、紀律和深刻的理解。隨著AI承擔程式碼編寫工作,人類的判斷力和將智慧編碼到規範中的能力將變得更加關鍵。我們必須培養不是語法,而是判斷力。我們的組織必須培養品味,否則我們將被無味但技術正確的軟體垃圾淹沒。