🔧 阿川の電商水電行
我最近為 Nudges 提交的 PR是 +96 -312，修改了 38 個文件，大約 90% 的程式碼都是基於 vibe 風格編寫的。我對它很有信心。
當我在海拉爾大陸上自由馳騁時，兩個不同的 AI 代理正在悄悄地重構 Kafka 消費者，驗證有效負載形狀，並提交更改——乾淨、範圍明確且已準備好投入生產。
回來後，我瀏覽了差異，對函數名稱表示認可，仔細檢查了一些關鍵點，然後告訴 Claude Code 提交一個 PR。
關鍵是：感覺很好。
因為在這個系統中，人工智慧不僅僅是在猜測——它是在我有意建立的系統中運作的。
我擁有系統的架構、訊息格式、遙測資料以及所有後果。
Nudges 是我的。所以當程式碼自動生成時，感覺就像是我意志的延伸。
但在我的合約中，同樣的體驗——人工智慧作為共同開發者，無縫且快速——感覺卻完全不同。
因為在那裡，我並不擁有那個系統。
我什至不信任這個系統。
我是一名承包商，正在處理 30 萬行幾乎無法正常執行的程式碼，建築債務以年為單位計算，每一次「改進」都可能導致連鎖故障。
在這種背景下，人工智慧並不能讓人感到賦能。
它感覺就像一道抵禦認知超負荷的屏障。
它仍然會編寫程式碼。
但我不可能總是顧及程式碼是否是最好的。
而這——比其他任何因素都更甚——正是這個新時代的弔詭：
人工智慧消除了摩擦。
但摩擦曾是我們決定什麼才是最重要的。
副駕駛時刻
這一切都源自於一張不該存在的票據。
客戶希望使用者介面在表單處於特定狀態時發出警告。其中一個表單的規則與其他十幾個表單的規則重疊。
簡直一團糟。邏輯混亂，命名規則不一致，再加上多年來「我們會在下一個版本中解決」的技術債務，簡直雪上加霜。
我打開了 React 元件。 1100 行程式碼。大部分都是條件語句。
沒有測試覆蓋率。沒有文件。只有感覺和嵌套的三元運算子。
我打開了 Copilot，按下Win+H ，然後開始說話。
我解釋了我想要達成的目標、它的重要性以及在哪裡可以找到相關背景資訊。
然後我向後靠去，揉了揉眼睛。
其餘部分由人工智慧代理編寫。
一套全新的變數和檢查。
每一條都牢記於心。每一條都具有防禦性。
每個語句都具有足夠的語義分量，使我能夠繼續進行下去，而無需重構整個程式碼。
而它的魅力就在於：它比我所能寫的更精準。
因為我累了。
因為在編寫程式碼三十年後，當 AI 的「額外工作」在技術上是正確的，我並不總是能做到「正確」的做法。
所以我把它留下來了。我檢查了一下。它能用。
程式碼運作良好。
差速器看起來很專業。
但我內心深處知道，我只是在一個原本應該有 300 行的文件中加入了 30 行。
我一直在延續不良習慣。
關鍵是什麼？
我提交了PR。
因為這是正確的。
因為那樣就少了一件需要擔心的事。
認知演算
我本來可以把它提取出來的。
本來可以把驗證邏輯拆分成一個獨立的模組，搭建一個測試框架，然後把所有程式碼都組織好，讓讀者只需要「參考文件」就能理解。說真的，我自己都寫出來。
但那樣的話，就需要花兩個小時來弄清楚這團亂麻。
而我需要的是十分鐘的勢頭。
這就是現在的計算結果。
在某些合約中，我每週都要做出幾十次這樣的權衡：
-
正確的方法：提取、記錄、測試——2 小時。
-
「夠好」的方法：保持命名簡潔，確保功能正常，發布－5分鐘。
-
每週要做無數個決定，把這個數字乘以這個數字。
你開始看到它的形狀了。
我不寫人工智慧程式碼，因為我自己不會，或因為我懶惰或不在乎。
我利用人工智慧進行寫作，因為我已經學會如何最有效地利用我的精力。
而遊戲規則也正是在這裡改變了。
因為現在做「夠好」的事情太容易了。
它提供簡潔的名稱、智慧的保護機制和可重複使用的模式。
五分鐘的路程看起來像兩小時的路程——直到你縮小畫面。
這就是危險所在。
你會不知不覺地發現自己正在進行緊急救治。
因為這些繃帶看起來像真皮膚一樣。
模式複製器
用理查德·坎貝爾的話來說：“計算機是放大器。”
所以讓我們把話說清楚：
人工智慧並不會改進你的系統，它只會延續你的系統。
如果圖案清晰，清晰度就會提高。
如果這種模式被打破，功能障礙就會擴大——這種功能障礙以優美的格式和語義化的名稱來描述。
這就是危險所在。
它複製一切：
-
應該作為服務的內聯函數
-
元件上的防禦性屬性應該刪除
-
你原本打算以後再修復的模式，現在卻已經根深蒂固地融入每一行新行了。
而且它毫不費力地就做到了。
因為程式碼看起來沒問題。
沒有異常情況。沒有拼字錯誤。
就像一群微妙的異類互相堆疊，直到你被清晰卻錯誤的邏輯所掩埋。
你曾經有過這種感受──曾經與這個體制抗爭過。
現在系統像在軌道上一樣平穩地向前執行。
如果你不注意，它會把你帶到你從未想過要去的地方。
對比
差別不在於工具。
關鍵在於語境。
在 Nudges 中，我擁有整個系統。
我關心它的建造方式，因為六個月後我還會待在裡面。
每一個事件、每一個主題名稱、每一個模組邊界──都是我一手打造的。
所以當人工智慧加入某些東西時，我能立即看出：這應該放在這裡嗎？這符合我想要建置的系統的目標嗎？
如果不行呢？我就停下來。我把它調整好。我把它重新擺正。
因為我希望它能保持住。
從這個角度來看，人工智慧是醫療服務的擴大機。
它讓我能夠在不降低標準的前提下更快地前進——因為這些標準從一開始就融入設計之中。
但在我的合約工作中呢？
我不擁有這個系統。
我繼承了它。
我把它修補好了。
當人工智慧提供解決方案時，我不會停下來問“這是最佳實踐嗎？”
我問： “這行得通嗎？能成功嗎？能經受住下一次合併的考驗嗎？”
因為這就是工作內容。
因為關心他人的成本高於堅持正確的成本。
而且無論哪種方式，獎勵都是一樣的。
這跟技術無關。我年紀不大，速度也不慢。
改變的不是我能做什麼，而是我選擇做什麼，何時去做。
機器中的幽靈
我合併了Nudges的那個 PR。就是那個代理人在我玩遊戲的時候寫的 PR。它很棒，也很合適。但它之所以合適，是因為我花了兩年時間建立了讓它合適的約束條件。
明天，我又要處理客戶的另一個工單了。我會打開一個散發著2018年氣息的文件，然後後悔不已。我可能還會讓AI來修補一個我本來應該從源頭解決的漏洞。結果肯定很糟糕。但「差不多就行了」。而這正是這套系統應得的。
因為如果程式碼能自動生成，我們就無需觸碰鍵盤。但我們的指紋卻無所不在。
原文出處：https://dev.to/junothreadborne/the-vibe-coding-paradox-i31
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
