寶玉前幾天轉了 Tuhin Nair 的一篇文章，標題是《為什麼資深開發者講不清自己的專業能力》。我點開看完，戳到了。

我以為作者要罵的是工程師不會表達、PPT 做得爛，結果他切的點完全不一樣——資深開發者根本不是不會講，是站在跟業務完全相反的迴圈裡，用一套對方聽不懂的邏輯在說話。

我做了七、八年系統，被業務嫌「擋路」「太保守」「想太多」的次數，自己都記不清。每一次我都覺得對方不懂技術，現在回頭看，是我自己沒搞清楚對方在解什麼問題。

兩個迴圈，從來沒在同一條跑道上

Tuhin 的觀察很尖銳：業務團隊在跑的，是一個「消除不確定性」的迴圈——這個功能能不能賣？這個市場有沒有人要？這條廣告投放有沒有用？他們的工作就是不斷拋出假設、最小成本驗證、看結果再調整。對他們來說，速度是命。一週搞不定的事，三個月後可能整個議題都失效。

資深開發者跑的迴圈完全不一樣，是「管理複雜性」。

你維護的系統不是一個 Demo，是已經有客戶在付錢、半夜兩點不能掛掉、上面綁了三年累積的業務邏輯的東西。每加一行程式碼，你都在心裡算這條會不會踩到舊邏輯、會不會在年底結算那天爆掉、會不會三個月後被某個剛入職的新人改錯方向。資深開發者真正在保的，是這套系統十年後還活著。

兩個迴圈的方向就是反的。一邊追快、可以回滾，另一邊追穩、因為有些東西回滾不了——資料庫遷移、外洩的客戶資料、錯誤計算出去的對帳單。

問題是，兩邊都不知道對方在跑哪個迴圈。

你說「會出事」，業務聽到的是「我不做」

最尷尬的場景大概是這種：

業務說：「能不能在這個訂單流程加一個欄位？很簡單，只是多存一個值。」

你心裡的算盤是：訂單表已經 80 個欄位，再加一個你要動 ORM、改 API contract、改前端表單、改報表、改匯出 CSV 的程式、改三條後台稽核 query。然後這個欄位之後可能會被棄用，但棄用後欄位還在資料庫裡躺一輩子，每次新工程師接手都會問「這個欄位是幹嘛的」。

你開口：「這個改下去會動到很多地方，要評估一下。」

業務聽到的是：「我不想做。」

然後對方開始覺得工程師難搞、跨部門效率差、為什麼一個簡單需求要拖兩週。你覺得對方不懂技術、不尊重專業、永遠在送爛需求過來。兩邊都對自己很委屈。

我做政府案這幾年，最常遇到的版本是「主管下午開會要用」。某次承辦跑來：能不能加個查詢條件，按行政區分組看件數？我看了一下，現有的件數 query 聯集了三張歷史表加上動態權限過濾，要加分組得重寫 join、還會動到既有報表的合計。我跟他講了 20 分鐘為什麼這要兩天才動得了。對方回去之後，自己拿 Excel 把昨晚的匯出檔手動分行政區，下午會議就這樣硬上了。後來主管覺得這個分組蠻好用、要做進系統正式給其他人用，承辦直接把他手刻的計算邏輯丟給工程師，那段邏輯漏算了幾個早期的歷史代碼。三個月後件數對不上被內部稽核抓出來，回去追才知道是那次留下的後遺症。整件事我從頭到尾沒做錯任何技術判斷，但我把「我擔心」講成了「我不做」，剩下的就由不得我了——而且最後系統的爛攤子還是我接。

這篇文章戳破的就是這層：你用「控制複雜性」的話術去回應對方「消除不確定性」的需求，根本沒有交集。他要的是更快得到一個答案，你給他一份風險評估。他在問「能不能驗證這個假設」，你在回「這個架構不適合長期擴展」。對方聽完只覺得你跟需求無關。

AI 來了之後，這道翻譯題變得更難

過去十年，工程師還有一個天然護城河：寫程式碼這件事本身就慢、就門檻高，業務沒法繞過你。所以即使你話術不好、解釋不清，老闆還是知道「沒有他這東西做不出來」。

過去業務只能在背後抱怨你慢，現在他第一次覺得可以繞過你。

業務打開 Claude Code、Codex，丟一句「幫我做一個訂單匯出功能」，五分鐘真的吐出能跑的程式碼。雖然這份程式碼可能沒考慮交易並發、沒處理超大檔案 OOM、沒做權限檢查，但業務只看到「啊，能跑欸」。對他們而言，AI 解決了「速度」這個他們最在意的事。

那你還剩什麼？

我自己這幾個月也問過自己很多次。後來想通了：AI 寫得出程式碼，但承擔不了責任。

半夜系統爆掉，AI 不會起床。年底結算數字不對，AI 不會被叫去解釋。這些事的最後責任人都是你。

文章結尾就講這個——AI 能快速產出程式碼，但資深開發者不可替代的價值在於為系統長期穩定「承擔責任」。我看了三遍。它不浪漫，但精準。

真正該學的不是更深的技術，是翻譯

那要怎麼辦？我這陣子的體悟是，要把腦袋裡那套「我為什麼擔心」的邏輯，包裝成業務能聽懂的選項。

文章給了一句話術範本，我覺得很妙：「我們能不能試個更快的辦法？」

差別在哪？

舊版本：「這個架構不能這樣改，會影響到後續維護。」

新版本：「我們能不能試個更快的辦法？這個需求如果直接動訂單表，後面要動五個地方才能上線，可能要兩週。但如果我們先在側邊存一張小表驗證，三天可以給你結果，等驗證 OK 再決定要不要正式併進主表。」

兩句話的技術判斷是一模一樣的——我都不想動主表。但前者是拒絕，後者是提供加速路徑。業務聽完會覺得：「喔你不是不做，你是給我更快的選項。」

訊號完全反過來。

我以前最常犯的錯，是直接把心裡的擔憂講出口。我會說「這個之後會變技術債」、「這個耦合太緊」、「現在不重構之後會更難改」。這些都是真的。但對方接收到的訊號就是「你阻擋我」。

現在我會強迫自己多想一層：對方真正想要的是什麼？他想驗證一個假設、他想看一個數字、他想知道某個用戶會不會點某個按鈕。我能不能給他一條更短的路，先拿到他要的答案？

很多時候答案是可以。一張暫存表、一個 feature flag、一個 hardcode 寫死的版本，都比動五個檔案的「正式版本」快。對業務來說這就夠了。對我來說，我也守住了主系統不被亂改的底線。

兩邊的迴圈第一次有了交集。

一個小尷尬：這套話術不能濫用

寫到這裡我想多補一句，不然會變成「資深工程師都該去學業務話術」這種我自己也不信的結論。

不是每個需求都能找到「更快的辦法」。權限、客戶資料外洩、金流計算、法規合規、不可逆的資料庫遷移——這幾類沒有「慢一點」的版本，錯了就是錯了，沒得回頭。

這時候你的工作不是給對方一條更短的路，而是把問題從「我拒絕你」改成「這個風險最後誰要扛」。

我學到的版本長這樣：「這條我可以做，但我要先跟你講清楚會發生什麼。如果出事，是你扛、我扛、還是公司一起扛？你來決定。」前半段不擋路、後半段把責任攤開。決策權還是業務的，但你要確保他做這個決定時是清醒的——不是被你嚇住、也不是以為「工程師說可以就沒事」。

如果你連這層也不講清楚，業務就會去找 CTO 投訴、找老闆鬧、找實習生說「他不肯改我就自己改」——最後系統還是爛掉，你還背鍋。

這幾年看下來，能在公司裡走得久的資深工程師，幾乎沒有純技術派的。都是技術夠硬、然後願意花力氣把技術判斷翻譯成業務語言的人。不是因為他們圓滑，是因為他們搞清楚了一件事——護城河不是程式碼寫得多漂亮，是讓決策的人理解你的判斷為什麼值得信。

最後

我不確定這篇文章算不算「金句製造機」，但它至少給了我一個檢查點。下次當我又在會議上聽到自己脫口而出「這個架構不適合這樣改」的時候，我會停一下，問自己：對方真正想驗證的是什麼？我有沒有更短的路給他？

AI 越來越會寫程式碼這件事，要說我完全不焦慮是騙人的。我每天用 Claude Code 寫東西，看著它幾分鐘吐出我以前要花半天寫的程式碼，腦中當然會閃過「那我呢」。但這個焦慮的內容變了——以前怕的是「AI 會不會取代我」，現在怕的是「我講不清楚自己在負責什麼，讓決策的人以為我和 AI 是同一個位置」。

公司願意付我這份薪水，買的不是我打字快，是我願意為這套系統十年後還活著負責。而要讓買單的人相信這份責任值錢，我得先學會把這份責任講成他們聽得懂的話。

文章出處：