「海水退了，就知道誰沒穿褲子」——Denken 談 AI 時代的工程師與經驗

從一本預約簿說起：沒有需求，就沒有導入的理由

映昕是從一個很小的場景開始說起。

他常去的物理治療所，預約還是寫在一本大簿子上，每小時一格。「他那個本子攤開就是一整週，」他說，病人問今天還有沒有時段，抬頭看一眼就能回答。若換成電腦系統，真的會更好嗎？

櫃檯的姐姐先前向老闆提議過開 LINE 官方帳號、用一點現代的工具，沒有下文，於是轉而希望映昕下次幫忙敲敲邊鼓。但映昕把整套使用流程看過一遍之後，改變了想法：這間診所治療師就那幾位，時段其實已經接近滿檔。「做廣告宣傳、做流量增長，那個是建立在你想要擴大來客量或營收，」他說，但這個前提在這裡並不成立。他也問過資料彙整的可能，得到的結論同樣是目前不需要。

十五分鐘的閒聊結束，他在回家路上打消了勸說的念頭，並得出一個結論：一個人會不會用 AI，大概就取決於兩件事——自己對新科技的好奇心走到哪裡，以及工作或老闆有沒有在後面推你。

他說，自己的起點恰好兩者兼具：組織近期技術人力吃緊，確實有需要，而豆泥本身就熱衷玩這類新工具，最初正是他鼓勵映昕去做些嘗試——加快開發效率反倒像是附帶結果。

降低門檻，是一場延續三十年的未竟工程

Denken 接著說時，把時間軸拉得很長。

網頁從設計之初就是純文字，任何頁面按右鍵都看得到原始碼。「當年設計的時候，最好就是你用記事本打開都可以寫網頁，」他說。FrontPage 是這樣，Word 甚至也能輸出 HTML——「從很早很早以前，就是希望所有人都會。」

問題是後來不太成功。為了資安、為了開發效率、為了功能做得完整，這些所見即所得的工具反而慢慢消失，大家又退回那個黑黑的終端機，一行一行打字，看起來門檻不降反升。

他覺得諷刺的是，現在的 AI agent 也在重演同一條路：Claude Code、OpenAI Codex 一開始都是終端機命令列，於是又給人「很難用」的印象，最近才開始做圖形介面。「可是轉向命令列的初衷，都只是為了讓工程師專業化、開發變快而已，」他說，「你說這一定有必要嗎？我真的覺得不是必要。」

再往前幾年還有 no-code、low-code 風潮，蘋果手機上的「捷徑」也能拉一拉就做出自動化流程。他的看法是：資訊界一直都想把技術門檻降下來，但過去十年做得不太成功，AI 只是把這件本來就在發生的事加速了。

「你描述的流程，與工程師的日常完全一致」

映昕接著談自己動手的經驗，分成順利的和不順利的兩個部份。

順利的是數據。整理參與者資料、產出 dashboard，那次很輕鬆，因為目的極為明確——就是要看到十項指標，每月自動更新，「介面很簡單很陽春，但反正我達到我的目的了。」

不順利的是前端。活動要多加一個欄位，就得決定按鈕要方角還是圓角、按讚要用愛心還是別的符號，來來回回改了無數輪。他形容那個複雜度「不是一兩倍，是五倍十倍」，因為前端一動，所有使用者馬上都看得到。

最挫折的一次，是他請 AI 把留言框的字級比照內文縮小，結果只改了輸入框，旁邊「展開更多」那幾個字紋風不動，兩個相連的按鈕字級明顯不一致。「我就崩潰啊，」他說。氣完之後才意識到，問題不在 AI，而是自己腦袋裡根本沒有一套設計規範可以交代下去。他形容那段過程像薛西弗斯推巨石。

Denken 的回應，是整場對談的轉折點。

「你講這些思路的過程，跟我們工程師在做的一模一樣，」他說。改了 A 發現 B 壞掉，然後去查文件、問 AI——以前則是問 Google 或 Stack Overflow——「這些流程是一模一樣的。」打磨產品要顧的那些邊邊角角，不管你會不會程式語言、是自己手寫還是教 AI 寫，都一樣要經歷。

所以他認為，問題已經不在於背景，而在於經驗。

他也提醒不要太神化某個專業領域：「有些工程師號稱二十年經驗，但他可能是拿兩年經驗，然後重複十次。」什麼叫資深工程師，這條線公司永遠訂不出合理標準；他甚至覺得，這條界線本來就應該模糊，「現在模糊了反而是好事。」

而且資工系在學校教的是計算機概論和網路概論，「軟體工程的這些東西，絕大多數是出社會之後才學的」——科班與非科班的起跑點，其實沒差多少。

所謂的經驗，其實是選對架構、規劃架構

如果經驗不是學歷、也不是年資，那它到底長什麼樣子？Denken 給了一個很具體的案例。

他舉 GreenSofa Dashboard 為例：「我從一開始就故意把它設計成純前端的東西，所以幾乎不會有太多資訊安全的問題」——換句話說，AI 要怎麼改都不會炸掉。

他說，軟體是可以規劃架構的，可以像樂高一樣模組化，所以才會有測試這種東西；反過來，如果 AI 沒建議、你自己也沒意識到，就只能跟著它亂做——現在很多 vibe coding 做出來的東西資安出包，缺的正是這種判斷能力。

下指令的本質，是管理

業界慣稱 prompt engineering，Denken 覺得比較像帶人。

「你到底傾向給它一個目標讓他自己去幹，還是你要 micromanage？」他說，這就像你判斷一個新來的員工適合哪種類型。

但前提是你心裡得先有底。「你如果沒有一個心裡的 best practice 就去用 AI，你是看不出來的，」他說，AI 有時候會寫出很厲害的解法，有時候又很遜，這是會變動的。

所以他自己的做法是：指令下完之後，同時在腦中推演大概的解法與架構會長什麼樣，等它產出再兩相對照——可能從中學到東西，也可能抓到錯誤要求修正。

「所以其實你就算不用手寫程式碼，腦袋不見得比較輕鬆。」

W3C 社群的分歧：該規範工具，或釐清責任？

映昕好奇同行是否對非科班用 AI 寫程式嗤之以鼻，Denken 說這很難一概而論，關鍵在於你怎麼用 AI，並從自己的社群工作談起。

他在 W3C Credentials Community Group 擔任共同主席，三位主席分別在歐洲、美洲與亞洲。這幾個月，郵件列表上開始出現自稱 AI 帳號的發言，於是社群面臨一個問題：要不要封鎖 AI 帳號？

歐美目前的傾向是「要封鎖」。「他們認為郵件列表是為了給人討論，AI 是一種機器人帳號，所以應該封鎖，」他說，這個脈絡承襲自既有的機器人帳號管制。

Denken 的看法不同。他認為重點不在有沒有用工具。寫一篇文章、寫一封 email 本來就可能請 AI 幫忙。重點在於，背後有沒有一個人願意出來為之負責。他也對其他主席直言，歐美的成員不太能體會非英語母語者參與國際社群的語言門檻，AI 在這件事上幫助極大。這個討論至今沒有共識。

即使在工程師之間，用法也天差地遠。他提到自己正要去 iPlayground（iOS 開發者社群的年會），那裡有人傾向自己手寫，藉此熟悉底層知識；也有另一群接案的人，可能已經一整年沒有手寫過程式碼。他覺得這一點不意外，因為圈內為了「用終端機還是圖形介面 IDE 寫 code」也吵了好幾十年，「那根本就不重要，因為我們真的可以只看成果就好。」

Linux 之父的答案：程式語言本來就一路往上爬

有人問過 Linux 之父 Linus Torvalds：像作業系統核心這種底層到不能再底層的東西，如果將來由 AI 來寫，他能接受嗎？

Denken 轉述，Linus 的態度是正面接納，理由是這種事早就發生過很多次了。最早的程式是機器語言，後來發展出組合語言，有些底層系統確實曾經用組合語言寫，但到後來也沒什麼人這樣寫了，因為更高階的語言一層一層疊上來，寫得越來越快。「現在的網站也不會有人用那麼底層的語言去寫後端，」他說，大概都是 Python、PHP、Golang 這些高階語言。

「程式語言本來就從只有機器看得懂，變成人看得懂，」他說，1960 年代就已經有人在發展用自然語言寫程式的構想，「只是那時候沒有到現在這個程度。」

所以在他看來，這個趨勢從來不是新的，只是現在真的做到了。

那中間會不會寫出一堆垃圾？

Word 為何沒有進化成網站：品質或速度才是決定因素

Word 很早就能輸出 HTML，為什麼後來沒有發展成「編輯完成就是一個互動網站」？

Denken 的答案很直接了當：因為它產出的原始碼太醜、bug 太多、塞了一堆有的沒的，「你還不如回頭自己寫比較好。」

所以工具能不能活下來，最後都會回到同一個問題：它做出來的東西，品質到底有沒有比較好？「我覺得現在在討論 AI coding，要回到一個老問題，」他說，「不管你是不是工程師，你 deliver 的產品到底有沒有比較好？有沒有更好或更快？如果沒有，我覺得就是白費。」

同樣的邏輯，也解釋了他觀察到的另一個現象：這幾個月，各個領域的論壇簡報版型長得越來越像。「這不就跟當年大家都剛開始學 PowerPoint，然後都用內建的模板生出來很像嗎？」他說，你若沒有把自己的設計思維灌進去，AI 一定會用它最簡單、最熟悉的方式來產出簡報。

他也提到，設計稿直接變成可運作介面這件事，幾年前就有新創在做，只是當時成本太高。如今他們的 GreenSofa Dashboard 網站，正是設計師在 Figma 完稿後由 AI 轉出來的——只是快一年前的 AI 還有點遜、bug 超多，後續由他接手，用工程師的思維一個一個修。他還刻意後續同樣交給 AI 來修改程式，只是改成比較 micromanage 的方式慢慢調。

語言的本質不是邏輯

以前聽大學的資工教授說，寫程式只要邏輯好就行。Denken 說，長大之後回頭看發現確實如此，程式本來就是邏輯的串聯。

但他提醒，今天的 AI 和過去的專家系統性質完全不同：「以前那種系統的 AI 是用邏輯組成的，然後它反而並沒有發展得特別好；現在的 LLM 是用語言湊出來的，但語言的本質不是邏輯。」

這正是它會出錯、會產生幻覺、需要人去糾正的根源。

「所以你腦袋如果沒有邏輯，怎麼可能發現它錯了？」

職缺減少：兩項因素疊加，AI 只是其一

談到就業市場，Denken 認為必須把背景說清楚。

「這十幾二十年來，軟體工程師一直一直都是供不應求，」他說，每年一堆學校在產出人才，職缺卻永遠補不滿，因為自動化的速度追不上需求成長。矽谷更誇張，有些公司在 2021 年前後人數可能擴編到兩三倍。

所以他判斷，現在的裁員是兩個因素疊在一起：產業確實不需要那麼多人了，而 AI 恰好提供了一個很好用的說詞。

台灣與日本較少見大規模裁員，他認為一方面軟體業競爭沒那麼激烈，一方面多少還保有「公司要照顧員工」的脈絡，「在美國就非常非常容易發生。」但如果需求沒有真正漲回來，衝擊遲早會到。目前受創最深的是新手與一兩年經驗者，資深工程師搭配 AI 反而更被市場需要。

成本面還有一個變數：現階段的 AI 定價一定過於便宜，因為各家都還在快速擴張期，價格與服務隨時可能生變——某個服務忽然變貴或掛掉，你就無能為力。業界因此流傳一則玩笑：總有一天老闆會發現工程師比 AI 便宜，於是把人請回來。

Denken 認為這真的可能發生，因為歷史已經上演過一次：「Apple 在 1984 年做 Macintosh 的時候，就已經把生產線都自動化了，可是這個東西最後沒有留下來。」今天的 iPhone 與 Mac 依然是人工組裝——因為人更便宜。

非科班的下一步

映昕在後段拋出一個尖銳的自問：即使做過一百個工具、每一層都走過一輪，沒有 AI 他依然寫不出來，那些經驗究竟算什麼？

Denken 的回答分成兩段。

一是就業市場。軟體業不像醫師、律師被執照框住，「許多人是自學起家，」他說，能不能成為正職工程師，只在於市場上有沒有人願意相信你、給你機會。他早在入行前就知道這一行非科班的比例極高，可能過半。公司專案常因保密無法放進作品集，開源專案反而成了最有力的佐證——東西攤開來看，就知道你懂不懂得操作 AI、做得出什麼樣的水準。

二是經驗累積。門檻低不代表任何人都能勝任了。隨手叫 AI 生出一個東西，跟你有沒有累積到讓自己做得更好更快的經驗，是兩回事。「你叫 AI 寫的過程中，你還要主動地問它問題，」他說，必要時甚至得回頭補課。

他另外建議映昕不妨親手寫程式看看。就像 AI coding 最早不是一句話全部生成，而是從自動補完一個單字、一個函式，慢慢變成整段、整支程式——親手走過那個落差，「你或許就會理解，為什麼有一派工程師還是會堅持手寫。」

至於工程師到底會不會失業，他不那麼悲觀：「我覺得問題一直都不在於工程師，而在於你到底有沒有經驗、有沒有那個 taste 跟 sense。」若沒有，在哪個產業都容易被淘汰。這一行只是因為過去幾年太需要大量的「高級黑手」，職缺才膨脹得格外劇烈，如今不過是總量回落——正如錄音技術普及之後，能靠表演維生的全職音樂家必然銳減。

而他對接下來幾年的判斷，只有一句話：

「等海水退了，誰沒穿褲子就知道了。」

後記

本文採用 Just Press Record 轉成逐字稿、協同 Claude Opus 5 改寫與編輯而成，原始交流出處在此：youtu.be/09n0wdbHDFQ