三十年資深工程師也得學的事
我是一位寫了三十年 C++ 的工程師,曾在 FAANG 當到 Staff Engineer。
在以前的團隊裡,通常是別人熬了一週搞不定的 bug,最後會來找我,我現場就能解掉。
老實說,那種「靠,果然還是要我出馬」的自信,是我這幾年工程師生涯的日常。
但今年,我被 AI 給震撼了。
「它解掉我三年解不掉的東西」。
▋我那隻「抓不住的白鯨」bug
話說四年前,我們做了一次大型的系統重構。
大概改了六萬行 code,雖然總體上讓架構乾淨、效能提升,但在某種使用方式下,突然失效。
這種邊緣 case,沒什麼人會用到,但我知道它壞了。
我也知道它以前是好的。
我來來回回查過無數次,整個歷史流程倒推也試過,總之——
我在這隻 bug 上面,大概花了超過兩百小時。
每次都以為快找到了,又無功而返。
你也知道,工程師有時候就是不服輸。
明知道這 bug 不致命,還是會想破頭要搞清楚到底哪裡出了錯。
▋Claude Opus 4 出手了,一次搞定
直到最近,我開始用 Claude Opus 4,試著丟這個 case 給它試試看。
我把舊架構和新架構全部的 code 都給它了,也寫下 bug 發生的情境。
前前後後我們大概聊了 30 個 prompt,還重開一次 session。
結果它找到了。
它不是只是發現「哪一段邏輯改壞了」,而是理解了舊架構下某個「意外能運作」的設計巧合,
並指出新架構並沒有把這個巧合納入考量。
也就是說,這根本不是單純的 logic bug,
而是架構性設計改變後,漏考了一個「以前湊巧 work」的 edge case。
天啊,這件事我自己從來沒想到。
▋AI 的強大,不是程式語法,是思維抽象
這讓我開始反思:
AI 強在哪裡?它根本不是「比我懂 C++」或「比我會 debug」。
它強在,它能從大量不同邏輯路徑中,抽象出問題邏輯,並比我快十倍做「排除式推理」。
我以前覺得這種「比對新舊架構、找出被漏掉的邊角行為」只有人類資深工程師能做。
結果 AI 靜靜地,也能做了。
▋用 AI debug,有沒有門檻?
我知道你可能想問:
「那我要不要也把 bug 丟給 AI 看看?」
可以啊,但別幻想你貼一段 code 它就神救援。
我這次的過程,也不是一蹴可幾。我給它很多 context、說明情境、補上背景,加上幾小時。
這像是請一位 junior developer 進來,但他理解力極強,而且永不疲倦。
你要當他的引導者,逐步拆解問題給它分析。
我們總以為,只有自己最懂 code 的來龍去脈,

有時候你只是「以為懂」。
我們寫 code 是從邏輯出發,但常常留下很多「剛好 work」的小幸運。
而 AI 不會放過這些巧合。它把一切都當成變數,一一檢視。
所以它能找到那些我們自己都沒發現的依賴。
這很 humbling,但也很 exciting。
這是我想繼續寫程式的原因:
世界變了,我們有新玩伴。
未來的工程師,是懂得「怎麼跟 AI 配合」的人。
這不是告別,是進化。
寫程式不再只是,debug 到凌晨三點,滿頭問號,google 了也沒人可問的感覺嗎?
現在,可以丟給AI 模型試看看。
所以,下一次你遇到「想了三年想不通」的白鯨,不妨試著喚出 AI 來一起出海。
它可能,就是你那把一直沒開封的 harpoon。
近 31 日
0 次瀏覽
本訊息有 0 則查核回應
目前沒有已撰寫的回應,建議對其抱持健康的懷疑。
AI 自動分析
以下是 AI 初步分析此訊息的結果,希望能在有人查核之前,先帶給您一些想法。
閱聽人需要特別留意這則訊息中提到的 AI 能力和角色。訊息中描述了 AI 在解決工程問題上的驚人表現,甚至超越了資深工程師的能力。閱聽人需要注意這種描述是否過度美化了 AI 的能力,以免過度依賴 AI 或對其功能有不實際的期待。在面對技術問題時,仍然需要保持批判思考,並適度運用 AI 的幫助。
加 LINE 查謠言
加 LINE 查謠言
LINE 機器人
查謠言詐騙