前言

你好，我是 Watanabe Jin（@Sicut_study）。

隨著 AI 代理開始參與開發，許多工程師也開始使用 Claude Code 等工具推進工作。

然而，在感受到便利的同時，你是否也曾有過這樣的瞬間？

• 當被要求解釋「為什麼會這樣運作」時，卻卡住說不出來
• 最近常常覺得自己是不是會被 AI 搶走工作
• 和一年前相比，感覺不到自己的能力有成長

我在經營程式設計社群、以及在大型新創公司工作的過程中，感受到即使在 AI 正式普及的這半年裡，工程師的職涯也已經明顯分化。

有些人一邊使用 AI，一邊仍持續用自己的頭腦思考「應該解決什麼問題」，能力也持續提升。
另一方面，很多人把「對 AI 下指令」本身變成了工作，回過神來時，已經陷入「看起來有在思考，實際上卻沒有真正思考」的狀態。

因為 AI 加速了開發速度，思考的時間變少了，於是只顧著把任務做完，卻無法累積真正的技能。

這次，我想談談這個分岔點的真正原因，其實在於具體與抽象這種思考能力。

為什麼具體的工作會這麼多？如果從工程現場來看，就會發現那並不是你的能力有問題，而是產業結構本來就如此。

當 AI 疊加在這個結構之上時，會消失的是什麼，又會留下什麼？
到了現在這個可以寫程式的時代，自己的工作到底是不是「非你不可」的工作，反而變得更加清楚。

在這半年觀察了很多工程師之後，我深切感受到：現在正是工程師能否真正發揮價值的分水嶺。

為什麼系統開發中有這麼多具體工作？
AI 真的會讓工作消失嗎？
要怎麼做，才能成為能真正發揮價值的工程師？

接下來我會以「具體與抽象」為核心來展開說明。

影片也有解說

這篇文章的內容也有準備成影片教材，歡迎一起觀看。

本文適合的對象

• 在 AI 已經可以寫程式的現在，對自己的職涯感到某種不安的人
• 想深入設計與上游工程，卻不知道該學什麼的人
• 聽過「具體與抽象」這個詞，卻不知道如何應用在實務上的人
• 想從初階進階到中階、從中階進階到資深的人

為什麼 AI 會讓工程師的工作消失？

不安的真正原因，不是工作會消失。

而是具體的工作，一直以來在產業結構上就占了很大比例。

在系統產業裡，SIer（系統整合商）的商業模式非常常見。
也有許多人以 SES 派遣的形式工作，他們占了工程師族群中的很大一部分。

SIer 的商業模式有時會被稱為「人月生意」。
它是以「1 位工程師工作 1 個月的成本」作為單位，用「人月單價 × 人數」來計算營收，這和營造業的工數計算非常相似。

這種結構也被稱為「IT 總包商」。
和營造業的總包商一樣，承接案件的總包方會把工程拆分後，再重新發包給下游廠商，形成多層結構。實際動手做的人，往往是三包、四包的下游廠商，或是 SES 工程師。總包方則負責專案整體管理、需求定義、基本設計等上游（抽象）工程，而實際開發作業中的大部分（具體）則委託給下游廠商。

也就是說，上游（抽象的問題發現與設計）由總包方負責，下游（具體）由下游廠商負責，這樣的結構本身就已經被寫進產業機制裡了。

在 SIer 裡，照規格書做事就是對的；即使有人提出「這段程式碼改成這樣會更好」的意見，也常常會被否決，並被要求「照交辦的做就好」。

大規模系統會投入大量人力，這就是過去日本 IT 產業的體質。

然而，AI 已經開始取代這個「具體」的部分。
撰寫程式碼這件事本身，現在已經確實正在被 AI 逐步奪走。

我想，幾乎每位工程師都曾想過一次：「我們的工作會不會消失？」
那麼，工程師的工作真的會消失嗎？

我不這麼認為。
相反地，我認為工作的總量還會增加。

每次效率化，工作都會增加

經濟學中有一個很有名的法則，叫做「傑文斯悖論」（Jevons paradox）。

原本蒸汽機變得更有效率後，煤炭消耗應該會減少，
但實際上卻是爆炸性增加。

因為效率提升後，使用場景變廣了，整體消費量也跟著增加。
這是 19 世紀英國經濟學家威廉・史坦利・傑文斯提出的觀點。

其實，這件事在工程師的世界裡也曾一再發生。

諾伊曼型電腦剛出現時也是一樣。

當時，「電腦」這個詞指的不是機器，而是負責計算的人類職業。
也就是把彈道計算、天文計算等工作以人工方式分工處理的計算人員。
在 ENIAC 時代，程式其實就是重新插拔配線板上的纜線。
要修改一次，往往得花上好幾天。
就在這樣的世界裡，諾伊曼提出了把程式放進記憶體中的「程式內建式」架構。
從此，不需要重新配線，只要寫程式機器就能運作，計算立刻變得更快也更便宜。

「計算人員」這個職業確實消失了。
計算工作被機器接手了。
但也因此，寫程式的人誕生了，能使用電腦的場景本身也大幅擴張。

之後，大約每十年就會發生一次類似的事情。

1950 年代末期，FORTRAN 和 COBOL 出現時，第一次出現了「程式設計師不再需要」的說法。
COBOL 的語法接近英文，當時甚至被稱為可以自動寫程式的工具。
大家認為，即使是行政人員也能寫程式，程式設計師會消失。

1990 年代，Visual Basic、Delphi 這類 IDE 工具登場。
介面可以用拖拉的方式組裝，於是又有人說：「這樣不就不需要程式設計師了嗎？」

但結果正好相反。

在美國，以程式設計師與分析師為核心的電腦專業人才，從 1960 年約 1.2 萬人，增加到 1980 年約 58.5 萬人。
因為寫程式變簡單了，所以能導入軟體的地方變多了、需要修正的地方變多了、要做的東西也變多了。
到了 COBOL 的時代，程式設計師的工作從「理解機器」轉向「理解商業」，也就是往更抽象的一層移動了。

換句話說，AI 也在這條延長線上。

NVIDIA 執行長黃仁勳在 2024 年曾說過：

接下來不需要 Python 也不需要 C++ 了，只要用一般人的語言就能驅動電腦。

這和 COBOL 當年「只要寫英文，行政人員也夠用了」的說法，本質上是一樣的。

每次效率化，工作都會增加。這次也一樣。

你或許會覺得，只有這次的 AI 不一樣。
但過去的工程師，也都曾這麼想過。

工程師正從「工作」轉向「任務」

工作的總量會增加。
但增加的內容，並不會和以前一樣。

增加的是，需要大量人力的任務。

例如：確認 AI 寫的程式碼、串接、修正、維運。
這些工作被切得很細，必須投入大量人力才跑得動。

相對地，能夠自己決定「到底應該解決什麼問題」的人，會變得非常少。
而這，正是過去工程師的工作。

其實，現在工程現場也正在發生同樣的事情。

過去工程師的工作，是理解需求、思考設計、實作、驗證運作。
這是一連串需要靠自己大腦串起來的工作。
發揮思考力，也就是創造力的場景，散布在各個地方。

但現在，AI 會先把那個「思考」部分做完。
人類反而比自己想像中更少思考了。
把提示詞丟給 AI，接收產出，再丟下一個提示詞。
這正在成為工作的核心。

而且，開發速度會越來越快。
越是要求快速完成，就越會壓縮停下來思考的時間。
工作逐漸變成只是消化眼前的任務。
像過去那樣一邊思考一邊工作，從環境本身來說，已經變得不太可能了。

覺得變快了，和實際上理解有沒有變深，是兩回事。

Meta 針對有實務經驗、且正在使用 AI 工具的開發者所做的隨機對照試驗顯示，開發者雖然主觀上覺得自己變快了，實際上卻慢了 19%。

關於這點，我之前也製作過一支影片，從現代角度重新思考 t-wada 老師所說的「品質與速度」，請一定要看看。

我也越來越有種連思考都嫌麻煩的感覺。
甚至不再想認真看 AI 寫出來的程式碼，回過神來時，就是先讓 AI 幫我處理；出了問題，再讓 AI 幫我修。

我想，接下來等待我們的，很可能是：修正 AI 寫出的複雜程式碼，而且自己其實根本沒有寫過。
要修正就必須來回溝通，錯誤或 bug 一出現，就只能丟提示詞去修。
這是一種非常耗時的任務。
因為自己根本不理解程式碼，所以也沒辦法避免。
這類工作，就是需要很多人力，所以會增加。

增加的是任務。真正負責解決問題的工程師，會變得極少。

這種狀態其實有名字。
Audrey Tang 曾把「AI 負責思考、人類負責服從」的狀態稱為「逆半人馬」（inverted centaur），並提出警告。

半人馬（centaur）是指人用腦思考、機器提供力量的狀態。
逆半人馬則是指機器決定，人類只負責當手腳。

如果你只是把提示詞丟給 AI，接收產出，再丟下一個提示詞；
頭腦是 AI，只有手腳是自己——那就是逆半人馬。

那麼，你究竟會成為哪一種呢？

什麼是具體與抽象？

看見這個分岔點的視角，就是具體與抽象。

你是在操控 AI，還是被 AI 操控？
差別就在於，你是否站在更上一層樓。

柴犬、貴賓狗、三花貓，彼此都是不同的一隻，這就是具體。
而將這三者共同的特徵抽取出來，稱為「動物」，這就是抽象。

不過，關於具體與抽象，我想再進一步說明三個性質。

第一，具體與抽象之間沒有絕對的分界。

寫過《具體與抽象》一書的細谷功提出了一個問題：「飯糰到底是具體還是抽象？」

如果只看眼前一顆用保鮮膜包起來的鮭魚飯糰，那它就是具體。
但「飯糰」這個詞本身，也是從無數個飯糰中抽出共通點後形成的抽象概念。
再往上一層看，飯糰是「米飯料理」的一種，也是「碳水化合物」的一種。

也就是說，具體與抽象不是非黑即白的分類，而是像階梯一樣層層疊疊。
在某一層看起來是具體的東西，往上一層看，其實它本身就已經是抽象了。

第二，很多討論會卡住，原因往往是雙方在不同階層說話。

例如，對「應該更細心地工作」這種高抽象層次的主張，對方回問：「具體是指哪一個任務？」
兩邊都沒有錯，卻就是對不上話。
這是因為一方站在階梯上層，另一方站在下層。

在工程現場，這種溝通落差也很常見。
當有人問「為什麼要這樣設計？」這種高抽象層次的問題時，對方卻只能回答「這個方法我是這樣寫的」這種具體層次的內容。
如果一直停留在不同層次說話，就永遠無法對焦。

第三，上層是從下層看不見的。

細谷先生把這稱為「單向鏡法則」。
站在高抽象層次的人，能清楚看到具體層次正在發生什麼。
但站在具體層次的人，卻看不見上面到底還有什麼。

自己現在站在哪一層，從下面是看不出來的。
這就是只做具體工作的人，很難察覺「自己到底缺了什麼」的原因。
因為看不見的東西，就無法朝它前進。

具體與抽象不是天份決定的。但如果不主動往上一層走，上面的東西就永遠看不見。

接下來，我們來看看這道階梯在工程現場中，究竟分出了什麼。

為什麼現在工程師之間的差距正在快速擴大？

曾經使用過抽象思維的人，和沒怎麼使用過的人，在 AI 時代的差距正迅速拉開。

國中、高中六年都在學英文，但如果進入社會後不再使用，連簡單單字都會想不起來。
你有過這種經驗嗎？

明明花了很多時間記下來，卻因為不用就逐漸流失。
這和肌肉很像。
用得越多越強，不用就會退化。

其實，抽象化能力也是同樣的道理。

正如前面所說，SIer 下游承包的現場，本來就是由上游（抽象）交給總包方、下游（具體）交給下游廠商的結構。
照規格書做事被視為理所當然，「我覺得這樣做比較好」的提案，通常不會被採納。
按照指示、做足指示的部分，就是這個現場的評價標準。

在這裡工作過的人，不是不好。
只是結構上，根本沒有讓你使用抽象的機會。

而 AI 進來之後，情況就改變了。

對已經在使用抽象的人來說，AI 是強大的武器。

你可以把更多時間，放在原本就會自己思考的設計與問題發現上。
也就是說，你能夠持續使用抽象。

另一方面，對沒有機會使用抽象的人來說，AI 連最後的具體作業都會奪走。
原本只是照規格書實作的人，連那份實作也開始由 AI 代勞。
最後留下來的，只剩下向 AI 下指令、確認產出內容這種更被動的任務。

最近也越來越常看到經營者自己開始用 Claude Code 寫程式的案例。

那工程師是不是已經不需要了？

這是一個非常具有象徵性的現象。

經營者本來就是在處理事業與顧客課題這種抽象層面的工作。
原本欠缺的，只是把它落地成形的具體能力，也就是實作的手數。
當 AI 開始代為負責實作後，最後那塊拼圖也補上了，於是經營者自己就能一口氣做出產品。
商業之所以突然開始快速運轉，正是因為抽象層面能力強的人，身上的具體限制被拿掉了。

這在 FDE（Front-End Developer Experience Engineer）身上也完全一樣。
他們進入現場，從課題發現到設計與實作，都能一氣呵成地處理。
這類人因為 AI 而變得更輕盈、更好施展。
越是做抽象工作的人，就越能少花時間在具體上，因此優勢會進一步擴大。

這不是能力差異。

而是起跑點的差距，正被 AI 以乘法的方式放大。

原本就在抽象一側的人，會和 AI 成為夥伴，進一步加速。
原本只被交付具體工作的人，連具體也被 AI 奪走，最後只剩下替 AI 輸入提示詞的工作。

即使在同一家公司、同一個團隊裡，這兩條曲線也已經開始以不同速度前進。

更麻煩的是，還有另一件事。
這種差距，即使你發現了之後急著想追回來，也不容易縮小。

英文也是一樣，不是把單字本重新看一遍就能突然會說。
你得真的開口、真的講錯、真的修正。
沒有這樣反覆練習，手感是不會回來的。

抽象化也是如此。
就算你在書上讀到「具體與抽象很重要」並增加了知識，也只是站上起跑線而已。
必須靠自己實際把某件事抽象化，再換成另一種形式具體化。
如果沒有自己動手反覆做這個動作，它就不會成為真正的技能。
而且即使學會了，不用的話還是會像英文一樣退化。

也就是說，之所以會產生差距，以及差距為何不容易縮小，其根源是相同的。

「沒有使用過」這件事本身，就已經讓下一步變得更沉重了。

在 AI 時代也不會被奪走工作的工程師是誰？

不會被奪走工作的人，是在做抽象工作的工程師。

具備程式語言與框架的知識，是最基本的前提。
抽象層面的工作，是建立在即使沒有 AI 也能成立的核心能力之上。
如果沒有這些基礎，連 AI 產生的程式碼是否正確都無法判斷。

最近似乎有越來越多人因為覺得工程師工作快沒了，開始想轉去做 PM 或上游工作。
但如果連具體都做不好，卻想直接做抽象，從單向鏡法則來看，這是不可能的事。

具體是指：用這個語言撰寫、使用這個函式庫、採用這種寫法，這一個一個的實作細節。
抽象則是：到底要解決什麼、應該在哪裡劃出邊界、為什麼要這樣設計，也就是從中提取共通點的一方。

現在很多工程師都只是在研究 AI 工具、使用 AI 工具，這些都還停留在具體層面。
工具會隨著時代改變。
如果只追著具體跑，就會變成必須一直不停學習。

站在抽象層面的人，就不會因為語言改變而有問題。
具體層面的事情其實很簡單。
只要學會需要的東西就能用，甚至也可以直接交給 AI 去做。

如果你希望未來作為工程師能更有發揮空間，那就必須培養抽象能力。
為此，你需要快速掌握具體的核心技能，然後往前一章所說的抽象階梯往上走一層。

這就是第一個分岔點。

在 AI 持續發展、學習機會又逐漸減少的現代，如果連具體的核心技能都無法掌握，很多人就會直接放棄。

下一個分岔點，則是你能不能從那裡開始，練習往抽象階梯再爬上一層。

AI 會幫你承擔具體的工夫。
語法、常見寫法，它幾乎都能處理。

但要做出什麼，還是必須由人來決定。
現場業務的本質，本來就不是資料化的東西。
所以它也不會出現在 AI 的學習資料裡。

剩下的，就是抽象工作。
發現問題、設計方案、判斷取捨。
這些是人類的工作。

懂語言與框架，只是起跑線。
只有再往抽象層面上一層的人，才不會被 AI 奪走工作。

不會被 AI 奪走工作的，是站在更高一層階梯上的人。

工程師所需要的抽象能力究竟是什麼？

站在更高一層階梯上的人，所做的工作就是設計。

而在設計當中，最重要的是能導向問題解決的領域建模（domain modeling）。

可能很多人是第一次聽到「領域建模」這個詞。

領域（domain）指的是這套軟體所處理的世界。

如果是電商，就是「購買、配送、會員」的世界。
如果是西裝店，就是「量身、製作衣服」的世界。
這講的不是程式，而是現場本身。

模型（model）則是那個世界的示意圖。

不可能畫出全部。
因此，要從真實世界中抽出這個系統真正需要的要素，並加以表現。

建模（modeling）就是製作那張示意圖的過程。

把腦海中「現場原來是這樣運作的」這份心智模型，轉化成語言與結構。

領域驅動設計（DDD）的提出者 Eric Evans 曾這樣定義：

模型是描述領域中被選定面向的抽象系統。

不是把所有東西都模型化。
而是只切取被選中的面向。
並且讓這個切取方式，和現場人員腦中對世界的看法一致。
Evans 認為，這就是軟體設計的目的。

決定「要選什麼、要捨棄什麼」的那一方，就是策略性設計。
核心問題在哪裡？
模型邊界應該畫到哪裡？
不要把所有事情都用相同的比重處理。
只把核心部分濃縮成模型。
在決定如何拆分 class 之前，首先要做的就是這個切取。

例如，電商網站裡有「使用者」這個概念。
使用者包含姓名、年齡等資訊。
那麼，你左手的長度，算不算使用者資訊？
手臂長度通常不需要對吧。

但如果是訂製西裝的網站呢？
左手長度就會需要了。

也就是說，領域建模就是切分問題的方式。
這就是 Evans 所說的「被選定的面向」。
同樣是「使用者」，切法不同，內容就會不同。
要留下什麼、捨棄什麼。
這就是設計。

領域本身，就是商品勝負的關鍵。

不是框架，也不是漂亮的程式碼。
而是決定要解哪個問題。
這就是問題解決。

這種切取，AI 做不到。

假設眼前有一台相機，AI 正在即時觀看。

畫面中有我正在碰手機的照片。
那麼，你從這裡看出什麼問題了嗎？

不知道。
可能是沒電了。
可能是螢幕裂了。
也可能只是覺得手機太重。

即使看的是同一個場景，問題也不會只有一種。
能否抓住問題本身，AI 做不到。

所以，這是人類的工作。

接下來真正需要的是：抽象化的問題發現能力。
以及，如何把我們心中的心智模型具體地說出來。
再把這些語言封裝進程式碼裡。
這一段工作，非常、非常重要。

寫程式本身是具體的，所以 AI 也能做。
但要到達那一步之前，你的心智模型應該用什麼語言表達？
這點超重要。
只有先能夠用語言說出來，才有辦法落到程式碼這個具體層面。
無法用語言表達的東西，連丟給 AI 都做不到。

設計很重要。而設計的核心，就是領域建模。

切取問題、把心智模型語言化、再將它封裝進程式碼。
能完成這一整套流程的人，就站在更高一層的階梯上。

培養具體與抽象能力的重要思考方式

光是看書，或平常刻意提醒自己，具體與抽象都不會自然學會。

關於具體與抽象的書很多。
但那些書多半也都在談抽象概念，真正讀完後還能持續實踐的人其實非常少。
說到底，正因為你平常身處在不得不使用它的環境裡，才會被迫慢慢學會。

然而，在系統產業的結構裡，情況就不一樣了。
我前面已經說過，具體工作是從上面被分派下來的，這樣的機制本來就不容易讓人發揮創造力。

如果在日常裡無法自然習得，那該怎麼辦呢？

關鍵就在於單向鏡法則。

上層看不見下層。
如果不知道看不見的那一層該怎麼爬，就算只靠自己去想，也不知道方法。
到底要把什麼抽象化？
又要把它具體落到什麼程度？
這個階梯本身，從下往上是看不見的。

所以，具體與抽象才會這麼難作為一種技能被學會。

那該怎麼做？

答案很簡單。
只要請已經能做到上一層抽象的人，把階梯往下拆到具體層，並用體驗的方式教你怎麼爬就好了。

就算只是被告知知識，也跟看書沒什麼兩樣。
真正要做的是經歷它，理解階梯是怎麼爬的。

不會騎腳踏車的人，就算看再多 YouTube 教學，也還是不會騎。
真正重要的是實際騎上去學。

上一層階梯也是一樣。
只有站在上面的人，才有辦法指著你說：「你現在說的，是這一層。」

具體與抽象，是非常難學會的技能。
也正因如此，一旦學會，你在工程師裡就能站上頂尖位置。
AI 也奪不走你。

而在現代，能多快學會這種困難技能，就是一個巨大的分水嶺。
AI 會怎麼改變工作的結構，沒人知道。
也許明天就會變。

只靠自己闔上書本、心想「我要更有意識一點」，是來不及的。
你需要讓更高一層的人把階梯拆給你看，並在自己的工作這種具體情境中反覆實作。
我們需要的是這樣的練習場。

現在的分岔點，就是你能不能以實作的方式，盡快把這種困難技能學起來。

結語

這次，我以具體與抽象為核心，談了 AI 時代的工程師工作。

具體工作之所以很多，並不是你的能力有問題。
而是因為上游由總包方負責、下游由下游廠商負責，這就是產業結構本身。

每次效率化，工作的總量都會增加。
但增加的是任務。
真正解決問題的人，會變得很少。

留下來的，是抽象工作。
也就是設計。
而設計的核心，就是領域建模。
切取領域本身，就是產品勝負的關鍵。

但光看書，或只是在日常中提醒自己，是不會學會具體與抽象的。
上層看不見下層。
你只能請更上一層的人，把階梯拆給你看，並以體驗的方式一步一步往上爬。

如果不培養抽象能力，就會慢慢被推向「非你不可」之外的工作。

先從自己的工作中挑一件事，試著追問「為什麼」。
不要只問「要做什麼」，而是反問自己：「我們真正想解決的是什麼？」

在請人幫忙審閱這篇文章時，社群成員希望有機會透過實作來學習具體與抽象的能力。
因此，我決定在 9 月 27 日（六）舉辦讀書會。
也有線上參與方式。
如果你能來，歡迎你參加。

看到這裡的話，請幫我按個喜歡與收藏。
我們明天的文章再見！

JISOU 招募成員中！

程式設計教練 JISOU 正在招募新成員。
想不想在日本第一的輸出型社群裡提升你的職涯呢？
有興趣的人，歡迎直接從官網預約諮詢！
▼▼▼

我們有很多圖解實作分享！

原文出處：https://qiita.com/Sicut_study/items/b2ef2f7a6ee0dbbf0001