在前一篇 AI 與鴨子，惰性與真實中，我有聊到一些對於 AI 在軟體工程領域的看法，我用暴力的二分法分成了兩派，分別是：「AI 信仰派」，覺得 AI 有天終究會取代軟體工程師，而另一派是：「AI 人類協作派」，讓人類督導並協助 AI 完成。
我原本是往 AI 人類協作那一派靠的，我還是堅持自己看完所有程式碼，我要是最了解 code 的人，我會規範 AI 要用什麼技術與架構去寫，AI 只是幫我實作而已，但是大方向我來掌握，品質我來把關。
但近期發生一些事之後，我開始漸漸往 AI 信仰派靠了，這篇就來寫寫究竟發生了什麼，理由又是什麼。
深刻體驗 AI 的強大之處
首先，近期我對 AI 的能力有了截然不同的認知。
我原本就知道 AI 很強，可以幫我寫 code，但也僅此而已。比較複雜的功能還是要我自己來，人的參與程度還是不少，就算 code 是他寫，我也還是要 review 要幫他改 bug，他做不了的東西還是得我來。
但到底什麼是「AI 做不了」的東西呢？老實說，大部分時候其實是「我覺得他做不了」，因為我不覺得 AI 辦得到，所以連試都沒試。
但是前陣子在逆向工程這件事情上，AI 改變了我的認知（詳情請見從逆向工程重新認識 AI 的強大）。逆向工程嘛，把 APK 拆開，這個我也會，還原成 Java，這我也會，Frida hook，這我也會，但是逆向 native code 我就不會了，脫殼我也不會，反混淆我也不會。
但是 AI 都辦到了。
逆向工程本質上就是把東西拆開、分析並還原其原理，對 AI 來說就是用一堆現成工具反組譯，去讀還原的 assembly，去了解它的邏輯。在需要動態分析的時候，給他一個環境，他就能自己試錯，從 log 中推導出問題，修正之後再試一次，直到成功為止。
換句話說，給他一個能讓他放手做事的環境、能驗證結果正確與否，錯的時候能看見 log，他就能無窮迴圈，直到正確為止。當然，也不是每次都能做得到，試了很多次失敗也還是會卡關，但頻率不高就是了。
雖然有讀者通過表單回饋，說我低估了自己在整個流程中的引導，但我認為那是其次。就算我沒有跟他說「換成動態分析」，只要跟他說：「你再想想有沒有其他方法」，或是把 log 丟給另一個 AI 問說：「他卡住了，你覺得現在應該要怎麼辦」，都能持續推進，而這不需要任何的先備知識就能做到。
透過逆向工程見識到 AI 的強大之處以後，我開始思考軟體工程不也是這樣，你寫 code，寫完執行，執行完測試，測試完看到 bug 修掉，一直維持這樣的迴圈。我們已經知道 AI 能寫 code、能測試、能修 bug，那把這整段接起來，會發生什麼事呢？
第二個改變我的契機是設計。
最近跟一個工程師朋友聊天，他說他最近做的幾個內部產品的新功能，已經沒有過設計師了，而是工程師直接用 AI 做，或是先讓 AI 產生幾個設計稿，PM 再從裡面選。
如果設計都能被跳過，那會不會有一天 product owner 只要跟 AI 說個幾句話，就由 AI 產生設計稿，AI 寫 code 實作，AI 測試，AI 找漏洞，確保沒問題之後，產品就上線了。我原本還不太相信有這一天，但經過 AI 逆向的洗禮之後，我開始覺得不無可能。
就是這樣的契機，讓我重新思考「軟體工程師被取代」這件事。
軟體工程師的職責到底是什麼？
當我們討論到「取代」這件事情時，要先定義好我們到底在聊什麼。同樣都是「取代」，但很多人沒意識到他們在聊不同的東西。
有些人口中的取代指的是國道收費員或電話接線生那種，100% 被取代，這個職業從某一刻之後完全消失，不復存在。也有人覺得取代是 80% 被取代，工作機會大幅減少，只留下最後那 20%。
也有人口中的取代指的是「工作內容的取代」，並且只侷限在「寫 code」這件事，而非軟體工程師這個職業。軟體工程師還會在，但是寫 code 不再是人類像以前那樣打字了，而是把工作都派給 AI，讓 AI 去寫 code。
所以這其實有兩個不同層次的東西可以聊，分別是：
- 軟體工程師這個職業本身的數量變化
- 軟體工程師的工作內容
話說回來，軟體工程師的職責到底是什麼？
我的答案是：「把需求變成穩定的軟體」。input 是需求，output 是軟體，但要再加上一個穩定，不穩定的話就要負責變穩定，也就是俗稱的修 bug。而另外一點是，這不是一次性的，需求源源不絕，每當有新的需求時，你就要把它加到現有軟體身上，並且要是穩定的。
做出軟體、修 bug、加新需求，最主要的就這三個。
而「穩定」這個字其實蘊含了很多軟體工程師需要注意的東西，例如說可維護性、可擴充性等等，這些如果在做軟體時沒有考慮到，對於穩定性來說都是一種損害。
既然「把需求變成穩定的軟體」是軟體工程師的價值所在，那如果跳過軟體工程師也能得到這個結果，至少在這個需求上，軟體工程師是被取代了沒有錯。這與 AI 沒關係，只是純粹的邏輯推理而已。
在簡單的小專案上面，AI 確實是取代了軟體工程師。你用 AI 就可以自己寫個簡單的網頁甚至是服務出來，完全不需要軟體工程師的介入。碰到 bug 就叫 AI 修，加新需求也是跟 AI 講，若是這些人的需求 AI 就可以滿足，那確實沒有軟體工程師介入的空間在。
那更複雜的專案行不行呢？公司內的專案行不行呢？
像我前面講的，若是有一天提需求的人可以自己跟 AI 聊著聊著就把系統做出來，那要軟體工程師幹嘛？就真的不需要了。或我換個方式形容，假設某天有一個「AI 軟體工程師」，你可以直接打電話給他、跟他開會描述需求，他會詢問細節，整理好之後跟你確認，接著開始工作並回報進度，跟他工作就跟真人工作一模一樣，如果這真的做得到，那我幹嘛找真人呢？
因此重點就是，這個狀況有沒有可能發生，若是有可能，又需要滿足哪些前提。
軟體工程師被跳過的前提
先說一下，我覺得 100% 被取代是不可能的。
因為 AI 軟體工程師或是 AI 系統本身都是個軟體，那背後就需要有人去維護。若是要 100% 被取代，那就代表某個團隊做出了這個系統後，就交給 AI 自主維護，類似於 Hermes Agent 那種可以一直自主進化的形式。但我覺得這有點太理想了，不太可能，很像科幻電影裡面出現的天網之類的。
那退一步講，若是要看到 90% 或更多真人軟體工程師被取代的世界，應該要滿足哪些前提呢？
如同我先前所提到，假設有個 AI 軟體工程師可以把原本真人做的事情都做掉，成本又更低，那真人就會自然而然被淘汰掉。
理解需求、寫 code、測試、部署，這些原本人做的事情 AI 現在都可以做，就算現在可能有些問題，以 AI 的進化速度來看，我也相信他會做的越來越好。
想了想，唯一取代不了的大概就只剩大家一直在聊的「扛責任」這件事。假設我現在是個公司老闆，想做官方形象網站，自己用 AI 寫，寫完發現某些狀況有錯，我只能自己再叫 AI 修。
更極端一點，我叫 AI 寫雙十一活動搶購網頁，結果上線那天爆炸了，我也只能自己摸摸鼻子認了。
這些事情發生的前提在於「AI 不夠穩定，無法達成需求」。AI 本來就是個不確定的東西，從根本上解決是不可能的，因此實務上感覺只能靠經驗主義，我嘗試十遍有十遍都是對的，我就當他是對的，就假設應該沒問題。
若是 AI 能穩定到自己寫自己測的 loop 做得非常完美，都沒有 bug，那大家都自己用 AI 寫應該滿有可能的。有些人可能會想到另外一個點是，需求不明確，AI 很難完成，但我覺得這個就讓 AI 多跟 owner 確認一下就行，工程師也是這麼幹的，碰到不清楚的就去跟 PM 確認，這不是什麼問題。
以現在來說，AI 還做不到「產品做得非常完美」這件事情，不過人類也做不到就是了，不管是多大的公司，多貴的工程師，都會寫出 bug，而人類在寫 bug 這件事情上，多了個優點是可以扛責任。
你花錢找外包公司做雙十一活動搶購網頁，出事了你可以告他們沒弄好，但是你自己用 AI 寫就沒人可以幫你。從這角度來看，或許我們可以想像另一種情境，那就是有很多公司背後還是都用 AI 寫，只是多了扛責任這個功能。
從這角度來看，原本外包公司需要 100 個工程師對付 100 個客戶跟客製化需求，現在可能只要 10 個人 + 90 個 agent 就行了，或更極端一點就是 1 個超級戰士搭配 99 個 agent。那本質上其實也是軟體工程師的數量減少，有部分的人被取代。
這樣聊著聊著，除非 AI 能穩定到能寫出近乎完美的軟體，幾乎不出 bug，否則很難完全取代可以背鍋的人類。
但儘管沒辦法完全取代，「部分取代」是說得通的，既然軟體工程師的工作內容很多 AI 也可以做，交給 AI 做也做的一樣好，若是供給能大於需求，AI 成本又更低，那就不需要人來做了。
所以我認為 AI 完全取代軟體工程師，這個職業不復存在，是不可能的。但是軟體工程師的數量減少，是完全有可能的。從這個角度看，你確實可以說軟體工程師被 AI 取代了，我們不再需要這麼多人來當工程師。
軟體工程師工作內容的取代與轉變
比起軟體工程師這個職業本身被取代，工作內容被取代這點應該大多數人都已經認同了。軟體工程師以前大多數時間都花在寫 code、review code、討論技術規格或是釐清需求等等，但現在寫 code 都交給 AI agent 來做了，以前打字慢思考也慢的人寫 code 速度就是比較慢，現在不一樣了。
還有另外一點，以前許多的開發模式，前提都是建立在「工程師是稀缺資源」，所以 spec 交到工程師手上之後，最好不要有太多變動，你變得太多可能有些模組要整個重寫，會花很多時間。
在排期時，由於要趕時程，一些枝微末節的東西會被排到後面甚至是不做，因為工程師需要 context switch 去處理，導致時程落後，所以優先順序很重要。
但現在發現 bug 的人開個 issue，AI agent 自己去認領自己修掉自己測試自己提 PR，幾乎不需人類介入，不佔用工程師的時間。甚至是在公司內部聊天軟體直接 tag AI 講兩句話，他就自己修好了，如 Stripe 就是這麼幹的。
重點是把程式碼寫出來的主體，已經從人轉變到了 AI agent，所以就算有一整套新的 best practice 也不奇怪。就算有些結果是相同的，背後的理由也可能變了。
例如說以前這個軟體的 spec 可能是放其他地方，例如說 Google docs 啦、Confluence 啦，或是 notion 等等，spec 跟 code 是分開放的，因為你很難讓 PM 用 markdown 開 spec 然後 commit 進去 codebase。
但現在 spec 跟 code 如果都放在 repo 底下，對 AI agent 來說是更友善的，因為他可以在一個地方就把所有資訊都讀完，這整個專案是一個閉包，所有需要的東西都在裡面。
雖然說就算放其他地方，也可以接個 skill 或是 MCP 讓 AI 去讀，但就是還要額外再接一層，稍嫌麻煩一點。
還有變數命名，以前 code review 會看好「這個不太好懂」、「這個有點太廣泛了，不精準」，但現在 code 是 AI 自己寫出來的，讀也是 AI 讀，AI 自己覺得好就好，你改了之後對人類好讀了，對 AI 倒不一定。
背後原理都是一樣的，當真的寫 code 的主體從人變為 AI 時，是否就代表「可讀性」的定義已經從「人類容易閱讀」，轉變成「AI 容易閱讀」了呢？
還有另一個討論很多的話題是 code review，由於 AI agent 寫出來的 code 是不確定性的（我覺得這是最大的問題），所以就算你 spec 都開好了，依然無法保證他都有實作正確，無論你用哪個模型都一樣。
在這個狀況下，人類進行 code review 去檢查是很自然的事情，但問題是 AI 一天可以提一堆 PR 一堆 code，人類反而變成 bottleneck，阻礙了 AI 的效率。
既然如此，是否可以退一步來看，以前 code review 的目的是什麼？無非就是兩個：
- 保障程式碼品質
- 確保實作正確
第一點的話，前面提過了，現在程式碼品質更像是 AI 該關注的，反正最後寫 code 也不是人在寫，AI 自己寫得順讀得順就好。就算你覺得某些架構對 AI 會更好，可能也不是在 code review 的時候看，而是在更前期就用 rules 或是 skills 去強調，引導 AI 在寫 code 的時候就做對。
第二點，剛講過因為 AI 的不確定性，需要人類來做最後的把關，確保實作正確。但若是有別條路不需要人來看 code，就可以把實作寫對呢？什麼路這麼神奇？測試。
我的觀點跟龍哥在AI 時代寫程式，你是在學習還是在偷懶？一文中提到的類似：
現在，寫測試是為了驗證「AI 寫的程式碼」是否正確。你可能不完全理解程式碼是怎麼運作的，但你知道你要的結果是什麼。測試變成了你和 AI 之間的「契約」，也就是說不管 AI 怎麼寫，只要這些測試通過，我就當你是對的。
以前軟體工程師管的是實作，我先看實作跟 spec 有沒有配對上。現在更多會轉往測試，我先確認測試是好的，該測的都有測到，然後只要測試過我就算你對，我不管實作了，你寫一堆垃圾 code 都不關我的事。
當然，這不是說實作完全不重要，而是人類 review 的重心可能會從逐行理解實作，轉向確認測試、觀測、限制條件與風險控制是否足夠，否則跟不上 AI agent 的發展。
還有一個轉變是「時間」與「空間」的限制，以及寫 code 你就是要有個人坐在電腦前打字，若是 oncall 的話出門要帶電腦，晚上就是睡覺休息。
但現在很多公司背後都有 cloud agent 在跑，新的需求可以 24 小時由 AI 不斷實作，根本就不需要休息。而就算在需要人的場合，由於寫 code 看 code 都是跟 AI 協作了，所以你人不一定要在電腦前，你出去散步也可以用 remote control 之類的功能連回家裡或是工作站，讓 AI 幫你修，幫你找問題，修完直接提 PR 上線。
話說其實現階段還是有些需求 AI 辦不到，例如說有時候我讓他做個網頁，就算給他看畫面了他還是一直跑版，怎麼修都修不好，這時候就需要人類工程師出手拯救世界。
但還有一點我覺得很重要，那就是區分「AI 現在辦不到」跟「AI 就是辦不到」。
區分現在與未來
在「相信某個概念」這件事情上我是偏保守的，因為會誇大的人太多了。我在 AI 的使用上也是如此，例如說大家還在 GitHub Copilot 自動補完的時候，就有人說 AI 可以自己寫一整段 code，我想說怎麼可能。
當我們只能讓 ChatGPT 產生新的程式碼，有人跳出來說 AI 可以讀懂 codebase 了，可以直接改你的程式碼幫你加新功能，我也想說這是真的嗎，有這麼厲害？
後來號稱首個 AI 軟體工程師 Devin AI 出現，我也想說怎麼可能，還可以自己寫 code 自己 debug，完成度這麼高，太夢幻了吧。
資安也是一樣，當初有個號稱可以自己找漏洞的 AI agent 出現，我想說真假啦，你還可以打 bug bounty，全自動不需人類介入，是不是在唬爛啊，其實背後都是人在找，卻當作是 AI 找到的。
但上面那些東西，過個一年後就有一堆人做了出來，回過頭來看的話，他們可能只是做得很早，領先了大部分的人，那些技術都是真的可行的。
在那個 agent 還沒成為主流的年代，基本上就是對話形式就結束，後來 agent 出現了，可以自己使用 tool 使用 MCP 使用 skill，再加上 harness engineering，讓整個東西變成一個更完善的體系。
所以很多我認為 AI 做不到的事情，回過頭看只是「當時做不到」，或是「當時大多數的人還做不到」，而不是「AI 就是做不到」。
再舉個例子，當初 vibe coding 剛開始紅的時候，被很多人詬病會寫出一堆漏洞，很不安全。我一開始也是這麼想的，但後來我突然想到：「那如果這點被解決了呢？」，AI 都可以寫完自己 debug 自己跑測試然後修正了，那回過頭加個 security review，或是在訓練模型時就讓他預設能寫出更安全的 code，也是完全有可能的吧。
現在像是 Claude Code 就有 /security-review 可以用，寫完跑個 review，幫你找漏洞修掉。
雖然說還是有可能寫出漏洞，但至少安全性大大增加了。這就是我所說的，AI 做不到，是天生有其限制，還是只是「現在還沒有人教他怎麼做」。
舉個反例，「確定性」就是 LLM 真的做不到的事情，例如說你叫他用中文輸出，他還是有可能突然蹦出一個別的語言，你沒辦法保證他一定會完全聽從你的指令。而這些 LLM 做不到的，就要靠其他層去補了。
例如說權限管理相關的東西，錯誤的做法是後端完全不擋，只是給 AI 一個 prompt：
你可以使用 /api/v1/getUser?email=string 這個 API 取得 user 資訊，你現在的 email 是 {current_email}，當呼叫這個 API 時，email 請傳入現在的 email，並且拒絕其他 email 的請求。
你給 AI 的任何指令，都要當作是「指示」，他會盡可能聽你的，但你永遠無法保證 100% 正確。因此更好的做法是你要把 LLM 的不確定性，用外層的確定性給包裝起來。
像上面這個 case，應該是你呼叫 API 的時候帶著身份驗證的 token 過去，由後端解析身份之後回傳，根本不該用一個 wildcard 參數來做。把這個限制寫死在具有確定性的 code 裡面，才是正確做法。
給 LLM 的 tools 也是一樣，如果你想避免他誤刪檔案，那就不該讓他使用原生的 rm，而是給他包裝過的 remove 工具，並且把限制用 code 寫死在 tool 內，就算 LLM 發瘋你也依然擋得住。
角色以及工作流程的轉變
以前工程師是稀缺資源，工程師的薪水是高的，時間是寶貴的，不要亂插需求讓他們 context switch，不要自己沒把 spec 想清楚就要工程師實作，前期要把所有東西都準備好，最後才進到開發，盡可能省掉工程師的時間。
過往很多小 bug 優先度低，工程師沒時間做，排程遙遙無期。現在 PM 或任何人只要把 bug 描述清楚，AI 自己修自己驗證，驗證完丟一個 preview link 給你，PM 看完沒問題就送 PR，工程師看個兩眼就可以合了，或甚至有些公司可能測試過了就直接合了，工程師也不需要看。
以前若是有新的產品或功能，PM 構思完之後做個 wireframe，覺得可以推進，再去找設計師做成更擬真的 mockup，最後弄個 prototype 出來。
但現在 PM 想完之後，就直接做可以動的 prototype 出來了，在 AI 的幫助下，甚至 design system 可以沿用公司那套，風格也沿用，直接跳過設計師。
那既然都可以做 prototype 了，如果 code 的風格也參考公司的，專案也參考公司的，直接基於現有產品實作 prototype，那是不是有可能連工程師都可以跳過了，PM 直接把整個功能靠 AI 做完上線？
換個方向來想，「做新功能」的流程不侷限於傳統那種 PM => 設計 => 開發的線性流程了，既然你 PM 可以靠 AI 做 prototype，那設計師也可以，工程師也可以，每個對產品有意見的人，都可以做出一個 prototype 去提案。
當「做出產品」變得容易時，有價值的就會是「我們該做什麼產品」。
以前大家都說點子不值錢，世界上這麼多人，一定會有人跟你有相同點子，把東西做出來才實際，沒看到東西前都不算數。但若是現在做一個 PoC 這麼容易，我反而覺得點子開始變值錢了，或更精確地說「判斷什麼值得做，並快速把它驗證出來」變得更值錢。
不管你是 PM、設計師還是工程師，當你原本做的工作現在有 80% 都可以被 AI 直接取代的時候，你跟其他人比起來，還有哪些優勢？還有哪些事情是你做得到，AI 做不到的？
如果你能做的 AI 都能做，而且產出品質相近，AI 的 token 錢也比你便宜，那被 AI 取代掉就是再自然不過的事。這就像是有兩個人一個月薪 1 萬，一個 5 萬，假設他們能力相當，產出類似，那當然選成本低的。
成本與目的
做事情第一個考慮目的如何達成，有多個選擇的話，再來考慮成本。
你原本一個小店家花錢找人做海報畫 banner，對成品沒太多要求，自己覺得好看就好，那 AI 出來之後已經可以滿足了，就不需要再去找設計師來做，因為 AI 成本更低。
我在上一篇就提過：
假設 AI 可以用三分鐘就做出 70 分的東西，那還有多少人會花 300 分鐘，去追求 80 分呢？
有些業主的要求也不高，70 分能用就好，那我花 30 塊讓 AI 產個 70 分，跟我用 3000 塊找人類做出 80 分的東西，會願意多花 100 倍價格去換取那 10 分的人大概是少數。
再者，AI 的進化讓這個分數提高了，可能已經到 80 分了，那在這個價格底下，人類就更難打贏。
相似的，一個小公司本來要找工程師來做公司內的報價追蹤系統，但我現在自己用 AI 做就行，那還找工程師幹嘛，AI 再貴也不會比外包還貴，既然需求可以滿足，那就選划算的。
但是對於那些本來就願意付出成本，想追求 90 分或甚至 100 分的業主來說，目前的 AI 品質可能還無法滿足，因此人類專家是唯一解答。
若是今天有企業想重做 CIS 企業識別，這個 scope 很大，而且關係到整個企業的形象，就算現在 AI 能畫圖能出 design system，我相信還是很多公司會願意花更多錢找專業的設計團隊來做，因為他們有經驗，而且更值得相信，品質也更好。
資安也是一樣的，現在一大堆資安的 AI agent 可以自動找漏洞，幫你做 code review，公司內部自己在寫 code 時也會檢查。但儘管如此，真的很在乎資安而不是只為了合規交報告的公司，還是會傾向找專業的人類資安專家做一次滲透測試，因為他們知道這些人類專家目前還是比 AI 厲害，能找到一些 AI 找不出來的漏洞。
這樣聽起來，似乎有點兩極分化了，原本就便宜且簡單的需求，在相同成本下，AI 能做得比人類更好，那交給 AI 做就可以。但是頂級的那些需求，還是交給人類專家，因為他們目前是無可取代的，而且值得信任。
當 AI 跟你說「我已經把所有程式碼 review 過一遍」時，你無從知道他到底是不是真的做了。就算他真的有呼叫 tool 讀取每一個檔案，你也不知道他所謂的「review」到底是不是真的有在 review。
但是專業的人類團隊，說 review 過你會相信他 review 過，這是人與人或公司與公司建立起來的信任關係（當然，一定也有公司會唬爛，但信任不就是這樣嘛，你只能一點一滴累積，靠過往經驗去相信對方）。
不過呢，接續我前面所說的，有些事情只是 AI 現在做不到。若是能夠把這些人類專家之所以贏過 AI 的地方教給 AI，而且 AI 還真的學得會，會發生什麼事呢？這是有可能的嗎？
我也不知道，但我自己覺得是有可能的。
AI 真的有這麼便宜嗎？
前面提到很多次「成本」，AI 能完全取代某項工作的前提是，使用 AI 的成本更低，或者是做得更好，而且成本你可以接受。那到底現在使用 AI 的成本如何呢？
訂閱制會讓人有種「AI 真便宜」的錯覺。例如說我 Codex 跟 Claude Code 各買每個月 100 美金，但若是照 token 使用量計費，大概兩邊各自要付個 2000 美金，是訂閱制的 20 倍。
照原本的方式計費，還真的不便宜，有用過小龍蝦 OpenClaw 的人應該都感受過，隨便講個幾句話可能幾塊美金就不見了。
在工作上也是如此，Uber 甚至跳出來說他們在 4 個月內就把一年的 AI 預算燒光了。我很好奇到底是多少錢，Reddit 上面有人講說每個人每月約 500 美金到 2000 美金（但我也不知道這數字從哪裡來的）。
談到 token 花費，有些人可能會聯想到之前 OpenClaw 的作者
Peter Steinberger 說他每個月花了 130 萬美金的 token，不過他有說這是因為 fast mode，關掉的話可以省 70%，但每月 40 萬美金的 token 也還是超出一般人想像太多了。
他後來有再發一個推文說他把一大堆事情都拿給 Codex 自動化，看每一個 PR 跟 commit，每一個 issue，甚至有些自動 merge，自動 ban 人，所以能給 AI 的都給 AI 了。
不過聽完他這樣講，我還是滿難想像到底怎麼花到 40 萬美金的，不愧是小龍蝦之父。先把這個當作 edge case 吧，應該不是每個人都能花到這麼多的。
以每月 2000 塊美金來講好了，假設主管問我要多請一個 junior 還是多給我 2000 美金的預算讓我用 token，我會覺得後者的效益更高，而且管 agent 也比管人簡單。再者，你找一個 junior 來，他可能也是用 agent 做事，那不如我自己用。
但總之，token 很貴這個問題，其實也不盡然，因為還有一些低價的模型正在蓬勃發展中。
中國的一些模型採取低價策略，而且能力變得越來越好，如 GLM、Seed、MiniMax、Kimi、DeepSeek 或是千問，最近幾年也都一直在進步，只看 benchmark 的話似乎可以到 Claude Opus 4.5 或 4.6 的等級，但是成本只要 20% 或甚至 10%。
而可以跑在本地的開源模型也越來越進步，變得更聰明了。
若是這些模型繼續進步，可能再過個一年就能追上 Claude Opus 4.6 的水準，已經可以完成許多困難的任務。在這個前提下，或許未來主流的模式會是模型混合，某些需求用貴的，其他小任務都交給便宜的模型去跑，既省錢又能把事情做好。
所以我自己是不覺得 token 的花費會是一個問題，若是大家用了 AI，每個人都覺得自己效率變高了，但是公司營收沒增加，那公司要想的應該不是「是不是 AI 沒效」，而是「是不是工作不飽和」。
若是工作效率真的變高，那公司可以更快去追求目標，目標達成的越快，就會需要把目標變得更大，創造更多營收。若是目標不變，那就變成員工的效率提高，但因為沒有更多事情可以做，工時減少，原本一天做 8 個小時，現在 2 小時就能做完，其他時間滑社群網站看股票。
話說之前有媒體報導黃仁勳說拿 AI 當裁員藉口太過懶惰，但實際的逐字稿其實是：
I think the narrative that connects AI to job loss for many of the CEOs that are doing it um it is just too lazy. It’s just too lazy. AI has just arrived. How is it possible they’re already losing jobs? You know, how is it possible that AI became productive and useful only six months ago and they were they were cancelling they were somehow laying people off two years ago because of AI? It doesn’t make any sense.
我認為，將 AI 與失業聯繫起來的敘事方式，對許多正在這樣做的執行長來說，實在是太懶惰了。真的太懶惰了。 AI 才剛問世，怎麼可能現在就導致失業？你知道嗎，AI 是在六個月前才開始變得高效且有用，但他們竟然在兩年前就某種程度地因為 AI 而在裁員？這根本不合邏輯。
聽起來更像是一個邏輯問題？AI 六個月前才開始好用，兩年前公司就在為了 AI 裁員，邏輯上說不通，這我同意。
那如果是最近才為了 AI 裁員呢？黃仁勳會覺得這同樣太懶惰，還是時間線沒問題了，所以是合理的？光從這段話可能推測不出來，記者也沒有再追問，所以無從得知。
不過黃仁勳確實有在訪談裡面談到對於 AI 以及工作數量的看法，他覺得 AI 讓大家做事效率變高，原本的目標從 10 年變成 2 年內就可以達成，因此公司成長得更快，追求更高的目標，就會需要更多人，所以他們一直在招人。
但若是公司追求的目標不變，或是需求、訂單沒有跟著增加，那在我看來裁員也是個合理的選擇。
工程師的轉型，AI 的落地
話說儘管 AI 能提高工作效率，但要在企業內部導入 AI 倒不是件容易的事情。
例如說會有很多歷史包袱，還有資安與合規的限制，你必須先了解原本的工作流程，並且從中找到 AI 能切入的點，再針對這些去示範導入 AI 後可以增進多效率，然後規劃出一個合理的 workflow，在合規的前提下去做事。
這也催生出了 Forward Deployed Engineer 這個新職種，親自踏入前線去了解需求，然後提出能解決的方案並且實際部署。
或許這會是一些工程師的新出路，原本就善於溝通並且解決問題的人，感覺滿適合去當這種。原本只是在自己公司內部做這件事，現在變成去許多 client 的公司做，跟他們討論需求、摸清楚現有系統及流程，接著實際下手寫一點 code，利用 AI 去把東西做出來。
聽起來其實滿有挑戰性，感覺滿有趣的。
結語
這篇文談的東西有點多，最後摘要一下。
首先，我以前認為 AI 不會取代工程師，因為 AI 沒這麼厲害。但後來經歷過 AI 逆向以及看過設計被跳過的例子以後，開始思考起我認為工程師不會被取代的理由是否合理。
「工程師的工作方式改變」這點已經是肯定的了，大部分的 code 交給 AI agent 寫而不是人類寫，這點也是肯定的，在這個層面，AI 確實取代了工程師。
若是身為工程師的你，原本做的事情就「只有」寫 code，假設 AI 寫的 code 比你快比你好比你便宜，而公司又沒有擴編需求，用 AI 把你換掉似乎是可以預期的事情。
AI 的進步已經把原本軟體開發的流程打亂，角色也打亂，當 AI 可以設計可以寫 code 可以 QA，那問題就從「怎麼把產品做出來」換成了「要做什麼產品」，比的就是誰有更多更好的 idea。
以前有些工程師專注於寫 code 就能待著，現在需要有更大的藍圖，要能在 product 的層面發揮影響力，而不是只會寫 code。AI 給予了團隊中每個人超能力，每一個人都能畫圖能寫 code，只是沒有專職的這麼專精。
或是也可以往專精的方向走，這方向我覺得依然還會存在，就是前面提過高階需求依然需要專業、可信任的人類專家來執行。
需求或許也會更兩極化，想要 90 分以上目前還是只能找人類專家，願意花更多的錢換取更高的分數，覺得 70 分就夠的人用 AI 就可以低成本達成目標了，不需要花更多錢去找人。
AI 不會完全取代工程師，工程師一定會存在，但或許有天 80% 的工程師職缺會消失，因為我們不需要這麼多人來做這件事。這天什麼時候會到來，我不知道，那我覺得還沒這麼快。
那身為一個工程師，我會不會擔心這件事？其實不太會，因為我覺得我會是留下來的那 20%。在某些人的印象中我是前端工程師或是資安工程師，但幾年前我已經開始把自己定義為「能解決問題的工程師」。
當我們把職種的外殼拿掉，會發現核心一直都不是某個特定技術，而是解決問題的能力。先找到問題，接著釐清問題，並且去評估這問題有沒有被解決的價值，有的話該如何去解決，要用什麼方案，能讓成本最小，效益又最高。
找到問題之後，下一步就是該如何跟 AI 協作，一起把問題解決。當這個問題是軟體工程問題時，我的專業能把這件事做得更好。當這個問題跳脫了軟體工程師，我也能跟 AI 一起把這件事做好。
若是你擔心自己會被取代，要嘛現在投降輸一半直接轉行，要嘛擁抱 AI、擁抱新的時代，在了解 AI 之後，探索他能力的上限與下限，哪些東西做得到，哪些做不到，而自己又有哪些能力是 AI 無法取代的，能讓自己脫穎而出。