真不敢相信我花了兩週寫這篇。
上週，我在 Cursor 社群活動上做了一場關於 AI，以及它如何改變我們打造軟體方式的演講。活動辦得很棒，講完之後，有不少人走過來跟我做一對一交流。
其中有一位特別引起了我的注意。他不是技術人員，但他問了我一個很有意思的問題：
「現在有這麼多工具和技術可用，你到底是怎麼在這一切之中導航，並挑選出正確的那些？」
他覺得這一定很令人不知所措。接著他笑著說，既然有這麼多選擇，他希望能做出很多很棒的東西。
我想了一下，也笑了。還沒等我回答，他就得離開了……但他的問題一直留在我心裡。
幾天後，我坐在圖書館裡找書看，意外遇到了一個答案：W. Richard Stevens 的 UNIX Network Programming。（真的是本好書，推薦讀一下！）
90 年代的技術、有限的記憶體、有限的運算能力、有限的頻寬、有限的工具……等等。
但不知怎麼地，我們還是做出了 UNIX、TCP/IP、早期作業系統、令人驚嘆的數學突破、大型工程專案，以及一些有史以來最優雅的技術作品。
這讓我不禁思考：
如果限制我們的東西，同時也是逼我們變得更好的東西呢？
如果卓越不總是來自擁有更多，而是來自被迫用更少做更多呢？
那位先生以為更多工具就代表更接近卓越，但我手中的那本書，恰好證明了相反的事。
限制的悖論
我相信，少一點有時候反而能讓我們變得更好，背後是有原因的。
我們通常把限制看成需要克服的東西：錢更少、時間更少、資源更少、知識更少。所有這些都擋在我們和想達成的目標之間。
但限制還有另一面，只是我們不太常談到。
限制不只是拿走了某些東西，它也拿走了原本本來可能發生的那些事。
而這或許正是我們需要的。因為當一切都可用、每個方向都可行、每種工具都在手邊、每種做法都向我們敞開時，聽起來像是自由。
但沒有邊界的自由，其實出乎意料地難以生活其中。
你給一個人無限資源，他可能會花上一輩子決定要拿它做什麼。你什麼都不給，問題反而突然變得簡單：
我能用手上現有的東西做到多少？
這個問題會改變你的思考方式。你不再尋找完美的工具，因為它不存在；你開始用眼前已有的東西來建造。你會注意到原本看不見的細節，不是因為你天生更敏銳，而是因為你已經沒有忽略它們的奢侈。
也許這才是限制真正的禮物：縮小你的選項，同時磨利你的注意力。
也許這就是那個悖論：我們擁有的門越少，我們就越清楚看見自己正站在哪一扇門前。
順帶一提，這也不是什麼新觀念。
約束會逼出創造力
那本書
先來看看 Stevens 的那本書。這本書本質上就是一份 sockets API 的導覽：socket()、bind()、listen()、accept()、connect()、read()、write()、close()。
這就是讓地球兩端的兩台機器可靠通訊的全部詞彙。
但 Stevens 並不是發明這些呼叫的人。Berkeley sockets 是 1983 年左右，從 UC Berkeley 的 CSRG 在 4.2BSD 裡出來的。Stevens 寫了這本書，教導一整代程式設計師它們實際上是怎麼運作的。
他不是在為一個算力無限的世界設計。那個 API 誕生於記憶體昂貴、CPU 緩慢、連線不可靠、低頻寬的年代，根本沒有犯錯的空間，也沒有空間去做臃腫、什麼都想包進去的介面，或是泛用、什麼都接受的契約。
每個函式都必須證明自己存在的價值。
而在這些限制逼迫之下，設計出來的結果是一個極簡而且高度協作的 API；四十多年後，即使當初那些限制都已不復存在，它仍然是幾乎每一種程式語言在網路功能上會包裝的介面。
看看 Python 的 socket 模組、Node 的 net 模組，或 Go 的 net 套件，它們的形狀都能一路追溯回那大約八個左右的原始基元。
縮影中的悖論：因為沒有揮霍的餘裕去打造一個臃腫的東西，他們只能打造出一個經得起時間考驗的東西。BSD 是在匱乏中把它做出來的；Stevens 則記錄了它為何如此精煉。
當然，這也是我在決定翻開一本 90 年代的書時感到驚喜的原因。我原本以為它會很過時，結果卻從中學到很多，而其中不少內容到今天我仍然可以直接應用在我正在打造的軟體上。
C
一切的起點，也是今天所有事物的基礎。
C 是這裡很好的例子：它是一門極其優雅的語言，卻給你的東西少得驚人。沒有 GC，沒有複雜的標準抽象，沒有保護你與記憶體之間的安全網。你想要什麼？通常得先理解底層正在發生什麼。
以今天的標準來看，我們會說它不安全，或者把這當成它的弱點，但這種限制也迫使你採取某種思考方式：你必須更注意細節，你會對記憶體、資料排列、所有權，以及機器實際在做什麼變得更有意識。
這門語言不會給你太多選項或答案，但它會逼你問出更好的問題，並做出更好、更經得起時間考驗的決定。
Go
讓我們回到未來，看看 Go。Go 走的是另一條路，它的限制不是由硬體強加，而是很大程度上由設計者主動選擇。
在它所處的時代，已經有了各種可用的東西；但這門語言的設計，刻意把功能維持得非常精簡與單純。不論是語法還是型別系統，都盡量減少表達同一件事的方法。
當一門語言給你更少的方法去解決問題，你花在爭論該用哪個聰明抽象的時間就更少，反而能把更多時間拿去真正解決問題。
Go 的克制就是它的特點。它省略了什麼，和它包含了什麼一樣有意義。
音樂
我有彈鋼琴，所以這個例子不是紙上談兵。
今天你可以在筆電上裝一個 DAW、一千個外掛，再加上一個 AI 人聲修音器，然後在任何地方做出一張專輯。到了 70、80 年代，很多工作都是實體操作。磁帶剪錯一段就沒了。軌道有限、錄音室時間有限、器材昂貴。樂團必須真的把段落練熟。一次錄音失誤，有時候大家就得全部重來。
當錄音時間真的要花錢時，你不會花六個小時只為了調一顆小鼓。當你只有八軌時，你會決定哪個東西值得佔一軌。你能在那些唱片裡聽到這一點：表演、瑕疵、以及那些取捨。
我不是主張我們應該回去剪磁帶。我想說的是：這些限制所做的工作，不是無限次復原所能取代的。
擁有一切的問題
豐富有時會帶來自滿、無盡的選擇……也就帶來一種誘惑：用「再多丟一點進去」來解決每個問題。
讓我們回到 AI 這個主題。像現代 DAW 一樣，我相信 AI 是我們工作中很棒的夥伴。但同時，它也在以我們前所未見的速度移除大量限制。
就在幾年前，一個需求功能大概要花 1 到 2 個月。想試不同架構，就是真的得把它做出來。重寫一段程式碼也要時間；如果那段不是我寫的，我還得先理解脈絡。
現在我可以叫 AI 在幾秒內全部完成。過去阻止你的，是成本。當這個成本下降時，很容易就不再問「我到底該不該做？」而只是一直做。你會產生五個版本，而不是選一個。你會再加一個函式庫，因為模型已經懂它了。你會重寫原本可用的程式碼，只因為新的草稿看起來更乾淨。
這個轉變不再是「我能不能做出來？」而是 「我應不應該做？」
當你什麼都沒有時，限制是外在加諸於你的。當你什麼都有時，你必須自己替自己設下限制。
那你該怎麼做
我最後沒有在活動上回答那位先生。如果現在要我回答，我不會給他一份工具清單。
我會告訴他：更多選擇不保證更好的作品，只會讓你更容易一直不做決定。90 年代之所以能產生 UNIX，不是因為人們擁有更多，而是因為他們擁有更少，而更少迫使作品變得誠實。
這不代表要把 AI 丟掉，或是回去剪磁帶，或是什麼都用 C 寫。我的意思是，現在的環境不會免費幫你提供限制了。如果你想要那種被磨利的感覺，你得自己選一個。這週只交付一個使用情境。讓模型去生成那些無聊的部分，核心決策還是交給你。給自己一個醜到不能再拖的期限。
這週就把技術堆疊收斂一下。
原文出處：https://dev.to/adamthedeveloper/greatness-is-forged-by-limitation-e20
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
