9 月 15 日,印度——連同斯里蘭卡與坦尚尼亞——會慶祝工程師節,以紀念 M. Visvesvaraya 爵士的誕辰。他負責了多項重要的灌溉與水資源管理工程,包括克里希納拉賈薩加爾水壩,並率先設計出自動水閘系統,最早安裝於 Khadakvasla 水庫。他從未自稱是開創者。因為他忙著打造那些真的得能蓄水的東西。
我提起他,是因為不知從何時開始,在 AI 程式設計工具與「公開建造」的年代之間,很多人默默拉低了「工程」的標準——而這件事開始顯現出來了。
你一定看過這種模式。某個人把一個提示詞丟進 AI 工具,拿到一個可運作的登入頁,把它部署到免費主機上,到了晚上就開始自稱「創辦人」。沒有做過架構決策。也不知道當免費方案的速率限制被打滿時會發生什麼事。也沒有檢查模型實際寫了什麼。只有一個網址,以及一篇關於「公開建造」的貼文。
問題不在於他們用了 AI。
問題在於,有一個能跑的東西,正悄悄被等同於 理解它為什麼能跑。
這就像向自動販賣機要一罐汽水,然後自稱調酒師。
可怕的地方不是 AI 能在幾分鐘內生成一個可運作的 App——這部分其實真的很棒。可怕的是,在很多人的腦袋裡,「產生出某個東西」與「理解那個東西」正悄悄變成同義詞。快速上線,當然很好。只是別把它跟真正讓你成為工程師的那部分搞混了。
我今年稍早就因為一個很具體的經驗,真切學到了這件事,而且是單打獨鬥。
ShelfTalk 一開始只是大學作業——我在一學期內獨自做完的一個完整 MERN 讀書會 App,做得剛好夠交差,之後就被我丟在 GitHub 上好幾個月沒再碰。GitHub 的 Finish-Up-A-Thon——一個專門鼓勵把 AI 協助的作品好好收尾,而不是半吊子放著不管的挑戰——給了我期限,讓我回頭把它重做成可供正式上線的版本:真正的 Socket.io 聊天,不再只是 REST 輪詢;即時同步的閱讀室;遷移到 MongoDB Atlas 並使用 GridFS;以及從 Create React App 搬到 Vite,將 HMR 時間大約縮短了 80%。
我在 500 多個參賽作品中拿到前 10 名。
{% link https://dev.to/dj29/shelftalk-books-dont-talk-we-do-a-college-project-revived-o4o
真正讓我學到最多的,不是那些成果,而是幾週後在正式環境中冒出來的一個 bug。我為推播通知加了一個我以為很聰明的最佳化——如果分頁是可見的,就不要顯示桌面通知,畢竟沒人喜歡收到一則自己正在看的訊息的提醒。當時我覺得這樣的使用者體驗很乾淨。結果之後使用者開始漏掉私訊,而我自己的測試又無法重現:程式碼的運作完全符合我設計的樣子。
結果那個 bug 藏在一個假設裡,不在某一行程式碼裡。
我的程式默默把「作業系統能不能把這個像素顯示出來」與「有沒有人正在注意」混為一談——任何在第二個螢幕上開著 ShelfTalk 的人,都會無聲無息地漏掉每一則通知,因為從技術上來說,只要分頁在畫面中可見,就算「可見」,即使其實已經二十分鐘沒人看它。最後的修正,就是刪掉我原本引以為傲的那個最佳化。多發一點點重複通知,只是有點煩;默默漏掉訊息,則是產品壞掉了。
這個 bug 在 demo 裡完全看不出來,而你也不會只是靠一路提示詞就把這種問題找出來——我之所以能發現它,是因為有使用者抱怨,然後我得一直盯著「它的確完全按照設計在運作」這句話,直到意識到設計背後最核心的假設其實是錯的。
Copilot 幫我完成了不少 ShelfTalk 重做的工作——它幫我搭起 socket 事件處理器、在 Vite 遷移時抓出 import 錯誤、也自動補完了一些我原本也會手動查找的 UI 模式。可是我不會把那稱作「vibe coding」,因為我批評的那種 vibe coding,跳過了你發現自己的專案其實壞掉,然後還得在壓力下把它修好的那一段。
那一段——檢查、除錯、真正知道自己做了什麼的那一段——才是整個工作本身。那是我一個人做的,沒有人可以幫我抓漏。Visvesvaraya 面對混凝土與鋼鐵時是如此;現在即使有 Copilot 幫忙打一些字,這件事仍然一樣成立;而在第二個螢幕上一個愚蠢的布林值問題上,這道理同樣沒有改變。
我不認為問題在 AI。我認為問題在於:我們變得太容易跳過那個讓你成為工程師的部分,卻還保留了讓你聽起來像工程師的部分。
AI 並沒有消除工程工作。它只是讓人更容易假裝自己做過。
所以我直接問:你會把「使用 AI 來打造某個東西」和「只是看著 AI 幫你打造」的分界畫在哪裡?
你有沒有曾經發現自己站在那條線的另一側? 👇